Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
HP-UX Reference > G

gated.conf(4)

HP-UX 11i Version 3: February 2007
» 

Technical documentation

» Feedback
Content starts here

 » Table of Contents

 » Index

NAME

gated.conf — 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 OfDefined by StatementDefault
direct connected networksinterface0
OSPF routesospf10
IS-IS level 1 routesisis level 115
IS-IS level 2 routesisis level 218
internally generated defaultgendefault20
redirectsredirect30
routes learned via route socketkernel40
static routes from configstatic60
ANS SPF (SLSP) routesslsp70
HELLO routeshello90
RIP routesrip100
point-to-point interface 110
routes to interfaces that are downinterfaces120
aggregate/generate routesaggregate/generate130
OSPF AS external routesospf150
BGP routesbgp170
EGPegp200

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

Note: The keepall option is mandatory when gated is being used in a Service Guard environment.

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 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 parameter overrides the global option for this interface.

Note: The keepall option is mandatory when gated is being used in a Service Guard environment.

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

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.

nonbroadcast multiaccess or nbma

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.

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 misinterpreted, RIP II can only use noncompatible 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 misinterpreted. 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 nonloopback 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 nonbroadcast 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 0 1 100 2 148 3 219 4 325 5 481 6 713 7 1057 8 1567 9 2322 10 3440 11 5097 12 7552 13 11190 14 16579 15 24564 16 30000

HELLO and network masks

HELLO derives the network mask of received networks and hosts from the network mask of the interface the packet via which the packet was received. If a received network or host is on the same natural network as the interface over which it was received and that network is subnetted (the specified mask is more specific than the natural netmask), the subnet mask is applied to the destination. If bits outside the mask are set, it is assumed to be a host. Otherwise it is assumed to be a subnet.

On point-to-point interfaces, the netmask is applied to the remote address. The netmask on these interfaces is ignored if it matches the natural network of the remote address or is all ones.

Unlike in previous releases, the zero subnet mask (a network that matches the natural network of the interface, but has a more specific, or longer, network mask) is ignored. If this is not desirable, a route filter may be used to reject it.

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 nonloopback 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 nonbroadcast 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 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.

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.

authtype 0 | 1 | none | simple

OSPF specifies an authentication scheme per area. Each interface in the area must use this same authentication scheme although it may use a different authenticationkey. The currently valid values are none (0) for no authentication, or simple (1) for simple password authentication.

stub [ cost cost]

A stub area is one in which there are no ASE routes. If a cost is specified, this is used to inject a default route into the area with the specified cost.

networks

The networks list describes the scope of an area. Intra-area LSAs that fall within the specified ranges are not advertised into other areas as inter-area routes. Instead, the specified ranges are advertised as summary network LSAs. If restrict is specified, the summary network LSAs are not advertised. Intra-area LSAs that do not fall into any range are also advertised as summary network LSAs. This option is very useful on well designed networks in reducing the amount of routing information propagated between areas. The entries in this list are either networks, or a subnetwork/mask pair. See the section on Route Filtering for more detail about specifying ranges.

stubhosts

This lists specifies directly attached hosts that should be advertised as reachable from this router and the costs they should be advertised with. Point-to-point interfaces on which it is not desirable to run OSPF should be specified here.

It is also useful to assign a additional address to the loopback interface (one not on the 127 network) and advertise it as a stub hosts. If this address is the same one used as the router-id, it enables routing to OSPF routers by router-id, instead of by interface address. This is more reliable than routing to one of the routers interface addresses which may not always be reachable.

interface interface_list [cost cost ]

This form of the interface clause is used to configure a broadcast (which requires IP multicast support) or a point-to-point interface. See the section on interface list specification for the description of the interface_list.

Each interface has a cost. The costs of all interfaces a packet must cross to reach a destination are summed to get the cost to that destination. The default cost is one, but another nonzero value may be specified.

Interface parameters common to all types of interfaces are:

retransmitinterval time

The number of seconds between link state advertisement retransmissions for adjacencies belonging to this interface.

transitdelay time

The estimated number of seconds required to transmit a link state update over this interface. Transitdelay takes into account transmission and propagation delays and must be greater than 0.

priority priority

A number between 0 and 255 specifying the priority for becoming the designated router on this interface. When two routers attached to a network both attempt to become designated router, the one with the highest priority wins. A router whose router priority is set to 0 is ineligible to become designated router.

hellointerval time

The length of time, in seconds, between Hello packets that the router sends on the interface.

routerdeadinterval time

The number of seconds not hearing Hello packets of a router before the neighbors of the router will declare it down.

authkey auth_key

Used by OSPF authentication to generate and verify the authentication field in the OSPF header. The authentication key can be configured on a per interface basis. It is specified by one to eight decimal digits separated by periods, a one to eight byte hexadecimal string preceded by 0x, or a one to eight character string in double quotes.

Point-to-point interfaces also support this additional parameter:

nomulticast

By default, OSPF packets to neighbors on point-to-point interfaces are sent via the IP multicast mechanism. Although, some implementations of IP multicasting for Unix have a bug that precludes the use of IP multicasting on these interfaces. Gated will detect this condition and fall back to using sending unicast OSPF packets to this point-to-point neighbor.

If the use of IP multicasting is not desired because the remote neighbor does not support it, the nomulticast parameter may be specified to force the use of unicast OSPF packets. This option may also be used to eliminate warnings when Gated detects the bug mentioned above.

interface interface_list nonbroadcast [cost cost ]

This form of the interface clause is used to specify a nonbroadcast interface on a nonbroadcast multiaccess (NBMA) media. Since an OSPF broadcast media must support IP multicasting, a broadcast capable media, such as Ethernet, that does not support IP multicasting must be configured as a nonbroadcast interface.

A nonbroadcast interface supports any of the standard interface clauses listed above, plus the following two that are specific to nonbroadcast interfaces:

pollinterval time

Before adjacency is established with a neighbor, OSPF packets are sent periodically at the specified pollinterval.

routers

By definition it is not possible to send broadcast packets to discover OSPF neighbors on a nonbroadcast, so all neighbors must be configured. The list includes one or more neighbors and an indication of their eligibility to become a designated router.

virtuallink neighborid router_id transitarea area

Virtual links are used to establish or increase connectivity of the backbone area. The neighborid is the router_id of the other end of the virtual link. The transit area specified must also configured on this system. All standard interface parameters defined by the interface clause above may be specified on a virtual link.

Tracing options

In addition to the following OSPF specific trace flags, OSPF supports the state which traces interface and neighbor state machine transitions.

lsabuild

Link State Advertisement creation

spf

Shortest Path First (SPF) calculations

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

hello

OSPF HELLO packets which are used to determine neighbor reachability.

dd

OSPF Database Description packets which are used in synchronizing OSPF databases.

request

OSPF Link State Request packets which are used in synchronizing OSPF databases.

lsu

OSPF Link State Update packets which are used in synchronizing OSPF databases.

ack

OSPF Link State Ack packets which are used in synchronizing OSPF databases.

The Exterior Gateway Protocol (EGP)

The Exterior Gateway Protocol (EGP) is an exterior routing protocol used for exchanging routing information with gateways in other autonomous systems. Unlike interior protocols, EGP propagates only reachability indications, not true metrics. EGP updates contain metrics, called distances which range from 0 to 255. GateD will only compare EGP distances learned from the same AS. them.

Before EGP sends routing information to a remote router, it must establish an adjacency with that router. This is accomplished by an exchange of Hello (not to be confused with the HELLO protocol, or OSPF HELLO messages) and I Heard You (I-H-U) messages with that router. Computers communicating via EGP are called EGP neighbors, and the exchange of HELLO and I-H-U messages is referred to as acquiring a neighbor. Once the neighbor is acquired, the system polls the neighbor for routing information. The neighbor responds by sending an update containing routing information. If the system receives a poll from its neighbor, it responds with its own update packet. When the system receives an update, it includes routes from the update into its routing database. If the neighbor fails to respond to three consecutive polls, GateD assumes that the neighbor is down and removes the routes of that neighbor from its database.

The EGP Statement

egp yes | no | on | off [ { preference preference ; defaultmetric metric ; packetsize number ; traceoptions trace_options ; group [ peeras autonomous_system ] [ localas autonomous_system ] [ maxup number ] { neighbor host [ metricout metric ] [ preference preference ] [ preference2 preference ] [ ttl ttl ] [ nogendefault ] [ importdefault ] [ exportdefault ] [ gateway gateway ] [ lcladdr local_address ] [ sourcenet network ] [ minhello | p1 time ] [ minpoll | p2 time ] [ traceoptions trace_options ] ; } ; } ] ;

preference preference

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.

defaultmetric metric ;

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.

packetsize maxpacketsize

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.

traceoptions trace_options

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

group

EGP neighbors must be specified as members of a group. A group is usually used to group all neighbors in one autonomous system. Parameters specified on the group clause apply to all of the subsidiary neighbors unless explicitly overridden on a neighbor clause. Any number of group clauses 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:

peeras

Identifies the autonomous system number expected from peers in the group. If not specified, it will be learned dynamically.

localas

Identifies the autonomous system which GateD is representing to the group. The default is that which has been set globally in the autonomoussystem statement. This option is usually only used when masquerading as another autonomous system and its use is discouraged.

maxup

