Our network devices contain detailed configuration files, and the management of these configurations can sometimes be overwhelming. In this video, you’ll learn about change management, device configuration backups, and creating configuration file baselines.
<< Previous: Interface MonitoringNext: On-Boarding and Off-Boarding Mobile Devices >>
In our enterprise networks, they’re always changes that need to be made. We need to upgrade software, change a firewall rule, change the settings in a switch port. Something is going to need some type of modification. But you can’t simply log into a device and make that change in the middle of the day. There needs to be some type of process in place to manage those changes.
That’s why there’s change management. You can plan for the change, make the actual change, test it afterwards, and if there is a problem, revert back to the original configuration. This is something that’s very common in the enterprise. There are probably weekly change management meetings in your organization. It’s something that is occurring all the time.
Unfortunately, companies will sometimes ignore the change management process, or they won’t have any process at all. People can log into devices, make changes on routers, and switches, and servers all in the middle of the day without anyone else knowing that it’s occurring. And undoubtedly, this is going to cause problems when incompatibilities arise between these different systems.
You’ll find that the change management process is going to be well-documented. People are going to know exactly how often this occurs, how long you have to make these changes during the maintenance window, the actual process that will occur for the installation of the change, and any procedures so that you can fall back if something does not work the way you expected.
If your organization does not currently have a change control process in place, you may find it very difficult to implement one. It’s so easy to log into a router or a switch and make a configuration change without any concern of how it may affect anything else, and of course, with no testing. And to change that entire process from something that is so casual to something that’s very formal will take a lot of work and a lot of effort.
The switches, and the routers, and the firewalls, and all of the other devices in your network have configuration files on them. You’ve made specific configuration settings, and they’re stored somewhere on those infrastructure devices. Normally, you would make backups of these configuration files. Some people do backups once a week, some once a day. Some organizations will back up their configuration files once every hour, so they have an hourly snapshot of everything that’s changed in that particular device.
Unfortunately, all of these myriad devices have completely different file systems and different processes in place to transfer the configuration files off of the device. So you want to use whatever method you can to retrieve those files and store them somewhere safely. These configuration backups will come in handy for things like change control. You’ll be able to document exactly what changes were made inside of a configuration. And you’ll have timestamps that show exactly when those occurred.
If the device, for some reason, was to fail– perhaps the file system on that device suddenly became corrupted– you would at least have a backup configuration, so that when that problem was resolved, you can simply copy your old config right back into the device. And you’re up and running again. If you’re running some enterprise management software that’s specific to those routers or those switches or those firewalls, that software may already have a backup function inside of it. And you just have to configure your management software to back those up regularly and save them somewhere safe.
In your environment, you may be tasked with deploying a switch. In fact, you may be tasked with deploying many, many switches. And in these scenarios, you might want to create a configuration file that is a framework or a baseline that you can then add to later. There will certainly be parts of the configuration that are identical between all of these different switches. And you can build a baseline configuration that takes into account all these commonalities.
For example, a switch configuration baseline may decide on a very specific version of software that will be loaded on the switch. There may be a standard that you use to name the ports that are inside the switch, so that no matter which switch you’re logging into, they’re all following the exact same naming convention. Or you might decide that certain ports on the switch may be associated with certain VLANs. For example, you may decide that port 1 is always going to be connected to your management VLAN. That way you can look at a switch and know instantly what interfaces are assigned to other VLANs and which interfaces are specifically assigned for management.
Because this is a baseline that everyone is going to use, you don’t want to make any changes to this unless everybody has sat down, gone through what the changes are, and agreed that this will be a change to the baseline. This makes it easy once you start building out your configuration, because you’ll be able to very easily delineate what was the baseline configuration and what things you added that were specific to this particular switch.