gated.conf(4)

NAME

gated.config — GateDaemon Configuration Guide

SYNOPSIS

/etc/gated.conf

DESCRIPTION

Configuration Overview

Introduction
Statement Summary
Preferences and Route Selection
Trace Statements and Global Options
Directive Statements
Options Statements
Interface Statements and Configuration
Definition Statements

Protocol Statements

Protocol Overview
Interior gateway protocols (igps)
- RIP, HELLO, OSPF
Exterior gateway protocols (egps)
- EGP, BGP
ICMP Statement
Redirect Statement
Router Discovery Statement
Kernel Interface
Static Routes

Control Statements

Route filtering
Matching AS paths
Route Importation
Route Exportation
Route Aggregation

Appendices

Glossary of Terms
References

Introduction to Configuring GateD

Syntax

The gated configuration file consists of a sequence of statements terminated by a semi-colon (`;'). Statements are composed of tokens separated by white space, which can be any combination of blanks, tabs and newlines. This structure simplifies identification of the parts of the configuration associated with each other and with specific protocols. Comments may be specified in either of two forms. One form begins with a pound sign (`#') and runs to the end of the line. The other form, C style, starts with a `/*' and continues until it reaches `*/'.

Syntax description conventions

Keywords and special characters that the parser expects exactly are displayed using bold type. Parameters are displayed in italic variable definition style. Parameters shown in square brackets (`[' and `]') are used to show optional keywords and parameters. The vertical bar (`|') is used to indicate between a choice of optional parameters. Parentheses (`(' and `)') are used to group keywords and parameters when necessary.

For example, in the syntax description:

[ backbone | ( area area ) ]

The square brackets say that either parameter is optional. The keywords are backbone and area. The vertical bar indicates that either ``backbone'' or ``area area'' may be specified. Since area is in the variable definition style, it is a parameter that needs to be provided.

Statement Grouping

The configuration statements and the order in which these statements appear divide gated.conf into options statements, interface statements, definition statements, protocol statements, static statements, control statements, and aggregate statements. Entering a statement out of order causes an error when parsing the configuration file.

Two other types of statements do not fit in these categories: %directive statements and %trace statements. These statements provide instructions to the parser and control tracing from the configuration file. They do not relate to the configuration of any protocol and may occur anywhere in the gated.conf file.

Statement Summary

A summary table of the configuration statements (in the configuration statement summary) lists each GateD configuration statement by name, identifies the statement type, and provides a short synopsis of the command function. More detailed definitions and descriptions of each of the eight classes of GateD statements follow in separate sections.

GateD Configuration Statement Summary

The GateD configuration commands are summarized below. The table lists each command by name, identifies the statement type, and gives a synopsis of the statement function:

Summary of GateD Configuration Statements

%directory (directive): sets the directory for include files.
%include (directive): includes a file into gated.conf.
traceoptions (trace): specifies which events are traced.
options (definition): defines GateD options.
interfaces (definition): defines GateD interfaces.
autonomoussystem (definition): defines the AS number.
routerid (definition): defines the originating router (BGP, OSPF).
martians (definition): defines invalid destination addresses.
rip (protocol): enables RIP protocol.
hello (protocol): enables HELLO protocol.
isis (protocol): enables ISIS protocol.
kernel (protocol): configures kernel interface options.
ospf (protocol): enables OSPF protocol.
egp (protocol): enables EGP protocol.
bgp (protocol): enables BGP protocol.
redirect (protocol): configures the processing of ICMP redirects.
icmp (protocol): configures the processing of general ICMP packets.
static (static): defines static routes.
import (control): defines which routes to import.
export (control): defines which routes to export.
aggregate (control): defines which routes to aggregate.
generate (control): defines which routes to generate.

Preference

Preference is the value GateD uses to order preference of routes from one protocol or peer over another. Preference can be set in the GateD configuration files in several different configuration statements. Preference can be set based on network interface over another, from one protocol over another, or from one remote gateway over another. Preference may not be used to control the selection of routes within an igp, this is accomplished automatically by the protocol based on metric. Preference may be used to select routes from the same egp learned from different peers or autonomous systems. Each route has only one preference value associated with it, even though preference can be set at many places in the configuration file. Simply, the last or most specific preference value set for a route is the value used. (See Glossary of Terms: Preference.) The preference value is an arbitrarily assigned value used to determine the order of routes to the same destination in a single routing database. The active route is chosen by the lowest preference value. Some protocols implement a second preference (preference2), sometimes referred to as a tie-breaker.

