Content-type: text/html Man page of gated.proto

gated.proto

Section: Devices and Network Interfaces (4)
Index Return to Main Contents
 

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 and exterior protocols. The gated software combines management of the interior and exterior routing protocols in one software daemon.  

Interior Routing Protocols

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: 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 1388. HELLO uses delay as the deciding factor in choosing the best route. Round-trip time is the length of time it takes a datagram to travel from the source and destination. HELLO is historically significant for the Internet as it was the protocol used among the original prototype NSFNET backbone fuzzball gateways. Today, like fuzzballs, HELLO is a little-used protocol.
An earlier version of the HELLO protocol is described in RFC 891. 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 1583; the MIB is defined in RFC 1253. 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: 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. 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. The version 3 MIB is described in RFC 1269. The documents RFC 1164 and RFC 1268 describe the application of version 2 and 3 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. And finally, RFC 1403 describes BGP - OSPF interaction.
 

Other Routing Protocols

The following routing protocol is also supported: The Router Discovery protocol is used to inform hosts of the availability of hosts it can send packets to and is used to supplement a statically configured default router. This is the preferred protocol for hosts to run, they are discouraged from wiretapping routing protocols.

Router Discovery is described in RFC 1256.
 

Routing Information Protocol (RIP)

One of the most widely used interior gateway protocols is the Routing Information Protocol (RIP). RIP is an implementation of a distance-vector, or Bellman-Ford routing protocol for local networks. It 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: 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. 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 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 is still experimental and might change in incompatible ways in future releases. This 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-I and network masks

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.  

Syntax