Specifies the number of neighbors GateD should acquire from this group. The default is to acquire all of the neighbors in the group. GateD will attempt to acquire the first maxup neighbors in the order listed. If one of the first neighbors is not available, it will acquire one further down the list. If after start-up GateD does manage to acquire the more desirable neighbor, it will drop the less desirable one.

neighbor neighbor_address

Each neighbor subclause defines one EGP neighbor within a group. The only part of the subclause that is required is the neighbor_address argument which is the symbolic host name or IP address of the neighbor. All other parameters are optional.

preference preference

Specifies the preference used for routes learned from these neighbors. This can differ from the default EGP preference set in the egp statement, so that GateD can prefer routes from one neighbor, or group of neighbors, over another. This preference may be explicitly overridden by import policy.

preference2 preference

In the case of a preference tie, the second preference, preference2 may be used to break the tie. The default value is 0.

metricout metric

This defines a metric to be used for all routes sent to this neighbor. The value overrides the default metric set in the egp statement and any metrics specified by export policy, but only for this specific neighbor or group of neighbors.

nogendefault

Prevents GateD from generating a default route when EGP receives a valid update from its neighbor. The default route is only generated when the gendefault option is enabled.

importdefault

Enables GateD to accept the default route (0.0.0.0) if it is included in a received EGP update. If not specified, the default route contained in an EGP update is ignored. For efficiency, some networks have external routers announce a default route to avoid sending large EGP update packets.

exportdefault

Enables GateD to include the default route (0.0.0.0) in EGP updates sent to this EGP neighbor. This allows the system to advertise the default route via EGP. Normally a default route is not included in EGP updates.

gateway gateway

If a network is not shared with a neighbor, gateway specifies a router on an attached network to be used as the next hop router for routes received from this neighbor. This option is only rarely used.

lcladdr local_address

Specifies the address to be used on the local end of the connection with the neighbor. The local address must be on an interface which is shared with the neighbor or with the gateway of the neighbor when the gateway parameter is used. A session will only be opened when an interface with the appropriate local address (through which the neighbor or gateway address is directly reachable) is operating.

sourcenet network

Specifies the network queried in the EGP Poll packets. By default this is the network shared with neighbors address specified. If there is no network shared with the neighbor, one of the network the neighbor is attached to should be specified. This parameter can also be used to specify a network shared with the neighbor other than the one on which the EGP packets are sent. This parameter is normally not needed.

p1 time

minhello time

Sets the minimum acceptable interval between the transmission of EGP HELLO packets. The default hello interval is 30 seconds. If the neighbor fails to respond to three hello packets, GateD stops trying to acquire the neighbor. Setting a larger interval gives the neighbor a better chance to respond. Minhello is an alias for the P1 value defined in the EGP specification.

p2 time

minpoll time

Sets the time interval between polls to the neighbor. The default is 120 seconds. If three polls are sent without a response, the neighbor is declared "down" and all routes learned from that neighbor are removed from the routing database. A longer polling interval supports a more stable routing database but is not as responsive to routing changes. Minpoll is an alias for the P2 value defined in the EGP specification.

ttl ttl

By default, GateD sets the IP TTL for local neighbors to one and the TTL for nonlocal neighbors to 255. This option is provided when attempting to communicate with improperly functioning routers that ignore packets sent with a TTL of one.

traceoptions trace_options

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

Tracing options

The state and policy options work with EGP.

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

packets

All EGP packets

hello

EGP HELLO/I-HEARD-U packets which are used to determine neighbor reachability.

acquire

EGP ACQUIRE/CEASE packets which are used to initiate and terminate EGP sessions.

update

EGP POLL/UPDATE packets which are used to request and receive reachability updates.

The BGP Protocol

The Border Gateway Protocol (BGP) is an exterior routing protocol used for exchanging routing information between autonomous systems. BGP is used for exchange of routing information between multiple transit autonomous systems as well as between transit and stub autonomous systems. BGP is related to EGP but operates with more capability, greater flexibility, and less required bandwidth. BGP uses path attributes to provide more information about each route, and in particular maintain an AS path, which includes the AS number of each autonomous system the route has transited, providing information sufficient to prevent routing loops in an arbitrary topology. Path attributes may also be used to distinguish between groups of routes to determine administrative preferences, allowing greater flexibility in determining route preference to achieve a variety of administrative ends.

BGP supports two basic types of sessions between neighbors, internal (sometimes referred to as IBGP) and external. Internal sessions are run between routers in the same autonomous system, while external sessions run between routers in different autonomous systems. When sending routes to an external peer the local AS number is prepended to the AS path, hence routes received from an external peer are guaranteed to have the AS number of that peer at the start of the path. Routes received from an internal neighbor will not in general have the local AS number prepended to the AS path, and hence will in general have the same AS path that the route had when the originating internal neighbor received the route from an external peer. Routes with no AS numbers in the path may be legitimately received from internal neighbors; these indicate that the received route should be considered internal to your own AS.

The BGP implementation supports three versions of the BGP protocol, versions 2, 3 and 4. BGP versions 2 and 3 are quite similar in capability and function. They will only propagate classed network routes, and the AS path is a simple array of AS numbers. BGP 4 will propagate fully general address-and-mask routes, and the AS path has some structure to represent the results of aggregating dissimilar routes.

External BGP sessions may or may not include a single metric, which BGP calls the Multi-Exit Discriminator, in the path attributes. For BGP versions 2 and 3 this metric is a 16-bit unsigned integer, for BGP version 4 it is a 32-bit unsigned integer. In either case smaller values of the metric are to be preferred. Currently this metric is only used to break ties between routes with equal preference from the same neighbor AS. Internal BGP sessions carry at least one metric in the path attributes, which BGP calls the LocalPref. The size of the metric is identical to the MED. For BGP versions 2 and 3 this metric is considered better when its value is smaller, for version 4 it is better when it is larger. BGP version 4 sessions may optionally carry a second metric on internal sessions, this being an internal version of the Multi-Exit Discriminator. The use of these metrics is dependent on the type of internal protocol processing which is specified.

BGP collapses routes with similar path attributes into a single update for advertisement. Routes that are received in a single update will be readvertised in a single update. The churn caused by the loss of a neighbor will be minimized and the initial advertisement sent during peer establishment will be maximally compressed. BGP does not read information from the kernel message-by-message, but fills the input buffer. It processes all complete messages in the buffer before reading again. BGP also does multiple reads to clear all incoming data queued on the socket. This feature may cause other protocols to be blocked for prolonged intervals by a busy peer connection.

All unreachable messages are collected into a single message and sent prior to reachable routes during a flash update. For these unreachable announcements, the next hop is set to the local address on the connection, no metric is sent and the path origin is set to incomplete. On external connections the AS path in unreachable announcements is set to the local AS, on internal connections the AS path is set to zero length.

The BGP implementation expects external peers to be directly attached to a shared subnet, and expects those peers to advertise next hops which are host addresses on that subnet (though this constraint can be relaxed by configuration for testing). For groups of internal peers, however, there are several alternatives which may be selected from by specifying the group type. Type internal groups expect all peers to be directly attached to a shared subnet so that, like external peers, the next hops received in BGP advertisements may be used directly for forwarding. Type routing groups instead will determine the immediate next hops for routes by using the next hop received with a route from a peer as a forwarding address. This forwarding address is used to look up an immediate next hop in routes of the IGP. Such groups support distant peers, but need to be informed of the IGP whose routes they are using to determine immediate next hops. Finally, type igp groups expect routes from the group peers to not be used for forwarding at all. Instead they expect that copies of the BGP routes received will also be received via an IGP, and that the BGP routes will only be used to determine the path attributes associated with the IGP routes. Such groups also support distant peers, and also need to be informed of the IGP they are running with.

For internal BGP group types (and for test groups), where possible a single outgoing message is built for all group peers based on the common policy. A copy of the message is sent to every peer in the group, with possible adjustments to the next hop field as appropriate to each peer. This minimizes the computational load of running large numbers of peers in these types of groups. BGP allows unconfigured peers to connect if an appropriate group has been configured with an allow clause.

The BGP Statement

bgp yes | no | on | off [ { preference preference ; defaultmetric metric ; traceoptions trace_options ; group type ( external peeras autonomous_system ) | ( internal peeras autonomous_system ) | ( igp peeras autonomous_system proto proto ) | ( routing peeras autonomous_system proto proto interface interface_list ) | ( test peeras autonomous_system ) { allow { network network mask mask network masklen number all host host } ; peer host [ metricout metric ] [ localas autonomous_system ] [ nogendefault ] [ gateway gateway ] [ preference preference ] [ preference2 preference ] [ lcladdr local_address ] [ holdtime time ] [ version number ] [ passive ] [ sendbuffer number ] [ recvbuffer number ] [ indelay time ] [ outdelay time ] [ keep [ all | none ] ] [ showwarnings ] [ noauthcheck ] [ noaggregatorid ] [ keepalivesalways ] [ v3asloopokay ] [ nov4asloop ] [ logupdown ] [ ttl ttl ] [ traceoptions trace_options ] ; } ; } ] ; external | internal | igp | test

The bgp statement enables or disables BGP. By default BGP is disabled. The default metric for announcing routes via BGP is not to send a metric.

preference preference

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

defaultmetric metric

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

traceoptions trace_options

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

Groups

BGP peers are grouped by type and the autonomous system of the peers. Any number of groups may be specified, but each must have a unique combination of type and peer autonomous system. There are four possible group types:

group type external peeras autonomous_system

In the classic external BGP group, full policy checking is applied to all incoming and outgoing advertisements. The external neighbors must be directly reachable through one of the 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.

group type internal peeras autonomous_system

An internal group operating where there is no IP-level IGP, for example an SMDS network or MILNET. All 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.

group type igp peeras autonomous_system proto proto

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.

group type routing peeras autonomous_system proto proto interface interface_list

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.

group type test peeras autonomous_system

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.

Group parameters

The BGP statement has group clauses and peer subclauses. Any number of peer subclauses may be specified within a group. A group clause usually defines default parameters for a group of peers, these parameters apply to all subsidiary peer subclauses. Any parameters from the peer subclause may be specified on the group clause to provide defaults for the whole group (which may be overridden for individual peers).

Specifying peers

Within a group, BGP peers may be configured in one of two ways. They may be explicitly configured with a peer statement, or implicitly configured with the allow statement. Both are described here:

allow

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

peer host

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.

Within each group clause, individual peers can be specified or a group of potential peers can be specified using allow. Allow is used to specify a set of address masks. If GateD receives a BGP connection request from any address in the set specified, it will accept it and set up a peer relationship.

Peer parameters

The BGP peer subclause allows the following parameters, which can also be specified on the group clause. All are optional.

metricout metric

If specified, this metric is used as the primary metric on all routes sent to the specified peer(s). This metric overrides the default metric, a metric specified on the group and any metric specified by export policy.

localas autonomous_system

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.

nogendefault

Prevents GateD from generating a default route when EGP receives a valid update from its neighbor. The default route is only generated when the gendefault option is enabled.

gateway gateway

If a network is not shared with a peer, gateway specifies a router on an attached network to be used as the next hop router for routes received from this neighbor. This parameter is not needed in most cases.

preference preference

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

preference2 preference

In the case of a preference tie, the second preference, preference2 may be used to break the tie. The default value is 0.

lcladdr local_address

Specifies the address to be used on the local end of the TCP connection with the peer. For external peers the local address must be on an interface 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.

holdtime time

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.

version version

Specifies the version of the BGP protocol to use with this peer. If not specified, the highest supported version is used first and version negotiation is attempted. If it is specified, only the specified version will be offered during negotiation. Currently supported version are 2, 3 and 4.

passive

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.

sendbuffer buffer_size

recvbuffer buffer_size

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.

indelay time

outdelay time

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.

keep all

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

showwarnings

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.

noauthcheck

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.

noaggregatorid

Causes GateD to specify the routerid in the aggregator attribute as zero (instead of its routerid) in order to prevent different routers in an AS from creating aggregate routes with different AS paths.

keepalivesalways

Causes gated to always send keepalives, even when an update could have correctly substituted for one. This allows interoperability with routers that do not completely obey the protocol specifications on this point.

v3asloopokay

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.

nov4asloop

Prevents routes with looped AS paths from being advertised to version 4 external peers. This can be useful to avoid advertising such routes to peer which would incorrectly forward the routes on to version 3 neighbors.

logupdown

Causes a message to be logged via the syslog mechanism whenever a BGP peer enters or leaves the ESTABLISHED state.

ttl ttl

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.

traceoptions trace_options

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

Tracing options

Note that the state option works with BGP, but does not provide true state transition information.

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

packets

All BGP packets

open

BGP OPEN packets which are used to establish a peer relationship.

update

BGP UPDATE packets which are used to pass network reachability information.

keepalive

BGP KEEPALIVE packets which are used to verify peer reachability.

The ICMP Statement

On systems without the BSD routing socket, gated listens to ICMP messages received by the system. Currently gated only does processing on ICMP redirect packets, but more functionality may be added in the future, such as support for the router discovery messages. Processing of ICMP redirect messages is handled by the redirect statement.

Currently the only reason to specify the icmp statement is to be able to trace the ICMP messages that gated receives.

The ICMP statement

icmp { traceoptions trace_options ; }

traceoptions trace_options ;

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

Tracing options

Packet tracing options (which may be modified with detail and recv):

packets

All ICMP packets received.

redirect

Only ICMP REDIRECT packets received.

routerdiscovery

Only ICMP ROUTER DISCOVERY packets received.

info

Only ICMP informational packets, which include mask request/response, info request/response, echo request/response and time stamp request/response.

error

Only ICMP error packets, which include time exceeded, parameter problem, unreachable and source quench.

Redirect Processing

The redirect code is passed ICMP or ISO redirects learned by monitoring ICMP messages, or via the routing socket on systems that support it. It processes the redirect request and decides whether to accept the redirect. If the redirect is accepted, a route is installed in the gated routing table with the protocol redirect. Redirects are deleted from the routing table after 3 minutes.

If GateD determines that a redirect is not acceptable, it tries to figure out if the kernel forwarding table has been modified. On systems where ICMP messages are monitored this is accomplished by trying to second guess what the kernel would have done with the redirect. On systems with the routing socket, the kernel provides and indication of whether the redirect was accepted; GateD ignores redirects that were not processed.

If GateD has determined that the state of the kernel forwarding table has been changed, the necessary requests to the kernel are made to restore the correct state.

Note that on currently available systems it is not possible to disable the processing of ICMP redirects, even when the system is functioning as a router. To ignore the effects of redirects, GateD must process each one and actively restore any changes it made to the state of the kernel. Because of the mechanisms involved, there will be windows where the effects of redirects are present in the kernel.

By default, GateD removes redirects when actively participating in an interior gateway protocol (RIP, HELLO, OSPF or IS-IS). It is not possible to enable redirects once they have been automatically disabled. Listening to RIP or HELLO in nobroadcast mode does not cause redirects to be ignored, nor does the use of EGP and BGP. Redirects must be manually configured off in these cases.

Note that in accordance with the latest IETF Router Requirements document, GateD insures that all ICMP net redirects are processed as host redirects. When an ICMP net redirect is accepted, GateD issues the requests to the kernel to make sure that the kernel forwarding table is updated to reflect a host redirect instead of a net redirect.

The redirect statement does not prevent the system from sending redirects, only from listening to them.

The Redirect Statement

redirect yes | no | on | off [ { preference preference ; interface interface_list [ noredirects ] | [redirects ] ; trustedgateways gateway_list ; traceoptions trace_options ; } ] ;

preference

Sets the preference for a route learned from a redirect. The default is 30.

interface interface_list

The interface statement allows the enabling and disabling of redirects on an interface-by-interface basis. See the section on interface list specification for the description of the interface_list. The possible parameters are:

noredirects

Specifies that redirects received via the specified interface will be ignored. The default is to accept redirects on all interfaces.

redirects

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

trustedgateways gateway_list

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.

traceoptions trace_options

There are no redirect-specific tracing options. All non-error messages are traced under the normal class.

Tracing options

There are no Redirect-specific tracing options. All nonerror messages are traced under the normal class.

The Router Discovery Protocol

The Router Discovery Protocol is an IETF standard protocol used to inform hosts of the existence of routers. It is intended to be used instead of having hosts wiretap routing protocols such as RIP. It is used in place of, or in addition to statically configured default routes in hosts.

The protocol is split into to portions, the server portion which runs on routers, and the client portion that runs on hosts. GateD treats these much like two separate protocols, only one of which may be enabled at a time.

The Router Discovery Server

The Router Discovery Server runs on routers and announces their existence to hosts. It does this by periodically multicasting or broadcasting a Router Advertisement to each interface on which it is enabled. These Router Advertisements contain a list of all the routers addresses on a given interface and their preference for use as a default router.

Initially these Router Advertisements occur every few seconds, then fall back to every few minutes. In addition, a host may send a Router Solicitation to which the router will respond with a unicast Router Advertisement (unless a multicast or broadcast advertisement is due momentarily).

Each Router Advertisement contains a Advertisement Lifetime field indicating for how long the advertised addresses are valid. This lifetime is configured such that another Router Advertisement will be sent before the lifetime has expired. A lifetime of zero is used to indicate that one or more addresses are no longer valid.

On systems supporting IP multicasting, the Router Advertisements are by default send to the all-hosts multicast address 224.0.0.1. However, the use of broadcast may be specified. When Router Advertisements are being sent to the all-hosts multicast address, or an interface is configured for the limited-broadcast address 255.255.255.255, all IP addresses configured on the physical interface are included in the Router Advertisement. When the Router advertisements are being sent to a net or subnet broadcast, only the address associated with that net or subnet is included.

The Router Discovery Server Statement

routerdiscovery server yes | no | on | off [ { traceoptions trace_options ; interface interface_list [ minadvinterval time ] [ maxadvinterval time ] [ lifetime time ] ; address interface_list [ advertise ] | [ ignore ] [ broadcast ] | [ multicast ] [ ineligible ] | [ preference preference ] ; } ] ;

traceoptions trace_options

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

interface interface_list

Specifies the parameters that apply to physical interfaces. Note a slight difference in convention from the rest of GateD, interface specifies just physical interfaces (such as le0, ef0 and en1), while address specifies protocol (in this case IP) addresses.

Interface parameters are:

maxadvinterval time

The maximum time allowed between sending broadcast or multicast Router Advertisements from the interface. Must be no less than 4 and no more than 30:00 (30 minutes or 1800 seconds). The default is 10:00 (10 minutes or 600 seconds).

