Border Gateway Protocol (BGP)
The Border Gateway Protocol (BGP) is an exterior routing
protocol used for
exchanging routing information between autonomous systems.
BGP is used for the
exchange of routing information between multiple transit autonomous systems
as well as between transit and stub autonomous systems.
BGP is related to EGP
but operates with more capability, greater flexibility, and less required
bandwidth.
BGP uses path attributes to provide more information about each
route, and in particular maintains an AS path,
that includes the AS number of
each autonomous system the route has transited, providing information
sufficient to prevent routing loops in an arbitrary topology.
Path attributes also include an origin parameter that indicates
whether the source of the routing information is from within the
autonomous system of the sending gateway (igp), external from the
autonomous system (egp), or from some other source (incomplete).
Path attributes may
be used to distinguish between groups of routes to determine
administrative preferences, allowing greater flexibility in determining route
preference to achieve a variety of administrative ends.
BGP supports two basic types of session between neighbors, internal (sometimes referred to as IBGP) and external. Internal sessions are run between routers in the same autonomous system, while external sessions run between routers in different autonomous systems. When sending routes to an external peer, the local AS number is prepended to the AS path. Hence, routes received from an external peer are guaranteed to have the AS number of that peer at the start of the path. A route received from an internal neighbor will not in general have the local AS number prepended to the AS path, and hence, will in general have the same AS path that the route had when the originating internal neighbor received the route from an external peer. Routes with no AS numbers in the path may be legitimately received from internal neighbors; these indicate that the received route should be considered internal to your own AS.
The BGP implementation supports two versions of the BGP protocol: Versions 2, and 3. BGP Versions 2 and 3 are quite similar in capability and function. They will only propagate classed network routes, and the AS path is a simple array of AS numbers.
External BGP sessions may or may not include a single metric, which BGP calls the Multi-Exit Discriminator (MED), in the path attributes. For BGP Versions 2 and 3 this metric is a 16-bit unsigned integer. Smaller values of the metric are to be preferred. Currently, this metric is used only to break ties between routes with equal preference from the same neighbor AS. Internal BGP sessions carry at least one metric in the path attributes, which BGP calls the LocalPref. The size of the metric is identical to the MED. For BGP Versions 2 and 3, this metric is considered better when its value is smaller.
BGP collapses routes with similar path attributes into a single update for advertisement. Routes that are received in a single update will be readvertised in a single update. This minimizes the churn caused by the loss of a neighbor and maximally compresses the initial advertisement sent during peer establishment. BGP does not read information from the kernel message-by-message but fills the input buffer. It processes all complete messages in the buffer before reading again.
All unreachable messages are collected into a single message and sent prior to reachable routes during a flash update. For these unreachable announcements, the next hop is set to the local address on the connection, no metric is sent, and the path origin is set to incomplete. On external connections, the AS path in unreachable announcements is set to the local AS; on internal connections the AS path is set to zero length.
The BGP implementation expects external peers to be directly attached to a shared subnet and expects those peers to advertise next hops that are host addresses on that subnet (though this constraint can be relaxed by configuration for testing). For internal peers, however, there are two alternatives that may be selected from by specifying the ``internal'' or ``igp'' group type. See ``gated BGP protocol statement'' for a discussion of specifying group types.
When group type ``internal'' is specified, BGP expects all peers in the group to be directly attached to a shared subnet so that, like external peers, the next hops received in BGP advertisements may be used directly for forwarding. When group type ``igp'' is specified, BGP expects routes from the peers in the group not to be used for forwarding at all. Instead, they expect that copies of the BGP routes received will also be received via an IGP (interior gateway protocol such as RIP) and that the BGP routes will only be used to determine the path attributes associated with the IGP routes. Such groups also support distant peers and also need to be informed of the IGP they are running with.
For ``internal'' BGP group types (and for ``test'' groups), where possible, a single outgoing message is built for all group peers based on the common policy. A copy of the message is sent to every peer in the group, with possible adjustments to the next hop field as appropriate to each peer. This minimizes the computational load of running large numbers of peers in these types of groups. BGP allows unconfigured peers to connect if an appropriate group has been configured with an allow clause.
BGP Version 1 is described in RFC 1105, Version 2 in RFC 1163, and Version 3 in RFC 1267. The Version 3 MIB is described in RFC 1269. The two documents, RFC 1164 and RFC 1268, describe the application of Versions 2 and 3 in the internet. A protocol analysis of and experience with BGP Version 3 are available in RFC 1265 and RFC 1266. RFC 1397 talks about advertising a default route in BGP Versions 2 and 3. RFC 1403 describes BGP-OSPF interaction.