Access-list wrong order

[steuwissen]

Hi all,

I'm trying to edit an access-list, but I experience some problems.

I'm making the following changes:

1. Delete access-list 1

2. Install the commands below

access-list 1 remark == s1
access-list 1 permit ip address 1
access-list 1 remark ==> Network Management <==
access-list 1 remark == s2
access-list 1 permit ip address 2
access-list 1 permit ip address 3
access-list 1 remark == s3
access-list 1 permit ip address 4
access-list 1 remark ==> Scanning Appliances <==
access-list 1 remark == s4
access-list 1 permit ip address 5
access-list 1 permit ip address 6
access-list 1 remark == s5
access-list 1 permit ip address 7
access-list 1 permit ip address 8
access-list 1 permit ip address 9
access-list 1 remark == s6
access-list 1 permit ip address 10
access-list 1 permit ip address 11
access-list 1 permit ip address 12
access-list 1 remark == s7
access-list 1 permit ip address 13
access-list 1 permit ip address 14
access-list 1 permit ip address 15
access-list 1 permit ip address 16
access-list 1 remark == s8
access-list 1 permit ip address 17
access-list 1 permit ip address 18
access-list 1 remark == s9
access-list 1 permit ip address 19
access-list 1 deny any log

3. After issueing show running-config | include access-list 1, I receive this:

access-list 1 remark == s1
access-list 1 permit ip address 1
access-list 1 remark ==> Network Management <==
access-list 1 remark == s2
access-list 1 permit ip address 2
access-list 1 permit ip address 3
access-list 1 remark ==> Scanning Appliances <==
access-list 1 remark == s3
access-list 1 permit ip address 5
access-list 1 remark == s4
access-list 1 permit ip address 4
access-list 1 permit ip address 6
access-list 1 remark == s5
access-list 1 permit ip address 7
access-list 1 permit ip address 8
access-list 1 permit ip address 9
access-list 1 remark == s6
access-list 1 permit ip address 10
access-list 1 permit ip address 11
access-list 1 permit ip address 12
access-list 1 remark == s7
access-list 1 permit ip address 13
access-list 1 permit ip address 14
access-list 1 permit ip address 15
access-list 1 permit ip address 16
access-list 1 remark == s8
access-list 1 permit ip address 17
access-list 1 permit ip address 18
access-list 1 remark == s9
access-list 1 permit ip address 19
access-list 1 deny any log

What is going on here? How can I fix this? I noticed more engineers experience difficulties with these issues.

[Peter Paluch]

Hello Daniel,

Thank you for your response.

I would like to clarify - this is not a defect. This is an expected behavior that has no functional impact on the ACL whose entries are reordered, aside from improving its efficiency. Most importantly, it does not change the results of the ACL evaluation - all traffic that was intended to be permitted or denied will be permitted or denied exactly as intended, even if IOS reorders the entries. This is an optimization technique in action.

The bug ID you referenced exists only because other customers were also confused by the behavior and had this behavior raised as a defect, but the behavior was clarified by the software engineering team as expected. There will be no fix because this is not a defect and there is nothing to repair, and the public notes to the CSCdu55701 say it clearly. Note that not every Cisco bug ID refers to a true bug: Often, a defect is opened for a behavior that is later clarified to be correct and expected, albeit sometimes admittedly unintuitive. CSCdu55701 is one of such cases that was considered to be a defect by the engineer who raised it, and was subsequently clarified as correct and expected behavior.

I have explained the logic behind the behavior in detail here:

https://community.cisco.com/t5/switching/access-list-wrong-order/m-p/3181371/highlight/true#M390769

Please feel welcome to ask further!

Best regards,
Peter

[daniel.silva@la.logicalis.com]

Thank you very much for the response, however, we must affirm that it is a defect. The problem is not only about how the show is observed, the problem is about administration. Cisco offers an organization system of the ACL to improve the user experience when reviewing the configuration, the problem is that after the user places the order in which he wants to show the information, the IOS reorders it. It can be called an edible problem, but it affects the experience of many users, and a product must not only be functional in operation but also functional in its administration, revision and maintenance. For the client, this is reflected in 400 devices that he manages where he can not reference what he sees. It certainly does not affect the operation but the administration of the platform.

[Joseph W. Doherty]

As Peter notes, the ACL functions correctly, but when the ACL is displayed in a different sequence than entered/numbered, it does seem wrong. (I know it had me scratching my head, first time I encountered it.)

Although logically a "re-sequenced" ACL is correct, if you're trying to sequence ACEs in an expected match order, and that cannot be obtained, one might consider that a bug unless by logically merging some ACEs the overall ACL execution is improved (which is what Cisco is doing).

For example:

access list 1 permit 1.1.1.0
access list 1 permit 1.1.1.1
access list 1 permit 1.1.1.2
access list 1 permit 1.1.1.3