minadvinterval time

The minimum time allowed between sending unsolicited broadcast or multicast Router Advertisements from the interface. Must be no less than 3 seconds and no greater than maxadvinterval. The default is 0.75 * maxadvinterval.

lifetime time

The lifetime of addresses in a Router Advertisement. Must be no less than maxadvinterval and no greater than 2:30:00 (two hours, thirty minutes or 9000 seconds). The default is 3 * maxadvinterval.

address interface_list

Specifies the parameters that apply to the specified set of addresses on 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.

advertise

Specifies that the specified address(es) should be included in Router Advertisements. This is the default.

ignore

Specifies that the specified address(es) should not be included in Router Advertisements.

broadcast

Specifies that the given address(es) should be included in a broadcast Router Advertisement because this system does not support IP multicasting, or some hosts on attached network do not support IP multicasting. It is possible to mix addresses on a physical interface such that some are included in a broadcast Router Advertisement and some are included in a multicast Router Advertisement. This is the default if the router does not support IP multicasting.

multicast

Specifies that the given address(es) should only be included in a multicast Router Advertisement. If the system does not support IP multicasting, the address(es) will not be included. If the system supports IP multicasting, the default is to include the address(es) in a multicast Router Advertisement if the given interface supports IP multicasting. If the given interface does not support IP multicasting, the address(es) will be included in a broadcast Router Advertisement.

preference preference

The preferability of the address(es) as a default router address, relative to other router addresses on the same subnet. A 32-bit, signed, twos-complement integer, with higher values meaning more preferable. Note that hex 80000000 may only be specified as ineligible. The default is 0.

ineligible

Specifies that the given address(es) will be assigned a preference of (hex 80000000) which means that it is not eligible to be the default route for any hosts.

This is useful when the address(es) should not be used as a default route, but are given as the next hop in an ICMP redirect. This allows the hosts to verify that the given addresses are up and available.

The Router Discovery Client

A host listens for Router Advertisements via the all-hosts multicast address (224.0.0.1) if IP multicasting is available and enabled, or on the interface broadcast address. When starting up, or when reconfigured, a host may send a few Router Solicitations to the all-routers multicast address, 224.0.0.2, or the interface broadcast address.

When a Router Advertisement with nonzero lifetime is received, the host installs a default route to each of the advertised addresses. If the preference ineligible, or the address is not on an attached interface, the route is marked unusable but retained. If the preference is usable, the metric is set as a function of the preference such that the route with the best preference is used. If more than one address with the same preference is received, the one with the lowest IP address will be used. These default routes are not exportable to other protocols.

When a Router Advertisement with a zero lifetime is received, the host deletes all routes with next-hop addresses learned from that router. In addition, any routers learned from ICMP redirects pointing to these addresses will be deleted. The same will happen when a Router Advertisement is not received to refresh these routes before the lifetime expires.

The Router Discovery Client Statement

routerdiscovery client yes | no | on | off [ { traceoptions trace_options ; preference preference ; interface interface_list [ enable ] | [ disable ] [ broadcast ] | [ multicast ] [ quiet ] | [ solicit ] ; } ] ;

traceoptions trace_options

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

preference preference ;

Specifies the preference of all Router Discovery default routes. The default is 55.

interface interface_list

Specifies the parameters that apply to physical interfaces. Note a slight difference in convention from the rest of GateD, interface specifies just physical interfaces (such as le0, ef0 and en1). The Router Discovery Client has no parameters that apply only to interface addresses.

enable

Specifies that Router Discovery should be performed on the specified interface(s). This is the default.

disable

Specifies that Router Discovery should not be performed on the specified interface(s).

broadcast

Specifies that Router Solicitations should be broadcast on the specified interface(s). This is the default if IP multicast support is not available on this host or interface.

multicast

Specifies that Router Solicitations should be multicast on the specified interface(s). If IP multicast is not available on this host and interface, no solicitation will be performed. The default is to multicast Router Solicitations if the host and interface support it. Otherwise Router Solicitations are broadcast.

quiet

Specifies that no Router Solicitations will be sent on this interface, even though Router Discovery will be performed.

solicit

Specifies that initial Router Solicitations will be sent on this interface. This is the default.

Tracing options

The Router Discovery Client and Server support the state trace flag which traces various protocol occurrences.

state

State transitions

The Router Discovery Client and Server do not directly support any packet tracing options, tracing of router discovery packets is enabled via the ICMP Statement.

The Kernel Statement

While the kernel interface is not technically a routing protocol, it has many characteristics of one, and GateD handles it similarly to one. The routes GateD chooses to install in the kernel forwarding table are those that will actually be used by the kernel to forward packets.

The add, delete and change operations GateD must use to update the typical kernel forwarding table take a nontrivial amount of time. This does not present a problem for older routing protocols (RIP, EGP), which are not particularly time critical and do not easily handle very large numbers of routes anyway. The newer routing protocols (OSPF, BGP) have stricter timing requirements and are often used to process many more routes. The speed of the kernel interface becomes critical when these protocols are used.

To prevent GateD from locking up for significant periods of time installing large numbers of routes (up to a minute or more has been observed on real networks), the processing of these routes is now done in batches. The size of these batches may be controlled by the tuning parameters described below, but normally the default parameters will provide the proper functionality.

During normal shutdown processing, GateD normally deletes all the routes it has installed in the kernel forwarding table, except for those marked with retain. Optionally, GateD can leave all routes in the kernel forwarding table by not deleting any routes. In this case changes will be made to insure that routes with a retain indication are installed in the table. This is useful on systems with large numbers of routes as it prevents the need to re-install the routes when GateD restarts. This can greatly reduce the time it takes to recover from a restart.

Forwarding tables and Routing tables

The table in the kernel that controls the forwarding of packets is a forwarding table, also know in ISO speak as a forwarding information base, or FIB. The table that GateD uses internally to store routing information it learns from routing protocols is a routing table, known in ISO speak as a routing information base, or RIB. The routing table is used to collect and store routes from various protocols. For each unique combination of network and mask an active route is chosen, this route will be the one with the best (numerically smallest) preference. All the active routes are installed in the kernel forwarding table. The entries in this table are what the kernel actually uses to forward packets.

Updating the Forwarding Table

There are two main methods of updating the kernel FIB, the ioctl() interface and the routing socket interface. Their various characteristics are described here.

Updating the Forwarding Table with the ioctl interface

The ioctl interface to the forwarding table was introduced in BSD 4.3 and widely distributed in BSD 4.3. This is a one-way interface, it only allows GateD to update the kernel forwarding table. It has several other limitations:

Fixed subnet masks

The BSD 4.3 networking code assumed that all subnets of a given network had the same subnet mask. This limitation is enforced by the kernel. The network mask is not stored in the kernel forwarding table, but determined when a packet is forwarded by searching for interfaces on the same network.

One way interface

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.

Blind updates

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.

Changes not supported

In all known implementations, there is no change operation supported, to change a route that exists in the kernel, the route must be deleted and a new one added.

Updating the Forwarding Table with the routing socket interface

The routing socket interface to the kernel forwarding table was introduced in BSD 4.3 Reno, widely distributed in BSD 4.3 Net/2 and improved in BSD 4.4. This interface is simply a socket, similar to a UDP socket, on which the kernel and GateD exchange messages. It has several advantages over the ioctl() interface:

Variable subnet masks

The network mask is passed to the kernel explicitly. This allows different masks to be used on subnets of the same network. It also allows routes with masks that are more general than the natural mask to be used. This is known as classless routing.

Two way interface

Not only is GateD able to change the kernel forwarding table with this interface, but the kernel can also report changes to the forwarding table to GateD. The most interesting of these is an indication that a redirect has modified the kernel forwarding table; this means that gated no longer needs to monitor ICMP messages to learn about redirects. Plus, there is an indication of whether the kernel processed the redirect, GateD can safely ignore redirect messages that the kernel did not process.

Updates visible

Changes to the routing table by other processes, including the route command are received via the routing socket. This allows GateD to insure that the kernel forwarding table is 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.

Changes supported

There is a functioning change message that allows routes in the kernel to be atomically changed. Some early versions of the routing socket code had bugs in the change message processing. There are compilation time and configuration time options that cause delete and add sequences to be used in lieu of change messages.

Expandable

New levels of kernel/GateD communications may be added by adding new message types.

Reading the Forwarding Table

When GateD starts up it reads the kernel forwarding table and installs corresponding routes in the routing table. These routes are called remnants and are timed out after a configured interval (which defaults to 3 minutes), or as soon as a more attractive route is learned. This allows forwarding to occur during the time it takes the routing protocols to start learning routes.

There are three main methods for reading the forwarding table from the kernel.

Reading forwarding table via kmem

On many systems, especially those based on BSD 4.3, GateD must have knowledge of the kernel data structures and can go into the kernel to read the current state of forwarding table. This method is slow and subject to error if the kernel forwarding table is updated while GateD is in the middle of reading it. This can happen if the system administrator uses the route command, or an ICMP redirect message is received while GateD is starting up.

Due to an oversight some systems, such as OSF/1, which are based on BSD 4.3 Reno or later, do not have the getkerninfo() system call described below which allows GateD to read routes from the kernel without know about kernel internal structures. On these systems it is necessary to read the kernel radix tree from the kernel by poking around in kernel memory. This is even more error prone than reading the hash based forwarding table.

