Configuring for Manageability, Part I

Peter J. Welcher

I've installed CiscoWorks 3.0 at a few sites lately, as part of some network management consulting work. Configuring a router for manageability ties into this rather naturally, and seems like a topic of general interest. So that's what we'll talk about this month (and next).

This is especially important if you're about to roll out a new network, perhaps converting SNA leased lines to run over Frame Relay, using Cisco routers, TCP/IP, and perhaps DLSw+. When a site is implementing new router connectivity, it is useful to work from a configuration template to enhance productivity. This is particularly important in large-scale Frame Relay networks, because auditing and altering router configurations to obtain consistency between tens or hundreds of routers can be very tedious and time-consuming.

It is also useful for established sites to occasionally audit their router configurations to verify they are configured consistently, and that they are making best use of management and security features on the routers.

We'll look at configuring for manageability, but along the way, we'll also briefly discuss good configuration practice. The two go hand-in-hand in making your network easier to maintain.

Thanks to D. McCord of INS for some configuration tips he shared with the Cisco email list. I'd "invented" or run across a number of his ideas in other settings, but it was a very handy compilation of information. Some of these tips appear below, altered to suit my taste. Any changes or errors are my sole responsibility!

Design

It is a good idea to get the network design done thoroughly before beginning rollout of a new network. In the real world, this rarely happens. Some networks apparently "just happened."

Design here encompasses not just addressing and naming (see below), but scaling and routing protocol issues, architectural issues if you will. In large networks, designing hierarchy of both physical links and of addressing is necessary for best results.

Relevance to manageability: if your network was designed in hierarchical fashion, then understanding routes, failure modes, and access lists are probably a lot simpler than in a "randomly cross-connected" (a.k.a "furball") network. "Keep It Simple" has a big impact on manageability!

IP Addressing Scheme

Once design has resolved how many subnets are available, an IP addressing scheme needs to be laid out. Bear in mind that it won't be perfect. One very big company apparently re-addresses their IP network roughly every 3 years (due to corporate re-organization, mergers, etc.). They've done this enough times now that they assume it will keep on being necessary. It is important to do the best job you can with present information, delaying any need to re-address as long as possible.

Assigning addresses to summarize, as is required for OSPF networks of any scale, is a good idea. If OSPF is later needed, this will save re-addressing hosts. And if another protocol such as EIGRP is used, the summarizable addresses can still be put to good use.

Relevance to manageability: how easy is it to understand randomly assigned subnet numbers?

Naming Scheme

You should have a site convention producing meaningful host and router names. Meaningful does not mean router_10_1_1_1 (IP address built into name). It means that the name should convey useful information to humans, such as where the router is and what its function is. You should probably not build the model number into the name, because you may someday want to replace a router with a more powerful model having similar interface types and the same addresses (and then replacing the old name in various places can be a nuisance).

Configure the name into the router with the hostname command:

hostname chicago_wan

If you want to identify the box as a router, "chicagoWanRtr" or "chicago_wan_rtr" works. I personally tend to prefer all-lowercase in every host naming context, as I've been burned too many times by case-sensitivity in software that should have known better.

Note that SNMP management stations can retrieve the router hostname as the sysName variable, so the name should be meaningful. It's possible to write UNIX scripts to pull objects from HP OpenView or IBM NetView, get the sysName, build /etc/hosts entries, and then generate DNS files.

Relevance to manageability: consistent naming, /etc/hosts, and DNS entries, as well as router ip host tables, makes network navigation and troubleshooting a lot easier.

Interfaces

A certain amount of good hygiene is helpful: use the "shutdown" command unless an interface is intended to be up. It's particularly important to do this during a network rollout. That way, when things go sour and you do a "show interfaces" command and see "down ... down", you know that that's a problem and not just a link that hasn't been installed yet. If you don't follow this practice, you can lose valuable time tracking which down interfaces are supposed to be down and which aren't.

This is particularly crucial when dealing with MIP or CT1 cards with channel group subinterfaces, or with Frame Relay subinterfaces, due to the large number of virtual interfaces. It can take a long time to check which of 192 subinterfaces are supposed to be up!

It is also good practice to put a description line on every interface. For a LAN interface, indicate the physical location (building, floor, etc.) and the user community reached via the interface (which department or workgroup). For WAN links, it's a good idea to describe the sites or cities that the link connects, together with the circuit provider and circuit ID. It's tempting to include the phone contact and number, but if that changes you have a lot of reconfiguration of routers to do!

interface serial 0.10 point-to-point
description AT&T PVC, New York to Chicago, circuit id BC12-345678
ip address ...

Note that the description line shows up with the "show interfaces" command. In addition, it is available as the lifDescr variable in the Cisco MIB. The lifDescr shows up in CiscoView, in the interface information dialog box. If you don't have CiscoView, it might be useful to write an HP OpenView or IBM NetView "application" that polls a router for all interfaces: ifIndex, ifDescr, and lifDescr. This is very easy to do.

Don't forget to specify bandwidth for serial links (default is T1 speed, 1.544 Mbps). This is important for a couple of reasons: some routing protocol metrics depend on configured bandwidth (OSPF, IGRP, EIGRP, etc.), it shows up in "show interfaces" output, also showing in the link utilization, which is also available via SNMP. Correct routing behavior depends on properly configured bandwidth (if it is not T1 speed) for these protocols.

Specify bandwidth in Kbps, so that a 128 Kbps line is configured as:

interface serial 0
bandwidth 128

Another idea: if you're using Frame Relay subinterfaces, have the subinterface number match the local DLCI for the PVC. That simplifies "which DLCI goes with which subinterface?".

interface serial0
encapsulation frame-relay
no ip address
interface Serial0.941 point-to-point
frame-relay interface-dlci 941
ip address ...

The router is quite happy with this. In fact, I configured a router with "interface serial 0.1234567" today. (Do NOT try this at home, folks!)

Relevance to manageability: if router configurations are self-documenting, you don't have to scramble for the map or printout to find key information. "Shutdown" documents that an interface is intended to be down or is not in use.

And a War Story

It really is a good idea to put "shutdown" on unused interfaces.

One of our consultants visited a shop with an unused serial cable left connected at one end to a router. Overhead fluorescent lights or other electrical noise induced signal in that nice big antenna cable and apparently caused enough interface transitions to make the router CPU rather busy. And the SNMP traps also made the network management station busy! Configuring "shutdown" told the router to ignore all this, giving the CPU and the network managers some rest.

I've witnessed a WAN service provider failure where 192 DS0's off MIP cards were being rolled out to customers of a service. Some sites were connected, others were not. It wasn't at all clear from "show interface" whether random DS0's were down, or whether all the connected sites were up. It turned out that all the down interfaces were just not connected, but figuring that out took precious time. It then took additional time to find the real problem: an installer had messed up the network statements on the 7000 router, so there was no routing to LANs at customer sites. He'd pinged directly connected interfaces on the 2500 models at customer sites, which of course works even without routing.

To Be Continued

Don't touch that dial! More on 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 .