DIGITAL TCP/IP Services for OpenVMS
Management
Previous Contents Index

B.7.2 Packet Tracing

Every protocol has one or more options for tracing packets. All protocols allow the packets keyword to be used for tracing all packets sent and received by the protocol. Most protocols have other options for limiting tracing to a useful subset of packet types. These tracing options can be further controlled with the following modifiers:
detail Specifies a more verbose format to provide more information about the contents of the packet. The detail option must be specified before send or recv. By default, packets are traced in a terse form of one or two lines.
send Limits the tracing to packets sent received. If neither send nor recv option is specified, both sent and received packets are traced.
recv Limits the tracing to packets received. If neither send nor recv option is specified, both sent and received packets are traced.

Note
If a protocol allows several different types of packet tracing, modifiers can be applied to each individual type. Be aware, however, that within one tracing specification the trace flags are summed up, so specifying detail packets turns on full tracing for all packets.

B.8 Directive Statements

Directive statements provide direction to the GATED configuration language parser about included files and the directories in which these files reside. Directive statements are immediately acted upon by the parser. Other statements terminate with a semicolon (;), but directive statements terminate with a new line. The two directive statements are as follows:

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

B.9 Options Statements

The options statement allows specification of some global options. If used, options must appear before any other type of configuration statement in the TCPIP$GATED.CONF file.

The syntax for the options statement is as follows: 


  options 
 [nosend] 
 [noresolv] 
 [gendefault [preference preference] [gateway gateway]] 
 [mark time] 
 ;

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

gendefault [preference preference] [gateway gateway] When gendefault is enabled and a BGP or EGP neighbor is up, a default route with the special protocol default is created. This can be disabled per BGP/EGP group with the nogendefault option. By default, this route has a preference of 20. This route is normally not installed in the kernel forwarding table; it is only present so it can be announced to other protocols.

If a gateway is specified, the default route is installed in the kernel forwarding table with a next hop of the listed gateway.

Note that the use of the more general option is preferred to the use of the gendefault option. The gendefault option may be removed in the future. See the section on Route Aggregation in the gated.control(4) manual reference page for more information on the generate statement.

nosend Do not send any packets. This option makes it possible to run GATED on a live network to test protocol interactions without actually participating in the routing protocols. The packet traces in the GATED log can be examined to verify that GATED is functioning properly. This is useful for RIP and HELLO and possibly the SMUX SNMP interface. This option does not apply to BGP and is not useful with EGP and OSPF.
noresolv By default, GATED tries to resolve symbolic names into IP addresses by using the gethostbyname() and getnetbyname() library calls. These calls usually use the Domain Name System (DNS) instead of the host's local host and network tables. If there is insufficient routing information to send DNS queries, GATED deadlocks during startup. This option can be used to prevent these calls; symbolic names result in configuration file errors.
mark time Specifying this option causes GATED to output a message to the trace log at the specified interval. This can be used to determine if GATED is still running.

B.10 Interface Statements

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

The syntax for the interfaces statement is as follows: 


  interfaces { 
        options 
     [strictinterfaces] 
     [scaninterval time] 
     ; 
       interface interface_list
       [preference preference] 
       [down preference  preference] 
       [passive] 
       [simplex] 
       [reject] 
       [blackhole] 
       ; 
       define  address
            [broadcast  address] | [pointtopoint  address] 
            [netmask  mask] 
            [multicast] 
            ; 
  } ;

Here,

B.10.1 Interface Lists

An interface list is a list of references to interfaces or groups of interfaces. The following four methods, from most general to most specific, are available for referring to interfaces:

