Configuring for Manageability, Part I

Route Caching

First, more details concerning interfaces.

If a WAN interface is less than 256K, you may want to add “no ip route-cache” to make more buffers available. When process switching (i.e. using the CPU to make the forwarding decisions), the main memory buffers are used (as opposed to shared memory allocated to an interface, or memory elsewhere in the system).

On fast LAN interfaces in 7000 models with Silicon Switch Processor (SSP), you may wish to add per-protocol commands such as:

If you have a older model 7000 or AGS, you may need “ip route-cache cbus” instead. Either of these boosts performance and decreases CPU loading. Use autonomous, silicon, optimum, or netflow switching for the protocol(s) with significant traffic only. Memory for the cache is a scarce resource here.

[You’ll have to check which switching modes are available for each hardware platform you have. The help facility built into the router is one way to do this.]

If you have heavy traffic to / from hosts communicating from a primary IP subnet to a secondary IP subnet (or vice versa) on the same interface, use “ip route-cache same-interface” to increase throughput. This may be needed if you formerly segmented with a router and now have a switch with multiple IP subnets attached to it (and a Cisco router).

Be aware the caching technique also affects load-balancing (per-destination versus per-packet). The details vary with the network protocol.

Loopback Interface

If your addressing scheme can supply enough subnets, establish a loopback address on each router. This defines an address for the router which is always up, reachable if there is a path to the router. This is most often used with VLSM if a classless routing protocol (OSPF, EIGRP, BGP, IS-IS for IP) is in use.

This has several uses:

  • SNMP polling: network management software typically does not go beyond trying the first address returned from /etc/hosts or DNS. A similar benefit applies to telnet from the network management station: if there is a route to the router, you can telnet to it without thinking about which interfaces are up.
  • IP unnumbered: eliminate serial link IP addresses using the loopback address instead
  • OSPF router id: Cisco routers use a loopback address as OSPF router ID, instead of the highest IP address on an interface. This is stable in case of link outages.
  • SNA peering (RSRB, DLSw+, STUN): the loopback interface never goes down
  • Internal BGP peering: the iBGP peer is not lost if a key link goes down but there is another route
  • SLIP or PPP connectivity (with no physical LAN’s attached), handy for upgrading the Cisco operating software from a laptop
  • MACIP servers: MACIP server requires that you use a valid interface address, and by using the loopback address you can effectively give your MACIP server a separate ip subnet

Cisco allows configuration of loopback interfaces using the mask

SNMP Configuration

It’s best to restrict SNMP access to known network management stations, and a simple access list is used for this. This remains vulnerable to source address spoofing, but is better than nothing.

It is reasonably safe to allow read-only access without such an access list. Multiple community strings may be used for different network management groups’ accesses.

The SNMP community strings identify what a user can do, and also act as a password. If you don’t mind anyone getting SNMP data from your routers, including your routing tables and ARP caches, make “password1” above “public”, and leave off the access list number, 60, following the RO (read-only) community. If you’re on the Internet, you may well feel this is giving away too much information, in which case you’ll want a non-obvious password and probably the access list as well.

The RW (read-write) community string should be a different and well-chosen password that you don’t tell many people about. It allows your routers to be reconfigured, so guard it well! I strongly recommend using the access list to reduce the window of exposure here.

This allows SNMP-triggered rebooting of the router. Turn this on if you’re going to use CiscoWorks to download IOS images to routers. Otherwise, it’s better to leave this feature turned off.

If you have an old IOS release on an AGS+ or another rouer where the hardware can’t tell the software the chassis-id, you may want to configure:

(where YYYY is replaced by the actual ID, of course). Otherwise, this defaults to the chassis-id picked up from the hardware, if any.

To avoid unpleasant interactions with large groups of SNMP variables and SunNet Manager, and to allow larger SNMP packets to be used, configure

Most people using SNMP want to receive SNMP traps, as early indications of trouble (with polling serving as backup in case the traps are lost). For each management station, configure:

This causes the router to send traps to hosts a.b.c.d and a.b.c.g.