Reading the forwarding table via getkerninfo/sysctl

Besides the routing socket, BSD 4.3 Reno introduced the getkerninfo() system call. This call allows a user process (of which GateD is one) to read various information from the kernel without knowledge of the kernel data structures. In the case of the forwarding table, it is returned to gated atomically as a series of routing socket messages. This prevents the problem associated with the forwarding table changing while GateD is in the process of reading it.

BSD 4.4 changed the getkerninfo() interface into the sysctl() interface, which takes different parameters, but otherwise functions identically.

Reading the forwarding table via OS specific methods

Some operating systems, for example SunOS 5, define their own method of reading the kernel forwarding table. The SunOS 5 version is similar in concept to the getkerninfo() method.

Reading the interface list

The kernel support subsystem of GateD is responsible for reading the status of the kernel physical and protocol interfaces periodically. GateD detects changes in the interface list and notifies the protocols so they can start or stop instances or peers. The interface list is read one of two ways:

Reading the interface list with SIOCGIFCONF

On systems based on BSD 4.3, 4.3 Reno and 4.3 Net/2 the SIOCGIFCONF ioctl interface is used to read the kernel interface list. Using this method a list of interfaces and some basic information about them is returned by the SIOCGIFCONF call. Other information must be learned by issuing other ioctls to learn the interface network mask, flags, MTU, metric, destination address (for point-to-point interfaces) and broadcast address (for broadcast capable interfaces).

GateD reads re-reads this list every 15 second looking for changes. When the routing socket is in use, it also re-reads it whenever a messages is received indicating a change in routing configuration. Receipt of a SIGUSR2 signal also causes GateD to re-read the list. This interval may be explicitly configured in the interface configuration.

Reading the interface list with sysctl

BSD 4.4 added the ability to read the kernel interface list via the sysctl system call. The interface status is returned atomically as a list of routing socket messages which GateD parses for the required information.

BSD 4.4 also added routing socket messages to report interface status changes immediately. This allows GateD to react quickly to changes in interface configuration.

When this method is in use, GateD re-reads the interface list only once a minute. It also re-reads it on routing table changes indications and when a SIGUSR2 is received. This interval may be explicitly configured in the interface configuration.

Reading interface physical addresses

Later version of the getkerninfo() and sysctl() interfaces return the interface physical addresses as part of the interface information. On most systems where this information is not returned, GateD scans the kernel physical interface list for this information for interfaces with IFF_BROADCAST set, assuming that their drivers are handled the same as Ethernet drivers. On some systems, such as SunOS 4 and SunOS 5, system specific interfaces are used to learn this information

The interface physical addresses are useful for IS-IS, for IP protocols, they are not currently used, but may be in the future.

Reading kernel variables

At startup, GateD reads some special variables out of the kernel. This is usually done with the nlist (or kvm_nlist) system call, but some systems use different methods.

The variables read include the status of UDP checksum creation and generation, IP forwarding and kernel version (for informational purposes). On systems where the routing table is read directly from kernel memory, the root of the hash table or radix tree routing table is read. On systems where interface physical addresses are not supplied by other means, the root of the interface list is read.

Special route flags

The later BSD based kernel support the special route flags described here.

RTF_REJECT

Instead of forwarding a packet like a normal route, routes with RTF_REJECT cause packets to be dropped and unreachable messages to be sent to the packet originators. This flag is only valid on routes pointing at the loopback interface.

RTF_BLACKHOLE

Like the RTF_REJECT flag, routes with RTF_BLACKHOLE cause packets to be dropped, but unreachable messages are not sent. This flag is only valid on routes pointing at the loopback interface.

RTF_STATIC

When GateD starts, it reads all the routes currently in the kernel forwarding table. Besides interface routes, it usually marks everything else as a remnant from a previous run of GateD and deletes it after a few minutes. This means that routes added with the route command 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.

Kernel Configuration

kernel { options [ nochange ] [ noflushatexit ] [ remnantholdtime time ] ; routes number ; flash [ limit number ] [ type interface | interior | all ] ; background [ limit number ] [ priority flash | higher | lower ] ; traceoptions trace_options ; } ;

options option_list

Configure kernel options. The valid options are:

nochange

On systems supporting the routing socket this insures that changes operations will not be performed, only deletes and adds. This is useful on early versions of the routing socket code where the change operation was broken.

noflushatexit

During normal shutdown processing GateD deletes all routes from the kernel forwarding table that do not have a retain indication. The noflushatexit option prevents route deletions at shutdown. Instead, routes are changed and added to make sure that all the routes marked with retain get installed.

This is handy on systems with thousands of routes. Upon startup GateD will notice which routes are in the kernel forwarding table and not have add them back.

remnantholdtime time

Normally remnant routes read from the kernel forwarding table at startup are timed out in three minutes or as soon as they are overridden. This option allows the interval to be configured to a value between zero and 15 minutes. Setting it to zero causes these routes to be deleted immediately.

routes number

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.

flash

When routes change, the process of notifying the protocols is called a flash update. The kernel forwarding table interface is the first to be notified. Normally a maximum of 20 interface routes may be processed during one flash update. The flash command allows tuning of these parameters.

limit number

Specifies the maximum number of routes which may be processed during one flash update. The default is 20. A value of -1 will cause all pending route changes of the specified type to be processed during the flash update.

type interface | interior | all

Specifies the type of routes that will be processed during a flash update. Interior specifies that interior routes (See the definition of interior gateway protocols) will also be installed. All specifies the inclusion of exterior routes (See the definition of exterior gateway protocols) as well. The default is interface which specifies that only interface routes will be installed during a flash update.

Specifying flash limit -1 all causes all routes to be installed during the flash update; this mimics the behavior of previous versions of GateD.

background

Since only interface routes are normally installed during a flash update, the remaining routes are processed in batches in the background, that is, when no routing protocol traffic is being received. Normally, 120 routes are installed at a time to allow other tasks to be performed and this background processing is done at lower priority than flash updates the following parameters allow tuning of these parameters:

limit number

Specifies the number of route which may be processed at during one batch. The default is 120.

priority flash | higher | lower

Specifies the priority of the processing of batches of kernel updates in relationship to the flash update processing. The default is lower which means that flash updates are processed first. To process kernel updates at the same priority as flash updates, specify flash; to process them at a lower priority, use lower.

Tracing options

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

symbols

Symbols read from the kernel, by nlist() or similar interface.

iflist

Interface list scan. This option is useful when entered from the command line as the first interface list scan is performed before the configuration file is parsed.

The following tracing options may only be specified in the configuration file. They are not valid from the command line.

remnants

Routes read from the kernel when GateD starts.

request

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

Static Statements

Static statements define the static routes used by GateD. A single static statement can specify any number routes. The static statements occur after protocol statements and before control statements in the gated.conf file. Any number of static statements may be specified, each containing any number of static route definitions. These routes can be overridden by routes with better preference values.

static { ( host host ) | default | ( network [ ( mask mask ) | ( masklen number ) ] ) gateway gateway_list [ interface interface_list ] [ preference preference ] [ retain ] [ reject ] [ blackhole ] [ noinstall ] ; ( network [ ( mask mask ) | ( masklen number ) ] ) interface interface [ preference preference ] [ retain ] [ reject ] [ blackhole ] [ noinstall ] ; } ;

host host gateway gateway_list

( network [ ( mask mask ) | ( masklen number ) ] )

default gateway gateway_list

This is the most general form of the static statement. It defines a static route through one or more gateways. Static routes are installed when one or more of the gateways listed are available on directly attached interfaces. If more than one eligible gateways are available, they are limited by the number of multipath destinations supported (this compile time parameter is currently almost always one on Unix).

Parameters for static routes are:

interface interface_list

When this parameter is specified, gateways are only considered valid when they are on one of these interfaces.See the section on interface list specification for the description of the interface_list.

preference preference

This option selects the preference of this static route. The preference controls how this route competes with routes from other protocols. The default preference is 60.

retain

Normally gated removes all routes except interface routes from the kernel forwarding table during a graceful shutdown. The retain option may be used to prevent specific static routes from being removed. This is useful to insure that some routing is available when gated is not running.

reject

Instead of forwarding a packet like a normal route, reject routes cause packets to be dropped and unreachable messages to be sent to the packet originators. Specifying this option causes this route to be installed as a reject route. Not all kernel forwarding engines support reject routes.

blackhole

A blackhole route is the same as a reject route except that unreachable messages are not supported.

noinstall

Normally the route with the lowest preference is installed in the kernel forwarding table and is the route exported to other protocols. When noinstall is specified on a route, it will not be installed in the kernel forwarding table when it is active, but it will still be eligible to be exported to other protocols.

( network [ ( mask mask ) | ( masklen number ) ] ) interface interface

This form defines a static interface route which is used for primitive support of multiple network addresses on one interface. The preference, retain, reject, blackhole and noinstall options are the same as described above.

Control Statements Overview

Control statements control routes that are imported from routing peers and routes that are exported to these peers. These are the final statements to be included in the gated.conf file. The control statements are:

  • the Import Statement

  • the Export Statement

  • the Aggregate Statement

  • the Generate Statement

Route Filtering

Routes are filtered by specifying configuration language that will match a certain set of routes by destination, or by destination and mask. Among other places, route filters are used on martians, import and export statements.

