cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1725
Views
0
Helpful
1
Replies

BGP FSM Connect/Active

Mahesh Gohil
Level 7
Level 7

Hi Expert,

There is some confusion for BGP connect and active state.

RFC-4271 says

Connect State: In this state, BGP FSM is waiting for the TCP connection to be completed.

Regards

Mahesh

Active State: In this state, BGP FSM is trying to acquire a peer by listening

for, and accepting, a TCP connection.

I configured BGP between two nodes on p2p ip and captured debug output.

R1(10.10.10.1)-----------(10.10.10.2)R2.

R1 initiated bgp session with remote port as 179 so R1 is active and R2 as passive.

As we can see in below debug R1 moves to Active state and R2 moves to connect state. I just want to know based on what event R2 decided to move to connect state ? Is it because of some TCP packet with remote port:179 from peer end which forced R2 to move to connect state or is there any other parameter which forced R2 to move to connect state.


R1 Debug:

*Mar  8 09:37:33.367: BGP: nbr global 10.10.10.2 Open active delayed 1024ms (0ms max, 60% jitter)
*Mar  8 09:37:33.987: BGP: 10.10.10.2 active went from Idle to Active
*Mar  8 09:37:33.991: BGP: 10.10.10.2 open active, local address 10.10.10.1
*Mar  8 09:37:34.123: BGP: ses global 10.10.10.2 (0) act read request no-op
*Mar  8 09:37:34.131: BGP: ses global 10.10.10.2 (0) act Adding topology IPv4 Unicast:base
*Mar  8 09:37:34.131: BGP: ses global 10.10.10.2 (0) act Send OPEN
*Mar  8 09:37:34.131: BGP: 10.10.10.2 active went from Active to OpenSent

R2 Debug:

*Mar  8 09:37:33.519: BGP: nbr global 10.10.10.1 Open active delayed 7168ms (35000ms max, 60% jitter)
*Mar  8 09:37:34.147: BGP: 10.10.10.1 passive open to 10.10.10.2
*Mar  8 09:37:34.147: BGP: 10.10.10.1 passive went from Idle to Connect
*Mar  8 09:37:34.147: BGP: ses global 10.10.10.1 (0) pas Setting open delay timer to 60 seconds.
*Mar  8 09:37:34.155: BGP: ses global 10.10.10.1 (0) pas read request no-op
*Mar  8 09:37:34.159: BGP: ses global 10.10.10.1 (0) pas read request no-op
*Mar  8 09:37:34.163: BGP: 10.10.10.1 passive rcv message type 1, length (excl. header) 31
*Mar  8 09:37:34.163: BGP: ses global 10.10.10.1 (0) pas Receive OPEN
*Mar  8 09:37:34.163: BGP: 10.10.10.1 passive rcv OPEN, version 4, holdtime 180 seconds
*Mar  8 09:37:34.167: BGP: 10.10.10.1 passive rcv OPEN w/ OPTION parameter len: 21
*Mar  8 09:37:34.167: BGP: 10.10.10.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Mar  8 09:37:34.167: BGP: 10.10.10.1 passive OPEN has CAPABILITY code: 1, length 4
*Mar  8 09:37:34.171: BGP: 10.10.10.1 passive OPEN has MP_EXT CAP for afi/safi: 1/1
*Mar  8 09:37:34.171: BGP: 10.10.10.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar  8 09:37:34.171: BGP: 10.10.10.1 passive OPEN has CAPABILITY code: 128, length 0
*Mar  8 09:37:34.171: BGP: 10.10.10.1 passive OPEN has ROUTE-REFRESH capability(old) for all address-families
*Mar  8 09:37:34.175: BGP: 10.10.10.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar  8 09:37:34.175: BGP: 10.10.10.1 passive OPEN has CAPABILITY code: 2, length 0
*Mar  8 09:37:34.175: BGP: 10.10.10.1 passive OPEN has ROUTE-REFRESH capability(new) for all address-families
*Mar  8 09:37:34.175: BGP: 10.10.10.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 3
*Mar  8 09:37:34.179: BGP: 10.10.10.1 passive OPEN has CAPABILITY code: 131, length 1
*Mar  8 09:37:34.179: BGP: 10.10.10.1 passive OPEN has MULTISESSION capability, without grouping
*Mar  8 09:37:34.179: BGP: nbr global 10.10.10.1 neighbor does not have IPv4 MDT topology activated
*Mar  8 09:37:34.179: BGP: ses global 10.10.10.1 (0) pas mdt prepare old peer: BGP_MDT_STYLE_NONE or Internal Problem
*Mar  8 09:37:34.183: BGP: 10.10.10.1 passive rcvd OPEN w/ remote AS 9498
*Mar  8 09:37:34.183: BGP: ses global 10.10.10.1 (0) pas Adding topology IPv4 Unicast:base
*Mar  8 09:37:34.183: BGP: ses global 10.10.10.1 (0) pas Send OPEN
*Mar  8 09:37:34.187: BGP: 10.10.10.1 passive went from Connect to OpenSent

Also if anyone has idea of below two lines: How is this time decided ? both end is having different timer.

R1: *Mar  8 09:37:33.367: BGP: nbr global 10.10.10.2 Open active delayed 1024ms (0ms max, 60% jitter)

R2: *Mar  8 09:37:33.519: BGP: nbr global 10.10.10.1 Open active delayed 7168ms (35000ms max, 60% jitter)

1 Accepted Solution

Accepted Solutions

Peter Paluch
Cisco Employee
Cisco Employee

Hi Mahesh,

As we can  see in below debug R1 moves to Active state and R2 moves to connect  state. I just want to know based on what event R2 decided to move to  connect state ?

According to your debugs, R1 opened the TCP session towards R2. That would be the event that moved R2 to the Connect state. I should stress that according to my experiments, Cisco's BGP implementation does not seem to be 100% aligned to the RFC 4271 with the usage and transitions between BGP states.

How is this time decided ? both end is having different timer.

R1: *Mar  8 09:37:33.367: BGP: nbr global 10.10.10.2 Open active delayed 1024ms (0ms max, 60% jitter)

R2: *Mar  8 09:37:33.519: BGP: nbr global 10.10.10.1 Open active delayed 7168ms (35000ms max, 60% jitter)

I would believe that this is a random timer. But there seems to be a certain logic to it - when I used the neighbor transport connection-mode active, the timer started at 850 ms and went gradually to 1000ms, 2000ms, 4000ms...

Best regards,

Peter

View solution in original post

1 Reply 1

Peter Paluch
Cisco Employee
Cisco Employee

Hi Mahesh,

As we can  see in below debug R1 moves to Active state and R2 moves to connect  state. I just want to know based on what event R2 decided to move to  connect state ?

According to your debugs, R1 opened the TCP session towards R2. That would be the event that moved R2 to the Connect state. I should stress that according to my experiments, Cisco's BGP implementation does not seem to be 100% aligned to the RFC 4271 with the usage and transitions between BGP states.

How is this time decided ? both end is having different timer.

R1: *Mar  8 09:37:33.367: BGP: nbr global 10.10.10.2 Open active delayed 1024ms (0ms max, 60% jitter)

R2: *Mar  8 09:37:33.519: BGP: nbr global 10.10.10.1 Open active delayed 7168ms (35000ms max, 60% jitter)

I would believe that this is a random timer. But there seems to be a certain logic to it - when I used the neighbor transport connection-mode active, the timer started at 850 ms and went gradually to 1000ms, 2000ms, 4000ms...

Best regards,

Peter

Review Cisco Networking for a $25 gift card