rip yes | no | on | off [ {
    broadcast ;
    nobroadcast ;
    nocheckzero ;
    preference preference ;
    defaultmetric metric ;
    query authentication [none | [[simple|md5] password]] ;
    interface interface_list
        [noripin] | [ripin]
        [noripout] | [ripout]
        [metricin metric]
        [metricout metric]
        [version 1]|[version 2 [multicast|broadcast]]
        [[secondary] authentication [none | [[simple|md5] password]] ;
    trustedgateways gateway_list ;
    sourcegateways gateway_list ;
    traceoptions trace_options ; } ] ;

The rip statement enables or disables RIP. If the rip statement is not specified the default is rip on;. If enabled, RIP assumes nobroadcast when there is only one interface and broadcast when there is more than one. The following rip options are supported: Specifies that RIP 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. 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. 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. 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. 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. Specifies the authentication required of query packets that do not originate from routers. The default is none. Controls various attributes of sending RIP on specific interfaces. See the Interface Lists section in gated.conf(4) for the description of the interface_list.

Note that if there are multiple interfaces configured on the same subnet, RIP updates are sent from first one on which RIP output is configured.
The following interface parameters are supported: Specifies that RIP packets received via the specified interface are ignored. The default is to listen to RIP packets on all non-loopback interfaces. This is the default. This argument might be necessary when noripin is used on a wild card interface descriptor. 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. 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. 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. 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. Specifies that RIP packets sent via the specified interface(s) are version 1 packets. This is the default. 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. Specifies that RIP version 2 packets should be multicast on this interface. This is the default. Specifies that RIP version 1-compatible version 2 packets should be broadcast on this interface, even if IP multicast is available. Defines the authentication type to use. It applies only to RIP version 2 and is ignored for RIP-1 packets. The default authentication type is none. If a password is specified, the authentication type defaults to simple. The password should be a quoted string with between 0 and 16 characters.
If secondary is specified, this defines the secondary authentication. If omitted, the primary authentication is specified. The default is primary authentication of none and no secondary authentication. Defines the list of gateways from which RIP will accept updates. The gateway_list is a list of host names or IP addresses. By default, all routers on the shared network are trusted to supply routing information. But if the trustedgateways clause is specified, only updates from the gateways in the list are accepted. Defines a list of routers to which RIP sends packets directly, not through multicast or broadcast. This can be used to send different routing information to specific gateways. Updates to gateways in this list are not affected by noripout on the interface. Specifies the tracing options for RIP. (See the Trace Options Statement section in gated.conf(4) and the RIP-specific tracing options that follow.)
 

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: All RIP packets. RIP information request packets, such as REQUEST, POLL and POLLENTRY RIP RESPONSE packets, which is the type of packet that actually contains routing information. Any other type of packet. The only valid ones are TRACE_ON and TRACE_OFF both of which are ignored.  

The Hello Protocol

Unless you have a specific need for the HELLO protocol, do not use it. Support for it might be dropped in the future.

The HELLO protocol is an interior protocol that uses a routing metric based on the length of time it takes a packet to make the trip between the source and the destination. HELLO packets carry timestamp information that allows receivers to compute the shortest delay paths to destinations. The best route is the route with the shortest time delay. The unit of time used in HELLO is milliseconds. If a HELLO update packet takes less than 100 milliseconds to travel between two routers, a minimum value of 100 is used for that hop. Thus on networks built of high-speed interfaces, HELLO defaults to using hop counts. As in any routing algorithm, HELLO cannot change routes too rapidly or it would be unstable. To avoid instabilities, implementations of HELLO build in hysteresis and hesitate to change routes until they have confidence that the change will be lasting.

By default, HELLO, like RIP, uses the kernel interface metric set by the ifconfig command to influence metric added to routes as they are installed in the routing table (metricin). Since the kernel interface metric is in hops, it must be translated into HELLOs millisecond metric. In order to do that, the following table is used:


   Hops    HELLO metric
     0          0
     1        100
     2        148
     3        219
     4        325
     5        481
     6        713
     7       1057
     8       1567
     9       2322
    10       3440
    11       5097
    12       7552
    13      11190
    14      16579
    15      24564
    16      30000  

HELLO and network masks

HELLO 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.  

Syntax

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 assumes nobroadcast when there is only one interface and broadcast when there is more than one interface. The following parameters are supported: Specifies that HELLO packets are 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. Specifies that HELLO packets are not broadcast on attached interfaces, even if there are more than one. If a sourcegateways clause is present, routes are still unicast directly to that gateway. Sets the preference for routes learned from HELLO. The default preference is op. This preference can be overridden by a preference specified in import policy. Defines the metric used when advertising routes via HELLO that 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 can be overridden by a metric specified in export policy. Controls various attributes of sending HELLO on specific interfaces. See the Interface List section in gated.conf(4) for the description of the interface_list.

Note that if there are multiple interfaces configured on the same subnet, HELLO updates are sent only from first one on which HELLO output is configured. This limitation is required because of the way the UNIX kernel operates. It will hopefully be removed in a future release. The following parameters are supported: Specifies that HELLO packets received via the specified interface be ignored. The default is to listen to HELLO on all non-loopback interfaces. This is the default. This argument might be necessary when nohelloin is used on a wild card interface descriptor. Specifies that no HELLO packets are sent on the specified interfaces. The default is to send HELLO on all broadcast and non-broadcast interfaces when in broadcast mode. The sending of HELLO on point-to-point interfaces must be manually configured. This is the default. This argument is necessary when it is desired to send HELLO on point-to-point interfaces and might be necessary when nohelloin is used on a wild card interface descriptor. Specifies the HELLO 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 HELLO 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 HELLO routes learned via the specified interface(s) less than HELLO routes from other interfaces. Specifies the HELLO 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 HELLO routes over this router. 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. 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. Specifies the tracing options for HELLO. (See the Trace Options Statement section in gated.conf(4) and the HELLO specific tracing options that follow.)

The default preference is 90. The default metric is 30000.  

Tracing options

The policy option logs information 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: All HELLO packets  

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 area. This enables some areas to use much stricter authentication than others. There are two authentication schemes available. The first uses a simple authentication key of up to 8 characters and is standardized. The second is still experimental and uses the MD5 algorithm and an authentication key of up to 16 characters.

The simple password provides very little protection because in many cases it is possible to easily capture packets from the network and learn the authentication key. The experimental MD5 algorithm provides much more protection as it does not include the authentication key in the packet.

The OSPF specification currently specifies that the authentication type be configured per area with the ability to configure separate passwords per interface. This has been extended to allow the configuration of different authentication types and keys per interface. In addition it is possible to specify both a primary and a secondary authentication type and key on each interface. Outgoing packets use the primary authentication type, but incoming packets can match either the primary or secondary authentication type and key.  

Syntax

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
       } ;
    } ; } ] ;
