Configuring for Manageability, Part II

Peter J. Welcher

This month we continue with the theme of configuring a router for manageability.

Last month we discussed network revisions and rollouts, and network design. I made the claim that network design is important, because it can make your routers easier to configure and manage. In the Cisco Internetwork Design course, one of the important themes is that IP addressing shouldn't "just happen" but rather should be planned. (This of course applies to other network protocols as well.) Larger networks really should be addressed to allow summarization of routes. We saw how naming fits into this as well. Good naming makes it much easier to filter Appletalk and NetBIOS.

We also discussed good configuration practice for interfaces, including use of the "shutdown" and "description" commands, both of which allow your configuration to document your intended design for your network. Using Frame Relay DLCI number for subinterface number was another form of this same idea.

We'll pick up the thread this month with some more aspects of configuring interfaces. We'll then shift gears and talk about configuring SNMP, dealing with time, and making use of the syslog logging facility.

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:

interface fddi 0/0
ip route-cache sse
ip address ...

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.

interface loopback0
ip address a.b.c.d  255.255.255.252

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

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.

access-list 60 permit a.b.c.d 0.0.0.0
access-list 60 permit e.f.g.h 0.0.0.0
access-list 60 deny 0.0.0.0 255.255.255.255

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.

snmp-server community password1 RO 
snmp-server community password2 RO 60
snmp-server community password3 RW 60

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.

snmp-server system-shutdown

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:

snmp-server chassis-id YYYY

(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

snmp-server packetsize 4000

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:

snmp-server host a.b.c.d
snmp-server host a.b.c.g

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:

snmp-server contact XXXX
snmp-server location YYYY

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

snmp-server trap-authentication

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:

a.b.c.d        paris   paris_s0
e.f.g.h        paris   paris_e0

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!

Time

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:

clock timezone EST -5
clock calendar-valid
ntp master

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:

clock timezone PST -8
ntp update-calendar
ntp server m.n.o.p
ntp server m.n.o.r

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.

ntp authenticate
ntp authentication-key 55 md5 mySecretKey
ntp trusted-key 55

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

clock summer-time EDT recurring

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

Syslog

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:

logging on
logging buffered

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!

logging A.B.C.D 
logging A.B.C.G

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.

service timestamps log datetime

You can also provide timestamps for debug output, with:

service timestamps debug datetime

To set the level of logging information:

logging trap info

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.

logging facility local7

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.

To Be Continued

Don't touch that dial! We'll finish up this topic next month, including more configuration commands!

Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has nine CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw@netcraftsmen.net .