13 Replies Latest reply: Jan 3, 2014 7:01 AM by GOVARDHANA RSS

    BGP NEIGHBOR STATES QUESTION

    Jaris

      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

        • 1. Re: BGP NEIGHBOR STATES QUESTION
          Jaris

          It's assumed that TCP connections will not reach UP in CONNECT state, so I blocked the TCP packets with an ACL, but the state remains in ACTIVE. The router goes into ACTIVE state if there's no response to the OPEN message.

           

          The ACL was configured on router R1.

           

          R1#show ip access-list 100

          Extended IP access list 100

              10 deny tcp any eq bgp any (414 matches)

              15 deny tcp any any eq bgp (91 matches)

              20 permit ip any any (1235 matches)

           

          R1#show tcp brief

          TCB       Local Address           Foreign Address        (state)

          64744200  10.1.1.1.12311          10.1.1.2.179           SYNSENT

           

          Debugging the TCP packets on router R2:

           

          R2#

          *Mar  1 04:11:33.262: tcp0: I LISTEN 10.1.1.1:30689 10.1.1.2:179 seq 3280459458

                  OPTS 4 SYN  WIN 16384

          *Mar  1 04:11:33.278: tcp0: O SYNRCVD 10.1.1.1:30689 10.1.1.2:179 seq 2081678903

                  OPTS 4 ACK 3280459459 SYN  WIN 16384

          R2#

          *Mar  1 04:11:41.286: tcp0: I LISTEN 10.1.1.1:30689 10.1.1.2:179 seq 3280459458

                  OPTS 4 SYN  WIN 16384

          *Mar  1 04:11:41.302: tcp0: O SYNRCVD 10.1.1.1:30689 10.1.1.2:179 seq 832451741

                  OPTS 4 ACK 3280459459 SYN  WIN 16384

          R2#

          *Mar  1 04:12:07.638: tcp0: O CLOSED 10.1.1.1:179 10.1.1.2:33487 seq 3691648816

                  OPTS 4 SYN  WIN 16384

           

          R2#show ip bgp neighbors | inc state

            BGP state = Active

           

          R2#show ip bgp neighbors | inc TCP

            No active TCP connection

           

          So why the state jumps from IDLE to ACTIVE without passing through CONNECT state????

           

          Thanks.

          • 2. Re: BGP NEIGHBOR STATES QUESTION
            Jaris

            Thanks for your answers......I already passed the ROUTE exam the last week!!!

            • 3. Re: BGP NEIGHBOR STATES QUESTION
              Erick

              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.

              • 4. Re: BGP NEIGHBOR STATES QUESTION
                Scott Morris - CCDE/4xCCIE/2xJNCIE

                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

                • 5. Re: BGP NEIGHBOR STATES QUESTION
                  Erick

                  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.

                  • 6. Re: BGP NEIGHBOR STATES QUESTION
                    BIGEVIL

                    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.

                    • 7. Re: BGP NEIGHBOR STATES QUESTION
                      Erick

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

                      • 8. Re: BGP NEIGHBOR STATES QUESTION
                        Scott Morris - CCDE/4xCCIE/2xJNCIE

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

                         

                        Scott

                        • 9. Re: BGP NEIGHBOR STATES QUESTION
                          Erick

                          No doubt.

                          • 10. Re: BGP NEIGHBOR STATES QUESTION
                            BIGEVIL

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

                            • 11. Re: BGP NEIGHBOR STATES QUESTION
                              Jaris

                              Hey guys thanks for everything; I didn't receive any advice about your anwers. By the way thanks. I gave the points to you.

                              • 12. Re: BGP NEIGHBOR STATES QUESTION
                                layer4down

                                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

                                • 13. Re: BGP NEIGHBOR STATES QUESTION
                                  GOVARDHANA

                                  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: