Troubleshooting gated

After creating or modifying a gated configuration file, you should start gated from the command line with the -C option. This option causes the configuration file to be parsed for syntax errors.

gated prints information about its activity in the form of tracing output. This information includes routes that gated reads, adds, and deletes from the kernel routing table, as well as packets sent and received.

You can specify tracing either with the gated -t command line option or with the traceoptions statement in the /etc/gated.conf file. Using any of the following combinations, you can determine where the tracing output is printed and whether tracing is performed:

	NOTE: With version 3.5 of gated, the two statements previously in the Trace class (tracefile and traceoptions) have been combined into one traceoptions statement. So, the tracefile statement has been eliminated. For details about the new syntax, type man 4 gated.conf at the HP-UX prompt.

Once tracing is started to a file, the trace file can be rotated. Receipt of a SIGUSR1 signal causes gated to stop tracing and closes the trace file. The trace file can then be moved out of the way. To send a SIGUSR1 signal to gated, issue one of the following commands:

/usr/bin/kill -SIGUSR1 pid

or

/usr/bin/kill -USR1 pid

where pid is gated's process ID, determined by invoking the command ps -ef | grep gated.

A subsequent SIGUSR1 signal starts tracing again to the same trace file. If the trace options are changed before tracing is started up again, the new options will take effect.

	NOTE: You cannot use the SIGUSR1 signal if tracing to a file has not previously been specified when starting gated.

Sending gated a SIGINT signal causes gated to write out its information in /var/tmp/gated_dump. The information includes the interface configurations, tasks information for each protocol, and the routing tables.

/usr/sbin/ripquery is a support tool that can be used to query gated for RIP routing information. ripquery sends out two types of commands: a POLL command or a RIP request command. gated responds to a POLL command by listing all routes learned from RIP that are in its routing table. This does not include the interface routes for the local network or routes from other protocols that are announced via RIP. When gated receives a RIP request command, it announces routes via RIP on that interface. This includes routes from other protocols that are being imported by gated on the node.

You can use ripquery to query other non-gated RIP routers. To do so, you may need to use the -p option. This option causes ripquery to initially send POLL commands and then, if there is no response, send RIP request commands. The default query (POLL commands) sent by ripquery may not be supported by all RIP routers. Type man 1M ripquery at the HP-UX prompt for more information.

/usr/sbin/ospf_monitor is a support tool that can be used to query OSPF routers for information on OSPF routing tables, interfaces, and neighbors, as well as data on AS external databases, link-state databases, error logs, and input/output statistics. Running the ospf_monitor command displays a prompt that allows you to enter interactive commands. See the ospf_monitor man page for details on using this tool.

First, check the syslogd output for any syntax errors that may have been flagged.

To detect incorrect configuration commands, use gated tracing. The following shows two sample configuration files, along with the trace files generated by gated. The node used has three interfaces: lan0, lan1, and lan2. In the configuration files, lan0, lan1, and lan3 are specified. In the first configuration shown, the strictintfs option has been specified for the interfaces, so gated exits when the error is detected.

Interface Configuration with strictintfs Option Specified

The following configuration references a non-existent interface. The line options strictintfs in the interfaces statement means that all configured interfaces must be present before gated starts.

traceoptions "tt" general; interfaces { options strictintfs ; interface lan0 lan1 lan3 passive ; } ; rip yes ;

The following is the tracing output that is produced when gated is started with this configuration:

