ld days, you could just issue the no access-list 101 command, and the entire 101 access list would be gone. On an ASA, that command doesn't do anything, because it wants you to enter a specific line to be deleted: ASA-5540/GAD(config)# no access-list 101 ERROR: % Incomplete command This is actually a good thing, as it will cut down on instances where you accidentally delete an entire access list when all you really wanted to do was delete one line. (Not that that's ever happened to me.) On an ASA, if you want to delete an entire access list, use the clear configure access-list access-list-name command: ASA-5540/GAD(config)# clear configure access-list 101 Turbo ACLs Normally, ACLs must be interpreted every time they are referenced. This can lead to significant processor usage, especially on devices with large ACLs. One of the options for enhancing performance with large ACLs is to compile them. A compiled ACL is called a Turbo ACL (usually pronounced turbo-ackle). Compiling an ACL changes it to machine code, which no longer needs to be interpreted before pro- cessing. This can have a significant impact on performance. PIX firewalls and Cisco routers support Turbo ACLs. On PIX, the command access- list compiled tells the firewall to compile all access lists. Only Cisco routers in the 7100, 7200, 7500, and 12000 series (12.0(6)S and later) support Turbo ACLs. The IOS command to enable this feature is also access-list compiled. The latest versions of ASA code have Turbo ACLs enabled by default. This behavior cannot be negated. When Turbo ACLs are enabled on a PIX, the output of show access-list is altered to indicate that the ACLs are compiled and show how much memory each ACL occupies. This output is not present on the newest versions of the ASAs: PIX(config)#access-list comp PIX(config)#show access-list TurboACL statistics: State Memory(KB) Inbound Operational 2 Shared memory usage: 2056 KB access-list compiled access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 1024) alert-interval 300 access-list 