Selecting a route

The route with the best (numerically smallest) preference is preferred.
If the two routes have the same preference, the route with the best (numerically smallest) preference2 (also known as a tie-breaker) is preferred.
A route learned from a igp is preferred to a route learned from an egp. Least preferred is a route learned indirectly by an igp from an egp.
If AS path information is available, it is used to help determine the most preferred route.
- A route with an AS path is preferred over one without an AS path.
- If the AS paths and origins are identical, the route with the lower metric is preferred.
- A route with an AS path origin of igp is preferred over a route with an AS path origin of egp. Least preferred is an AS path with an unknown origin.
- A route with a shorter AS path is preferred.
If both routes are from the same protocol and AS, the one with the lowest metric is preferred.
The route with the lowest numeric next-hop address is used.

Assigning preferences

A default preference is assigned to each source from which GateD receives routes. Preference values range from 0 to 255 with the lowest number indicating the most preferred route.

The following table summarizes the default preference values for routes learned in various ways. The table lists the statements (some of these are clauses within statements) that set preference, and shows the types of routes to which each statement applies. The default preference for each type of route is listed, and the table notes preference precedence between protocols. The narrower the scope of the statement, the higher precedence its preference value is given, but the smaller the set of routes it affects.

`Preference Of`	Defined by Statement	Default
direct connected networks	interface	0
OSPF routes	ospf	10
IS-IS level 1 routes	isis level 1	15
IS-IS level 2 routes	isis level 2	18
internally generated default	gendefault	20
redirects	redirect	30
routes learned via route socket	kernel	40
static routes from config	static	60
ANS SPF (SLSP) routes	slsp	70
HELLO routes	hello	90
RIP routes	rip	100
point-to-point interface		110
routes to interfaces that are down	interfaces	120
aggregate/generate routes	aggregate/generate	130
OSPF AS external routes	ospf	150
BGP routes	bgp	170
EGP	egp	200

Sample Preference Specifications

interfaces {
    interface 138.66.12.2 preference 10 ;
} ;
rip yes {
    preference 90 ;
} ;
import proto rip gateway 138.66.12.1 preference 75 ;

In these statements the preference applicable to routes learned via RIP from gateway 138.66.12.1 is 75. The last preference applicable to routes learned via RIP from gateway 128.66.12.1 is defined in the accept statement. The preference applicable to other RIP routes is found in the rip statement. The preference set on the interface statement applies only to the route to that interface.

Trace Statements

Trace statements control tracing options. The GateD tracing options may be configured at many levels. Tracing options include the file specifications, control options, and global and protocol specific tracing options. Unless overridden, tracing options from the next higher level are inherited by lower levels. For example, BGP peer tracing options are inherited from BGP group tracing options, which are inherited from global BGP tracing options, which are inherited from global GateD tracing options. At each level tracing specifications override the inherited options.

Global tracing options

There are two types of global options, those which only affect global operations and those which have potential significance to protocols.

Global significance only

The trace flags that only have global significance are:

parse: Trace the lexical analyzer and parser. Mostly used by GateD developers for debugging.
adv: Trace the allocation of and freeing of policy blocks. Mostly used by the GateD developers for debugging.
symbols: Used to trace symbols read from the kernel at startup. The only useful way to specify this level of tracing is via the -t option on the command line since the symbols are read from the kernel before parsing the configuration file.
iflist: Used to trace the reading of the kernel interface list. It is useful to specify this with the -t option on the command line since the first interface scan is done before reading the configuration file.

Protocol significance

The options flags that have potential significance to protocols are:

all: Turn on all of the following.
general: A shorthand notation for specifying both normal and route.
state: Trace state machine transitions in the protocols.
normal: Trace normal protocols occurrences. Abnormal protocol occurrences are always traced.
policy: Trace application of protocol and user-specified policy to routes being imported and exported.
task: Trace system interface and processing associated with this protocol or peer.
timer: Trace timer usage by this protocol or peer.
route: Trace routing table changes for routes installed by this protocol or peer.

Not all of the above options apply to all of the protocols. In some cases their use does not make sense (for instance, RIP does not have a state machine) and in some instances the requested tracing has not been implemented (such as RIP support of the policy option).

It is not currently possible to specify packet tracing from the command line. This is because a global option for packet tracing would potentially create too much output.

