I’m building configuration policy checks for a customer and realized that it would be beneficial to share the design choices and implementation details that I encountered. The tool that I used is NetMRI’s Configuration Policy, but the same thing would work for other tools that have similar configuration policy mechanisms.
This customer recently implemented a new Cisco ACS server and new AAA configurations needed to be installed in all the network devices. We were able to use NetMRI to determine if there were any devices that did not have the new configurations installed by checking for the contents of a new banner that was applied at the same time. That was pretty easy, but it didn’t validate that the configurations were actually correct. The update process was manual and even though they used cut-and-paste, there was still a chance of error. So we built a configuration policy to verify that the correct configuration existed.
There are several significant benefits from performing configuration policy checking.
- It assures configuration consistency across the network. Consistent configurations allow you to more easily perform updates because you know what exists in the current configurations.
- With the same configurations, there are fewer problems due to inconsistency. A difference in a QoS policy, for example, might cause important traffic to be improperly classified and marked, resulting in undesirable prioritization of certain traffic. The affected traffic may not be the improperly classified traffic – a large volume of improperly classified traffic could impact the flow of more important traffic.
- Consistent policies increase network security. The policy in this case, the AAA configuration, has security implications. The stated policy is that all changes are to be tracked in the ACS server so that there is an audit log of network changes and who made them. It is critical that all network devices receive an authorization confirmation from ACS before allowing a network administrator to change a configuration and to log the specifics of the change.
When configuring network policies, I find that it makes sense to start with a policy written in sentences. This establishes intent, which is not communicated in the policies themselves. For example, the AAA policy says:
All configuration commands must be authorized and logged in the ACS server so that an audit trail of configuration changes is created.
This policy results in a specific set of AAA commands that we verify are contained within all the network devices. Automating the configuration command check makes sure that any exceptions are noted when they occur. Any future change that isn’t consistent with the policy is identified and an alert regarding the exception is created.
Consistent configuration policies can also reduce troubleshooting time. Let’s look at a policy for edge ports.
Configure edge ports with portfast, auto/auto for speed/duplex setting, bpdu-guard, and error-disable timeout set to 90 seconds.
If non-edge ports are identified with tags (see my post on Device and Interface Tagging), then any port that’s not tagged is an edge port and should be configured as such. I recently found a pair of edge interfaces on a switch where someone had “cleaned up” the cabling in a room by plugging the dangling end of a cable into another wall jack. This created a loop, but fortunately, one of the ports went into the blocking state instead of creating a spanning tree loop. A better configuration would have been for the ports to go into the err-disable state with a timer specified to re-enable the ports when the cabling error is corrected. In the above case, a field technician had to be dispatched to solve the cabling problem when it would have been better to have the switch disable the ports and just ignore the cabling error. The customers in the area would have eventually corrected the problem when connectivity was eventually needed. Duplex mismatches and native vlan mismatches also come to mind as examples where a consistent configuration avoids problems that require troubleshooting.
In the next post, I’ll talk about building configuration policy rules from the written policies.
-Terry
_____________________________________________________________________________________________
Re-posted with Permission
NetCraftsmen would like to acknowledge Infoblox for their permission to re-post this article which originally appeared in the Applied Infrastructure blog under http://www.infoblox.com/en/communities/blogs.html
