Managing Cisco Routers

Peter J. Welcher

In addition to doing network management consulting, I teach the CiscoWorks ICWC course. There are some frequently asked questions about managing routers. So an article on network management seems in order (all you wanted to know, in 6000 bytes or less).

Generally, people these days think managing routers is synonymous with SNMP. But the Cisco Networkers slides have a nice perspective on that: managing at the low end can involve things like configuring via telnet, show and debug commands, TFTP for configuration and downloading IOS updates to flash. Not to be a Cisco cheerleader, but Cisco routers really do have a wide variety of features that lend themselves well to managing the network. (How easy is it to configure the brand X router with the menu or MS Windows GUI , when you have to work across a modem dial-up link because your network is broken?) It's easy to overlook these features, and we shouldn't forget them. (But we're going to, for the remainder of this article).

Expect

So you've bought a shiny new SNMP management tool, and you have to enable SNMP in all your routers. We'll look at the commands to do this in a moment. There's a minor issue of actually having to configure your routers. Up to about 20 or 30 routers, doing it manually is tolerable if boring. More than that and you either need a team of fingers or an automated approach.

Until you do this for the first time, you can't use CiscoWorks to configure the routers in a group (it needs SNMP read-write access).

If you're working with a UNIX platform for network management, as most people are, you can use the EXPECT language to assist you. If you have CiscoWorks 2.x, you already have the EXPECT interpreter. Otherwise, it's freeware you can pick up from the usual archive sites (like ftp.uu.net). You'll need TCL as well, since EXPECT is based on TCL. Both are valuable tools, and many UNIX sites are using the Tk / TCL toolkit for rapid development of Xwindows software. Portions of CiscoWorks seem to be based on Tk, so this is high-quality freeware.

EXPECT is a marvelous tool for writing scripts to drive other programs. It recognizes prompts and sends keystrokes in response. It was written by Don Libes of NIST, and you can find papers on it in Usenix LISA (Large Systems Administration) conference proceedings, as well as on the Internet.

You don't even have to write your own EXPECT scripts to manage routers. There is a set by Matt Crawford of FERMILAB, available from Cisco's ftp.cisco.com. They're in pub/cisco-expect.shar.

Break out the three small scripts (each is about 1/2 page long when printed) and you've got a basic toolkit. The scripts are named ciscoexec and ciscoconfig, with ciscologin.expect for loading router names and passwords from a file. The ciscoexec script lets you feed EXEC commands to routers via telnet. The ciscoconfig script configures routers. Both take sequences of commands in quotes, separated by semicolons, on the command line. Having the router passwords in a UNIX file is of course a security issue. One possibility is to keep this toolkit under lock and key (chmod the directory, etc.) for occasional use only.

The scripts did need some tweaking to work with recent versions of EXPECT. Syntax seems to have changed mildly. I don't want lots of people bothering Matt, so I shortened the names (most of my stuff passes through DOS at one time or another). I added the line

set argv [ concat "cisexec" $argv ]

as the first line of the script (argv[0] seems to have been left out), and I added quotes to the send lines at the end, as in

send "terminal length 0\r"

Put "debug 1" at the start of the script and it will tell you what it's doing, in copious detail.

It may be some initial fiddling to get this to work, but it gives you a fallback tool if you ever should need it (for example, someone goofs and uses CiscoWorks to turn off SNMP in all your routers).

SNMP Platform

As soon as we get into SNMP management, the big question is "what network management software is best". I usually try to duck this, since the software that's available all has strengths and weaknesses. The bigger question is the range of devices each package can manage, and that depends to some extent on how actively you "manage" devices. Is having an icon for a PC managing it? (I don't think so.) Is receiving traps and lighting up an icon management? (Probably, but rather passive.) Is polling a device management? (Yes.)

As far as Operating System, UNIX seems to be where it's at. There's the minor issue of administering the system -- no problem if you can get another group in the company to do it (and not dictate to you). MS Windows will handle small networks, perhaps actively managing a few tens of devices. I hear rumors of various network management products coming for Windows NT. We'll have to see if Windows NT really has enough horsepower.

So let's assume you've got some SNMP package and are wondering what to do with it. Some people almost seem to feel guilty about not collecting every SNMP variable from every device on their network. If it makes you feel any better: you probably can't do that, unless you have management station CPU cycles and bandwidth to burn. It's more important to have just enough polling to watch whether interfaces are up or down, and to watch a few key variables such as line utilization, CPU load, and other items of importance in your business.

SNMP Configuration

So let's look at what's involved in configuring routers to speak SNMP version 1. Not much! Here's a sample configuration, with explanation mixed in.

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's best to restrict SNMP access to network management stations, and a simple access list is used for this. This remains vulnerable to source address spoofing, but is better than nothing.

snmp-server community password1 RO 60
snmp-server community password2 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+, you may want to configure:

snmp-server chassis-id ZZZZ

Otherwise, this defaults to the chassis-id.

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

This causes the router to send traps to host a.b.c.d.

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!

Syslog

I also recommend using the syslog facility to collect router console messages. I might even have enough to say to make up another article!

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 .