A lot of template management discussion focusses on using the network configs as the canonical model of the network. Storing the network model in the DB (whatever form that takes) is much more sane. There is the brownfields issue of populating that database and then building device state from there, but once that's done a lot of the problems go away. A solution like rancid/tail-f then simply becomes the mechanics to push your device state to the devices. Some good stuff here: https://www.nanog.org/meetings/nanog44/presentations/Monday/Gill_programatic... --Simon On 27 February 2014 09:46, Erik Muller <erikm@buh.org> wrote:
On 2/27/14, 12:21 , Suresh Ramasubramanian wrote:
This has been around for several years now - http://sourceforge.net/projects/cisco-conf-rep/
But that's just archiving, like rancid, right? Still doesn't have any correlation to the template-management side of things. While having the backups makes it easy to check for simple things ("do all my routers have the right syslog host set?"), OP's question is about tracking what versions of templates may have been applied to routers; if there's any complex logic (like, "are all active customer routes on this device included in the bcp38 acl on the upstream interface") or site-specific things, that can get a lot harder to audit without the metadata on how the configuration got there. -e