When protocols inherit their tracing options from the global tracing options, tracing levels that do not make sense (such as parse, adv and packet tracing options) are masked out.

Global tracing statements have an immediate effect, especially parsing options that effect the parsing of the configuration file. Tracing values inherited by protocols specified in the configuration file are initially inherited from the global options in effect as they are parsed, unless they are overridden by more specific options. After the configuration file is read, tracing options that were not explicitly specified are inherited from the global options in effect at the end of the configuration file.

Packet tracing

Tracing of packets is very flexible. For any given protocol there are one or more options for tracing packets. all protocols allow use of the packets keyword allows for tracing all packets sent and received by the protocol. most protocols have other options for limiting tracing to a useful subset of packet types. These tracing options can be further controlled with the following modifiers:

detail: 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.
send
recv: These options limit the tracing to packets sent or received. Without these options both sent and received packets will be traced.

Detail, if specified, must be before send or recv. If a protocol allows for several different types of packet tracing, modifiers may be applied to each individual type. But be aware that within one tracing specification the trace flags are summed up, so specifying detail packets will turn on full tracing for all packets.

Traceoptions syntax

traceoptions ["trace_file" [replace] [size size[k|m] files files]]
        [control_options] trace_options [except trace_options] ;

traceoptions none ;

trace_file

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

replace

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

size size[k|m] files files

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

control_options

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

nostamp: Specifies that a timestamp should not be prepended to all trace lines.

except trace_options

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

none

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

Directive Statements

Directive statements provide direction to the GateD configuration language parser about included files and the directories in which these files reside. Directive statements are immediately acted upon by the parser. Other statements terminate with a semi-colon (;), but directive statements terminate with a newline. The two directive statements are:

%directory "directory": Defines the directory where the include files are stored. When it is used, GateD looks in the directory identified by pathname for any included files that do not have a fully qualified filename, such as files that do not begin with "/". This statement does not actually change the current the directory, it just specifies the prefix applied to included file names.
%include "filename": Identifies an include file. The contents of the file is included in the gated.conf file at the point in the gated.conf file where the %include directive is encountered. If the filename is not fully qualified (does not begin with "/"), it is considered to be relative to the directory defined in the %directory directive. The %include directive statement causes the specified file to be parsed completely before resuming with this file. Nesting up to ten levels is supported. The maximum nesting level may be increased by changing the definition of FI_MAX in parse.h.

In a complex environment, segmenting a large configuration into smaller more easily understood segments might be helpful, but one of the great advantages of GateD is that it combines the configuration of several different routing protocols into a single file. Segmenting a small file unnecessarily complicates routing configurations.

Options Statements

Options statements allow specification of some global options. If used, options must appear before any other type of configuration statement in the gated.conf file.

The options statement syntax is:

options
    [ nosend ]
    [ noresolv ]
    [ gendefault [ preference preference ] [ gateway gateway] ]
    [ syslog [ upto ] log_level ]
    [ mark time ]
    ;

The options list can contain one or more of the following options:

gendefault [ preference preference ] [ gateway gateway]

When gendefault is enabled, when a BGP or EGP neighbor is up it causes the creation of a default route with the special protocol default. This can be disabled per BGP/EGP group with the nogendefault option. By default, this route has a preference of 20. This route is normally not installed in the kernel forwarding table, it is only present so it can be announced to other protocols. If a gateway is specified, the default route will be installed in the kernel forwarding table with a next hop of the listed gateway.

Note that the use of the more general option is preferred to the use of this gendefault option. The gendefault option may go away in future releases. The the section on Route Aggregation for more information on the generate statement.

nosend

Do not send any packets. This option makes it possible to run GateD on a live network to test protocol interactions without actually participating in the routing protocols. The packet traces in the GateD log can be examined to verify that GateD is functioning properly. This is most useful for RIP and HELLO and possibly the SMUX SNMP interface. This option does not yet apply to BGP and is less than useful with EGP and OSPF.

noresolv

By default GateD will try to resolve symbolic names into IP addresses by using the gethostbyname() and getnetbyname() library calls. These calls usually use the Domain Name System (DNS) instead of the hosts local host and network tables. If there is insufficient routing information to send DNS queries, GateD will deadlock during startup. This option can be used to prevent these calls, symbolic names will result in configuration file errors.

syslog [ upto ] log_level

