From: Howard C. Berkowitz (hcb@gettcomm.com)
Date: Mon May 31 2004 - 19:08:40 GMT-3
At 2:07 PM -0400 5/31/04, MMoniz wrote:
>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
Mike is quite correct, but it's worth noting that there are
additional factors that may make the initialization even longer.
Capabilities advertisement may cause additional attempts for the two
speakers to agree on the set of capabilities.
We are seeing more and more mechanisms that might come into effect
before the route exchange, or occasionally after initialization.
Exchanging rules for outbound route filtering is one good example.
Obviously, the size of the routing tables to be exchanged will also
vary tremendously. As something of an aside, when you get into
multivendor BGP, you can get strange and wonderful variations in the
table transfer time, depending on two factors: how the sender orders
(and packs) NLRI, and the data structure method the receiver uses to
store the updates.
This archive was generated by hypermail 2.1.4 : Wed Jun 02 2004 - 11:12:19 GMT-3