Skip navigation
Cisco Learning Home > Certifications > Routing & Switching (CCNP) > Discussions

_Communities

This Question is Answered
6853 Views 13 Replies Latest reply: Jan 3, 2014 7:01 AM by GOVARDHANA RSS

Currently Being Moderated

BGP NEIGHBOR STATES QUESTION

Mar 20, 2011 11:14 AM

Jaris 59 posts since
Jun 9, 2010

Hi everybody; I have a doubt about the states of BGP before to ESTABLISHED.

 

According with the material of BGP, the next are the states:

 

1) Idle - The BGP process is either administratively down or awaiting the next retry attempt.

2) Connect - The BGP process is waiting for the TCP connection to be completed. You cannot determine from this state information whether the TCP connection can complete.

3) Active - The TCP connection has been completed, but no BGP messages have been sent to the peer yet.

4) Opensent - The TCP connection exists, and a BGP Open message has been sent to the peer, but the matching Open message has not yet been received from the other router.

5) Openconfirm - An Open message has been both sent to and received from the other router. The next step is to receive a BGP Keepalive message (to confirm all neighborrelated parameters matched) or BGP Notification message (to learn there is some mismatch in neighbor parameters).

6) Established - All neighbor parameters match, the neighbor relationship works, and the peers can now exchange Update messages.

 

In another book I found these:

 

1) Idle: No peering; router is looking for neighbor. Idle (admin) means that the neighbor relationship has been administratively shut down.

2) Connect: TCP handshake completed.

3) OpenSent, or Active: An open message was sent to try to establish the peering.

4) OpenConfirm: Router has received a reply to the open message.

5) Established: Routers have a BGP peering session. This is the desired state.

 

So I'm a little bit confused about the differences between CONNECT and ACTIVE state.

 

In this example, I ran the "debug ip bgp" command  then I configured BGP in both routers but I can never see the CONNECT state.

 

R1#

*Mar  1 02:11:01.827: BGP: 10.1.1.2 went from Idle to Active

*Mar  1 02:11:01.839: BGP: 10.1.1.2 open active, local address 10.1.1.1

*Mar  1 02:11:01.935: BGP: 10.1.1.2 went from Active to OpenSent

*Mar  1 02:11:01.939: BGP: 10.1.1.2 sending OPEN, version 4, my as: 100, holdtime 180 seconds

*Mar  1 02:11:01.947: BGP: 10.1.1.2 send message type 1, length (incl. header) 45

*Mar  1 02:11:02.035: BGP: 10.1.1.2 rcv message type 1, length (excl. header) 26

*Mar  1 02:11:02.035: BGP: 10.1.1.2 rcv OPEN, version 4, holdtime 180 seconds

*Mar  1 02:11:02.039: BGP: 10.1.1.2 rcv OPEN w/ OPTION parameter len: 16

*Mar  1 02:11:02.039: BGP: 10.1.1.2 rcvd OPEN w/ optional parameter type 2 (Capability) len 6

*Mar  1 02:11:02.043: BGP: 10.1.1.2 OPEN has CAPABILITY code: 1, length 4

*Mar  1 02:11:02.043: BGP: 10.1.1.2 OPEN has MP_EXT CAP for afi/safi: 1/1

*Mar  1 02:11:02.047: BGP: 10.1.1.2 rcvd OPEN w/ optional parameter type 2 (Capability) len 2

*Mar  1 02:11:02.051: BGP: 10.1.1.2 OPEN has CAPABILITY code: 128, length 0

*Mar  1 02:11:02.051: BGP: 10.1.1.2 OPEN has ROUTE-REFRESH capability(old) for all address-families

*Mar  1 02:11:02.051: BGP: 10.1.1.2 rcvd OPEN w/ optional parameter type 2 (Capability) len 2

*Mar  1 02:11:02.051: BGP: 10.1.1.2 OPEN has CAPABILITY code: 2, length 0

*Mar  1 02:11:02.051: BGP: 10.1.1.2 OPEN has ROUTE-REFRESH capability(new) for all address-families BGP: 10.1.1.2 rcvd OPEN w/ remote AS 200

