gated.conf(4)

sets the directory for include files.

includes a file into gated.conf.

specifies which events are traced.

defines GateD options.

defines GateD interfaces.

defines the AS number.

defines the originating router (BGP, OSPF).

defines invalid destination addresses.

enables RIP protocol.

enables HELLO protocol.

enables ISIS protocol.

configures kernel interface options.

enables OSPF protocol.

enables EGP protocol.

enables BGP protocol.

configures the processing of ICMP redirects.

configures the processing of general ICMP packets.

defines static routes.

defines which routes to import.

defines which routes to export.

defines which routes to aggregate.

defines which routes to generate.

Trace the lexical analyzer and parser. Mostly used by GateD developers for debugging.

Trace the allocation of and freeing of policy blocks. Mostly used by the GateD developers for debugging.

Used to trace symbols read from the kernel at startup. The only useful way to specify this level of tracing is via the -t option on the command line since the symbols are read from the kernel before parsing the configuration file.

Used to trace the reading of the kernel interface list. It is useful to specify this with the -t option on the command line since the first interface scan is done before reading the configuration file.

Turn on all of the following.

A shorthand notation for specifying both normal and route.

Trace state machine transitions in the protocols.

Trace normal protocols occurrences. Abnormal protocol occurrences are always traced.

Trace application of protocol and user-specified policy to routes being imported and exported.

Trace system interface and processing associated with this protocol or peer.

Trace timer usage by this protocol or peer.

Trace routing table changes for routes installed by this protocol or peer.

detail must be specified before send or recv. Normally packets are traced in a terse form of one or two lines. When detail is specified, a more verbose format is used to provide further detail on the contents of the packet.

These options limit the tracing to packets sent or received. Without these options both sent and received packets will be traced.

Specifies the file to receive tracing information. If this file name does not begin with a slash (/), the directory where gated was started in prepended to the name.

Tracing should start by replacing an existing file. The default is to append to an existing file.

Limit the maximum size of the trace file to the specified size (minimum 10k). When the trace file reaches the specified size, it is renamed to file.0, then file.1, file.2 up to the maximum number of files (minimum specification is 2).

Specifies options that control the appearance of tracing. Valid values are:

Used to enable a broad class of tracing and then disable more specific options.

Specifies that all tracing should be turned off for this protocol or peer.

Allows configuration of some global options related to interfaces. These are:

Sets interface options on the specified interfaces. An interface list is all or a list of interface names (see warning about interface names), domain names, or numeric addresses. Options available on this statement are:

Defines interfaces that might not be present when GateD is started so they may be referenced in the configuration file when strictinterfaces is defined. Possible define keywords are:

An interface not defined as broadcast or point-to-point is assumed to be nonbroadcast multiaccess (NBMA), such as an X.25 network.

This refers to all available interfaces.

This refers to all the interfaces of the same type. Unix interfaces consist of the name of the device driver, like ie, and a unit number, like 0, 5 or 22. Reference to the name contain only alphabetic characters and match any interfaces that have the same alphabetic part.

For example, ie on a Sun would refer to all Interlan Ethernet interfaces, le would refer to all Lance Ethernet interfaces. But ie would not match iel0.

This refers to a specific interface, usually one physical interface. These are specified as an alphabetic part followed by a numeric part. This will match one specific interface. But be aware that on many systems, there can be more than one protocol (IP) address on a given physical interface. For example, ef1 will match an interface named ef1, but not an interface named ef10.

This matches one specific interface. The reference can be by protocol address (10.0.0.51), or by symbolic hostname (nic.ddn.mil). Note that a symbolic hostname reference is only valid when it resolves to only one address. Use of symbolic hostnames is not recommended.

This interface must have the address of 127.0.0.1. Packets sent to this interface are sent back to the originator. This interface is also used as a catch all interface for implementing other features, such as reject and blackhole routes. Although a netmask is reported on this interface, it is ignored. It is useful to assign an additional address to this interface that is the same as the OSPF or BGP router id; this allows routing to a system based on the router id which will work if some interfaces are down.

This is a multiaccess interface capable of a physical level broadcast, such as Ethernet, Token Ring and FDDI. This interface has an associated subnet mask and broadcast address. The interface route to an broadcast network will be a route to the complete subnet.

This is a tunnel to another host, usually on some sort of serial link. This interface has a local address, and a remote address. Although it may be possible to specify multiple addresses for a point-to-point interface, there does not seem to be a useful reason for doing so.

