10. Configuring Network Routing

 

 

This chapter describes how to configure network routing.

Routing Methods Overview

MultiNet provides two routing methods:

The IP routing table (also known as static routing)

Specifies the IP addresses of destinations and gateways for your communications. Use static routing when you have a very simple network, or a moderately complex network with a configuration that does not change often. Static routing is simple to configure and use.

The GATED dynamic gateway routing daemon

Handles multiple routing protocols and replaces ROUTED and EGPUP. GATED is used when node or gateway reconfigurations occur frequently, where the network geometry changes as networks come and go, or when dynamic routing protocols are being used for other reasons. GATED is more difficult to configure and use, but is much more flexible than static routing and provides a much greater selection of features.

 

Configuring Static IP Routes

The MULTINET SET /ROUTE command specifies static IP routing, including the default route. This command is normally invoked automatically by the network startup command file generated by the MultiNet Network Configuration Utility (NET-CONFIG).

Note: If the GATED gateway routing service is enabled, it takes full control of your routing tables and removes any statically-defined routes that are not also specified in the GATED configuration.

 

Adding Static Routes

You can configure a static default route using NET-CONFIG.

You can add additional static routes by creating the command file MULTINET:LOCAL_ROUTES.COM, which is executed as part of the network startup.

An example of the command for configuring a static route is:

$ MULTINET SET/ROUTE/ADD=(DEST=DEFAULT,GATE=192.0.0.1)

 

Changing the Default Route

To change the default route, first delete the current default route, then add the new one:

$ MULTINET SET/ROUTE/DELETE=(DEST=DEFAULT,GATE=IP address)
$ MULTINET SET/ROUTE/ADD=(DEST=DEFAULT,GATE=IP address)

Using GateD         

The Gateway Routing Daemon (GateD) manages multiple routing protocols, including the Routing Information Protocol (RIP), Local Network Protocol (HELLO), Router Discovery Protocol, Open Shortest Path First (OSPF) protocol, Exterior Gateway Protocol (EGP), and Border Gateway Protocol (BGP).

Using GateD, the network administrator can control the flow of routing information through a configuration language. Once you start GateD, it makes routing decisions based on the data gathered by the routing protocols. If routing using GateD, use GateD exclusively.

GateD allows you to control importing and exporting routing information by:

·         Individual protocol

·         Source and destination Autonomous System (AS)

·         Source and destination interface

·         Previous hop router

·         Specific destination address

You can assign preference levels for different combinations of imported routing information by using a flexible masking capability. In MultiNet, the name of the GateD process is GateD.

 

GateD Configuration File

MultiNet stores GateD configuration information in the MULTINET:GATED.CONF file. You must create this file before you can use GateD. For details on GateD configuration, see GateD Configuration Statements.

GateD Route Selection

GateD determines the "best" route using preference values set for each protocol or peer. Each route has a single associated preference value, even though you can set preferences at many places in the GATED.CONF file. The last (or most specific) preference value is the one GateD uses. Some protocols have a secondary preference, sometimes called a "tie-breaker."

The factors GateD uses in determining "best" routes include:

·         The route with the numerically smallest preference value is preferred.

·         For two routes with equal preferences, the route with the numerically smallest preference2 (the "tie-breaker") is preferred.

·         A route learned from an interior gateway protocol is preferred over a route learned from an exterior gateway protocol. Least preferred is a route learned indirectly by an interior protocol from an exterior protocol.

·         If Autonomous System (AS) path information is available, it helps determine the most preferred route:

o   A route with an AS path is preferred over one without an AS path.

o   If the AS paths and origins are identical, the route with the lower metric is preferred.

o   A route with an AS path origin of interior protocol is preferred over one with an origin of exterior protocol. Least preferred is an AS path with an unknown origin.

o   A route with a shorter AS path is preferred.

·         If both routes are from the same protocol and AS, the one with the lower metric is preferred.

·         The route with the lowest numeric next-hop address is used.

Preference values range from 0 to 255. The below table summarizes the default preference values for routes learned in various ways.

Default preference value	Is defined by ... statement
0	interface
10	ospf
20	gendefault (internally generated default)
30	redirect
40	kernel (routes learned using the socket route)
60	static
90	hello
100	rip
110	(point-to-point interfaces)
120	interfaces (routes to interfaces that are down)
130	aggregate/generate
150	ospf (AS external)
170	bgp
200	egp

 

Starting and Stopping GateD

After creating the MULTINET:GATED.CONF file, you need to stop and restart GateD. Follow these steps:

1. Log in as the system manager.

2. Stop the GateD process by entering:  MULTINET GATED/STOP

3. Restart the GateD process by entering: @MULTINET:START_SERVER

Note: It is not necessary to stop and restart GateD to get it to read a new MULTINET:GATED.CONF file, just use MULTINET GATED/LOAD.

 

Configuring GATED

Use the commands in the table below to manage the GateD process. To use these commands, you need OPER or SYSPRV privilege.

Command	Description
MULTINET GATED/CHECK (file)	Checks a GateD configuration file for syntax errors
MULTINET GATED/DUMP	Dumps the state of the GateD process to a file
MULTINET GATED/LOAD	Loads a new GateD configuration file
MULTINET GATED/SET/TRACE	Controls tracing in GateD
MULTINET GATED/SHOW/OSPF/ADVERTISE	Shows OSPF link state advertisements
MULTINET GATED/SHOW/OSPF/AS	Shows the AS external database entries
MULTINET GATED/SHOW/OSPF/DESTINATIONS	Shows the list of destinations and their indices
MULTINET GATED/SHOW/OSPF/ERRORS	Shows the OSPF error log
MULTINET GATED/SHOW/OSPF/HOPS	Shows the set of next hops for the OSPF router queried
MULTINET GATED/SHOW/OSPF/INTERFACES	Shows all configured interfaces for OSPF
MULTINET GATED/SHOW/OSPF/LOG	Shows the cumulative OSPF log of input/output statistics
MULTINET GATED/SHOW/OSPF/ NEIGHBORS	Shows all OSPF routing neighbors
MULTINET GATED/SHOW/OSPF/ROUTING	Shows the OSPF routing table
MULTINET GATED/SHOW/OSPF/STATE	Shows the link state database (except AS Externals)
MULTINET GATED/SHOW/RIP	Queries Routing Information Protocol (RIP) gateways
MULTINET GATED/SHOW/TRACE	Shows tracing in GateD
MULTINET GATED/STOP	Stops the GateD process
MULTINET GATED/TOGGLE_TRACING	Toggles tracing in GateD
MULTINET GATED/UPDATE_INTERFACES	Rescans the GateD network interfaces

 

GateD Configuration Statements

The GateD configuration file is MULTINET:GATED.CONF. This file must be present for the GateD process to run. The structure of the GateD configuration language is similar to C.  The configuration file consists of statements terminated by a semicolon (;). Statements consist of tokens separated by a space. This structure simplifies identification of the associated parts of the configuration.

