[nsp] pushing config changes out to routers

Simon Leinen simon at limmat.switch.ch
Wed Sep 3 00:53:34 EDT 2003


On Wed, 6 Aug 2003, Streiner, Justin writes:
> While we're more or less on the subject, I'd be curious to see how
> various networks manage pushing mass configuration changes (BGP
> filters, regular password changes, updates to standard configs, etc)
> out to their boxes.  From past experience I'll hazard a guess that
> this is largely custom applications that people have specifically
> tailored to their needs.

Sorry for the late followup.  Note that there is an ongoing IETF
effort to define a protocol for "network configuration" (NETCONF)
where we need exactly this kind of input from operators! See

    http://www.ops.ietf.org/netconf/

> Specifically, I'm interested in what safeguards people put in place
> to 1) hopefully prevent a typo in a master config database from
> getting pushed out to lots of devices, possible causing a large
> outage, and 2) integrity checking of the pending config beyond
> things like making sure that a static route has the correct next-hop
> address, e.g. things like if interface X has access-group Y applied
> to it, make sure that access-list Y actually exists...

We don't do much automatic checking when changing router
configurations.  Engineers are either supposed to know what they are
doing, or use scripts for simple cases (e.g. peering filters).

For certain complex tasks that involved configuration changes on many
routers, I have written ad-hoc programs that parse all our router
configurations and generates deltas.  (Unfortunately I tend to write
these things in Lisp, so nobody else can use them :-)

> Awhile back I wrote a fairly extensive system for backing up
> configurations from network devices I'm responsible for and storing
> them in a journaled format so I can pull an old revision if needed.

We have such a system too (homegrown), and I think many operators use
RANCID for this.

> While it wouldn't be especially tough to add the functionality in it
> to allow the system to upload a modified config to a router, I
> specifically left that piece out because I was still grappling with
> the safeguard issue.

Uploading a complete (modified) configuration to a router is
problematic, at least on Cisco, because you have to reboot the router
to make the uploaded configuration the effective configuration.

So we try to modify the running configuration to become the target
configuration, hopefully with minimal disruption.

For routine tasks such as updating access lists, we have a script that
can install configuration snippets.  It uses pseudocomments in those
snippets (files) to determine the default set of routers on which to
upload, and the default set of e-mail addresses to send a change
notification to.  The user can pass a text note as an argument to the
script that will be included in the notification mail.

> Thoughts/insight are greatly appreciated.
-- 
Simon Leinen				       simon at babar.switch.ch
SWITCH				   http://www.switch.ch/misc/leinen/

	       Computers hate being anthropomorphized.
Date: Tue, 02 Sep 2003 23:53:23 +0200
Message-ID: <aabru226y4.fsf at limmat.switch.ch>
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (usg-unix-v)


More information about the cisco-nsp mailing list