The action taken when no match is found is dependent on the context, for instance import and export route filters assume an all reject ; at the end a list.

A route will match the most specific filter that applies. Specifying more than one filter with the same destination, mask and modifiers will generate an error.

Filtering syntax

network [ exact | refines ] network mask mask [ exact | refines ] network masklen number [ exact | refines ] all default host host

These are all the possible formats for a route filter. Not all of these formats are available in all places, for instance the host and default formats are not valid for martians.

In most cases it is possible to specify additional parameters relevant to the context of the filter. For example, on a martian statement it is possible to specify the allow keyword, on an import statement you can specify a preference, and on a export you can specify a metric.

network [ exact | refines ]

network mask mask [ exact | refines ]

network masklen number [ exact | refines ]

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:

exact

This parameter specifies that the mask of the destination must match the supplied mask exactly. This is used to match a network, but no subnets or hosts of that network.

refines

Specifies that the mask of the destination must be more specified (longer) than the filter mask. This is used to match subnets and/or hosts of a network, but not the network.

all

This entry matches anything. It is equivalent to:

0.0.0.0 mask 0.0.0.0

default

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

0.0.0.0 mask 0.0.0.0 exact

host host

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:

host mask 255.255.255 exact

Matching AS paths

An AS path is a list of autonomous_systems that routing information has passed through to get to this router, and an indicator of the origin of the AS path. This information can be used to prefer one path to a destination network over another. The primary method for doing this with GateD is to specify a list of patterns to be applied to AS paths when importing and exporting routes.

Each autonomous system that a route passed through prepends its AS number to the beginning of the AS path.

The origin information details the completeness of AS path information. An origin of igp indicates the route was learned from an interior routing protocol and is most likely complete. An origin of egp indicates the route was learned from an exterior routing protocol that does not support AS paths (EGP for example) and the path is most likely not complete. When the path information is definitely not complete, an origin of incomplete is used.

AS path regular expressions are defined in RFC 1164 section 4.2.

AS path matching syntax

An AS path is matched using the following syntax.

aspath aspath_regexp origin any | ( [ igp ] [egp ] [ incomplete ] )

This specifies that an AS matching the aspath_regexp with the specified origin is matched.

AS path regular expressions

Technically, an AS path regular expression is a regular expression with the alphabet being the set of AS numbers. An AS path regular expression is composed of one or more AS paths expressions. An AS path expressions is composed of AS path terms and AS path operators.

AS path terms

An AS path term is one of the following three objects:

autonomous_system . ( aspath_regexp )

where

autonomous_system

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

.

Matches any autonomous system number.

( aspath_regexp )

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

AS path operators

An AS path operator is one of the following:

aspath_term {m,n} aspath_term {m} aspath_term {m,} aspath_term * aspath_term + aspath_term ? aspath_term | aspath_term

aspath_term {m,n}

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

aspath_term {m}

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

aspath_term {m,}

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

aspath_term *

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

aspath_term +

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

aspath_term ?

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

aspath_term | aspath_term

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

The Import Statement

Importation of routes from routing protocols and installation of the routes in the GateD routing database is controlled by import statements. The format of an import statement varies depending on the source protocol.

Specifying preferences

In all cases, one of two keywords may be specified to control how routes compete with other protocols:

restrict preference preference

restrict

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

preference preference

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

Route Filters

All the formats allow route filters as shown below. See the section on route filters for a detailed explanation of how they work. When no route filtering is specified (when restrict is specified on the first line of a statement), all routes from the specified source will match that statement. If any filters are specified, only routes that match the specified filters will be imported. Put differently, if any filters are specified, an all restrict; is assumed at the end of the list.

network [ exact | refines ] network mask mask [exact | refines ] network masklen number [ exact | refines ] default host host

Importing routes from BGP and EGP

import proto bgp | egp autonomoussystem autonomous_system restrict ; import proto bgp | egp autonomoussystem autonomous_system [ preference preference ] { route_filter [ restrict | ( preference preference ) ] ; } ; import proto bgp aspath aspath_regexp origin any | ( [ igp ] [egp ] [ incomplete ] ) restrict ; import proto bgp aspath aspath_regexp origin any | ( [ igp ] [egp ] [ incomplete ] ) [ preference preference ] { route_filter [ restrict | ( preference preference ) ] ; } ;

EGP importation may be controlled by autonomous system. BGP also supports controlling propagation by the use of an AS path regular expressions, which are documented in the section on Matching AS paths. Note that EGP and BGP versions 2 and 3 only support the propagation of natural networks, so the host and default route filters are meaningless. BGP version 4 supports the propagation of any destination along with a contiguous network mask.

EGP and BGP both store any routes that were rejected implicitly by not being mentioned in a route filter, or explicitly with the restrict keyword in the routing table with a negative preference. A negative preference prevents a route from becoming active, which prevents it from being installed in the forwarding table, or exported to other protocols. This alleviates the need to break and re-establish a session upon reconfiguration if importation policy is changed.

Importing routes from an RIP, HELLO and Redirects

import proto rip | hello | redirect [ ( interface interface_list ) | (gateway gateway_list ) ] restrict ; import proto rip | hello | redirect [ ( interface interface_list ) | (gateway gateway_list ) ] [ preference preference ] { route_filter [ restrict | ( preference preference ) ] ; } ;

The importation of RIP, HELLO and Redirect routes may be controlled by any of protocol, source interface and source gateway. If more than one is specified, they are processed from most general (protocol) to most specific (gateway).

RIP and HELLO do not support the use of preference to choose between routes of the same protocol. That is left to the protocol metrics. These protocols do not save routes that were rejected since they have short update intervals.

Importing routes from OSPF

import proto ospfase [ tag ospf_tag ] restrict ; import proto ospfase [ tag ospf_tag ] [ preference preference ] { route_filter [ restrict | ( preference preference ) ] ; } ;

Due to the nature of OSPF, only the importation of ASE routes may be controlled. OSPF intra- and inter-area routes are always imported into the gated routing table with a preference of 10. If a tag is specified, the import clause will only apply to routes with the specified tag.

It is only possible to restrict the importation of OSPF ASE routes when functioning as an AS border router. This is accomplished by specifying an export ospfase clause. Specification of an empty export clause may be used to restrict importation of ASEs when no ASEs are being exported.

Like the other interior protocols, preference can not be used to choose between OSPF ASE routes, that is done by the OSPF costs. Routes that are rejected by policy are stored in the table with a negative preference.

The Export Statement

The import statement controls which routes received from other systems are used by GateD, and the export statement controls which routes are advertised by GateD to other systems. Like the import statement, the syntax of the export statement varies slightly per protocol. The syntax of the export statement is similar to the syntax of the import statement, and the meanings of many of the parameters are identical. The main difference between the two is that while route importation is just controlled by source information, route exportation is controlled by both destination and source.

The outer portion of a given export statement specifies the destination of the routing information you are controlling. The middle portion restricts the sources of importation that you wish to consider. And the innermost portion is a route filter used to select individual routes.

Specifying metrics

The most specific specification of a metric is the one applied to the route being exported. The values that may be specified for a metric depend on the destination protocol that is referenced by this export statement.

restrict metric metric

restrict

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

metric metric

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

Route Filters

All the formats allow route filters as shown below. See the section on route filters for a detailed explanation of how they work. When no route filtering is specified (when restrict is specified on the first line of a statement), all routes from the specified source will match that statement. If any filters are specified, only routes that match the specified filters will be exported. Put differently, if any filters are specified, an all restrict ; is assumed at the end of the list.

network [ exact | refines ] network mask mask [exact | refines ] network masklen number [ exact | refines ] default host host

Specifying the destination

As mentioned above, the syntax of the export statement varies depending on the protocol it is being applied to. One thing that applies in all cases is the specification of a metric. All protocols define a default metric to be used for routes being exported, in most cases this can be overridden at several levels of the export statement.

The specification of the source of the routing information being exported (the export_list) is described below.

Exporting to EGP and BGP

export proto bgp | egp as autonomous system restrict ; export proto bgp | egp as autonomous system [ metric metric ] { export_list ; } ;

Exportation to EGP and BGP is controlled by autonomous system, the same policy is applied to all routers in the AS. EGP metrics range from 0 to 255 inclusive with 0 being the most attractive.

BGP metrics are 16 bit unsigned quantities. They range from 0 to 65535 inclusive with 0 being the most attractive. While BGP version 4 actually supports 32 bit unsigned quantities, GateD does not yet support this.

If no export policy is specified, only routes to attached interfaces will be exported. If any policy is specified, the defaults are overridden; it is necessary to explicitly specify everything that should be exported.

Note that EGP and BGP versions 2 and 3 only support the propagation of natural networks, so the host and default route filters are meaningless. BGP version 4 supports the propagation of any destination along with a contiguous network mask.

Exporting to RIP and HELLO

export proto rip | hello [ ( interface interface_list ) | (gateway gateway_list ) ] restrict ; export proto rip | hello [ ( interface interface_list ) | (gateway gateway_list ) ] [ metric metric ] { export_list ; } ;

Exportation to RIP and HELLO is controlled by any of protocol, interface or gateway. If more than one is specified, they are processed from most general (protocol) to most specific (gateway).

It is not possible to set metrics for exporting RIP routes into RIP, or exporting HELLO routes into HELLO. Attempts to do this are silently ignored.

