HP-UX Reference (11i v2 03/08) - 4 File Formats (vol 8)

g
gated.conf(4) gated.conf(4)
update
EGP POLL/UPDATE packets which are used to request and receive reachability updates.
The BGP Protocol
The Border Gateway Protocol (BGP) is an exterior routing protocol used for exchanging routing informa-
tion between autonomous systems. BGP is used for 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 maintain an AS path, which
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 may also be used to distin-
guish 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 sessions 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. Routes received from an internal
neighbor will not in general have the local AS number prepended to the AS path, and hence will in gen-
eral 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 three versions of the BGP protocol, versions 2, 3 and 4. 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. BGP 4 will propagate fully general address-and-mask
routes, and the AS path has some structure to represent the results of aggregating dissimilar routes.
External BGP sessions may or may not include a single metric, which BGP calls the Multi-Exit Discrimi-
nator, in the path attributes. For BGP versions 2 and 3 this metric is a 16-bit unsigned integer, for BGP
version 4 it is a 32-bit unsigned integer. In either case smaller values of the metric are to be preferred.
Currently this metric is only used 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 con-
sidered better when its value is smaller, for version 4 it is better when it is larger. BGP version 4 sessions
may optionally carry a second metric on internal sessions, this being an internal version of the Multi-Exit
Discriminator. The use of these metrics is dependent on the type of internal protocol processing which is
specified.
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. The churn caused by the loss of a
neighbor will be minimized and the initial advertisement sent during peer establishment will be maxi-
mally compressed. 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. BGP also does multi-
ple reads to clear all incoming data queued on the socket. This feature may cause other protocols to be
blocked for prolonged intervals by a busy peer connection.
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 con-
nection, 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 which are host addresses on that subnet (though this constraint can be
relaxed by configuration for testing). For groups of internal peers, however, there are several alternatives
which may be selected from by specifying the group type. Type internal groups expect all peers to be
directly attached to a shared subnet so that, like external peers, the next hops received in BGP advertise-
ments may be used directly for forwarding. Type routing groups instead will determine the immediate
next hops for routes by using the next hop received with a route from a peer as a forwarding address.
This forwarding address is used to look up an immediate next hop in routes of the IGP. Such groups sup-
port distant peers, but need to be informed of the IGP whose routes they are using to determine immedi-
ate next hops. Finally, type igp groups expect routes from the group peers to not be used for forwarding
at all. Instead they expect that copies of the BGP routes received will also be received via an IGP, and
Section 4−−102 Hewlett-Packard Company − 26 − HP-UX 11i Version 2: August 2003