From: sabrina pittarel (sabri_esame@yahoo.com)
Date: Sat Sep 02 2006 - 15:26:32 ART
Mohamed,
I didn't came across your same literature, and if I did I forgot, but this is what I'm seeing in my box:
.4 .5
R4 -------------------- R5
AS400 AS500
R4#sh tcp bri
TCB Local Address Foreign Address (state)
03B64780 136.1.145.4.11177 136.1.145.5.179 ESTAB
R4#
The BGP session has been established by R4 to R5 BGP port.
R4
-----
*Sep 2 17:54:36.700: TCB03B64780 created
*Sep 2 17:54:36.700: TCB03B64780 setting property TCP_WINDOW_SIZE (0) 3B62E90
*Sep 2 17:54:36.700: TCB03B64780 setting property TCP_MD5KEY (5) 0
*Sep 2 17:54:36.700: TCB03B64780 setting property TCP_TOS (11) 3B62E8F
*Sep 2 17:54:36.700: TCP: Random local port generated 11177
*Sep 2 17:54:36.700: TCB03B64780 bound to 136.1.145.4.11177
*Sep 2 17:54:36.700: TCP: sending SYN, seq 3739483899, ack 0
*Sep 2 17:54:36.700: TCP0: Connection to 136.1.145.5:179, advertising MSS 1460
*Sep 2 17:54:36.700: TCP0: state was CLOSED -> SYNSENT [11177 -> 136.1.145.5(179)]
*Sep 2 17:54:36.704: TCP0: state was SYNSENT -> ESTAB [11177 -> 136.1.145.5(179)]
*Sep 2 17:54:36.704: TCP: tcb 3B64780 connection to 136.1.145.5:179, peer MSS 1460, MSS is 1460
*Sep 2 17:54:36.704: TCB03B64780 connected to 136.1.145.5.179
R4 was ready to send a SYN and it did.
R5
----
*Sep 2 17:54:37.244: TCB039BA8B8 created
*Sep 2 17:54:37.244: TCP0: state was LISTEN -> SYNRCVD [179 -> 136.1.145.4(11177)]
*Sep 2 17:54:37.244: TCP: tcb 39BA8B8 connection to 136.1.145.4:11177, peer MSS 1460, MSS is 516
*Sep 2 17:54:37.244: TCP: sending SYN, seq 4129485682, ack 3739483900
*Sep 2 17:54:37.244: TCP0: Connection to 136.1.145.4:11177, advertising MSS 1460
*Sep 2 17:54:37.244: TCP0: state was SYNRCVD -> ESTAB [179 -> 136.1.145.4(11177)]
*Sep 2 17:54:37.252: TCB03B716B0 callback, connection queue = 1
*Sep 2 17:54:37.252: TCB03B716B0 accepting 039BA8B8 from 136.1.145.4.11177
R5(config-if)#
R5 received the SYN and replied with a SYN ACK.
I have also seen exactly the opposite behavior.
I have never seen any RST or FIN message sent that would have made me think of BGP trying to reset the connection because of a failed check on the router id.
Sabrina
----- Original Message ----
From: Mohamed Saeed <mohamed_saeed2@rayacorp.com>
To: ccielab@groupstudy.com
Sent: Saturday, September 2, 2006 10:25:23 AM
Subject: RE: BGP Neighborship Establishment
Hi Sabrina,
I got your point, but could we say that the peers may start by deciding
who has higher ID and then leave it initiate the session.
I have faced this concept on one of the popular CCIE preparation books.
Shows and debugs in the book where confirming this. However, my tests
showed that there is no relation,
Regards
Mohamed ..
-----Original Message-----
From: sabrina pittarel [mailto:sabri_esame@yahoo.com]
Sent: Saturday, September 02, 2006 7:10 PM
To: Mohamed Saeed; ccielab@groupstudy.com
Cc: Mohamed Saeed
Subject: Re: BGP Neighborship Establishment
Mohamed,
how a peer can know, before initiating the session, that he has a
router ID lower than the remote side and hence it has to wait for the
other side to start?
Sabrina
----- Original Message ----
From: Mohamed Saeed <mohamed_saeed2@rayacorp.com>
To: ccielab@groupstudy.com
Cc: Mohamed Saeed <mohamed_saeed2@rayacorp.com>
Sent: Saturday, September 2, 2006 4:50:05 AM
Subject: BGP Neighborship Establishment
Hi All,
Regarding the BGP peering establishment, it is supposed that the peer
with higher ID would initiate the session by sending TCP Sync (client)
while the peer with lower ID will respond (server). I was testing this
and I discovered that it is independent of the bgp router id.
If R1 with ID 10.0.0.1 has a bgp peering with R2 of ID 10.0.0.2, when I
clear the peering while I am on R1, I notice that R1 initiates the
session and R2 responds (using "debug ip packet detail" while clearing
the session). If, however, I cleared the peering while I am on R2, I
notice that R2 initiates the session !!
Has somebody else encountered this ?
Regards
Mohamed ...
This archive was generated by hypermail 2.1.4 : Sun Oct 01 2006 - 16:55:39 ART