Aaron Glenn wrote on 04/09/2005 08:45 PM:
> Kirby,
>
> If you would be so kind as to elaborate on a few of your points outlined below.
>
> On Apr 8, 2005 6:52 PM, Kirby Files <ksfiles@gmail.com> wrote:
>
>>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.
>
>
> Perhaps it's the cleaning fluid fumes in my apartment today, but I'm
> having trouble fully grasping what you're describing there. Can you
> take it down a notch to laymens terms?
For us, a complete configuration management system includes:
* a vendor-independent model of the physical and logical network
(objects and fields describing configuration of devices, cards,
interfaces, etc; and relationships between these objects)
* An interface for defining this model in network engineering terms
* definition of services in terms of component devices and logical path
* scripts or code defining how to build configs for specific vendors
based upon the model, connections, and applied services
* service activation manager that can manage many simultaneous
threads of network communication for deploying these configs in a
transactional process
* configuration backups, history, diffs, equipment hardware
management, etc.
* network auditing to ensure database accuracy
* a database schema or API to query all fields, relationships,
events, etc.
This combination allows for the shifting of all configuration
responsibilities from users to the CM system (now, users mostly login
to core equipment only for troubleshooting), speeding up deployment,
reducing errors, and improving reliability. It also serves to provide
a true functional definition for all services frequently lacking in
Product Mangement docs; if the product can't be reduced to a
well-defined body of script or code, it's not baked enough to be
called "standard".
> What is a "queryable network model" ?
Well, as described above, the network model is a database that is
capable of describing what the equipment is, how it is configured, and
how devices are connected to each other. It includes the network
topologies and hierarchy, logical connections, IP subnets, routing
policies, physical components, etc.
For us, the key has been to keeps the schema for the model defined not
in the management software or static database tables, but a NetEng
modifiable syntax that can be quickly changed to add new concepts,
hardware, and services.
In this context, queryable means just that: all interesting features
of the network should be discoverable by external users and systems,
rather than being hardcoded in software. Whether this is implemented
in SQL (not always recommended, especially since SQL is terrible at
tree representations), a well-defined API, query syntax, or message
format is less important.
Thanks,
--kirby
Follow-Ups:
References:
|
|
