HP-UX Reference (11i v1 05/09) - 4 File Formats (vol 8)

g
gated.conf(4) gated.conf(4)
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 ses-
sions 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 general have the
same AS path that the route had when the originating internal neighbor received the route from an exter-
nal 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 Discrimina-
tor, in the path attributes. For BGP versions 2 and 3 this metric is a 16-bit unsigned integer, for BGP ver-
sion 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 neigh-
bor 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 neigh-
bor will be minimized and the initial advertisement sent during peer establishment will be maximally
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 multiple 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 connec-
tion, 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 support dis-
tant peers, but need to be informed of the IGP whose routes they are using to determine immediate 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 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.
The BGP Statement
bgp yes | no | on | off
[ {
preference preference ;
defaultmetric metric ;
traceoptions trace_options ;
HP-UX 11i Version 1: September 2005 − 26 − Hewlett-Packard Company Section 4−−95