Specify the defaults used when importing OSPF ASE routes into the gated routing table and exporting routes from the gated routing table into OSPF ASEs. The preference is used to determine how OSPF routes compete with routes from other protocols in the gated routing table. The default value is 150. The cost is used when exporting a non-OSPF route from the gated routing table into OSPF as an ASE. The default value is 1. This can be explicitly overridden in export policy. OSPF ASE routes have a 32-bit tag field that is not used by the OSPF protocol, but might be used by export 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. 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. 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. Specifies how often a batch of ASE link state advertisements are generated and flooded into OSPF. The default is once per second. Specifies how many ASEs are generated and flooded in each batch. The default is 100. Specifies the tracing options for OSPF. (See gated.conf(4) and the OSPF tracing options section.) 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. 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. OSPF specifies an authentication scheme per area. Each interface in the area must use this same authentication scheme although it can use a different authenticationkey. The currently valid values are none (0) for no authentication or simple (1) for simple password authentication. A stub area is one in which there are no ASE routes. If a cost is specified, this injects a default route into the area with the specified cost. The networks list describes the scope of an area. Intra-area LSAs that fall within the specified ranges are not advertised into other areas as inter-area routes. Instead, the specified ranges are advertised as summary 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. 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. 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. The following interface parameters are common to all types of interfaces: The number of seconds between link state advertisement retransmissions for adjacencies belonging to this interface. The estimated number of seconds required to transmit a link state update over this interface. The transitdelay parameter takes into account transmission and propagation delays and must be greater than 0. A number between 0 and 255 specifying the priority for becoming the designated router on this interface. When two routers attached to a network both attempt to become designated router, the one with the highest priority wins. A router whose router priority is set to 0 is ineligible to become designated router. The length of time, in seconds, between Hello packets that the router sends on the interface. 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. 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.
Point-to-point interfaces also support the following parameter: 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. This form of the interface clause is used to specify a nonbroadcast interface on a non-broadcast multi-access (NBMA) medium. Since an OSPF broadcast medium must support IP multicasting, a broadcast capable medium, such as Ethernet, 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: Before adjacency is established with a neighbor, OSPF packets are sent periodically at the specified poll interval. By definition, it is not possible to send broadcast packets to discover OSPF neighbors on a non-broadcast, so all neighbors must be configured. The list includes one or more neighbors and an indication of their eligibility to become a designated router. 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.
 

Tracing options