The remote address must be unique among all the interface addresses on a given router. The local address may be shared among many point-to-point and up to one non-point-to-point interface. This is technically a form of the router id method for addressless links. This technique conserves subnets as none are required when using this technique.

If a subnet mask is specified on a point-to-point interface, it is only used by RIP version 1 and HELLO to determine which subnets may be propagated to the router on the other side of this interface.

This type of interface is multiaccess, but not capable of broadcast. And example would be frame relay and X.25. This type of interface has a local address and a subnet mask.

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 which is the shortest path, not taking into account congestion or delay on route.

The RIP version 1 protocol is described in RFC 1058 and the RIP version 2 protocol is described in RFC 1388.

HELLO , another interior protocol, 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 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 Gateway Protocol: 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 which assumes a hierarchical structure, became less effective.

The EGP protocol is described in RFC 827 and RFC 904.

Border Gateway Protocol 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 may 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 two documents, RFC 1164 and RFC 1268 describe the application of version 2 and three 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.

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.

Specifies that RIP packets will be broadcast regardless of the number of interfaces present. This is useful when propagating static routes or routes learned from anther protocol into 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 will not be broadcast on attached interfaces, even if there are more than one. If a sourcegateways clause is present, routes will still be unicast directly to that gateway.

Specifies that RIP should not make sure that reserved fields in incoming version 1 RIP packets are zero. Normally RIP will reject packets where the reserved fields are zero.

Sets the preference for routes learned from RIP. The default preference is 100. This preference may 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 may 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 section on interface list specification for the description of the interface_list.

Note that if there are multiple interfaces configured on the same subnet, RIP updates will only be sent from first one one which RIP 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 possible parameters are:

Defines the list of gateways from which RIP 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 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 Trace Statements and the RIP specific tracing options below.)

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.

Specifies that HELLO packets will be broadcast regardless of the number of interfaces present. This is useful when propagating static routes or routes learned from anther protocol into HELLO. In some cases, the use of broadcast when only one network interface is present can cause data packets to traverse a single network twice.

Specifies that HELLO packets will not be broadcast on attached interfaces, even if there are more than one. If a sourcegateways clause is present, routes will still be unicast directly to that gateway.

Sets the preference for routes learned from HELLO. The default preference is 90. This preference may 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 may be overridden by a metric specified in export policy.

Controls various attributes of sending HELLO on specific interfaces. See the section on interface list specification for the description of the interface_list.

Note that if there are multiple interfaces configured on the same subnet, HELLO updates will only be sent from first one one 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 possible parameters are:

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 Trace Statements and the HELLO specific tracing options below.)

All HELLO packets

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

Because of the nature of OSPF, the rate at which ASEs are flooded must be limited. These two parameters can be used to adjust those rate limits.

Specifies the tracing options for OSPF. (See Trace Statements and the OSPF specific tracing options below.)

OSPF state may be queried using the ospf_monitor (This should be a hyperlink) utility. This utility sends nonstandard OSPF packets which 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 may 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 may only be configured using the backbone keyword, it may not be specified as area 0. The backbone interface may be a virtuallink.

Link State Advertisement creation

Shortest Path First (SPF) calculations

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.

Sets the preference for routes learned from RIP. The default preference is 200. This preference may 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 may consider unreachable. This choice of values requires you to explicitly specify a metric when exporting routes to EGP neighbors. This metric may be overridden by a metric specified on the neighbor or group statements or in export policy.

This 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 will be incomplete and have to be discarded. The length of this packet will be noted and the expected size will be increased to be able to receive a packet of this size. Specifying the parameter here will prevent 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 may be overridden on a group or neighbor basis. (See Trace Statements and the EGP specific tracing options below.)

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 may specify any number of neighbor clauses.

Any parameters from the neighbor subclause may be specified on the group clause to provide defaults for the whole group (which may be overridden for individual neighbors). In addition, the group clause is the only place to set the following attributes:

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. All other parameters are optional.

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.

Sets the preference for routes learned from RIP. The default preference is 170. This preference may be overridden by a preference specified on the group or peer statements or by import policy.

Defines the metric used when advertising routes via BGP. If not specified, no metric is propagated. This metric may be overridden by a metric specified on the neighbor or group statements or in export policy.

