> 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?).
"It depends".
On one extreme, you limit the language you can speak, preventing
the ugly cases, consequently limiting the capability of your model.
On the other is no restriction, with a resultingly more expressive
model, but with halting trouble if the user doesn't use it well.
Personally, I'm for being allowed to shoot myself in the head if
that's what I said to do, but getting to a model that allows me to
both shoot myself in the head and have the computer warn me that "by
the way, you might want to know that saying 'twiddle the flubbypux
into state 29' may mean 'shoot yourself and twenty friends in the
head'" is a little bit of work.
Witness my example from a few days ago on infrastructures: the
addresses within a subnet are numbers. I don't mean that in the
obvious sense (being 32 bit numbers), I mean that in a more subtle
one. If you allow the user of your configuration system to operate on
these numbers in arbitrary ways and define functions on them (which
you pretty much have to do in order to give them what they need),
you're giving them the very tools they need to create halting
problems.
In the case of network engineering, your semantic and reflection
problems with reasoning with loops is relatively easy.
Consider the case of destroying the only path to talk to a
computer (not terribly different from a router in this simple
example). Assuming a linux machine, and we were sitting at some other
host in our network, typing something like the following is an
instance of the statement class we are concerned with:
$ ssh host-thats-gonna-die
<authenticate1>
$ sudo ifconfig eth0 0
<authenticate2>
where once authenticate2 completes, the deed is done.
What we want to be able to do is equate the above statement with the
notion of destroying our ability to reach hosts-thats-gonna-die from
wherever we started from (and if our network has reasonable transitive
properties, no host can reach it).
This is "simple", for an annoying value of simple. It mostly comes
down to being able to compute the meaning of each statement in a
reasonably large size world (one thats as large as your network). In
particular, you need to be able to reason with how
"sudo ifconfig eth0 0" transmitted to our victim host is going to side
effect the network configuration of the victim such that it would be
unreachable to the broader world. Somehow differentiate this
condition from other cases like
"sudo ifconfig eth0 192.168.1.1 netmask 0xffffff00" where that isn't a
reasonable value for your broader network and
"sudo ifconfig eth0 192.168.2.1 netmask 0xffffff00" where that just so
happens to be the same as what's configured now.
May of the issues you speak of are creations of the semantic issues of
configuration management.
Here's the basic ordering that the math enforces:
1. Do the following, in parallel. They do not readily seperate.
a. Figure out the semantic problems.
b. Figure out the knowledge problems.
2. Arrive at something that works for your domain. Try to apply it to
another domain. Watch it break. Go back to step 1.
So, "model the network" is really step 1 in disguise.
Understanding of your deployment characteristics is once again step 1.
The question of how to avoid disabling IGP when you're using telnet
that depends on routing working to perform the configuration changes
is a knowledge and semantics question.
Some amount of the questions of "how to produce delta statements",
both at some macro level of the entire network, and the micro level of
a given device are also semantic in nature. There are lot of other
issues involved, but questions in the form of "how does it behave" and
"how do I tell it...?" should set of bells.
This is not to say that you are in an endless sea of "figure out step
one first or you're doomed". Quite the opposite; take the problem
apart in whatever way you find works, and there are plenty of parts
out there. Hopefully some of my own examples help.
I'm not sure how tall we'll have to climb to really produce
satisfactory reasoning with the problem of "this" yet.
The IGP example, the destroy the ip address of the interface, and many
other complex "godel" looking problems in configuration come down to
the presence of an implied "this" concept. For simple things like
"this router", it's can be easy enough to express. Other things are
probably less so.
Follow-Ups:
References:
|
|
