Robert - all great suggestions. Big cross-vendor configuration generation and deployment is outside the scope of what I was hoping for here. The goal is to have the version information somehow encoded into the configuration, and I'm not sure that NETCONF has anything to say about that matter. Certainly the same problem of which-versions-are-where exists in the puppet/chef world and there are platform specific ways to answer those questions. Deep analysis of the router configuration itself can give pretty strong hints about which version are deployed, but lets assume full config digestion and comparison is out of the question. From some off-list responses I am hearing that some folks do similar kludges with other text fields, wether they be remark/banner/snmp-foo/interface descriptions. On Wed, Feb 26, 2014 at 5:59 PM, Robert Drake <rdrake@direcpath.com> wrote:
On 2/26/2014 5:37 PM, Robert Drake wrote:
Most people roll their own solution. If you're looking to do that consider using augeas for parsing the configuration files. It can be really useful for documenting changes, and probably to diff parts of the config. You might also consider rabbitmq or another message queue to handle scheduling and deploying the changes. It can retry failed updates. You should work towards all or nothing commits (not all cisco gear supports this, but you can fake it in a couple of ways. Ultimately you want to rollback to a known good configuration if things go wrong)
I should amend that even though I recommend all this I haven't used any of it for networking. I guess those are more shiny ball ideas than actual things I've used. We have perl scripts that wrap an in-house API to access our IPAM which generates initial configuration. The template files are a mix of m4 and Template::Toolkit.
We use basically one-off perl scripts for auditing sections of the configs to find discrepancies. We use rancid to collect configs. We just started using netdot which is nice for topology discovery. TACACS and DHCP logs are parsed and stored in logstash. All of those tools provide the who, what, where and when but not the why. The why would require a bit more custom stuff and forcing people to use a frontend interface instead of directly touching the routers. We aren't ready for that yet.