[afnog] Cisco ACL

[Alan Whinery]

Also take special note of the effects of acl logging on cpu load; if you put "log" at the end, your fast switching scheme (cef, et al) can get bypassed.

http://www.cisco.com/web/about/security/intelligence/acl-logging.html#4



On 5/26/2010 9:54 PM, Mark Tinka wrote:
> On Thursday 27 May 2010 05:02:14 am Guillaume FORTAINE 
> wrote:
>
>   
>> http://code.google.com/p/capirca/
>>     
> I'd add that wherever possible, use named ACL's in IOS 
> rather than numbered ACL's. The reasons for this are:
>
> 	- Numbered ACL's are recompiled on-the-fly for every ACE
> 	  (Access Control Entry) that you add. So the router CPU is
> 	  always at 100% (or close) as you edit the ACL. The
> 	  situation can be exacerbated if the length of your ACL
> 	  (and the time you take to edit it) is considerable.
>
> 	- Named ACL's are updated atomically. This means the CPU
> 	  only recompiles them once, when you exit the ACL context.
> 	  The CPU will spend some cycles updating the system and
> 	  then quit. This gives much better performance when
> 	  handling ACL's.
>
> I'd also recommend enabling "Turbo ACL's" where supported. 
> Turbo ACL's compile ACL's into a set of look-up tables that 
> can be accessed in a small, fixed number of searches 
> regardless of the size of the ACE's. So an increase in the 
> number of ACE's has no additional impact on the CPU's 
> ability to process the ACL.
>
> In IOS, some features would only support numbered ACL's. In 
> these cases, you can't do much. Certain platforms, 
> thankfully, only support named ACL's, e.g., IOS XR, e.t.c. 
> With IOS XR, even though you can use a numeral to denote the 
> naming of an ACL, internally in the system, the numeral is 
> treated as a name or string.
>
> Hope this helps.
>
> Cheers,
>
> Mark.
>   
>
>
> _______________________________________________
> afnog mailing list
> http://afnog.org/mailman/listinfo/afnog

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://afnog.org/pipermail/afnog/attachments/20100527/9224a110/attachment.htm>