vs.

access list 1 permit 1.1.1.0 0.0.0.3

The latter aggregate ACE, if done as one physical operation would be more efficient than doing the four separate ACEs, even if the first ACE, of the four, is matched 99.9999% of the time. I.e. unless the first of four ACEs is matched 100% of the time, the aggregate ACE will be more efficient.

[Peter Paluch]

Hi Joe, hi Daniel,

Joe, thank you for stepping in! It's been quite a while. How are you?

Gentlemen, I can see your point.

In my personal opinion (no claims about it being representative), we are debating the level of management comfort here. You create an ACL using entries in a particular order, and after you enter it into configuration, IOS will - with the best intentions - reorder the ACL to maximize its efficiency while not changing its overall results. We now debate how inconvenient or disruptive to management purposes it is to maintain this reordered ACL. Would you agree?

The CSCdu55701 was filed in 2005 (yes, 13 years ago), and from a purely practical point of view, it is clear that after all that time the behavior is not going to change. While there is a chance to ask TAC to raise a feature enhancement request to continue displaying the standard ACLs in the order they have been entered, regardless of their internal organization order, I am afraid that the folks would have implemented it already if there was enough internal push for it - and there likely wasn't. Giving it another try with a solid business case, though, is always worth a try.

However, there is a quick workaround available: Use extended ACLs wherever possible since they are not subject to this kind of optimization, and every standard ACL can be rewritten as an extended ACL.

Best regards,
Peter

[Joseph W. Doherty]

Peter, yes I believe the debate does boil down to config management. Personally, I've learned to live with it, although it would have been nice to at least have an option to see config as it was entered. (Another ACL quirk, I recall, is how ACL remarks can get shuffled too, such that when you read an edited ACL, they don't make sense as their position has been altered.) Of course, similar debates can be had about how Cisco decides/changes what are "defaults" commands (and suppressed from a normal show config/run). (BTW, there's one port command I came across that when you changed it to its non-default and then back to default, the non-default value then appeared. [I was scripting, so I had to deal with default command both being hidden and not.] The only way to get the command to disappear was to default the port, and reconfigure the port w/o the non-default command.)

Besides the ACL reordering - years ago I also noted reordering of OSPF network statements - again, a bit of a surprise when I first saw an IOS doing it. Like this ACL "issue", functionally the reordered OSPF network statements were correct.

Your 100% right, without a large demand for change, this is unlikely to be changed, but Cisco doesn't know, unless you do file a feature request.

BTW, the last company I worked for was large enough customer of Cisco's, that if we really demanded a feature, we generally got it. Of course, we would have to convince our own company's management for the need before they would demand it from Cisco, so it was a rare event. In the event we didn't get the feature, or obtain it within a timely manner, well let's say Cisco was unhappy when within two years half our old equipment was replaced by brand "J". Amazing how much more interested/cooperative Cisco was in our feature requirements after that.

So, when you make a feature request, might not hurt to add "hey, Brand X has/does it". ;)

[milan.kulik]

Hi Peter,

as usually, Cisco can say "It's not a bug, it's a feature!"

But it's a pretty confusing feature...

Let me give you an example on a switch running an old IOS 12.2(55)SE10:

sw0(config)#access-l 66 permit 10.10.10.1
sw0(config)#access-l 66 permit 10.10.10.2
sw0(config)#access-l 66 permit 10.10.10.3
sw0(config)#^Z
sw04#sh access-l 66
Standard IP access list 66
20 permit 10.10.10.2
30 permit 10.10.10.3
10 permit 10.10.10.1
sw04#wr
Building configuration...
[OK]
sw04#relo
Proceed with reload? [confirm]

sw04#sh access-l 66
Standard IP access list 66
10 permit 10.10.10.2
20 permit 10.10.10.3
30 permit 10.10.10.1
sw04#

So you can see the sequence numbers in the show access-list ... command output have been changed after the switch reboot.

You may say it's just a cosmetic change in the show command output.

But some newer switches (3850 running IOS XE 16.12.04, e.g.) are using following syntax within their config:

ip access-list standard 66
10 permit 10.10.10.2

So the sequence number is also changed inside the config after the switch reboot!

Which brings lots of issues if you are running some automatic scripts checking the configuration accuracy...

So I guess the only workaround is to issue

ip access-list resequence ... 10 10

command after the access-list was entered.

Which should give the ACL entries the same sequence numbers as a potential device reboot.

I was also considering using extended ACLs instead of standard ones.

But it's not always possible. Some IOS versions don't support extended ACLs to restrict SNMPv3 user access, e.g.

Best regards,

Milan

[CiscoGuru4Life]

Thank you, Peter Paluch for this answer. This should be marked Solved with this as the answer.