Cisco Router Management Configuration Template

by Peter J. Welcher

Mentor Technologies

Introduction

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

The following document describes router configuration commands that are useful for managing routers.

We also discuss good configuration practice, to the extent that is possible in such a brief document.

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. Quite a few of these tips appear below, somewhat altered to suit my taste.

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.

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.

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 of the big three automobile manufacturers re-addresses their very large 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. On the other hand, it's important to do the best job you can with present information, in the hope of 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.

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.

I have some Unix scripts that take object information from HP OpenView and IBM NetView and use the sysName variable to produce /etc/hosts entries. There is a Perl script called h2n that will convert this information to DNS.

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. It may 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).

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

interface serial 0
bandwidth 128

If you're using Frame Relay subinterfaces, one idea is to have the subinterface number match the local DLCI for the PVC. That cuts down on "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 ...

Route Caching

If a WAN interface is less than 256K, you may want to add "no ip route-cache" to make more buffers available.

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 for the protocol(s) with significant traffic only.

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

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 disabled: 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.

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.

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.

Host Table

A host table may be configured into the router with the "ip host" command. I recommend doing this even if DNS is available, because Murphy's Law says it won't be available in a network outage.

ip host new_york_router  a.b.c.d   e.f.g.h   i.j.k.l
ip host chicago_router   a.b.c.g   m.n.o.p

Put at least your major routers and servers into each router, and keep this list updated as you add new devices. It's well worth the effort the day your network goes down!

DNS

A router should be configured with the local domain name, even if DNS is not yet available:

ip domain-name foo.com

If one or more DNS servers are available, configure the router with their addresses:

ip name-server a.b.c.d
ip name-server a.b.c.g

If no DNS server is available, it is useful to turn off DNS name resolution with

no ip domain-lookup

This speeds response in case of router command typos.

CDP

The new Cisco Discovery Protocol is normally enabled. The information it collects ("show cdp neighbor details") is available via SNMP.

Leave CDP enabled, it may be very useful to future network management tools.

Passwords

Good passwords (hard to guess passwords) should be used where applicable. This includes SNMP read-write community string, enable password, console and AUX port password(s), and telnet vty passwords.

It is simpler to administer passwords, especially on access servers, using a central server mechanism, such as XTACACS or TACACS+, below. One-time passwords are valuable protection against password capture and re-use. Generally a mechanism such as the SecureID card is used for this, in conjuction with a form of TACACS.

The "service password-encryption" form of encryption is not secure, nor was it ever intended to be. I've heard there is a C program out on the Internet that breaks old-style encrypted passwords.

The new command to use is "enable secret", which overrides any configured enable password. Thus minimal but reasonable password protection consists of:

enable secret myEnableSecret
enable password anotherSecret
line console 0
login
password xxxx
line aux 0
login
password xxxx
line vty 0 4
login
password yyyy

XTACACS

We recommend you use XTACACS or TACACS+ for centralized control of access to routers and NAS's (access servers). TACACS+ is the newer of these. The CiscoSecure product provides a GUI and supported TACACS+ daemon, but for a while XTACACS may be required for use with SecureID cards.

Start by turning on extended TACACS mode:

tacacs-server extended

Then tell the router the address(es) of the TACACS servers:

tacacs-server host A.B.C.D
tacacs-server host E.F.G.H

Tell the router to use TACACS to authenticate enabled mode access, with the configured enable password as fallback if the TACACS server is inaccessible:

enable use-tacacs
tacacs-server authenticate enable
enable last-resort password

Similarly, if the TACACS server fails to respond, users may use a local password or the configured enable password to login to the router:

tacacs-server last-resort password

Options for authenticating users before they can use certain commands at the router EXEC prompt.

tacacs-server authenticate connection
tacacs-server authenticate enable
! if SLIP is to be authenticated:
tacacs-server authenticate slip
! if CHAP is not used with PPP:
ppp use-tacacs

Options for logging what users do:

tacacs-server notify connection
tacacs-server notify enable
! if SLIP or PPP are to be used:
tacacs-server notify slip
! if you care to log logouts (for connect time
! computation):
tacacs-server notify logout

And what EXEC connections do we want to use (X)TACACS to authenticate:

line console 0
login tacacs
line aux 0
no exec
line vty 0 4
login tacacs

If you don't want Telnet (as on a firewall router), put "no exec" on the vty's. If nothing is on the AUX port, "no exec" prevents people from connecting up and trying to log in.

TACACS+

For now, see my CiscoWorld article, which can be found on www.mentortech.com

PPP CHAP

Access servers should use CHAP or SecureID to control access to a network.

