[Infrastructures] using IA methodologies to build network element configuration

Craig Anderson acraiga@pacbell.net
Sat, 2 Apr 2005 22:49:59 -0800


Check Point did this with their firewall configurations.
A generalized set of rules that govern how traffic is
allowed to flow between sources and destinations.
the rules are pushed to all firewalls where they are
interpreted based on actual interfaces on each firewall.
It worked quite well.  Their licensing scheme made
their boxes a real pain, but the configuration was cool.

I think that the generalization in the rules, at first,
made understanding a configuration harder.  When
you are used to thinking in terms of a particular firewall
and it's inside and outside, the shift to a generalized
global view took some adjustment.  But then after
some mental discipline, it was nice.

Sorry, I'm not on sanog.

Craig

On Apr 2, 2005, at 6:58 PM, Brent Chapman wrote:

> At 2:55 PM -0500 4/2/05, Daniel Hagerty wrote:
>>  > In the networking world (I am not including firewalls in this), I 
>> have
>>  > not yet seen that much data is duplicated and needs to be 
>> normalised.
>>  > If you think that normalisation will help, I am for it.
>>
>>     So what do you think the routing policy of a network is?  In my
>> mind, it's a distributed object (I could invent a language that
>> described the routing policy for an entire network) that is somehow
>> realized in pieces across each element within a network.  That strikes
>> me as duplication of some form, even if the precise aspect of the
>> duplicating may not be obvious.
>
> 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 routing policy is by far from the only example (like the
>> firewalls you're avoiding), but it all comes down to the same problems
>> in the end:
>>
>>     You have a large, distributed system.  Each part of it has to be
>> consistent with the the whole for the distributed system to perform
>> correctly.  Whether the distributed system consists primarily of unix
>> machines,  or routers is of little consequence -- distributed system
>> is distributed system.
>
> Yes, precisely; that's a good explanation.
>
>>     If the world was perfect, you could write down a language that
>> described your entire distributed system, and produce all the other
>> configuration aspects of it from this one uber language.  In practice,
>> there's some getting there from here to achieve this.  People are able
>> to do it now to more or lesser extents, but we're still producing
>> these languages in an ad hoc fashion.
>
> I've been toying with the idea of creating a system (database, 
> language, etc.) for describing networks in enough detail that you 
> could build various tools on top of the system to produce 
> configurations for particular devices.  So, for instance, you would 
> describe your network in this system, and then run one tool against 
> that description to generate a Cisco config for a particular router, 
> another tool to generate a Juniper config for another router, yet 
> another tool to generate an Alteon config for a particular load 
> balancer, etc.   And still another tool to generate Cricket config 
> files to do SNMP performance monitoring of all the devices in your 
> network, and another tool to generate Nagios configurations for SNMP 
> status monitoring, and another tool to generate Snort configs for 
> sensors in particular locations, and so forth.  All running against a 
> common, shared description of your network.
>
>
> -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
> _______________________________________________
> Infrastructures mailing list
> Infrastructures@mailman.terraluna.org
> http://mailman.terraluna.org/mailman/listinfo/infrastructures
>