on network modeling, have you all come up with your own model or used
something existing? Or taken something existing and modified it?
I have looked at CIM and after scratching my head for a few days finally
realized that I think of the network in terms of associations, and CIM is
laid out by generalizations (inheritance.) The associations are defined,
but are sort of hard to find because of the generalization perspective. I
don't want to get into a semantics discussion of what's right, I'm more
interested in being able to hand a database to a network engineer and say:
go for it. IMO a db schema laid out with CIM is too confusing because it
isn't laid out according to associations, which is (IMO) how network
engineers (vs IT modeling guys) see things.
Anyway, I have done this before and we sort of took some clues from what
was available at the time (SNMP and some vendor tools.) It wasn't exactly
right, but I learned a lot from the experience. We put together the
database for one specific tool, then realized afterwards how much else it
could be used for. I believe the core piece missing is the network
model/database, consider all the other parts (how to update devices,
monitoring configuration changes, etc) as component services that the
database enables. Not all the component parts have to be written for the
database to have value, and not everyone will want to use the same
component parts.
Are you all interested in starting an open source project around this?
On Mon, 11 Apr 2005, Andrew Fort wrote:
> 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:
|
|
