GateD Configuration Guide - BGP

# 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-opt`clause (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.

1. Configured Policy - The route with smallest preference, as determined by the policy defined in gated.conf.
2. Local_Pref - The route with the highest BGP local preference.
3. Shortest AS Path - The route with the fewest ASes listed in its AS Path.
4. 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.
5. 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.)
6. Shortest IGP distance - The route whose NEXT_HOP is closer (with respect to the IGP distance) is preferred.
7. Source IGP < EBGP < IBGP - Prefer first the strictly interior route, then the strictly exterior route, then the exterior route learned from an interior session.
8. 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 `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 ]
                    [ 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 `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_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_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
  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 `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 April 26, 1997