Paxton wrote on 04/08/2005 04:22 PM:
> I was interested by Brent's original NANOG posting, in which he states:
>
> ..."I'm not simply talking about [..] device configuration monitoring
> systems [..] Instead I'm talking about systems that will start from a
> description of how a network ought to be configured, then interact with
> the various devices on that network to make it so..."
>
> What currently available tools actually do this?
None that I've seen. Before going the route of building our own
internal system for vendor-independent configuration generation and
management, I met with every CM vendor I could find, including a whole
bunch of dot-com busts. To name a few (the more promising ones):
Orchestream
Dorado
Goldwire
Digital Fairways
Cplane
Network Mantra
Rendition
Most of these focused on two things: config backup, and limited Cisco
service config templating.
What we were looking for was a full network equipment and relationship
model, generic enough to model all types of routers, switches and
containers, along with a scriptable configuration generation engine to
interpret that model into device-dependent configuration deltas, and a
service activation manager to resolve dependencies (which services
required changes to which devices) and schedule config changes.
Some of the tools above evolved to be support a little more than just
Cisco, and some of the config templating got a little more
sophisticated, but most have since died or been acquired, and none
meet the above goals.
Unfortunately, 4 years later, we still wouldn't be able to replace our
homegrown configuration management system with any COTS system that
had comparable features. And the importance of having a queryable
network model cannot be overstated. This has become the core of our
OSS systems: driving data collection, automating NMS configuration and
performance measurement, and enabling much better inventory control
than we ever had before.
Originally, I had hoped that the DMTF Common Information Model and
Directory Enabled Networking initiatives might yield some useful
products in this direction, where TMN failed to help. But these took
the same path of TMN of over-abstracting and over-specifying
particularly at the physical layer, making them unworkable for logical
network modeling.
--kirby files
NMS Software Lead
Masergy Communications
Follow-Ups:
References:
|
|
