gated.conf.4 (2010 09)

g
gated.conf(4) gated.conf(4)
preference preference
Sets the preference for routes learned from RIP. The default preference is 170. This preference
may be overridden by a preference specified on the group or peer statements or by import
policy.
defaultmetric metric
Defines the metric used when advertising routes via BGP. If not specified, no metric is pro-
pagated. This metric may be overridden by a metric specified on the neighbor or group state-
ments or in export policy.
traceoptions trace_options
Specifies the tracing options for BGP. By default these are inherited from the global trace
options. These values may be overridden on a group or neighbor basis. (See Trace Statements
and the BGP specific tracing options below.)
Groups
BGP peers are grouped by type and the autonomous system of the peers. Any number of groups may be
specified, but each must have a unique combination of type and peer autonomous system. There are four
possible group types:
group type external peeras autonomous_system
In the classic external BGP group, full policy checking is applied to all incoming and outgoing
advertisements. The external neighbors must be directly reachable through one of the local
interfaces of the machine . By default no metric is included in external advertisements, and
the next hop is computed with respect to the shared interface.
group type internal peeras autonomous_system
An internal group operating where there is no IP-level IGP, for example an SMDS network or
MILNET. All neighbors in this group are required to be directly reachable via a single inter-
face. All next hop information is computed with respect to this interface. Import and export
policy may be applied to group advertisements. Routes received from external BGP or EGP
neighbors are by default readvertised with the received metric.
group type igp peeras autonomous_system proto proto
An internal group that runs in association with an interior protocol. The IGP group examines
routes which the IGP is exporting and sends an advertisement only if the path attributes could
not be entirely represented in the IGP tag mechanism. Only the AS path, path origin, and
transitive optional attributes are sent with routes. No metric is sent, and the next hop is set to
the local address used by the connection. Received internal BGP routes are not used or read-
vertised. Instead, the AS path information is attached to the corresponding IGP route and the
latter is used for readvertisement. Since internal IGP peers are sent only a subset of the routes
which the IGP is exporting, the export policy of the IGP is used. There is no need to implement
the "don’t routes from peers in the same group" constraint since the advertised routes are
routes that IGP already exports.
group type routing peeras autonomous_system proto proto interface interface_list
An internal group which uses the routes of an interior protocol to resolve forwarding
addresses. A type routing group propagates external routes between routers which are not
directly connected. A type routing group computes immediate next hops for these routes by
using the BGP next hop which arrived with the route as a forwarding address. The forwarding
address is to be resolved via the routing information of an internal protocol. In essence, inter-
nal BGP is used to carry AS external routes, while the IGP is expected to only carry AS inter-
nal routes, and the latter is used to find immediate next hops for the former.
The proto names the interior protocol to be used to resolve BGP route next hops, and may be
the name of any IGP in the configuration. By default the next hop in BGP routes advertised to
type routing peers will be set to the local address on the BGP connection to those peers, as it is
assumed a route to this address will be propagated via the IGP. The interface_list can option-
ally provide a list interfaces whose routes are carried via the IGP for which third party next
hops may be used instead.
group type test peeras autonomous_system
An extension to external BGP which implements a fixed policy using test peers. Fixed policy
and special case code make test peers relatively inexpensive to maintain. Test peers do not
need to be on a directly attached network. If GateD and the peer are on the same (directly
attached) subnet, the advertised next hop is computed with respect to that network. Otherwise
28 Hewlett-Packard Company − 28 − HP-UX 11i Version 3: September 2010