Home > Cisco, Network > Cisco Router/Switch Standard Configuration Checklist

Cisco Router/Switch Standard Configuration Checklist

Every time I go to configure a new Cisco router/switch, I refer to my trusty text file of the “standard” items I need to setup in order to easily manage/troubleshoot the device in the future, as well as to properly secure it.  I have posted the annotated version of that checklist here in the hopes that others find it useful as well!

As always, if you have any suggestions for items to add to my list feel free to email me!  I am sure there are cool tips/tricks I am missing.

  1. I first have to figure out how to “get in” to the device.  Often if I am re-configuring an old device I must first follow the password-recovery process as the password may be lost.
  2. Once I am logged into the device I must determine how much RAM and flash memory the device has so that I can decide on the best IOS version to run.
  3. I go to cisco.com and figure out what IOS rev makes the most sense based on what features I need, how much RAM/flash I have to work with, what I am licensed for, and what level of reliability is required (i.e. can I only run “General Deployment” code, or am I willing to run a “technology” train because it has some new feature I need).
  4. If the device is a stackable switch make sure it is all stacked together the way you want it stacked with the correct device the command switch (check your priority settings).  Note that even a single switch by itself could think it was the 3rd switch in a stack (if previously a stack member) and mess up all your interface numbers which is painful to fix later!
  5. If configuring certain models of switch, you need to set the system MTU (which persists outside the configuration file) and reboot the switch for it to take effect.  The default is 1500, so unless you are planning on using jumbo frames (i.e. 9000 bytes hopefully), you don’t need to worry about this.
  6. I make sure I have IP connectivity to the device from my laptop so that I can download firmware to it.  Often times this means I will tftp the config from the device to my laptop to prove it works (and saving the old config may be valuable depending on the situation).
  7. Since I generally like to have as absolutely clean of a device as possible, I will often reformat the flash device so that I can be guaranteed to start from scratch.  Note that this can be dangerous if the device crashed/lost power before you got a new image on it.  You would then have to connect to the console and zmodem download the OS at 9600 baud (not fun!)
  8. Once the format is complete I tftp the new IOS version onto the device.
  9. I do a “write erase” to make sure there is no configuration left in the device (I want it to start from the new defaults as set by whatever version of IOS I am loading).
  10. I will often times check to see what the bootvar is set to, but really at this point it does not matter since there is only one image on the flash disk so it will choose that even if something else is specified.
  11. I issue the reload command and choose *not* to save the running config (since I just zeroed out the startup-config).
  12. When the device boots I say no to the setup prompts and I tell it to kill autoinstall if that is trying to run.
  13. I check all the startup messages to make sure all the hardware is recognized and initialized properly.
  14. At this point I jump into enable mode and do a “show run” to verify all the interfaces I expect are available and to see what new defaults or settings Cisco threw in on this build (they often have default settings show up in the config in order to call your attention to a new feature, or something that has changed).
  15. My first order of business is normally to get the device remotely accessible, as using the console is slow, and I am normally not in a very comfortable environment (i.e. cold, noisy datacenter with poor ergonomics).  To accomplish this I will often just enable telnet (if I am connecting across a secure network), and then later enable SSH.  To make telnet work you need an “enable secret” (well you could use an “enable password”, but that’s old and less secure so just don’t bother).  You will also need to set a password on the vty’s for telnet.  “line vty 0 15″ “password <blah>”.
  16. Before you can actually login to the device you must configure an IP on at least one interface, and un-shut it.  You may also need a default route (or some kind of static route) depending on if you are connecting from the local subnet or not.
  17. Once into the device, it is time for a ton of “housekeeping”.  First off, set the “hostname” and “ip domain name <domainname>”.  Note that both of these are required for generating RSA keys later so you can enable SSH.
  18. Setup your name servers with “ip name-server <server>” commands.
  19. Make sure your “boot system <x>” parameter (also known as bootvars) is set to nothing (if you only have one image on the flash device it will boot off that image).  I generally only use this command when upgrading to a new IOS version and I want to keep the old one around for fallback purposes.  I believe in keeping my config’s as simple as possible.  I only configure something if it provides value.
  20. Make sure “service password-encryption” is turned on.  This at least obfuscates some passwords that are normally stored in clear text.
  21. Depending on how you want log entries to look, I will often adjust the “service timestamps” command to have it log in localtime.  If you are just dealing with a small local network in one timezone it is often easier to troubleshoot when not having to think about GMT.  Users generally report issues in local time.  ;-)
  22. Set the timezone using “clock timezone PST -8″ (or whatever is appropriate for you).  You then must further tell it to do daylight savings time (if your locale observes it).  I use “clock summer-time PDT recurring” myself.  The thing that sucks about this command is that I suspect the dates it changes the time forward and back on change depending on how new your IOS is since the US keeps mucking with them.  You can also manually tell it when to make these time changes with this command.
  23. Setup at least one ntp server with the “ntp server <ip>” command so that your device always has the correct time.  Having the correct time is really important for correlating log file entries when troubleshooting.
  24. Turn off CDP on any interfaces that are hooked to “untrusted” networks (i.e. if they are connected to an ISP turn it off).  Issue the “no cdp enable” command on these interfaces.
  25. Setup logging as appropriate for your environment.  If you don’t have an external syslog server (or even if you do), you may want to use something like “logging buffered notifications” (or some other logging level) so that you can at least do a “show log” on the device and see the last “x” number of messages.
  26. I will generally setup my devices with a local username and password (which I can use for SSH, console, telnet, etc…) and then get rid of the enable password, enable secret, and line passwords.  To accomplish this I use the following commands: “username <username> privilege 15 password <password>”, “aaa new-model”, “aaa authentication login default local”, “aaa authorization exec default local”.  Make sure to test your access to the device before you drop out of enable mode or disconnect as you could lock yourself out!
  27. Now that you have configured a local user account, and earlier on you set a hostname and domain name, you can now generate RSA keys so that you can SSH to the device.  Issue the “crypto key generate rsa modulus 1024″ command to accomplish this.  Note that you can use various modulus values.  The default is 512 but I generally step it up a bit.
  28. Turn off “ip http-server” unless you use it.  Otherwise it is just a security issue (I think the previous step may actually not password protect the http server by default so be careful of this).
  29. On all your terminal lines (console, aux, and vty’s) use the “transport preferred none” command to keep the stupid router from trying to telnet every time you fumble finger a command!  I prefer this method of disabling this annoying functionality over the “no ip domain-lookup” route since doing dns queries from your router is sometimes convenient (and necessary!).
  30. You can also use the “logging synchronous” on the terminal lines in order to have the device re-print the command you are in the process of typing after it rudely spews a log message to your console.
  31. To make your router/switch only accessible via ssh (since telnet is insecure right?) issue the “transport input ssh” command on the vtys.
  32. For security purposes, set timeout’s on the terminal lines so that users get kicked out after inactivity.
  33. Setup a loopback IP address for device management.  This allows you to connect (and stay connected) to the device when interfaces go up and down.  You will likely want to make this the source IP for syslog messages and snmp traps as to not confuse your NMS (if you have one).
  34. If you are configuring a switch, setup your VLANs (name them etc…), also, make sure to set the root bridge priorities (you don’t want random switches becoming the root bridge).
  35. On switches, you may want to set global settings for portfast, bpduguard, and rootguard to apply to all ports.
  36. If setting up a switch, you should configure (or disable using transparent mode) VTP explicitly, otherwise someone could add another VTP switch to the network as a server and magically your switch will become part of that VTP domain.  This can impact your VLAN settings for all your switchports!
  37. Ok, now that we have all that drugery out of the way, go ahead and configure all your interfaces with IP addresses as appropriate.  Please make sure while you are at it to use the “description” command on each of them to describe what is attached.  If it is an ISP or WAN circuit make sure to provide the circuit ID for ease of troubleshooting.
  38. If your device is a layer three switch and you want it to do routing, make sure to set “ip routing”.  This command is frequently overlooked and is very frustrating to troubleshoot why the device won’t route packets!  For some reason (probably with good intentions to keep routing loops from happening or for security reasons) Cisco keeps this one turned off by default.
  39. Make sure all your speed and duplex settings are set properly for each port.
  40. If on a switch, make sure all ports are set explicitly to access mode if that is what you intend them to be used for.  By default a negotiation will take place and a port you did not configure can become a “trunk” port, providing access to VLAN’s  you were not intending to make available.
  41. Add in whatever default routes or routing protocols you need to run in order to have connectivity to the rest of the network.  Remove any un-needed temporary static routes you had put in place earlier.  Make sure to disable routing protocols on interfaces where they could pose a security risk.
  42. Setup an access list to control remote management access to your router based on IP address.
  43. Setup an snmp community on the device if you plan to use it.  I generally recommend everyone setup snmp read access so they can poll their devices with network graphing software.  Some environment use snmp traps for alerting.  You can also control access to snmp with an access list.  Make sure to set the snmp “location” and “contact” settings.
  44. Once the device is up and operational, make sure to check the interface statistics to ensure you are not getting errors.  The most common mis-configurations are with speed/duplex settings on Ethernet, and when talking about T-1′s the most common issue is getting the clock sources correct.
  45. Shutdown any un-needed interfaces.

See, wasn’t that an easy 45 step simple process?  ;-)

-Eric

Categories: Cisco, Network Tags:
  1. November 16th, 2009 at 22:46 | #1

    The points are very vali, it would be nice if you convert it into any script that will save lot of time.

    regards
    shivlu.blogspot.com

  2. April 29th, 2010 at 02:23 | #2

    Thanks for this useful checklist. I will be using it as a foundation for our new Cisco builds.

  1. April 29th, 2009 at 20:04 | #1