RE: Managing IOS Configuration Snippets

["Chuck Church" <chuckchurch () gmail com>]

Along those same lines, we've been using alias exec for the same thing for a
while:

Alias exec  NTP  6500_NTP_V1.0.1
Alias exec bgp  6500_peer_V2.0.0

Thanks,

Chuck

-----Original Message-----
From: Tim Durack [mailto:tdurack () gmail com] 
Sent: Thursday, February 27, 2014 11:50 AM
To: Ryan Shea
Cc: nanog () nanog org
Subject: Re: Managing IOS Configuration Snippets

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