ALL Refers to all available interfaces.
Interface name wildcard Refers to all the interfaces of the same type. Interfaces consist of the device driver name and a unit number, for example, LE0. References to the name contain only alphabetic characters and match any interfaces that have the same alphabetic part.
Interface name Refers to a specific interface, usually one physical interface. These are specified as an alphabetic part followed by a numeric part. This will match one specific interface. But be aware that on many systems, there can be more than one protocol (for example, IP) address on a given physical interface. For example, EF1 matches an interface named EF1, but not an interface named EF10.
Interface address Matches one specific interface. The reference can be by protocol address (for example, 10.0.0.51) or by symbolic host name (for example, nic.ddn.mil). Note that a symbolic host name reference is only valid when it resolves to only one address. Use of symbolic host names is not recommended.

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

For example, the following interface list is for a system with three interfaces, LE0, LE1, and DU0: 


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

In this example, RIP packets are accepted from interfaces le0 and le1, but not from du0. RIP packets are sent only on interface le1.

B.10.2 IP Interface Addresses and Routes

The BSD 4.3 and later networking implementations allow the following four types of interfaces. Some implementations allow multiple protocol addresses per physical interface, but these are mostly based on BSD 4.3 or later.
Loopback This interface must have the address of 127.0.0.1. Packets sent to this interface are sent back to the originator. This interface is also used as an interface for implementing other features, such as reject and blackhole routes. Although a netmask is reported on this interface, it is ignored. It is useful to assign an additional address to this interface that is the same as the OSPF or BGP router ID; this allows routing to a system based on the router ID that will work if some interfaces are down.
Broadcast This is a multiaccess interface capable of a physical level broadcast, such as Ethernet, Token Ring, and FDDI. This interface has an associated subnet mask and broadcast address. The interface route to a broadcast network is a route to the complete subnet.
Point-to-point This is a tunnel to another host, usually on some sort of serial link. This interface has a local address and a remote address. Although it may be possible to specify multiple addresses for a point-to-point interface, there is no useful reason for doing so.

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

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

Nonbroadcast multi-access or nbma This type of interface is multiaccess, but not capable of broadcast, for example, frame relay and X.25. This type of interface has a local address and a subnet mask. (Not supported.)

The GATED daemon ensures that there is a route available to each IP interface that is configured and up. Normally this is done by the SET INTERFACE command that configures the interface; GATED also does it to ensure consistency.

For point-to-point interfaces, GATED installs some special routes. If the local address on one or more point-to-point interfaces is not shared with a non-point-to-point interface, GATED installs a route to the local address pointing at the loopback interface with a preference of 110. This ensures that packets originating on this host destined for this local address are handled locally.

OSPF prefers to route packets for the local interface across the point-to-point link where they will be returned by the router on the remote end. This is used to verify operation of the link. Because OSPF installs routes with a preference of 10, these routes override the route installed with a preference of 110.

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

When the status of an interface changes, GATED notifies all the protocols, which take the appropriate action. The GATED daemon assumes that interfaces that are not marked UP do not exist.

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

B.11 Definition Statements

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

B.11.1 Autonomous System Configuration

The statement autonomoussystem as_number [loops number]; sets the AS number of this router used by BGP EGP. The AS number is the official autonomous system number assigned to you by the Network Information Center (NIC).

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

B.11.2 Router ID Configuration

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

B.11.3 Martian Configuration

Sometimes a misconfigured system sends out invalid destination addresses. These invalid addresses, called martians, are rejected by the routing software. A martian configuration defines a list of martian addresses from which all routing information is ignored. A martian configuration is structured as follows: 


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

The martians martian_list statement adds martian addresses to a martian address list. Routing information will not be accepted from the addresses specified in this list.

You can specify the allow parameter to explicitly allow a subset of a range that was disallowed.

B.11.4 Sample Definition Statements

The following sample shows definition statements for a system: 


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

A description of each statement in this sample follows:

B.12 Protocol Overview

Routing protocols determine the "best" route to each destination and distribute routing information among the systems on a network. Routing protocols are divided into two general groups: interior and exterior protocols. GATED software combines management of the interior and exterior routing protocols in one software daemon.

B.12.1 Interior Routing Protocols

Interior protocols are used to exchange reachability information within an autonomous system (AS). They are refered to as a class by the acronym IGP. There are several interior protocols:

Previous Next Contents Index