Cisco Router Management Configuration Template


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.


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

The 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 the 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 the 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:

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.


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 a 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!

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:

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

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:

If you have an 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.

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.

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 router 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 the 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 the 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 a hierarchical fashion from the master clock. That is, some routers should use the master clock as the server, more routers use those routers as time servers, and so on. This is configured with:

The “ntp update-calendar” configuration command tells the 7000 routers 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 process 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 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.

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 debugging 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 the 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 debugged 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.

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.

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!


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

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

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

This speeds response in case of router command typos.


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.


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 conjunction 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:


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:

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

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

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

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

Options for logging what users do:

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

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.


For now, see my CiscoWorld article, which can be found on


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:

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

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.


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

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.

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

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

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.