You can include comment lines either by beginning them with a pound sign (#) or delimiting them with slash asterisk (/*) and asterisk slash (*/). The configuration file consists of the following sections, which reflect the order in which the statements, if used, must appear:

Directives	(%directory, %include)
Statements	traceoptions options interfaces
Definitions	autonomous-system routeid martians
Protocols	rip help redirect router-discovery server/client bgp ospf
Static routes	static
Control	import export aggregate generate

 

Directives

Directive statements include:

%directory

%include

Directive statements provide special instructions to the parser. They do not relate to the protocol configuration and can occur anywhere in GATED.CONF. They also end in a new line instead of a semicolon (;) like the other statements.

 

Format

%directory "directory"

Defines the directory where the include files go if you do not fully specify directory as part of the filename in the %include statement. Does not actually change the current directory, but simply applies the directory prefix.

 

%include "filename"

Identifies an include file. GateD includes the contents of the file in GATED.CONF at the point where the %include appears. If you do not fully specify the filename, it is relative to the directory defined in %directory. The %include directive causes GateD to parse the specified file completely before resuming. You can nest up to ten levels of include files.

 

 

 

 

 

traceoptions

The traceoptions statement controls tracing options. You can configure GateD tracing options at many levels. These include file specifications, control options, and global and protocol-specific tracing options.

Lower levels of statements inherit tracing options from the next higher level, unless overridden.

 

Format

traceoptions [ "tracefile" [replace] [size size[k | m] files files]]
                      [nostamp] traceoptions [except traceoptions] | none ;

 

Options and Parameters

"tracefile"

File to receive tracing information. If this filename is not fully specified, GateD creates it in the directory where you started GateD.

 

replace

Replaces an existing file. The default is to append to an existing file.

 

size size[k | m] files files

Limits the maximum size, in k or m or the files indicated, of the trace file (the minimum is 10k). When the file reaches size, GateD creates a new version.

 

nostamp

Control option which means not to prepend a timestamp to all trace lines. The default is to prepend a timestamp.

 

traceoptions

Specific to each protocol statement. Note that these global options may not apply to all protocols.

 

except traceoptions

Disables more specific trace options after enabling broader ones.

 

none

Turns off all tracing for the protocol or peer.

 

Option	Description
adv	For debugging: traces the allocation and freeing of policy blocks.
all	Turns on the general, normal, policy, route, state, task, and timer options.
general	Shorthand for specifying both the normal and route options.
iflist	Traces reading of the kernel interface.  Useful to specify this with the  -t option on the command line since the first interface scan occurs before reading the configuration file.
normal	Traces normal protocol occurrences (abnormal protocol occurrences are always traced).
parse	For debugging: traces the lexical analyzer and parser.
policy	Traces how protocol and user-specified policy apply to routes imported and exported.
route	Traces routing table changes for routes installed by the protocol or peer.
state	Traces state machine transitions in the protocols.
symbols	Traces symbols read from the kernel at startup.  The only useful way to specify this level of tracing is to use the -t option on the command line, since GateD reads the symbols from the kernel before parsing the configuration file.
task	Traces system interface and processing associated with the protocol or peer.
timer	Traces timer usage by the protocol or peer.

 

 

 

 

 

options

The options statements let you specify some global options. If used, options must appear before any other type of configuration statement in GATED.CONF.

 

Format

options [nosend]
        [noresolv]
        [gendefault [preference value][gateway host] ]
        [syslog [upto] loglevel]
        [mark time] ;

 

Options and Parameters

nosend

Does not send packets. Makes it possible to run GateD on a live network to test protocol interactions, without actually participating in the routing protocols. You can examine the packet traces in the GateD log to verify that GateD functions properly. Most useful for RIP and HELLO. Does not yet apply to BGP, and not useful with EGP and OSPF.

 

noresolv

Does not resolve symbolic names into IP addresses. By default, GateD uses the gethostbyname() and getnetbyname() library calls that usually use the Domain Name System (DNS) instead of the host’s local host and network tables. If there is insufficient routing information to send DNS queries, GateD deadlocks during startup. Use this option to prevent these calls.

Note: When you use this option, symbolic names cause configuration file errors.

 

gendefault [preference value] [gateway host]

nogendefault

Creates a default route with the special protocol default when a BGP or EGP neighbor is up. You can disable this for each BGP/EGP group with the nogendefault option. By default, this route has a preference value of 20. This route is normally not installed in the kernel forwarding table; it is only present for announcement to other protocols. The gateway option installs the default route in the kernel forwarding table with a next hop of the gateway defined.

Note: Using more general options is preferred to using gendefault. (See aggregate for details on the generate statement.)

 

syslog [upto] loglevel

Amount of data GateD logs to OPCOM. OpenVMS systems map UNIX syslog logging levels to OPCOM severity levels. The default is syslog upto info. The mapping of syslog to OPCOM logging levels appears in Mapping of UNIX syslog Levels to OpenVMS OPCOM Severity Levels.

 

mark time

GateD sends a message to the trace log at the specified time interval. Can be one method of determining if GateD is still running.

syslog log level	Is equivalent to OPCOM level...
emerg	FATAL
alert	FATAL
crit	FATAL
err	ERROR
warning	WARNING
notice	INFORMATIONAL
info (default)	INFORMATIONAL
debug	INFORMATIONAL

 

Example

#  generate a default route when peering with an EGP or BGP neighbor:
#
options gendefault ;

 

 

 

 

interfaces

An interface is the connection between a router and one of its attached networks. Specify a physical interface by interface name, IP address, or domain name. Multiple reference levels in the configuration language let you identify interfaces using wildcards (only the device driver part of the name, to match any unit number), interface type names, or addresses.

 

Format

Interfaces

{
  options
      [strictinterfaces]
      [scaninterval time] ;
  interface list
      [preference value]
      [down preference value]
      [passive]
      [simplex]
  define address
      [broadcast address] | [pointtopoint address]
      [netmask mask]
      [multicast] ;
};

 

Options Clause

options
      [strictinterfaces]
      [scaninterval time] ;

 

strictinterfaces

Makes it a fatal error to use reference interfaces not present when you start GateD or that are not part of the define parameter. Normally, GateD issues a warning message and continues.

 

scaninterval time

Sets 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 (such as BSD 4.4).

 

Interface Clause

Sets interface options on the specified interfaces. A list can consist of interface names, domain names, numeric addresses, or the value all. Include one or more interface names, including wildcard names (without a number) and those that can specify more than one interface or address.

There are three ways to reference an interface:

By wildcard	Only the device driver part of the name, to match any unit number.
By name	Combined device driver and unit number of an interface.
By address	IP address or domain name (if resolving to one address only).

 

There are four types of interfaces allowed:

Loopback	Must have the address 127.0.0.1. Packets from a loopback interface go back to the originator. Also used for reject and blackhole routes (not supported in MultiNet). The interface ignores any net mask. It is useful to assign an additional address to the loopback interface that is the same as the OSPF or BGP router ID; this allows routing to a system based on router ID that works if some interfaces are down.
Broadcast	Multiaccess interface capable of physical level broadcast, such as Ethernet, Token-Ring, and FDDI. A broadcast interface has an associated subnet mask and broadcast address. The interface route to a broadcast network is a route to the complete subnet.
Point-to-point	Tunnel to another host, usually on some sort of serial link. A point-to-point interface has a local address and a remote address. The remote address must be unique among the interface addresses on a given router. Many point-to-point interfaces and up to one non point-to-point interface must share the local address. This conserves subnets as you do not need any when using this technique. If you use a subnet mask on a point-to-point interface, only RIP version 1 and HELLO use it to determine which subnets propagate to the router on the other side of the point-to-point interface.
Non-broadcast multiaccess (NBMA)	Multiaccess but not capable of broadcast, such as frame relay and X.25. This type of interface has a local address and a subnet mask.

 

preference value

Sets the preference for routes to this interface when it is up and GateD determines it to function properly. The default preference value is 0. While the preference statement is optional, it is strongly recommended that you set an explicit preference value if you do use it.

 

down preference value

Sets the preference for routes to this interface when GateD determines that it does not function properly, but the kernel does not indicate that it is down. The default down preference value is 120.

 

passive

Does not change the preference of the route to the interface if determined not to function properly from lack of routing information. GateD checks this only if the interface actively participates in a routing protocol.

 

simplex

The interface does not recognize its own broadcast packets. Some systems define an interface as simplex with the IFF_SIMPLEX flag. On others, the configuration defines it. On simplex interfaces, packets from the local host are assumed to have been looped back in software and are not used to indicate that the interface functions properly.

 

 

 

 

 

Define Clause

Interfaces

{
  define address
    [broadcast address] | [pointtopoint address]
    [netmask mask]
    [multicast] ;
} ;

Defines interfaces not present when starting GateD so that the configuration file can reference them when using options strictinterfaces.

 

broadcast address

Makes the interface broadcast-capable (for Ethernet or Token-Ring) and specifies the broadcast address.

 

pointtopoint address

Makes the interface point-to-point (such as SLIP or PPP) and specifies the address on the local side of the interface. The first address in the define statement references the host on the remote end of the interface.

An interface not defined as broadcast or pointtopoint must be nonbroadcast multiaccess (NBMA), such as for an X.25 network.

 

netmask mask

Subnet mask to use on the interface. Ignored on point-to-point interfaces.

 

multicast

Makes the interface multicast-capable.

 

Examples

1. This example sets the interface as passive.

#  do not mark interface 192.168.95.41 as down,
#  even if there is no traffic:
#
interfaces{
  interface 192.168.95.41 passive ;
} ;

 

2. This example shows the interface statements used with the rip statement (see the rip description). Users would receive RIP packets only from interfaces sva-0 and sva-1, but not from fza-0, and sva-1 would be the only one that could send them.

rip yes {
  interface all noripin noripout ;
  interface sva ripin
;
  interface sva-1 ripout ;
  } ;

 

Definition Statements

Definition statements include:

autonomoussystem

routerid

martians

 

Definition statements are general configuration statements that relate to all of GateD or at least to more than one protocol. You must use these statements for any protocol statements in the configuration file.

 

Format

autonomoussystem ASnumber [loops number];

An autonomous system (AS) is a set of routers under a single technical administration, using an internal protocol and common metrics to route packets within the AS, and an external protocol to route packets to other ASs. The Network Information Center (NIC) assigns AS numbers.

The autonomoussystem statement sets the AS number of the router. You require this option if using BGP or EGP. The loops option is only for protocols supporting AS paths, such as BGP. It controls the number of times this AS can appear in an AS path, and defaults to 1.

 

routerid host ;

A router ID is an IP address used as a unique identifier assigned to represent a specific router, usually the address of an attached interface. The routerid statement sets the router ID for the BGP and OSPF protocols. The default is the address of the first interface GateD encounters. The address of a non-point-to-point interface is preferred over the local address of a point-to-point interface, and an address on a loopback interface that is not the loopback address (127.0.0.1) is most preferred.

 

martians

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

The martians statement defines a list of invalid addresses, called martians, that the routing software ignores. Sometimes a misconfigured system sends out obviously invalid destination addresses. The statement allows additions to the list of martian addresses. (See Route Filtering for details on specifying ranges.)

You can also use the allow parameter to explicitly allow a subset of an otherwise disallowed range.

 

Example

This example shows the use of all three definition statements, autonomoussystem, routerid, and martians.

#  use AS number 249:
#
autonomoussystem 249 ;
#
#  set the router
ID number:
#
routerid 192.168.95.41 ;
#
#  prevent routes to
0.0.0.26 from ever being accepted:
#
martians {
host 0.0.0.26 ;
};

 

 

 

 

Route Filtering

You can filter routes by matching a certain set of routes by destination, or by destination and mask. Use route filters on martians, import, and export statements.

The action taken when no match is found depends on the context. For example, import and export route filters assume an all reject ; at the end of a list. A route matches the most specific filter that applies. Specifying more than one filter with the same destination, mask, and modifiers generates an error.

 

Format

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

 

Options and Parameters

network

Destination network IP address. You can use one of the following options:

exact	Destination mask must match the supplied mask exactly. Used to match a network, but no subnets or hosts of that network.
refines	Destination mask must be more specified (longer) than the filter mask. Used to match subnets or hosts of a network, but not the network.
allow	See the martians definition statement.

 

mask mask

Destination network mask.

 

masklen number

Length of the destination network mask.

 

all

Entry matches anything. 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. Equivalent to 0.0.0.0 mask 0.0.0.0 exact. (Not valid for martians statements.)

 

host host

Matches the specific host. To match, the address must match exactly the specified host, and the network mask must be a host mask (all 1s). Equivalent to host mask 255.255.255 exact. (Not valid for martians statements.)

 

 

 

 

 

rip

GateD supports the Routing Information Protocol (RIP). RIP is a distance-vector protocol for distributing routing information at the local network level of the Internet. In distance-vector routing, each router transmits destination addresses and costs to its neighbors (computers communicating over RIP).

RIP versions 1 and 2 are 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 uses the fewest gateways, that is, the shortest path, not taking into account congestion or delay along the way.

RIP uses two types of packets: requests and responses.

Requests. A request asks for information about specific destinations or for all destinations. RIP can send requests when a router:

·         Comes up

·         Receives timed-out information about a destination

If a request fails to specify a destination, RIP assumes the router requests information about all destinations.

Responses. Responses contain destination and cost pairs. RIP sends responses under the following three conditions:

·         In response to a request

·         When information changes; for example, cost information

·         At set intervals; for example, reporting the destination to each neighbor every 30 seconds

RIP discards the destination and cost information if a neighbor fails to report the distance to a destination after a certain time interval.

RIP IP Addresses. RIP version 1 contains no provision for passing around a mask. RIP infers the mask based on whether the address is class A, B, or C. Sometimes there are special cases when the inferred mask differs from class A, B, or C. For example:

·         When you use RIP with a subnet (in this case the routers must know the subnet mask for a particular network number)

·         When the system updates RIP with an address reported as 0.0.0.0, RIP considers this address as a default destination with a mask of 0.0.0.0

·         When the system updates RIP with bits set in the host portion of the address, RIP assumes the address refers to a host with a mask of 255.255.255.255

With RIP version 2, you can specify the network mask with each network in a packet.

Configuring RIP. You configure RIP in the GATED.CONF file using a GateD protocol statement that enables or disables RIP. The syntax of the rip statement is as follows, with the parameters described next:

 

Format

rip  yes | no | on | off
[{

     [no]broadcast ;
     nocheckzero ;
     preference value ;
     defaultmetric metric ;
     query authentication [ none | [ [simple | md5] password ]];
     interface list
       [[no]ripin ] [ [no]ripout ]
       [metricin metric]
       [metricout metric] ;
       [version 1] | [ version 2 [multicast | broadcast] ]
       [ [secondary] authentication [none | [[simple | md5] password ]]];

     trustedgateways list ;

     sourcegateways list ;

     traceoptions options ;

}] ;

 

Options and Parameters

yes | on (default)
no | off

When enabled on a host, RIP listens in the background to routing updates. When enabled on a gateway, RIP supplies routing updates. Enabled by default.

 

broadcast ;

Broadcasts RIP packets regardless of the number of interfaces present. Useful when propagating static routes or routes learned from another protocol into RIP. In some cases, using broadcast when only one network interface is present can cause data packets to traverse a single network twice. The default for more than one interface.

 

nobroadcast ;

Does not broadcast RIP packets on attached interfaces even if there is more than one. If you use the sourcegateways parameter, routes are still unicast directly to that gateway. The default for a single interface.

 

nocheckzero ;

Does not make sure that reserved fields in incoming RIP version 1 packets are zero. Normally RIP rejects packets whose reserved fields are zero.

 

preference value ;

Sets the preference for routes learned from RIP. A preference specified in import policy can override this. The default preference value is 100.

 

defaultmetric metric ;

Metric used when advertising routes learned from other protocols. Choice of values requires that you explicitly specify a metric in order to export routes from other protocols into RIP. A metric specified in export policy can override this. The default metric is 16.

 

query authentication ;

Authentication required of query packets that do not originate from routers. The default is none.

 

 

 

 

 

 

Interface Clause

rip  yes | no | on | off
[{

    [no]broadcast ;
    nocheckzero ;
    preference value ;
    defaultmetric metric ;
    query authentication [ none | [ [simple | md5] password ] ] ;
    interface list
      [ [no]ripin ] [ [no]ripout ]
      [metricin metric]
      [metricout metric] ;
      [version 1] | [ version 2 [multicast | broadcast] ]
      [ [secondary] authentication [none | [ [simple | md5] password] ] ;
      trustedgateways list ;
      sourcegateways list ;
      traceoptions options ;
}] ;

Controls various attributes of sending RIP on specific interfaces. (See the interfaces statement for a description of list.) Note that if there are multiple interfaces configured on the same subnet, only the first one on which RIP output is configured sends the RIP updates. This limitation is required because of the way the UNIX kernel operates. A future GateD release will hopefully remove this limitation. The default list value is all.

 

ripin (default)

noripin

Use ripin explicitly when using noripin on a wildcard interface descriptor. The noripin option ignores RIP packets received over the specified interfaces.

 

ripout (default)

noripout

Use ripin explicitly when using noripout on a wildcard interface descriptor. The noripin does not send RIP packets over the specified interfaces.

 

metricin metric

RIP metric to add to incoming routes before they are installed in the routing table. Makes the router prefer RIP routes learned using the specified interfaces less than those learned from other interfaces. The default is the kernel interface metric plus 1. If using this as the absolute value, the kernel metric is not added.

 

metricout metric

RIP metric to add to routes sent over the specified interface(s). Makes other routers prefer other sources of RIP routes over this router. The default metric value is 0.

 

version 1 (default)

Sends RIP version 1 packets over the specified interface(s).

 

version 2 [multicast | broadcast]

Sends RIP version 2 packets over the specified interfaces. If IP multicasting support is available on this interface, the default is to send full version 2 packets. If multicasting is not available, version 1 compatible version 2 packets are sent. Options include:

multicast	Multicasts RIP version 2 packets over this interface. (Default)
broadcast	Broadcasts RIP version 1 compatible version 2 packets over this interface even if IP multicasting is available

 

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

Authentication type to use. Applies only to RIP version 2 and is ignored for RIP-1 packets. If you specify a password, the authentication type defaults to simple. The password should be a quoted string with 0 to 16 characters. If you specify secondary, this defines the secondary authentication. The default is authentication none.

 

trustedgateways list

List of gateways from which RIP accepts updates (host names or IP addresses). If used, only updates from the gateways in the list are accepted. The default list value is all.

 

sourcegateways list

List of routers to which RIP sends packets directly, not through multicasting or broadcasting. If used, only updates from the gateways in the list are accepted. The default list value is all.

 

traceoptions options

RIP-specific trace options:

packets	All RIP packets, or packets [detail] send or [detail] recv (detail provides a more verbose format to provide more details; if used, detail must come before send or recv)
request	RIP information request packets, such as REQUEST, POLL and POLLENTRY
response	RIP RESPONSE packets that actually contain routing information

 

 

 

 

 

 

hello

GateD supports the HELLO protocol. HELLO is an interior protocol that uses delay as the deciding factor when selecting the best route. Delay is the round trip time between source and destination. HELLO is not as widely used as when it was the interior protocol of the original 56-Kb/sec NSFNET backbone and used between LSI-11 ("fuzzball") routers. Because of this, HELLO is disabled by default.

By default, HELLO, like RIP, uses the kernel interface metric set by the ifconfig command to influence metrics 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 HELLO’s millisecond metric. For the translation scheme, see the HELLO Hops-to-Metrics Translation table below.

This many Hops	Translate to this HELLO metric	This many Hops	Translate to this HELLO metric	This many Hops	Translate to this HELLO metric
0	0	6	713	12	75522
1	100	7	1057	13	11190
2	148	8	1567	14	16579
3	219	9	2322	15	24564
4	325	10	3440	16	3000
5	481	11	5097

 

You configure HELLO in the GATED.CONF file using a GateD protocol statement that enables or disables HELLO.

When enabled, HELLO assumes nobroadcast when only one interface exists. HELLO assumes broadcast when more than one interface exists.

 

Format

hello  yes | no | on | off
[{

    [no]broadcast ;
    preference value ;
    defaultmetric metric ;
    interface list
      [ [no]helloin ]
      [ [no]helloout ]
      [metricin metric]
      [metricout metric] ;
      trustedgateways list ;
      sourcegateways list ;
      traceoptions options ;
}] ;

 

Options and Parameters

yes | on or no | off (default)

When enabled on a host, HELLO listens in the background for routing updates. When enabled on a gateway, HELLO supplies routing updates. Disabled by default.

 

broadcast ;

nobroadcast ;

The broadcast option broadcasts HELLO packets regardless of the number of interfaces present. Useful when propagating static routes or routes learned from another protocol into HELLO. In some cases, using broadcast when only one network interface is present can cause data packets to traverse a single network twice. The default for more than one interface.

The nobroadcast option does not broadcast HELLO packets on attached interfaces, even if there is more than one. If you use the sourcegateways parameter, routes are still unicast directly to that gateway. The default for a single interface.

 

preference value ;

Preference for routes learned from HELLO. A preference specified in import policy can override this. The default preference value is 90.

 

defaultmetric metric ;

Metric used when advertising routes learned from other protocols. Requires you to explicitly specify a metric in order to export routes from other protocols into HELLO. A metric specified in export policy can override this. The default metric is 30000.

 

interface list
     [ [no]helloin ]
     [ [no]helloout ]
     [metricin metric]
     [metricout metric] ;

Controls various attributes of sending HELLO on specific interfaces. (See interfaces statement for a description of list.) Note that if there are multiple interfaces configured on the same subnet, only the first interface that has HELLO output configured sends the HELLO updates. This limitation is required because of the way the UNIX kernel operates. A future GateD release will hopefully remove this limitation. The default interface list value is all.

 

helloin (default)

nohelloin

Use helloin explicitly when using nohelloin on a wildcard interface descriptor. The nohelloin option ignores HELLO packets received over the specified interfaces.

 

helloout (default)

nohelloout

Use helloout explicitly when using nohelloout on a wildcard interface descriptor. The nohelloout option does not send HELLO packets over the specified interfaces.

 

metricin metric

HELLO metric to add to incoming routes before GateD installs them in the routing table. Makes this router prefer HELLO routes learned from other interfaces over those from the specified interface(s). The default is the kernel interface metric plus one. If using this as the absolute value, GateD does not add the kernel metric to the routing table.

 

metricout metric

HELLO metric to add to routes that are sent over the specified interface(s). Makes other routers prefer other sources of HELLO routes over this router. The default metric out metric value is 0.

 

trustedgateways list

List of gateways from which HELLO accepts updates (host names or IP addresses). If used, HELLO accepts only updates from the gateways in the list. The default list value is all.

 

sourcegateways list

List of routers to which HELLO sends packets directly, not through multicasting or broadcasting. If used, HELLO accepts only updates from the gateways in the list. The default list value is all.

 

traceoptions packets

All HELLO packets, or packets [detail] send or [detail] recv (detail provides a more verbose format to provide more details; if used, detail must come before send or recv).

 

 

 

 

 

icmp

On systems without the BSD routing socket, GateD listens to ICMP messages received by the system. 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.

 

Format

icmp { traceoptions options ; }

 

Options and Parameters

traceoptions options ;

ICMP tracing options (which you can modify with detail and recv) are as follows:

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 timestamp request/response
error	Only ICMP error packets, which include time exceeded, parameter problem, unreachable and source quench

 

 

 

 

redirect

GateD controls whether ICMP redirect messages can modify the kernel routing table. If disabled, GateD only prevents a system from listening to ICMP redirects. By default, ICMP redirects are enabled on hosts, and disabled on gateways that run as RIP or HELLO suppliers.

You configure ICMP redirect handling in the GATED.CONF file using a GateD protocol statement.

 

Format

redirect  yes | no | on | off
[{

    preference value ;
    interface list [ [no]redirects ] ;
    trustedgateways list ;
}];

 

Options and Parameters

yes | on

no | off

Enabled by default on hosts. Disabled by default on gateways running as RIP or HELLO suppliers.

 

preference value

Preference for routes learned from a redirect. The default preference value is 30.

 

interface list [ [no]redirects ]

Enables and disables redirects interface by interface. (See interfaces for a description of list.) The default interface list value is all. The possible parameters are:

redirects	May be necessary when you use noredirects on a wildcard interface descriptor. (Default)
noredirects	Ignores redirects received over the specified interface(s). The default is to accept redirects on all interfaces.

 

trustedgateways list

List of gateways from which redirects are accepted (host names or addresses). By default, all routers on the shared network(s) are trusted to supply redirects. If used, only redirects from the gateways in the list are accepted. The default list value is all.

 

 

 

 

 

routerdiscovery server

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

The protocol is in two parts, the server that runs on routers and the client that runs on hosts (see the next statement). GateD treats these much like two separate protocols that you can enable only one at a time.

The Router Discovery Server runs on routers and announces their existence to hosts. It does this by periodically multicasting or broadcasting a Router Advertisement to each interface on which it is enabled. These Router Advertisements contain a list of all router 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 occurring every few minutes. In addition, a host may send a Router Solicitation to which the router will respond with a unicast Router Advertisement (unless a multicast or broadcast advertisement is due momentarily).

Each Router Advertisement contains an Advertisement Lifetime field indicating how long the advertised addresses are valid. This lifetime is configured such that another Router Advertisement is sent before the lifetime expires. A lifetime of zero indicates that one or more addresses are no longer valid.

On systems supporting IP multicasting, the Router Advertisements are sent to the all-hosts multicast address 224.0.0.1 by default. However, you can specify broadcast. 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.

Note: Do not mix routerdiscovery server and routerdiscovery client statements in the GATED.CONF file or you may get unintended results. You should also include preference statements in the interfaces and routerdiscovery statements whenever possible.

 

Format

routerdiscovery server  yes | no | on | off
[{

    traceoptions state ;
    interface list
      [minadvinterval time]
      [maxadvinterval time]
      [lifetime time] ;
    address list
      [advertise] | [ignore]
      [broadcast] | [multicast]
      [ineligible] | [preference value] ;
}];

Note: Interface must be mentioned in the “Interface” directive.

 

Options and Parameters

yes | on

no | off

Enables or disables Router Discovery Protocol Server.

 

traceoptions state

The state is the only trace option, which traces the state transitions. The Router Discovery Server does not directly support packet tracing options; tracing of router discovery packets is enabled through the icmp statement described in the icmp statement section.

 

interface list

Parameters that apply to physical interfaces. Note a slight difference in convention from the rest of GateD: interface specifies just physical interfaces, while address specifies protocol (in this case, IP) addresses.

 

maxadvinterval time

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). The default is 10:00 (10 minutes).

 

minadvinterval time

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 X maxadvinterval.

 

lifetime time

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

 

address list

Parameters that apply to the specified set of addresses on this physical interface. Note a slight difference in convention from the rest of GateD: interface specifies just physical interfaces while address is protocol (in this case, IP) addresses.

 

advertise (default)

ignore

The advertise keyword includes the specified addresses in Router Advertisements. The ignore keyword does not.

 

broadcast

multicast

The broadcast keyword includes the given addresses in a broadcast Router Advertisement because this system does not support IP multicasting, or some hosts on an 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.

The multicast keyword includes the given addresses in a multicast Router Advertisement. If the system does not support IP multicasting, the address(es) is not included. If the system supports IP multicasting, the default is to include the addresses in a multicast Router Advertisement if the given interface supports IP multicasting. If not, the addresses are included in a broadcast Router Advertisement.

 

preference value

ineligible

The preference keyword sets the preferability of the addresses as a default router address, relative to other router addresses on the same subnet. A 32-bit, signed, two’s complement integer, with higher values meaning more preferable. Note that hex 80000000 may only be specified as ineligible. The default value is 0. Use a preference statement whenever possible.

The ineligible keyword assigns the given addresses 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 addresses 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.

 

 

 

 

 

 

routerdiscovery client

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

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

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

Note: Do not mix routerdiscovery server and routerdiscovery client statements in the GATED.CONF file or you may get unintended results. You should also include preference statements in the interfaces and routerdiscovery statements whenever possible.

 

Format

routerdiscovery client  yes | no | on | off
[{

    traceoptions state ;
    preference value ;
    interface list
      [enable] | [disable]
      [broadcast] | [multicast]
      [quiet] | [solicit] ;
}] ;

 

Options and Parameters

yes | on

no | off

Enables or disables the Router Discovery Protocol Client.

 

traceoptions state ;

The state is the only trace option, which traces the state transitions. The Router Discovery Server does not directly support packet tracing options; tracing of router discovery packets is enabled through the icmp statement described in the icmp statement section.

 

preference value ;

Preference of all Router Discovery default routes. Use a preference statement whenever possible. Default is 55.

 

interface list

Parameters that apply to physical interfaces. Note a slight difference in convention from the rest of GateD: interface specifies just physical interfaces. The Router Discovery Client has no parameters that apply only to interface addresses.

 

enable (default)

disable

Either performs or does not perform Router Discovery on the specified interfaces.

 

broadcast

multicast

The broadcast keyword broadcasts Router Solicitations on the specified interfaces. This is the default if IP multicast support is not available on this host or interface.

The multicast keyword multicasts Router Solicitations on the specified interfaces. If IP multicast is not available on this host and interface, no solicitation is performed. The default is to multicast Router Solicitations if the host and interface support it, otherwise Router Solicitations are broadcast.

 

solicit (default)

quiet

Either sends or does not send Router Solicitations on this interface, even though Router Discovery is performed.

 

 

 

 

 

egp

GateD supports the Exterior Gateway Protocol (EGP). EGP is an exterior routing protocol that moves routing information between Autonomous Systems (ASs). Unlike interior protocols, EGP propagates only reachability indications, not true metrics. EGP updates contain metrics, called distances, which range from 0 to 255. GateD only compares EGP distances learned from the same AS. EGP currently has limited usage. By default, EGP is disabled.

Before EGP sends routing information to a remote router, it must establish an adjacency with that router. This occurs by exchanging Hello and I Heard You (I-H-U) messages with that router. (Hello should not to be confused with the HELLO protocol, or OSPF HELLO messages.) Computers communicating over EGP are called EGP neighbors, and the exchange of Hello and I-H-U messages is known as acquiring a neighbor.

Once you acquire a neighbor, the system polls it for routing information. The neighbor responds by sending an update containing routing information. If the system receives a poll from its neighbor, it responds with its own update packet. When the system receives an update, it includes routes from the update into its routing database. If the neighbor fails to respond to three consecutive polls, GateD assumes that the neighbor is down and removes the neighbor’s routes from its database.

You configure EGP in the GATED.CONF file using a GateD protocol statement.

 

Format

egp  yes | no | on | off
[{

    preference value ;
    defaultmetric metric ;
    packetsize max ;
    traceoptions options ;
    group
      [peeras ASnumber]
      [localas ASnumber]
      [maxup number
      {

        neighbor host
        [metricout metric]
        [preference value]
        [preference2 value]
        [ttl ttl]
        [nogendefault]
        [importdefault]
        [exportdefault]
        [gateway gateway]
        [lcladdr local-address]
        [sourcenet network]
        [minhello | p1 time]
        [minpoll | p2  time]
        [traceoptions options] ;
      };
}] ;

 

Options and Parameters

yes | on

no | off (default)

Enables or disables EGP support. Disabled by default.

 

preference value ;

Preference for routes learned from EGP. A preference specified on the group or neighbor statements or by import policy can override this. The default preference value is 200.

 

defaultmetric metric ;

Metric used when advertising routes over EGP. This choice of values requires you to explicitly specify a metric when exporting routes to EGP neighbors. A metric specified on the neighbor or group statements or in export policy can override this. The default metric is 255.

 

packetsize max ;

Maximum size of a packet that EGP expects to receive from this neighbor. If EGP receives a larger packet, it is incomplete and EGP discards it. EGP notes the length of this packet and increases the expected size to be able to receive a packet of this size. Specifying the parameter prevents the first packet from being dropped. All packet sizes are rounded up to a multiple of the system page size. The default packet size max value is 8192.

 

traceoptions options ;

Tracing options for EGP (can be overridden on a group or neighbor basis):

packets	All EGP packets, or packets [detail] send or [detail] recv (detail provides a more verbose format to provide more details; if used, detail must come before send or recv)
hello	EGP HELLO/I-HEARD-U packets used to determine neighbor reachability
acquire	EGP ACQUIRE/CEASE packets used to initiate and terminate EGP sessions
update	EGP POLL/UPDATE packets used to request and receive reachability updates

 

 

Group Clause

Group [peeras ASnumber] [localas ASnumber] [maxup number
{

  neighbor host
    [metricout metric]
    [preference value]
    [preference2 value]
    [ttl ttl]
    [nogendefault]
    [importdefault]
    [exportdefault]
    [gateway gateway]
    [lcladdr local-address]
    [sourcenet network]
    [minhello | p1 time]
    [minpoll | p2  time]
    [traceoptions options] ;

};

EGP neighbors must be members of a group, which groups all neighbors in one AS. Parameters specified in the group clause apply to all the subsidiary neighbors, unless explicitly overridden on a neighbor clause. Any number of group clauses can specify any number of neighbor clauses. You can specify any parameters from the neighbor subclause on the group clause to provide defaults for the whole group (which you can override for individual neighbors).

The group clause is the only place to set the following attributes:

peeras ASnumber

AS number expected from peers in the group. Learned dynamically.

 

localas ASnumber

AS that GateD represents to the group. Usually only used when masquerading as another AS. Use is discouraged. Set globally in autonomoussystem.

 

maxup number

Number of neighbors GateD should acquire from this group. GateD attempts to acquire the first maxup neighbors in the order listed. If one of the first neighbors is not available, it acquires one farther down the list. If after startup, GateD does manage to acquire the more desirable neighbor, it drops the less desirable one. By default, GateD acquires all neighbors in the group.

 

Group Neighbor Clause

egp  yes | no | on | off
[{

    preference value ;
    defaultmetric metric ;
    packetsize max ;
    traceoptions options ;
    group
      [peeras ASnumber]
      [localas ASnumber]
      [maxup number
      {

        neighbor host
        [metricout metric]
        [preference value]
        [preference2 value]
        [ttl ttl]
        [nogendefault]
        [importdefault]
        [exportdefault]
        [gateway gateway]
        [lcladdr local-address]
        [sourcenet network]
        [p1  time | minhello]
        [p2  time | minpoll]
        [traceoptions options] ;

      };

}] ;

Each neighbor subclause defines one EGP neighbor within a group. The only required part of the subclause is the host argument, the symbolic host name or IP address of the neighbor.

 

metricout metric

Metric used for all routes sent to this neighbor. 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.

 

preference value

Preference used for routes learned from these neighbors. 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. Import policy can explicitly override this.

 

preference2 value

Tie-breaker, in the case of a preference tie. The default value is 0.

 

ttl ttl

IPL time-to-live. Provided when attempting to communicate with improperly functioning routers that ignore packets sent with a TTL 1. The default ttl for local neighbors is 1; the default for nonlocal neighbors is 255.

 

nogendefault

Does not generate a default route when EGP receives a valid update from its neighbor. The default route is only generated when you enable the gendefault option.

 

importdefault

Accepts the default route (0.0.0.0) if included in a received EGP update. For efficiency, some networks have external routers announce a default route to avoid sending large EGP update packets. The default route in the EGP update is ignored.

 

exportdefault

Includes the default route (0.0.0.0) in EGP updates sent to this EGP neighbor. Allows the system to advertise the default route using EGP. Normally a default route is not included in EGP updates.

 

gateway gateway

Router on an attached network used as the next hop router for routes received from this neighbor if a network is not shared with a neighbor. Rarely used.

 

lcladdr local-address

Address used on the local end of the connection with the neighbor. The local address must be on an interface shared with the neighbor, or with the neighbor’s gateway when using the gateway option. A session only opens when an interface with the appropriate local address (through which the neighbor or gateway address is directly reachable) is operating.

 

sourcenet network

Network queried in the EGP Poll packets. If there is no network shared with the neighbor, specify one of the networks attached to the neighbor. Also use to specify a network shared with the neighbor, other than the one on which the EGP packets are sent. Normally not needed. The default is the network shared with the neighbor’s address.

 

p1 time or minhello

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

 

p2 time or minpoll

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

 

traceoptions options

Tracing options for this EGP neighbor, which are:

packets	All EGP packets, or packets [detail] send or [detail] recv (detail provides a more verbose format to provide more details; if used, detail must come before send or recv)
hello	EGP HELLO/I-HEARD-U packets used to determine neighbor reachability
acquire	EGP ACQUIRE/CEASE packets used to initiate and terminate EGP sessions
update	EGP POLL/UPDATE packets used to request and receive reachability updates

 

 

 

 

 

bgp

The Border Gateway Protocol (BGP) is an exterior routing protocol used to exchange routing information between multiple transit Autonomous Systems (ASs) as well as between transit and stub ASs. BGP is related to EGP but operates with more capability, greater flexibility, and less bandwidth required. BGP uses path attributes to provide more information about each route. It maintains an AS path, which includes the AS number of each AS the route transits, providing information sufficient to prevent routing loops in an arbitrary topology. You can also use path attributes to distinguish between groups of routes to determine administrative preferences. This allows greater flexibility in determining route preference to achieve a variety of administrative ends.

BGP supports two basic types of sessions between neighbors—internal (sometimes called IBGP) and external. Internal sessions run between routers in the same AS, while external sessions run between routers in different ASs. 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 do not generally have the local AS number prepended to the AS path. Hence, these routes generally have the same AS path 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 similar in capability and function. They only propagate classed network routes, and the AS path is a simple array of AS numbers. BGP version 4 propagates fully general address-and-mask routes, and the AS path has some structure to represent the results of aggregating dissimilar routes.

External BGP sessions may or may not include a single metric, which BGP calls the Multi-Exit Discriminator (MED), in the path attributes. For BGP versions 2 and 3 this metric is a 16-bit unsigned integer; for BGP version 4 it is a 32-bit unsigned integer. In either case, smaller values of the metric are preferred. Currently this metric only breaks 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 better when its value is smaller; for version 4 it is better when it is larger. BGP version 4 sessions optionally carry a second metric on internal sessions, this being an internal version of the MED. The use of these metrics depends on the type of internal protocol processing specified.

BGP collapses routes with similar path attributes into a single update for advertisement. Routes received in a single update are readvertised in a single update. The churn caused by the loss of a neighbor is minimized, and the initial advertisement sent during peer establishment is maximally compressed. BGP does not read information from the kernel message by message, but fills the input buffer. It processes all complete messages in the buffer before reading again. BGP also does multiple reads to clear all incoming data queued on the socket. This feature 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.

BGP implementation expects external peers to be directly attached to a shared subnet, and expects those peers to advertise next hops that are host addresses on that subnet (although this constraint can be relaxed by configuration for testing). For groups of internal peers, however, there are several alternatives that can be selected 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 determine the immediate next hops for routes, by using the next hop received with a route from a peer as a forwarding address, and using this to look up an immediate next hop in an IGP’s routes. Such groups support distant peers, but need to be informed of the IGP whose routes they use to determine immediate next hops. Finally, type IGP groups expect routes from the group peers not to be used for forwarding at all. Instead, they expect that copies of the BGP routes are also received through an IGP, and that the BGP routes are only 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 with which they are running.

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 was configured with an allow clause.

 

Format

bgp  yes | no | on | off
[{

    preference value ;
    defaultmetric metric ;
    traceoptions options ;
    group type
    external peeras ASnumber
              | internal peeras ASnumber
              | igp peeras ASnumber proto proto
              | routing peeras ASnumber proto proto interface list
              | test peeras ASnumber
    {

       allow
       {

         network
         network mask mask
         network masklen number
         all
         host host

       } ;
       peer host
         [metricout metric]
         [localas ASnumber]
         [nogendefault]
         [gateway gateway]
         [preference value]
         [preference2 value]
         [lcladdr local-address]
         [holdtime time]
         [version number]
         [passive]
         [sendbuffer number]
         [recvbuffer number]
         [indelay time]
         [outdelay time]
         [keep [all | none] ]
         [analretentive]
         [noauthcheck]
         [noaggregatorid]
         [keepalivesalways]
         [v3asloopokay]
         [nov4asloop]
         [logupdown]
         [ttl ttl]
         [traceoptions options] ;
    };
}];

 

Options and Parameters

yes | on

no | off (default)

Enables or disables BGP support. Disabled by default.

 

preference value ;

Preference for routes learned from BGP. A preference specified on the group or peer statements, or by import policy, can override this. The default preference value is 170.

 

defaultmetric metric ;

Metric used when advertising routes over BGP. A metric specified on the group or peer statements, or in export policy, can override this. The default metric is 65535.

 

traceoptions options ;

Tracing options for BGP. May be overridden on a group or peer basis. The trace options are:

packets	All BGP packets, or packets [detail] send or [detail] recv [detail] provides a more verbose format to provide more details; if used, detail must come before send or recv).
open	BGP OPEN packets used to establish a peer relationship
update	BGP UPDATE packets used to pass network reachability information
keepalive	BGP KEEPALIVE packets used to verify peer reachability

 

Group Type Clause

peeras

For group type, specify one of the following peeras options:

external peeras ASnumber	In the classic external BGP group, full policy checking is applied to all incoming and outgoing advertisements. The external neighbors must be directly reachable through one of the machine’s local interfaces. No metric included in external advertisements and the next hop is computed with respect to the shared interface.
internal peeras ASnumber	Internal group operating where there is no IP-level IGP; for example, an SMDS network or MILNET. All neighbors in this group must be directly reachable over 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 readvertised with the received metric.
igp peeras ASnumber	Internal group that runs in association with an interior protocol. The IGP group examines routes the IGP exports, 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 the connection uses. 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 the IGP exports, the export policy used is the IGP’s. There is no need to implement the "don’t route from peers in the same group" constraint, since the advertised routes are routes that IGP already exports.
routing peeras ASnumber	Internal group that uses the routes of an interior protocol to resolve forwarding addresses. A type routing group propagates external routes between routers not directly connected, and computes immediate next hops for these routes by using the BGP next hop that arrived with the route as a forwarding address to be resolved using an internal protocol’s routing information.   In essence, internal BGP is used to carry AS external routes, while the IGP is expected to only carry AS internal routes, and the latter is used to find immediate next hops for the former. The next hop in BGP routes advertised to the type routing peers are set to local address on BGP connection to those peers, as it is assumed a route to this address is propagated over IGP. ·         proto proto - Interior protocol used to resolve BGP route next hops, and can be the name of any IGP in the configuration. ·         interface list - Optionally provides a list of interfaces whose routes are carried over the IGP for which third party next hops can be used instead.
test peeras ASnumber	Extension to external BGP that implements a fixed policy using test peers. Fixed policy and special case code make test peers relatively inexpensive to maintain. Test peers do not need to be on a directly attached network. If GateD and the peer are on the same (directly attached) subnet, the advertised next hop is computed with respect to that network; otherwise the next hop is the local machine’s current next hop.   All routing information advertised by and received from a test peer is discarded, and all BGP advertisable routes are sent back to the test peer. Metrics from EGP- and BGP-derived routes are forwarded in the advertisement; otherwise no metric is included.

 

Group Type Allow Clause

Allows peer connections from any addresses in the specified range of network and mask pairs. Configure all parameters for these peers 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 details on specifying the network/mask pairs, see Route Filtering.)

Group Type Peer Clause

Configures an individual peer. Each peer inherits all parameters specified on a group as defaults. You can override these defaults using parameters explicitly specified in the peer subclause. Allows the following parameters:

 

metricout metric

Primary metric on all routes sent to the specified peer(s). Overrides the default metric, a metric specified on the group, and any metric specified by export policy.

 

localas ASnumber

AS that GateD represents to this group of peers. ASnumber is set globally in autonomoussystem.

 

nogendefault

Does not generate a default route when EGP receives a valid update from its neighbor. The default route is generated only when enabling the gendefault option.

 

gateway gateway

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

 

preference value

Preference used for routes learned from these peers. Can differ from the default BGP preference set in the bgp statement, so that GateD can prefer routes from one peer, or group of peers, over others. Import policy can explicitly override this.

 

preference2 value

In the case of a preference tie, can break the tie.

 

lcladdr local-address

Address used on the local end of the TCP connection with the peer. For external peers, the local address must be on an interface shared with the peer or with the peer’s gateway when using the gateway parameter. A session with an external peer only opens when an interface with the appropriate local address (through which the peer or gateway address is directly reachable) is operating. For other types of peers, a peer session is maintained when any interface with the specified local address is operating. In either case, incoming connections are only recognized as matching a configured peer if they are addressed to the configured local address.

 

holdtime time

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, the BGP connection is closed. The value must be either 0 (no keepalives are sent) or at least 3.

 

version number

Version of the BGP protocol to use with this peer. If specified, only the specified version is offered during negotiation. Currently supported versions are 2, 3, and 4. By default, the highest supported version is used first, and version negotiation is attempted.

 

passive

Does not attempt active OPENs to this peer. GateD should wait for the peer to issue an open. By default, all explicitly configured peers are active.

 

sendbuffer number and recvbuffer number

Controls the amount of send and receive buffering asked of the kernel. The maximum number supported is 65535 bytes, although many kernels have a lower limit. Not needed on normally functioning systems. By default, the maximum supported is configured.

 

indelay time and outdelay time

Dampens route fluctuations. The 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. The outdelay is the amount of time a route must be present in the GateD routing database before it is exported to BGP. Default time in both cases is 0.

 

keep all

Retains routes learned from a peer even if the routes’ AS paths contain one of our exported AS numbers.

 

analretentive

Issues warning messages when receiving questionable BGP updates such as duplicate routes and/or deletions of nonexistent routes. Normally these events are silently ignored.

 

noauthcheck

Communicates with an implementation that uses some form of authentication other than the normal authentication field of all ones.

 

noaggregatorid

GateD should 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

GateD should always send keepalives, even when an update could have correctly substituted for one. Allows interoperability with routers that do not completely obey the protocol specifications on this point.

 

v3asloopokay

By default, GateD does not advertise routes whose AS path is looped (that have 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

Does not advertise routes with looped AS paths to version 4 external peers. Can be useful to avoid advertising such routes to peer which would incorrectly forward the routes on to version 3 neighbors.

 

logupdown

Logs a message using syslog whenever a BGP peer enters or leaves ESTABLISHED state.

 

ttl ttl

Provided when attempting to communicate with improperly functioning routers that ignore packets sent with a TTL 1. Not all kernels allow the TTL to be specified for TCP connections. The default ttl for local neighbors is 1; the default for nonlocal neighbors is 255.

 

traceoptions options ;

Tracing options for this BGP neighbor include:

packets	All BGP packets, or packets [detail] send or [detail] recv (detail provides a more verbose format to provide more details; if used, detail must come before send or recv)
open	BGP OPEN packets used to establish a peer relationship
update	BGP UPDATE packets used to pass network reachability information
keepalive	BGP KEEPALIVE packets used to verify peer reachability

 

 

 

 

 

ospf

Open Shortest Path First (OSPF) routing 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 (AS). OSPF chooses the least cost path as the best path. Suitable for complex networks with many routers, OSPF provides equal cost multipath routing where packets to a single destination can be sent over 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 (that is, the router’s usable interfaces and reachable neighbors) throughout the AS by flooding.

Each multiaccess network with 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 lets you group networks into areas. Routing information passed between areas is abstracted, which can significantly reduce 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, while inter-area paths have destinations in other OSPF areas. AS 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 making a routing decision, OSPF adds the internal cost of 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, GateD uses only the internal OSPF cost of the AS Border router 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 from internal routers, so that there is no ambiguity about the source or reliability of routes. Externally derived routing information (for example, routes learned from EGP or BGP) passes transparently through the AS and is separate from OSPF’s internally derived data. Each external route can also be tagged by the advertising router, enabling a passing of additional information between routers on the borders of the AS.

OSPF optionally includes type of service (TOS) routing and allows administrators to install multiple routes to a given destination for each type of service (such as for low delay or high throughput.) A router running OSPF uses the destination address and the TOS to choose the best route to the destination.

OSPF intra- and inter-area routes are always imported into the GateD routing database with a preference of 10. It would be a violation of the protocol if an OSPF router did not participate fully in the area’s OSPF, so it is not possible to override this. Although it is possible to give other routes lower preference values explicitly, it is ill-advised to do so.

Hardware multicast capabilities are also used where possible to deliver link-status messages.

OSPF areas are connected by the backbone area, the area with identifier 0.0.0.0. All areas must be logically contiguous and the backbone is no exception. To permit maximum flexibility, OSPF allows the configuration of virtual links to enable the backbone area to appear contiguous when they are actually not.

All routers in an area must agree on that area’s parameters. A separate copy of the link-state algorithm is run for each area. Because of this, most configuration parameters are defined on a per area basis. All routers belonging to an area must agree on that area’s configuration. Misconfiguration leads to adjacencies not forming between neighbors, and routing information might not flow, or even loop.

Authentication. You can authenticate OSPF protocol exchanges. 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 eight 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 you configure the authentication type per area with the ability to configure separate passwords per interface. This was extended to allow configuration of different authentication types and keys per interface. Also, you can 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.

You configure OSPF in the MULTINET:GATED.CONF file using a GateD protocol statement.

Format

ospf  yes | no | on | off
[{

    defaults
    {

      preference value ;
      cost cost ;
      tag [as] tag ;
      type 1 | type 2 ;
    } ;
    exportlimit routes ;
    exportinterval time ;
    traceoptions options;
    monitorauthkey key ;
    monitorauth  none | [simple | md5] authkey ;
    backbone | area area
    {

      authtype 0 | authtype 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 list [cost cost]
      {   interface-parameters } ;
      interface list nonbroadcast [cost cost]
      {

        pollinterval time ;
        routers
        {

          gateway [eligible] ;

        };
        interface-parameters
      } ;
      /* Backbone only: */
      virtuallink neighborid router-id transitarea area
      {   interface-parameters } ;
    } ;
}] ;

 

Options and Parameters

yes | on

no | off

Enables or disables OSPF support.

 

defaults

Defaults used when importing OSPF ASE routes into the GateD routing table, and exporting routes from the GateD routing table into OSPF ASEs, including:

preference value;	How OSPF routes compete with routes from other protocols in the GateD routing table. The default preference value is 150.
cost cost ;	Used when exporting a non-OSPF route from the GateD routing table into OSPF as an ASE. Export policy can explicitly override this. The default cost is 1.
tag [as] tag ;	OSPF ASE routes have a 32-bit tag field that the OSPF protocol does not use, but export policy can use it to filter routes. When OSPF interacts with an EGP, you can use the tag field to propagate AS path information. In this case you would specify the as keyword and the tag is limited to 12 bits of information. The default tag value is 0.
type 1 or 2 ;	Export policy can explicitly change and override the default here. The default is type 1.

 

exportlimit routes ;

How many ASEs are generated and flooded in each batch. The default export limits routes value is 100.

 

exportinterval time ;

How often a batch of ASE link state advertisements are generated and flooded into OSPF. The default export interval time value is 1 (once per second).

 

traceoptions 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
lsatransmit	Link State Advertisement (LSA) transmission
lsareceive	LSA reception
state	State transitions

 

Packet tracing options (which you can modify with detail, send, and recv):

hello	OSPF HELLO packets used to determine neighbor reachability
dd	OSPF Database Description packets used in synchronizing OSPF databases
request	OSPF Link State Request packets used in synchronizing OSPF databases
lsu	OSPF Link State Update packets used in synchronizing OSPF databases
ack	OSPF Link State Ack packets used in synchronizing OSPF databases

 

authtype 0 or 1 or none or simple	OSPF specifies an authentication scheme per area. Each interface in the area must use this same authentication scheme, although it can use a different authentication key. 0 is the same as none; 1 is the same as simple.
stub [cost cost]	A stub area is one in which there are no ASE routes. Use cost to inject a default route into the area with the specified cost.
networks { network [restrict] ;  network mask mask [restrict] ;  network masklen number [restrict];  host host [restrict] ; } ;	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 you specify restrict, 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.
stubhosts { host cost cost ; }	The stubhosts list specifies directly attached hosts that should be advertised as reachable from this router, and the costs with which they should be advertised. Specify point-to-point interfaces here on which it is not desirable to run OSPF.   It is also useful to assign an additional address to the loopback interface (one not on the 127 network) and advertise it as a stub host. If this address is the same one used as the router ID, it enables routing to OSPF routers by router ID, instead of by interface address. This is more reliable than routing to one of the router’s interface addresses, which may not always be reachable.
interface list cost cost {interface-parameters}	Use this form of the interface clause (with the optional cost value, and immediately followed by the interface-parameters) to configure a broadcast (which requires IP multicast support) or a point-to-point interface. (See the interfaces statement for a description of list.) Each interface has a cost. The costs of all the interfaces a packet must cross to reach a destination are summed to get the cost to that destination. The cost can be any non-zero value (the default is 1).

 

monitorauthkey key ;

monitorauth none | [simple | md5] authkey ;

You can query the OSPF state using the ospf_monitor utility, which sends nonstandard OSPF packets that generate a text response from OSPF. If you configure an authentication key, the incoming requests must match the specified authentication key. These packets cannot change OSPF state, but the act of querying OSPF can expend system resources. Not authenticated by default.

 

Backbone/Area Clause Options and Parameters

backbone or area area

Configures each OSPF router into at least one OSPF area. If you configure more than one area, at least one must be the backbone. Configure the backbone using the backbone keyword only; you cannot specify it as area 0. The backbone interface can be a virtuallink.

Further parameters include:

 

The following are the interface-parameters. You can specify them on any class of interface:

enable | disable ;
retransmitinterval time ;
transitdelay time ;
priority value ;
hellointerval time ;
routerdeadinterval time ;
authkey key ;

 

retransmitinterval time	Number of seconds between link state advertisement retransmissions for adjacencies belonging to this interface.
transitdelay time	Estimated number of seconds required to transmit a link state update over this interface. Takes into account transmission and propagation delays and must be greater than 0.
priority value	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 prevails. A router whose router priority is 0 is ineligible to become designated router.
hellointerval time	Length of time, in seconds, between Hello packets that the router sends on the interface.
routerdeadinterval time	Number of seconds not hearing a router’s Hello packets before the router’s neighbors will declare it down.
authkey key	Used by OSPF authentication to generate and verify the authentication field in the OSPF header. You can configure the authentication key on a per-interface basis. Specify it using 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.

 

The form of the interface clause with the nobroadcast option is for point-to-point interfaces only. By default, OSPF packets to neighbors on point-to-point interfaces are sent using the IP multicast mechanism. GateD detects this condition and falls back to using sending unicast OSPF packets to this point-to-point neighbor.

If you do not want IP multicasting, because the remote neighbor does not support it, specify nobroadcast to force the use of unicast OSPF packets. You can also use this option to eliminate warnings when GateD detects the bug mentioned previously. (See the previous page for the interface-parameters.)

Use this form of the interface clause to specify a nonbroadcast interface on a nonbroadcast multiaccess (NBMA) media. Since an OSPF broadcast media must support IP multicasting, you must configure a broadcast-capable media, such as Ethernet, that does not support IP multicasting as a nonbroadcast interface. A nonbroadcast interface supports any of the standard interface clauses listed previously, 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 poll interval.
routers gateway	By definition, it is not possible to send broadcast packets to discover OSPF neighbors on a nonbroadcast, so you must configure all neighbors. The list includes one or more neighbors and an indication of their eligibility to become a designated router.

 

virtuallink neighborid routerid transitarea area
{ interface-parameters } ;

For backbone only: 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 be configured on this system. You can specify all standard interface parameters defined by the interface clause previously described on a virtual link. (See the previous page for the interface-parameters.)

 

 

 

 

static

The static statements define the static routes GateD uses. A single static statement can specify any number of routes. These statements must occur after protocol statements and before control statements in GATED.CONF. Specify any number of static statements, each containing any number of static route definitions. You can override these routes with ones with better preference values.

 

Format

static
{

  host host  gateway list
          | network [mask mask  | masklen number] gateway list
          | default gateway list
                     [interface list]
                     [preference value]
                     [retain]
                     [reject]
                     [blackhole]
                     [noinstall]
                     ;
            network [mask mask  |  masklen number]
                     interface interface
                     [preference value]
                     [retain]
                     [noinstall]
                     ;
} ;

 

Options and Parameters

host...gateway list or default gateway list

Most general form of the static statement. 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 gateway is available, they are limited by the number of multipath destinations supported.

The second form of the network mask... clause farther down in the statement is for primitive support of multiple network addresses on one interface.

 

interface list

Gateways are valid only when they are on one of these interfaces.

 

preference value

Preference of this static route. Controls how this route competes with routes from other protocols. The default value is 60.

 

retain

Prevent specific static routes from being removed. Normally GateD removes all routes except interface routes from the kernel forwarding table during a graceful shutdown. Useful for ensuring that some routing is available when GateD is down.

 

noinstall

Do not install the route in the kernel forwarding table when active, but make it still exportable to other protocols. Normally the route with the lowest preference is installed there and is the route exported to other protocols.

 

 

 

 

 

import

The control statements are:

import

export

aggregate

generate

 

Format

import [restrict | preference value]

The import statements control importing routes from routing protocols, and installing the routes in GateD’s routing database. The format of an import statement varies depending on the source protocol. In all cases, you can specify one of two keywords to control how routes compete with other protocols:

restrict	Restrict the routes from 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 that they will not be installed in the forwarding table or exported to other protocols.
preference value	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 can be exported to other protocols. The individual protocols configure the default preferences.

 

Importing Routes from BGP and EGP

You can control EGP importation by AS. Note that EGP and BGP versions 2 and 3 only support propagating natural networks, so the host and default route filters are meaningless. BGP version 4 supports propagating any destination along with a contiguous network mask.

EGP and BGP both store any routes rejected implicitly by their not being mentioned in a route filter, or explicitly if restrict appears 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 removes the need to break and reestablish a session on reconfiguring if changing the importation policy.

The syntax of the import statement for importing routes from BGP or EGP is any of the following:

import proto  bgp | egp  autonomoussystem ASnumber restrict ;
import proto  bgp | egp  autonomoussystem ASnumber
  [preference value]  {
  route-filter [restrict  |  preference value] ; } ;
import proto bgp aspath ASpathregexp
  origin   any | [igp] [egp] [incomplete]   restrict ;
import proto bgp aspath ASpathregexp
  origin   any | [igp] [egp] [incomplete]
                            [preference value] {
                            routefilter [restrict | preference value] ; } ;

The third and fourth variation of the import statements is for BGP only and supports controlling propagation by using AS path regular expressions. An AS path is a list of ASs that routing information passes through to get to a router, and an indicator of the origin of the AS path. Use this information to set the preference of one path to a destination network over another. You do this by listing patterns applied to AS paths when importing and exporting routes. Each AS that a route passes through prepends its AS number to the beginning of the AS path.

 

Aspath Clause

The following aspath clause in the import statement indicates that an AS matching the ASpathregexp with the specified origin is matched. The parameters follow:

aspath ASpathregexp origin  any | [igp] [egp] [incomplete]

 

Aspath Clause Regular Expression

ASpathregexp

Regular expression, with the alphabet as the set of AS numbers, consisting of one or more AS path expressions, which are terms and operators. An AS path term (ASpathterm) consists of the following:

ASnumber	Any valid AS system number, from 1 through 65534.
.	Matches any AS number.
(ASpathregexp)	Parentheses group sub-expressions. An operator such as asterisk (*) or question mark (?) works on a single element or on a regular expression enclosed in parentheses.

 

Aspath Clause Operators

AS path operators consists of the following:

ASpathterm {m}	Exactly m repetitions, where m is a positive integer.
ASpathterm {m,}	m or more repetitions, where m is a positive integer.
ASpathterm {m,n}	At least m and at most n repetitions, where m and n are both nonnegative integers and m <= n.
ASpathterm *	Zero or more repetitions (shorthand for {0,}).
ASpathterm +	One or more repetitions (shorthand for {1,}).
ASpathterm ?	Zero or one repetition (shorthand for {0,1}).
ASpathterm | ASpathterm	Matches either term.

 

Remaining Import Statement Options

origin  any | [igp] [egp] [incomplete]

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

Importing Routes from RIP, HELLO, and Redirects

You can control importing RIP, HELLO, and Redirect routes by any protocol, source interface, or source gateway. If using more than one, they are processed from most general (protocol) to most specific (gateway). RIP and HELLO do not support preferences to choose between routes of the same protocol; they use metrics instead. They also do not save rejected routes since they have short update intervals.

The syntax of the import statement for importing routes from RIP, HELLO, or redirects is either of the following:

import proto  rip | hello | redirect
       [interface list  |  gateway list]
       restrict ;

import proto  rip | hello | redirect
       [interface list  |  gateway list]
       [preference value]
      {   routefilter [restrict  |  preference value] ; } ;

 

Importing Routes from OSPF

You can only control importing AS External (ASE) routes. OSPF intra- and inter-area routes are always imported into the GateD routing table with a preference of 10. If using an ospftag, the import clause only applies to routes with the specified tag.

You can only restrict importing OSPF ASE routes if functioning as an AS border router. Do this by specifying an export ospfase clause. Specifying an empty export clause can restrict importing ASEs, when no ASEs are exported.

Like the other interior protocols, you cannot use preference to choose between OSPF ASE routes; OSPF costs accomplish this. Routes rejected by policy go into the table with a negative preference.

The syntax of the import statement for importing routes from OSPF is either of the following:

import proto ospfase [tag ospftag] restrict ;

import proto ospfase [tag ospftag]
          [preference value]
         { routefilter [restrict  | preference value] ; } ;

 

 

 

 

export

 

Format

export [restrict | metric metric]

The export statement controls which routes GateD advertises to other systems. Like import, the export syntax varies slightly for each protocol. Both syntaxes are similar and the meanings of many of the parameters are the same. The main difference is that while source information controls importing routes, both destination and source information control exporting routes.

The outer portion of a given export statement specifies the destination of the routing information you control. The middle portion restricts the sources. The innermost portion is a route filter used to select individual routes.

One thing that applies in all cases is the specification of a metric. All protocols define a default metric for routes exported. In most cases, this can be overridden at several levels of the export statement. The most specific specification of a metric is the one applied to the route exported. The values you can specify for a metric depend on the destination protocol the export statement references:

restrict	Do not export anything. If specified on the destination portion of the export statement, it means not to export anything to this destination. If specified on the source portion, it means not to export anything from this source. If specified as part of a route filter, it means not to export the routes matching that filter.
metric metric	Metric used when exporting to the specified destination.

 

Exporting to EGP and BGP

The AS controls exporting to EGP and BGP, the same policy applied to all routers in the AS. EGP metrics range from 0 through 255, with 0 the most attractive. BGP metrics are 16-bit unsigned quantities (that range from 0 through 65535, inclusive with 0 the most attractive). While BGP version 4 actually supports 32-bit unsigned quantities, GateD does not yet support this.

If you do not specify an export policy, only routes to attached interfaces are exported. If you specify any policy, the defaults are overridden; you should explicitly specify everything you want 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.)

The syntax of the export statement for exporting routes to EGP or BGP is either of the following:

export proto  bgp | egp  as ASnumber  restrict ;

export proto  bgp | egp  as ASnumber  [metric metric]
    {  exportlist ; } ;

 

Exporting to RIP and HELLO

Any protocol, interface, or gateway can control exporting to RIP and HELLO. If you specify more than one, 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 you do not specify an export policy, RIP and interface routes are exported into RIP and HELLO, and interface routes are exported into HELLO. If you specify any policy, the defaults are overridden; it is necessary to explicitly specify everything that should be exported.

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 is capable of propagating all routes, when not sending version 1 compatible updates.

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

The syntax of the export statement for exporting routes to RIP or HELLO is either of the following:

export proto  rip | hello
       [interface list  |  gateway list] restrict ;

export proto  rip | hello
       [interface list  |  gateway list]  [metric metric]
    {  exportlist ; } ;

 

Exporting to OSPF

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 details on the two types). Specify the default type using the defaults subclause of the ospf clause. You can override this with the export statement.

OSPF ASE routes also have the provision to carry a tag. This is an arbitrary 32-bit number you can use on OSPF routers to filter routing information. (See the OSPF protocol configuration for details on OSPF tags.) You can override the default tag specified by the ospf defaults clause with a tag specified on the export statement.

The syntax of the export statement for exporting routes to OSPF is either of the following:

export proto osfpase [type 1 | 2] [tag ospf-tag]  restrict ;

export proto osfpase [type 1 | 2] [tag ospf-tag]
       [metric metric]
      { exportlist ; } ;

 

Exporting BGP and EGP Routes

You can specify BGP and EGP routes by source AS. You can export all routes by AS path. The syntax of the proto statement for exporting BGP or EGP routes is either of the following:

proto  bgp | egp  autonomoussystem ASnumber  restrict ;

proto  bgp | egp  autonomoussystem ASnumber  [metric metric]
     {  routefilter [restrict  |  metric metric] ; } ;

 

Exporting RIP and HELLO Routes

You can export RIP and HELLO routes by protocol, source interface, or source gateway. The syntax of the proto statement for exporting RIP or HELLO routes is either of the following:

proto  rip | hello
    [interface list  |  gateway list]  restrict ;

proto  rip | hello
    [interface list  |  gateway list]  [metric metric]
    {  routefilter [restrict  |  metric metric] ; } ;

 

Exporting OSPF Routes

You can export both OSPF and OSPF ASE routes into other protocols. The syntax of the proto statement for exporting OSPF routes is either of the following:

proto  ospfase | ospfase  restrict ;

proto  ospfase | ospfase [metric metric]
    { routefilter [restrict  |  metric metric] ; } ;

 

Exporting Routes from Nonrouting Protocols with Interface

If you want GateD to export direct or static routes, or routes learned from the kernel, use the protocol statement or interface statement along with the interface of the next hop in the GateD configuration file. The syntax of the proto statement for exporting routes from nonrouting protocols with an interface is either of the following:

proto  direct | static | kernel
    [interface list] restrict ;

proto  direct | static | kernel
    [interface list]  [metric metric]
    { routefilter [restrict  |  metric metric] ; } ;

The proto statement parameters include:

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. You can export these routes 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.

 

Exporting Routes from Non-Routing Protocols by Protocol

If you want GateD to export default or aggregate routes, use the protocol statement in the GateD configuration file. The syntax of the proto statement for exporting routes from nonrouting protocols by protocol is either of the following:

proto default | aggregate  restrict ;
proto default | aggregate
       [metric metric]
       { routefilter [restrict  |  metric metric] ; } ;

The proto statement parameters include:

default	Routes created by the gendefault option. Use route generation instead.
aggregate	Routes synthesized from other routes when using the aggregate and generate statements.

 

Exporting by AS Path

When configuring BGP, all routes get an AS path when 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. (The AS path regular expression syntax appears in the Importing Routes from BGP and EGP subsection.)

The syntax of the proto statement for exporting by AS path is either of the following:

proto  proto | all  aspath ASpathregexp
  origin  any | [igp] [egp] [incomplete]  restrict ;
proto  proto | all  aspath ASpathregexp
  origin  any | [igp] [egp] [incomplete]  [metric metric]
       { routefilter [restrict  |  metric metric] ; } ;

 

Exporting by Route Tag

Both OSPF and RIP version 2 currently support tags. All other protocols always have a tag of zero. You can select the source of exported routes based on this tag. This is useful when classifying routes by tag when exporting them into a given routing protocol. The syntax of the proto statement for exporting by route tag is either of the following:

proto  proto | all  all tag tag restrict ;
proto  proto | all  all tag tag
      [metric metric]
      { routefilter [restrict  |  metric metric] ; } ;

 

 

 

 

 

aggregate

 

Use route aggregation to generate a more general route from a specific one. Use it, for example, at an AS border to generate a route to a network to be advertised through EGP, given the presence of one or more subnets of that network learned through RIP. Regional and national networks also use route aggregation to reduce routing information. By carefully allocating network addresses to clients, regional networks can just announce one route to regional networks instead of hundreds. No aggregation occurs unless explicitly requested in an aggregate statement.

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 that does not match one of the component routes that led to the generation of an aggregate route, is supposed to respond with an ICMP network unreachable message. This prevents packets for unknown component routes from following a default route into another network where they would be continuously forwarded back to the border router, until their TTL expires. Sending an unreachable message for a missing piece of an aggregate is only possible on systems that support reject routes, which MultiNet does not.

 

Format

aggregate  default | network [mask mask  |  masklen number]
     [preference value] [brief]
     { proto [all | direct | static | kernel | aggregate | proto]
           [as AS  |  tag tag  |  aspath ASpathregexp] restrict ;
      proto [all | direct | static | kernel | aggregate | proto]
           [as AS  |  tag tag  |  aspath ASpathregexp]  [preference value]
           { routefilter [restrict  |  preference value] ; } ;
     } ;

 

Options and Parameters

preference value

The default preference value is 130.

 

brief

Truncate the AS path 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, you can select the contributing protocol from among those currently configured in GateD.

 

as AS

Restrict selection of routes to those learned from the specified AS.

 

tag tag

Restrict selection of routes to those with the specified tag.

 

aspath ASpathregexp

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

 

restrict

Restrict certain routes from contributing to the specified aggregate.

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

 

 

 

 

 

generate

 

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

 

Format

generate  default | network [mask mask  |  masklen number]
       [preference value] [brief]
            { [as AS  |  tag tag  |  aspath ASpathregexp]
            restrict ;
       proto [all | direct | static | kernel | aggregate | proto]
            [as AS  |  tag tag  |  aspath ASpathregexp]
            [preference value]
            { routefilter [restrict  |  preference value] ; } ;
       } ;

 

 

 

 

 

Sample GateD Configurations

The below diagram shows two networks connected within an AS using RIP. The following configuration files show the RIP statements on each end host and gateway alpha, which has IP forwarding enabled. All systems are running GateD.

 

Configuration File for izar

#  turn on RIP and listen for updates.
#
rip on;

 

GateD Configuration File for alpha

#  turn on RIP.
#
rip yes;
#
#  use RIP to pass routing information to the banzai network.
#
export proto rip interface 10.10.10.1
    {
    #  we know about the flowers network, so announce it.
    #
    proto direct {
      10.10.8.0 mask 255.255.255.0;
      };
    #  use RIP to announce all routes learned from flowers.
    #
    proto rip interface 10.10.8.0 {
       all;
       };
     };

 

GateD Configuration File for omega

#  turn on RIP and listen for updates.
#
rip on;

Below is a sample RIP statement where the gateway announces a default route to the backbone, and announces all of the individual subnet routes to the outside world.

#  enable RIP:
#
rip yes;

#  using RIP, announce all local subnets via interface 192.168.12.3:
#
export proto rip interface 192.168.12.3 metric 3
    {
       proto rip interface 192.168.1.5
       {
           all;
       };
     };
#
#  Using RIP, announce default via interface 192.168.1.5:
#
export proto rip interface 192.168.3.1
     {
        proto rip interface 192.168.1.5
         {
            default;
         };
      };

 

Below is a configuration for AS 283 that enables RIP and OSPF, which you can use to test both.

# this interface is passive:
#
interfaces {
        interface SVA-0 passive;
        };
#
#  this Autonomous System number is 283:
#
autonomoussystem 283;
#
#  turn on RIP:
#    packets are to be broadcast.
#    metric for routes learned via other protocols is 5.
#    multicast RIP V2 packets on SVA-0.
#
rip yes {
     broadcast;

                       defaultmetric 5;
                       interface SVA-0 version 2 multicast;
                       };
#
# turn on OSPF:
#    Trace Link State Advertisement creation and
#    Shortest Path First calculations
#    use authentication key "ZZZZZZZZ" when handling OSPF queries.
#    this system is on the backbone.
#      use simple password authentication for this area.
#      make this system very unlikely to be a designated router.
#      set the OSPF header authentication key to "YYYYYYYY" for
#      packets going out on SVA-0.
#

ospf yes {
       traceoptions lsabuild spf;
       monauthkey "ZZZZZZZZ";
       backbone {
           authtype simple;
           interface all {
              priority 2;
              };
           interface SVA-0 {
              authkey "YYYYYYYY";
              };
           };
      };

 

Below is a configuration for a static route.

#
# in this example our host's address is 192.168.1.42
#
static {
         192.168.2.0 masklen 24 interface 192.168.1.42 retain;
        default gateway 192.168.1.1 ;
              ;

 

 

RTSOLD

RTSOLD is the IPv6 router solicitation daemon.  It will be automatically run at startup when IPv6 has been enabled for an interface.  RTSOLD sends ICMPv6 Router Solicitation messages on the specified interface.  The ICMPv6 code will use the information in Router Advertisement messages that it receives to configure interface prefix and default route. IPv6 Routers send out advertisement messages periodically and when requested; usage of RTSOLD reduces the amount of time until a router advertisement message is processed by the system and IPv6 routes are defined. RTSOLD will send out solicitation messages until a Router Advertisement message has been received or three attempts have been made.

Format

rtsold [-adDF] [interface]

 

Options:

·         a - auto interface probe.  RTSOLD determines what interfaces are available and sends out solicitation messages on the interfaces that it finds.

·         d - debug level 1

·         D - debug level 2, includes timer information

·         F - Force setting of kernel variables.  IPV6CTL_ACCEPT_RTADV is set to 1 and IPV6CTL_FORWARDING is set to 0 (zero).  This allows Router Advertisement messages to be processed and disables forwarding (routing) on this system.

MULTINET:START_MULTINET.COM will start RTSOLD with -a -F when an IPv6 interface has been configured.