The BGP Protocol
The Border Gateway Protocol (BGP) is an exterior routing protocol used
for exchanging routing information 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 has more capability, greater flexibility, and less
required bandwidth. BGP uses path attributes to provide more information
about each route, and in particular to 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 distinguish 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 neighbours, 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. This
means that routes received from an external peer are guaranteed to have
the AS number of that peer at the start of the path. In general, routes
received from an internal neighbour will not have the local AS number prepended
to the AS path, and hence will have the same AS path that the route had
when the originating internal neighbour received the route from an external
peer. Routes with no AS numbers in the path may be legitimately received
from internal neighbours. These routes should be considered internal to
the receiver's 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 structure can represent the results
of aggregating dissimilar routes.
External BGP sessions may or may not include a single metric, which
BGP calls the Multi-Exit Discriminator, among 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. Smaller values of the Multi-Exit
Discriminator are preferred. Currently this metric is only used to
break ties between routes with equal preference from the same neighbouring
AS.
Internal BGP sessions carry at least one metric in the path attributes,
which BGP calls the LocalPref. The range of LocalPref is
identical to the range of the MED. For BGP versions 2 and 3, a route is
preferred if its value for LocalPref is smaller. For BGP version
4, a route is preferred if its value for this metric is larger. BGP version
4 internal sessions may optionally include a second metric, the Multi-Exit
Discriminator, carried in from external sessions. 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 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 connection,
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 length zero.
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 and route reflection options. 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 advertisements 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, and using this to look up an immediate
next hop in an IGP's routes. Such groups support distant peers, but need
to be informed of the IGP whose routes they are using to determine immediate
next hops.
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.
Route Reflection
Generally, all border routers in a single AS need to be internal peers
of each other, and in fact all non-border routers frequently need to be
internal peers of all border routers. While this is usually acceptable
in small networks, it may lead to unacceptably large internal peer groups
in large networks. To help address this problem, BGP supports route
reflection for internal peer groups (with BGP version 4 only). When
using route reflection, the rule that a router may not re-advertise routes
from internal peers to other internal peers is relaxed for some routers,
called route reflectors. A typical use of route reflection might
involve a "core" backbone of fully meshed routers ("fully
meshed" means all the routers in the fully meshed group peer directly
with all other routers in the group), some of which act as route reflectors
for routers which are not part of the core group.
Two types of route reflection are supported. By default, all routes
received by the route reflector from a client are sent to all internal
peers (including the client's group but not the client itself). If the
no-client-reflect option is enabled, routes received from a route
reflection client are sent only to internal peers which are not members
of the client's group. In this case, the client's group must itself be
fully meshed. In either case, all routes received from a non-client internal
peer are sent to all route reflection clients.
Typically, a single router will act as the reflector for a set, or cluster,
of clients. However, for redundancy two or more may also be configured
to be reflectors for the same cluster. In this case, a cluster ID
should be selected to identify all reflectors serving the cluster, using
the clusterid keyword. Gratuitous use of multiple redundant reflectors
is not advised, as it can lead to an increase in the memory required to
store routes on the redundant reflectors' peers.
No special configuration is required on the route reflection clients.
From a client's perspective, a route reflector is simply a normal IBGP
peer. Any BGP version 4 speaker should be able to be a reflector client.
(Note however that gated versions 3.5B3 and earlier, and 3.6A1 and earlier
contain a bug which prevent them from acting as route reflection clients.)
Readers are referred to the route reflection specification document
(rfc1966 as of this
writing) for further details.
Communities
The Communities attribute allows the administrator of a Routing Domain
to tag groups of routes with a community tag. The tag consists of 2 octets
of Autonomous System (AS) and 2 octets of Community ID. The Community attribute
is passed from routing domain to routing domain to maintain the grouping
of these routes. A set of routes may have more than one community tag in
its Community attribute.
Communities import and export policy is configured using the aspath-opt
clause (or mod-aspath clause) to the group, import and export
statements.
Please refer to the Communities specification and its accompanying usage
document (rfc1997
and rfc1998 as of
this writing) for further details on BGP Communities.
Multi-Exit Discriminator
The Multi Exit Discriminator, or MED, allows the administrator of a
Routing Domain to choose between various exits from a neighboring AS. This
attribute is used only for decision making in choosing the best route to
the neighboring AS. If all the other factors for a path to a given AS are
equal, the path with the lower MED value takes preference over other paths.
This attribute is not propagated to other neighboring AS's. However,
this attribute may be propagated to other BGP speakers within the same
AS.
The MED attribute, for BGP version 4, is a four-octet unsigned integer.
MED is originated using the metricout option of the export,
group and/or peer statement. It is imported using the med keyword
on the BGP group statement.
Route Selection
BGP selects the best path to an AS from all the known paths and propagates
the selected path to its neighbors. Gated uses the following criteria,
in order, to select the best path. If routes are equal at a given point
in the selection process, then the next criterion is applied to break the
tie.
- Configured Policy - The route with smallest preference, as determined
by the policy defined in gated.conf.
- Local_Pref - The route with the highest BGP local preference. LOCAL_PREF
is used by a BGP speaker to inform other BGP speakers in its own autonomous
system of the originating speaker's degree of preference for an advertised
route. LOCAL_PREF is only meaningful if using the setpref
option on the BGP statement.
- Shortest AS Path - The route with the fewest ASes listed in its AS
Path.
- Origin IGP < EGP < Incomplete - The route with an AS path origin
of IGP is preferred. Next in preference is the route with AS path origin
of EGP. Least preferred is an AS path that is incomplete.
- MED (if not ignored) - The route with the best Multi-Exit Discriminator
is preferred. MEDs are only compared between routes which were received
from the same neighbor AS. (So this test is only applied if the local AS
has two or more connections to a given neighbor AS.)
- Shortest IGP distance - The route whose NEXT_HOP is closer (with respect
to the IGP distance) is preferred.
- Source IGP < EBGP < IBGP - Prefer first the strictly interior
route, then the strictly exterior route, then the exterior route learned
from an interior session.
- Lowest Router ID - The route whose next hop IP address is numerically
lowest.
Local_Pref
Routes propagated by IBGP must include a Local_Pref attribute. By default,
BGP sends the Local_Pref path attribute as 100, and ignores it on receipt.
In effect, this causes rule #2 above to be ignored.
GateD BGP does not use Local_Pref as a route-preference decision maker
unless the setpref option has been set. For Routing- or Internal-type
groups, the setpref option allows gated's global protocol preference
to be exported into Local_Pref and allows Local_Pref to be used for gated's
route selection preference. Note that the setpref option is the
only way for gated to send a route with a given local_pref. The
local_pref is never set directly, but rather as a function of the gated
preference and setpref metrics.
The translation of gated's internal preference to and from Local_Pref
is done as follows. In the table below, metric is the argument to
setpref, e.g., in the statement, "setpref 100",
metric is 100. "Exported preference" is the gated preference
of the exported route. "Imported preference" is the gated preference
assigned to the imported route.
Exported Preference |
Local_Pref |
Imported Preference |
less than metric |
254 |
metric |
metric ... 254 |
254 ... metric |
metric ... 254 |
N/A |
greater than 254 |
metric |
In effect, any gated preference of less than metric is exported
such that it will be re-imported with a preference of exactly metric.
Any preference of metric or above will be exported such that it
will be re-imported with the same preference it had originally.
Local_Pref, as exported to BGP peers, is calculated as
Local_Pref = 254 - (global protocol preference for this route)
+ metric
A value greater than 254 will be reset to 254. Gated will only send
Local_Pref values between 0 and 254.
Note: Non-gated IBGP implementations may send Local_Prefs which are
greater than 254. When operating a mixed network of this type, it is recommended
that all routers restrict themselves to sending Local_Prefs in the range
metric to 254, so that they will be correctly interpreted by all
routers in the network. If gated receives any Local_Pref with a value greater
than 254, it will import it with a gated preference of metric.
Note: All routers in the same network which are running gated and participating
in IBGP should use setpref uniformly. That is, if one router has
setpref set, all should set it, and all should use the same value
of metric. The value for metric should be selected to be
consistent with the import policy in use in the network. For example, if
import policy sets gated preferences ranging from 170 to 200, a setpref
metric of 170 would make sense. It is advisable to set metric high
enough to avoid conflicts between BGP routes and IGP or static routes.
The BGP Statement
bgp yes | no | on | off
[ {
preference preference ;
defaultmetric metric ;
traceoptions trace_options ;
[ clusterid host ; ]
group type
( external peeras autonomous_system
[ ignorefirstashop ]
[ med ] )
| ( internal peeras autonomous_system
[ ignorefirstashop ]
[ lcladdr local_address ]
[ outdelay time ]
[ metricout metric ]
[ reflector-client [ no-client-reflect ] ])
| ( routing peeras autonomous_system proto proto
interface interface_list
[ ignorefirstashop ]
[ lcladdr local_address ]
[ outdelay time ]
[ metricout metric ]
[ reflector-client [ no-client-reflect ] ] )
| ( test peeras autonomous_system )
[ aspath-opt ]
{
allow {
network
network mask mask
network masklen number
all
host host
} ;
peer host
[ metricout metric ]
[ setpref metric ]
[ localas autonomous_system ]
[ ignorefirstashop ]
[ nogendefault ]
[ gateway gateway ]
[ preference preference ]
[ preference2 preference ]
[ lcladdr local_address ]
[ holdtime time ]
[ version number ]
[ passive ]
[ sendbuffer number ]
[ recvbuffer number ]
[ outdelay time ]
[ keep [ all | none ] ]
[ show-warnings ]
[ noaggregatorid ]
[ keepalivesalways ]
[ v3asloopokay ]
[ nov4asloop ]
[ ascount count ]
[ logupdown ]
[ ttl ttl ]
[ traceoptions trace_options ]
;
} ;
} ] ;
The bgp statement enables or disables BGP. By default BGP is
disabled. The default metric for announcing routes via BGP is no metric.
- preference preference
- Sets the global preference for BGP incoming routes. The default preference
is 170. This preference may be overridden by a preference specified on
the group or peer statement or by import policy. However,
Local_Pref is always derived from preference.
- 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
on the neighbor or group statements 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.)
- clusterid host
- Specifies the route reflection cluster
ID for BGP. The cluster ID defaults to be the same as the router
ID. If a router is to be a route reflector, then a single cluster ID
should be selected and configured on all route reflectors in the cluster.
The only constraints on the choice of cluster ID is that (a) IDs of clusters
within an AS must be unique within that AS, and (b) the cluster ID must
not be 0.0.0.0. Choosing the cluster ID to be the router ID of one router
in the cluster will always fulfil these criteria. If there is only one
route reflector in the cluster, the clusterid setting may be ommitted,
as the default will suffice.
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, peer autonomous system and aspath-opt
options. There are four possible group types:
- group type external peeras autonomous_system
[ med ] [ ignorefirstashop ] [ aspath-opt
]
- 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. The
next hop transmitted is computed with respect to the shared interface.
- med
- By default, any metric (Multi_Exit_Disc, or MED) received on a BGP
connection is ignored. If it is desired to use MEDs in routing computations,
the med option must be specified on the group. By default, MEDs
are not sent on external connections. To send MEDs, use the "metric"
option of the export statement or the "metricout" peer/group
parameter
- ignorefirstashop
- Some routers, known as Route Servers, are capable of propagating
routes without appending their own AS to the AS Path. By default, GateD
will drop such routes. Specifying "ignorefirstashop" on either
the group statement or peer clause disables this feature. This option should
only be used if it is positively known that the peer is a route server
and not a normal router.
- aspath-opt
- Originate the specified AS path attributes. If the attributes are already
present they may be augmented (as with communities) or possibly replaced
(other attributes which may be supported in the future).
- group type routing peeras autonomous_system
proto proto interface interface_list
- [ reflector-client [ no-client-reflect ] ] [ ignorefirstashop]
- [ lcladdr local_address ] [ outdelay time ] [ metricout
metric ] [ aspath-opt ]
- 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, and computes immediate
next hops for these routes by using the BGP next hop which arrived with
the route as a forwarding address to be resolved via an internal protocol's
routing information. In essence, internal BGP is used to carry AS external
routes, while the IGP is expected to only carry AS internal 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 optionally provide a list of interfaces whose
routes are carried via the IGP for which third-party next hops may be used
instead.
- lcladdr, outdelay, and metricout must be set in
the group statement, not on a per-peer basis, for the group types Internal
and Routing. If these options are set on the peer statement, they must
equal the values set on the corresponding group statement.
- The reflector-client option specifies that gated will act as
a route reflector for this group. All routes
received from any group member will be sent to all other internal neighbors,
and all routes received from any other internal neighbors will be sent
to the reflector clients. Since the route reflector forwards routes in
this way, the reflector-client group need not be fully meshed. If the no-client-reflect
option is specified, routes received from reflector clients will only be
sent to internal neighbors which are not in the same group as the
sending reflector client. In this case the reflector-client group should
be fully meshed. In all cases, routes received from normal internal peers
will be sent to all reflector clients. Note that it is necessary to export
routes from the local AS into the local AS when acting as a route
reflector. (For example, suppose that the local AS number is 2. An export
statement like the folowing would suffice to make reflection work right:
- export proto bgp as 2 {
- proto bgp as 2 {all;}; # for reflection
- # other exports
- };
- If the cluster ID is changed and gated is
reconfigured with a SIGHUP, all BGP sessions with reflector clients will
be dropped and restarted.
- group type internal peeras autonomous_system
[ reflector-client [ no-client-reflect ] ]
- [ignorefirstashop ] [ lcladdr local_address ]
[ outdelay time ] [ metricout metric ]
- [ aspath-opt ]
- 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.
- The lcladdr, outdelay, metricout, reflector-client and
no-client-reflect options are described under the routing
group description.
- 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,
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-advertiseable
routes are sent back to the test peer. Metrics from EGP- and BGP-derived
routes are forwarded in the advertisement; otherwise, no metric is included.
Group parameters
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 on the group clause to provide defaults for the whole
group (which may be overridden for individual peers).
Specifying 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 statement. Both are described here:
- allow
- The allow clause allows peer connections from any addresses
in the specified range of network and mask pairs. All parameters for these
peers must be configured on 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 the section on Route Filtering.
- peer host
- A peer clause configures an individual peer. Each peer inherits
all parameters specified on a group as defaults. Many 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 it and set up a peer relationship.
Peer parameters
The BGP peer subclause allows the following parameters, which
can also be specified on the group clause. All are optional.
- metricout metric
- If specified, this metric may be used on all routes sent to the specified
peer(s). The metric hierarchy is as follows, starting from the most preferred:
1)The metric specified by export policy. 2) Peer-level metricout. 3) Group-level
metricout 4) Default metric. For group types Internal and Routing, set
this option on the group clause instead of on the peer clause.
- setpref metric
- Allows BGP's LOCAL_PREF attribute to be used to set the gated
preference on reception, and allows the gated preference to set the LOCAL_PREF
on transmission. The setpref metric works as a lower limit, below which
the imported LOCAL_PREF may not set the gated preference.
(For full details see the discussion of LOCAL_PREF
above.)
- localas autonomous_system
- Identifies the autonomous system which 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 only generated when
the gendefault option is enabled.
- ignorefirstashop
- Disable dropping of routes from peers which do not insert their own
AS number into the AS Path. This option should only be used if it is positively
known that the peer is a route server and not a normal router.
- 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 peer,
over others. This preference may be explicitly overridden by import policy.
- preference2 preference
- In the case of a preference tie, the second preference, preference2
may be used to break the tie. The default value is 0.
- 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 which 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 peers, 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. For group types Internal
and Routing, set this option on the group clause. For group type Routing,
it is advisable to set the lcladdr to a non-physical interface,
such as a loopback interface.
- holdtime time
- Specifies the BGP holdtime value to use when negotiating the connection
with this peer, in seconds. 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 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 version are 2,
3 and 4.
- passive
- If this option is used, GateD will never try to open a BGP connection
with this peer (or group). Instead, it will wait for the peer to initiate
a connection. This option was introduced to handle a problem in BGP3 and
earlier, where two peers might both attempt to initiate a connection at
the same time. This problem is fixed in the BGP4 protocol, so "passive
is not needed with BGP4 sessions. Note that if it is applied to both sides
of a peering session, "passive" will prevent the session from
ever being established. For this reason, and because it is generally not
needed, the use of "passive" is discouraged.
- sendbuffer buffer_size
- recvbuffer buffer_size
- 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.
- outdelay time
- Used to dampen route fluctuations. Outdelay is the amount
of time a route must be present in the gated routing database before it
is exported to BGP. The default value for each is 0, meaning that these
features are disabled. For group types Internal and Routing, set this option
on the group clause.
- keep all
- Used to retain routes learned from a peer even if the routes' AS paths
contain one of our exported AS numbers.
- show-warnings
- Causes GateD to issue warning messages when receiving questionable
BGP updates such as duplicate routes and/or deletions of non-existing routes.
Normally these events are silently ignored.
- noaggregatorid
- Causes GateD to specify the routerid in the aggregator attribute as
zero (instead of its routerid) in order to prevent different routers in
an AS from creating aggregate routes with different AS paths.
- keepalivesalways
- Causes gated to always send keepalives, even when an update could have
correctly substituted for one. This allows interoperability with routers
that do not completely obey the protocol specifications on this point.
- v3asloopokay
- By default gated will not advertise routes whose AS path is looped
(i.e. with an AS appearing more than once in the path) to version 3 external
peers. Setting this flag removes this constraint. Ignored when set on internal
groups or peers.
- nov4asloop
- Prevents routes with looped AS paths from being advertised to version
4 external peers. This can be useful to avoid advertising such routes to
peer which would incorrectly forward the routes on to version 3 neighbours.
- ascount count
- How many times we will insert our own AS number when we send the AS
path to an external neighbor. Default is 1. Higher values are typically
used to bias upstream neighbors' route selection. (All things being equal
most routers will prefer to use routes with shorter AS Paths. Using ascount,
the AS Path we send can be artificially lengthened.) Note that ascount
supersedes the nov4asloop option -- regardless of whether nov4asloop is
set, we will still send multiple copies of our own AS if the ascount option
is set to something greater than one. Also, note that if the value of ascount
is changed and gated is reconfigured, routes will not be sent to
reflect the new setting. If this is desired, it will be necessary to restart
the peer session (by commenting out the peer or group, reconfiguring, and
then uncommenting and reconfiguring again, or by restarting gated).
- logupdown
- Causes a message to be logged via the syslog mechanism whenever a BGP
peer enters or leaves the ESTABLISHED state.
- ttl ttl
- By default, GateD sets the IP TTL for local peers to one and
the TTL for non-local peers to 255. This option mainly is provided when
attempting to communicate with improperly functioning routers that ignore
packets sent with a TTL of one. Not all kernels allow the TTL to be specified
for TCP connections.
- traceoptions trace_options
- Specifies the tracing options for this BGP neighbor. By default these
are inherited from group or BGP global trace options. (See Trace
Statements and the BGP specific tracing options below.)
Tracing options
Note that the state option works with BGP, but does not provide
true state transition information.
Packet tracing options (which may be modified with detail,
send, and recv):
- packets
- All BGP packets
- open
- BGP OPEN packets which are used to establish a peer relationship.
- update
- BGP UPDATE packets which are used to pass network reachability
information.
- keepalive
- BGP KEEPALIVE packets which are used to verify peer reachability.
- all
- Additional useful information, including
additions/changes/deletions to the gated routing table.
Limitations
This section eventually will go into a troubleshooting guide.
- If an interface goes down and comes back up and there is policy associated
with that interface, gated must be restarted since the interface policy
is not recovered.
Last updated 1996/08/5 11:35:30.
gated@gated.cornell.edu