6.2.3 Inter-Domain Routing Protocols
2. The Border Gateway Protocol (BGP)
The Border Gateway Protocol (BGP) is an exterior routing or Inter-Domain 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 neighbors, 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 neighbor 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 neighbor received the route from an external peer. Routes with no AS
numbers in the path may be legitimately received from internal neighbors. 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 neighboring 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-optclause (or
mod-aspath clause) to the group, import and export statements.
Please refer to the Communities specification and its accompanying usage document (rfc1997and
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.
Weighted Route Dampening
The basic idea of weighted route dampening is to treat routes that are being announced and
withdrawn (flapping) at a rapid rate as unreachable. If a route flaps at a low rate it should not be
suppressed at all or suppressed only for a brief period of time. With weighted route dampening,
the suppression of a route or routes occurs in a manner that adapts to the frequency and duration
that a particular route appears to be flapping. The more a route flaps during a period of time, the
longer it will be suppressed. The adaptive characteristics of weighted route dampening are
controlled by a few configurable parameters.
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.
- 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. Local_Pref may be 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. Unless the setpref option has been set,
BGP sends the Local_Pref path attribute as 100.
GateD always uses the received Local_Pref to select between BGP routes which have the same
GateD preference. BGP routes with a larger Local_Pref are preferred.
Setpref
The setpref option allows GateD to set the local_pref to reflect GateD's own internal preference
for the route, as given by the global protocol preference value. The setpref option may be used
with routing or internal type groups. 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 (by
a distant GateD) 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.
For example, suppose GateD is sending routes to an internal group using "setpref 100", and the
routes are subsequently received by another router in the group, also using "setpref 100". The
table below lists some sample route preferences, the local_prefs with which the routes will be
sent, and the preferences with which the routes will be imported:
Preference Before Export |
Local_Pref |
Preference After Import |
170 |
184 = (254-170+100) |
170 |
171 |
183 |
171 |
254 |
100 |
254 |
100 |
254 |
100 |
5 |
254 |
100 |
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.
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 setprefmetric 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 ]
[ nexthopself ]
[ 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
peerstatement 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-optoptions. 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_systemproto proto interface interface_list
- [ reflector-client [ no-client-reflect ] ] [ ignorefirstashop]
- [ lcladdr local_address ] [ outdelay time ] [ metricoutmetric ] [ 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, including "static". 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_listcan 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 following
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 routinggroup 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-advertisable 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 details 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; and 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_PREFabove.)
- 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
- Disables 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. The
gateway parameter may also be used to specify a next hop for peers which are on
shared networks. This might be used to ensure that third-party next hops are never
accepted from a given peer, by specifying that peer's address as its own gateway. This
parameter is not needed in most cases.
- nexthopself
- Causes the next hop in route advertisements set to this peer or group of peers to be set
to our own router's address, even if it would normally be possible to send a third-party
next hop. Use of this option may cause inefficient routes to be followed, but it may be
needed in some cases to deal with broken bridged interconnect media (in cases where
the routers on the "shared" medium do not really have full connectivity to each other) or
broken political situations.
- 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 peers which would incorrectly
forward the routes on to version 3 neighbors.
- 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
ascountis 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 April 26, 1997
gated@gated.merit.edu