Best Practices, Tips, and Tricks to Switch Configuration

I’m working on a new network design for a remote location and thought I would share some of my best practices, tips and tricks.

In this article I will assume the general design has been sorted out and will go to the configuration phase.

In some large companies, this step can be very simple. You get an IP address and password configured.  After the switch is installed and powered on, the network staff can remote in and ‘push’ the final configuration to the switch. In this case, I do not have that option.

My checklist of items to configure will be based on the client design documentation. Here’s a quick list of items to cover: DHCP, routing, VLANs, Spanning Tree, passwords, backups/upgrades, access lists, interface descriptions, time servers, authentication details, telnet/SSH, web interface, sys logging, and SNMP. Let’s look at these items in more detail.

DHCP

switch-config-DHCP.jpg

(Cisco configuration example)

If your switch supports it, I always enable DHCP for the installation since the network connection to the production DHCP server may not be available. In some cases, I create a vendor VLAN, with DHCP that only allows access to specific networks or devices. That way the vendor isn’t always asking for a static IP when on site or guessing and causing a duplicate IP address situation. I’m sure we’ve all seen people invert the default and host IP address.

Routing

If the switch has routing capabilities, it is important to configure the proper default gateway or which specific routing protocols need to be supported. Pay attention to those scenarios where you may have two or more default routes since every vendor treats this differently. Some round robin between destination IP address, or treat it as a fail over, or load balance based on all sorts of options. In this case, the client specified a static route to a single destination, easy.

VLANS

switch-config-VLANs.jpg

(Cisco configuration example)

Typically you will have two VLANS: admin and clients. Or in some cases three VLANS: admin, clients, and VOIP. It is very important to figure out as much of this in advance for your IP subnetting design. In most cases, contiguous IP subnets are preferred. Don’t forget to put descriptions on your VLAN interfaces, if your device supports it. Deciding on your VLAN tagging configuration also falls into this category.

Spanning tree

Spanning tree, rapid spanning tree, or the many other names that cover this same protocol is always significant. This also include specific items such as BODU blocking and manually configuring Priority values. In some specific cases, I disabled spanning tree but refer to your design document.

Passwords

Figure out your password naming convention, how often it will change, and if you must include any authentication servers like Radius TACAS+. You should check your equipment manual to see if your device supports some advanced features like incorrect login lockouts/accounting/alerts.

Backups/updates

I always keep the base configuration on the device and a USB key while installing in case I need to revert back to the original configuration. You need to consider how often you will back up device configurations. There are many options, from manually backing up configurations, to scripts and finally applications that will back up whenever changes are made.  I have written quite a few scripts for clients that did not have a solution in place to perform a weekly backup. Don’t forget about backing up your firmware, IOS, and equipment software.  It is quite common to discover the device needs updates even though you just received it.

Access lists or filters

 This covers device to protocol access. Device access is how you connect to the device with physical ports like Ethernet, Serial, USB, and others. I am not a fan of leaving physical ports without passwords unless the client specifically requests it. If you device has various ‘levels of access’ avoid using the same password. If you are going to create multiple user accounts, try to do it by job function or department like WAN, WiFI, Voice, and others.

Then there is other forms of access like HTTP/HTTPS, Telnet/SSH, API’s, and vendor specific applications/protocols. Protocol access involves allowing access to specific protocols, IP addresses, or IP subnets.  Depending on your product, this might cover such items such as telnet, SNMP, RMON, Netflow, HTTP/HTTPS, and others. During the installation I believe it is critical to monitor new equipment and ensure all is well. In some cases we might enable SNMP for a while until the equipment is added to the corporate monitoring system.

Interface descriptions

switch-config-descriptors.jpg

(Cisco configuration example)

I can’t stress enough how important descriptions are for ALL devices when possible. Device such as switches, routers, and firewalls may be in secured locations or offsite so knowing what is connected to speeds up troubleshooting. Do not solely rely on vendor discovery protocols since they may not be compatible with all equipment and you never know what devices will send them out. In specific scenarios, I actually disable discovery protocols from untrusted or public ports or networks since a lot of important information is being sent out all ports in clear text.

Sys logging, time servers and SNMP

This also covers other monitoring protocols Netflow, RMON, and more. The point here is to decide what the addresses and credentials are of these devices in your environment and ensure the relevant protocols work before walking away.

All these points should be confirmed and reviewed during support and configuration changes.