Controls the amount of data GateD logs via syslog on systems where setlogmask() is supported. The available logging levels and other terminology are as defined in the setlogmask(3) man page. The default is equivalent to syslog upto info.

mark time

Specifying this option causes gated to output a message to the trace log at the specified interval. This can be used as one method of determining if gated is still running.

Interfaces Statement

Interface Syntax

interfaces {
    options
        [ strictinterfaces ]
        [ scaninterval time ]
        [ aliases-nh ( primary | lowestip | keepall ) ]
        ;
    interface interface_list
        [ preference preference ]
        [ down preference preference ]
        [ passive ]
        [ simplex ]
        [ reject ]
        [ blackhole ]
        [ alias  primary address ]
        [ aliases-nh ( primary | lowestip | keepall ) ]
        ;
    define address
        [ broadcast address ] | [ pointtopoint address ]
        [ netmask mask ]
        [ multicast ]
        ;
} ;

An interface is the connection between a router and one of its attached networks. A physical interface may be specified by interface name, by IP address, or by domain name, (unless the network is an unnumbered point-to-point network.) Multiple levels of reference in the configuration language allow identification of interfaces using wildcard, interface type name, or delete word address. Be careful with the use of interface names as future Unix operating systems may allow more than one address per interface. The interface_list is a list of one or more interface names including wildcard names (names without a number) and names which may specify more than one interface or address, or the token all for all interfaces.

options

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

strictinterfaces: Indicates that it is a fatal error to reference an interface in the configuration file that is not present when GateD is started and not listed in a define statement. Without this option a warning message will be issued but GateD will continue.
scaninterval time: Specifies how often GateD scans the kernel interface list for changes. The default is every 15 seconds on most systems, and 60 seconds on systems that pass interface status changes through the routing socket (BSD 4.4). Note that GateD will also scan the interface list on receipt of a SIGUSR2.
aliases-nh ( primary | lowestip | keepall ): Specifies which address GateD will install as the next hop for interface routes when multiple addresses are assigned to an interface like the Service Guard environment. If primary is used, the primary interface address (default) will be installed. If lowestip is used, the address with the lowest IP address will be installed. If keepall is used, all interface routes are kept in the kernel up to a maximum of RT_N_MULTIPATH routes. This is a compile-time constant. This is a global parameter that may be overridden for interfaces using the interface option.

interface interface_list

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:

preference preference: Sets the preference for routes to this interface when it is up and appears to be functioning properly. The default preference is 0.
down preference preference: Sets the preference for routes to this interface when GateD does not believe it to be functioning properly, but the kernel does not indicate it is down. The default value is 120.
passive: Prevents GateD from changing the preference of the route to this interface if it is not believed to be functioning properly due to lack of received routing information. GateD will only perform this check if the interface is actively participating in a routing protocol.
simplex: Defines an interface as unable to hear its own broadcast packets. Some systems define an interface as simplex with the IFF_SIMPLEX flag, on others it needs to be specified in the configuration file. On simplex interfaces, packets from myself are assumed to have been looped back in software and are not used as an indication that the interface is functioning properly.
reject: Specifies that the address of the interface which matches these criteria will be used as the local address when installing reject routes in the kernel. Should only be used with systems based on BSD 4.3 Tahoe or earlier which have installed a reject/blackhole pseudo interface.
blackhole: Specifies that the address of the interface which matches these criteria will be used as the local address when installing reject routes in the kernel. Should only be used with systems based on BSD 4.3 Tahoe or earlier which have installed a reject/blackhole pseudo interface.
alias primary address: Specifies a primary address for this interface. This option overrides the address that GateD determines to be primary.
aliases-nh ( primary | lowestip | keepall ): Specifies which address GateD will install as the next hop for the route associated with this interface when multiple adresses are assigned to an interface like the Service Guard environment. If primary is used, the primary interface address (default) will be installed. If lowestip is used, the address with the lowest IP address will be installed. If keepall is used, all interface routes are kept in the kernel up to a maximum of RT_N_MULTIPATH routes. This is a compile-time constant. This parameter overrides the global option for this interface.

define address

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:

broadcast address: Defines the interface as broadcast capable (Ethernet or Token Ring) and specifies the broadcast address.
pointtopoint address: Defines the interface as a point-to-point interface (SLIP or PPP) and specifies the address on the local side. The first address on the define statement references the address of the host on the remote end of the interface, the address specified after this pointtopoint keyword defines the address on the local side of the interface.

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