Specifies the tracing options for BGP. By default these are inherited from the global trace options. These values may be overridden on a group or neighbor basis. (See Trace Statements and the BGP specific tracing options below.)

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 local interfaces of the machine . 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 may 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 which 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 which the IGP is exporting, the export policy of the IGP is used. 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 which uses the routes of an interior protocol to resolve forwarding addresses. A type routing group propagates external routes between routers which are not directly connected. A type routing group computes immediate next hops for these routes by using the BGP next hop which arrived with the route as a forwarding address. The forwarding address is to be resolved via the routing information of an internal protocol. In essence, internal BGP is used to carry AS external routes, while the IGP is expected to only carry AS internal routes, and the latter is used to find immediate next hops for the former.

The proto names the interior protocol to be used to resolve BGP route next hops, and may be the name of any IGP in the configuration. By default the next hop in BGP routes advertised to type routing peers will be set to the local address on the BGP connection to those peers, as it is assumed a route to this address will be propagated via the IGP. The interface_list can optionally provide a list interfaces whose routes are carried via the IGP for which third party next hops may be used instead.

An extension to external BGP which implements a fixed policy using test peers. Fixed policy and special case code make test peers relatively inexpensive to maintain. Test peers do not need to be on a directly attached network. If GateD and the peer are on the same (directly attached) subnet, the advertised next hop is computed with respect to that network. Otherwise the next hop is the current next hop of the local machine. 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-derived and BGP-derived routes are forwarded in the advertisement. Otherwise no metric is included.

The allow clauses 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.

A peer clause configures an individual peer. Each peer inherits all parameters specified on a group as defaults. Those default may be overridden by parameters explicitly specified on the peer subclause.

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 which 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 not needed in most cases.

Specifies the preference used for routes learned from these peers. This can differ from the default BGP preference set in the bgp statement, so that GateD can prefer routes from one peer, or group of peer, over others. This preference may be explicitly overridden by import policy.

In the case of a preference tie, the second preference, preference2 may 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 which is shared with the peer or with the gateway of the peer when the gateway parameter is used. A session with an external peer will only be opened when an interface with the appropriate local address (through which the peer or gateway address is directly reachable) is operating. For other types of peers, a peer session will be maintained when any interface with the specified local address is operating. In either case incoming connections will only be recognized as matching a configured peer if they are addressed to the configured local address.

Specifies the BGP holdtime value to use when negotiating the connection with this peer, in seconds. 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, then the BGP connection will be 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 will be offered during negotiation. Currently supported version are 2, 3 and 4.

Specifies that active OPENs to this peer should not be attempted. GateD 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. Indelay is the amount of time a route learned from a BGP peer must be stable before it is accepted into the gated routing database. Outdelay is the amount of time a route must be present in the gated routing database before it is exported to BGP. The default value for each is 0, meaning that these features are disabled.

Used to retain routes learned from a peer even if the AS paths of the routes contain one of our exported AS numbers.

Causes GateD to issue warning messages when receiving questionable BGP updates such as duplicate routes and/or deletions of nonexisting routes. Normally these events are silently ignored.

Normally GateD verifies that incoming packets have an authentication field of all ones. This option may 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 will not advertise routes whose AS path is looped (with an AS appearing more than once in the path) to version 3 external peers. Setting this flag removes this constraint. Ignored when set on internal groups or peers.

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 which would incorrectly forward the routes on to version 3 neighbors.

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 nonlocal peers to 255. This option mainly is provided when attempting to communicate with improperly functioning routers that ignore packets sent with a TTL of one. Not all kernels allow the TTL to be specified for TCP connections.

Specifies the tracing options for this BGP neighbor. By default these are inherited from group or BGP global trace options. (See Trace Statements and the BGP specific tracing options below.)

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.

Specifies the tracing options for ICMP. (See Trace Statements and the ICMP specific tracing options below.)

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.

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 section on interface list specification for the description of the interface_list. The possible parameters are:

Defines the list of gateways from which redirects will be 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.

Specifies the Router Discovery tracing options. (See Trace Statements and the Router Discovery specific tracing options below.)

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.

Interface parameters are:

Specifies the parameters that apply to the specified set of addresses on this 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 the tracing options for OSPF. (See Trace Statements and the OSPF specific tracing options below.)

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.

State transitions

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.

GateD is able to update the kernel forwarding table, but it is not aware of other modifications of the forwarding table. GateD is able to listen to ICMP messages and guess how the kernel has updated the forwarding table with response to ICMP redirects.