If no export policy is specified, RIP and interface routes are exported into RIP and HELLO and interface routes are exported into HELLO. If any policy is specified, the defaults are overridden. It is necessary to explicitly specify everything that should be exports.

RIP version 1 and HELLO assume that all subnets of the shared network have the same subnet mask so they are only able to propagate subnets of that network. RIP version 2 removes that restriction and is capable of propagating all routes when not sending version 1 compatible updates.

To announce routes which specify a next hop of the loopback interface (static and internally generated default routes) via RIP or HELLO, it is necessary to specify the metric at some level in the export clause. Just setting a default metric for RIP or HELLO is not sufficient. This is a safeguard to verify that the announcement is intended.

Exporting to OSPF

export proto ospfase [ type 1 | 2 ] [ tag ospf_tag ] restrict ; export proto osfpase [ type 1 | 2 ] [ tag ospf_tag ] [ metric metric ] { export_list ; } ;

It is not possible to create OSPF intra- or inter-area routes by exporting routes from the GateD routing table into OSPF. It is only possible to export from the GateD routing table into OSPF ASE routes. It is also not possible to control the propagation of OSPF routes within the OSPF protocol.

There are two types of OSPF ASE routes, type 1 and type 2, see the OSPF protocol configuration for a detailed explanation of the two types. The default type is specified by the defaults subclause of the ospf clause. This may be overridden by a specification on the export statement.

OSPF ASE routes also have the provision to carry a tag. This is an arbitrary 32 bit number that can be used on OSPF routers to filter routing information. See the OSPF protocol configuration for detailed information on OSPF tags. The default tag specified by the ospf defaults clause may be overridden by a tag specified on the export statement.

Specifying the source

The export list specifies export based on the origin of a route and the syntax varies depending on the source.

Exporting BGP and EGP routes

proto bgp | egp autonomoussystem autonomous_system restrict ; proto bgp | egp autonomoussystem autonomous_system [ metric metric ] { route_filter [ restrict | ( metric metric ) ] ; } ;

BGP and EGP routes may be specified by source autonomous system. All routes may be exported by as path, see below for more information.

Exporting RIP and HELLO routes

proto rip | hello [ ( interface interface_list ) | (gateway gateway_list ) ] restrict ; proto rip | hello [ ( interface interface_list ) | (gateway gateway_list ) ] [ metric metric ] { route_filter [ restrict | ( metric metric ) ] ; } ;

RIP and HELLO routes may be exported by protocol, source interface and/or source gateway.

Exporting OSPF routes

proto ospf | ospfase restrict ; proto ospf | ospfase [ metric metric ] { route_filter [ restrict | ( metric metric ) ] ; } ;

Both OSPF, and OSPF ASE routes may be exported into other protocols. See below for information on exporting by tag.

Exporting routes from nonrouting protocols

Nonrouting with interface

proto direct | static | kernel [ (interface interface_list ) ] restrict ; proto direct | static | kernel [ (interface interface_list ) ] [ metric metric ] { route_filter [ restrict | ( metric metric ) ] ; } ;

These protocols may be exported by protocol, or by the interface of the next hop. These protocols are:

direct

Routes to directly attached interfaces.

static

Static routes specified in a static clause.

kernel

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.

Nonrouting by protocol

proto default | aggregate restrict ; proto default | aggregate [ metric metric ] { route_filter [ restrict | ( metric metric ) ] ; } ;

These protocols may only be referenced by protocol.

default

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

aggregate

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

Exporting by AS path

proto proto | all aspath aspath_regexp origin any | ( [ igp ] [egp ] [ incomplete ] ) restrict ; proto proto | all aspath aspath_regexp origin any | ( [ igp ] [egp ] [ incomplete ] ) [ metric metric ] { route_filter [ restrict | ( metric metric ) ] ; } ;

When BGP is configured, all routes are assigned an AS path when they are added to the routing table. For all interior routes this AS path specifies IGP as the origin and no ASes in the AS path (the current AS is added when the route is exported). For EGP routes this AS path specifies EGP as the origin and the source AS as the AS path. For BGP routes, the AS path is stored as learned from BGP.

AS path regular expressions are documented in the section on Matching AS paths.

Exporting by route Tag

proto proto | all tag tag restrict ; proto proto | all tag tag [ metric metric ] { route_filter [ restrict | ( metric metric ) ] ; } ;

Both OSPF and RIP version 2 currently support tags, all other protocols always have a tag of zero. The source of exported routes may be selected based on this tag. This is useful when routes are classified by tag when the are exported into a given routing protocol.

Route Aggregation

Route aggregation is a method of generating a more general route given the presence of a specific route. It is used, for example, at an autonomous system border to generate a route to a network to be advertised via EGP given the presence of one or more subnets of that network learned via RIP. Older versions of GateD automatically performed this function, generating an aggregate route to a natural network (using the old Class A, B and C concept) given an interface to a subnet of that natural network. However that was not always the correct thing to do, and with the advent of classless interdomain routing it is even more frequently the wrong thing to do, so aggregation must be explicitly configured. No aggregation is performed unless explicitly requested in an aggregate statement.

Route aggregation is also used by regional and national networks to reduce the amount of routing information passed around. With careful allocation of network addresses to clients, regional networks can just announce one route to regional networks instead of hundreds.

Aggregate routes are not actually used for packet forwarding by the originator of the aggregate route, only by the receiver (if it wishes). A router receiving a packet which does not match one of the component routes which led to the generation of an aggregate route is supposed to respond with an ICMP network unreachable message. This is to prevent packets for unknown component routes from following a default route into another network where they would be forwarded back to the border router, and around and around again and again, until their TTL expires. Sending an unreachable message for a missing piece of an aggregate is only possible on systems with support for reject routes.

A slight variation of aggregation is the generation of a route based on the existence of certain conditions. This is sometimes known as the route of last resort. This route inherits the next hops and aspath from the contributor specified with the lowest (most favorable) preference. The most common usage for this is to generate a default based on the presence of a route from a peer on a neighboring backbone.

Aggregation and Generation syntax

aggregate default | ( network [ ( mask mask ) | ( masklen number ) ] ) [ preference preference ] [ brief ] { proto [ all | direct | static | kernel | aggregate | proto ] [ ( as autonomous system ) | ( tag tag ) | ( aspath aspath_regexp ) ] restrict ; proto [ all | direct | static | kernel | aggregate | proto ] [ ( as autonomous system ) | ( tag tag ) | ( aspath aspath_regexp ) ] [ preference preference ] { route_filter [ restrict | ( preference preference ) ] ; } ; } ; generate default | ( network [ ( mask mask ) | ( masklen number ) ] ) [ preference preference ] { [ ( as autonomous system ) | ( tag tag ) | ( aspath aspath_regexp ) ] restrict ; proto [ all | direct | static | kernel | aggregate | proto ] [ ( as autonomous system ) | ( tag tag ) | ( aspath aspath_regexp ) ] [ preference preference ] { route_filter [ restrict | ( preference preference ) ] ; } ; } ;

Routes that match the route filters are called contributing routes. They are ordered according to the aggregation preference that applies to them. If there are more than one contributing routes with the same aggregating preference, the preferences of the route are used to order the routes. The preference of the aggregate route will be that of the contributing route with the lowest aggregate preference.

preference preference

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

brief

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

proto proto

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

as autonomous_system

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

tag tag

Restrict selection of routes to those with the specified tag.

aspath aspath_regexp

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

restrict

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

route_filter

See below.

A route may only contribute to an aggregate route which is more general than itself; it must match the aggregate under its mask. Any given route may only contribute to one aggregate route, which will be the most specific configured, but an aggregate route may contribute to a more general aggregate.

Route Filters

All the formats allow route filters as shown below. See the section on route filters for a detailed explanation of how they work. When no route filtering is specified (when restrict is specified on the first line of a statement), all routes from the specified source will match that statement. If any filters are specified, only routes that match the specified filters will be considered as contributors. Put differently, if any filters are specified, an all restrict ; is assumed at the end of the list.

network [ exact | refines ] network mask mask [exact | refines ] network masklen number [ exact | refines ] default host host

Glossary of Terms

Terms used in descriptions throughout this document are defined below:

adjacency

A relationship formed between selected neighboring routers for the purpose of exchanging routing information. Not every pair of neighboring routers becomes adjacent.

autonomous system

A set of routers under a single technical administration, using an interior gateway protocol and common metrics to route packets within the AS, and using an exterior gateway protocol to route packets to other ASs. Since this classic definition was developed, it has become common for a single AS to use several interior gateway protocols and sometimes several sets of metrics within an AS. The use of the term Autonomous System stresses that even when multiple igps and metrics are used, the administration of an AS appears to other ASs to have a single coherent interior routing plan and presents a consistent picture of what networks are reachable through it. The AS is represented by a number between 1 and 65534, assigned by the Internet Assigned Numbers Authority.

BGP

Border Gateway Protocol

One of a class of exterior gateway protocols, described in more detail in the BGP section of the Protocol Overview.

cost

An OSPF metric. See metric.

delay

A HELLO metric. Valid values are from zero to 30000 inclusive. The value of 30000 is the maximum metric and means unreachable. See metric.

designated router

OSPF: Each multiaccess network that has at least two attached routers as a designated router. The designated router generates a link state advertisement for the multiaccess network and assists in running the protocol. The designated router is elected by the HELLO protocol.

