Understanding BGP Building Blocks - BGP Design and Implementation - page 25

This step is skipped if any of the following are true:
•

The bgp bestpath compare-routerid command is enabled.

•

The router ID is the same for multiple paths, because the routes were received
from the same router.

•

There is no current best path. An example of losing the current best path occurs
when the neighbor advertising the path goes down.

BGP prefers the route coming from the BGP router with the lowest router ID. The
router ID is the highest IP address on the router, with preference given to loopback
addresses. It can also be set statically using the bgp router-id command. If a path
contains RR attributes, the ORIGINATOR_ID is substituted for the router ID in the
path selection process.

11

If the originator or router ID is the same for multiple paths, BGP prefers the path with
the minimum CLUSTER_LIST length. This is present only in BGP RR environments.
When peered with RRs or clients in other clusters, a client can use the CLUSTER_LIST
length to select the best path. To take advantage of this step, the client must be aware of
the RR-specific BGP attributes.

12

BGP prefers the path coming from the lowest neighbor address. This is the IP address
used in the BGP neighbor configuration, and it corresponds to the remote peer used
in the TCP connection with the local router.

13

BGP Capabilities
BGP, as defined in RFC 1771, can carry only IPv4 reachability information between peers.
To exchange network prefix information other than IPv4, BGP must be extended. This is
accomplished by the capabilities exchange and attribute extension. This section covers only
the capabilities exchange. Various attribute extensions are covered starting in Chapter 10.

As defined in RFC 1771, BGP supports the following four types of messages:
• Open —This type of message is used to set up the initial BGP connections.
• Update —These messages are used between peers to exchange network layer
reachability information.
• Notification —These messages are used to communicate error conditions.
• Keepalive —These messages are exchanged periodically between a pair of peers to
keep the session up.
Within the Open message is a field for Optional Parameters where additional optional
information can be negotiated during session setup. The addition of the Capabilities
Optional Parameter (Parameter Type 2) in RFC 3392 allows a pair of BGP speakers to
negotiate a common set of capabilities.