netmask mask: Specifies the subnetmask to be used on this interface. This is ignored on pointtopoint interfaces.
multicast: Specifies that the interface is multicast capable.

Interface lists

An interface list is a list of references to interfaces or groups of interfaces. There are four methods available for referring to interfaces. They are listed here from most general to most specific.

all

This refers to all available interfaces.

Interface name wildcard

This refers to all the interfaces of the same type. 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.

Interface name

This refers to a specific interface, usually one physical interface. These are specified as an alphabetic part followed by a numeric part. This will match one specific interface. 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.

Interface address

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.

If many interface lists are present in the configuration file with more than one parameter, these parameters are collected at run-time to create the specific parameter list for a given interface. If the same parameter is specified on more than one list, the parameters with the most specific interface is used.

For example, consider a system with three interfaces, le0, le1 and du0.

rip yes {
    interface all noripin noripout ;
    interface le ripin ;
    interface le1 ripout ;
} ;

RIP packets would only be accepted from interfaces le0 and le1, but not from du0. RIP packets would only be sent on interface le1.

IP Interface addresses and routes

The BSD 4.3 and later networking implementations allow four types of interfaces. Some implementations allow multiple protocol addresses per physical interface, these are mostly based on BSD 4.3 Reno or later.

loopback

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

broadcast

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

point-to-point

This is a tunnel to another host, usually on some sort of serial link. This interface has a local address, and a remote address. 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.

non-broadcast multi-access or nbma

This type of interface is multi-access, 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.

GateD insures that there is a route available to each IP interface that is configured and up. Normally this this done by the ifconfig command that configures the interface; GateD does it to insure consistency.

For point-to-point interfaces, gated installs some special routes. If the local address on one or more point-to-point interfaces is not shared with a non-point-to-point interface, gated installs a route to the local address pointing at the loopback interface with a preference of 110. This insures that packets originating on this host destined for this local address are handled locally. OSPF prefers to route packets for the local interface across the point-to-point link where they will be returned by the router on the remote end. This is used to verify operation of the link. Since OSPF installs routes with a preference of 10, these routes will override the route installed with a preference of 110.

If the local address of one or more point-to-point interfaces is shared with a non-point-to-point interface, gated installs a route to the local with a preference of 0 that will not be installed in the forwarding table. This is to prevent protocols like OSPF from routing packets to this address across a serial interface when this system could be functioning as a host.

When the status of an interface changes, GateD notifies all the protocols, which take the appropriate action. GateD assumes that interfaces which are not marked UP do not exist. While this might not be the most correct action, it is the way things currently work.

GateD ignores any interfaces that have invalid data for the local, remote or broadcast addresses or the subnet mask. Invalid data includes zeros in any field. GateD will also ignore any point-to-point interface that has the same local and remote addresses, it assumes it is in some sort of loopback test mode.

Definition Statements

Definition statements are general configuration statements that relate to all of GateD or at least to more than one protocol. The three definition statements are autonomoussystem, routerid and martians. if used, autonomoussystem, routerid and martians must appear before any other type of configuration statement in gated.conf file.

Autonomous System configuration

autonomoussystem autonomous_system [ loops number ] ;

Sets the autonomous system number of this router to be autonomous system. This option is required if BGP or EGP are in use. The AS number is assigned by the Network Information Center (NIC).

Loops is only for protocols supporting AS paths, such as BGP. It controls the number of times this autonomous system may appear in an AS path and defaults to 1 (one).

Router ID configuration

routerid host ;

Sets the router identifier for use by the BGP and OSPF protocols. The default is the address of the first interface encountered by GateD. The address of a non-point-to-point interface is preferred over the local address of a point-to-point interface and an address on a loopback interface that is not the loopback address (127.0.0.1) is most preferred.

Martian configuration

martians {
    host host [ allow ] ;
        network [ allow ] ;
        network mask mask [ allow ] ;
        network masklen number [ allow ] ;
    default [ allow ] ;
} ;

Defines a list of martian addresses about which all routing information is ignored. Sometimes a misconfigured system sends out obviously invalid destination addresses. These invalid addresses, called martians, are rejected by the routing software. This command allows additions to the list of martian addresses. See the section on Route Filtering for more information on specifying ranges. Also, the allow parameter may be specified to explicitly allow a subset of a range that was disallowed.

Sample Definition Statements

