It is your first day as a network administrator. Your boss walks up to your desk and for your first task you must implement standard configurations across all your switches and routers. Let’s not yet worry about how you will deploy these configurations across the enterprise, but let’s talk a bit about the content.
Standards are important in networks. Having a uniform config is a great goal to have. Different site configurations will vary, but there are certain configuration pieces you can keep the same. Whether you deploy Cisco, Juniper or another solution, there are best practices you can implement.
I always recommend looking at the best practices section for your solution and implement what you can. Below are just a few configs I’ve found useful, picked up through studies or are recommended best practices. These network device configurations are specific to Cisco, but others have similarities.
In the world of Spanning Tree Protocol, loop prevention is of utmost important. When Spanning Tree Protocol is used in the topology, information is exchanged between switches in the form of Bridge Protocol Data Units (BPDU). You should not receive BPDUs from user-facing ports. I usually configure all user-facing with bpduguard.
interface GigabitEthernet 1/0/1 description User-A spanning-tree bpduguard enable
I recall early in my IT career a day that this and a few other commands would have helped. Off-brand switches and hubs were not allowed at the university where I worked, but they were often used for offline PC imaging. One of the techs found a stray cable laying around and thinking that this belonged to the rogue device, plugged it back in. This “offline” device was uplinked to one of the switches in the nearby closet. Also, we did not have bpduguard enabled, storm-control or anything else that would have helped. As the tech left for the day, the network slowed down to a crawl. It was all because of that one cable plugged back into the same switch. It took some detective work and a lot of time for the engineers to track the issue down. A few commands would have prevented it all.
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 and always will be 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 packets should come from. I added the interface trust command to the physical ports the actual DHCP server was on 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 do not 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.
You might be part of a smaller operation without the ability to track who does what with a TACACS or 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 config will allow you to use the show archive log config all command:
52 1 SrEngineer@vty0 | interface GigabitEthernet8/28 53 1 SrEngineer@vty0 | shutdown
Here is a simple command I toss on the console and lines when I am configuring a device.
line con 0 logging synchronousline 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. This will help when you must console in and configure devices.
These simple global commands do not do much, but they do help in keeping connections to a device (telnet/SSH) cleaned up during disconnects.
service tcp-keepalives-inservice 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 device does not know the remote connection was disrupted. Adding in these service commands will clear the connections for you.
As I mentioned in the beginning, looking at your best practices is key. This will allow you to create a set of configs you can deploy globally. Look at your infrastructure and come up with those standards. Your organization will thank you and if they do not, your future-self will.