*Mar  1 02:11:02.051: BGP: 10.1.1.2 went from OpenSent to OpenConfirm

*Mar  1 02:11:02.051: BGP: 10.1.1.2 went from OpenConfirm to Established

*Mar  1 02:11:02.055: %BGP-5-ADJCHANGE: neighbor 10.1.1.2 Up

  • Currently Being Moderated
    3. Mar 29, 2011 4:40 PM (in response to Jaris)
    Re: BGP NEIGHBOR STATES QUESTION

    Congratulations on passing the ROUTE exam.  There is no "connect" state that I am aware of.  I would go with the first set of BGP states that you listed in your original post.  Those are the correct ones.  That's the reason you didn't see "connect" in your debugs.  That's not a state.

  • Scott Morris - CCDE/4xCCIE/2xJNCIE 8,396 posts since
    Oct 7, 2008
    Currently Being Moderated
    4. Mar 30, 2011 2:06 AM (in response to Jaris)
    Re: BGP NEIGHBOR STATES QUESTION

    By the way, it's not really kosher to give yourself points for a message. 

     

    I'm not entirely sure there's a connect state either, but I'd suggest trying debugs on BOTH sides to find out.  Only one side is going to hit that trigger for the three-way handshake completing first.  The other side may skip it/not notice.

     

    *shrug*

     

    Congrats though!

     

    Scott

  • Currently Being Moderated
    5. Mar 30, 2011 4:45 AM (in response to Jaris)
    Re: BGP NEIGHBOR STATES QUESTION

    I looked it up in the RFC and "Connect" is a BGP state.  Very cool.  There really is no difference in the two states.  One waits for the TCP connection to complete and one "actively" tries to complete the TCP connection.  You may find that Scott is right on.  Run the debug on the side opposite the one you ran the first one.

  • BIGEVIL 347 posts since
    Jun 28, 2008
    Currently Being Moderated
    6. Mar 30, 2011 6:55 AM (in response to Erick)
    Re: BGP NEIGHBOR STATES QUESTION

    This bugged me so i just tried it.

     

    I have GNS3 router R1 & R2

     

    I issued clear bgp* on R1

     

     

    R1#

    *Mar  1 00:24:11.155: BGP: 10.10.10.2 went from Established to Idle

    *Mar  1 00:24:11.155: %BGP-5-ADJCHANGE: neighbor 10.10.10.2 Down User reset

    R1#

    *Mar  1 00:24:11.155: BGP: 10.10.10.2 closing

    R1#

    *Mar  1 00:24:31.223: BGP: 10.10.10.2 went from Idle to Active

    *Mar  1 00:24:31.223: BGP: 10.10.10.2 open active, delay 5610ms

    R1#

    *Mar  1 00:24:36.835: BGP: 10.10.10.2 open active, local address 10.10.10.1

    *Mar  1 00:24:36.911: BGP: 10.10.10.2 went from Active to OpenSent

    *Mar  1 00:24:36.911: BGP: 10.10.10.2 sending OPEN, version 4, my as: 1

    *Mar  1 00:24:36.915: BGP: 10.10.10.2 send message type 1, length (incl. header) 45

    *Mar  1 00:24:37.151: BGP: 10.10.10.2 rcv message type 1, length (excl. header) 26

    *Mar  1 00:24:37.155: BGP: 10.10.10.2 rcv OPEN, version 4

    *Mar  1 00:24:37.155: BGP: 10.10.10.2 rcv OPEN w/ OPTION parameter len: 16

    *Mar  1 00:24:37.155: BGP: 10.10.10.2 rcvd OPEN w/ optional parameter type 2 (Capability) len 6

    *Mar  1 00:24:37.155: BGP: 10.10.10.2 OPEN has CAPABILITY code: 1, length 4

    *Mar  1 00:24:37.155: BGP: 10.10.10.2 OPEN has MP_EXT CAP for afi/safi: 1/1

    *Mar  1 00:24:37.155: BGP: 10.10.10.2 rcvd OPEN w/ optional parameter type 2 (Capability) len 2

    *Mar  1 00:24:37.155: BGP: 10.10.10.2 OPEN has CAPABILITY code: 128, length 0

    *Mar  1 00:24:37.155: BGP: 10.10.10.2 OPEN has R

    R1#OUTE-REFRESH capability(old) for all address-families

    *Mar  1 00:24:37.159: BGP: 10.10.10.2 rcvd OPEN w/ optional parameter type 2 (Capability) len 2

    *Mar  1 00:24:37.159: BGP: 10.10.10.2 OPEN has CAPABILITY code: 2, length 0

    *Mar  1 00:24:37.159: BGP: 10.10.10.2 OPEN has ROUTE-REFRESH capability(new) for all address-families

    *Mar  1 00:24:37.159: BGP: 10.10.10.2 went from OpenSent to OpenConfirm

    *Mar  1 00:24:37.159: BGP: 10.10.10.2 went from OpenConfirm to Established

    *Mar  1 00:24:37.159: %BGP-5-ADJCHANGE: neighbor 10.10.10.2 Up

     

     

    From R2

     

    R2#

    *Mar  1 00:23:58.251: BGP: 10.10.10.1 remote close, state CLOSEWAIT

    *Mar  1 00:23:58.251: BGP: 10.10.10.1 -reset the session

    *Mar  1 00:23:59.251: BGP: 10.10.10.1 went from Established to Idle

    *Mar  1 00:23:59.251: %BGP-5-ADJCHANGE: neighbor 10.10.10.1 Down Peer closed the session

    *Mar  1 00:23:59.251: BGP: 10.10.10.1 closing

    *Mar  1 00:23:59.251: BGPNSF state: 10.10.10.1 went from nsf_not_active to nsf_not_active

    R2#

    *Mar  1 00:24:19.255: BGP: 10.10.10.1 went from Idle to Active

    *Mar  1 00:24:19.255: BGP: 10.10.10.1 open active, delay 6499ms

    R2#

    *Mar  1 00:24:22.327: BGP: 10.10.10.1 passive open

    *Mar  1 00:24:22.331: BGP: 10.10.10.1 went from Active to Idle

    *Mar  1 00:24:22.331: BGP: 10.10.10.1 went from Idle to Connect

    *Mar  1 00:24:22.399: BGP: 10.10.10.1 rcv message type 1, length (excl. header) 26

    *Mar  1 00:24:22.403: BGP: 10.10.10.1 rcv OPEN, version 4

    *Mar  1 00:24:22.403: BGP: 10.10.10.1 went from Connect to OpenSent

    *Mar  1 00:24:22.403: BGP: 10.10.10.1 sending OPEN, version 4, my as: 1

    *Mar  1 00:24:22.403: BGP: 10.10.10.1 rcv OPEN w/ OPTION parameter len: 16

    *Mar  1 00:24:22.403: BGP: 10.10.10.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 6

    *Mar  1 00:24:22.403: BGP: 10.10.10.1 OPEN has CAPABILITY code: 1, length 4

    *Mar  1 00:24:22.403: BGP: 10.10.10.1 OPEN has MP_EXT CAP for afi/safi: 1/1

    *Mar  1 00:24:22.407: BGP: 10.10.10.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2

    *Mar  1 00:24:22.407: BGP: 10.10.10.1 OPEN has CAPABILITY code: 128, length 0

    *Mar  1 00:24:22.407: BGP: 1

    R2#0.10.10.1 OPEN has ROUTE-REFRESH capability(old) for all address-families

    *Mar  1 00:24:22.407: BGP: 10.10.10.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2

    *Mar  1 00:24:22.407: BGP: 10.10.10.1 OPEN has CAPABILITY code: 2, length 0

    *Mar  1 00:24:22.407: BGP: 10.10.10.1 OPEN has ROUTE-REFRESH capability(new) for all address-families

    *Mar  1 00:24:22.407: BGP: 10.10.10.1 went from OpenSent to OpenConfirm

    *Mar  1 00:24:22.411: BGP: 10.10.10.1 send message type 1, length (incl. header) 45

    *Mar  1 00:24:22.639: BGP: 10.10.10.1 went from OpenConfirm to Established

    *Mar  1 00:24:22.643: %BGP-5-ADJCHANGE: neighbor 10.10.10.1 Up

    R2#

    *Mar  1 00:23:58.251: BGP: 10.10.10.1 remote close, state CLOSEWAIT

    *Mar  1 00:23:58.251: BGP: 10.10.10.1 -reset the session

    *Mar  1 00:23:59.251: BGP: 10.10.10.1 went from Established to Idle

    *Mar  1 00:23:59.251: %BGP-5-ADJCHANGE: neighbor 10.10.10.1 Down Peer closed the session

    *Mar  1 00:23:59.251: BGP: 10.10.10.1 closing

    *Mar  1 00:23:59.251: BGPNSF state: 10.10.10.1 went from nsf_not_active to nsf_not_active

    R2#

    *Mar  1 00:24:19.255: BGP: 10.10.10.1 went from Idle to Active

    *Mar  1 00:24:19.255: BGP: 10.10.10.1 open active, delay 6499ms

    R2#

    *Mar  1 00:24:22.327: BGP: 10.10.10.1 passive open

    *Mar  1 00:24:22.331: BGP: 10.10.10.1 went from Active to Idle

    *Mar  1 00:24:22.331: BGP: 10.10.10.1 went from Idle to Connect

    *Mar  1 00:24:22.399: BGP: 10.10.10.1 rcv message type 1, length (excl. header) 26

    *Mar  1 00:24:22.403: BGP: 10.10.10.1 rcv OPEN, version 4

    *Mar  1 00:24:22.403: BGP: 10.10.10.1 went from Connect to OpenSent

    *Mar  1 00:24:22.403: BGP: 10.10.10.1 sending OPEN, version 4, my as: 1

    *Mar  1 00:24:22.403: BGP: 10.10.10.1 rcv OPEN w/ OPTION parameter len: 16

    *Mar  1 00:24:22.403: BGP: 10.10.10.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 6

    *Mar  1 00:24:22.403: BGP: 10.10.10.1 OPEN has CAPABILITY code: 1, length 4

    *Mar  1 00:24:22.403: BGP: 10.10.10.1 OPEN has MP_EXT CAP for afi/safi: 1/1

    *Mar  1 00:24:22.407: BGP: 10.10.10.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2

    *Mar  1 00:24:22.407: BGP: 10.10.10.1 OPEN has CAPABILITY code: 128, length 0

    *Mar  1 00:24:22.407: BGP: 1

    R2#0.10.10.1 OPEN has ROUTE-REFRESH capability(old) for all address-families

    *Mar  1 00:24:22.407: BGP: 10.10.10.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2

    *Mar  1 00:24:22.407: BGP: 10.10.10.1 OPEN has CAPABILITY code: 2, length 0

    *Mar  1 00:24:22.407: BGP: 10.10.10.1 OPEN has ROUTE-REFRESH capability(new) for all address-families

    *Mar  1 00:24:22.407: BGP: 10.10.10.1 went from OpenSent to OpenConfirm

    *Mar  1 00:24:22.411: BGP: 10.10.10.1 send message type 1, length (incl. header) 45

    *Mar  1 00:24:22.639: BGP: 10.10.10.1 went from OpenConfirm to Established

    *Mar  1 00:24:22.643: %BGP-5-ADJCHANGE: neighbor 10.10.10.1 Up

     

     

    HTH.

  • Currently Being Moderated
    7. Mar 30, 2011 3:41 PM (in response to BIGEVIL)
    Re: BGP NEIGHBOR STATES QUESTION

    Well, there you go.   Thanks for confirming that.  That's a huge help and nice contribution.

  • Scott Morris - CCDE/4xCCIE/2xJNCIE 8,396 posts since
    Oct 7, 2008
    Currently Being Moderated
    8. Mar 30, 2011 4:41 PM (in response to Erick)
    Re: BGP NEIGHBOR STATES QUESTION

    Well, how about that.    It's all about perspective!  

     

    Scott

  • No doubt.

  • BIGEVIL 347 posts since
    Jun 28, 2008
    Currently Being Moderated
    10. Mar 31, 2011 4:02 AM (in response to Erick)
    Re: BGP NEIGHBOR STATES QUESTION

    You guys put the conception forward, i just wanted to see this. Hapyy i did, thanks.

  • layer4down 94 posts since
    Dec 27, 2010
    Currently Being Moderated
    12. May 24, 2011 5:46 AM (in response to Jaris)
    Re: BGP NEIGHBOR STATES QUESTION

    Hey Team,

     

    This one definitely threw me for a loop as well.I did a bit of my own labbing, referencing RFC's 1771 (obselete) and 4271.One thing I believe was throwing most of us off was the use of the terms "active" and "passive". Per RFC 4271, there is an "Active" state (capitalized in Cisco'sdebug) and an "active" TCP connection side (lowercase in Cisco's debug). I see the active side as "open active" and the passive side as "passive open" in Cisco's implementation of this protocol per the debug. Additionally, I expected the BGP States to be an exact sequence on both sides, which we see is clearly not the case, but it appears only to be different up to when the OPEN message is sent from both sides. We see the active side go from "IDLE" to "ACTIVE" to "OPEN-SENT" and the passive side go from "IDLE" to "CONNECT" to "OPEN-SENT".

     

    I decided to lab this up and document it for my studies and future reference. Below are screenshots of my findings. My debugs are almost identicial to those above and can actually be used as a reference to my screenshots. I've included a sequence of events chart, my Wireshark output (referenced within the chart), and a link to the BGP Finite-State Machine on Wikipedia as a visual aid. The only update I'd make to the FSM diagram on Wikipedia is updating the arrows between "IDLE" and "ACTIVE" to be bi-directional. Thank you in advance for pointing out any corrections or inconsistencies so I can improve my notes.

     

    BGP Peering - Sequence of Events Table.jpg

     

    BGP_peering_ebgp_tcp_ip_ethernet.jpg

     

    http://en.wikipedia.org/wiki/File:BGP_FSM.svg

  • GOVARDHANA 2 posts since
    Sep 20, 2013
    Currently Being Moderated
    13. Jan 3, 2014 7:01 AM (in response to Jaris)
    Re: BGP NEIGHBOR STATES QUESTION

    Hi Guys,

     

    As per my observation in GNS3 & from above output. I assume

    The router which try to intiate a BGP neighbor will go in below  state order.

    Idle-connect--open sent-open confirmation-Established

     

     

    the router which receives BGP session message from neighbor will go in below state oder

     

    Idle -active - opensent-openconfirmation-established

     

    you also could see a timedifference in BGP session.

     

    Here R2 is intiated the BGP session i,e why it showing connect state.

     

    R2#

    *Mar  1 00:24:22.327: BGP: 10.10.10.1 passive open

    *Mar  1 00:24:22.331: BGP: 10.10.10.1 went from Active to Idle

    *Mar  1 00:24:22.331: BGP: 10.10.10.1 went from Idle to Connect

    *Mar  1 00:24:22.399: BGP: 10.10.10.1 rcv message type 1, length (excl. header) 26

     

     

    *Mar  1 00:24:31.223: BGP: 10.10.10.2 went from Idle to Active

    *Mar  1 00:24:31.223: BGP: 10.10.10.2 open active, delay 5610ms

     

     

    R1#

    *Mar  1 00:24:36.835: BGP: 10.10.10.2 open active, local address 10.10.10.1

    *Mar  1 00:24:36.911: BGP: 10.10.10.2 went from Active to OpenSent

    *Mar  1 00:24:36.911: BGP: 10.10.10.2 sending OPEN, version 4, my as:

Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)