In addition to the following OSPF specific trace flags, OSPF supports the state that traces interface and neighbor state machine transitions. Link State Advertisement creation Shortest Path First (SPF) calculations Link State Advertisement (LSA) transmission LSA reception State transitions The following packet tracing options, which can be modified with detail, send, and recv, are supported: OSPF HELLO packets, which are used to determine neighbor reachability. OSPF Database Description packets, which are used in synchronizing OSPF databases. OSPF Link State Request packets, which are used in synchronizing OSPF databases. OSPF Link State Update packets, which are used in synchronizing OSPF databases. OSPF Link State Ack packets, which are used in 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.  

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
            [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]
            ;
    } ; } ] ;

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. 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. Defines the expected maximum size of a packet that EGP expects to receive from this neighbor. If a packet larger than this value is received, it is incomplete and is discarded. The length of this packet is noted and the expected size is increased to be able to receive a packet of this size. Specifying the parameter here prevents the first packet from being dropped. If not specified, the default size is 8192 bytes. All packet sizes are rounded up to a multiple of the system page size. Specifies the tracing options for EGP. By default these are inherited from the global trace options. These values can be 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.) 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: Identifies the autonomous system number expected from peers in the group. If not specified, it is learned dynamically. 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. Specifies the number of neighbors gated should acquire from this group. The default is to acquire all of the neighbors in the group. The gated daemon attempts to acquire the first maxup neighbors in the order listed. If one of the first neighbors is not available, it acquires one farther down the list. If after start-up gated does manage to acquire the more desirable neighbor, it drops the less desirable one. Each neighbor subclause defines one EGP neighbor within a group. The only part of the subclause that is required is the neighbor_address argument, which is the symbolic host name or IP address of the neighbor. The following parameters are optional: Specifies the preference used for routes learned from these neighbors. This can differ from the default EGP preference set in the egp statement, so that gated can prefer routes from one neighbor, or group of neighbors, over another. This preference can be explicitly overriden by import policy. In the case of a preference tie, the second preference, preference2, can be used to break the tie. The default value is 0. Defines a metric to be used for all routes sent to this neighbor. The value 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. 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. 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. Enables gated to include the default route (0.0.0.0) in EGP updates sent to this EGP neighbor. This allows the system to advertise the default route via EGP. Normally a default route is not included in EGP updates. If a network is not shared with a neighbor, gateway specifies a router on an attached network to be used as the next hop router for routes received from this neighbor. This option is rarely used. 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. 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. 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. 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. By default, gated sets the IP TTL for local neighbors to one and the TTL for non-local neighbors to 255. This option is provided when attempting to communicate with improperly functioning routers that ignore packets sent with a TTL of one. Specifies the tracing options for this EGP neighbor. By default these are inherited from group or EGP global trace options. (See the Trace Options Statement section in gated.conf(4) and the EGP tracing options that follow.)
 

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: All EGP packets EGP HELLO/I-HEARD-U packets, which are used to determine neighbor reachability. EGP ACQUIRE/CEASE packets, which are used to initiate and terminate EGP sessions. 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: Type internal groups expect all peers to be directly attached to a shared subnet so that, like external peers, the next hops received in BGP advertisements can be used directly for forwarding. Type routing groups determine the immediate next hops for routes by using the next hop received with a route from a peer as a forwarding address, and using this to look up an immediate next hop in an IGP's routes. Such groups support distant peers, but need to be informed of the IGP whose routes they are using to determine immediate next hops. Type igp groups expect routes from the group peers to not be used for forwarding at all. Instead, they expect that copies of the BGP routes received will also be received via an IGP, and that the BGP routes will only be used to determine the path attributes associated with the IGP routes. Such groups also support distant peers, and also need to be informed of the IGP they are running with.

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.  

Syntax

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]
          [sendbuffer number]
          [recvbuffer number]
          [indelay time]
          [outdelay time]
          [keep [all | none]]
          [analretentive]
          [noauthcheck]
          [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 to not send a metric.

The following options are supported: Sets the preference for routes learned from RIP. The default preference is 170. This preference can be overridden by a preference specified on the group or peer statements or by import policy. Defines the metric used when advertising routes via BGP. If not specified, no metric is propagated. This metric can be overridden by a metric specified on the neighbor or group statements or in export policy. Specifies the tracing options for BGP. By default, these are inherited from the global trace options. These 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.)

 

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: In the classic external BGP group, full policy checking is applied to all incoming and outgoing advertisements. The external neighbors must be directly reachable through one of the machine's local interfaces. By default, no metric is included in external advertisements, and the next hop is computed with respect to the shared interface. An internal group operating where there is no IP-level IGP, for example an SMDS network or MILNET. All neighbors in this group are required to be directly reachable via a single interface. All next hop information is computed with respect to this interface. Import and export policy can be applied to group advertisements. Routes received from external BGP or EGP neighbors are by default readvertised with the received metric. An internal group that runs in association with an interior protocol. The IGP group examines routes that the IGP is exporting and sends an advertisement only if the path attributes could not be entirely represented in the IGP tag mechanism. Only the AS path, path origin, and transitive optional attributes are sent with routes. No metric is sent, and the next hop is set to the local address used by the connection.

Received internal BGP routes are not used or readvertised. Instead, the AS path information is attached to the corresponding IGP route and the latter is used for readvertisement. Since internal IGP peers are sent only a subset of the routes that the IGP is exporting, the export policy used is the IGP's. There is no need to implement the "don't routes from peers in the same group" constraint since the advertised routes are routes that IGP already exports. 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. 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.

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. Any 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.

Specifying peers

Within a group, BGP peers can be configured in either of the following ways: explicitly with a peer statement or implicitly with the allow statement. A description of each is as follows: Configures an 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. 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.

