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 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.
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.
Configure the name into the router with the hostname command:
hostname chicago_wanIf 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.
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 128If 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 ...
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.
interface loopback0 ip address a.b.c.d 255.255.255.252This has several uses:
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.255It 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 60The 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-shutdownThis 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 4000Most 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.gThis 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 YYYYFinally, 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-authenticationand 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_e0That 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!
clock timezone EST -5 clock calendar-valid ntp masterThis 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.rThe "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 55Configuring the router to recognize daylight savings time may also be appropriate. In the U.S., use:
clock summer-time EDT recurringThis follows the usual U.S. rules (60 minute change, first Sunday in April through last Sunday in October).
To render logging safe:
logging on logging bufferedEnsure 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.GDo 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 datetimeYou can also provide timestamps for debug output, with:
service timestamps debug datetimeTo set the level of logging information:
logging trap infoThis 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 local7This 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.
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.pPut 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!
ip domain-name foo.comIf 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.gIf no DNS server is available, it is useful to turn off DNS name resolution with
no ip domain-lookupThis speeds response in case of router command typos.
Leave CDP enabled, it may be very useful to future network management tools.
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
Start by turning on extended TACACS mode:
tacacs-server extendedThen tell the router the address(es) of the TACACS servers:
tacacs-server host A.B.C.D tacacs-server host E.F.G.HTell 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 passwordSimilarly, 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 passwordOptions 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-tacacsOptions 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 logoutAnd 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 tacacsIf 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.
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 0The 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
no ip source-routeIf 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 romI generally prefer to NOT specify any boot system commands, and to set the configuration register to do the equivalent for me:
config-register 0x2102If you wish to slightly reduce LAN traffic, and are not in a DEC environment, turn off MOP:
interface ethernet 0 no mop enabledIt 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.
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