[Infrastructures] using IA methodologies to build network element configuration

[Brent Chapman]

At 6:40 AM -0400 4/3/05, Daniel Hagerty wrote:
>  > Exactly.  In many cases, you aren't actually "duplicating" info onto
>  > different network devices, but rather deriving specific info for each
>  > device from some common source.
>
>     The difference in our wording is simply a semantic one; we appear
>to speak of the same things, but word them differently.  Such is
>communication...

I wasn't disagreeing with you, merely pointing out that it isn't 
always easy to tell that config info on two different devices is 
(implicitly or explicitly) derived from a common root.

For example, think about a /30 subnet that's used for the IP 
addresses on each end of a point-to-point link, with different 
make/model routers at each end.  The router at one end might be a 
Cisco, and will therefore have something in its config file about a 
particular interface, along the lines of

	interface serial 1/1
		ip address 192.168.155.1 255.255.255.252
		no shutdown

The router at the other end might be a Linux box, with a completely 
different syntax for setting the ip address on the interface, and 
might refer to the address for its end as "192.168.155.2/30".

The key thing is, these are two different references in two different 
syntaxes to two different components (individual IP addresses for 
either end) of the same object (the /30 network for the 
point-to-point link).

What I need is a database that contains, in this trivial example, the 
following items of information:

	Network "private-line-1" is a point-to-point link between 
RtrA and RtrB,
	with subnet 192.168.155.0/30, using PPP, with RtrA at the low-numbered
	address, and RtrB at the high-numbered address.

	RtrA is a Cisco.

	RtrB is a Linux box.

	RtrA interface serial-1/1 connects to network "private-line-1".

	RtrB interface /dev/ttys9 connects to network "private-line-1".

 From those facts (plus various other facts about RtrA and RtrB), I 
should be able to run a Cisco-config-generator program that generates 
the appropriate configuration for RtrA, and a Linux-config-generator 
program that generates the appropriate configuration for RtrB.

Each of those config-generator programs should be able to query the 
database for information like "What interfaces are defined for me? 
What networks are those interfaces attached to?  What are the 
parameters for those networks?", get back answers in a 
vendor-independent form, and then translate those answers into 
whatever form is needed for the type of device in question; for 
example, the database might answer "what is the IP address for my 
interface to network 'private-line-1'?" with "192.168.155.1/30", 
which the Cisco config-generator would translate and use as 
"192.168.155.1 255.255.255.252".  I don't think the config-generator 
programs need to be much more than template manipulators written in 
Python or Perl or something similar.

>     Let me express a much simpler version of the same problem,
>different context (no pun intended).  I'm going to express it a very,
>very particular way, on purpose.
>
>     Consider the two unix programs inetd and xinetd.  They are
>different programs.  They have different configuration files.  And yet
>they do roughly the same thing; from far enough outside a system, you
>can't tell if it's one or the other implementing the functionality of
>the platonic "Internet Super Server" program.
>
>     It would obviously be useful to be able to specify our
>configuration "Internet Super Server" configuration in some uber
>language, and/or convert between the two configuration files.

I don't think that being able to convert between the two 
configuration files is necessary, and it complicates things 
significantly.  In particular, I don't think it's necessary to write 
the "unparser" you describe, to convert from the targeted config file 
back into the "uber language".  I think it's sufficiently useful just 
to be able to _generate_ the targeted config files from the "uber 
language".

>     As Steve will tell us, order really does matter in doing something
>like this.  If we're on a particular host, we have to login to the
>topologically far router first, reconfigure its network in a very
>careful order, and usually type one last key statement that destroys
>our ability to communicate with the router until we reconfigure the
>topologically near router to agree with the state of the far router.
>No amount of reconfiguring the near end router first will ever allow
>us to converge on the desired new state.

Yes, obviously, although I'll point out that having a robust 
out-of-band command-and-control network to all of your key devices 
(via conserver, or something like the Uplogix Envoy network 
management appliance; 
http://www.greatcircle.com/blog/2005/03/07/uplogix_envoy_n.html) goes 
a long way towards making issues like this irrelevant, because it 
keeps you from getting "cut off" from any of the devices.  Such 
networks are a good investment, in my opinion, and not all that 
expensive as a fraction of the total cost of the networks that 
they're used to manage.


-Brent
-- 
Brent Chapman <brent@greatcircle.com> -- Great Circle Associates, Inc.
Specializing in network infrastructure for Silicon Valley since 1989
For info about us and our services, please see http://www.greatcircle.com/
Network Automation blog: http://www.greatcircle.com/blog/network_automation