GateD is not able to detect changes to the forwarding table resulting from the use of 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.

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 in sync 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 may be added by adding new message types.

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 only valid 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 only valid 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 will not be 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 to GateD that said route was added by the systems administrator and should be retained.

Configure kernel options. The valid options are:

On some systems kernel memory is at a premium. With this parameter a limit can be placed on the maximum number of routes GateD will install in the kernel. Normally gated adds/changes/deletes routes in interface/internal/external order. It queues interface routes first, followed by internal routes, followed by external routes, and processes the queue from the beginning. If a 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 doing adds in interface/internal/external order until it hits the limit again. This will tend to favor internal routes over external routes. The default is not to 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 may be processed during one flash update. The flash command allows tuning of these parameters.

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:

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.

Routes read from the kernel when GateD starts.

Requests by GateD to Add/Delete/Change routes in the kernel forwarding table.

Matching usually requires both an address and a mask, although the mask is implied in the shorthand forms listed below. These three forms vary in how the mask is specified. In the first form, the mask is implied to be the natural mask of the network. In the second, the mask is explicitly specified. In the third, the mask is specified by the number of contiguous one bits.

If no additional parameters are specified, any destination that falls in the range given by the network and mask is matched. The mask of the destination is ignored. If a natural network is specified, the network, any subnets, and any hosts will be match. The two optional modifiers cause the mask of the destination to be considered also:

This entry matches anything. It is equivalent to:

Matches the default route. To match, the address must be the default address and the mask must be all zeros. This is equivalent to:

Matches the specific host. To match, the address must exactly match the specified host and the network mask must be a host mask (all ones). This is equivalent to:

Any valid autonomous system number, from one through 65534 inclusive.

Matches any autonomous system number.

Parentheses group subexpressions--an operator, such as * or ? works on a single element or on a regular expression enclosed in parentheses

a regular expression followed by {m,n} (where m and n are both nonnegative integers and m <= n) means at least m and at most n repetitions.

a regular expression followed by {m} (where m is a positive integer) means exactly m repetitions.

a regular expression followed by {m,} (where m is a positive integer) means m or more repetitions.

an AS path term followed by * means zero or more repetitions. This is shorthand for {0,}.

a regular expression followed by + means one or more repetitions. This is shorthand for {1,}.

a regular expression followed by ? means zero or one repetition. This is shorthand for {0,1}.

matches the AS term on the left, or the AS term on the right.

Specifies that the routes are not desired in the routing table. In some cases this means that the routes are not installed in the routing table. In others it means that they are installed with a negative preference; this prevents them from becoming active so they will not be installed in the forwarding table, or exported to other protocols.

Specifies the preference value used when comparing this route to other routes from other protocols. The route with the lowest preference available at any given route becomes the active route, is installed in the forwarding table, and is eligible to be exported to other protocols. The default preferences are configured by the individual protocols.

Specifies that nothing should be exported. If specified on the destination portion of the export statement, it specifies that nothing at all should be exported to this destination. If specified on the source portion, it specifies that nothing from this source should be exported to this destination. If specified as part of a route filter, it specifies that the routes matching that filter should not be exported.

Specifies the metric to be used when exporting to the specified destination.

Routes to directly attached interfaces.

Static routes specified in a static clause.

On systems with the routing socket, routes learned from the routing socket are installed in the GateD routing table with a protocol of kernel. These routes may be exported by referencing this protocol. This is useful when it is desirable to have a script install routes with the route command and propagate them to other routing protocols.

Refers to routes created by the gendefault option. It is recommended that route generation be used instead.

Refers to routes synthesized from other routes when the aggregate and generate statements are used. See the section on Route Aggregation for more information.

Specifies the preference to assign to the resulting aggregate route. The default preference is 130.

Used to specify that the AS path should be truncated to the longest common AS path. The default is to build an AS path consisting of SETs and SEQUENCEs of all contributing AS paths.

In addition to the special protocols listed, the contributing protocol may be chosen from among any of the ones supported (and currently configured into) GateD.

Restrict selection of routes to those learned from the specified autonomous system.

Restrict selection of routes to those with the specified tag.

Restrict selection of routes to those that match the specified AS path.

Indicates that these routes are not to be considered as contributors of the specified aggregate. The specified protocol may be any of the protocols supported by GateD.

See below.