options gendefault ;
autonomoussystem 249 ;
interface 128.66.12.2 passive ;
martians {
    0.0.0.26
    };

The statements in the sample perform the following functions:

The options statement tells the system to generate a default route when it peers with an EGP or BGP neighbor.
The autonomoussystem statement tells GateD to use AS number 249 for in EGP and BGP.
The interface statement tells GateD not to mark interface 128.66.12.2 as down even if it sees no traffic.
The martians statement prevents routes to 0.0.0.26 from ever being accepted.

Protocol Overview

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. 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. There are several interior protocols:

RIP

The Routing Information Protocol, Version 1 and Version 2, is the most commonly used interior protocol. RIP selects the route with the lowest metric as the best route. The metric is a hop count representing the number of gateways through which data must pass to reach its destination. The longest path that RIP accepts is 15 hops. If the metric is greater than 15, a destination is considered unreachable and GateD discards the route. RIP assumes the best route is the one that uses the fewest gateways 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

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.

OSPF

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 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. There are two exterior protocols currently supported by GateD:

EGP

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.

BGP

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.

Other Routing Protocols

Router Discovery

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

Router Discovery is described in RFC 1256.

Routing Information Protocol (RIP)

One of the most widely used interior gateway protocols is the Routing Information Protocol (RIP). RIP is an implementation of a distance-vector, or Bellman-Ford routing protocol for local networks. It classifies routers as active and passive (silent). Active routers advertise their routes (reachability information) to others; passive routers listen and update their routes based on advertisements, but do not advertise. Typically, routers run RIP in active mode, while hosts use passive mode.

A router running RIP in active mode broadcasts updates at set intervals. Each update contains paired values where each pair consists of an IP network address and an integer distance to that network. RIP uses a hop count metric to measure the distance to a destination. In the RIP metric, a router advertises directly connected networks at a metric of 1. Networks which are reachable through one other gateway are two hops etc. 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 would encounter 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 may 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 up, 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) add additional 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 mis-interpreted, 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.

Some of the most notable RIP II enhancements are:

Next hop

The primary ones are the ability to advertise a next hop to use other than the router supplying the routing update. This is quite useful when advertising a static route to a dumb router that does not run RIP as it avoids having packets destined through the dumb router from having to cross a network twice.

RIP I routers will ignore next hop information in RIP II packets. This may result in packets crossing a network twice, which is exactly what happens with RIP I. So this information is provided in RIP I compatible RIP II packets.

Network Mask

RIP I assumes that all subnetworks of a given network have the same network mask. It uses this assumption to calculate the network masks for all routes received. This assumption prevents subnets with different netmasks from being included in RIP packets. RIP II adds the ability to explicitly specify the network mask with each network in a packet.

While RIP I routers will ignore the network mask in RIP II packets, their calculation of the network mask will quite possibly be wrong. For this reason, RIP I compatible RIP II packets must not contain networks that would be mis-interpreted. These network must only be provided in native RIP II packets that are multicast.

Authentication

RIP II packets may also contain one of two types of authentication string that may be used to verify the validity of the supplied routing data. Authentication may be used in RIP I compatible RIP II packets, but be aware that RIP I routers will 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 may 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 may be used to reject it.

The RIP Statement

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

The rip statement enables or disables RIP. If the rip statement is not specified, the default is rip on ;. If enabled, RIP will assume nobroadcast when there is only one interface and broadcast when there is more than one.

The options are as follows:

broadcast

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.

nobroadcast

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.

nocheckzero

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.

preference preference

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.

defaultmetric metric

Defines the metric used when advertising routes via RIP that were learned from other protocols. If not specified, the default value is 16 (unreachable). This choice of values requires you to explicitly specify a metric in order to export routes from other protocols into RIP. This metric may be overridden by a metric specified in export policy.

query authentication [none | [[simple|md5] password]] ;

Specifies the authentication required of query packets that do not originate from routers. The default is none.

interface interface_list

Controls various attributes of sending RIP on specific interfaces. See the 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:

noripin

Specifies that RIP packets received via the specified interface will be ignored. The default is to listen to RIP packets on all non-loopback interfaces.

ripin

This is the default. This argument may be necessary when noripin is used on a wildcard interface descriptor.

noripout

Specifies that no RIP packets will be sent on the specified interfaces. The default is to send RIP on all broadcast and non-broadcast interfaces when in broadcast mode. The sending of RIP on point-to-point interfaces must be manually configured.

