 |
Index for
Section 4 |
|
 |
Alphabetical
listing for G |
|
 |
Bottom of
page |
|
gated.proto(4)
NAME
gated.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 management
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 supported:
RIP 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 representing 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.
OSPF
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
autonomous systems. Exterior protocols are only required when an
autonomous 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 system
to another autonomous system need to run an exterior routing protocol. The
following exterior protocols are supported by gated:
EGP 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 exterior routing protocol that assumes a
hierarchical structure, became less effective.
The EGP protocol is described in RFC 827 and RFC 904.
BGP Border Gateway Protocol (BGP) is replacing EGP as the exterior protocol
of choice. BGP exchanges reachability information between autonomous
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 topologies and can be used to implement a network
structure of equivalent 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 Confederations, and RFC 1403 for
BGP - OSPF interaction. A useful application document is RFC 1998, "An
Application of the BGP Community Attribute in Multi-home Routing".
Other Routing Protocols
The following routing protocol is also supported:
Router Discovery
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 classifies routers
as active and passive (silent). Active routers advertise 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 intervals.
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 implementations, if a
gateway is not heard from for 180 seconds, all routes from that gateway are
deleted from the routing database. This 180 second 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 misinterpreted,
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:
Next hop
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 provided in RIP I-
compatible RIP II packets.
Network Mask
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
different 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 packets,
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 network 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 specific 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.
Authentication
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 authentication key itself,
instead it contains a crypto-checksum, called the digest. The
receiving router will perform a calculation 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. Packets are
always sent using the primary method, but received packets 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:
broadcast
Specifies that RIP packets 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 single network twice.
nobroadcast
Specifies that RIP packets are not broadcast on attached interfaces,
even if there are more than one. If a sourcegateways clause is
present, routes are unicast directly to that gateway.
nocheckzero
Specifies that RIP should not make sure that reserved fields in
incoming version 1 RIP packets are zero. Normally RIP rejects packets
when the reserved fields are zero.
preference preference
Sets the preference for routes learned from RIP. The default
preference is 100. This preference can be overridden by a preference
specified in import policy.
defaultmetric metric
Defines the metric used when advertising routes via RIP that were
learned from other protocols. 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.
query authentication [none | [[simple|md5] password]] ;
Specifies the authentication required of query packets that do not
originate from routers. The default is none.
interface interface_list
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:
noripin
Specifies that RIP packets received via the specified interface are
ignored. The default is to listen to RIP packets on all non-loopback
interfaces.
ripin
This is the default. This argument might be necessary when noripin
is used on a wild card interface descriptor.
noripout
Specifies that no RIP packets are sent on the specified interfaces.
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.
ripout
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.
metricin metric
Specifies 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 interface(s) less than RIP routes from
other interfaces.
metricout metric
Specifies the RIP metric to be added to routes that are send via the
specified interface(s). The default is zero. This option is used to
make other routers prefer other sources of RIP routes over this
router.
version 1
Specifies that RIP packets sent via the specified interface(s) are
version 1 packets. This is the default.
version 2
Specifies 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.
multicast
Specifies that RIP version 2 packets should be multicast on this
interface. This is the default.
broadcast
Specifies that RIP version 1-compatible version 2 packets should be
broadcast on this interface, even if IP multicast is available.
[secondary] authentication
[none | [simple|md5] password]
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 authentication.
If omitted, the primary authentication is specified. The default is
primary authentication of none and no secondary authentication.
trustedgateways gateway_list
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 trustedgateways clause is specified, only
updates from the gateways in the list are accepted.
sourcegateways gateway_list
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 specific gateways. Updates to gateways in this
list are not affected by noripout on the interface.
traceoptions trace_options
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 metric
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:
packets
All RIP packets.
request
RIP information request packets, such as REQUEST, POLL and POLLENTRY
response
RIP RESPONSE packets, which is the type of packet that actually
contains routing information.
other
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 distributes
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 neighbors)
throughout the AS by flooding. Each multiaccess network that has at least
two attached routers has a designated router and a backup designated
router. The designated router floods a link state advertisement for the
multiaccess network and has other special responsibilities. 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 destinations external to the AS.
Routes imported into OSPF as type 1 routes are supposed to be from igps
whose external metrics are directly comparable 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 shortest
paths with itself as the root. This shortest-path tree gives the route to
each destination in the AS. Externally derived routing information 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 ambiguity 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 service 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 contiguous 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 separate
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 configuration.
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
guarantees 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 authentication 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 authentication 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 preceding 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 packets 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 multiple 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 generating 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 specify 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
} ;
} ;
} ] ;
defaults
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.
preference preference
The preference is used to determine how OSPF routes compete with
routes from other protocols in the gated routing table. The default
value is 150.
cost cost
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.
tag [as] tag
OSPF ASE routes have a 32-bit tag field that is not used by the OSPF
protocol, but might be used by export policy 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 information. If not
specified, the tag is set to zero.
type 1 | 2
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.
inherit-metric
Enables an OSPF ASE route to inherit the metric of the external route
when no metric is specified on the export. This option maintains
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.
ASE export rate
Because of the nature of OSPF, the rate at which ASEs are flooded must
be limited. The following two parameters can be used to adjust those
rate limits:
exportinterval time
Specifies how often a batch of ASE link state advertisements are
generated and flooded into OSPF. The default is once per second.
exportlimit routes
Specifies how many ASEs are generated and flooded in each batch. The
default is 100.
traceoptions trace_options
Specifies the tracing options for OSPF. (See gated.conf(4) and the
OSPF tracing options section.)
yslog [first pktcnt] [every every_pktcnt]
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.
monitorauthkey authkey
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 configured, 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.
area area | backbone
Each OSPF router must be configured into at least one OSPF area. If
more than one area is configured, 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.
stub [cost cost]
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.
networks
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 network 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 propagated 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.
stubhosts
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 loopback
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.
interface interface_list [cost cost]
This form of the interface clause is used to configure a broadcast
(which requires IP multicast support) or a point-to-point interface.
See the "Interfaces Statement" section in gated.conf(4) for the
description of the interface_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:
enable | disable
Enables or disables the interface.
See the "Interface Parameters" section for a list of parameters common to
all interface types.
interface interface_list nonbroadcast [cost cost]
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-capable
medium that does not support IP multicasting must be configured as a
non-broadcast interface.
A non-broadcast interface supports any of the standard interface
clauses listed previously and the following two that are specific to
non-broadcast interfaces:
pollinterval time
Before adjacency is established with a neighbor, OSPF packets are
sent periodically at the specified poll interval.
routers
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 eligibility to become a designated router.
See the "Interface Parameters" section for a list of parameters common to
all interface types.
virtuallink neighborid router_id transitarea area
Virtual links are used to establish or increase connectivity 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 interfaces:
retransmitinterval time
The number of seconds between link state advertisement retransmissions
for adjacencies belonging to this interface.
transitdelay time
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.
priority priority
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 designated router.
hellointerval time
The length of time, in seconds, between Hello packets that the router
sends on the interface.
routerdeadinterval time
The length of time, in seconds, a router's neighbors wait to hear a
router's Hello packets before the they declare the router down.
passive
Do not send or receive packets on this interface. This has the effect of
originating a stub link to this interface into the domain.
auth [none | simple auth_key | md5 md5-key]
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.
secondary [none | simple | md5] auth_key
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 character string in double
quotes. See the "Authentication" section for more information.
Point-to-point interfaces also support the following parameter:
nomulticast
By default, OSPF packets to neighbors on point-to-point interfaces are
sent via the IP multicast mechanism. Some implementations of IP
multicasting for UNIX, however, have a bug that precludes 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.
lsabuild
Creates the Link State Advertisement
lsatransmit or (lsatx)
Traces the link state packets transmitted
lsareceive or (lsarx)
Traces the link state packets received
spf Traces the Shortest Path First (SPF) calculations
debug
Traces OSPF at the debugging level of detail The following packet
tracing options, which can be modified with detail, send, and recv, are
supported:
hello
OSPF HELLO packets, which are used to determine neighbor reachability.
dd OSPF Database Description packets, which are used in synchronizing OSPF
databases.
request
OSPF Link State Request packets, which are used in synchronizing OSPF
databases.
lsu OSPF Link State Update packets, which are used in synchronizing OSPF
databases.
ack OSPF Link State Ack packets, which are used in synchronizing 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 autonomous
systems. Unlike interior protocols, EGP propagates only reachability
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 establish
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 routing
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]
;
} ;
} ] ;
preference preference
Sets the preference for routes learned from RIP. The default
preference is 200. This preference can be overridden by a preference
specified on the group or neighbor statements or by import policy.
defaultmetric metric ;
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 policy.
packetsize maxpacketsize
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.
traceoptions trace_options
Specifies the tracing options for EGP. By default these are inherited
from the global trace options. These values can be overridden on a
group or neighbor basis. (See the Trace Options Statement section in
gated.conf(4) and the EGP-specific tracing options that follow.)
group
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
number 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:
peeras
Identifies the autonomous system number expected from peers in the
group. If not specified, it is learned dynamically.
localas
Identifies 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.
maxup
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.
neighbor neighbor_address
Each neighbor subclause defines one EGP neighbor within a group. The
only part of the subclause that is required is the neighbor_address
argument, which is the symbolic host name or IP address of the
neighbor. The following parameters are optional:
preference preference
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.
preference2 preference
In the case of a preference tie, the second preference, preference2,
can be used to break the tie. The default value is 0.
metricout metric
Defines a metric to be used for all routes sent to this neighbor.
The value overrides the default metric set in the egp statement and
any metrics specified by export policy, but only for this specific
neighbor or group of neighbors.
nogendefault
Prevents gated from generating a default route when EGP receives a
valid update from its neighbor. The default route is generated only
when the gendefault option is enabled.
importdefault
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 packets.
exportdefault
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.
gateway gateway
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.
lcladdr local_address
Specifies 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.
sourcenet network
Specifies the network queried in the EGP Poll packets. By default
this is the network shared with neighbors address specified. 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.
p1 time
minhello time
Sets the minimum acceptable 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.
p2 time
minpoll time
Sets the time interval between polls to the neighbor. The default is
120 seconds. If three polls are sent without a response, the
neighbor is declared down and all routes learned from that neighbor
are removed from the routing database. A longer polling interval
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.
ttl ttl
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.
traceoptions trace_options
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 tracing
options, which can be modified with detail, send, and recv, are supported
for the EGP protocol:
packets
Traces all EGP packets
hello
Traces EGP HELLO/I-HEARD-U packets, which are used to determine
neighbor reachability.
acquire
Traces EGP ACQUIRE/CEASE packets, which are used to initiate and
terminate EGP sessions.
update
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 autonomous systems
as well as between transit and stub autonomous systems. 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 sessions run
between routers in different autonomous systems. When sending routes to an
external peer the local AS number is prepended to the AS path, 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 capability
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 neighbour 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 connection,
no metric is sent and the path origin is set to incomplete. On external
connections, the AS path in unreachable announcements is set to the local
AS; on internal connections, the AS path is set to 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:
internal
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.
routing
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 common policy.
A copy of the message is sent to every peer in the group, with possible
adjustments to the next hop field as appropriate to each peer. This
minimizes the computational load of running large numbers of peers in these
types of groups. BGP allows unconfigured peers to connect if an
appropriate group has been configured with an allow clause.
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 metric.
The following options are supported:
preference preference
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.
defaultmetric metric
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.
traceoptions trace_options
Specifies the tracing options for BGP. By default, these are inherited
from the global trace options. These values 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.)
clusterid host
Specifies the route reflection cluster ID for BGP. The cluster ID
defaults to be the same as the router ID. If a router is to be a route
reflector, 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 cluster 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 combination
of type and peer autonomous system. The following four group types are
supported:
group type external peeras autonomous_system
In the classic external BGP group, full policy checking is applied to
all incoming and outgoing advertisements. The external neighbors must
be directly reachable through one of the machine's local interfaces.
By default, no metric is included in external advertisements, and the
next hop is computed with respect to the shared interface.
group type internal peeras autonomous_system
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 readvertised 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 subclause, they must
equal the values set on the corresponding group clause.
group type igp peeras autonomous_system proto proto
An internal group to which the router is not connected. 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.
group type routing peeras autonomous_system proto proto
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 computes
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 configuration. By
default, the next hop in BGP routes advertised to type routing peers is
set to the local address on the BGP connection to those peers, as it is
assumed a route to this address will be propagated via the IGP. The
interface_list can optionally provide a list 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 subclause, they must
equal the values set on the corresponding group clause.
group type test peeras autonomous_system
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 network, otherwise the next hop is the local machine's current
next hop. All routing information advertised by and received from a
test peer is discarded, and all BGP routes that can be advertised are
sent back to the test peer. Metrics from EGP- and BGP-derived routes
are forwarded in the advertisement; otherwise no metric is included.
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 usually
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:
ascount count
[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 setting. If you want these routes to be sent,
restart the peer session by commenting out the group ascount,
reconfiguring, and then uncommenting and reconfiguring again, or by
restarting gated.
gateway gateway
If a network is not shared with a peer, gateway specifies a router on an
attached network to be used as the next hop router for routes received
from this neighbor. This parameter is usually not needed.
holdtime time
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.
ignorefirstashop
Some routers, known as route servers, are capable 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.
keepalivesalways
Causes gated to always send keepalives, even when an update could have
correctly substituted for one. This allows interoperability with routers
that do not completely obey the protocol specifications on this point.
keep (all | none)
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
numbers.
lcladdr local_address
Specifies the address to be used on the local end of the TCP connection
with the peer. For external peers, the local address must be on an
interface that is shared with the peer or with the peer's gateway when
the gateway parameter is used. A session with an external peer 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.
localas autonomous_system
Identifies the autonomous system that gated is representing to this group
of peers. The default is that which has been set globally in the
autonomoussystem statement.
logupdown
[Routing groups only] Causes messages to be logged via the syslog
mechanism whenever a BGP group enters or leaves the ESTABLISHED state.
med
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.
metricout metric
If specified, this metric is used as the primary metric on all routes
sent to the specified peer(s). This metric overrides the default metric,
a metric specified on the group, and any metric specified by export
policy.
nexthopself
[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.
noaggregatorid
Causes gated to specify the routerid in the aggregator attribute as zero
(instead of its routerid) in order to prevent different routers in an AS
from creating aggregate routes with different AS paths.
nogendefault
Prevents gated from generating a default route when EGP receives a valid
update from its neighbor. The default route is only generated when the
gendefault option is enabled.
nov4asloop
Prevents routes with looped AS paths from being advertised to version 4
external peers. This can be useful to avoid advertising such routes to
peer that would incorrectly forward the routes on to version 3
neighbours.
passive
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.
preference preference
Specifies the preference used for routes learned from these peers. This
can differ from the default BGP preference set in the bgp statement, so
that gated can prefer routes from one peer, or group of peers, over
others. This preference can be explicitly overriden by import policy.
preference2 preference
In the case of a preference tie, the second preference, preference2 can
be used to break the tie. The default value is 0.
recvbuffer buffer_size
sendbuffer buffer_size
Control the amount of receive and send buffering required of the kernel.
The maximum supported is 65535 bytes, although many kernels have a lower
limit. By default, gated configures the maximum supported. These
parameters are not needed on normally functioning systems.
showwarnings
Forces gated to issue warning messages when receiving questionable BGP
updates, such as duplicate routes or deletions of non-existing routes.
Typically these events are silently ignored.
traceoptions trace_options
[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 follow.)
ttl ttl
[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 functioning routers that ignore packets
sent with a TTL of one. Not all kernels allow the TTL to be specified
for TCP connections.
v3asloopokay
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.
version version
Specifies the version of the BGP protocol to use with this peer. If not
specified, the highest supported version is used first and version
negotiation is attempted. If it is specified, only the specified version
is offered during negotiation. Currently supported version are 2, 3, and
4.
The following parameters apply to groups only:
aspath-opt
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).
indelay time
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 feature is disabled.
interface interface_list
[Routing groups only] Provides a list of interfaces whose routes are
carried via the IGP for which third-party next hops may be used.
outdelay time
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.
reflector-client [no-client-reflect]
[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.
setpref metric
[IGP and routing groups only] Allows BGP's Local_Pref attribute to be
used to set the gated preference 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:
peer host
Configures an individual 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.
allow
Allows for peer connections from any addresses in the specified range
of network and mask pairs. All parameters for these peers must be
configured on the group clause. The internal peer structures are
created when an incoming open request is received and destroyed when
the connection is broken. For more detail on specifying the
network/mask pairs, see the section on Route Filtering 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:
authcheck
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:
packets
Traces all BGP packets.
open
Traces BGP OPEN packets, which are used to establish a peer
relationship.
update
Traces BGP UPDATE packets, which are used to pass network reachability
information.
keepalive
Traces BGP KEEPALIVE packets, which are used to verify peer
reachability.
all traces additions, changes, and deletions to the gated routing table.
The ICMP Statement
On systems without the BSD routing socket, gated listens to ICMP messages
received by the system. Currently, gated processes only ICMP redirect
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 ;
}
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:
packets
Traces all ICMP packets received.
redirect
Traces only ICMP REDIRECT packets received.
routerdiscovery
Traces only ICMP ROUTER DISCOVERY packets received.
info
Traces only ICMP informational packets, which include mask
request/response, info request/response, echo request/response and time
stamp request/response.
error
Traces only ICMP error packets, which include time exceeded, parameter
problem, unreachable 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 redirect.
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 redirect 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 redirects.
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 redirects,
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 ;
}] ;
preference
Sets the preference for a route learned from a redirect. The default
is 30.
interface interface_list
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:
noredirects
Specifies that redirects received via the specified interface are
ignored. The default is to accept redirects on all interfaces.
redirects
This is the default. This argument might be necessary when
noredirects is used on a wild card interface descriptor.
trustedgateways gateway_list
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.
traceoptions trace_options
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 existence
to hosts. It does this by periodically multicasting or broadcasting 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
indicating 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 Advertisement. 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]
;
}] ;
traceoptions trace_options
Specifies the Router Discovery tracing options. (See Trace Options
Statement section in gated.conf(4) and the Router Discovery specific
tracing options.)
interface interface_list
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:
maxadvinterval time
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).
minadvinterval time
The minimum time allowed between sending unsolicited broadcast or
multicast Router Advertisements from the interface. Must be no less
than 3 seconds and no greater than maxadvinterval. The default is
0.75 * maxadvinterval.
lifetime time
The lifetime of addresses in a Router Advertisement. 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.
address interface_list
Specifies the parameters that apply to the specified set of addresses
on these 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.
advertise
Specifies that the specified address(es) are included in Router
Advertisements. This is the default.
ignore
Specifies that the specified address(es) are not included in Router
Advertisements.
broadcast
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 network 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 multicast Router
Advertisement. This is the default if the router does not support IP
multicasting.
multicast
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 multicast Router Advertisement. If the interface
does not support IP multicasting, the address(es) are included in a
broadcast Router Advertisement.
preference preference
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.
ineligible
Specifies 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 redirect. 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 reconfigured, 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 preference 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]
;
}] ;
traceoptions trace_options
Specifies the tracing options for OSPF. (See the Trace Options
Statement section in gated.conf(4) and the OSPF-specific tracing
options that follow.)
preference preference ;
Specifies the preference of all Router Discovery default routes. The
default is 55.
interface interface_list
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). The
Router Discovery Client has no parameters that apply only to interface
addresses.
enable
Specifies that Router Discovery should be performed on the specified
interface(s). This is the default.
disable
Specifies that Router Discovery should not be performed on the
specified interface(s).
broadcast
Specifies that Router Solicitations should be broadcast on the
specified interface(s). This is the default, if IP multicast support
is not available on this host or interface.
multicast
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.
quiet
Specifies that no Router Solicitations are sent on this interface,
even though Router Discovery is performed.
solicit
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.
state
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 protocol
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 independently. 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 protocol
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.
port port
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.
debug
Enables debugging of the ISODE SMUX code. The default is debugging
disabled.
traceoptions trace_options
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 packets and
are currently handled differently. The detail, send, and recv options are
not supported.
receive
SNMP requests received from the SMUX daemon and the associated
responses.
register
Protocol requests to register variables.
resolve
Protocol requests to resolve variable names.
trap
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 typical
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 easily 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 interface 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 information 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 characteristics
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:
Fixed subnet masks
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 kernel
forwarding table, but determined when a packet is forwarded by
searching for interfaces on the same network.
One way interface
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.
Blind updates
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.
Changes not supported
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 introduced
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:
Variable subnet masks
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.
Two way interface
Not only is gated able to change the kernel forwarding 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 forwarding table; this means that
gated no longer needs to monitor ICMP messages to learn about
redirects. Plus, there is an indication of whether the kernel
processed the redirect; gated can safely ignore redirect messages that
the kernel did not process.
Updates visible
Changes to the routing 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.
Changes supported
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 configuration time options that cause delete and add sequences
to be used in lieu of change messages.
Expandable
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 protocols 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 broadcast 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 configured 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 protocols,
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
generation, IP forwarding, and kernel version (for informational purposes).
On systems where the routing table is read directly from kernel 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:
RTF_REJECT
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.
RTF_BLACKHOLE
Like the RTF_REJECT flag, routes with RTF_BLACKHOLE cause packets to be
dropped, but unreachable messages are not sent. This flag is valid
only on routes pointing at the loopback interface.
RTF_STATIC
When gated starts, it reads all the routes currently 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 command 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 ;
} ;
options option_list
Configures kernel options. The following options are valid:
nochange
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.
noflushatexit
During normal shutdown processing, 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.
routes number
On some systems, kernel memory 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 forwarding table.
flash
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:
limit number
Specifies 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 during
the flash update.
type interface | interior | all
Specifies the type of routes that are processed during a flash
update. Interior specifies that interior 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 protocols) 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.
background
Since only interface routes are normally installed during a flash
update, the remaining routes are processed 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 parameters:
limit number
Specifies the number of routes that can be processed at during one
batch. The default is 120.
priority flash | higher | lower
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
Symbols read from the kernel, by nlist(), or similar interface.
iflist
Interface list scan. This option is useful when entered from the
command line as the first interface list scan is performed before the
configuration file is parsed.
The following tracing options can only be specified in the configuration
file. They are not valid from the command line.
remnants
Traces routes read from the kernel when gated starts.
request
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.
info
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
Routes exchanged with the kernel, including Add/Delete/Change messages
and Add/Delete/Change messages received from other processes.
redirect
Redirect messages received from the kernel.
interface
Interface status messages received from the kernel. These are only
supported on systems with networking code derived from BSD 4.4.
other
Other messages received from the kernel, including those mentioned 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] ;
} ;
host host gateway gateway_list
(network [(mask mask) | (masklen number)])
default gateway gateway_list
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:
interface interface_list
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
interface_list.
preference preference
Selects the preference of this static route. The preference controls
how this route competes with routes from other protocols. The
default preference is 60.
retain
Prevents specific 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.
reject
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.
blackhole
A blackhole route is the same as a reject route except that
unreachable messages are not supported.
noinstall
Normally, the route with the lowest preference is installed in the
kernel forwarding table and is the route exported to other protocols.
When noinstall is specified on a route, it is not installed in the
kernel forwarding table when it is active, but it will still be
eligible to be exported to other protocols.
(network [(mask mask) | (masklen number)])
interface interface
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 Protocol
(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.
|
Index for
Section 4 |
|
|
Alphabetical
listing for G |
|
 |
Top of
page |
|