[130313] in North American Network Operators' Group
Re: (cisco, or any) acl *reducers* out there?
daemon@ATHENA.MIT.EDU (Andy Davidson)
Fri Oct 1 04:56:49 2010
From: Andy Davidson <andy@nosignal.org>
Date: Fri, 1 Oct 2010 09:56:26 +0100
In-Reply-To: <5083397C-550D-40F9-89D2-9C076274AE55@apnic.net>
To: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On 19 Aug 2010, at 04:23, George Michaelson wrote:
>>> something which can take a couple of hundred basic and extended ACLs =
and tell you
>>> these <ten> don't work
>>> these <twenty> conflict
>>> the remaining <x> have a sequence and can reduce to this basic <x-y> =
set
> A reasonable call. Its probably where we'll be by default, because =
there isn't anything there and I think first principles upward is better =
than paring back.
> [...]
> I think its clear a tool like I asked doesn't exist, and very probably =
won't, anytime soon.
Hello
[ I'm sorry this reply is so late, holiday season ]
I understand the problem and think that it is partly caused by the =
complexity of keeping the acl configuration on all edge ports in sync, =
and keeping the acl definitions/purpose documented.
The way around this, is to have a configuration management system that =
records the detail of the ACL (description / ticket number - along with =
the filter specification in generic terms), which generates the =
configuration - or even better uses flow-specification to distribute the =
rules. Further procedures to review the data in this management system =
periodically help this scale.
For the config management, this would tend to have to be locally bespoke =
(but simple to produce) in order to fit with existing policy and =
procedure, but the glue to push these rules out to routers is easy as =
open source tools exist :-=20
=
http://labs.ripe.net/Members/thomas_mangin/content-exabgp-new-tool-interac=
t-bgp=20
http://bgp.exa.org.uk/
Andy=
