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.
source: http://www.networkcomputing.com/
