Network Configuration Management Practices

Fri Sep 17 07:59:36 UTC 2004

It I have frequent changes, I always automate them so that:
- operator enter data into the database;
- operator click 'UPDATE'
- operator review proposed update and click APPLY
- tier-3 receive change report and review it.

We did such thing (analyzing configs, creating schemas and posting it all @
internal WEB) when I woprked in ISP in MOscow, but we never (!) allowed
anyone to configure routers manually, except very unusual changes.
Everything other (interfaces, E1 channels, access lists, BGP filters, route
maps and so on) was generated and updated automatically.

When I saw tier-1 people doing 'conf t' here in USA, I think _oh, they have
so many money that they can allow people to touch configs manually' -:).
/Unfortunately, Cisco is not  old Cisco now, with a lot of skilled and
helpful developers, so no one hope that they will help in such automation/.

----- Original Message ----- 
From: "Austin Schutz" <tex at off.org>
To: "Alexei Roudnev" <alex at relcom.net>
Cc: "Scott Weeks" <surfer at mauigateway.com>; "Carl W.Kalbfleisch"
<c.kalbfleisch at comcast.net>; <nanog at merit.edu>
Sent: Wednesday, September 15, 2004 2:25 AM
Subject: Re: Network Configuration Management Practices

> On Wed, Sep 15, 2004 at 12:27:20AM -0700, Alexei Roudnev wrote:
> >
> > One more thing. We tried to review _proposed changes_ and _changed
applied_.
> > Practice showed, that it is impossible to see errors in proposed
updates,
> > even if 3 - 4 engineers review it (not design flaws, but syntac and
> > semantics errors), so we did not got many use from pre-change reviews
> > (except design ones). But we got extremely high profit from post-change
> > reviews (verifying, what really changed on the router / firewall after
> > maintanance window) - it allows to see some unwanted changes and avoid
few
> > possible service disruptions.
> >
>
> This doesn't seem to scale too well. When you have frequent changes
> (i.e. many access devices) the diff load becomes unmanageably large.
> My ideal would be to have a network monitoring tool which compares the
> actual network against a configured baseline. The presumption would be
that
> if the network matches what have been set forth as engineering rules, I
don't
> really care what the specific settings are.
> Currently we do something sort of halfway: archive the actual configs
> and then run audit scripts against them, which parse the configs.
Definitely
> not ideal but it helps catch simpler errors. One of these days when I have
> extra cycles.. (yeah, right)
>
> Austin