Router O&M Functions

10.3.2.1 Maintenance - Hardware Diagnosis

Each router SHOULD operate as a stand-alone device for the purposes of local hardware maintenance. Means SHOULD be available to run diagnostic programs at the router site using only on-site tools. A router SHOULD be able to run diagnostics in case of a fault. For suggested hardware and software

diagnostics see Section [10.3.3].

10.3.2.2 Control - Dumping and Rebooting

A router MUST include both in-band and out-of-band mechanisms to allow the network manager to reload, stop, and restart the router. A router SHOULD also contain a mechanism (such as a watchdog timer) which will reboot the router automatically if it hangs due to a software or hardware fault.

A router SHOULD IMPLEMENT a mechanism for dumping the contents of a router’s memory (and/or other state useful for vendor debugging after a crash), and either saving them on a stable storage device local to the router or saving them on another host via an up-line dump mechanism such as TFTP (see [OPER:2], [INTRO:3]).

10.3.2.3 Control - Configuring the Router

Every router has configuration parameters which may need to be set. It SHOULD be possible to update the parameters without rebooting the router; at worst, a restart MAY be required.

There may be cases when it is not possible to change parameters without rebooting the router (for instance, changing the IP address of an interface). In these cases, care should be taken to minimize disruption to the router and the surrounding

network.

There SHOULD be a way to configure the router over the network either manually or automatically. A router SHOULD be able to upload or download its parameters from a host or another router, and these parameters SHOULD be convertible into some sort of text format for making changes and then back to the form the router can read. A router SHOULD have some sort of stable storage for its configuration. A router SHOULD NOT believe protocols such as RARP, ICMP Address Mask Reply, and MAY not believe BOOTP.

DISCUSSION:

It is necessary to note here that in the future RARP, ICMP Address Mask Reply, BOOTP and other mechanisms may be needed to allow a router to auto-configure. Although routers may in the future be able to configure automatically, the intent here is to discourage this practice in a production

environment until such time as auto-configuration has been tested more thoroughly. The intent is NOT to discourage auto-configuration all together. In cases where a router is expected to get its configuration automatically it may be wise to allow the router to believe these things as it comes

up and then ignore them after it has gotten its configuration.

10.3.2.4 Netbooting of System Software

A router SHOULD keep its system image in local non-volatile storage such as PROM, NVRAM, or disk. It MAY also be able to load its system software over the network from a host or another router.

A router which can keep its system image in local non-volatile storage MAY be configurable to boot its system image over the network. A router which offers this option SHOULD be

configurable to boot the system image in its non-volatile local storage if it is unable to boot its system image over the

network.

DISCUSSION:

It is important that the router be able to come up and run on its own. NVRAM may be a particular solution for routers used in large networks, since changing PROMs can be quite time consuming for a network manager responsible for numerous or geographically dispersed routers. It is important to be able to netboot the system image because there should be an easy way for a router to get a bug fix or new feature more quickly than getting PROMS installed. Also if the router has NVRAM instead of PROMs, it will netboot the image and then put it in NVRAM.

A router MAY also be able to distinguish between different configurations based on which software it is running. If configuration commands change from one software version to another, it would be helpful if the router could use the configuration that was compatible with the software.

10.3.2.5 Detecting and responding to misconfiguration

There MUST be mechanisms for detecting and responding to misconfigurations. If a command is executed incorrectly, the router SHOULD give an error message. The router SHOULD NOT accept a poorly formed command as if it were correct.

DISCUSSION:

There are cases where it is not possible to detect errors:

the command is correctly formed, but incorrect with respect to the network. This may be detected by the router, but may not be possible.

Another form of misconfiguration is misconfiguration of the network to which the router is attached. A router MAY detect misconfigurations in the network. The router MAY log these findings to a file, either on the router or a host, so that the network manager will see that there are possible problems on the network.

DISCUSSION:

Examples of such misconfigurations might be another router with the same address as the one in question or a router with the wrong subnet mask. If a router detects such

problems it is probably not the best idea for the router to try to fix the situation. That could cause more harm than good.

10.3.2.6 Minimizing Disruption

Changing the configuration of a router SHOULD have minimal affect on the network. Routing tables SHOULD NOT be unnecessarily flushed when a simple change is made to the router. If a router is running several routing protocols, stopping one routing protocol SHOULD NOT disrupt other routing protocols, except in the case where one network is learned by more than one routing protocol.

DISCUSSION:

It is the goal of a network manager to run a network so that users of the network get the best connectivity possible.

Reloading a router for simple configuration changes can cause disruptions in routing and ultimately cause

disruptions to the network and its users. If routing tables are unnecessarily flushed, for instance, the default route will be lost as well as specific routes to sites within the network. This sort of disruption will cause significant downtime for the users. It is the purpose of this section to point out that whenever possible, these disruptions should be avoided.

10.3.2.7 Control - Troubleshooting Problems

(1) A router MUST provide in-band network access, but (except as required by Section [8.2]) for security considerations this access SHOULD be disabled by default. Vendors MUST document the default state of any in-band access.

DISCUSSION:

In-band access primarily refers to access via the normal network protocols which may or may not affect the permanent operational state of the router. This includes, but is not limited to Telnet/RLOGIN console access and SNMP operations.

This was a point of contention between the operational out of the box and secure out of the box contingents.

Any automagic access to the router may introduce insecurities, but it may be more important for the customer to have a router which is accessible over the network as soon as it is plugged in. At least one vendor supplies routers without any external console access and depends on being able to access the router via the network to complete its configuration.

Basically, it is the vendors call whether or not band access is enabled by default; but it is also the vendors responsibility to make its customers aware of possible insecurities.

(2) A router MUST provide the ability to initiate an ICMP echo. The following options SHOULD be implemented:

o Choice of data patterns o Choice of packet size o Record route

and the following additional options MAY be implemented:

o Loose source route o Strict source route o Timestamps

(3) A router SHOULD provide the ability to initiate a

traceroute. If traceroute is provided, then the 3rd party traceroute SHOULD be implemented.

Each of the above three facilities (if implemented) SHOULD have access restrictions placed on it to prevent its abuse by

unauthorized persons.