From: Victor Cappuccio (cvictor@protokolgroup.com)
Date: Sat Sep 02 2006 - 17:38:37 ART
Hi Guys,
Please sorry to put my nose here, But the Router ID has something to do
with the Neighbor Establishment, reading the RFC 1771 for this particular
case could help you in knowing why the lower Id could be considered the
server or the higher router ID is considered the client
Important parts for the discussion are:
BGP Identifier:
This 4-octet unsigned integer indicates the BGP Identifier of
the sender. A given BGP speaker sets the value of its BGP
Identifier to an IP address assigned to that BGP speaker. The
value of the BGP Identifier is determined on startup and is the
same for every local interface and every BGP peer.
6.8 Connection collision detection.
Based on the value of the BGP Identifier a convention is established
for detecting which BGP connection is to be preserved when a
collision does occur. The convention is to compare the BGP
Identifiers of the peers involved in the collision and to retain only
the connection initiated by the BGP speaker with the higher-valued
BGP Identifier.
.
1. The BGP Identifier of the local system is compared to the BGP
Identifier of the remote system (as specified in the OPEN
message).
2. If the value of the local BGP Identifier is less than the
remote one, the local system closes BGP connection that already
exists (the one that is already in the OpenConfirm state), and
accepts BGP connection initiated by the remote system.
3. Otherwise, the local system closes newly created BGP connection
(the one associated with the newly received OPEN message), and
continues to use the existing one (the one that is already in the
OpenConfirm state).
R3#show ip bgp neigh 150.1.4.4 | in port
Local host: 150.1.3.3, Local port: 179
Foreign host: 150.1.4.4, Foreign port: 14235
R4#show ip bgp neigh 150.1.3.3 | in port
Local host: 150.1.4.4, Local port: 14235
Foreign host: 150.1.3.3, Foreign port: 179
From point 2 of 6.8 at the RFC and by the output above I can assume this
BGP Server Listen at port 179, then it compares my Rid (local) with the
Rid received in the open Message
Then this simple decision is followed
My RID is lower than the RID Received?
Yes .- Then Im the server
A nice Explanation about the 3way handshake could be found at
http://support.microsoft.com/default.aspx?scid=kb;EN-US;172983
And this could be used for understanding the debug ip pa detail, if you like
to go to the packet level.
*BTW* this is well explained at the Advance Technology CCIE R&S of
Internetwork Experts
HTH
Victor.-
-----Mensaje original-----
De: nobody@groupstudy.com [mailto:nobody@groupstudy.com] En nombre de
Mohamed Saeed
Enviado el: Sabado, 02 de Septiembre de 2006 02:44 p.m.
Para: ccielab@groupstudy.com
Asunto: RE: BGP Neighborship Establishment
Thanks Sabrina for helping me with this, I think I will bypass this
section in that literature as my tests and so yours show that the router
ID has nothing to do with the session initiation,
Regards
Mohamed ...
-----Original Message-----
From: sabrina pittarel [mailto:sabri_esame@yahoo.com]
Sent: Saturday, September 02, 2006 8:27 PM
To: Mohamed Saeed; ccielab@groupstudy.com
Subject: Re: BGP Neighborship Establishment
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>
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>
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