HP-UX Reference (11i v1 00/12) - 4 File Formats (vol 8)

ManualsBrandsHP ManualsSoftwareHP-UX Reference Manuals

111

112

113

114

115

116

117

118

119

120

__________________________________________________________________________________________________________________________________________________________________________________________________

STANDARD Printed by: Nora Chuang [nchuang] STANDARD

/build/1111/BRICK/man4/!!!intro.4

________________________________________________________________

___ ___

gated.conf(4) gated.conf(4)

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

speciﬁed.

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 ﬁlls 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

ﬂash 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 conﬁguration 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 ﬁeld as appropriate to each peer. This minimizes the computational

load of running large numbers of peers in these types of groups. BGP allows unconﬁgured peers to connect

if an appropriate group has been conﬁgured with an allow clause.

The BGP Statement

bgp yes | no | on | off

[ {

preference preference ;

defaultmetric metric ;

traceoptions trace_options ;

group type ( external peeras autonomous_system )

|(internal peeras autonomous_system )

|(igp peeras autonomous_system proto proto )

|(routing peeras autonomous_system proto proto

interface interface_list )

HP-UX Release 11i: December 2000 − 26 − Section 4−−97

___