Peer parameters

The BGP peer subclause allows the following optional parameters, which can also be specified on the group clause: 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. 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. 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. 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. Specifies the preference used for routes learned from these peers. This can differ from the default BGP preference set in the bgp statement, so that gated can prefer routes from one peer, or group of peers, over others. This preference can be explicitly overriden by import policy. In the case of a preference tie, the second preference, preference2 can be used to break the tie. The default value is 0. 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. 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. 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. 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. Control the amount of send and receive buffering asked of the kernel. The maximum supported is 65535 bytes, although many kernels have a lower limit. By default, gated configures the maximum supported. These parameters are not needed on normally functioning systems. Used to dampen route fluctuations. The indelay parameter specifies the amount of time a route learned from a BGP peer must be stable before it is accepted into the gated routing database. The outdelay parameter specifies the amount of time a route must be present in the gated routing database before it is exported to BGP. The default value for each is 0, meaning that these features are disabled. Used to retain routes learned from a peer even if the routes' AS paths contain one of our exported AS numbers. Causes gated to issue warning messages when receiving questionable BGP updates such as duplicate routes or deletions of non-existing routes. Normally these events are ignored. 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. 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. 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. 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. 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. Causes a message to be logged via the syslog mechanism whenever a BGP peer enters or leaves the ESTABLISHED state. 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. 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.)
 

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: All BGP packets BGP OPEN packets, which are used to establish a peer relationship. BGP UPDATE packets, which are used to pass network reachability information. BGP KEEPALIVE packets, which are used to verify peer reachability.  

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.  

Syntax

icmp {
    traceoptions trace_options ; } Specifies the tracing options for ICMP. (See the Trace Options Statement section in gated.conf(4) and the ICMP tracing options that follow.)  

Tracing options

The following packet tracing options, which can be modified with detail and recv, are supported: All ICMP packets received. Only ICMP REDIRECT packets received. Only ICMP ROUTER DISCOVERY packets received. Only ICMP informational packets, which include mask request/response, info request/response, echo request/response and time stamp request/response. 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, HELLO, or OSPF). It is impossible to enable redirects once they have been automatically disabled. Listening to RIP or HELLO 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.  

Syntax

redirect yes | no | on | off [{
    preference preference ;
    interface interface_list
        [noredirects] | [redirects] ;
    trustedgateways gateway_list ;
    traceoptions trace_options ; }] ; Sets the preference for a route learned from a redirect. The default is 30. The interface statement allows the enabling and disabling of redirects on an interface-by-interface basis. See the Interface List section in gated.conf(4) for the description of the interface_list. The following parameters are supported: Specifies that redirects received via the specified interface are ignored. The default is to accept redirects on all interfaces. This is the default. This argument might be necessary when noredirects is used on a wild card interface descriptor. Defines the list of gateways from which redirects are accepted. The gateway_list is simply a list of host names or addresses. By default, all routers on the shared network(s) are trusted to supply redirects. But if the trustedgateways clause is specified, only redirects from the gateways in the list are accepted. There are no redirect-specific tracing options. All non-error messages are traced under the normal class.  

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.  

Syntax

routerdiscovery server yes | no | on | off [{
    traceoptions trace_options ;
    interface interface_list
        [minadvinterval time]
        [maxadvinterval time]
        [lifetime time]
        ;
    address interface_list
        [advertise] | [ignore]
        [broadcast] | [multicast]
        [ineligible] | [preference preference]
        ; }] ; Specifies the Router Discovery tracing options. (See Trace Options Statement section in gated.conf(4) and the Router Discovery specific tracing options.) Specifies the parameters that apply to physical interfaces. Note a slight difference in convention from the rest of gated: interface specifies just physical interfaces (such as le0, ef0 and en1), while address specifies protocol (in this case, IP) addresses.

The following interface parameters are supported: The maximum time allowed between sending broadcast or multicast Router Advertisements from the interface. Must be no less than 4 and no more than 30:00 (30 minutes or 1800 seconds). The default is 10:00 (10 minutes or 600 seconds). The minimum time allowed between sending unsolicited broadcast or multicast Router Advertisements from the interface. Must be no less than 3 seconds and no greater than maxadvinterval. The default is 0.75 * maxadvinterval. 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. 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. Specifies that the specified address(es) are included in Router Advertisements. This is the default. Specifies that the specified address(es) are not included in Router Advertisements. Specifies that the given address(es) are included in a broadcast Router Advertisement because this system does not support IP multicasting, or some hosts on attached 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. 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. 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. 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.  

