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 :- http://labs.ripe.net/Members/thomas_mangin/content-exabgp-new-tool-interact-bgp http://bgp.exa.org.uk/ Andy