destination

Any network or any host.

distance

An EGP metric. See metric. Valid values are from zero to 255 inclusive.

egp

exterior gateway protocol

exterior routing protocol

A class of routing protocols used to exchange routing information within an autonomous system. A detailed explanation of exterior gateway protocols is available in the Protocol Overview.

EGP

Exterior Gateway Protocol

One of a class of exterior gateway protocols, described in more detail in the EGP section of the Protocol Overview.

gateway

An intermediate destination by which packets are delivered to their ultimate destination. A host address of another router that is directly reachable via an attached network. As with any host address it may be specified symbolically.

gateway_list

A list of one or more gateways separated by white space.

HELLO

One of a class of interior gateway protocols, described in more detail in the HELLO section of the Protocol Overview.

host

The IP address of any host. Usually specified as a dotted quad, four values in the range of 0 to 255 inclusive separated by dots (.). For example 132.236.199.63 or 10.0.0.51. It may also be specified as an eight digit hexadecimal string preceded by 0x. For example 0x???????? or 0x0a000043. Finally, if options noresolv is not specified, a symbolic hostname. For example gated.cornell.edu or nic.ddn.mil. The numeric forms are much preferred over the symbolic form.

interface

The host address of an attached interface. This is the address of a broadcast, nbma or loopback interface and the remote address of a point-to-point interface. As with any host address it may be specified symbolically.

interface

The connection between a router and one of its attached networks. A physical interface may be specified by a single IP address, domain name, or interface 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. Dynamic interfaces can be added or deleted and indicated as up or down as well as changes to address, netmask and metric parameters.

igp

interior gateway protocol

interior routing protocol

One of a class of routing protocols used to exchange routing information within an autonomous system. A detailed explanation of interior gateway protocols is available in the Protocol Overview.

interface_list

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. See the section on interface lists for more information.

IS-IS

One of a class of interior gateway protocols.

local_address

The host address of an attached interface. This is the address of a broadcast, nbma or loopback interface and the local address of a point-to-point interface. As with any host address it may be specified symbolically.

mask

A means of subdividing networks using address modification. A mask is a dotted quad specifying which bits of the destination are significant. Except when used in a route filter, GateD only supports contiguous masks.

mask length

The number of significant bits in the mask.

metric

One of the units used to help a system determine the best route. Metrics may be based on hop count, routing delay, or an arbitrary value set by the administrator depending on the type of routing protocol. Routing metrics may influence the value of assigned internal preferences. (See preference.)

This sample table shows the range of possible values for each routing protocol metric and the value used by each protocol (See Protocol Overview.) to reach a destination.

SAMPLE ROUTING PROTOCOL METRICS Protocol Metric Represents Range Unreachable -------- ----------------- ----- ----------- RIP distance (hop-count) 0-15 16 HELLO delay (milliseconds) 0-29999 30000 OSPF cost of path 0-????? Delete ISIS cost of path 0-254 Delete EGP distance (unused) 0-65535 255 BGP unspecified 0-65534 65535

multiaccess networks

Those physical networks that support the attachment of multiple (more than two) routers. Each pair of routers on such a network is assumed to be able to communicate directly.

natural mask

The format of an IP address contains the network address and the host address. The natural mask is a default value applied to the 3 class addresses:

0xff000000 for class A (network.host.host.host), 0xffff0000 for class B (network.network.host.host) and 0xffffff00 for class C (network.network.network.host).

neighbor

Another router which with implicit or explicit communication is established by a routing protocol. Neighbors are usually on a shared network, but not always. This term is mostly used in OSPF and EGP. Usually synonymous with peer.

neighboring routers

Two routers that have interfaces to a common network. On multiaccess networks, routers are dynamically discovered by the OSPF HELLO protocol.

network

Any packet-switched network. A network may be specified by its IP address or network name. The host bits in a network specification must be zero. Default may be used to specify the default network (0.0.0.0).

network

The IP address of a network. Usually specified as a dotted quad, one to four values in the range of 0 to 255 inclusive separated by dots (.). For example 132.236.199, 132.236 or 10. It may also be specified as a hexadecimal string preceded by 0x with an even number of digits between two and eight. For example 0x??????, 0x???? or 0x0a. Also allowed is the symbolic value default which has the distinguished value 0.0.0.0, the default network. If options noresolv is not specified, a symbolic network name can be used, for example nr-tech-prod, cornellu-net and arpanet. The numeric forms are much preferred over the symbolic form.

number

A positive integer.

OSPF

Open Shortest Path First

One of a class of interior gateway protocols, described in more detail in the OSPF section of the Protocol Overview.

ospf_area

peer

Another router which with implicit or explicit communication is established by a routing protocol. Peers are usually on a shared network, but not always. This term is mostly used by BGP. Usually synonymous with neighbor.

port

A UDP or TCP port number. Valid values are from 1 through 65535 inclusive.

preference

A preference is a value between 0 (zero) and 255 used to select between many routes to the same destination. The route with the best (numerically lowest) preference is as the active route. The active route is the one installed in the kernel forwarding table and exported to other protocols. Preference zero is usually reserved for routes to directly attached interfaces. A default preference is assigned to each source from which GateD receives routes. (See Preference.)

prefix

A contiguous mask covering the most significant bits of an address. The prefix length specifies how many bits are covered.

QoS

quality of service

The OSI equivalent of TOS.

RIP

Routing Information Protocol

One of a class of interior gateway protocols, described in more detail in the RIP section of the Protocol Overview.

router id

A 32-bit number assigned to each router running the OSPF protocol. This number uniquely identifies the router within the autonomous system.

router_id

An IP address used as unique identifier assigned to represent a specific router. This is usually the address of an attached interface.

RIB

routing information base

routing database

routing table

The repository of all of the GateD retained routing information, used to make decisions and as a source for routing information which is propagated.

simplex

An interface may be marked as simplex either by the kernel, or by interface configuration. A simplex interface is an interface on a broadcast media that is not capable of receiving packets it broadcasts.

GateD takes advantage of interfaces that are capable of receiving their own broadcast packets to monitor whether an interface appears to be functioning properly.

time

A time value, usually a time interval. It may be specified in any one of the following forms:

number

A nonnegative decimal number of seconds. For example, 27, 60 or 3600.

number:number

A nonnegative decimal number of minutes followed by a seconds value in the range of zero to 59 inclusive. For example, 0:27, 1:00 or 60:00.

number:number:number

A nonnegative decimal number of hours followed by a minutes value in the range of zero to 59 inclusive followed by a seconds value in the range of zero to 59 inclusive. For example, 0:00:27, 0:01:00 or 1:00:00.

time to live

ttl

The Time To Live (TTL) of an IP packet. Valid values are from one (1) through 255 inclusive.

TOS

type of service

The type of service is for internet service quality selection. The type of service is specified along the abstract parameters precedence, delay, throughput, reliability, and cost. These abstract parameters are to be mapped into the actual service parameters of the particular networks the datagram traverses. The vast majority of IP traffic today uses the default type of service.

WARNINGS

gated contains provisions for BGP protocol, but it is not officially supported by HP at the present time. The route aggregation and generation statements which generate a more general route from compressing the specific routes through the explicit configuration are not supported in this release.

AUTHOR

See gated(1M).

SEE ALSO

RFC 827:

E. Rosen, Exterior Gateway Protocol EGP

RFC 891:

D. Mills, DCN local-network protocols

RFC 904:

D. Mills, Exterior Gateway Protocol formal specification

RFC 1058:

C. Hedrick, Routing Information Protocol

RFC 1105:

K. Lougheed, Y. Rekhter, Border Gateway Protocol BGP

RFC 1163:

K. Lougheed, Y. Rekhter, A Border Gateway Protocol (BGP)

RFC 1164:

J. Honig, D. Katz, M. Mathis, Y. Rekhter, J. Yu, Application of the Border Gateway Protocol in the Internet

RFC 1227:

M. Rose, SNMP MUX Protocol and MIB.

RFC 1245:

J. Moy, OSPF Protocol Analysis

RFC 1246:

J. Moy, Experience with the OSPF Protocol

RFC 1253:

F. Baker, R. Coltun, OSPF Version 2 Management Information Base

RFC 1256:

S. Deering, ICMP Router Discovery Messages

RFC 1265:

Y. Rekhter, BGP Protocol Analysis

RFC 1266:

Y. Rekhter, Experience with the BGP Protocol

RFC 1267:

K. Lougheed, Y. Rekhter, A Border Gateway Protocol 3 (BGP-3)

RFC 1268:

P. Gross, Y. Rekhter, Application of the Border Gateway Protocol in the Internet

RFC 1269:

J. Burruss, S. Willis, Definitions of Managed Objects for the Border Gateway Protocol (Version 3)

RFC 1321:

R. Rivest, The MD5 Message-Digest Algorithm

RFC 1370:

Internet Architecture Board Applicability Statement for OSPF

RFC 1388:

G. Malkin, RIP Version 2 Carrying Additional Information

RFC 1397:

D. Haskin, Default Route Advertisement In BGP2 And BGP3 Versions Of The Border Gateway Protocol

RFC 1403:

K. Varadhan, BGP OSPF Interaction

RFC 1583:

J. Moy, OSPF Version 2

Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
© 1983-2007 Hewlett-Packard Development Company, L.P.