gated BGP protocol statement
bgp yes|no|on|off [ {
[preference preference ;]
[defaultmetric metric ;]
[traceoptions traceoptions ;]
[group type external|internal|igp|test peeras peeras
[metricout metric]
[localas localas]
[nogendefault]
[gateway gateway]
[preference preference]
[lcladdr local_address]
[holdtime time]
[traceoptions traceoptions]
[version version]
[passive]
[importdefault]
[exportdefault]
[sendbuffer bufsize]
[recvbuffer bufsize]
[spoolbuffer bufsize]
[keepall]
{
[allow { dest_mask . . . } ;]
[peer host
[metricout metric]
[localas localas]
[nogendefault]
[gateway gateway]
[preference preference]
[lcladdr local_address]
[holdtime time]
[traceoptions traceoptions]
[version version]
[passive]
[importdefault]
[exportdefault]
[sendbuffer bufsize]
[recvbuffer bufsize]
[spoolbuffer bufsize]
[keepall]
;]
. . .
} ;
. . .]
} ] ;
The bgp statement enables or disables BGP.
By default, BGP is disabled.
The default metric for announcing routes via
BGP is not to send a metric.
preference preference-
Sets the preference for routes learned from BGP. 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 propagated. This metric may be overridden by a
metric specified in the neighbor or group statements or in export
policy.
traceoptions traceoptions-
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
``gated trace statements'').
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 machine's local interfaces. 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-
This is 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 interface. 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-
NOTE:
``igp '' as used in the above line is a keyword.
``igp'' as used in the following paragraph represents one or more unspecific
hosts running an internal routing protocol. In the latter case, ``igp''
stands for internal gateway protocol.)
This is an internal group that runs in association with an interior protocol.
The igp group examines routes that 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 readvertised.
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 that the igp
is exporting, the export policy used is the that of the igp.
There is no need to implement the "don't route from peers
in the same group" constraint since the advertised routes are routes that
igp already exports.
group type test peeras autonomous_system-
This is an extension to an external BGP group that 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, the next hop is the local machine's current next
hop. All routing information advertised by and received from a test peer
is discarded, and all BGP routes that may be advertised are sent back
to the test peer. Metrics from EGP- and BGP-derived
routes are forwarded in the advertisement; otherwise, no metric is included.
The BGP statement has group clauses and peer subclauses. Any number of
peer subclauses may be specified within a group. A group clause usually
defines default parameters for a group of peers; these parameters apply to all
subsidiary peer subclauses. Any parameters from the peer subclause may be
specified in the group clause to provide defaults for the whole group (which
may be overridden for individual peers).
Within a group, BGP peers may be configured in one of two ways.
They may be explicitly configured with a peer statement or implicitly
configured with the allow clause. Both are described following.
allow-
The allow clause allows for peer connections from any addresses in
the specified set of address masks. All parameters for these
peers must be configured in the group clause. The internal peer
structures are created when an incoming open request is received and
destroyed when the connection is broken.
For more detail on specifying
the network/mask pairs, see
``gated route filtering''.
peer host-
A peer clause configures an individual peer. Each peer inherits all
parameters specified on a group as defaults. Those defaults may be
overridden by parameters explicitly specified on the peer subclause.
Within each group clause, individual peers can be specified or a group of
potential peers can be specified using allow. allow
is used to specify a set
of address masks. If gated receives a BGP connection request from any
address in the set specified, it will accept the request
and set up a peer relationship.
The BGP peer subclause allows the following parameters, which can also be
specified in the group clause. All are optional.
metricout metric-
If specified, this metric is used as the primary metric on all routes sent
to the specified peer(s). This metric overrides the default metric, a
metric specified in the group, and any metric specified by export policy.
localas localas-
Identifies the autonomous system that gated is representing to this
group of peers. The default is that which has been set globally in the
autonomoussystem statement.
nogendefault-
Prevents gated from generating a default route when BGP receives a
valid update from its neighbor. The default route is generated
only when the gendefault option is enabled.
gateway gateway-
If a network is not shared with a peer, gateway specifies a
router on an
attached network to be used as the next hop router for routes received
from this neighbor. This parameter is not needed in most cases.
preference preference-
Specifies the preference used for routes learned from these peers. This
can differ from the default BGP preference set in the bgp statement, so
that gated can prefer routes from one peer,
or group of peers, over others.
This preference may be explicitly overridden by import policy.
lcladdr local_address-
Specifies the address to be used on the local end of the TCP
connection with the peer. For external peers, the local address must be on an
interface that is shared with the peer or with the peer's gateway when
the gateway parameter is used. A session with an external peer will
only be opened when an interface with the appropriate local address
(through which the peer or gateway address is directly reachable) is
operating. For other types of peer, a peer session will be maintained
when any interface with the specified local address is operating. In
either case incoming connections will only be recognized as matching a
configured peer if they are addressed to the configured local address.
holdtime time-
Specifies the BGP holdtime value to use when negotiating the
connection with this peer, in seconds. According
to BGP, if gated does
not receive a keepalive, update, or notification message within the
period specified in the Hold Time field of the BGP OPEN message, then
the BGP connection will be closed. The value must be either 0 (no
keepalives will be sent) or at least 3.
version version-
Specifies the version of the BGP protocol to use with this peer. If not
specified, the highest supported version is used first and version
negotiation is attempted. If it is specified, only the specified version
will be offered during negotiation. Currently supported versions are 2 and 3.
passive-
Specifies that active OPENs to this peer should not be attempted.
gated
should wait for the peer to issue an OPEN. By default, all explicitly
configured peers are active; they periodically send OPEN messages
until the peer responds.
sendbuffer bufsize
recvbuffer bufsize-
Control the amount of send and receive buffering asked of the kernel.
The maximum supported is 65535 bytes although many kernels have a
lower limit. By default, gated configures the maximum supported.
These parameters are not needed on normally functioning systems.
keepall-
Used to retain routes learned from a peer even if the routes' AS paths
contain one of the exported AS numbers.
traceoptions traceoptions-
Specifies the tracing options for this BGP neighbor.
By default, these are inherited from group or BGP
global trace options. (See
``gated trace statements'').
Next topic:
gated redirect protocol statement
Previous topic:
gated EGP protocol statement
© 2003 Caldera International, Inc. All rights reserved.
SCO OpenServer Release 5.0.7 -- 11 February 2003