[Infrastructures] using IA methodologies to build network element configuration

[Adam S. Moskowitz]

Joel Huddleston <joelh@paring.cyberzod.com> wrote:
> Push, damn, I *wish* Cisco, Bay and Juniper would put a decent user
> interface/mutlitasking OS on a router.

Why in the world would you want to do that?!?! It's a router, not a
general purpose computer! Do you really want a bloated, unproven, not-
hard-realtime O/S on routers that are handling metric buttloads of
packets every second? I certainly don't.

User interface? Why? You need a way to read the config, write the
config, and get stats. Want windows and full emacs line editing and
such? Sure -- build an X Windows client that presents the GUI of your
choice and talks the minimal protocol to the router.

AdamM

From: Joel Huddleston <joelh@paring.cyberzod.com>
To: infrastructures@terraluna.org
Subject: Re: [Infrastructures] using IA methodologies to build network element configuration
Date: Tue, 29 Mar 2005 09:53:34 -0700

Level 3 Communications uses a home-brew tool to manage their entire
international network. I was not a part of the team that built it, but I have
many friends on that team. Thousands of pieces of network gear are all
configured out of one place. By necessity, it uses push.  Until we have switches
and super-routers that run a full OS, that is just our world. Their tool is even
able to provision a new circuit to a customer, automatically, based on a
customer request through a web interface. The tool is very obviously proprietary
and a basic part of their business model. Still, it shows that such a thing can
be done and *is* done when engineers get the chance to build it before they must
start fighting fires.

In answer to your questions below:

Push, damn, I *wish* Cisco, Bay and Juniper would put a decent user
interface/mutlitasking OS on a router.

Order and dependency are resolved by blowing an entire config to the system each
time. If network contact is lost due to a bad config, redundant paths (and
routers) allow the network to continue to function and hard-lines to modems
allow the configuration management system to contact the router with the broken
config. (Side note, the network engineers have a "trophy" that they pass around
to denote the person who caused the most recent *major* network outage. It is
called the Lamp of Shame. OK, the name is much longer than that, but it has an
actual person's name in it. For her sake, I will not repeat it.)

Full configs are delivered each time a system is updated. Router configs tend to
be somewhat simpler (read "smaller") than entire OS configs. Of course, if my
wish for point 1 above were addressed, then this methodology might become
cumbersome. :-/

One conceivable solution to the push/pull problem would be a small UNIX system
(hell, a $499 MacNugget (Mac Mini) is IDEAL for this) colocated with network
gear. Have it "pull" new configs from the central authority. Give it ultimate
authority to deliver those through a local push. Have it test the configs to
ensure connectivity is maintained. Let it auto-backout if problems occur.

(Hmm, time to write a proposal....)

Quoting Andrew Fort <afort@choqolat.org>:

> Colleagues,
> Almost invariably, this list discusses (mostly UNIX) systems.
>
> I'm both a sysadmin and network engineer, having a CS degree background
> and done varying degrees of work as both network engineer/designer and
> sysadmin.  I'm all for sane 'infrastructure design', congruent or
> proscriptive tools to build it, recover it and manage it (depending on
> which lingo you prefer), and so on...
>
> However, I find that the majority of networks (in fact, all those I've
> ever worked at, both large and small), both initially design their
> network configurations using a manual process, and largely maintain them
> using a manual process.
>
> I use some cfengine triggers to define build times, and make to manage
> my dependencies and string together my vendor-specific configurations
> (based on the network model), and this is what I'd call a convergent
> tool -- since people are still allowed to configure services manually,
> divergence is inevitable.
>
> Some have recently tried to raise the profile of doing for networks what
>   we already do for systems, for example; Brent Chapman now has a blog
> discussing this field (www.greatcircle.com/blog/).  I know that some
> have developed their own systems and that some vendors are touting their
> solutions; I am, however, surprised that I find very little information
> about this approach to building networks.
>
> Is it just that I'm not finding the right folks, or do the majority of
> network engineers (some even call themselves 'architects' ;-) just not
> get it?
>
> Surely there must be some folks on here who build network configurations
> as well as host configurations?
>
>    - How have you approached the push/pull problem with applying
> configuration (considering that the major network equipment vendor
> doesn't provide an open 'pull' architecture)
>    - How do you manage order and dependency (I'd argue order is equally
> important for systems as well as networks)?
>    - How do your systems handle/differ for initial system build versus
> ongoing configuration management?
>
> I have a few ideas about this I'd love to discuss, but won't use any
> more bandwidth unless there are interested parties.  Anyone?
>
> regards,
> andrew fort
> _______________________________________________
> Infrastructures mailing list
> Infrastructures@mailman.terraluna.org
> http://mailman.terraluna.org/mailman/listinfo/infrastructures
>


--
Joel Huddleston
eka joelh@cyberzod.com
"Try going to your local middle-school chess club, hand out crystal
meth and guns. That might be good practice." -- Pvt. Church ( when
asked how to prepare for ones first exposure to the Internet.)

_______________________________________________
Infrastructures mailing list
Infrastructures@mailman.terraluna.org
http://mailman.terraluna.org/mailman/listinfo/infrastructures