Compare config against master template

After more thought, I'm leaning more towards the idea that this could be accomplished with either a Baseline Config Comparison (mentioned early), or via a home-made Compliance Report.

If everything except Location, Device Name, and IP address/mask/gateway are the same for all your devices, why not build a Compliance Report that compares all your devices, and that looks for the items that should be identical, and that alerts you when they're not identical?

Compliance Reports are easy to build and run.  Plus it has the benefit of being customizable for whatever things change (or should NOT change) in your environment.

If you're not familiar with building one, I can help you out with tips & tricks & screen shots.  Drop me a Message if you need assistance.

Swift Packets!

Rick Schroeder

I would also like to bump this thread.  Here are the key issues..

If the If-Then-Else statements don't get implemented, a "master template" with escaped fields would be ideal for large scale configs.  The RegEx are good, but the need to check multiple fields that may be different due to geographically separated locations is real.

This boils down to verifying things like QoS, line console/vty configurations, and aaa configurations.  Those should not change 90% of the time, so having a larger scale "check text" block that allows for escaped fields with variable rather than regex would be great.  An example could be tacacs-server host $IP or $x.x.x.x, something that auto-fills that RegEx information or flags that the next expected "word" will be an IP address.

Here's to hoping 2018 is the year for Configuration Template checking!

Bump

I agree with the above posters. I don't know why this doesn't exist already. Yes, you can basically do this with regular expressions, but it would take a LOT more work and a lot of rules to check against. It would be amazing to have a feature like this to get a bunch of settings (base configuration) cracked out in one fell swoop.

This is definitely a need. An alternative (in part) would be reverse compliance policy in a manner. If I tell NCM that the following strings and/or RegEx should be present in that config block, it would be useful to provide a check box that says "If there is anything else present in this config block, flag it." This would meet partial baselining requirements and cover a portion of what bene described in his comment above. I am havvng the same issue right now trying to figure out how to cross compliance reporting with baselining. Clearly baseline by node is a terrible idea when groups are already built in and supported in compliance node selection. Don't even get me started on the segregation between NPM and NCM groups...