There are two SNMP variables almost no-one seems to set. If you want to impress people with how well-managed your shop is, configure:

Finally, if you wish to be paranoid (or careful) about people possibly trying to guess your SNMP community string (assuming they haven’t snooped it off a wire somewhere), you can configure

and the router will send traps when an invalid SNMP community string is used.

By the way, you can specify the traps’ source address. This should not be necessary if all IP addresses for the router resolve to the same primary name. If you think in terms of the file, /etc/hosts, it should look something like:

That way, you can ping or telnet to a specific interface, but the addresses all resolve as “paris”, the same name. In DNS terms, the PTR name should be consistent, use CNAME records for the aliases.

A final suggestion: if you are counting on SNMP traps, it’s wise to test them! There’s several ways you can lose traps between your router and getting an icon to blink in your network management software. It’s wise to make sure you didn’t overlook anything.

One possible test is to “no shutdown” and later “shutdown” an unused interface on a router that is configured to send traps. Please don’t accidentally do this to the one you’ve telnetted in by!


Accurate time is a valuable debugging tool. It can also be useful for other purposes. Unless Internet access or a system with atomic clock reference is available, the internal clock on a Cisco 7000 is a fairly reliable time source. That router (one and only one router) can be configured as follows:

This tells the router its timezone, that the internal clock-calendar is to be trusted as a time source, and that it should act as an authoritative time source. There are two approaches to timezones: one is to use them, so that logged events reflect local time. The other is to NOT use timezones, or to use the timezone of the network management station, so that all event times correspond to wall clock time for the network managers.

Other routers should obtain time in hierarchical fashion from the master clock. That is, some routers should use the master clock as server, more routers use those routers as time servers, and so on. This is configured wih:

The “ntp update-calendar” configuration command tells the 7000 router to update its internal calendar from NTP. The NTP server commands identify time servers for this router.

NTP authentication may also be desirable if there is concern about invalid NTP time sources on a network.

Configuring the router to recognize daylight savings time may also be appropriate. In the U.S., use:

This follows the usual U.S. rules (60 minute change, first Sunday in April through last Sunday in October).


Syslog provides valuable logging capabilities — you can track console messages from all your routers on your Unix network management station. Unix tools like grep, awk, or Perl can be used to produce management reports from the log files containing these messages. And if you have CiscoWorks 3.x, the nmlogd process inserts all such log messages into the base platform’s TRAP log file. If you have a trouble-ticket system, it normals processes all such messages, giving you another way to interact with the console messages, produce reports, and so on.

To render logging safe:

Ensure console logging is not active: in case debug is turned on, all those messages going to the console at 9600 baud can halt productive use of the router. The “logging buffered” makes such information still available via the “show logging” command, but in a somewhat safer way. It also provides a local log of messages in case they don’t make it back to your management station for some reason. This can be particularly useful if you have out-of-band access to a remote router. Its logged error messages may shed light on why it became unreachable!

Do this once for each management station you intend to receive logging messages.

You can have timestamps put on logging messages by the router. This can give you local time at which events occurred. If you’re logging messages to a buffer on the router, it gives you the interval between events. It’s not too accurate unless you have NTP or other means to accurately set and synchronize the time on the routers.

You can also provide timestamps for debug output, with:

To set the level of logging information:

This is the default logging level. I’ve read through all the low severity (-5 and -6) error messages on the Cisco routers, and they ALL look like information I’d like to have my management station(s) receive and log. The messages all indicate trouble that is currently happening or about to happen.

There is one exception, the “Configured by” messages. However, these are a good thing to have logged if you’re practicing some form of change control over router configurations. (With TACACs variants, the message indicates who did the configuring).

Don’t configure ‘logging trap debug’ unless you need to capture debug output. It’s probably not good to have debug output being sent across the network! It causes much traffic and it can fill up the file system on the logging host.

This is the default facility (sender of syslog information); it doesn’t hurt to make sure the messages get sent to the right syslog facility on the UNIX net management station