Configuring for Manageability, Part II

Last article we discussed route caching, the loopback interface, SNMP configuration, time and NTP, and using syslog to capture router console messages.

This month: converting names to addresses: host table and DNS. Then a couple of words about CDP and passwords. Central control of passwords across multiple routers or NAS’s brings us to XTACACS, with a brief nod to TACACS+. We’ll finish with some random related ideas on things you might want to configure into your Cisco routers.

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. (CDP was the subject of a previous CiscoWorld article).

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


I 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 one-time password 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 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.


Access servers should use CHAP or one-time passwords (SecureID, DES Gold) 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

You might want to turn on access-list logging (to your syslog server).