On Apr 11, 2005 1:01 AM, Kirby Files <ksfiles@gmail.com> wrote:
> 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".
All spot on. I particularly like the product definition one, that has
played an important role here already - and we've only gotten to the
stage of importing network configuration into the model and
highlighting further study cases...
The key steps and comments in building and implementing such a system,
which many are faced with doing (hence: this is a great focus for an
open source project I think :-)), are, I see (and this is the process
we're going through now where I work):
- Model the network. In one projection of the idea, at the simplest
level you have objects and relationships (which are objects
themselves). Both of these types have attributes. It's important to
be able to map any network type that you'll need to configure, so you
probably need to store VLAN/FrDLCI information, for example. How to
map that? Perhaps some recursion is useful (a network segment object
(e.g. DLCI, VLAN) is "a member of" or "attached to" a physical link
object. IP interfaces are just mapped to a logical or physical
parent, and so on.
The key is obviously to get a model which can represent your entire
network completely enough that you don't need to work around it. The
basic approach above will work, how far you abstract it is network
dependant.
- Understand your deployment characteristics. You may or may not
have out-of-band management (in some and not all locations). If not,
how do you avoid cases like disabling the IGP router so that you won't
break the telnet session as the config is applied? How then, do you
perform changes to vital (e.g. management) interface configuration?
How do you avoid such problems? "disable certain commands"
immediately comes to mind, but how can you allow certain configuration
to occur whilst disabling potentially important commands. This part
is inevitably somewhat network specific, but you may like to use
approaches to have an interface attribute such as "management".
Configuration for these interfaces is then manual. However, it may be
impossible to know of all of these cases ahead of time without an
exhaustive search (possibly related to strange loops/Godel's
incompleteness theorem?).
Then you'll need some way of applying the config to the devices. A
device agent would be best (since we can treat the change to happen
atomically, at some particular pre-scheduled time) (cisco have such an
agent, but the interface is closed), at worst scripted-VTY access.
The latter of course has the problems spoken about above.
Scripted-console access may be a real boon, but is largely unsuitable
for many devices (CPE, small sites depending on your management
"will"), so we'll have to consider scripted VTY or similar - SNMP
configuration MIBs are not an option here (no non-v3 write (policy)),
but may be for you..
- Finally, enforce the model as being more important than the
element. The network element just provides reality for your network
model. Process as well as policy is needed (I encourage TAC+ command
lockouts),
Other notes I have about the goals of the system are:
- Configuration applied must have the same action no matter what the
initial state of the target element. This generally translates to
"bring all pre-requisite configuration along with the change".
This is important so that you can apply partial configurations to
devices in whatever state -- many of the "big boys" who do network
configuration management presently load to startup and reload, and
their networks handle this type of management. For many of us out
there, that's not possible.
So the model must support storing all necessary configuration (or at
least, identifying what standard templates need to be placed in what
order to build the "base config" of the device) so that both partial
and complete configurations can be formed.
How do I know what is already configured on the device? Assume
nothing? Probably. This depends on if you want to completely trust
your database, or whether you have some trust in the existing
configuration. The more I work in this area, the less I can trust the
network configuration.
- Allow the network operators to easily identify the change (via some
ID) that caused the most recent (or couple of most recent) change to
the element configuration. This tends to be important in helping the
NOC identify the triggers for recent change to the configuration. You
can alert people of this in other ways, e.g. via the configuration
manager itself.
Auto-generating "banner exec" works well on cisco devices, for
example, as a sign that "the change was applied" (whether it was
successful or not, is somewhat different).
Once the above has been nutted out, the multi-vendor hurdles are
mostly irrelevant, and all related to the "deployment characteristics"
situation above.
-andrew
Follow-Ups:
References:
|
|