Telnet Access

It is a good idea to secure routers to only allow access from a list of acceptable network management stations. This makes it harder for a hacker to get into the routers. (It is also a minor nuisance in managing the routers, the usual security versus ease-of-use trade-off.)

Here's an example:

access-list 1 permit a.b.c.0  0.0.0.255
access-list 1 permit a.b.g.0  0.0.0.255
line vty 0 4
access-class 1 in
login
password xxx
exec-timeout 5 0

The exec-timeout command specifies 5 minutes of idleness before you are automatically logged off. The default is 10. You can specify no automatic logout with "exec-timeout 0 0". But then someone else may have enabled router access from a terminal you once logged onto. The cautious may wish to specify

exec-timeout 1 0

Privilege Levels

The simplest approach if you have "operators" you don't fully trust, is to realize that most show commands do not require enabled access to the router. If you want more control or granularity, look into the multiple privilege levels in the router. This can be used to make some commands unavailable to "users", if you so choose, or to add to the commands available to non-enabled users. Or you can create intermediate levels of privilege, where some access to enabled mode commands is given, but not full access.

Miscellaneous

The following line disables IP source-routing, which is usually regarded as a security hole.

no ip source-route

If you feel the urge (need?) to configure "boot system" commands, always establish a fallback boot image from ROM. That way if flash is empty or some problem occurs, the router may be able to boot an older image from ROM.

boot system flash slot0:
boot system rom

I generally prefer to NOT specify any boot system commands, and to set the configuration register to do the equivalent for me:

config-register 0x2102

If you wish to slightly reduce LAN traffic, and are not in a DEC environment, turn off MOP:

interface ethernet 0
no mop enabled

It is generally unnecessary to alter the default buffers and buffer pools (buffers min-free, buffers max-free, etc.) Cisco would like to know about it if you do have to alter them, because they're trying to make the right things happen automatically. If you do specify buffers commands, be aware that it can drastically affect the performance of your router.

Other Ideas

Access-list logging.

Putting It All Together

Here's what that looks like, collected into one configuration.

hostname chicago_wan
interface ethernet 0
description Boston, Building A, Floor 1: Eastern Region Accounting
ip address ...
no mop enabled
interface ethernet 1
shutdown
no mop enabled
interface serial 0
description WAN link: Boston to New York: AT&T circuit 56-1234
ip address ...
bandwidth 56
no ip route-cache
interface serial 1
shutdown
interface loopback 0
! PRIVATE ADDRESSING USED FOR ROUTER ID'S ON LOOPBACKS
description Loopback 10.1.1.1 provides router access and id
ip address 10.1.1.1
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
snmp-server community password1 RO 
snmp-server community password2 RO 60
snmp-server community password3 RW 60
snmp-server system-shutdown
snmp-server chassis-id YYYY
snmp-server packetsize 4000
snmp-server host a.b.c.d
snmp-server host a.b.c.g
snmp-server contact XXXX
snmp-server location YYYY
snmp-server trap-authentication
clock timezone EST -5
ntp update-calendar
ntp server m.n.o.p
ntp authenticate
ntp authentication-key 55 md5 mySecretKey
ntp trusted-key 55
clock summer-time EDT recurring
logging on
no logging console
logging buffered
logging A.B.C.D 
logging A.B.C.G
logging trap info
logging facility local7
service timestamps log datetime
service timestamps debug datetime
ip host new_york_router  a.b.c.d   e.f.g.h   i.j.k.l
ip host chicago_router   a.b.c.g   m.n.o.p
ip domain-name foo.com
ip name-server a.b.c.d
ip name-server a.b.c.g
enable secret myEnableSecret
enable password anotherSecret
access-list 1 permit a.b.c.0  0.0.0.255
access-list 1 permit a.b.g.0  0.0.0.255
line vty 0 4
access-class 1 in
exec-timeout 5 0
no ip source-route
tacacs-server extended
tacacs-server host A.B.C.D
tacacs-server host E.F.G.H
enable use-tacacs
tacacs-server authenticate enable
enable last-resort password
tacacs-server last-resort password
! tacacs-server authenticate connection
tacacs-server authenticate enable
! if SLIP is to be authenticated:
tacacs-server authenticate slip
! if CHAP is not used with PPP:
ppp use-tacacs
tacacs-server notify connection
tacacs-server notify enable
! if SLIP or PPP are to be used:
tacacs-server notify slip
! if you care to log logouts (for connect time
! computation):
tacacs-server notify logout
line console 0
login tacacs
line aux 0
no exec
line vty 0 4
login tacacs