On 4/19/05, Daniel Hagerty <hag@linnaean.org> wrote:
> This is all doable. If you want rollback, you're going to
> discover that it starts to curve back on the modeling questions: how
> do you explain the rollback capabilities of a juniper versus those of
> a cisco, and how does we use these capabiltiies within a larger, more
> platonic notion of rollback?
I only see the concept of a revision number in the model (and what the
currently enacted revision is) - is anything else required?. As long
as you can diff between the "current enacted configuration" (last
transaction ACK) and the "to be applied configuration", you can
produce configuration statements that will roll forward and roll
backward (if supported by your device configuration language), or you
can produce the whole configuration for rollback.
The lurking assumption in that is "produce the whole configuration".
Surely this implies a congruent tool (i.e., it is the GOD of its
minions/devices). We can probably do equally well with simply
reloading a previously known good configuration and reloading.
However, if your tool is not congruent, and you implicitly change
state (by reloading existing configuration), is there a danger of
increasing entropy through such recoveries? I think this is going to
be OK, but is this system what you might call a strong axiomatic
system? (if so, we can't know for sure if it is going to be OK). I'm
guessing this is "the problem" with rollback.
As for building a device's configuration from a limited amount of
overall 'state'...
Could this be as simple as defining the device's role (or roles, in
smaller networks cash is much more limited). Each of these defines
pre-requisites, which gives you order, e.g. you must configure your
IGP before you configure BGP, you must configure crypto keys before
IPsec, and so on. But as always, syntax (i'm most familiar with IOS)
is rolling back on the semantics. Is this type of text-template
pre-requisite approach suitable for all device configuration
languages? What about overlaps between roles.. This is probably where
the tool relies on the implementor to avoid the implications of
occam's razor.
-andrew
References:
|
|
