Managing IOS Configuration Snippets

Tim Durack tdurack at
Thu Feb 27 16:50:28 UTC 2014

On Thu, Feb 27, 2014 at 9:50 AM, Ryan Shea <ryanshea at> 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

You could have an ACL that contains remarks only, and include version

ip access-list CFG-VER
 remark CFG-VER-NTP 1.0.3
 remark CFG-VER-VTY 4.3.2

You could break this into individual ACLs if you prefer:

ip access-list CFG-VER-NTP
 remark CFG-VER-NTP 1.0.3

ip access-list CFG-VER-VTY
 remark CFG-VER-VTY 4.3.2

Seems ridiculous, but that is the sorry state of the network OS.


More information about the NANOG mailing list