|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Network Configuration Management Practices
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" <[email protected]> To: "Alexei Roudnev" <[email protected]> Cc: "Scott Weeks" <[email protected]>; "Carl W.Kalbfleisch" <[email protected]>; <[email protected]> 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
|