thanks Chris, it was indeed very helpful. I read about the connect collision, the router with higher id drops the session on which it is passive, and the router with lower id drops the session on which it is active, that results into the client sourcing the session toward server on 179, and client here using a random port.
i tried packet capturing, and found that after configuring ebgp-multihop on one of the router, it sends packets with ttl value=2 and receives with a ttl value of 255. any idea how it works on ttl-security hop, and disable-connected-check, and all the game here is 'i guess so' about ttl. for all 3 commands. On Sat, Jun 25, 2011 at 11:20 PM, Chris Marget <[email protected]> wrote: > 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 > -- thanks gaurav http://routing0sand1s.blogspot.com/ _______________________________________________ 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
