Easy ACL question

no access-list 1624 access-list 1624 permit 10.33.224.0 0.0.0.255 access-list 1624 permit 172.22.20.0 0.0.0.15

Chris.

Greetings,

Because this is an un-named ACL, you need to REMOVE the ACL and re-apply it LESS the lines you want removed.

While the ACL is removed, be aware that the interace to which it is applied will not pass ANY traffic until the ACL is rebuilt, unless you remove the access-group command from it.

Cheers...................pk.

It's been several years since I did IOS work, so the below is going by what I remember of what I read in passing:

The show access-list 1624 output had line numbers. That suggests to me that the OP might be using one of the versions of IOS new enough to support editting by line number, in a manner very similar to editting ACLs by line number in the Cisco PIX 6.3; with PIX, the syntax would be

no access-list 1624 line 30

Going by memory again, I believe that is incorrect. In IOS, an access-list that exists at all (even with just a remark) has an implicit deny at the end of it, but my experience is that an access-list which is referenced but which does not exist at all is treated as permitting everything.

I recall tracking down a networking problem at our ISP that revolved around this exact issue, when they slightly misconfigured the Natchi Worm Mitigation.

(The worm mitigation involved a policy map that dropped packets that were a particular length and which matched an access-list, with the access-list set to permit icmp -- with a permit in this context meaning that it was permitted to apply the policy map action (of denying the packet.) When our ISP lost the contents of the access-list, the non-existant access list matched all kinds of packets, so 92 byte tcp packets were dropped, 92 byte udp, and so on. If the default behaviour for a missing ACL was to treat it as a deny all, then the application of the policy map would have been denied for all kinds of packets, which in this case would have meant that no packets would have been dropped at all by the policy.)

As another poster pointed out, there will be a hiatus where the interface will pass no traffic while the ACL is rebuilt, i.e as soon as you type "no access-list 1624". If you're connected to the router via that interface that can be embarrassing. The way to get around this is like this (assuming the ACL is applied inbound on interface Fa0/1 - make the necessary changes):

no access-list 1625 ! or use any other number that's available for scratch space ! now make 1625 a duplicate of your new 1624 access-list 1625 permit 10.33.224.0 0.0.0.255 access-list 1625 permit 172.22.20.0 0.0.0.15

! replace 1624 on the interface interface fa0/1 access-group 1625 in

! rebuild 1624 no access-list 1624 access-list 1624 permit 10.33.224.0 0.0.0.255 access-list 1624 permit 172.22.20.0 0.0.0.15

! apply updated 1624 and get rid of 1625 interface fa0/1 access-group 1624 in

no access-list 1625

Sam

Like this:

router#sh access-lists Standard IP access list 1624 10 permit 10.33.224.0, wildcard bits 0.0.0.255 20 permit 172.22.20.0, wildcard bits 0.0.0.15 30 permit 10.160.224.0, wildcard bits 0.0.0.255 router# router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. router(config)#ip access-list standard 1624 router(config-std-nacl)#no 30 router(config-std-nacl)#end router# Aug 2 22:14:04.789 AEST: %SYS-5-CONFIG_I: Configured from console router#sh access-lists Standard IP access list 1624 10 permit 10.33.224.0, wildcard bits 0.0.0.255 20 permit 172.22.20.0, wildcard bits 0.0.0.15 router#

Just be aware that the "new" sequence number based ACL editor does not understand "remark" entries. No idea what it does with them, if you work it out let us know.

Not true - you can apply an empty access-list to an interface and it will have no affect on network traffic.

Once the first line of the access-list has been entered, the implicit deny takes effect at the end of the access-list, but only when there are access-list entries. If an access-list is emptied when applied to an interface, it can function without affecting network traffic until it has entries again. There are possibly some exceptions to this exception to the rule.

The recommendation previously posted of removing the access-group from the interface before modifying is a very good idea. Your changes could be entered in a such a sequence that would disconnect you before completing the change.

Proof of this was demonstrated and then included below.

Sam's recommendation was to create a new ACL and access-group that into control of the interface with the new contents (and he then did some cleanup work on the old ACL.) That procedure works fine and prevents any interruption of service (provided the new ACL doesn't have any bugs in it!).

If you just remove an access-group from an interface before modifying the access-list, you temporarily allow too much access to the interface, which is not a good thing. Especially if someone is DoS'ing you at the time.