At 11:01 AM -0400 4/10/05, Kirby Files wrote:
>Aaron Glenn wrote on 04/09/2005 08:45 PM:
> > 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)
In other words, we want a model that represents information like:
- Device D1 contains cards C1, C2, and C3
- Card C1 on Device X has ports P1, P2, P3, and P4 of type Y
- Port P1 on Card C1 on Device D1 is a 100 Mb/s Ethernet port
- Port P1 on Card C1 on Device D1 is connected to network N1
- Network N1 is 192.168.1.0/24
- Port P1 on Card C1 on Device D1 is 192.168.1.1/24
And so forth, in as much detail as you want, for all the various
parts of your network.
> * An interface for defining this model in network engineering terms
In other words, an interface that lets you do things like
- Add Device
- Add Card to Device
- Add Port to Card
- Add Network
- Describe connection from Port to Network
etc.
> * definition of services in terms of component devices and logical path
I think I know what Kirby is talking about here, but I can't think of
a simple example.
> * scripts or code defining how to build configs for specific vendors
>based upon the model, connections, and applied services
In other words, code that knows how to generate a config file for
Device D1 if that device is a Cisco, based on data drawn from the
model. The code has to be able to extract information from the model
such as:
- What make/model of device is D1?
- What interfaces exist on D1?
- What ports are in use on those interfaces?
- What networks are those ports connected to?
- What are the characteristics/parameters of those connections?
> * service activation manager that can manage many simultaneous
>threads of network communication for deploying these configs in a
>transactional process
At this point, we move beyond the model to the actual ability to
deploy configurations derived from the model. In other words, I
conceptually separate the problem into two parts:
1) What should the configs be for each device?
2) How do I get those configs onto those devices?
> * configuration backups, history, diffs, equipment hardware
>management, etc.
In other words, the ability to answer questions like:
- What was the configuration of device D1 yesterday, before we
changed things and started having problems?
- How many unused card slots are there in device D1?
- How many unused ports are there on Card C1 in device D1?
> * network auditing to ensure database accuracy
In other words, "is my model of the network accurate?"
> * a database schema or API to query all fields, relationships,
>events, etc.
So that you can write the code to generate the configs for the
devices, as well as generate configs for related tools like SNMP
monitors (Cricket, etc.), system status monitors (Nagios, 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".
Yup.
> > 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.
Yes, this is important; it's got to be extendable, because you aren't
going to think of everything up front.
-Brent
--
Brent Chapman <brent@greatcircle.com> -- Great Circle Associates, Inc.
Specializing in network infrastructure for Silicon Valley since 1989
For info about us and our services, please see http://www.greatcircle.com/
Network Automation blog: http://www.greatcircle.com/blog/network_automation
Follow-Ups:
References:
|
|
