CCIE or Null!

Configuration management, without a doubt this is probably one of those things we all do, but to what end do we perform configuration management though? Usually configuration begins and sometimes ends with backing up and storing those configuration files but how much further can or should we go with configuration?

• Backing and storing configuration files – As mentioned before, this is step one. Keeping a copy of your device configuration is one the easiest and quickest ways to restore a device back into service after a physical failure.

That one task, as simple as it sounds it the heart of good configuration management. From that original point we gain the ability to perform many other tasks:

• Configuration comparison – Having the ability to compare two of your previously saved configuration can prove to be an invaluable resource. Let’s say you have dozens or hundreds of remote “cookie-cutter” devices out there and you have a single device acting up, comparing the configuration to a known good configuration can save you much troubleshooting time. Especially when you consider many configuration managers are convenient enough to highlight discrepancies making possible errors stand out like a sore thumb.
• Configuration / Version archival – This point follows suit with comparing configurations, because in most cases you may want to compare configurations from the same device that are from different points in time. Making it easy, to pin-point any recent configurations that could be causing the issue at hand.
• Reacting to configuration changes – Changes are a way a life, if nothing is changing then something is wrong, the tougher part is dealing with a way to manage those changes:
  • How do you know when a change occurs? – Many configuration managers will re-act to a device generated syslog or SNMP trap, do you have this configured, are you made aware of changes?
  • What do you do when a change occurs? – When this mysterious change occurs how do you re-act, do you acknowledge some type of alert or review some daily/weekly report, perhaps there are some checks and balances to ensure the altered configuration has been backed up after the change or to verify that the change was committed to memory?
  • Can you correlate network events with changes? – Do you have any capability of correlating network faults with configuration changes? There are definitely a few of those ‘eye in the sky’ type NMS platforms that are capable of linking device level events to any correlating configuration events on that device. Now, if only we can get a more abstract ability to monitor device groups holistically linking events. In my opinion event correlation exist to some degree with many NMS products, but there is definitely a lot of room for improvement.
  • Do you enforce a baseline or set configuration standard? – This one in my mind, is where many tools have lack-luster performance, when you find yourself in a situation with many nodes, you definitely want some ‘checks and balances’ out there. How upsetting is it when you find out that the issue you have been troubleshooting is all because a recent firewall change or routing policy change never got deployed to a particular device? If you can enforce some type of configuration ‘compliance’ or ‘baseline’ I guarantee you, that you solve many headaches before they occur.
• Software Management – While, this might seem outside of the scope of configuration management keeping your software versions in sync can be quite important and detrimental for keeping configurations in Sync
  • Software versions – Different software versions may implement different command syntax, this in itself can make configuration & troubleshooting tedious in itself. Different versions may also suffer from different software bugs/caveats into your environment.
  • Software licenses – Depending on the vendor and the device, if the incorrect license is applied or the incorrect software train is installed on the device some features may not even be configurable. Nothing is more upsetting then when you are trying to configure a device and you find out a simple license (non-technical) issue is the root cause.

So, there we have some groundwork for configuration management do you have other considerations in regards to configuration management?