Network Devices: Easy Config Tips

If you work in networking, you probably take care of the switches and routers in your environment or have some input on what happens with them. Switches are the doorway to the network. Even if you have a wireless device, the access point you connect to is probably connected to a switch. This is where your PCs, TVs, appliances and many other wired devices connect. Routers can manage connections in and out of your environment along with a plethora of other services. Everyone should have a template or standard config they use on any network device. With today’s tools and services like Prime Infrastructure or DNA Center, you can spread that configuration around or deploy it to new sites; however, you still need a config to apply. Different scenarios and environments call for different configuration, but there are always those sets of commands you can use everywhere. The goal of this writing is to share a few commands that are helpful and I typically apply. Most of these are commands you spot all over certification studies and others I’ve seen other engineers use.
Yes, you probably memorized every single command from the CCNA and even the CCNP…but did you apply them all on every single port? Sometimes, unless there is a need you might not have to. I call it, situational configuration. Apply what you need and what will keep the environment secure. The important piece is to be consistent. On switches, VLANs might be different for each interface, but why would some of your switches have “enable password” and others have “enable secret”?

DHCP Snooping – Here is a useful set of commands that can get you out of a jam with a rogue DHCP server.

ip dhcp snooping vlan <#s>
no ip dhcp snooping information option
ip dhcp snooping

interface <type/#>
   ip dhcp snooping trust

I remember when I received a call from a site about the internet not working. Well, that is definitely a vague statement. “What IP address do you have?” I asked. Usually this question can point you in the right direction. The IP I was then given was nothing like the IP they should have pulled from the DHCP server. That was the big clue something fishy was going on. I added the above command for the VLAN the users were on. The purpose of DHCP snooping is to trust specific ports where you know DHCP should come from. I added the interface trust command to the physical ports the actual DHCP server was in as well as the uplinks between the switches. The no ip dhcp snooping information option command is always a confusing one. Do I need it on or not? The option in question is DHCP option 82. This option gives the server additional info to where the device needing the IP resides in the network. In my experience I usually don’t need to do this with the Windows servers we use for DHCP. I do not need the option added in, so I run the above command. As soon as this occurs, only the true DHCP server can communicate with clients. The rogue server will not be able to communicate with clients. You can then use the switch logs to track down which port the rogue server connected to. At that point there will probably be a nice conversation with someone.

Archiving – You might be part of a smaller operation without the ability to track who does what with a Radius solution. That is the best option, but if you do not have it, you can still keep track of who ran what commands on the device:

archive
   log config
   log enable
   hidekeys

This is the quick and dirty way of finding out Senior Engineer So and So was the one that took down that uplink by mistake. Hey, it happens. We all do it. However, for accountability purposes, we need to know who did what and what commands were typed. The above command will allow you to use the show archive log config all command:

52 1 SrEngineer@vty0 | interface GigabitEthernet8/28
53 1 SrEngineer@vty0 | shutdown

Logging – Here is a simple command I toss on the console and lines when I am configuring a device.

line con 0
   logging synchronous
line vty 0 15
   logging synchronous

Have you ever started configuring a device and as you type commands the console output continues to interrupt what you are currently typing? Yes, it is annoying, distracting and just makes the output look messy as you type the next command. Adding logging synchronous to your lines will keep the commands you are currently typing on a separate line from the output coming out.

Service-tcp–keepalives – These simple global commands don’t do much, but they do help in keeping connections to a device (telnet/SSH) cleaned up during disconnects.

service tcp-keepalives-in
service tcp-keepalives-out

TCP connections to a device (usually a management connection to the device) that age out or are disrupted can stay “active” on the device. This happens because the particular device does not know the remote connection was disrupted. Adding in these service commands will clear the connections for you.

There are tons of other commands out there that can help in different scenarios or are a must use in your standard deployment. As always, take a look at release notes for the device and software version being used.