On Fri, Jun 24, 2011 at 9:52 PM, Christophe Lemaire
<[email protected]> wrote:

> When BGP peer are directly connected (and use directly connected IPs) the 
> router with the lowest IP will always initiated the BGP session.
> When Loopbacks are used, it somehow random. Usually, the last configured or 
> the last router where "clear ip bgp *" has been executed...

Y'know, I'd always thought this was true (even for the
loopback/non-directly connected interfaces), but I haven't seen it
codified anywhere, and my testing shows it not to be the case.

I'd memorized the expected behavior as "endpoint with the lower IP
address will use the lower TCP port number (179)"

But here's what happens in the lab:  Routers are peering on a directly
connected interfaces through an L2 switch with the following
configuration:
-------------------------------------------------------------------------------------
R1#sho run | begin router bgp
router bgp 1
 no synchronization
 bgp log-neighbor-changes
 neighbor 192.168.1.102 remote-as 2
 neighbor 192.168.1.102 fall-over
 no auto-summary
!
-------------------------------------------------------------------------------------
R2#sho run | begin router bgp
router bgp 2
 no synchronization
 bgp log-neighbor-changes
 neighbor 192.168.1.101 remote-as 1
 neighbor 192.168.1.101 fall-over
 no auto-summary
!
-------------------------------------------------------------------------------------
The switch interfaces are shut down, and I 'no shut' them with an
interface range command.  The interfaces come up within 10ms of each
other.

R1#
Jun 25 17:34:33.193: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Ethernet0/0, changed state to up
Jun 25 17:34:33.197: BGP: 192.168.1.102 went from Idle to Active
Jun 25 17:34:33.201: BGP: 192.168.1.102 open active delayed 26266ms (35000ms
max, 28% jitter)


R2#
Jun 25 17:34:33.203: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Ethernet0/0, changed state to up
Jun 25 17:34:33.211: BGP: 192.168.1.101 went from Idle to Active
Jun 25 17:34:33.211: BGP: 192.168.1.101 open active delayed 33533ms (35000ms
max, 28% jitter)

According to the "open active delayed" messages, R1 is going to issue
an active open 7 seconds before R2, making R1 the TCP client in spite
of his lower IP address.  Indeed, that's what happens:
R1#
Jun 25 17:34:59.469: BGP: 192.168.1.102 open active, local address 192.168.1.101
...
Jun 25 17:35:01.493: %BGP-5-ADJCHANGE: neighbor 192.168.1.102 Up


R2#
Jun 25 17:35:01.487: BGP: 192.168.1.101 passive open to 192.168.1.102
...
Jun 25 17:35:01.511: %BGP-5-ADJCHANGE: neighbor 192.168.1.101 Up



The 5-tuple for the session shows it clearly:
R1#show tcp brief
TCB       Local Address           Foreign Address        (state)
61BD36F8  192.168.1.101.34936     192.168.1.102.179      ESTAB

So, what's the deal here?  I've certainly learned that the lower IP
address is supposed to wait, but instead both ends delay their active
open according to the same "35second delay with 28% jitter" policy.

The only reference to higher/lower address/ID and client/server
relationship I've found in RFC 1771 or 4271 relate to resolving the
rare case of a session establishment collision.
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit 
www.ipexpert.com

Are you a CCNP or CCIE and looking for a job? Check out 
www.PlatinumPlacement.com

Reply via email to