On Thu, Feb 27, 2014 at 9:50 AM, Ryan Shea <ryans...@google.com> wrote:
> A couple more thoughts, regarding > > Network => DB > > I completely agree that trying to use the network config itself as the > authority for what we intend to be on a device is not the right long-term > approach. There is still a problem with Network => DB that I see. Assuming > you have *many* devices, that may or may not be up at a given time, or may > be in various stages of turn-up / burn-in / decom it is expected that a > config change will not successfully make it to all devices. There are other > timing issues, like a config built for a device being turned up, followed > by a push of an update to all devices that "succeeds", followed by the > final turn-up of this device. Even if you have a fancy config pushing > engine, let's just take as a given that you'll need to scrub through your > rancid-git backups to determine what needs to be updated. > > Regarding the MD5 approach, let's also think that configlets could have > "no" commands in them. In the NTP example I had before, if we wanted to > remove an NTP server the configlet would need the "no" version, but the > rancid backup obviously would not have this. I'm not trying to work a unit > test assertion framework here either. Some vendors have more robust > commenting, and this can be quite convenient for explicitly stating what > was pushed to the device. What are you using in your network... banner, > snmp-location, hope, prayer? > We don't do this, but the only flexible commenting in IOS style configs is ACLs. You could have an ACL that contains remarks only, and include version information: ip access-list CFG-VER remark CFG-VER-NTP 1.0.3 remark CFG-VER-VTY 4.3.2 end You could break this into individual ACLs if you prefer: ip access-list CFG-VER-NTP remark CFG-VER-NTP 1.0.3 end ip access-list CFG-VER-VTY remark CFG-VER-VTY 4.3.2 end Seems ridiculous, but that is the sorry state of the network OS. -- Tim:>