ripout

This is the default. This argument is necessary when it is desired to send RIP on point-to-point interfaces and may be necessary when noripin is used on a wildcard interface descriptor.

metricin metric

Specifies the RIP metric to add to incoming routes before they are installed in the routing table. The default is the kernel interface metric plus 1 (which is the default RIP hop count). If this value is specified, it will be used as the absolute value. The kernel metric will not be added. This option is used to make this router prefer RIP routes learned via the specified interface(s) less than RIP routes from other interfaces.

metricout metric

Specifies the RIP metric to be added to routes that are send via the specified interface(s). The default is zero. This option is used to make other routers prefer other sources of RIP routes over this router.

version 1

Specifies that RIP packets send via the specified interface(s) will be version 1 packets. This is the default.

version 2

Specifies that RIP version 2 packets will be 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 will be sent.

multicast

Specifies that RIP version 2 packets should be multicast on this interface. This is the default.

broadcast

Specifies that RIP version 1 compatible version 2 packets should be broadcast on this interface, even if IP multicast is available.

[secondary] authentication [none | [simple|md5] password]

This defines the authentication type to use. It applies only to RIP version 2 and is ignored for RIP-1 packets. The default authentication type is none. If a password is specified, the authentication type defaults to simple. The password should be a quoted string with between 0 and 16 characters.

If secondary is specified, this defines the secondary authentication. If omitted, the primary authentication is specified. The default is primary authentication of none and no secondary authentication.

trustedgateways gateway_list

Defines the list of gateways from which RIP will accept updates. The gateway_list is simply a list of host names or IP addresses. By default, all routers on the shared network are trusted to supply routing information. But if the trustedgateways clause is specified only updates from the gateways in the list are accepted.

sourcegateways gateway_list

Defines a list of routers to which RIP sends packets directly, not through multicast or broadcast. This can be used to send different routing information to specific gateways. Updates to gateways in this list are not affected by noripout on the interface.

traceoptions trace_options

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

Tracing options

The policy option logs info whenever a new route is announce, the metric being announced changes or a route goes or leaves holddown.

Packet tracing options (which may be modified with detail, send or recv):

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

The Hello Protocol

It is really better not to use HELLO unless you have a specific need for it. We plan to drop it some time around GateD 4.0.

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 which 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 essentially 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
       100
       148
       219
       325
       481
       713
      1057
      1567
      2322
      3440
      5097
      7552
     11190
     16579
     24564
     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.

The Hello Statement

hello yes | no | on | off [ {
    broadcast ;
    nobroadcast ;
    preference preference ;
    defaultmetric metric ;
    interface interface_list
            [nohelloin] | [helloin]
            [nohelloout] | [helloout]
            [metricin metric]
            [metricout metric] ;
    trustedgateways gateway_list ;
    sourcegateways gateway_list ;
    traceoptions trace_options ;
} ] ;

the hello statement enables or disables HELLO. If the hello statement is not specified, the default is hello off. If enabled, HELLO will assume nobroadcast when there is only one interface and broadcast when there is more than one interface.

broadcast

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

nobroadcast

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

preference preference

Sets the preference for routes learned from HELLO. The default preference is 90. This preference may be overridden by a preference specified in import policy.

defaultmetric metric

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.

interface interface_list

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

Note 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:

nohelloin: Specifies that HELLO packets received via the specified interface will be ignored. The default is to listen to HELLO on all non-loopback interfaces.
helloin: This is the default. This argument may be necessary when nohelloin is used on a wildcard interface descriptor.
nohelloout: Specifies that no HELLO packets will be 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.
helloout: This is the default. This argument is necessary when it is desired to send HELLO on point-to-point interfaces and may be necessary when nohelloin is used on a wildcard interface descriptor.
metricin metric: 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 will be used as the absolute value. The kernel metric will not be 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.
metricout metric: 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.

trustedgateways gateway_list

Defines the list of gateways from which HELLO will accept updates. The gateway_list is simply a list of host names or IP addresses. By default, all routers on the shared network are trusted to supply routing information. But if the trustedgateways clause is specified only updates from the gateways in the list are accepted.

sourcegateways gateway_list

Defines a list of routers to which HELLO sends packets directly, not through multicast or broadcast. This can be used to send different routing information to specific gateways. Updates to gateways in this list are not affected by noripout on the interface.

traceoptions trace_options

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

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

Tracing options

