From: MMoniz (ccie2002@tampabay.rr.com)
Date: Mon May 31 2004 - 15:07:35 GMT-3
Richard, when an initial BGP session is started, by entering the neighbor
commands, both will try to establish a
connection on dest TCP 179. After the first initial exchange, the session
will terminate and the peer with the lowest IP address will try to restart
the peering process. If after a certain amount of time the peering is not
established, the peer with the higher IP address will try to establish a
peer session on dest port 179. When the peering is finally done they will
then exchange tables etc.
It is this initial process that slows the peering relationship. It is my
understanding that this was to circumvent situations such as going through a
firewall, where connections are allowed one way but not the other, thus
peering would still be established.
I had a very good doc on this but am not able to locate it. This is from the
RFC. As you can see this process may
take a little while.
Mike
6.8 Connection collision detection.
If a pair of BGP speakers try simultaneously to establish a TCP
connection to each other, then two parallel connections between this
pair of speakers might well be formed. We refer to this situation as
connection collision. Clearly, one of these connections must be
closed.
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.
Upon receipt of an OPEN message, the local system must examine all of
its connections that are in the OpenConfirm state. A BGP speaker may
also examine connections in an OpenSent state if it knows the BGP
Identifier of the peer by means outside of the protocol. If among
these connections there is a connection to a remote BGP speaker whose
BGP Identifier equals the one in the OPEN message, then the local
system performs the following collision resolution procedure:
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).
Comparing BGP Identifiers is done by treating them as (4-octet
long) unsigned integers.
A connection collision with an existing BGP connection that is in
Established states causes unconditional closing of the newly
created connection. Note that a connection collision cannot be
detected with connections that are in Idle, or Connect, or Active
states.
Closing the BGP connection (that results from the collision
resolution procedure) is accomplished by sending the NOTIFICATION
message with the Error Code Cease.
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Richard Dumoulin
Sent: Monday, May 31, 2004 1:27 PM
To: ccielab@groupstudy.com
Subject: BGP
Hello group,
Something I have never thought about and that I took for granted is why does
BGP take so long to establish a peer connection ? I know it was designed to
be slow but was that the reason ?
Thanks,
--Richard
This archive was generated by hypermail 2.1.4 : Wed Jun 02 2004 - 11:12:19 GMT-3