HP TCP/IP Services for OpenVMS
Management


Previous Contents Index

A.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 the send nor the recv option is specified, both sent and received packets are traced.
recv Limits the tracing to packets received. If neither the send nor the 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.

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

A.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 [generate default] option is preferred to the use of the gendefault option. The gendefault option may be removed in the future. See Section A.18.6 for more information.

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 the RIP 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.

A.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 or interface type name. Be careful with the use of interface names because future versions of TCP/IP Services may allow more than one address per interface. The interface_list is a list of one or more interface names including wildcard names (names without a number) and names 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] 
            [aliases-nexthop ( primary | lowestip | keepall ) 
            ; 
       interface interface_list
            [preference preference] 
            [down preference preference] 
            [passive] 
            [simplex] 
            [reject] 
            [blackhole] 
            [ AS autonomoussystem ] 
            ; 
       define  address
            [broadcast address] | [pointtopoint  address] 
            [netmask mask] 
            [multicast] 
            ; 
          } ; 

The options portion of the interfaces statement allows configuration of the following global options related to interfaces:
strictinterfaces Indicates that it is a fatal error to refer to an interface in the configuration file that is not present when GATED is started and not listed in a define statement. Without strictinterfaces , a warning message is issued but GATED will continue.
scaninterval time Specifies how often GATED scans the kernel interface list for changes. The default is every 15 seconds on most systems, and 60 seconds on systems that pass interface status changes through the routing socket (BSD 4.4). Note that GATED also scans the interface list on receipt of a SET GATED/CHECK_INTERFACES.
aliases-nexthop primary | lowestip | keepall
  Specifies which address GATED will install as the next hop for interface routes. If you specify primary , the primary interface address (default) will be installed. If you specify lowestip , the address with the lowest IP address will be installed. If you specify keepall , all interface routes are kept in the kernel up to a maximum of RT_N_MULTIPATH routes. aliases-nexthop is a compile-time constant. aliases-nexthop is a global parameter that may be overridden for interfaces using the interface option.

The interface portion of the interfaces statement sets interface options on the specified interfaces. An interface list is all or a list of interface names (see Section A.10.1), domain names, or numeric addresses. Options available on this statement are:
preference preference
  Sets the preference for routes to this interface when it is up and appears to be functioning properly. The default preference is 0.
down preference preference
  Sets the preference for routes to this interface when GATED does not believe it to be functioning properly, but the kernel does not indicate it is down. The default value is 120.
passive Prevents GATED from changing the preference of the route to this interface if it is not believed to be functioning properly due to lack of received routing information. The GATED daemon only performs this check if the interface is actively participating in a routing protocol.
simplex Defines an interface as unable to hear its own broadcast packets. Some systems define an interface as simplex with the IFF_SIMPLEX flag; others require it to be specified in the configuration file. On simplex interfaces, a sender's own packets are assumed to have been looped back in software and are not used as an indication that the interface is functioning properly.
reject Specifies that the address of the interface matching these criteria is used as the local address when installing reject routes in the kernel.

Use reject only with systems based on BSD 4.3 Tahoe or earlier that have installed a reject/blackhole pseudo-interface.

blackhole Specifies that the address of the interface matching these criteria is used as the local address when installing reject routes in the kernel. Use this only with systems based on BSD 4.3 Tahoe or earlier that have installed a reject/blackhole pseudo interface.

The define portion of the interfaces statement defines interfaces that might not be present when GATED is started so they may be referenced in the configuration file when strictinterfaces is defined. The following are valid define keywords:
broadcast address Defines the interface as broadcast capable (for example, Ethernet or Token Ring) and specifies the broadcast address.
pointopoint address Defines the interface as a point-to-point interface (for example, SLIP or PPP) and specifies the address on the local side. The first address on the define statement references the address of the host on the remote end of the interface, the address specified after this pointopoint keyword defines the address on the local side of the interface.
netmask mask Specifies the subnet mask to be used on this interface. This is ignored on point-to-point interfaces.
multicast Specifies that the interface is multicast capable.
AS autonomoussystem Specifies the AS that will be used to create an AS path associated with the route created from the definition of this interface.

A.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 nor from DU0. RIP packets are sent only on interface LE1.

A.10.1.1 Example of Current Define Statements for GATED


 
interfaces { 
   define 192.168.12.5 broadcast 192.168.12.255 netmask 255.255.255.0 ; 
   define 192.168.13.129 netmask 255.255.255.252 broadcast 192.168.13.131;   
 
   # pointtopoint - is local side, 1st address is remote 
   define  192.168.13.116 pointtopoint 192.168.13.114 multicast; 
   }; 

A.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 RENO or later.
Loopback This interface must have the address of 127.0.0.1. Packets sent to this interface are sent back to the originator. This interface is also used as 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 routerid ; 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.

The remote address must be unique among all the interface addresses on a given router.

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

Nonbroadcast multi-access (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. 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.

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.

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

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

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

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


Previous Next Contents Index