gated.proto(4)gated.proto(4)NAMEgated.proto - Gate daemon configuration file (protocol statements)
DESCRIPTION
Routing protocols determine the "best" route to each destination and
distribute routing information among the systems on a network. Routing
protocols are divided into two general groups: interior (intra-domain)
and exterior (inter-domain) protocols. The gated software combines man‐
agement of the interior and exterior routing protocols in one software
daemon.
Intra-Domain Routing Protocols
Intra-domain (interior) protocols are used to exchange reachability
information within an autonomous system (AS). They are referred to as
a class by the acronym IGP. The following interior protocols are sup‐
ported: The Routing Information Protocol, Version 1 and Version 2, is
the most commonly used interior protocol. RIP selects the route with
the lowest metric as the best route. The metric is a hop count repre‐
senting the number of gateways through which data must pass to reach
its destination. The longest path that RIP accepts is 15 hops. If the
metric is greater than 15, a destination is considered unreachable and
gated discards the route. RIP assumes the best route is the one that
uses the fewest gateways (the shortest path), not taking into account
congestion or delay on route.
The RIP version 1 protocol is described in RFC 1058; the RIP
version 2 protocol is described in RFC 11723. Open Shortest
Path First (OSPF) is a link-state protocol. OSPF is better
suited than RIP for complex networks with many routers. OSPF
provides equal cost multipath routing.
OSPF is described in RFC 2178; OSPF Version 2 is described in
RFC 1583. The OSPF Version 2 MIB is defined in RFC 1850. Other
related documents are RFC 1245, RFC 1246, and RFC 1370.
Exterior Routing Protocols
Exterior protocols are used to exchange routing information between au‐
tonomous systems. Exterior protocols are only required when an autono‐
mous system must exchange routing information with another autonomous
system. Routers within an autonomous system run an interior routing
protocol like RIP. Only those gateways that connect an autonomous sys‐
tem to another autonomous system need to run an exterior routing proto‐
col. The following exterior protocols are supported by gated: Exterior
Gateway Protocol (EGP). Originally EGP reachability information was
passed into ARPANET/MILNET "core" gateways where the best routes were
chosen and passed back out to all connected autonomous systems. As the
Internet moved toward a less hierarchical architecture, EGP, an exte‐
rior routing protocol that assumes a hierarchical structure, became
less effective.
The EGP protocol is described in RFC 827 and RFC 904. Border
Gateway Protocol (BGP) is replacing EGP as the exterior protocol
of choice. BGP exchanges reachability information between au‐
tonomous systems, but provides more capabilities than EGP. BGP
uses path attributes to provide more information about each
route as an aid in selecting the best route. Path attributes
can include, for example, administrative preferences based on
political, organizational, or security (policy) considerations
in the routing decision. BGP supports nonhierarchical topolo‐
gies and can be used to implement a network structure of equiva‐
lent autonomous systems.
BGP version 1 is described in RFC 1105, version 2 in RFC 1163,
version 3 in RFC 1267, and version 4 in RFC 1771. The version 3
MIB is described in RFC 1269. The documents RFC 1164, RFC 1268,
and RFC 1772 describe the application of version 2, 3, and 4 in
the Internet. A protocol analysis of and experience with BGP
version 3 are available in RFC 1265 and RFC 1266. RFC 1397
talks about advertising a default route in BGP version 2 and 3.
The BGP-4 MIB is draft standard, but schedule to go to standard.
Other references for BGP are: RFC 1997 for BGP Communities, RFC
1966 for BGP Route Reflection, RFC 1966 for BGP AS Confedera‐
tions, and RFC 1403 for BGP - OSPF interaction. A useful appli‐
cation document is RFC 1998, "An Application of the BGP Commu‐
nity Attribute in Multi-home Routing".
Other Routing Protocols
The following routing protocol is also supported: The Router Discovery
protocol is used to inform hosts of the availability of hosts it can
send packets to and is used to supplement a statically configured
default router. This is the preferred protocol for hosts to run, they
are discouraged from wiretapping routing protocols.
Router Discovery is described in RFC 1256.
Routing Information Protocol (RIP)
One of the most widely used interior gateway protocols is the Routing
Information Protocol (RIP). RIP is an implementation of a distance-
vector, or Bellman-Ford routing protocol for local networks. It clas‐
sifies routers as active and passive (silent). Active routers adver‐
tise their routes (reachability information) to others; passive routers
listen and update their routes based on advertisements, but do not
advertise. Typically, routers run RIP in active mode, while hosts use
passive mode.
A router running RIP in active mode broadcasts updates at set inter‐
vals. Each update contains paired values where each pair consists of
an IP network address and an integer distance to that network. RIP
uses a hop count metric to measure the distance to a destination. In
the RIP metric, a router advertises directly connected networks at a
metric of 1. Networks that are reachable through one other gateway are
two hops, and so on. Thus, the number of hops or hop count along a
path from a given source to a given destination refers to the number of
gateways that a datagram encounters along that path. Using hop counts
to calculate shortest paths does not always produce optimal results.
For example, a path with hop count 3 that crosses three Ethernets might
be substantially faster that a path with a hop count 2 that crosses two
slow-speed serial lines. To compensate for differences in technology
many routers advertise artificially high hop counts for slow links.
As delivered with most UNIX systems, RIP is run by the routing daemon,
routed (pronounced route-"d"). A RIP routing daemon dynamically builds
on information received through RIP updates. When started, it issues a
REQUEST for routing information and then listens for responses to the
request. If a system configured to supply RIP hears the request, it
responds with a RESPONSE packet based on information in its routing
database. The RESPONSE packet contains destination network addresses
and the routing metric for each destination.
When a RIP RESPONSE packet is received, the routing daemon takes the
information and rebuilds the routing database adding new routes and
better (lower metric) routes to destinations already listed in the
database. RIP also deletes routes from the database if the next router
to that destination says the route contains more than 15 hops, or if
the route is deleted. All routes through a gateway are deleted if no
updates are received from that gateway for a specified time period. In
general, routing updates are issued every 30 seconds. In many imple‐
mentations, if a gateway is not heard from for 180 seconds, all routes
from that gateway are deleted from the routing database. This 180 sec‐
ond interval also applies to deletion of specific routes.
RIP version 2 (more commonly known as RIP II) adds capabilities to RIP.
Some of these capabilities are compatible with RIP I and some are not.
To avoid supplying information to RIP I routes that could be misinter‐
preted, RIP II can only use non-compatible features when its packets
are multicast. On interfaces that are not capable of IP multicast, RIP
I-compatible packets are used that do not contain potentially confusing
information.
The following is a list of main RIP II enhancements: The primary ones
are the ability to advertise a next hop to use other than the router
supplying the routing update. This is quite useful when advertising a
static route to a dumb router that does not run RIP as it avoids having
packets destined through the dumb router from having to cross a network
twice.
RIP I routers ignore next hop information in RIP II packets.
This might result in packets crossing a network twice, which is
exactly what happens with RIP I. So this information is pro‐
vided in RIP I-compatible RIP II packets. RIP I assumes that
all subnetworks of a given network have the same network mask.
It uses this assumption to calculate the network masks for all
routes received. This assumption prevents subnets with differ‐
ent netmasks from being included in RIP packets. RIP II adds
the ability to explicitly specify the network mask with each
network in a packet.
While RIP I routers will ignore the network mask in RIP II pack‐
ets, their calculation of the network mask will quite possibly
be wrong. For this reason, RIP I-compatible RIP II packets must
not contain networks that would be misinterpreted. These net‐
work must only be provided in native RIP II packets that are
multicast.
RIP-I derives the network mask of received networks and hosts
from the network mask of the interface the packet via which the
packet was received. If a received network or host is on the
same natural network as the interface over which it was received
and that network is subnetted (the specified mask is more spe‐
cific than the natural netmask), the subnet mask is applied to
the destination. If bits outside the mask are set it is assumed
to be a host, otherwise it is assumed to be a subnet.
On point-to-point interfaces, the netmask is applied to the
remote address. The netmask on these interfaces is ignored if
it matches the natural network of the remote address or is all
ones.
Unlike in previous releases, the zero subnet mask (a network
that matches the natural network of the interface, but has a
more specific, or longer, network mask) is ignored. If this is
not desirable, a route filter can be used to reject it. RIP II
packets can also contain one of two types of authentication
string that can be used to verify the validity of the supplied
routing data. Authentication can be used in RIP I-compatible
RIP II packets, but be aware that RIP I routers ignore it.
The first method is a simple password in which an authentication
key of up to 16 characters is included in the packet. If this
does not match what is expected, the packet will be discarded.
This method provides very little security as it is possible to
learn the authentication key by watching RIP packets.
The second method uses the MD5 algorithm to create a crypto-
checksum of a RIP packet and an authentication key of up to 16
characters. The transmitted packet does not contain the authen‐
tication key itself, instead it contains a crypto-checksum,
called the digest. The receiving router will perform a calcula‐
tion using the correct authentication key and discard the packet
if the digest does not match. In addition, a sequence number is
maintained to prevent the replay of older packets. This method
provides a much stronger assurance that routing data originated
from a router with a valid authentication key.
Two authentication methods can be specified per interface. Pack‐
ets are always sent using the primary method, but received pack‐
ets are checked with both the primary and secondary methods
before being discarded. In addition, a separate authentication
key is used for non-router queries.
RIP Syntax
rip yes | no | on | off [ {
broadcast ;
nobroadcast ;
nocheckzero ;
preference preference ;
defaultmetric metric ;
query authentication [none | [[simple|md5] password]] ;
interface interface_list
[noripin] | [ripin]
[noripout] | [ripout]
[metricin metric]
[metricout metric]
[version 1]|[version 2 [multicast|broadcast]]
[[secondary] authentication [none | [[simple|md5] password]] ;
trustedgateways gateway_list ;
sourcegateways gateway_list ;
traceoptions trace_options ; } ] ;
The rip statement enables or disables RIP. If the rip statement is not
specified the default is rip on;. If enabled, RIP assumes nobroadcast
when there is only one interface and broadcast when there is more than
one. The following rip options are supported: Specifies that RIP pack‐
ets are broadcast regardless of the number of interfaces present. This
is useful when propagating static routes or routes learned from anther
protocol into RIP. In some cases, the use of broadcast when only one
network interface is present can cause data packets to traverse a sin‐
gle network twice. Specifies that RIP packets are not broadcast on
attached interfaces, even if there are more than one. If a sourcegate‐
ways clause is present, routes are unicast directly to that gateway.
Specifies that RIP should not make sure that reserved fields in incom‐
ing version 1 RIP packets are zero. Normally RIP rejects packets when
the reserved fields are zero. Sets the preference for routes learned
from RIP. The default preference is 100. This preference can be over‐
ridden by a preference specified in import policy. Defines the metric
used when advertising routes via RIP that were learned from other pro‐
tocols. If not specified, the default value is 16 (unreachable). This
choice of values requires you to explicitly specify a metric in order
to export routes from other protocols into RIP. This metric can be
overridden by a metric specified in export policy. Specifies the
authentication required of query packets that do not originate from
routers. The default is none. Controls various attributes of sending
RIP on specific interfaces. See the Interface Lists section in
gated.conf(4) for the description of the interface_list.
Note that if there are multiple interfaces configured on the
same subnet, RIP updates are sent from first one on which RIP
output is configured.
The following interface parameters are supported: Specifies that
RIP packets received via the specified interface are ignored.
The default is to listen to RIP packets on all non-loopback
interfaces. This is the default. This argument might be neces‐
sary when noripin is used on a wild card interface descriptor.
Specifies that no RIP packets are sent on the specified inter‐
faces. The default is to send RIP on all broadcast and non-
broadcast interfaces when in broadcast mode. The sending of RIP
on point-to-point interfaces must be manually configured. This
is the default. This argument is necessary when it is desired
to send RIP on point-to-point interfaces and might be necessary
when noripin is used on a wild card interface descriptor. Spec‐
ifies the RIP metric to add to incoming routes before they are
installed in the routing table. The default is the kernel
interface metric plus 1 (which is the default RIP hop count).
If this value is specified, it is used as the absolute value,
the kernel metric is not added. This option is used to make
this router prefer RIP routes learned via the specified inter‐
face(s) less than RIP routes from other interfaces. Specifies
the RIP metric to be added to routes that are send via the spec‐
ified interface(s). The default is zero. This option is used
to make other routers prefer other sources of RIP routes over
this router. Specifies that RIP packets sent via the specified
interface(s) are version 1 packets. This is the default. Spec‐
ifies that RIP version 2 packets are sent on the specified
interfaces(s). If IP multicast support is available on this
interface, the default is to send full version 2 packets. If it
is not available, version 1 compatible version 2 packets are
sent. Specifies that RIP version 2 packets should be multicast
on this interface. This is the default. Specifies that RIP
version 1-compatible version 2 packets should be broadcast on
this interface, even if IP multicast is available. Defines the
authentication type to use. It applies only to RIP version 2
and is ignored for RIP-1 packets. The default authentication
type is none. If a password is specified, the authentication
type defaults to simple. The password should be a quoted string
with between 0 and 16 characters.
If secondary is specified, this defines the secondary authenti‐
cation. If omitted, the primary authentication is specified.
The default is primary authentication of none and no secondary
authentication. Defines the list of gateways from which RIP
will accept updates. The gateway_list is a list of host names
or IP addresses. By default, all routers on the shared network
are trusted to supply routing information. But if the trust‐
edgateways clause is specified, only updates from the gateways
in the list are accepted. Defines a list of routers to which
RIP sends packets directly, not through multicast or broadcast.
This can be used to send different routing information to spe‐
cific gateways. Updates to gateways in this list are not
affected by noripout on the interface. Specifies the tracing
options for RIP. (See the Trace Options Statement section in
gated.conf(4) and the RIP-specific tracing options that follow.)
RIP Tracing options
The policy option logs info whenever a new route is announced, the met‐
ric being announced changes, or a route goes or leaves holddown. The
following packet tracing options, which can be modified with detail,
send, or recv, are supported: All RIP packets. RIP information request
packets, such as REQUEST, POLL and POLLENTRY RIP RESPONSE packets,
which is the type of packet that actually contains routing information.
Any other type of packet. The only valid ones are TRACE_ON and
TRACE_OFF both of which are ignored.
The OSPF Protocol
Open Shortest Path Routing (OSPF) is a shortest path first (SPF) or
link-state protocol. OSPF is an interior gateway protocol that dis‐
tributes routing information between routers in a single autonomous
system. OSPF chooses the least cost path as the best path. Suitable
for complex networks with a large number of routers, OSPF provides
equal cost multipath routing where packets to a single destination can
be sent via more than one interface simultaneously.
In a link-state protocol, each router maintains a database describing
the entire AS topology, which it builds out of the collected link state
advertisements of all routers. Each participating router distributes
its local state (the router's usable interfaces and reachable neigh‐
bors) throughout the AS by flooding. Each multiaccess network that has
at least two attached routers has a designated router and a backup des‐
ignated router. The designated router floods a link state advertise‐
ment for the multiaccess network and has other special responsibili‐
ties. The designated router concept reduces the number of adjacencies
required on a multiaccess network.
OSPF allows networks to be grouped into areas. Routing information
passed between areas is abstracted, potentially allowing a significant
reduction in routing traffic. OSPF uses four different types of
routes, listed in order of preference: intra-area, inter-area, type 1
external and type 2 external. Intra-area paths have destinations
within the same area, inter-area paths have destinations in other OSPF
areas and Autonomous System External (ASE) routes are routes to desti‐
nations external to the AS. Routes imported into OSPF as type 1 routes
are supposed to be from igps whose external metrics are directly compa‐
rable to OSPF metrics. When a routing decision is being made, OSPF
adds the internal cost to the AS Border router to the external metric.
Type 2 ASEs are used for egps whose metrics are not comparable to OSPF
metrics. In this case, only the internal OSPF cost to the AS Border
router is used in the routing decision.
From the topology database, each router constructs a tree of the short‐
est paths with itself as the root. This shortest-path tree gives the
route to each destination in the AS. Externally derived routing infor‐
mation appears on the tree as leaves. The link-state advertisement
format distinguishes between information acquired from external sources
and information acquired from internal routers, so there is no ambigu‐
ity about the source or reliability of routes. Externally derived
routing information (for example, routes learned from EGP or BGP) is
passed transparently through the autonomous system and is kept separate
from OSPF's internally derived data. Each external route can also be
tagged by the advertising router, enabling a passing of additional
information between routers on the borders of the autonomous system.
OSPF optionally includes type of service (TOS) routing and allows
administrators to install multiple routes to a given destination for
each type of service (for example, low delay or high throughput). A
router running OSPF uses the destination address and the type of ser‐
vice to choose the best route to the destination.
OSPF intra- and inter-area routes are always imported into the gated
routing database with a preference of 10. It would be a violation of
the protocol if an OSPF router did not participate fully in the area's
OSPF, so it is not possible to override this. Although it is possible
to give other routes lower preference values explicitly, it is ill-
advised to do so.
Hardware multicast capabilities are also used where possible to deliver
link-status messages. OSPF areas are connected by the backbone area,
the area with identifier 0.0.0.0. All areas must be logically contigu‐
ous and the backbone is no exception. To permit maximum flexibility,
OSPF allows the configuration of virtual links enable the backbone area
to appear contiguous despite the physical reality.
All routers in an area must agree on that area's parameters. A sepa‐
rate copy of the link-state algorithm is run for each area. Because of
this, most configuration parameters are defined on a per area basis.
All routers belonging to an area must agree on that area's configura‐
tion. Misconfiguration will lead to adjacencies not forming between
neighbors, and routing information might not flow, or even loop.
Authentication
All OSPF protocol exchanges can be authenticated. Authentication guar‐
antees that routing information is only imported from trusted routers,
to protect the Internet and its users. A variety of authentication
schemes can be used but a single scheme must be configured for each
interface. This enables some interfaces to use much stricter authenti‐
cation than others. The following authentication schemes are available:
No authentication. To use no authentication, add the following line to
the appropriate OSPF interface statements: auth none ; Simple authenti‐
cation key. Use this to prevent certain routers from exchanging OSPF
packets. The interfaces that the packets are to be sent on still need
to be trusted because the key will be placed in the packets and can be
seen by anyone with access to the network.
To specify simple authentication, add the following line to your
OSPF interface statements: auth simple auth_key; In the preced‐
ing line, auth_key is a string of up to 8 characters, and is
standardized. MD5 authentication. Use this when you do not
trust other users of your network. This system works by using
shared secret keys. Because the keys are used to sign the pack‐
ets with an MD5 checksum, they cannot be forged or tampered
with. Because the keys are not included in the packet, snooping
the key is not possible. Users of the network can still snoop
the contents of packets, however, because the packets are not
encrypted.
MD5 authentication is compliant with the OSPF specification in
RFC 2178. This specification uses the MD5 algorithm and an
authentication key of up to 16 characters. RFC 2178 allows mul‐
tiple MD5 keys per interface. Each key has two associated time
ranges.
To specify a single MD5 key on an interface, add the following
to the appropriate OSPF interface statements: auth md5 md5-key
where md5-key is: key your-key id id-number [ {
[ start-generate date-time ; ]
[ stop-generate date-time ; ]
[ start-accept date-time ; ]
[ stop-accept date-time ; ] } ] ; Where id-number is an
integer with a value between 1 and 255 and date-time is in the
format YYYY/MM/DD HH:MM (If any time fields are used, all are
required).
If no value is given for the time ranges, the default values
are: key is always generated key is always accepted
Thus, if you always want your key to be accepted, simply specify
a sequence such as: auth md5 key "mikeyone" id 1; To specify
multiple MD5 keys on an interface, add the following to the
appropriate OSPF interface statements: auth md5 {
md5-key
md5-key
.
.
.
md5-key } ; For example, two routers may start out generat‐
ing key 1 and want to switch to key 2 at 6:00 GMT. In order to
make the transition between keys easier, the routers agree to
stop generating key 1 at 6:00 GMT, but accept key 1 until 6:10
GMT. Key 2 is accepted 10 minutes before the planned switch
time (5:50 GMT). These overlapping ranges allow the clocks on
the routers to be slightly out of syncronization. You can spec‐
ify this sequence of keys as follows: auth md5 {
key "mikeyone" id 1 {
stop-generate 1999/05/01 06:00;
stop-accept 1999/05/01 06:10;
};
key "mikeytwo" id 2 {
start-generate 1999/05/01 06:00;
start-accept 1999/05/01 05:50;
}; };
OSPF Syntax
ospf yes | no | on | off [ {
defaults {
preference preference ;
cost cost ;
tag [as] tag ;
type 1 | 2 ;
inherit-metric ;
} ;
exportlimit routes ;
exportinterval time ;
traceoptions trace_options ;
syslog [first pktcnt][ every every_pktcnt] ;
monitorauthkey authkey ;
area area | backbone {
stub [cost cost] ;
networks {
network [restrict] ;
network mask mask [restrict] ;
network masklen number [restrict] ;
host host [restrict] ;
} ;
stubhosts {
host cost cost ;
} ;
interface interface_list; [cost cost] [ {
enable | disable ;
interface_parameters
} ] ;
interface interface_list nonbroadcast [cost cost] [ {
pollinterval time ;
routers {
gateway [eligible] ;
} ;
interface_parameters
} ] ;
Backbone only:
virtuallink neighborid router_id transitarea area {
interface_parameters
} ;
} ; } ] ; Specify the defaults used when importing OSPF Autonomous
System External (ASE) routes into the gated routing table and exporting
routes from the gated routing table into OSPF ASEs. The preference is
used to determine how OSPF routes compete with routes from other proto‐
cols in the gated routing table. The default value is 150. The cost
is used when exporting a non-OSPF route from the gated routing table
into OSPF as an ASE. The default value is 1. This can be explicitly
overridden in export policy. OSPF ASE routes have a 32-bit tag field
that is not used by the OSPF protocol, but might be used by export pol‐
icy to filter routes. When OSPF is interacting with an EGP, the tag
field can be used to propagate AS path information, in which case the
as keyword is specified and the tag is limited to 12 bits of informa‐
tion. If not specified, the tag is set to zero. Routes exported from
the gated routing table into OSPF default to becoming type 1 ASEs.
This default can be explicitly changed here and overridden in export
policy. Enables an OSPF ASE route to inherit the metric of the exter‐
nal route when no metric is specified on the export. This option main‐
tains compatibility with all the current export functions: A metric
specified on the export will take precedence. The cost specified in
the default will be used if inherit-metric is not specified. Because
of the nature of OSPF, the rate at which ASEs are flooded must be lim‐
ited. The following two parameters can be used to adjust those rate
limits: Specifies how often a batch of ASE link state advertisements
are generated and flooded into OSPF. The default is once per second.
Specifies how many ASEs are generated and flooded in each batch. The
default is 100. Specifies the tracing options for OSPF. (See
gated.conf(4) and the OSPF tracing options section.) Specifies the
tracing options for logging OSPF packets. The log will contain the
first pkcnt packets for every type of OSPF packet. After the first
pckcnt packets, the syslog will only save one message per every
every_pktcnt packets. OSPF state can be queried using the ospf_monitor
(This should be a hyperlink) utility. This utility sends non-standard
OSPF packets that generate a text response from OSPF. By default,
these requests are not authenticated; if an authentication key is con‐
figured, the incoming requests must match the specified authentication
key. No OSPF state can be changed by these packets, but the act of
querying OSPF can utilize system resources. Each OSPF router must be
configured into at least one OSPF area. If more than one area is con‐
figured, at least one must the be backbone. The backbone can only be
configured using the backbone keyword, it cannot be specified as area
0. The backbone interface can be a virtuallink. A stub area is one in
which there are no ASE routes. If a cost is specified, this injects a
default route into the area with the specified cost. The networks list
describes the scope of an area. Intra-area LSAs that fall within the
specified ranges are not advertised into other areas as inter-area
routes. Instead, the specified ranges are advertised as summary net‐
work LSAs. If restrict is specified, the summary network LSAs are not
advertised. Intra-area LSAs that do not fall into any range are also
advertised as summary network LSAs. This option is very useful on well
designed networks in reducing the amount of routing information propa‐
gated between areas. The entries in this list are either networks or a
subnetwork/mask pair. See the section on "Route Filtering" in
gated.control(4) for more detail about specifying ranges. Specifies
directly attached hosts that should be advertised as reachable from
this router and the costs they should be advertised with. Point-to-
point interfaces on which it is not desirable to run OSPF should be
specified here.
It is also useful to assign an additional address to the loop‐
back interface (one not on the 127 network) and advertise it as
a stub host. If this address is the same one used as the
router-id, it enables routing to OSPF routers by router-id
instead of by interface address. This is more reliable than
routing to one of the router's interface addresses, which might
not always be reachable. This form of the interface clause is
used to configure a broadcast (which requires IP multicast sup‐
port) or a point-to-point interface. See the "Interfaces State‐
ment" section in gated.conf(4) for the description of the inter‐
face_list parameters.
Each interface has a cost. The costs of all interfaces a packet
must cross to reach a destination are summed to get the cost to
that destination. The default cost is one, but another non-zero
value can be specified.
This form has one unique parameter: Enables or disables the
interface. See the "Interface Parameters" section for a list of
parameters common to all interface types. This form of the
interface clause is used to specify a nonbroadcast interface on
a non-broadcast multi-access (NBMA) medium. Because an OSPF
broadcast medium must support IP multicasting, a broadcast-capa‐
ble medium that does not support IP multicasting must be config‐
ured as a non-broadcast interface.
A non-broadcast interface supports any of the standard interface
clauses listed previously and the following two that are spe‐
cific to non-broadcast interfaces: Before adjacency is estab‐
lished with a neighbor, OSPF packets are sent periodically at
the specified poll interval. By definition, it is not possible
to send broadcast packets to discover OSPF neighbors on a non-
broadcast, so all neighbors must be configured. The list
includes one or more neighbors and an indication of their eligi‐
bility to become a designated router. See the "Interface Param‐
eters" section for a list of parameters common to all interface
types. Virtual links are used to establish or increase connec‐
tivity of the backbone area. The neighborid is the router_id of
the other end of the virtual link. The transit area specified
must also configured on this system. All standard interface
parameters defined by the interface clause can be specified on a
virtual link.
See the "Interface Parameters" section for a list of parameters
common to all interface types.
Interface Parameters
The following interface parameters are common to all types of inter‐
faces: The number of seconds between link state advertisement retrans‐
missions for adjacencies belonging to this interface. The estimated
number of seconds required to transmit a link state update over this
interface. The transitdelay parameter takes into account transmission
and propagation delays and must be greater than 0. A number between 0
and 255 specifying the priority for becoming the designated router on
this interface. When two routers attached to a network both attempt to
become designated router, the one with the highest priority wins. A
router whose router priority is set to 0 is ineligible to become desig‐
nated router. The length of time, in seconds, between Hello packets
that the router sends on the interface. The length of time, in sec‐
onds, a router's neighbors wait to hear a router's Hello packets before
the they declare the router down. Do not send or receive packets on
this interface. This has the effect of originating a stub link to this
interface into the domain. Used by OSPF authentication to generate and
verify the authentication field in the OSPF header. The authentication
key can be configured on a per interface basis. It is specified by one
to eight decimal digits separated by periods, a one- to eight-byte
hexadecimal string preceded by 0x, or a one to eight character string
in double quotes. See the "Authentication" section for additional
information.
Specify MD5 authentication with the md5-key, which is specified
as: key auth-key id id-number [ {
[start-generate date-time;]
[stop-generate date-time;]
[start-accept date-time;]
[stop-accept date-time;] }]; Where auth-key is a one-to-
eight character string, id-number is an integer with a value
between 1 and 255, and date-time is in the format YYYY/MM/DD
HH:MM. If any time fields are used, all are required.
See the "Authentication" section for additional information.
Used by OSPF authentication to generate and verify the secondary
authentication field in the OSPF header. The authentication key
can be configured on a per-interface basis. It is specified by
one to eight decimal digits separated by periods, a one-to-eight
byte hexadecimal string preceded by 0x, or a one-to-eight char‐
acter string in double quotes. See the "Authentication" section
for more information.
Point-to-point interfaces also support the following parameter:
By default, OSPF packets to neighbors on point-to-point inter‐
faces are sent via the IP multicast mechanism. Some implementa‐
tions of IP multicasting for UNIX, however, have a bug that pre‐
cludes the use of IP multicasting on these interfaces. The
gated daemon detects this condition and falls back to using
sending unicast OSPF packets to this point-to-point neighbor.
If the use of IP multicasting is not desired because the remote
neighbor does not support it, the nomulticast parameter can be
specified to force the use of unicast OSPF packets. You can
also use this option to eliminate warnings when gated detects
the previously described bug.
OSPF Tracing options
In addition to the following OSPF specific trace flags, OSPF supports
the state that traces interface and neighbor state machine transitions.
Creates the Link State Advertisement Traces the link state packets
transmitted Traces the link state packets received Traces the Shortest
Path First (SPF) calculations Traces OSPF at the debugging level of
detail The following packet tracing options, which can be modified with
detail, send, and recv, are supported: OSPF HELLO packets, which are
used to determine neighbor reachability. OSPF Database Description
packets, which are used in synchronizing OSPF databases. OSPF Link
State Request packets, which are used in synchronizing OSPF databases.
OSPF Link State Update packets, which are used in synchronizing OSPF
databases. OSPF Link State Ack packets, which are used in synchroniz‐
ing OSPF databases.
The Exterior Gateway Protocol (EGP)
The Exterior Gateway Protocol (EGP) is an exterior routing protocol
used for exchanging routing information with gateways in other autono‐
mous systems. Unlike interior protocols, EGP propagates only reacha‐
bility indications, not true metrics. EGP updates contain metrics,
called distances, that range from 0 to 255. The gated daemon compares
EGP distances learned from the same AS.
Before EGP sends routing information to a remote router, it must estab‐
lish an adjacency with that router. This is accomplished by an
exchange of Hello (not to be confused with the HELLO protocol or OSPF
HELLO messages) and I Heard You (I-H-U) messages with that router.
Computers communicating via EGP are called EGP neighbors, and the
exchange of HELLO and I-H-U messages is referred to as acquiring a
neighbor.
Once the neighbor is acquired, the system polls the neighbor for rout‐
ing information. The neighbor responds by sending an update containing
routing information. If the system receives a poll from its neighbor,
it responds with its own update packet. When the system receives an
update, it includes routes from the update into its routing database.
If the neighbor fails to respond to three consecutive polls, gated
assumes that the neighbor is down and removes the neighbor's routes
from its database.
EGP Syntax
egp yes | no | on | off [ {
preference preference ;
defaultmetric metric ;
packetsize number ;
traceoptions trace_options ;
group
[peeras autonomous_system]
[localas autonomous_system]
[maxup number]
{
neighbor host
[preference preference]
[preference2 preference]
[metricout metric]
[nogendefault]
[importdefault]
[exportdefault]
[gateway gateway]
[lcladdr local_address]
[sourcenet network]
[minhello | p1 time]
[minpoll | p2 time]
[ttl ttl]
[traceoptions trace_options]
;
} ; } ] ;
Sets the preference for routes learned from RIP. The default prefer‐
ence is 200. This preference can be overridden by a preference speci‐
fied on the group or neighbor statements or by import policy. Defines
the metric used when advertising routes via EGP. If not specified, the
default value is 255, which some systems can consider unreachable.
This choice of values requires you to explicitly specify a metric when
exporting routes to EGP neighbors. This metric can be overridden by a
metric specified on the neighbor or group statements or in export pol‐
icy. Defines the expected maximum size of a packet that EGP expects to
receive from this neighbor. If a packet larger than this value is
received, it is incomplete and is discarded. The length of this packet
is noted and the expected size is increased to be able to receive a
packet of this size. Specifying the parameter here prevents the first
packet from being dropped. If not specified, the default size is 8192
bytes. All packet sizes are rounded up to a multiple of the system
page size. Specifies the tracing options for EGP. By default these
are inherited from the global trace options. These values can be over‐
ridden on a group or neighbor basis. (See the Trace Options Statement
section in gated.conf(4) and the EGP-specific tracing options that fol‐
low.) EGP neighbors must be specified as members of a group. A group
is usually used to group all neighbors in one autonomous system.
Parameters specified on the group clause apply to all of the subsidiary
neighbors unless explicitly overridden on a neighbor clause. Any num‐
ber of group clauses can specify any number of neighbor clauses.
Any parameters from the neighbor subclause can be specified on
the group clause to provide defaults for the whole group (which
can be overridden for individual neighbors). In addition, the
group clause is the only place to set the following attributes:
Identifies the autonomous system number expected from peers in
the group. If not specified, it is learned dynamically. Iden‐
tifies the autonomous system that gated is representing to the
group. The default is that which has been set globally in the
autonomoussystem statement. This option is usually only used
when masquerading as another autonomous system and its use is
discouraged. Specifies the number of neighbors gated should
acquire from this group. The default is to acquire all of the
neighbors in the group. The gated daemon attempts to acquire
the first maxup neighbors in the order listed. If one of the
first neighbors is not available, it acquires one farther down
the list. If after start-up gated does manage to acquire the
more desirable neighbor, it drops the less desirable one. Each
neighbor subclause defines one EGP neighbor within a group. The
only part of the subclause that is required is the neigh‐
bor_address argument, which is the symbolic host name or IP
address of the neighbor. The following parameters are optional:
Specifies the preference used for routes learned from these
neighbors. This can differ from the default EGP preference set
in the egp statement, so that gated can prefer routes from one
neighbor, or group of neighbors, over another. This preference
can be explicitly overriden by import policy. In the case of a
preference tie, the second preference, preference2, can be used
to break the tie. The default value is 0. Defines a metric to
be used for all routes sent to this neighbor. The value over‐
rides the default metric set in the egp statement and any met‐
rics specified by export policy, but only for this specific
neighbor or group of neighbors. Prevents gated from generating
a default route when EGP receives a valid update from its neigh‐
bor. The default route is generated only when the gendefault
option is enabled. Enables gated to accept the default route
(0.0.0.0) if it is included in a received EGP update. If not
specified, the default route contained in an EGP update is
ignored. For efficiency, some networks have external routers
announce a default route to avoid sending large EGP update pack‐
ets. Enables gated to include the default route (0.0.0.0) in
EGP updates sent to this EGP neighbor. This allows the system
to advertise the default route via EGP. Normally a default
route is not included in EGP updates. If a network is not
shared with a neighbor, gateway specifies a router on an
attached network to be used as the next hop router for routes
received from this neighbor. This option is rarely used. Spec‐
ifies the address used on the local end of the connection with
the neighbor. The local address must be on an interface that is
shared with the neighbor or with the neighbor's gateway when the
gateway parameter is used. A session is opened only when an
interface with the appropriate local address (through which the
neighbor or gateway address is directly reachable) is operating.
Specifies the network queried in the EGP Poll packets. By
default this is the network shared with neighbors address speci‐
fied. If there is no network shared with the neighbor, specify
one of the networks to which the neighbor is attached. You can
also use this parameter to specify a network shared with the
neighbor other than the one on which the EGP packets are sent.
This parameter is normally not needed. Sets the minimum accept‐
able interval between the transmission of EGP HELLO packets.
The default hello interval is 30 seconds. If the neighbor fails
to respond to three hello packets, gated stops trying to acquire
the neighbor. Setting a larger interval gives the neighbor a
better chance to respond. The minhello parameter is an alias
for the P1 value defined in the EGP specification. Sets the
time interval between polls to the neighbor. The default is 120
seconds. If three polls are sent without a response, the neigh‐
bor is declared down and all routes learned from that neighbor
are removed from the routing database. A longer polling inter‐
val supports a more stable routing database, but is not as
responsive to routing changes. The minpoll parameter is an
alias for the P2 value defined in the EGP specification. By
default, gated sets the IP TTL for local neighbors to one and
the TTL for non-local neighbors to 255. This option is provided
when attempting to communicate with improperly functioning
routers that ignore packets sent with a TTL of one. Specifies
the tracing options for this EGP neighbor. By default these are
inherited from group or EGP global trace options. (See the
Trace Options Statement section in gated.conf(4) and the EGP
tracing options that follow.)
EGP Tracing options
The state and policy options work with EGP. The following packet trac‐
ing options, which can be modified with detail, send, and recv, are
supported for the EGP protocol: Traces all EGP packets Traces EGP
HELLO/I-HEARD-U packets, which are used to determine neighbor reacha‐
bility. Traces EGP ACQUIRE/CEASE packets, which are used to initiate
and terminate EGP sessions. Traces EGP POLL/UPDATE packets, which are
used to request and receive reachability updates.
The BGP Protocol Statement
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 au‐
tonomous systems as well as between transit and stub autonomous sys‐
tems. BGP is related to EGP, but operates with more capability,
greater flexibility, and less required bandwidth.
BGP uses path attributes to provide more information about each route,
and in particular 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 can 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 ses‐
sions run between routers in different autonomous systems. When send‐
ing routes to an external peer the local AS number is prepended to the
AS path, hence routes received from an external peer are guaranteed to
have the AS number of that peer at the start of the path. Routes
received from an internal neighbour will not in general have the local
AS number prepended to the AS path, and hence will in general 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 can be legitimately received from internal neighbours; these
indicate that the received route should be considered internal to your
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 capa‐
bility and function. They propagate only classed network routes, and
the AS path is a simple array of AS numbers. BGP 4 propagates fully
general address-and-mask routes, and the AS path has some structure to
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 (MED), in 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. In either case, smaller
values of the metric are preferred. Currently this metric is only used
to break ties between routes with equal preference from the same neigh‐
bour AS.
Internal BGP sessions carry at least one metric in the path attributes,
which BGP calls the LocalPref. The size of the metric is identical to
the MED. For BGP versions 2 and 3, this metric is considered better
when its value is smaller; for version 4 it is better when it is
larger. BGP version 4 sessions can optionally carry a second metric on
internal sessions, this being an internal version of the Multi-Exit
Discriminator. The use of these metrics is dependent on the type of
internal protocol processing that is specified.
BGP collapses routes with similar path attributes into a single update
for advertisement. Routes that are received in a single update are
readvertised in a single update. The churn caused by the loss of a
neighbor is minimized and the initial advertisement sent during peer
establishment is 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 might 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 connec‐
tion, 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 zero
length.
The BGP implementation expects external peers to be directly attached
to a shared subnet, and expects those peers to advertise next hops that
are host addresses on that subnet (though this constraint can be
relaxed by configuration for testing). For groups of internal peers,
however, you can select one of the following group types: 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
can be used directly for forwarding. Type routing groups 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 com‐
mon 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.
BGP Syntax
At the top of your configuration file, you must specify the AS and
routerid in order for BGP to operate. bgp yes | no | on | off [ {
preference preference ;
defaultmetric metric ;
traceoptions trace_options ;
[clusterid host ; ]
group type (external peeras autonomous_system)
| (internal peeras autonomous_system)
| (igp peeras autonomous_system proto proto)
| (routing peeras autonomous_system proto proto
interface interface_list)
| (test peeras autonomous_system)
{
allow {
network
network mask mask
network masklen number
all
host host
} ;
peer host
[authcheck]
[gateway gateway]
[holdtime time]
[ignorefirstashop]
[keep [all | none]]
[keepalivesalways]
[lcladdr local_address]
[logupdown]
[med]
[metricout metric]
[nexthopself]
[noaggregatorid]
[nogendefault]
[nov4asloop]
[passive]
[preference preference]
[preference2 preference]
[recvbuffer number]
[sendbuffer number]
[showwarnings]
[traceoptions trace_options]
[ttl ttl]
[v3asloopokay]
[version number]
;
} ; } ] ; external | internal | igp | test
The bgp statement enables or disables BGP. By default BGP is disabled.
The default metric for announcing routes via BGP is to not send a met‐
ric.
The following options are supported: Sets the preference for routes
learned from RIP. The default preference is 170. This preference can
be overridden by a preference specified on the group or peer statements
or by import policy. Defines the metric used when advertising routes
via BGP. If not specified, no metric is propagated. This metric can
be overridden by a metric specified on the neighbor or group statements
or in export policy. Specifies the tracing options for BGP. By
default, these are inherited from the global trace options. These val‐
ues can be overridden on a group or neighbor basis. (See the Trace
Options Statement section in gated.conf(4) and the BGP tracing options
that follow.) 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, you should select and configure a single cluster
ID on all route reflectors in the cluster. Use the following guidelines
in choosing a cluster ID: IDs of clusters within an AS must be unique
within that AS The cluster ID must not be 0.0.0.0. Choosing the clus‐
ter ID to be the router ID of one router in the cluster will always
fulfill these criteria. If there is only one route reflector in the
cluster, the clusterid setting may be omitted because the default will
suffice.
BGP Groups
BGP peers are grouped by type and the autonomous system of the peers.
Any number of groups can be specified, but each must have a unique com‐
bination of type and peer autonomous system. The following four group
types are supported: In the classic external BGP group, full policy
checking is applied to all incoming and outgoing advertisements. The
external neighbors must be directly reachable through one of the
machine's local interfaces. By default, no metric is included in
external advertisements, and the next hop is computed with respect to
the shared interface. An internal group operating where there is no
IP-level IGP, for example an SMDS network or MILNET. All peers 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 can be applied to group advertisements.
Routes received from external BGP or EGP peers are by default readver‐
tised with the received metric.
The lcladdr, outdelay, and metricout options must be set in the
group clause, not on a per-peer basis, for the group types
internal and routing. If these options are set on the peer sub‐
clause, they must equal the values set on the corresponding
group clause. An internal group to which the router is not con‐
nected. The proto keyword names the interior protocol to be
used to resolve BGP route next hops, and might be the name of
any IGP in the configuration, including static. An internal
group that uses the routes of an interior protocol to resolve
forwarding addresses. A type routing group propagates external
routes between routers that are not directly connected, and com‐
putes immediate next hops for these routes by using the BGP next
hop that 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 can be the name of any IGP in the configu‐
ration. By default, the next hop in BGP routes advertised to
type routing peers is set to the local address on the BGP con‐
nection to those peers, as it is assumed a route to this address
will be propagated via the IGP. The interface_list can option‐
ally provide a list interfaces whose routes are carried via the
IGP for which third party next hops can be used instead.
The lcladdr, outdelay, and metricout options must be set in the
group clause, not on a per-peer basis, for the group types
internal and routing. If these options are set on the peer sub‐
clause, they must equal the values set on the corresponding
group clause. An extension to external BGP that implements a
fixed policy using test peers. Fixed policy and special case
code make test peers relatively inexpensive to maintain. Test
peers do not need to be on a directly attached network. If
gated and the peer are on the same (directly attached) subnet,
the advertised next hop is computed with respect to that net‐
work, otherwise the next hop is the local machine's current next
hop. All routing information advertised by and received from a
test peer is discarded, and all BGP routes that can be adver‐
tised are sent back to the test peer. Metrics from EGP- and
BGP-derived routes are forwarded in the advertisement; otherwise
no metric is included.
BGP Group parameters
The BGP statement has group clauses and peer subclauses. Any number of
peer subclauses can be specified within a group. A group clause usu‐
ally defines default parameters for a group of peers; these parameters
apply to all subsidiary peer subclauses. Most parameters from the peer
subclause can be specified on the group clause to provide defaults for
the whole group, which can be overridden for individual peers.
The following optional parameters apply to both groups and peers:
[External groups only] Describes the number of times that this router
will insert its own AS number when it sends the AS path to an external
peer. The default is 1. Higher values are typically used to bias
upstream peers' route selection. (Most routers will prefer to use
routes with shorter AS Paths. Using ascount, the AS Path this router
sends can be artificially lengthened.)
Note: ascount supersedes the nov4asloop option. Regardless of
whether nov4asloop is set, this router will send multiple copies
of its own AS if the ascount option is set to something greater
than 1. Also, if the value of ascount is changed and gated is
reconfigured, routes will not be sent to reflect the new set‐
ting. If you want these routes to be sent, restart the peer ses‐
sion by commenting out the group ascount, reconfiguring, and
then uncommenting and reconfiguring again, or by restarting
gated. If a network is not shared with a peer, gateway speci‐
fies a router on an attached network to be used as the next hop
router for routes received from this neighbor. This parameter
is usually not needed. Specifies the BGP holdtime value, in
seconds, to use when negotiating the connection with this peer.
According to BGP, if gated does not receive a keepalive, update,
or notification message within the period specified in the Hold
Time field of the BGP Open message, the BGP connection is
closed. The value must be either 0 (no keepalives will be sent)
or at least 3. Some routers, known as route servers, are capa‐
ble of propagating routes without appending their own AS to the
AS Path. By default, gated drops such routes. Specifying
ignorefirstashop on the group clause allows gated to keep these
routes. Use this option only if you are sure that the peers in
this group are route servers and not normal routers. 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 specifica‐
tions on this point. The all parameter retains routes learned
from a peer even if the routes' AS paths contain one of our
exported AS numbers. The none parameter (the default) causes
gated to disregard routes containing the router's own AS num‐
bers. Specifies the address to be used on the local end of the
TCP connection with the peer. For external peers, the local
address must be on an interface that is shared with the peer or
with the peer's gateway when the gateway parameter is used. A
session with an external peer is opened only 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 is maintained when any
interface with the specified local address is operating. In
either case, incoming connections are recognized as matching a
configured peer if they are addressed to the configured local
address. Identifies the autonomous system that gated is repre‐
senting to this group of peers. The default is that which has
been set globally in the autonomoussystem statement. [Routing
groups only] Causes messages to be logged via the syslog mecha‐
nism whenever a BGP group enters or leaves the ESTABLISHED
state. By default, any metric (Multi Exit Discriminator)
received on a BGP connection is ignored. If MEDs are used 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 option to the peer or group parameter. If speci‐
fied, this metric is used as the primary metric on all routes
sent to the specified peer(s). This metric overrides the
default metric, a metric specified on the group, and any metric
specified by export policy. [Internal and external groups only]
Sets this group's next hops to the router's own address even if
it would normally be possible to send a third-party next hop.
Using 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
when other situations cause broken links. Causes gated to spec‐
ify 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. Pre‐
vents gated from generating a default route when EGP receives a
valid update from its neighbor. The default route is only gen‐
erated when the gendefault option is enabled. 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 that would incorrectly forward the routes on to version 3
neighbours. Specifies that active OPENs to this peer should not
be attempted. The gated daemon should wait for the peer to issue
an open. By default, all explicitly configured peers are
active; they periodically send OPEN messages until the peer
responds. Specifies the preference used for routes learned from
these peers. This can differ from the default BGP preference
set in the bgp statement, so that gated can prefer routes from
one peer, or group of peers, over others. This preference can
be explicitly overriden by import policy. In the case of a
preference tie, the second preference, preference2 can be used
to break the tie. The default value is 0. Control the amount
of receive and send buffering required of the kernel. The maxi‐
mum 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.
Forces gated to issue warning messages when receiving question‐
able BGP updates, such as duplicate routes or deletions of non-
existing routes. Typically these events are silently ignored.
[Routing groups only] Specifies the tracing options for this BGP
neighbor. By default these are inherited from group or BGP
global trace options. (See the Trace Options Statement section
in gated.conf(4) and the BGP specific tracing options that fol‐
low.) [Routing groups only] By default, gated sets the IP TTL
for local peers to one and the TTL for non-local peers to 255.
This option is provided for communicating with improperly func‐
tioning routers that ignore packets sent with a TTL of one. Not
all kernels allow the TTL to be specified for TCP connections.
By default, gated does not advertise routes whose AS path is
looped (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. Specifies the
version of the BGP protocol to use with this peer. If not spec‐
ified, the highest supported version is used first and version
negotiation is attempted. If it is specified, only the speci‐
fied version is offered during negotiation. Currently supported
version are 2, 3, and 4.
The following parameters apply to groups only: Originates the specified
AS path attributes. If the attributes are already present, they may be
augmented (as with communities) or possibly replaced (with other
attributes that may be supported in the future). Specifies the amount
of time a BGP route must be present before it is accepted into the
gated routing database. The default value is 0, meaning that this fea‐
ture is disabled. [Routing groups only] Provides a list of interfaces
whose routes are carried via the IGP for which third-party next hops
may be used. Specifies the amount of time a route must be present in
the gated routing database before it is exported to BGP. The default
value is 0, meaning that this feature is disabled. [Internal, IGP, and
routing groups only] Specifies that gated will act as a route reflector
for this group. The no-client-reflect option specifies that gated will
not act as an intra-group reflector. [IGP and routing groups only]
Allows BGP's Local_Pref attribute to be used to set the gated prefer‐
ence on reception, and allows 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.
Specifying peers
Within a group, BGP peers can be configured in either of the following
ways: explicitly with a peer statement or implicitly with the allow
statement. A description of each is as follows: Configures an individ‐
ual peer. Each peer inherits all parameters specified on a group as
defaults. Those default can be overridden by parameters explicitly
specified on the peer subclause. Allows for peer connections from any
addresses in the specified range of network and mask pairs. All param‐
eters 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 Filter‐
ing in gated.control(4).
Within each group clause, individual peers can be specified or a group
of potential peers can be specified using allow. The allow statement
is used to specify a set of address masks. If gated receives a BGP
connection request from any address in the set specified, it accepts it
and sets up a peer relationship.
BGP Peer parameters
The BGP peer subclause allows the following optional parameters, which
can also be specified on the group clause: Normally gated verifies that
incoming packets have an authentication field of all ones. This option
can be used to allow communication with an implementation that uses
some other form of authentication.
BGP Tracing options
Note that the state option works with BGP, but does not provide true
state transition information.
The following packet tracing options, which can be modified with
detail, send, and recv, are supported: Traces all BGP packets. Traces
BGP OPEN packets, which are used to establish a peer relationship.
Traces BGP UPDATE packets, which are used to pass network reachability
information. Traces BGP KEEPALIVE packets, which are used to verify
peer reachability. traces additions, changes, and deletions to the
gated routing table.
The ICMP Statement
On systems without the BSD routing socket, gated listens to ICMP mes‐
sages received by the system. Currently, gated processes only ICMP re‐
direct packets, but might process additional ICMP messages, such as
router discovery messages, in the future. Processing of ICMP redirect
messages is handled by the redirect statement.
Currently, the only reason to specify the icmp statement is to trace
the ICMP messages that gated receives.
ICMP Syntax
icmp {
traceoptions trace_options ; } Specifies the tracing options for
ICMP. (See the Trace Options Statement section in gated.conf(4) and the
ICMP tracing options that follow.)
ICMP Tracing options
The following packet tracing options, which can be modified with detail
and recv, are supported: Traces all ICMP packets received. Traces only
ICMP REDIRECT packets received. Traces only ICMP ROUTER DISCOVERY
packets received. Traces only ICMP informational packets, which
include mask request/response, info request/response, echo
request/response and time stamp request/response. Traces only ICMP
error packets, which include time exceeded, parameter problem, unreach‐
able and source quench.
Redirect Statement
The redirect code is passed ICMP or ISO redirects learned by monitoring
ICMP messages, or via the routing socket on systems that support it.
It processes the redirect request and decides whether to accept the re‐
direct. If the redirect is accepted, a route is installed in the gated
routing table with the protocol redirect. Redirects are deleted from
the routing table after 3 minutes.
If gated determines that a redirect is not acceptable, it verifies
whether the kernel forwarding table has been modified. On systems
where ICMP messages are monitored, this is accomplished by guessing
what the kernel would have done with the redirect. On systems with the
routing socket, the kernel provides an indication of whether the redi‐
rect was accepted; gated ignores redirects that were not processed.
If gated has determined that the state of the kernel forwarding table
has changed, the necessary requests to the kernel are made to restore
the correct state.
Note: On currently available systems, it is not possible to disable the
processing of ICMP redirects, even when the system is functioning as a
router. To ignore the effects of redirects, gated must process each
one and actively restore any changes it made to the kernel's state.
Because of the mechanism's involved, there will be windows where the
effects of redirects are present in the kernel.
By default, gated removes redirects when actively participating in an
interior gateway protocol (RIP or OSPF). It is impossible to enable
redirects once they have been automatically disabled. Listening to RIP
in nobroadcast mode does not cause redirects to be ignored, nor does
the use of EGP and BGP. Redirects must be manually configured off in
these cases.
Note: In accordance with the latest IETF Router Requirements document,
gated insures that all ICMP net redirects are processed as host redi‐
rects. When an ICMP net redirect is accepted, gated issues the
requests to the kernel to make sure that the kernel forwarding table is
updated to reflect a host redirect instead of a net redirect.
The redirect statement does not prevent the system from sending redi‐
rects, only from listening to them.
Redirect Syntax
redirect yes | no | on | off [{
preference preference ;
interface interface_list
[noredirects] | [redirects] ;
trustedgateways gateway_list ;
traceoptions trace_options ; }] ; Sets the preference for a route
learned from a redirect. The default is 30. The interface statement
allows the enabling and disabling of redirects on an interface-by-
interface basis. See the Interface List section in gated.conf(4) for
the description of the interface_list. The following parameters are
supported: Specifies that redirects received via the specified inter‐
face are ignored. The default is to accept redirects on all inter‐
faces. This is the default. This argument might be necessary when
noredirects is used on a wild card interface descriptor. Defines the
list of gateways from which redirects are accepted. The gateway_list
is simply a list of host names or addresses. By default, all routers
on the shared network(s) are trusted to supply redirects. But if the
trustedgateways clause is specified, only redirects from the gateways
in the list are accepted. There are no redirect-specific tracing
options. All non-error messages are traced under the normal class.
Redirect Tracing options
There are no redirect-specific tracing options. All non-error messages
are traced under the normal class.
The Router Discovery Protocol
The Router Discovery Protocol is an IETF standard protocol used to
inform hosts of the existence of routers. It is intended to be used
instead of having hosts wiretap routing protocols such as RIP. It is
used in place of, or in addition to, statically configured default
routes in hosts.
The protocol is split into two portions: the server portion, which runs
on routers, and the client portion, which runs on hosts. The gated
daemon treats these as two separate protocols, only one of which can be
enabled at a time.
The Router Discovery Server
The Router Discovery Server runs on routers and announces their exis‐
tence to hosts. It does this by periodically multicasting or broad‐
casting a Router Advertisement to each interface on which it is
enabled. These Router Advertisements contain a list of all the routers
addresses on a given interface and their preference for use as a
default router.
Initially these Router Advertisements occur every few seconds, then
fall back to every few minutes. In addition, a host might send a
Router Solicitation to which the router responds with a unicast Router
Advertisement (unless a multicast or broadcast advertisement is due
momentarily).
Each Router Advertisement contains a Advertisement Lifetime field indi‐
cating for how long the advertised addresses are valid. This lifetime
is configured such that another Router Advertisement is sent before the
lifetime has expired. A lifetime of zero indicates that one or more
addresses are no longer valid.
On systems supporting IP multicasting, the Router Advertisements are by
default sent to the all-hosts multicast address 224.0.0.1. However,
the use of broadcast can be specified. When Router Advertisements are
sent to the all-hosts multicast address, or an interface is configured
for the limited-broadcast address 255.255.255.255, all IP addresses
configured on the physical interface are included in the Router Adver‐
tisement. When the Router advertisements are being sent to a net or
subnet broadcast, only the address associated with that net or subnet
is included.
Router Discovery Server Syntax
routerdiscovery server yes | no | on | off [{
traceoptions trace_options ;
interface interface_list
[minadvinterval time]
[maxadvinterval time]
[lifetime time]
;
address interface_list
[advertise] | [ignore]
[broadcast] | [multicast]
[ineligible] | [preference preference]
; }] ; Specifies the Router Discovery tracing options. (See
Trace Options Statement section in gated.conf(4) and the Router Discov‐
ery specific tracing options.) Specifies the parameters that apply to
physical interfaces. Note a slight difference in convention from the
rest of gated: interface specifies just physical interfaces (such as
le0, ef0 and en1), while address specifies protocol (in this case, IP)
addresses.
The following interface parameters are supported: The maximum
time allowed between sending broadcast or multicast Router
Advertisements from the interface. Must be no less than 4 and
no more than 30:00 (30 minutes or 1800 seconds). The default is
10:00 (10 minutes or 600 seconds). The minimum time allowed
between sending unsolicited broadcast or multicast Router Adver‐
tisements from the interface. Must be no less than 3 seconds
and no greater than maxadvinterval. The default is 0.75 * max‐
advinterval. The lifetime of addresses in a Router Advertise‐
ment. Must be no less than maxadvinterval and no greater than
2:30:00 (two hours, thirty minutes or 9000 seconds). The
default is 3 * maxadvinterval. Specifies the parameters that
apply to the specified set of addresses on these physical inter‐
faces. Note a slight difference in convention from the rest of
gated: interface specifies just physical interfaces (such as
le0, ef0 and en1), while address specifies protocol (in this
case, IP) addresses. Specifies that the specified address(es)
are included in Router Advertisements. This is the default.
Specifies that the specified address(es) are not included in
Router Advertisements. Specifies that the given address(es) are
included in a broadcast Router Advertisement because this system
does not support IP multicasting, or some hosts on attached net‐
work do not support IP multicasting. It is possible to mix
addresses on a physical interface such that some are included in
a broadcast Router Advertisement and some are included in a mul‐
ticast Router Advertisement. This is the default if the router
does not support IP multicasting. Specifies that the given
address(es) are included in a multicast Router Advertisement.
If the system does not support IP multicasting, the address(es)
are not included. By default, if the system and given interface
support IP multicasting, the address(es) are included in a mul‐
ticast Router Advertisement. If the interface does not support
IP multicasting, the address(es) are included in a broadcast
Router Advertisement. The preferability of the address(es) as a
default router address, relative to other router addresses on
the same subnet. A 32-bit, signed, twos-complement integer,
with higher values meaning more preferable. Note: hex 80000000
can only be specified as ineligible. The default is 0. Speci‐
fies that the given address(es) are assigned a preference of
(hex 80000000), which means that it is not eligible to be the
default route for any hosts.
This is useful when the address(es) should not be used as a
default route, but are given as the next hop in an ICMP redi‐
rect. This allows the hosts to verify that the given addresses
are up and available.
The Router Discovery Client
A host listens for Router Advertisements via the all-hosts multicast
address (224.0.0.2), if IP multicasting is available and enabled, or on
the interface's broadcast address. When starting up, or when reconfig‐
ured, a host can send a few Router Solicitations to the all-routers
multicast address, 224.0.0.2, or the interface's broadcast address.
When a Router Advertisement with non-zero lifetime is received, the
host installs a default route to each of the advertised addresses. If
the preference is ineligible, or the address is not on an attached
interface, the route is marked unusable but retained. If the prefer‐
ence is usable, the metric is set as a function of the preference such
that the route with the best preference is used. If more than one
address with the same preference is received, the one with the lowest
IP address will be used. These default routes are not exportable to
other protocols.
When a Router Advertisement with a zero lifetime is received, the host
deletes all routes with next-hop addresses learned from that router.
In addition, any routers learned from ICMP redirects pointing to these
addresses are deleted. The same happens when a Router Advertisement is
not received to refresh these routes before the lifetime expires.
Router Discovery Client Syntax
routerdiscovery client yes | no | on | off [{
traceoptions trace_options ;
preference preference ;
interface interface_list
[enable] | [disable]
[broadcast] | [multicast]
[quiet] | [solicit]
; }] ; Specifies the tracing options for OSPF. (See the Trace
Options Statement section in gated.conf(4) and the OSPF-specific trac‐
ing options that follow.) Specifies the preference of all Router Dis‐
covery default routes. The default is 55. Specifies the parameters
that apply to physical interfaces. Note a slight difference in conven‐
tion from the rest of gated: interface specifies just physical inter‐
faces (such as le0, ef0 and en1). The Router Discovery Client has no
parameters that apply only to interface addresses. Specifies that
Router Discovery should be performed on the specified interface(s).
This is the default. Specifies that Router Discovery should not be
performed on the specified interface(s). Specifies that Router Solici‐
tations should be broadcast on the specified interface(s). This is the
default, if IP multicast support is not available on this host or
interface. Specifies that Router Solicitations should be multicast on
the specified interface(s). If IP multicast is not available on this
host and interface, no solicitation is performed. The default is to
multicast Router Solicitations if the host and interface support it;
otherwise, Router Solicitations are broadcast. Specifies that no
Router Solicitations are sent on this interface, even though Router
Discovery is performed. Specifies that initial Router Solicitations
are sent on this interface. This is the default.
Router Discovery Tracing options
The Router Discovery Client and Server support the state trace flag,
which traces various protocol occurrences. Traces state transitions
The Router Discovery Client and Server do not directly support any
packet tracing options; tracing of router discovery packets is enabled
via the ICMP Statement.
The SNMP Statement
The Simple Network Management Protocol (SNMP) is a not a routing proto‐
col but a network management protocol. The snmp statement controls
whether gated tries to contact the SNMP Multiplexing daemon to register
supported variables. The SNMP daemon (usually smuxd) must be run inde‐
pendently. The snmp statement only controls whether gated keeps the
management software apprised of its status.
The gated daemon communicates with the SNMP daemon via the SMUX proto‐
col that is described in RFC 1227.
SNMP Syntax
snmp yes | no | on | off [{
port port ;
debug ;
traceoptions traceoptions ; }] ;
Reporting is enabled by specifying yes or on and disabled with no or
off. The default is on. Specifies that gated try to contact the SMUX
daemon on a port other than the default port. By default, the SMUX
daemon listens for requests on port 199. Enables debugging of the
ISODE SMUX code. The default is debugging disabled. Specifies the
tracing options for SMUX. (See the Trace Options Statement section in
gated.conf(4) and the SMUX tracing options that follow.)
SNMP Tracing options
There are no SNMP-specific trace options. SNMP requests received via
the SMUX protocol from the SNMP daemon are not handles quite like pack‐
ets and are currently handled differently. The detail, send, and recv
options are not supported. SNMP requests received from the SMUX daemon
and the associated responses. Protocol requests to register variables.
Protocol requests to resolve variable names. SNMP trap requests from
protocols.
The Kernel Statement
While the kernel interface is not technically a routing protocol, it
has many characteristics of one, and gated treats it like a routing
protocol. The routes gated chooses to install in the kernel forwarding
table are those that are used by the kernel to forward packets.
The add, delete and change operations gated must use to update the typ‐
ical kernel forwarding table take a significant amount of time. This
does not present a problem for older routing protocols (for example,
RIP and EGP), which are not particularly time critical and do not eas‐
ily handle very large numbers of routes. The newer routing protocols
(for example, OSPF and BGP) have stricter timing requirements and are
often used to process many more routes. The speed of the kernel inter‐
face becomes critical when these protocols are used.
To prevent gated from locking up for significant periods of time
installing large numbers of routes (up to a minute or more has been
observed on real networks), the processing of these routes is now done
in batches. The size of these batches can be controlled by the tuning
parameters described below, but normally the default parameters will
provide the proper functionality.
During normal shutdown processing, gated normally deletes all the
routes it has installed in the kernel forwarding table, except for
those marked with retain. Optionally, gated can leave all routes in
the kernel forwarding table by not deleting any routes. In this case,
changes are made to insure that routes with a retain indication are
installed in the table. This is useful on systems with large numbers
of routes as it prevents the need to reinstall the routes when gated
restarts. This can greatly reduce the time it takes to recover from a
restart.
Forwarding tables and Routing tables
The table in the kernel that controls the forwarding of packets is a
forwarding table (referred to in ISO as a forwarding information base,
or FIB). The table that gated uses internally to store routing infor‐
mation it learns from routing protocols is a routing table (referred to
in ISO as a routing information base, or RIB). The routing table is
used to collect and store routes from various protocols. For each
unique combination of network and mask, an active route is chosen; this
route is the one with the best (numerically smallest) preference. All
the active routes are installed in the kernel forwarding table. The
entries in this table are what the kernel actually uses to forward
packets.
Updating the Forwarding Table
There are two main methods of updating the kernel FIB: the ioctl()
interface and the routing socket interface. Their various characteris‐
tics are described as follows:
Updating the Forwarding Table with the ioctl interface
The ioctl interface to the forwarding table was introduced in BSD 4.3
and widely distributed in BSD 4.3. This is a one-way interface; it
allows gated to update the kernel forwarding table only. It has the
following limitations: The BSD 4.3 networking code assumed that all
subnets of a given network had the same subnet mask. This limitation
is enforced by the kernel. The network mask is not stored in the ker‐
nel forwarding table, but determined when a packet is forwarded by
searching for interfaces on the same network. The gated daemon is able
to update the kernel forwarding table, but it is not aware of other
modifications of the forwarding table. The gated daemon is able to
listen to ICMP messages and determine how the kernel has updated the
forwarding table in response to ICMP redirects. The gated daemon is
not able to detect changes to the forwarding table resulting from the
use of the the route command by the system administrator. Use of the
route command on systems that use the ioctl() interface is strongly
discouraged while gated is running. In all known implementations,
there is no change operation supported. To change a route that exists
in the kernel, the route must be deleted and a new one added.
Updating the Forwarding Table with the routing socket interface
The routing socket interface to the kernel forwarding table was intro‐
duced in BSD 4.3 Reno, widely distributed in BSD 4.3 Net/2 and improved
in BSD 4.4. This interface is simply a socket, similar to a UDP
socket, on which the kernel and gated exchange messages. It has the
following advantages over the ioctl() interface: The network mask is
passed to the kernel explicitly. This allows different masks to be
used on subnets of the same network. It also allows routes with masks
that are more general than the natural mask to be used. This is known
as classless routing. Not only is gated able to change the kernel for‐
warding table with this interface, but the kernel can also report
changes to the forwarding table to gated. The most interesting of
these is an indication that a redirect has modified the kernel forward‐
ing table; this means that gated no longer needs to monitor ICMP mes‐
sages to learn about redirects. Plus, there is an indication of
whether the kernel processed the redirect; gated can safely ignore re‐
direct messages that the kernel did not process. Changes to the rout‐
ing table by other processes, including the route command are received
via the routing socket. This allows gated to insure that the kernel
forwarding table is synchronized with the routing table. Plus it
allows the system administrator the ability to do some operations with
the route command while gated is running. There is a functioning
change message that allows routes in the kernel to be atomically
changed. Some early versions of the routing socket code had bugs in
the change message processing. There are compilation time and configu‐
ration time options that cause delete and add sequences to be used in
lieu of change messages. New levels of kernel/gated communications can
be added by adding new message types.
Reading the Forwarding Table
When gated starts up, it reads the kernel forwarding table and installs
corresponding routes in the routing table. These routes are called
remnants, and are timed out after a configured interval (which defaults
to 3 minutes), or as soon as a more attractive route is learned. This
allows forwarding to occur during the time it takes the routing proto‐
cols to start learning routes.
The following methods are used for reading the forwarding table from
the kernel:
Reading forwarding table via kmem
On Tru64 UNIX systems, gated reads the forwarding table via kmem at
boot time. After the system is booted, gated uses the Routing Socket
interface to receive updates from the kernel.
Reading the forwarding table via OS specific methods
Some operating systems define their own method of reading the kernel
forwarding table.
Reading the interface list
The kernel support subsystem of gated is responsible for reading the
status of the kernel's physical and protocol interfaces periodically.
The gated daemon detects changes in the interface list and notifies the
protocols so they can start or stop instances or peers. The interface
list is read in the following ways:
Reading the interface list with SIOCGIFCONF
On systems based on BSD 4.3, 4.3 Reno, and 4.3 Net/2, the SIOCGIFCONF
ioctl interface is used to read the kernel interface list. Using this
method, a list of interfaces and some basic information about them is
returned by the SIOCGIFCONF call. Other information must be learned by
issuing other ioctls to learn the interface network mask, flags, MTU,
metric, destination address (for point-to-point interfaces) and broad‐
cast address (for broadcast capable interfaces).
The gated daemon rereads this list every 15 second looking for changes.
When the routing socket is in use, the daemon also rereads it whenever
a message is received indicating a change in routing configuration.
Receipt of a SIGUSR2 signal also causes gated to reread the list. This
interval can be explicitly configured in the interface configuration.
Reading the interface list with sysctl
BSD 4.4 added the ability to read the kernel interface list via the
sysctl system call. The interface status is returned atomically as a
list of routing socket messages that gated parses for the required
information.
BSD 4.4 also added routing socket messages to report interface status
changes immediately. This allows gated to react quickly to changes in
interface configuration.
When this method is used, gated rereads the interface list only once a
minute. It also rereads the list on routing table change indications
and when a SIGUSR2 is received. This interval can be explicitly con‐
figured in the interface configuration.
Reading interface physical addresses
Later versions of the getkerninfo() and sysctl() interfaces return the
interface physical addresses as part of the interface information. On
most systems where this information is not returned, gated scans the
kernel physical interface list for this information for interfaces with
IFF_BROADCAST set, assuming that their drivers are handled the same as
Ethernet drivers. On some systems, system specific interfaces are used
to learn this information.
The interface physical addresses are useful for IS-IS. For IP proto‐
cols, they are not currently used, but might be in the future.
Reading kernel variables
At startup, gated reads some special variables out of the kernel. This
is usually done with the nlist (or kvm_nlist) system call, but some
systems use different methods.
The variables read include the status of UDP checksum creation and gen‐
eration, IP forwarding, and kernel version (for informational pur‐
poses). On systems where the routing table is read directly from ker‐
nel memory, the root of the hash table or radix tree routing table is
read. On systems where interface physical addresses are not supplied
by other means, the root of the interface list is read.
Special route flags
The later BSD-based kernels support the following special route flags:
Instead of forwarding a packet like a normal route, routes with
RTF_REJECT cause packets to be dropped and unreachable messages to be
sent to the packet originators. This flag is valid only on routes
pointing at the loopback interface. Like the RTF_REJECT flag, routes
with RTF_BLACKHOLE cause packets to be dropped, but unreachable mes‐
sages are not sent. This flag is valid only on routes pointing at the
loopback interface. When gated starts, it reads all the routes cur‐
rently in the kernel forwarding table. Besides interface routes, it
usually marks everything else as a remnant from a previous run of gated
and deletes it after a few minutes. This means that routes added with
the route command are not retained after gated has started.
To fix this, the RTF_STATIC flag was added. When the route com‐
mand is used to install a route that is not an interface route,
it sets the RTF_STATIC flag. This signals gated that said route
was added by the system administrator and should be retained.
Kernel Syntax
kernel {
options
[nochange]
[noflushatexit]
;
routes number ;
flash
[limit number]
[type interface | interior | all]
;
background
[limit number]
[priority flash | higher | lower]
;
traceoptions trace_options ; } ; Configures kernel options. The
following options are valid: On systems supporting the routing socket,
this insures that changes operations are not performed, only deletes
and adds. This is useful on early versions of the routing socket code
where the change operation was broken. During normal shutdown process‐
ing, gated deletes all routes from the kernel forwarding table that do
not have a retain indication. The noflushatexit option prevents route
deletions at shutdown. Instead, routes are changed and added to make
sure that all the routes marked with retain get installed.
This is handy on systems with thousands of routes. Upon
startup, gated notices which routes are in the kernel forwarding
table and does not add them back. On some systems, kernel mem‐
ory is scarce. This parameter limits the maximum number of
routes gated installs in the kernel. Normally, gated adds,
changes, or deletes routes in interface, internal, or external
order; that is, it queues interface routes first, followed by
internal routes, followed by external routes, and processes the
queue from the beginning.
If this parameter is specified and the limit is hit, gated does
two scans of the list instead. On the first scan it does
deletes, and also deletes all changed routes, turning the queued
changes into adds. It then rescans the list, adding routes in
interface/internal/external order until it hits the limit again.
This tends to favor internal routes over external routes. The
default is to not limit the number of routes in the kernel for‐
warding table. When routes change, the process of notifying the
protocols is called a flash update. The kernel forwarding table
interface is the first to be notified. Normally a maximum of 20
interface routes can be processed during one flash update. The
flash command allows tuning of the following parameters: Speci‐
fies the maximum number of routes that can be processed during
one flash update. The default is 20. A value of -1 causes all
pending route changes of the specified type to be processed dur‐
ing the flash update. Specifies the type of routes that are
processed during a flash update. Interior specifies that inte‐
rior routes (See the definition of interior gateway protocols)
are also installed. The all parameter specifies the inclusion
of exterior routes (See the definition of exterior gateway pro‐
tocols) as well. The default is interface, which specifies that
only interface routes is installed during a flash update.
Specifying flash limit -1 all causes all routes to be installed
during the flash update; this mimics the behavior of previous
versions of gated. Since only interface routes are normally
installed during a flash update, the remaining routes are pro‐
cessed in batches in the background, that is, when no routing
protocol traffic is being received. Normally, 120 routes are
installed at a time to allow other tasks to be performed and
this background processing is done at lower priority than flash
updates. The following parameters allow tuning of these parame‐
ters: Specifies the number of routes that can be processed at
during one batch. The default is 120. Specifies the priority
of the processing of batches of kernel updates in relationship
to the flash update processing. The default is lower, which
means that flash updates are processed first. To process kernel
updates at the same priority as flash updates, specify flash; to
process them at a lower priority, use lower.
Kernel Interface Tracing options
While the kernel interface is not a routing protocol, in many cases it
is handled as one. The following two symbols make sense when entered
from the command line since the code that uses them is executed before
the trace file is parsed.
Symbols read from the kernel, by nlist(), or similar interface. Inter‐
face list scan. This option is useful when entered from the command
line as the first interface list scan is performed before the configu‐
ration file is parsed.
The following tracing options can only be specified in the configura‐
tion file. They are not valid from the command line. Traces routes
read from the kernel when gated starts. Traces requests by gated to
Add/Delete/Change routes in the kernel forwarding table.
The following general option and packet-tracing options only apply on
systems that use the routing socket to exchange routing information
with the kernel. They do not apply on systems that use the old BSD4.3
ioctl() interface to the kernel. Informational messages received from
the routing socket, such as TCP loss, routing lookup failure, and route
resolution requests. The gated daemon does not currently do processing
on these messages, just logs the information if requested.
The following packet tracing options, which can be modified with
detail, send, and recv, are supported: Routes exchanged with the ker‐
nel, including Add/Delete/Change messages and Add/Delete/Change mes‐
sages received from other processes. Redirect messages received from
the kernel. Interface status messages received from the kernel. These
are only supported on systems with networking code derived from BSD
4.4. Other messages received from the kernel, including those men‐
tioned in the info type above.
Static Routes Statements
The static statements define the static routes used by gated. A single
static statement can specify any number routes. The static statements
occur after protocol statements and before control statements in the
gated.conf file. Any number of static statements can be specified,
each containing any number of static route definitions. These routes
can be overridden by routes with better preference values.
Static Syntax
static {
(host host) | default |
(network [(mask mask) | (masklen number)])
gateway gateway_list
[interface interface_list]
[preference preference]
[retain]
[reject]
[blackhole]
[noinstall] ;
(network [(mask mask) | (masklen number)])
interface interface
[preference preference]
[retain]
[reject]
[blackhole]
[noinstall] ; } ; This is the most general form of the static
statement. It defines a static route through one or more gateways.
Static routes are installed when one or more of the gateways listed are
available on directly attached interfaces. If more than one eligible
gateways are available, they are limited by the number of multipath
destinations supported (this compile time parameter is currently almost
always one on Unix).
The following parameters for static routes are supported: When
this parameter is specified, gateways are only considered valid
when they are on one of these interfaces. See the section on
interface list specification for the description of the inter‐
face_list. Selects the preference of this static route. The
preference controls how this route competes with routes from
other protocols. The default preference is 60. Prevents spe‐
cific static routes from being removed. Normally, gated removes
all routes except interface routes from the kernel forwarding
table during a graceful shutdown. This is useful to insure that
some routing is available when gated is not running. Installs
this route as a reject route. Instead of forwarding a packet
like a normal route, reject routes cause packets to be dropped
and unreachable messages to be sent to the packet originators.
Not all kernel forwarding engines support reject routes. A
blackhole route is the same as a reject route except that
unreachable messages are not supported. Normally, the route
with the lowest preference is installed in the kernel forwarding
table and is the route exported to other protocols. When noin‐
stall is specified on a route, it is not installed in the kernel
forwarding table when it is active, but it will still be eligi‐
ble to be exported to other protocols. This form defines a
static interface route that is used for primitive support of
multiple network addresses on one interface. The preference,
retain, reject, blackhole, and noinstall options are the same as
described previously.
RELATED INFORMATION
Daemons: gated(8).
Files: gated.conf(4), gated.control(4).
Networking: gated_intro(7).
RFC 827, Exterior Gateway Protocol EGP, E. Rosen.
RFC 891, DCN local-network protocols, D. Mills.
RFC 904, Exterior Gateway Protocol Formal Specification, D. Mills.
RFC 1058, Routing Information Protocol, C. Hedrick.
RFC 1105, Border Gateway Protocol BGP, K. Lougheed, Y. Rekhter.
RFC 1163, A Border Gateway Protocol (BGP), K. Lougheed, Y. Rekhter.
RFC 1164, Application of the Border Gateway Protocol in the Internet,
J. Honig, D. Katz, M. Mathis, Y. Rekhter, J. Yu.
RFC 1227, SNMP MUX Protocol and MIB, M. Rose.
RFC 1245, OSPF Protocol Analysis, J. Moy.
RFC 1246, Experience with the OSPF Protocol, J. Moy.
RFC 1253, OSPF Version 2 Management Information Base, F. Baker, R.
Coltun.
RFC 1256, ICMP Router Discovery Messages, S. Deering.
RFC 1265, BGP Protocol Analysis, Y. Rekhter.
RFC 1266, Experience with the BGP Protocol, Y. Rekhter.
RFC 1267, A Border Gateway Protocol 3 (BGP-3), K. Lougheed, Y. Rekhter.
RFC 1268, Application of the Border Gateway Protocol in the Internet,
P. Gross, Y. Rekhter.
RFC 1269, Definitions of Managed Objects for the Border Gateway Proto‐
col (Version 3), J. Burruss, S. Willis.
RFC 1321, The MD5 Message-Digest Algorithm, R. Rivest.
RFC 1370, Internet Architecture Board Applicability Statement for OSPF
RFC 1388, RIP Version 2 Carrying Additional Information, G. Malkin.
RFC 1397, Default Route Advertisement In BGP2 And BGP3 Versions Of The
Border Gateway Protocol, D. Haskin.
RFC 1403, BGP OSPF Interaction, K. Varadhan.
RFC 1583, OSPF Version 2, J. Moy. delim off
gated.proto(4)