Syntax

routerdiscovery client yes | no | on | off [{
    traceoptions trace_options ;
    preference preference ;
    interface interface_list
   [enable] | [disable]
   [broadcast] | [multicast]
   [quiet] | [solicit]
   ; }] ; Specifies the tracing options for OSPF. (See the Trace Options Statement section in gated.conf(4) and the OSPF-specific tracing options that follow.) Specifies the preference of all Router Discovery default routes. The default is 55. 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. Specifies that Router Discovery should be performed on the specified interface(s). This is the default. Specifies that Router Discovery should not be performed on the specified interface(s). Specifies that Router 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. Specifies that Router Solicitations should be multicast on the specified interface(s). If IP multicast is not available on this host and interface, no solicitation is performed. The default is to multicast Router Solicitations if the host and interface support it; otherwise, Router Solicitations are broadcast. Specifies that no Router Solicitations are sent on this interface, even though Router Discovery is performed. Specifies that initial Router Solicitations are sent on this interface. This is the default.  

Tracing options

The Router Discovery Client and Server support the state trace flag, which traces various protocol occurrences. 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.  

Syntax

snmp yes | no | on | off [{
    port port ;
    debug ;
    traceoptions traceoptions ; }] ;

Reporting is enabled by specifying yes or on and disabled with no or off. The default is on. Specifies that gated try to contact the SMUX daemon on a port other than the default port. By default, the SMUX daemon listens for requests on port 199. Enables debugging of the ISODE SMUX code. The default is debugging disabled. Specifies the tracing options for SMUX. (See the Trace Options Statement section in gated.conf(4) and the SMUX tracing options that follow.)  

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. SNMP requests received from the SMUX daemon and the associated responses. Protocol requests to register variables. Protocol requests to resolve variable names. SNMP trap requests from protocols.  

The Kernel Statement

While the kernel interface is not technically a routing protocol, it has many characteristics of one, and gated treats it like a routing protocol. The routes gated chooses to install in the kernel forwarding table are those that are used by the kernel to forward packets.

The add, delete and change operations gated must use to update the 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: 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. The gated daemon is able to update the kernel forwarding table, but it is not aware of other modifications of the forwarding table. The gated daemon is able to listen to ICMP messages and determine how the kernel has updated the forwarding table in response to ICMP redirects. The gated daemon is not able to detect changes to the forwarding table resulting from the use of the the route command by the system administrator. Use of the route command on systems that use the ioctl() interface is strongly discouraged while gated is running. In all known implementations, there is no change operation supported. To change a route that exists in the kernel, the route must be deleted and a new one added.  

Updating the Forwarding Table with the routing socket interface

The routing socket interface to the kernel forwarding table was 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: The network mask is passed to the kernel explicitly. This allows different masks to be used on subnets of the same network. It also allows routes with masks that are more general than the natural mask to be used. This is known as classless routing. Not only is gated able to change the kernel 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. 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. 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. 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 Digital 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: Instead of forwarding a packet like a normal route, routes with RTF_REJECT cause packets to be dropped and unreachable messages to be sent to the packet originators. This flag is valid only on routes pointing at the loopback interface. Like the RTF_REJECT flag, routes with RTF_BLACKHOLE cause packets to be dropped, but unreachable messages are not sent. This flag is valid only on routes pointing at the loopback interface. 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.
 

Syntax

