Proper way to manipulate ACL's

Kevin Melton · ‎05-07-2007

Hello all

This is basically a general knowledge question. I have been working for some time now with ACL's on both routers and on PIX's.

My question is as follows, and it is a little bit old school. I was taught years ago that this was fundamentally the proper course of events to perform when making a change to an existing ACL applied to an interface (this would be on the routers).

Step.1 - We must take the ACL which is applied to the interface...ex. config-if# no acess-group 123 in

Step. - The ACL is then copied out of the config onto Notepad and saved.

Step. 3. The ACL is deleted off of the box.

Step. 4- Changes are made to the ACL on Notepad.

Step 5.- The new ACL is then copied and pasted back to the box in global config

Step. 6 - The new ACL is re-applied to the interface.

I have always followed this methodology when working with ACL's .. this prevents paranoia of taking down a network.

Can someone verify that this is the proper course of action. I came across a young CCIE the other day whom was certain that you did not have to do any of that to implement changes to an ACL while it is applied.

I simply want to know what is correct so I can do the correct action.

Thanks

Jon Marshall · ‎05-07-2007

Hi

There is a chance he was talking about an extended access-list where each line is numbered which means you can insert lines into the access-list without having to remove it and re-paste it in.

HTH

Jon

mohammedmahmoud · ‎05-07-2007

Hi,

Your steps are perfect, but as Jon has stated earlier most probably your mate was talking about named ACL which contains number for each entry, such that you can delete a certain entry or insert a certain entry between 2 other entries without needing to remove the ACL and reconfigure it.

Users can apply sequence numbers to permit or deny statements and also reorder, add, or remove such statements from a named IP access list. This feature makes revising IP access lists much easier. Prior to this feature, users could add access list entries to the end of an access list only; therefore needing to add statements anywhere except the end required reconfiguring the access list entirely.

example:

Router# show access-list 150

Extended IP access list 150

10 permit ip host 10.3.3.3 host 172.16.5.34

20 permit icmp any any

30 permit tcp any host 10.3.3.3

40 permit ip host 10.4.4.4 any

50 Dynamic test permit ip any any

60 permit ip host 172.16.2.2 host 10.3.3.12

70 permit ip host 10.3.3.3 any log

80 permit tcp host 10.3.3.3 host 10.1.2.2

90 permit ip host 10.3.3.3 any

100 permit ip any any

http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a008043105e.html

HTH, please do rate all helpful replies,

Mohammed Mahmoud.

glen.grant · ‎05-07-2007

All acl's under newer code are really named acl's and you can make changes to them on the fly by going into acl config mode , when in this mode you can make any changes you want to the running acl and even reorder entries if you want to . Believe the named and acl config mode became prevalent with like 12.2T train software. Named came in before that but the numbereing scheme came out with 12.2T I believe.

Richard Burts · ‎05-07-2007

Kevin

The responses talking about manipulating named access lists give good advice. But I believe that your question really asks about best practices and I would like to suggest my approach as being a slightly different best practice:

- copy the existing access list to notepad.

- change the access list identifier to create a different access list (works both for numbered and named access lists).

- make changes in notepad in the access list logic (add lines, or delete lines, or move lines, or whatever you need).

- paste from notepad to create a new access list.

- change the ip access-group on the interface to reference the new access list.

- after everything is tested out and stable, delete the old access list.

I believe that there are several advantages in this approach:

- if your new access list has a logic mistake (OOPS I did not really mean to have deny ip any any as the first line in the access list) it is easy to go back to the old/working version of the access list.

- there is never any time when the interface is not protected by an access list (if you remove the access list from the interface, delete the list, make changes, and re-create the list, and assign the access list to the interface then there is some period of time when the interface has no access list.

HTH

Rick

HTH

Rick