Contains configuration information for the gated daemon.
The /etc/gated.conf file contains configuration
information for the gated daemon. The
file contains a sequence of statements. Statements are composed of
tokens separated by white space. You can create white space using any
combination of blanks, tabs, and new lines. The
gated.conf file supports several statements:
| %directory (directive) | Sets the directory for include files. |
| %include (directive) | Includes a file into gated.conf. |
| traceoptions (trace) | Specifies which events are traced. |
| options (definition) | Defines gated.conf options. |
| interfaces (definition) | Defines gated.conf interfaces. |
| autonomoussystem | Defines the AS number. |
| routerid (definition) | Defines the originating router (BGP, OSPF). |
| martians (definition) | Defines invalid destination addresses. |
| rip (protocol) | Enables RIP protocol. |
| hello (protocol) | Enables HELLO protocol. |
| isis (protocol) | Enables ISIS protocol. |
| ospf (protocol) | Enables OSPF protocol. |
| EGP (protocol) | Enables EGP protocol. |
| bgp (protocol) | Enables BGP protocol. |
| icmp (protocol) | Configures the processing of general ICMP packets. |
| snmp (protocol) | Enables reporting to SNMP. |
| static (static) | Defines static routes. |
| import (control) | Defines which routes to import. |
| export (control) | Defines which routes to export. |
| aggregate (control) | Defines which routes to aggregate. |
| generate (control) | Defines which routes to generate. |
Directive statements provide direction to the gated.conf
configuration language parser about included files and the directories in
which these files reside. Directive statements are immediately acted
upon by the parser. Other statements terminate with a semi-colon
(;), but directive statements terminate with a newline. The two
directive statements are:
In a complex environment, segmenting a large configuration into smaller more easily understood segments might be helpful, but one of the great advantages of gated.conf is that it combines the configuration of several different routing protocols into a single file. Segmenting a small file unnecessarily complicates routing configurations.
Trace statements control tracing options. gated.conf's tracing options may be configured at many levels. Tracing options include the file specifications, control options, and global and protocol specific tracing options. Unless overridden, tracing options from the next higher level are inherited by lower levels. For example, BGP peer tracing options are inherited from BGP group tracing options, which are inherited from global BGP tracing options, which are inherited from global gated.conf tracing options. At each level, tracing specifications override the inherited options.
There are two types of global options, those that only affect global operations, and those that have potential significance to protocols.
The trace flags that only have global significance are:
| parse | Traces the lexical analyzer and parser. Mostly used by gated.conf developers for debugging. |
| adv | Traces the allocation of and freeing of policy blocks. Mostly used by the gated.conf developers for debugging. |
| symbols | Used to trace symbols read from the kernel at startup. The only useful way to specify this level of tracing is via the -t option on the command line since the symbols are read from the kernel before parsing the configuration file. |
| iflist | Used to trace the reading of the kernel interface list. It is useful to specify this with the -t option on the command line since the first interface scan is done before reading the configuration file. |
The options flags that have potential significance to protocols are:
| all | Turn on all of the following. |
| general | Shorthand notation for specifying both normal and route. |
| state | Trace state machine transitions in the protocols. |
| normal | Trace normal protocols occurrences. Abnormal protocol occurrences are always traced. |
| policy | Trace application of protocol and user-specified policy to routes being imported and exported. |
| task | Trace system interface and processing associated with this protocol or peer. |
| timer | Trace timer usage by this protocol or peer. |
| route | Trace routing table changes for routes installed by this protocol or peer. |
Note: Not all of the above options apply to all of the protocols. In some cases, their use does not make sense (for instance, RIP does not have a state machine) and in some instances the requested tracing has not been implemented (such as RIP support of the policy option).
Note: It is not currently possible to specify packet tracing from the command line. This is because a global option for packet tracing would potentially create too much output.
When protocols inherit their tracing options from the global tracing options, tracing levels that don't make sense (such as parse, adv and packet tracing options) are masked out.
Global tracing statements have an immediate effect, especially parsing options that affect the parsing of the configuration file. Tracing values inherited by protocols specified in the configuration file are initially inherited from the global options in effect as they are parsed, unless they are overridden by more specific options. After the configuration file is read, tracing options that were not explicitly specified are inherited from the global options in effect at the end of the configuration file.
Tracing of packets is very flexible. For any given protocol, there are one or more options for tracing packets. All protocols allow use of the packets keyword that allows for tracing all packets sent and received by the protocol. Most protocols have other options for limiting tracing to a useful subset of packet types. These tracing options can be further controlled with the following modifiers:
Note: Detail, if specified, must be before send or recv. If a protocol allows for several different types of packet tracing, modifiers may be applied to each individual type. But be aware that within one tracing specification the trace flags are summed up, so specifying detail packets will turn on full tracing for all packets.
traceoptions ["trace_file" [replace] [size size[k|m] files files]]
[control_options] trace_options [except trace_options] ;
traceoptions none ;
| trace_file | Specifies the file to receive tracing information. If this file name does not begin with a slash (/), the directory where gated was started is prepended to the name. |
| replace | Indicates tracing should start by replacing an existing file. The default is to append to an existing file. |
| size size[k|m] files files | Limits the maximum size of the trace file to the specified size (minimum 10k). When the trace file reaches the specified size, it is renamed to file.0, then file.1, file.2 up to the maximum number of files (minimum specification is 2). |
| control_options | Specifies options that control the appearance of tracing. Valid
values are:
|
| except trace_options | Used to enable a broad class of tracing and then disable more specific options. |
| none | Specifies that all tracing should be turned off for this protocol or peer. |
Options statements allow specification of some global options. If used, options must appear before any other type of configuration statement in the gated.conf file.
The options statement syntax is:
options
[nosend ]
[noresolv ]
[gendefault [preference preference ] [gateway gateway] ]
[syslog [upto ] log_level ]
[mark time ]
;
The options list can contain one or more of the following options:
| gendefault [preference preference ] [gateway gateway] | When gendefault is enabled when a BGP or EGP neighbor is up,
it causes the creation of a default route with the special protocol
default. This can be disabled per BGP/EGP group with the
nogendefault option. By default, this route has a preference
of 20. This route is normally not installed in the kernel forwarding
table, it is only present so it can be announced to other protocols. If
a gateway is specified, the default route will be installed in the kernel
forwarding table with a next hop of the listed gateway.
Note: The use of the more general generate default option is preferred to the use of this gendefault option. See the section on Route Aggregation for more information on the generate statement. |
| nosend | Do not send any packets. This option makes it possible to run gated.conf on a live network to test protocol interactions without actually participating in the routing protocols. The packet traces in the gated.conf log can be examined to verify that gated.conf is functioning properly. This is most useful for RIP and HELLO. |
| noresolv | By default, gated.conf will try to resolve symbolic names into IP addresses; this option will prevent that. |
| syslog [upto ] log_level | Controls the amount of data gated.conf logs via syslog. |
| mark time | Specifying this option causes gated to output a message to the trace log at the specified interval. This can be used as one method of determining if gated is still running. |
interfaces {
options
[ strictinterfaces ]
[ scaninterval time ]
;
interface interface_list
[ preference preference ]
[ down preference preference ]
[ passive ]
[ simplex ]
[ reject ]
[ blackhole ]
;
define address
[ broadcast address ] | [ pointtopoint address ]
[ netmask mask ]
[ multicast ]
;
} ;
An interface is the connection between a router and one of its attached
networks. A physical interface may be specified by interface name, by
IP address, or by domain name, (unless the network is an unnumbered
point-to-point network.) Multiple levels of reference in the
configuration language allow identification of interfaces using wildcard,
interface type name, or delete word addresses. The
interface_list is a list of one or more interface names including
wildcard names (names without a number) and names that may specify more than
one interface or address, or the token all for all
interfaces.
| interface interface_list | Sets interface options on the specified interfaces. An interface
list is all or a list of interface names domain names, or numeric
addresses. Options available on this statement are:
|
| define address | Defines interfaces that might not be present when the gated
daemon is started so they may be referenced in the configuration file when
strictinterfaces is defined. Possible define
keywords are:
|
An interface list is a list of references to interfaces or groups of
interfaces. There are four methods available for referring to
interfaces. They are listed here from most general to most
specific.
| all | This refers to all available interfaces. |
| Interface name wildcard | This refers to all the interfaces of the same type. The operating system interfaces consist of the name of the device driver, like en, and a unit number, like 0 or 5. References to the name contain only alphabetic characters and match any interfaces that have the same alphabetic part. For example, en would refer to all Ethernet interfaces. |
| Interface name | This refers to a specific interface, usually one physical interface. These are specified as an alphabetic part followed by a numeric part. This will match one specific interface. For example, en1 will match an interface named en1, but not an interface named en10. |
| Interface address | This matches one specific interface. The reference can be by protocol address (that is, 10.0.0.51), or by symbolic hostname (that is, hornet.ibm.com). Note that a symbolic hostname reference is only valid when it resolves to only one address. Use of symbolic hostnames is not recommended. |
If many interface lists are present in the config file with more than one parameter, these parameters are collected at run-time to create the specific parameter list for a given interface. If the same parameter is specified on more than one list, the parameter with the most specific interface is used.
For example, consider a system with three interfaces: en0, en1, and tr0.
rip yes {
interface all noripin noripout;
interface en ripin;
interface en1 ripout;
} ;
RIP packets would only be accepted from interfaces en0 and en1, but not from tr0. RIP packets would only be sent on interface en1.
| loopback | This interface must have the address of 127.0.0.1. Packets sent to this interface are sent back to the originator. This interface is also used as a catch-all interface for implementing other features, such as reject and blackhole routes. Although a netmask is reported on this interface, it is ignored. It is useful to assign an additional address to this interface that is the same as the OSPF or BGP router id; this allows routing to a system based on the router id that will work if some interfaces are down. |
| broadcast | This is a multi-access interface capable of a physical level broadcast, such as Ethernet, Token Ring, and FDDI. This interface has an associated subnet mask and broadcast address. The interface route to a broadcast network will be a route to the complete subnet. |
| point-to-point | This is a tunnel to another host, usually on some sort of
serial link. This interface has a local address,
and a remote address.
The remote address must be unique among all the interface addresses on a given router. The local address may be shared among many point-to-point and up to one non-point-to-point interface. This is technically a form of the router id method for addressless links. This technique conserves subnets as none are required when using this technique. If a subnet mask is specified on a point-to-point interface, it is only used by RIP version 1 and HELLO to determine which subnets may be propagated to the router on the other side of this interface. |
| non-broadcast multi-access or nbma | This type of interface is multi-access, but not capable of broadcast. An example would be frame relay and X.25. This type of interface has a local address and a subnet mask. |
The gated daemon insures that there is a route available to each IP interface that is configured and up. Normally this is done by the ifconfig command that configures the interface; the gated daemon does it to insure consistency.
For point-to-point interfaces, the gated daemon installs some special routes. If the local address on one or more point-to-point interfaces is not shared with a non-point-to-point interface, the gated daemon installs a route to the local address pointing at the loopback interface with a preference of 110. This insures that packets originating on this host destined for this local address are handled locally. OSPF prefers to route packets for the local interface across the point-to-point link where they will be returned by the router on the remote end. This is used to verify operation of the link. Since OSPF installs routes with a preference of 10, these routes will override the route installed with a preference of 110.
If the local address of one or more point-to-point interfaces is shared with a non-point-to-point interface, the gated daemon installs a route to the local with a preference of 0 that will not be installed in the forwarding table. This is to prevent protocols like OSPF from routing packets to this address across a serial interface when this system could be functioning as a host.
When the status of an interface changes, the gated daemon notifies all the protocols, which take the appropriate action. The gated daemon assumes that interfaces that are not marked UP do not exist.
The gated daemon ignores any interfaces that have invalid data for the local, remote, or broadcast addresses or the subnet mask. Invalid data includes zeros in any field. The gated daemon will also ignore any point-to-point interface that has the same local and remote addresses.
Definition statements are general configuration statements that relate to all of gated daemon or at least to more than one protocol. The three definition statements are autonomoussystem, routerid, and martians. If used, autonomoussystem, routerid, and martians must appear before any other type of configuration statement in the gated daemon file.
autonomoussystem autonomous_system [loops number] ;
Sets the autonomous system number of this router to be autonomous system. This option is required if BGP or EGP are in use. The AS number is assigned by the Network Information Center (NIC).
Loops is only for protocols supporting AS paths, such as BGP. It controls the number of times this autonomous system may appear in an AS path and defaults to 1 (one).
routerid host ;
Sets the router identifier for use by the BGP and OSPF protocols. The default is the address of the first interface encountered by the gated daemon. The address of a non-point-to-point interface is preferred over the local address of a point-to-point interface and an address on a loopback interface that is not the loopback address (127.0.0.1) is most preferred.
martians {
host host [allow] ;
network [allow] ;
network mask mask [allow] ;
network masklen number [allow] ;
default [allow] ;
} ;
Defines a list of martian addresses about which all routing information is ignored. Sometimes a misconfigured system sends out obviously invalid destination addresses. These invalid addresses, called martians, are rejected by the routing software. This command allows additions to the list of martian addresses. See the section on Route Filtering for more information on specifying ranges. Also, the allow parameter may be specified to explicitly allow a subset of a range that was disallowed.
options gendefault ;
autonomoussystem 249 ;
interface 128.66.12.2 passive ;
martians {
0.0.0.26
};
The statements in the sample perform the following functions:
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 will assume nobroadcast when there is only one interface and broadcast when there is more than one.
The options are as follows:
Note:If there are multiple interfaces configured on the same subnet, RIP updates will only be sent from the first one from which RIP output is configured.
The possible parameters are:
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.
The policy option logs info whenever a new route is announced, the metric being announced changes, or a route goes or leaves holddown.
Packet tracing options (which may be modified with detail,
send, or recv):
| packets | All RIP packets. |
| request | All RIP information request packets, such as REQUEST, POLL, and POLLENTRY. |
| response | All RIP RESPONSE packets, which are the types of packets 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. |
hello yes | no | on | off [{
broadcast ;
nobroadcast ;
preference preference ;
defaultmetric metric ;
interface interface_list
[nohelloin] | [helloin]
[nohelloout] | [helloout]
[metricin metric]
[metricout metric] ;
trustedgateways gateway_list ;
sourcegateways gateway_list ;
traceoptions trace_options ;
} ] ;
The hello statement enables or disables HELLO. If the
hello statement is not specified, the default is hello
off. If enabled, HELLO will assume nobroadcast when
there is only one interface and broadcast when there is more than
one interface.
| broadcast | Specifies that HELLO packets will be broadcast regardless of the number of interfaces present. This is useful when propagating static routes or routes learned from anther protocol into HELLO. 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 HELLO packets will not be broadcast on attached interfaces, even if there are more than one. If a sourcegateways clause is present, routes will still be unicast directly to that gateway. |
| preference preference | Sets the preference for routes learned from HELLO. The default preference is op. This preference may be overridden by a preference specified in import policy. |
| defaultmetric metric | Defines the metric used when advertising routes via HELLO were learned from other protocols. If not specified, the default value is 30000 (unreachable). This choice of values requires you to explicitly specify a metric in order to export routes from other protocols into HELLO. This metric may be overridden by a metric specified in export policy. |
| interface interface_list | Controls various attributes of sending HELLO on specific
interfaces. See the section on interface list specification for the
description of the
interface_list.
Note: If there are multiple interfaces configured on the same subnet, HELLO updates will only be sent from the first one from which the HELLO output is configured.
The possible parameters are:
|
| trustedgateways gateway_list | Defines the list of gateways from which HELLO will accept updates. The gateway_list is simply 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 HELLO 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 HELLO. (See Trace Statements and the HELLO specific tracing
options below.)
The default preference is 90. The default metric is 30000. |
The policy option logs info whenever a new route is announced, the metric being announced changes, or a route goes or leaves holddown.
Packet tracing options (which may be modified with detail,
send, and/or recv):
| packets | All HELLO packets |
isis no | dual | ip | iso {
level 1|2 ;
[traceoptions <isis_traceoptions> ;]
[systemid <6_digit_hexstring> ;]
[area <hexstring> ;]
[set <isis_parm> <value> ; ... ]
circuit <string>
metric [level 1|2] <1..63>
...
priority [level 1|2] <0..127>
...
;
...
} ;
This statement enables the IS-IS protocol in the gated
daemon. By default, IS-IS is disabled. The dual
option specifies that the IS-IS protocol is enabled for both ISO and IP
addressing. The isis statement consists of an initial
description of the IS and a list of statements that determine the
configuration of the specific circuits and networks to be managed.
Statements may appear in any order and include:
| level | Indicates whether gated is running on a Level 1 (intra-area) or Level 2 (inter-area) IS. The default is Level 1. |
| traceoptions | Covered in the Tracing options section below. |
| systemid | Overrides the autoconfigured system ID (determined from interface addresses and corresponding netmasks). If no system identifier is specified, the system ID portion of the first real circuit's NSAP is used. Once a system ID is set, it cannot be changed without disabling and reenabling all of IS-IS. |
| area | IS-IS area addresses are automatically configured based on the real circuits over which IS-IS runs. Addresses specified in this statement are maintained in addition to those configured automatically from the circuits. This command is used primarily for simulation. |
| circuit | Each circuit statement specifies one of the circuits the system will manage. Circuits normally correspond to UNIX interfaces, with string being the interface name, but simulated device names may also be specified. If the string is in the form of "simN", where N is an integer, the circuit is assumed to be a simulated circuit managed by the network simulator troll. The circuit attributes are a list of options that may appear in any order in the circuit statement. |
| metric | Allows specifications of Level 1 and Level 2 metrics for each circuit. Only the default metric type is supported. IS-IS metrics must be in the range 1 to 63. If no metric is set for the circuit, the default value is 63. |
| priority | Determines designated router election results; higher values give a higher likelihood of becoming the designated router. The level defaults to Level 1. If no priority is specified, priority is set to a random value between 0 and 127. |
On a level 2 IS, to configure a circuit with a Level 1 metric of 10 and a Level 2 metric of 20, add two metric options to the circuit statement.
The default Level is 1: the default metric is 63. The default preference for IS-IS Level 1 is 15 for IS-IS Level 2 is 18.
Traceoptions can be one or more of the following:
all iih lanadj p2padj lspdb lspcontent lspinput flooding buildlsp csnp psnp route update paths spf events
ospf yes | no | on | off [{
defaults {
preference preference ;
cost cost ;
tag [as ] tag ;
type 1 | 2 ;
} ;
exportlimit routes ;
exportinterval time ;
traceoptions trace_options ;
monitorauthkey authkey ;
monitorauth none | ( [simple | md5 ] authkey ) ;
backbone | ( area area ) {
authtype 0 | 1 | none | simple ;
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 ] {
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
} ;
};
} ];
The following are the interface_parameters referred to above. They may be specified on any class of interface and are described under the interface clause.
enable | disable;
retransmitinterval time;
transitdelay time;
priority priority;
hellointerval time;
routerdeadinterval time;
authkey auth_key;
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 hosts. If this address is the same one used as the router-id, it enables routing to OSPF routers by router-id, instead of by an interface address. This is more reliable than routing to one of the router's interface addresses that may not always be reachable.
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 may be specified.
Interface parameters common to all types of interfaces are:
Point-to-point interfaces also support this additional parameter:
If the use of IP multicasting is not desired because the remote neighbor does not support it, the nomulticast parameter may be specified to force the use of unicast OSPF packets. This option may also be used to eliminate warnings when gated.conf detects the bug mentioned above.
A non-broadcast interface supports any of the standard interface clauses listed above, plus the following two that are specific to non-broadcast interfaces:
In addition to the following OSPF specific trace flags, OSPF supports the
state that traces interface and neighbor state machine
transitions.
| lsabuild | Link State Advertisement creation |
| spf | Shortest Path First (SPF) calculations |
Packet tracing options (which may be modified with detail,
send and recv):
| hello | OSPF HELLO packets that are used to determine neighbor reachability. |
| dd | OSPF Database Description packets that are used in synchronizing OSPF databases. |
| request | OSPF Link State Request packets that are used in synchronizing OSPF databases. |
| lsu | OSPF Link State Update packets that are used in synchronizing OSPF databases. |
| ack | OSPF Link State Ack packets that are used in synchronizing OSPF databases. |
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
[metricout metric ]
[preference preference ]
[preference2 preference ]
[ttl ttl ]
[nogendefault ]
[importdefault ]
[exportdefault ]
[gateway gateway ]
[lcladdr local_address ]
[sourcenet network ]
[minhello | p1 time ]
[minpoll | p2 time ]
[traceoptions trace_options ]
;
} ;
} ] ;
Any parameters from the neighbor subclause may be specified on the group clause to provide defaults for the whole group (which may be overridden for individual neighbors). In addition, the group clause is the only place to set the following attributes:
The state and policy options work with EGP.
Packet tracing options (which may be modified with detail,
send and recv):
| packets | All EGP packets |
| hello | EGP HELLO/I-HEARD-U packets that are used to determine neighbor reachability. |
| acquire | EGP ACQUIRE/CEASE packets that are used to initiate and terminate EGP sessions. |
| update | EGP POLL/UPDATE packets that are used to request and receive reachability updates. |
bgp yes | no | on | off
[ {
preference preference ;
defaultmetric metric ;
traceoptions trace_options ;
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
[ metricout metric ]
[ localas autonomous_system ]
[ nogendefault]
[ gateway gateway ]
[ preference preference ]
[ preference2 preference ]
[ lcladdr local_address ]
[ holdtime time ]
[ version number ]
[ passive]
[ indelay time ]
[ outdelay time ]
[ keep [ all | none] ]
[ noaggregatorid]
[ keepalivesalways]
[ v3asloopokay]
[ nov4asloop]
[ logupdown]
[ ttl ttl ]
[ traceoptions trace_options ]
;
} ;
}] ;
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
not to send a metric.
| preference preference | Sets the preference for routes learned from RIP. The default preference is 170. This preference may 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 may be overridden by a metric specified on the neighbor or group statements or in export policy. |
| traceoptions trace_options | Specifies the tracing options for BGP. By default these are inherited from the global trace options. These values may be overridden on a group or neighbor basis. (See Trace Statements and the BGP specific tracing options below.) |
BGP peers are grouped by type and the autonomous system of the peers. Any number of groups may be specified, but each must have a unique combination of type and peer autonomous system. There are four possible group types:
The proto names the interior protocol to be used to resolve BGP route next hops, and may be the name of any IGP in the configuration. By default, the next hop in BGP routes advertised to type routing peers will be set to the local address on the BGP connection to those peers, as it is assumed a route to this address will be propagated via the IGP. The interface_list can optionally provide list interfaces whose routes are carried via the IGP for which third party next hops may be used instead.
The BGP statement has group clauses and peer subclauses. Any number of peer subclauses may be specified within a group. A group clause usually defines default parameters for a group of peers, these parameters apply to all subsidiary peer subclauses. Any parameters from the peer subclause may be specified on the group clause to provide defaults for the whole group (which may be overridden for individual peers).
Within a group, BGP peers may be configured in one of two ways. They
may be explicitly configured with a peer statement, or implicitly
configured with the allow statement. Both are described
here:
| allow | The allow clause allows 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. |
| peer host | A peer clause configures an individual peer. Each peer inherits all parameters specified on a group as defaults. Those defaults may be overridden by parameters explicitly specified on the peer subclause. |
Within each group clause, individual peers can be specified or a group of potential peers can be specified using allow. Allow is used to specify a set of address masks. If the gated daemon receives a BGP connection request from any address in the set specified, it will accept it and set up a peer relationship.
The BGP peer subclause allows the following parameters, which can also be specified on the group clause. All are optional.
Note: The state option works with BGP, but does not provide true state transition information.
Packet tracing options (which may be modified with detail,
send, and recv):
| packets | All BGP packets. |
| open | BGP OPEN packets that are used to establish a peer relationship. |
| update | BGP UPDATE packets that are used to pass network reachability information. |
| keepalive | BGP KEEPALIVE packets that are used to verify peer reachability. |
icmp {
traceoptions trace_options ;
}
| traceoptions trace_options; | Specifies the tracing options for ICMP. (See Trace Statements and the ICMP specific tracing options below.) |
Packet tracing options (which may be modified with detail and
recv):
| packets | All ICMP packets received. |
| redirect | Only ICMP REDIRECT packets received. |
| routerdiscovery | Only ICMP ROUTER DISCOVERY packets received. |
| info | Only ICMP informational packets, which include mask request/response, info request/response, echo request/response, and time stamp request/response. |
| error | Only ICMP error packets, which include time exceeded, parameter problem, unreachable and source quench. |
The Simple Network Management Protocol (SNMP) is a not a routing protocol but a network management protocol. The snmp statement controls whether gated.conf tries to contact the SNMP Multiplexing daemon to register supported variables. The SNMP daemon, smuxd, must be run independently. The snmp statement only controls whether gated.conf keeps the management software apprised of its status.
gated.conf communicates with the SNMP daemon via the SMUX protocol that is described in RFC 1227.
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 | By default, the SMUX daemon listens for requests on port 199. The gated.conf subroutine can be configured to try to contact the SMUX daemon on a different port by explicitly specifying the port. |
| debug | Specifying this option enables debugging of the ISODE SMUX code. The default is debugging disabled. |
| traceoptions trace_options | Specifies the tracing options for SMUX. (See Trace Statements and the SMUX specific tracing options below.) |
There are no SNMP-specific trace options. 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. |
Static statements define the static routes used by the
gated daemon. 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 may be specified, each containing any number of static route
definitions. These routes can be overridden by routes with better
preference values.
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] ;
} ;
Parameters for static routes are:
| 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 | This option 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 | Normally the gated daemon removes all routes except interface routes from the kernel forwarding table during a graceful shutdown. The retain option may be used to prevent specific static routes from being removed. This is useful to insure that some routing is available when gated is not running. |
| reject | 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. Specifying this option causes this route to be installed as a reject route. 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 will not be installed in the kernel forwarding table when it is active, but it will still be eligible to be exported to other protocols. |
Importation of routes from routing protocols and installation of the routes in the gated daemon's routing database is controlled by import statements. The format of an import statement varies depending on the source protocol.
In all cases, one of two keywords may be specified to control how routes
compete with other protocols:
restrict
preference preference
| restrict | Specifies that the routes are not desired in the routing table. In some cases, this means that the routes are not installed in the routing table. In others, it means that they are installed with a negative preference; this prevents them from becoming active so they will not be installed in the forwarding table, or exported to other protocols. |
| preference preference | Specifies the preference value used when comparing this route to other routes from other protocols. The route with the lowest preference available at any given route becomes the active route, is installed in the forwarding table, and is eligible to be exported to other protocols. The default preferences are configured by the individual protocols. |
All the formats allow route filters as shown below. See the section on route filters for a detailed explanation of how they work. When no route filtering is specified (that is, when restrict is specified on the first line of a statement), all routes from the specified source will match that statement. If any filters are specified, only routes that match the specified filters will be imported. Put differently, if any filters are specified, an all restrict; is assumed at the end of the list.
network [ exact | refines ]
network mask mask [exact | refines ]
network masklen number [ exact | refines ]
default
host host
import proto bgp | EGP autonomoussystem autonomous_system
restrict ;
import proto bgp | EGP autonomoussystem autonomous_system
[ preference preference ] {
route_filter [ restrict | ( preference preference ) ] ;
} ;
import proto bgp aspath aspath_regexp
origin any | ( [ IGP ] [EGP ] [ incomplete ] )
restrict ;
import proto bgp aspath aspath_regexp
origin any | ( [ IGP ] [EGP ] [ incomplete ] )
[ preference preference ] {
route_filter [ restrict | ( preference preference ) ] ;
} ;
EGP importation may be controlled by autonomous system.
BGP also supports controlling propagation by the use of AS path regular expressions, which are documented in the section on Matching AS paths.
Note: EGP and BGP versions 2 and 3 only support the propagation of natural networks, so the host and default route filters are meaningless. BGP version 4 supports the propagation of any destination along with a contiguous network mask.
EGP and BGP both store any routes that were rejected implicitly by not being mentioned in a route filter, or explicitly with the restrict keyword in the routing table with a negative preference. A negative preference prevents a route from becoming active, which prevents it from being installed in the forwarding table, or exported to other protocols. This alleviates the need to break and re-establish a session upon reconfiguration if importation policy is changed.
import proto rip | hello | redirect
[ ( interface interface_list ) | (gateway gateway_list ) ]
restrict ;
import proto rip | hello | redirect
[ ( interface interface_list ) | (gateway gateway_list ) ]
[ preference preference ] {
route_filter [ restrict | ( preference preference ) ] ;
} ;
The importation of RIP, HELLO, and Redirect routes may be controlled by any of protocol, source interface, and source gateway. If more than one is specified, they are processed from most general (protocol) to most specific (gateway).
RIP and HELLO don't support the use of preference to choose between routes of the same protocol. That is left to the protocol metrics. These protocols do not save routes that were rejected since they have short update intervals.
import proto ospfase [ tag ospf_tag ] restrict ;
import proto ospfase [ tag ospf_tag ]
[ preference preference ] {
route_filter [ restrict | ( preference preference ) ] ;
} ;
Due to the nature of OSPF, only the importation of ASE routes may be controlled. OSPF intra- and inter-area routes are always imported into the gated routing table with a preference of 10. If a tag is specified, the import clause will only apply to routes with the specified tag.
It is only possible to restrict the importation of OSPF ASE routes when functioning as an AS border router. This is accomplished by specifying an export ospfase clause. Specification of an empty export clause may be used to restrict importation of ASEs when no ASEs are being exported.
Like the other interior protocols, preference can not be used to choose between OSPF ASE routes, that is done by the OSPF costs. Routes that are rejected by policy are stored in the table with a negative preference.
The import statement controls routes received from other systems that are used by the gated daemon, and the export statement controls which routes are advertised by the gated daemon to other systems. Like the import statement, the syntax of the export statement varies slightly per protocol. The syntax of the export statement is similar to the syntax of the import statement, and the meanings of many of the parameters are identical. The main difference between the two is that while route importation is just controlled by source information, route exportation is controlled by both destination and source.
The outer portion of a given export statement specifies the destination of the routing information you are controlling. The middle portion restricts the sources of importation that you wish to consider And the innermost portion is a route filter used to select individual routes.
The most specific specification of a metric is the one applied to the route being exported. The values that may be specified for a metric depend on the destination protocol that is referenced by this export statement.
restrict
metric metric
| restrict | Specifies that nothing should be exported. If specified on the destination portion of the export statement, it specifies that nothing at all should be exported to this destination. If specified on the source portion, it specifies that nothing from this source should be exported to this destination. If specified as part of a route filter, it specifies that the routes matching that filter should not be exported. |
| metric metric | Specifies the metric to be used when exporting to the specified destination. |
All the formats allow route filters as shown below. See the section on route filters for a detailed explanation of how they work. When no route filtering is specified (that is, when restrict is specified on the first line of a statement), all routes from the specified source will match that statement. If any filters are specified, only routes that match the specified filters will be exported. Put differently, if any filters are specified, an all restrict ; is assumed at the end of the list.
network [ exact | refines ]
network mask mask [exact | refines ]
network masklen number [ exact | refines ]
default
host host
As mentioned above, the syntax of the export statement varies depending on the protocol to which it is being applied. One thing that applies in all cases is the specification of a metric. All protocols define a default metric to be used for routes being exported, in most cases this can be overridden at several levels of the export statement.
The specification of the source of the routing information being exported (the export_list) is described below.
export proto bgp | EGP as autonomous system
restrict ;
export proto bgp | EGP as autonomous system
[ metric metric ] {
export_list ;
} ;
Exportation to EGP and BGP is controlled by autonomous system, the same policy is applied to all routers in the AS.
EGP metrics range from 0 to 255 inclusive with 0 being the most attractive.
BGP metrics are 16 bit unsigned quantities, that is, they range from 0 to 65535 inclusive with 0 being the most attractive.
If no export policy is specified, only routes to attached interfaces will be exported. If any policy is specified, the defaults are overridden. It is necessary to explicitly specify everything that should be exported.
Note: EGP and BGP versions 2 and 3 only support the propagation of natural networks, so the host and default route filters are meaningless. BGP version 4 supports the propagation of any destination along with a contiguous network mask.
export proto rip | hello
[ ( interface interface_list ) | (gateway gateway_list ) ]
restrict ;
export proto rip | hello
[ ( interface interface_list ) | (gateway gateway_list ) ]
[ metric metric ] {
export_list ;
} ;
Exportation to RIP and HELLO is controlled by any of protocol, interface or gateway. If more than one is specified, they are processed from the most general (protocol) to the most specific (gateway).
It is not possible to set metrics for exporting RIP routes into RIP, or exporting HELLO routes into HELLO. Attempts to do this are silently ignored.
If no export policy is specified, RIP and interface routes are exported into RIP and HELLO and interface routes are exported into HELLO. If any policy is specified, the defaults are overridden. It is necessary to explicitly specify everything that should be exports.
RIP version 1 and HELLO assume that all subnets of the shared network have the same subnet mask so they are only able to propagate subnets of that network. RIP version 2 removes that restriction and is capable of propagating all routes when not sending version 1 compatible updates.
To announce routes that specify a next hop of the loopback interface (that is, static and internally generated default routes) via RIP or HELLO, it is necessary to specify the metric at some level in the export clause. For example, just setting a default metric for RIP or HELLO is not sufficient. This is a safeguard to verify that the announcement is intended.
export proto osfpase [ type 1 | 2 ] [ tag ospf_tag ]
restrict ;
export proto osfpase [ type 1 | 2 ] [ tag ospf_tag ]
[ metric metric ] {
export_list ;
} ;
It is not possible to create OSPF intra- or inter-area routes by exporting routes from the the gated daemon routing table into OSPF. It is only possible to export from the gated daemon routing table into OSPF ASE routes. It is also not possible to control the propagation of OSPF routes within the OSPF protocol.
There are two types of OSPF ASE routes, type 1 and type 2. See the OSPF protocol configuration for a detailed explanation of the two types. The default type is specified by the defaults subclause of the ospf clause. This may be overridden by a specification on the export statement.
OSPF ASE routes also have the provision to carry a tag. This is an arbitrary 32 bit number that can be used on OSPF routers to filter routing information. See the OSPF protocol configuration for detailed information on OSPF tags. The default tag specified by the ospf defaults clause may be overridden by a tag specified on the export statement.
The export list specifies export based on the origin of a route and the syntax varies depending on the source.
proto bgp | EGP autonomoussystem autonomous_system
restrict ;
proto bgp | EGP autonomoussystem autonomous_system
[ metric metric ] {
route_filter [ restrict | ( metric metric ) ] ;
} ;
BGP and EGP routes may be specified by the source autonomous system. All routes may be exported by as path, see the Exporting by AS Path section for more information.
proto rip | hello
[ ( interface interface_list ) | (gateway gateway_list ) ]
restrict ;
proto rip | hello
[ ( interface interface_list ) | (gateway gateway_list ) ]
[ metric metric ] {
route_filter [ restrict | ( metric metric ) ] ;
} ;
RIP and HELLO routes may be exported by protocol, source interface, and/or source gateway.
proto ospf | ospfase restrict ;
proto ospf | ospfase [ metric metric ] {
route_filter [ restrict | ( metric metric ) ] ;
} ;
Both OSPF and OSPF ASE routes may be exported into other protocols. See below for information on exporting by tag.
proto direct | static | kernel
[ (interface interface_list ) ]
restrict ;
proto direct | static | kernel
[ (interface interface_list ) ]
[ metric metric ] {
route_filter [ restrict | ( metric metric ) ] ;
} ;
These protocols may be exported by protocol, or by the interface of the
next hop. These protocols are:
| direct | Routes to directly attached interfaces. |
| static | Static routes specified in a static clause. |
| kernel | Routes learned from the routing socket are installed in the gated routing table with a protocol of kernel. These routes may be exported by referencing this protocol. |
proto default | aggregate
restrict ;
proto default | aggregate
[ metric metric ] {
route_filter [ restrict | ( metric metric ) ] ;
} ;
These protocols may only be referenced by protocol.
| default | Refers to routes created by the gendefault option. It is recommended that route generation be used instead. |
| aggregate | Refers to routes synthesized from other routes when the aggregate and generate statements are used. See the section on Route Aggregation for more information. |
proto proto | all aspath aspath_regexp
origin any | ( [ IGP ] [EGP ] [ incomplete ] )
restrict ;
proto proto | all aspath aspath_regexp
origin any | ( [ IGP ] [EGP ] [ incomplete ] )
[ metric metric ] {
route_filter [ restrict | ( metric metric ) ] ;
} ;
When BGP is configured, all routes are assigned an AS path when they are added to the routing table. For all interior routes, this AS path specifies IGP as the origin and no ASEs in the AS path (the current AS is added when the route is exported). For EGP routes this AS path specifies EGP as the origin and the source AS as the AS path. For BGP routes, the AS path is stored as learned from BGP.
AS path regular expressions are documented in the section on Matching AS paths.
proto proto | all tag tag restrict ;
proto proto | all tag tag
[ metric metric ] {
route_filter [ restrict | ( metric metric ) ] ;
} ;
Both OSPF and RIP version 2 currently support tags; all other protocols always have a tag of zero. The source of exported routes may be selected based on this tag. This is useful when routes are classified by a tag when they are exported into a given routing protocol.
Route aggregation is a method of generating a more general route given the presence of a specific route. It is used, for example, at an autonomous system border to generate a route to a network to be advertised via EGP given the presence of one or more subnets of that network learned via RIP. No aggregation is performed unless explicitly requested in an aggregate statement.
Route aggregation is also used by regional and national networks to reduce the amount of routing information passed around. With careful allocation of network addresses to clients, regional networks can just announce one route to regional networks instead of hundreds.
Aggregate routes are not actually used for packet forwarding by the originator of the aggregate route, only by the receiver (if it wishes).
A slight variation of aggregation is the generation of a route based on the existence of certain conditions. This is sometimes known as the route of last resort. This route inherits the next hops and aspath from the contributor specified with the lowest (most favorable) preference. The most common usage for this is to generate a default based on the presence of a route from a peer on a neighboring backbone.
aggregate default
| ( network [ ( mask mask ) | ( masklen number ) ] )
[ preference preference ] [ brief ] {
proto [ all | direct | static | kernel | aggregate | proto ]
[ ( as autonomous system ) | ( tag tag )
| ( aspath aspath_regexp ) ]
restrict ;
proto [ all | direct | static | kernel | aggregate | proto ]
[ ( as autonomous system ) | ( tag tag )
| ( aspath aspath_regexp ) ]
[ preference preference ] {
route_filter [ restrict | ( preference preference ) ] ;
} ;
} ;
generate default
| ( network [ ( mask mask ) | ( masklen number ) ] )
[ preference preference ] {
[ ( as autonomous system ) | ( tag tag )
| ( aspath aspath_regexp ) ]
restrict ;
proto [ all | direct | static | kernel | aggregate | proto ]
[ ( as autonomous system ) | ( tag tag )
| ( aspath aspath_regexp ) ]
[ preference preference ] {
route_filter [ restrict | ( preference preference ) ] ;
} ;
} ;
Routes that match the route filters are called contributing
routes. They are ordered according to the aggregation preference that
applies to them. If there are more than one contributing routes with
the same aggregating preference, the route's own preferences are used to
order the routes. The preference of the aggregate route will be that of
contributing route with the lowest aggregate preference.
| preference preference | Specifies the preference to assign to the resulting aggregate route. The default preference is 130. |
| brief | Used to specify that the AS path should be truncated to the longest common AS path. The default is to build an AS path consisting of SETs and SEQUENCEs of all contributing AS paths. |
| proto proto | In addition to the special protocols listed, the contributing protocol may be chosen from among any of the ones supported (and currently configured into) gated. |
| as autonomous_system | Restrict selection of routes to those learned from the specified autonomous system. |
| tag tag | Restrict selection of routes to those with the specified tag. |
| aspath aspath_regexp | Restrict selection of routes to those that match the specified AS path. |
| restrict | Indicates that these routes are not to be considered as contributors of the specified aggregate. The specified protocol may be any of the protocols supported by the gated daemon. |
| route_filter | See the section on Route Filters for more detail. |
A route may only contribute to an aggregate route that is more general than itself; it must match the aggregate under its mask. Any given route may only contribute to one aggregate route, which will be the most specific configured, but an aggregate route may contribute to a more general aggregate.
All the formats allow route filters as shown below. See the section on route filters for a detailed explanation of how they work. When no route filtering is specified (that is, when restrict is specified on the first line of a statement), all routes from the specified source will match that statement. If any filters are specified, only routes that match the specified filters will be considered as contributors. Put differently, if any filters are specified, an all restrict ; is assumed at the end of the list.
network [ exact | refines ]
network mask mask [exact | refines ]
network masklen number [ exact | refines ]
default
host host
Preference is the value the gated daemon uses to order preference of routes from one protocol or peer over another. Preference can be set in the gated.conf configuration file in several different configuration statements.
Preference can be set based on network interface over another, from one protocol over another, or from one remote gateway over another.
Preference may not be used to control the selection of routes within an IGP, this is accomplished automatically by the protocol based on metric. Preference may be used to select routes from the same EGP learned from different peers or autonomous systems.
Each route has only one preference value associated with it, even though preference can be set at many places in the configuration file. Simply, the last or most specific preference value set for a route is the value used. The preference value is an arbitrarily assigned value used to determine the order of routes to the same destination in a single routing database. The active route is chosen by the lowest preference value.
Some protocols implement a second preference (preference2), sometimes refered to as a tie-breaker.
A default preference is assigned to each source from which the gated daemon receives routes. Preference values range from 0 to 255 with the lowest number indicating the most preferred route.
The following table summarizes the default preference values for routes learned in various ways. The table lists the statements (some of these are clauses within statements) that set preference, and shows the types of routes to which each statement applies. The default preference for each type of route is listed, and the table notes preference precedence between protocols. The narrower the scope of the statement, the higher precedence its preference value is given, but the smaller the set of routes it affects.
Preference Of Defined by Statement Default direct connnected networks interface 0 OSPF routes ospf 10 IS-IS level 1 routes isis level 1 15 IS-IS level 2 routes isis level 2 18 internally generated default gendefault 20 redirects redirect 30 routes learned via route socket kernel 40 static routes from config static 60 ANS SPF (SLSP) routes slsp 70 HELLO routes hello 90 RIP routes rip 100 point-to-point interface 110 routes to interfaces that are down interfaces 120 aggregate/generate routes aggregate/generate 130 OSPF AS external routes ospf 150 BGP routes bgp 170 EGP EGP 200
interfaces {
interface 138.66.12.2 preference 10 ;
} ;
rip yes {
preference 90 ;
} ;
import proto rip gateway 138.66.12.1 preference 75 ;
In these statements, the preference applicable to routes learned via RIP from gateway 138.66.12.1 is 75. The last preference applicable to routes learned via RIP from gateway 128.66.12.1 is defined in the accept statement. The preference applicable to other RIP routes is found in the rip statement. The preference set on the interface statement applies only to the route to that interface.
The Router Discovery Protocol is an IETF standard protocol used to inform hosts of the existence of routers. 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 that runs on hosts. The gated daemon treats these much like two separate protocols, only one of which may be enabled at a time.
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 default routers.
Initially, these Router Advertisements occur every few seconds, then fall back to every few minutes. In addition, a host may send a Router Solicitation to which the router will respond with a unicast Router Advertisement (unless a multicast or broadcast advertisement is due momentarily).
Each Router Advertisement contains an Advertisement Lifetime field indicating for how long the advertised addresses are valid. This lifetime is configured such that another Router Advertisement will be sent before the lifetime has expired. A lifetime of zero is used to indicate that one or more addresses are no longer valid.
The Router Advertisements are by default sent to the all-hosts multicast address 224.0.0.1. However, the use of broadcast may be specified. When Router Advertisements are being 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.
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]
;
} ] ;
Interface parameters are:
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.
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 may 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 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 will be deleted. The same will happen when a Router Advertisement is not received to refresh these routes before the lifetime expires.
routerdiscovery client yes | no | on | off [ {
traceoptions trace_options ;
preference preference ;
interface interface_list
[ enable ] | [ disable ]
[ broadcast ] | [ multicast ]
[ quiet ] | [ solicit ]
;
} ] ;
The Router Discovery Client and Server support the state trace
flag that traces various protocol occurrences.
| state | 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.
Routes are filtered by specifying configuration language that will match a certain set of routes by destination, or by destination and mask. Among other places, route filters are used on martians, import and export statements.
The action taken when no match is found is dependent on the context, for instance import and export route filters assume an all reject ; at the end of a list.
A route will match the most specific filter that applies. Specifying more than one filter with the same destination, mask and modifiers will generate an error.
network [ exact | refines ]
network mask mask [ exact | refines ]
network masklen number [ exact | refines ]
all
default
host host
These are all the possible formats for a route filter. Not all of these formats are available in all places, for instance the host and default formats are not valid for martians.
In most cases it is possible to specify additional parameters relevent to the context of the filter. For example, on a martian statement it is possible to specify the allow keyword, on an import statement you can specify a preference, and on a export you can specify a metric.
If no additional parameters are specified, any destination that falls in the range given by the network and mask is matched, the mask of the destination is ignored. If a natural network is specified, the network, any subnets, and any hosts will be match. The two optional modifiers cause the mask of the destination to be considered also:
0.0.0.0 mask 0.0.0.0
0.0.0.0 mask 0.0.0.0 exact
host mask 255.255.255 exact
An AS path is a list of autonomous_systems that routing information has passed through to get to this router, and an indicator of the origin of the AS path. This information can be used to prefer one path to a destination network over another. The primary method for doing this with gated.conf is to specify a list of patterns to be applied to AS paths when importing and exporting routes.
Each autonomous system that a route passed through prepends its AS number to the beginning of the AS path.
The origin information details the completeness of AS path information. An origin of IGP indicates the route was learned from an interior routing protocol and is most likely complete. An origin of EGP indicates the route was learned from an exterior routing protocol that does not support AS paths (EGP, for example) and the path is most likely not complete. When the path information is definitely not complete, an origin of incomplete is used.
AS path regular expressions are defined in RFC 1164 section 4.2.
An AS path is matched using the following syntax:
aspath aspath_regexp origin any | ( [IGP] [EGP] [incomplete] )
This specifies that an AS matching the aspath_regexp with the specified origin is matched.
Technically, an AS path regular expression is a regular expression with the alphabet being the set of AS numbers. An AS path regular expression is composed of one or more AS paths expressions. An AS path expressions is composed of AS path terms and AS path operators.
An AS path term is one of the following three objects:
autonomous_system . ( aspath_regexp )
| autonomous_system | Is any valid autonomous system number, from one through 65534 inclusive. |
| . | Matches any autonomous system number. |
| ( aspath_regexp ) | Contains parentheses group subexpressions--an operator, such as * or ? works on a single element or on a regular expression enclosed in parentheses. |
An AS path operator is one of the following:
aspath_term {m,n}
aspath_term {m}
aspath_term {m,}
aspath_term *
aspath_term +
aspath_term ?
aspath_term | aspath_term
| aspath_term {m,n} | a regular expression followed by {m,n} (where m and n are both non-negative integers and m <= n) means at least m and at most n repetitions. |
| aspath_term {m} | a regular expression followed by {m} (where m is a positive integer) means exactly m repetitions. |
| aspath_term {m,} | a regular expression followed by {m,} (where m is a positive integer) means m or more repetitions. |
| aspath_term * | an AS path term followed by * means zero or more repetitions. This is shorthand for {0,}. |
| aspath_term + | a regular expression followed by + means one or more repetitions. This is shorthand for {1,}. |
| aspath_term ? | a regular expression followed by ? means zero or one repetition. This is shorthand for {0,1}. |
| aspath_term | aspath_term | matches the AS term on the left, or the AS term on the right. |