kernel {
    options
        [nochange]
        [noflushatexit]
        [remnantholdtime time]
        ;
    routes number ;
    flash
        [limit number]
        [type interface | interior | all]
        ;
    background
        [limit number]
        [priority flash | higher | lower]
        ;
    traceoptions trace_options ; } ; Configures kernel options. The following options are valid: On systems supporting the routing socket, this insures that changes operations are not performed, only deletes and adds. This is useful on early versions of the routing socket code where the change operation was broken. During normal shutdown 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. Normally remnant routes read from the kernel forwarding table at startup expire in three minutes or as soon as they are overridden. This option allows the interval to be configured to a value between zero and 15 minutes. Setting it to zero deletes these routes immediately. 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. 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: 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. 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. 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: Specifies the number of routes that can be processed at during one batch. The default is 120. Specifies the priority of the processing of batches of kernel updates in relationship to the flash update processing. The default is lower, which means that flash updates are processed first. To process kernel updates at the same priority as flash updates, specify flash; to process them at a lower priority, use lower.
 

Tracing options

While the kernel interface is not a routing protocol, in many cases it is handled as one. The following two symbols make sense when entered from the command line since the code that uses them is executed before the trace file is parsed.

Symbols read from the kernel, by nlist(), or similar interface. 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. Routes read from the kernel when gated starts. Requests by gated to Add/Delete/Change routes in the kernel forwarding table.

The following general option and packet-tracing options only apply on systems that use the routing socket to exchange routing information with the kernel. They do not apply on systems that use the old BSD4.3 ioctl() interface to the kernel. Informational messages received from the routing socket, such as TCP loss, routing lookup failure, and route resolution requests. The gated daemon does not currently do processing on these messages, just logs the information if requested.

The following packet tracing options, which can be modified with detail, send, and recv, are supported: Routes exchanged with the kernel, including Add/Delete/Change messages and Add/Delete/Change messages received from other processes. Redirect messages received from the kernel. Interface status messages received from the kernel. These are only supported on systems with networking code derived from BSD 4.4. Other messages received from the kernel, including those mentioned in the info type above.  

Static 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.  

Syntax

static {
    (host host) | default |
    (network [(mask mask) | (masklen number)])
        gateway gateway_list
        [interface interface_list]
        [preference preference]
        [retain]
        [reject]
        [blackhole]
        [noinstall] ;
    (network [(mask mask) | (masklen number)])
        interface interface
        [preference preference]
        [retain]
        [reject]
        [blackhole]
        [noinstall] ; } ; This is the most general form of the static statement. It defines a static route through one or more gateways. Static routes are installed when one or more of the gateways listed are available on directly attached interfaces. If more than one eligible gateways are available, they are limited by the number of multipath destinations supported (this compile time parameter is currently almost always one on Unix).

The following parameters for static routes are supported: When this parameter is specified, gateways are only considered valid when they are on one of these interfaces. See the section on interface list specification for the description of the interface_list. Selects the preference of this static route. The preference controls how this route competes with routes from other protocols. The default preference is 60. Prevents 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. Installs this route as a reject route. Instead of forwarding a packet like a normal route, reject routes cause packets to be dropped and unreachable messages to be sent to the packet originators. Not all kernel forwarding engines support reject routes. A blackhole route is the same as a reject route except that unreachable messages are not supported. Normally, the route with the lowest preference is installed in the kernel forwarding table and is the route exported to other protocols. When 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. 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. delim off


 

Index

NAME
DESCRIPTION
Interior Routing Protocols
Exterior Routing Protocols
Other Routing Protocols
Routing Information Protocol (RIP)
RIP-I and network masks
Syntax
Tracing options
The Hello Protocol
HELLO and network masks
Syntax
Tracing options
The OSPF Protocol
Authentication
Syntax
Tracing options
The Exterior Gateway Protocol (EGP)
Syntax
Tracing options
The BGP Protocol Statement
Syntax
Groups
Tracing options
The ICMP Statement
Syntax
Tracing options
Redirect Statement
Syntax
Tracing options
The Router Discovery Protocol
The Router Discovery Server
Syntax
The Router Discovery Client
Syntax
Tracing options
The SNMP Statement
Syntax
Tracing options
The Kernel Statement
Forwarding tables and Routing tables
Updating the Forwarding Table
Updating the Forwarding Table with the ioctl interface
Updating the Forwarding Table with the routing socket interface
Reading the Forwarding Table
Reading the interface list
Syntax
Tracing options
Static Statements
Syntax
RELATED INFORMATION

This document was created by man2html, using the manual pages.
Time: 02:40:02 GMT, October 02, 2010