The policy option logs info whenever a new route is announce, the metric being announced changes or a route goes or leaves holddown.

Packet tracing options (which may be modified with detail, send and/or recv):

packets: All HELLO packets

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 usable interfaces and reachable neighbors of the router) 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 will add 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 the OSPF 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 (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 OSPF of the area, 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 the parameters of that area. 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 the configuration of that area. Misconfiguration will lead to adjacencies not forming between neighbors, and routing information might not flow, or even loop.

Authentication

All OSPF protocol exchanges are 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. OSPF protocol exchanges may be authenticated. Authentication guarantees that routing information is imported only from trusted routers, to protect the Internet and its users. 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 may match either the primary or secondary authentication type and key.

The OSPF Statement

ospf yes | no | on | off [ {
    defaults {
        preference preference ;
        cost cost ;
        tag [ as ] tag ;
        type 1 | 2 ;
    } ;
    exportlimit routes ;
    exportinterval time ;
    traceoptions trace_options ;
    monitorauthkey authkey ;
    monitorauth none | ( [ simple | md5 ] authkey ) ;
    backbone | ( area area ) {
        authtype 0 | 1 | none | simple ;
        stub [ cost cost] ;
        networks {
            network [ restrict ] ;
            network mask mask [ restrict ] ;
            network masklen number [ restrict ] ;
            host host [ restrict ] ;
        } ;
        stubhosts {
            host cost cost ;
        } ;
        interface interface_list; [cost cost ] {
            interface_parameters
        } ;
        interface interface_list nonbroadcast [cost cost ] {
            pollinterval time ;
            routers {
                gateway [ eligible ] ;
            } ;
            interface_parameters
        } ;
        Backbone only:
        virtuallink neighborid router_id transitarea area {
            interface_parameters
        } ;
    } ;
} ] ;

The following are the interface_parameters referred to above. The may be specified on any class of interface and are described under the interface clause.

enable | disable ;
retransmitinterval time ;
transitdelay time ;
priority priority ;
hellointerval time ;
routerdeadinterval time ;
authkey auth_key ;

defaults

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.

preference preference: The preference is used to determine how OSPF routes compete with routes from other protocols in the gated routing table. The default value is 150.
cost cost: The cost is used when exporting a non-OSPF route from the GateD routing table into OSPF as an ASE. The default value is 1. This may be explicitly overridden in export policy.
tag [ as ] tag: OSPF ASE routes have a 32 bit tag field that is not used by the OSPF protocol, but may be used by export policy to filter routes. When OSPF is interacting with an egp, the tag field may be used to propagate AS path information, in which case the as keyword is specified and the tag is limited to 12 bits of information. If not specified, the tag is set to zero.
type 1 | 2: Routes exported from the GateD routing table into OSPF default to becoming type 1 ASEs. This default may be explicitly changed here and overridden in export policy.

ASE export rate

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.

exportinterval time: This specifies how often a batch of ASE link state advertisements will be generated and flooded into OSPF. The default is once per second.
exportlimit routes: This parameter specifies how many ASEs will be generated and flooded in each batch. The default is 100.

traceoptions trace_options

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

monitorauthkey authkey

OSPF state may be queried using the ospf_monitor (This should be a hyperlink) utility. This utility sends non-standard 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.

backbone

area area

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

gated.conf(4)

Technical documentation

» Table of Contents

» Index

NAME

SYNOPSIS

DESCRIPTION

Configuration Overview

Protocol Statements

Control Statements

Appendices

Introduction to Configuring GateD

Syntax

Syntax description conventions

Statement Grouping

Statement Summary

GateD Configuration Statement Summary

Summary of GateD Configuration Statements

Preference

Selecting a route

Assigning preferences

Sample Preference Specifications

Trace Statements

Global tracing options

Global significance only

Protocol significance

Packet tracing

Traceoptions syntax

Directive Statements

Options Statements

Interfaces Statement

Interface Syntax

Interface lists

IP Interface addresses and routes

Definition Statements

Autonomous System configuration

Router ID configuration

Martian configuration

Sample Definition Statements

Protocol Overview

Interior Routing Protocols

Exterior Routing Protocols

Other Routing Protocols

Routing Information Protocol (RIP)

RIP-I and network masks

The RIP Statement

Tracing options

The Hello Protocol

HELLO and network masks

The Hello Statement

Tracing options

The OSPF Protocol

Authentication

The OSPF Statement