trace_on: Tracing to "/tt" started Tracing flags enabled: general parse: conf.tt:4 Interface not found at 'lan3' parse_parse: 2 parse errors Exit gated[15941] version @(#)Revision: 1.0 based on Cornell GateD R3_5Beta_3

Interface Configuration without strictintfs Option Specified

The following configuration references a non-existent interface, but does not include the strictintfs option.

traceoptions "tt" general; interfaces { interface lan0 lan1 lan3 passive ; } ; rip yes ;

The following is the tracing output that is produced when gated is started with this configuration:

trace_on: Tracing to "/tt" started Tracing flags enabled: general inet_routerid_notify: Router ID: 15.13.119.134

The results of this same command can also be found in the gated_dump file, although not as easily. In the following segment of a gated_dump file, the interface is listed as passive in the interface policy statement at the bottom of the example.

Interfaces: lo0 Index 1 Change: <> State: <Loopback> Refcount: 2 Up-down transitions: 0 127.0.0.1 Metric: 0 MTU: 4072 Refcount: 4 Preference: 0 Down: 120 Change: <> State: <Up Loopback Multicast> Subnet Mask: 255.255.255.255 proto: RIP State: <NoIn NoOut> lan0 Index 2 Address 802.2 8:0:9:1b:da:1f Change: <> State: <> Refcount: 2 Up-down transitions: 0 15.13.119.134 Metric: 0 MTU: 1436 Refcount: 6 Preference: 0 Down: 120 Change: <> State: <Up Broadcast Multicast NoAge> Broadcast Address: 15.13.119.255 Subnet Number: 15.13.112 Subnet Mask: 255.255.248 lan2 Index 3 Address 802.2 8:0:9:3d:2c:b1 Change: <> State: <> Refcount: 2 Up-down transitions: 0 198.1.1.17 Metric: 0 MTU: 1436 Refcount: 4 Preference: 0 Down: 120 Change: <> State: <Up Broadcast Multicast> Broadcast Address: 198.1.1.255 Subnet Number: 198.1.1 Subnet Mask: 255.255.255 lan1 Index 4 Address 802.2 8:0:9:3d:3c:69 Change: <> State: <> Refcount: 2 Up-down transitions: 0 198.2.1.40 Metric: 0 MTU: 1436 Refcount: 4 Preference: 0 Down: 120 Change: <> State: <Up Broadcast Multicast NoAge> Broadcast Address: 198.2.1.255 Subnet Number: 198.2.1 Subnet Mask: 255.255.255 Interface policy: Interface lan0 lan1 lan3 passive

Note that the state recorded in lan2 does not contain the "NoAge" flag because the interface was not set to "passive" in the interface policy statement.

A common mistake is to expect gated to always send out RIP packets when you specify rip yes in a configuration file. gated will be an active RIP participant only if the host is a router (the host has more than one network interface).

gated maintains a complete routing table in user space, and keeps the kernel routing table synchronized with its table. When gated starts, it reads the entries in the kernel routing table. However, if gated does not get confirmation from its routing protocols (RIP, OSPF, etc.) about a route, it will delete the route from its tables and the kernel routing table.

It is common to see gated delete the default route that many people configure in the /etc/rc.config.d/netconf file. To solve this problem, configure a static default route as described in the section “Installing Static Routes”.

Another common scenario occurs in networks where not all gateways implement the gated routing protocols. In this situation, routes that do not use gated gateways will not be confirmed by gated, and gated will delete them unless a static statement is included in /etc/gated.conf:

static {
    13.0.0.0 mask 0xff000000 gateway 15.14.14.14 ;
};

The static entry in the above example ensures that the local system will include a route to network 13.0.0.0 even though the gateway to that network (15.14.14.14) is not running any of the gated protocols.

You may want to put restrict clauses in the export statements to keep these extra routes from being advertised.

Start by looking at the routing table maintained by gated. Send gated a SIGINT, and look at the information output in /var/tmp/gated_dump. Look for the entry of the route in question. The entry shows the protocol that this route was heard over and the first-hop router. The first-hop router is likely to be the immediate source of the information.

If the route was learned over RIP, use /usr/sbin/ripquery to query the first-hop router for the route. That router may claim to have heard the route from a router further on. If the first-hop router is another host running gated, have that host's gated dump its routing table to find out where it learned about the route. You may have to repeat this process several times to track down the original source of the route. If the problem is that you expect the route to go through a different router, turn on gated tracing. The tracing tells you which routers are advertising this route and the values attached to those routes.

Tracking down this problem is much like the previous problem (problem 3, above). You expect one or more routers to advertise the route. Turn on gated tracing to verify that gated is receiving packets of the type of routing protocol you expect. If these packets do not contain a route you expect to be there, trace packets on the router you expect to advertise the route.