Ken Claussen makes some excellent points about compiled access lists, 
which, as far as I know, still don't reorder.

Several things might be causing confusion about reordering.  There 
were several changes around IOS 10.2 and 10.3.

In what I'm pretty sure was 10.2, if you typed in

          172.16.10.0   with the wildcard mask 0.0.255.255,

the mask would override the address specification to produce a 
displayed access list rule of

          172.16.0.0   with the same wildcard mask.

If you analyze the two statements, they have the same effect, but 
look different.

Also, I believe with 10.2, mnemonics automatically replaced port 
number specifications in extended access lists, which wasn't 
backwards compatible. If you had the expression

           ...eq 23

in a 10.0 config, loading it into 10.2 would produce

           ...eq telnet

A 10.3 difference was the treatment of access group statements with 
no corresponding access list rules.  Prior to 10.3, the IOS assumed 
that pointing to access-list 1, even if there were no explicit rules, 
referred to a list containing only the implicit deny all. All 
traffic, therefore, was blocked.

In 10.3 and subsequent releases, if there was not at least one 
explicit access list rule, coding the access group statement had no 
effect.


>On some of the higher end (7000 series) router platforms there is a command
>called "Access-list compiled" When added to the IOS config this command
>tells the router to re-order the list for the most efficient operation.
>
>Turbo Access Control Lists
>"Feature Overview
>This feature enables Cisco 7200 and 7500 series routers, and Cisco 12000
>series Gigabit Switch Routers to evaluate access control lists (ACLs) for
>more expedient packet classification and access checks.
>
>Benefits
>Access control lists (ACLs) are normally searched sequentially to find a
>matching rule, and ACLs are ordered specifically to take this factor into
>account. Because of the increasing needs and requirements for security
>filtering and packet classification, ACLs can expand to the point that
>searching the ACL adds a significant amount of time and memory when packets
>are being forwarded. Moreover, the time taken by the router to search the
>list is not always consistent, adding a variable latency to the packet
>forwarding. A high CPU load is necessary for searching an ACL with several
>entries.
>
>The Turbo ACL feature compiles the ACLs into a set of lookup tables, while
>maintaining the first match requirements. Packet headers are used to access
>these tables in a small, fixed number of lookups, independently of the
>existing number of ACL entries. The benefits of this feature include:
>
>
>For ACLs larger than 3 entries, the CPU load required to match the packet to
>the pre-determined packet-matching rule is lessened. The CPU load is fixed,
>regardless of the size of the ACL, allowing for larger ACLs without
>incurring any CPU overhead penalties. The larger the ACL, the greater the
>benefit.
>
>
>The time taken to match the packet is fixed, so that latency of the packets
>are smaller (significantly in the case of large ACLs) and more importantly,
>consistent, allowing better network stability and more accurate transit
>times."
>
>http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120
>limit/120s/120s6/turboacl.htm (Watch for Word wrap)
>
>Ken Claussen MCSE CCNA CCA
>[EMAIL PROTECTED]
>"The Mind is a Terrible thing to Waste!"
>
>
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
>Scott Meyer
>Sent: Tuesday, April 17, 2001 7:44 AM
>To: [EMAIL PROTECTED]
>Subject: RE: access list rearrange? [7:861]
>
>
>Remember there is an implied deny at the end of every list. The purpose of
>the list is to permit 172.16.40.0 and deny everything else. This small a
>list, especially a standard one, wont have a much impact on router
>performance. Why deny 172.16.20.0 and 172.16.30.0 first, and making the
>router process 3 lines of list, if it is going to be denied anyway? Is there
>a difference between
>
>  access-list 1 deny 172.16.20.0 0.0.0.255
>  access-list 1 deny 172.16.30.0 0.0.0.255
>  access-list 1 permit 172.16.40.0 0.0.0.255
>
>
>and
>access-list 1 permit 172.16.40.0 0.0.0.255
>
>
>The 2 deny statements are not needed, don't do anything, and only add work
>for the processor.
>
>Scott Meyer
>CCNA, CCDA, MCSE, etc
>[EMAIL PROTECTED]
>
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
>Tolanid
>Sent: Monday, April 16, 2001 8:53 PM
>To: [EMAIL PROTECTED]
>Subject: Re: access list rearrange? [7:861]
>
>
>Scott - my experience has been that access lists are NEVER re-arranged.  I
>would not believe the book.  I have the book you are talking about - I'll
>refer the errata for the book from their website (if they have it).  But,
>again,  my understanding is - the IOS will never re-arrange the access list
>the way "it" thinks is right.
>
>Also - I am looking at the example you provided but don't see why the new
>"re-ordered" one is better??
>
>Thanks
>
>Raj
>"Scott Meyer"  wrote in message
>[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>>  I was reading Sybex's old ACRC book. One of the study questions, as well
>as
>>  a tip in the chapter indicate that the IOS will reorder an access list to
>>  make more sense.
>>
>>  For example, an access list entered as:
>>  access-list 1 deny 172.16.20.0 0.0.0.255
>>  access-list 1 deny 172.16.30.0 0.0.0.255
>>  access-list 1 permit 172.16.40.0 0.0.0.255
>>
>>  would be re-ordered as :
>>  access-list 1 permit 172.16.40.0 0.0.0.255
>>  access-list 1 deny 172.16.20.0 0.0.0.255
>>  access-list 1 deny 172.16.30.0 0.0.0.255
>>
>>  I played around a bit and could not confirm this. show ip access list
>showed
>>  the access-list exactly as I entered it.
>>  I had always thought that IOS would never re-arrange the list, no matter
>how
>>  stupid it was entered.
>>
>>  Am I on crack or is the book wrong?
>>
>>  Scott Meyer
>>  [EMAIL PROTECTED]
>>  FAQ, list archives, and subscription info:
>http://www.groupstudy.com/list/cisco.html
>>  Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>FAQ, list archives, and subscription info:
>http://www.groupstudy.com/list/cisco.html
>Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>FAQ, list archives, and subscription info:
>http://www.groupstudy.com/list/cisco.html
>Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>FAQ, list archives, and subscription info: 
>http://www.groupstudy.com/list/cisco.html
>Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=933&t=861
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to