This article by Jennifer Minella originally appeared in Network Computing.
There are five configurations a network administrator should apply to a newly provisioned switch or router. Although application of these configurations may seem like common sense, 90% of devices I see are missing at least one of these settings, and about 75% are missing two or more. Use this checklist as an action item to verify your existing devices have these settings, at minimum, and integrate these in to any templates or provisioning documents you use. You’ll appreciate the results of the consistency this adds to your network management and monitoring.
Define a default gateway or default route
Let’s start with the fantastically easy one–a management IP and default gateway. Obviously, you can’t manage a device across the network unless it has, at bare minimum, a management IP address. Instead of harping on the obvious, instead take note that many times when edge devices are provisioned, an IP address is configured but the default gateway or default route is forgotten or omitted.
What happens when this configuration is missing? Those edge switches will hum along happily until one of three things happens: Your management tool is installed or moved to a different subnet. You try to manage the switch from a different network or subnet. You begin adding other VLANs or subnets to the switch.
Without a default gateway or route off of the network the switch is using, traffic may reach the switch, but it won’t find its way back off that network. You won’t believe how many edge devices are in the wild with this grievous omission, often resulting in the switch becoming unmanaged, by virtue of the management tools not able to see it.
Cisco & HP Networking: # ip default-gateway # ip route 0.0.0.0 0.0.0.0
Set the time
If I could ask administrators to set only one configuration out of the box after the basic IP settings, I’d ask for this: the correct time. Correct time on a switch is vital when troubleshooting the device. A string of log entries dated 1/1/90 are useless to network administrators troubleshooting a problem.
The three most popular ways to set time on a device are manual time settings, TimeP or Network Time Protocol (NTP), and Simple NTP (SNTP). You should really have a time server in your environment to keep the network all in sync. If you don’t have a time server now, you can very easily add one. In Windows Server environments, a few clicks will have you up and running with SNTP in less than 5 minutes. You can also use public (Internet-hosted) time servers, although you shouldn’t put yourself in a position to force each switch to call out over the Internet for time. As a last resort, set the time manually, but, by all means, set it somehow.
Cisco: # ntp server # clock timezone # show clock
HP Networking: # ip timep manual # timesync timep # clock timezone Or # sntp server # sntp unicast # timsync sntp # show time
Enable neighbor discovery
Neighbor discovery protocols are essential for network administrators and management tools to accurately construct a view of the network topology. Each manufacturer has its own supported mix of neighbor discovery protocols, loosely based on how standards-focused that vendor is and how much it wants to pay in royalties to use proprietary protocols. The two most widely used are LLDP (Link Layer Discovery Protocol), an IEEE standard, and CDP (Cisco Discovery Protocol). Support varies by brand and at times even by model or firmware versions. What you may see in some devices is LLDP supported for listening and talking, but only the only CDP support is for listening. Others may offer equal capabilities for both protocols.
Enabling all supported neighbor discovery methods is highly recommended. The information it provides lets you immediately locate neighboring switches and even media endpoints such as phones and access points that use LLDP-MED, an extension of LLDP. Not only can you see where these devices are connected, you can get details of the device type, its host name, IP address and even what port it’s connected to on the other end. In a similar fashion, your network monitoring and management tools will use these protocols to crawl the network, discover new devices, and correctly identify and show interswitch links.
Cisco: CDP is enabled by default, Enable LLDP # lldp run # show lldp neighbors <+ optional details>
HP Networking: LLDP is enabled by default. Enable CDP receive only support # show lldp info remote <+ optional details> # show cdp neighbors <+ optional details>
Configure logging and traps
Notifications of events on the network are a critical component of monitoring, troubleshooting and real-time alerting. Most switches offer two primary means of sending this data to a central repository: logging events via syslog and trap events via SNMP ((Simple Network Management Protocol). Configuration of both is simple, usually varying minimally from switch to switch and even from brand to brand.
Most organizations have a syslog server or a management tool configured to receive SNMP traps. If yours doesn’t have such an application, I’d strongly encourage you to use this opportunity to investigate your options. If you don’t have budget or time, look at your existing management tools and you’ll likely find something you can use already in production. If not, there are a variety of free syslog and SNMP tools; just make sure you download free tools from a source you trust.
Cisco & HP Networking: # logging # snmp-server host
Add custom SNMP communities
SNMP is used to manage or monitor all types of devices in a network, including switches, servers and even desktops. SNMP allows us to define different community strings that are mapped to different access rights. Most simply, we have a read-only string and a read-write string. The read-only string lets monitoring tools see and gather information from the device, whereas the read-write string allows management tools to make modifications and configuration changes to the device. By default, switches most often have either no predefined strings or they use a combination of public and private.
Some of you may feel this should be included with the full management configuration (defining local users or RADIUS/TACACS authentication, enabling secure management with SSH and HTTPS), but I define it as one of the recommended out-of-the-box settings. Within an organization, you likely have only a set or two of custom SNMP community strings, and these strings aren’t going to change from the time you order the switch, unbox it and then deploy it. Initial omission of the strings is usually an oversight, or network admins consciously leave it out and figure they’ll go back and add it later. Your management tools should already be set to talk to your devices using your custom SNMP strings, so go ahead and start off on the right foot by setting it early on the device. Remember, they are case-sensitive, and you’ll avoid the frustration of typos if you include these in a template or at least copy-paste from a base text document. Incorrect SNMP strings are frustrating, especially in larger environments. Correct strings will let your device be seen and managed immediately by all your management and monitoring applications.
Cisco: # snmp-server community ro # snmp-server community rw # show snmp
HP Networking: # snmp-server community operator restricted # snmp-server community manager unrestricted # show snmp-server
There are many other configurations recommended in a production environment, including secure encrypted management and file transfers, as well as SNMPv3 in certain networks. These five settings are a quick start to ensuring consistent management of your infrastructure devices across the enterprise.
# # #
