standard access-list sorting is out of order on 16.x

[hemmerling]

Is there a reason that under the 16.12.06 IOS on a 9300L that both the running config and show access-list command show extended ACLs just fine but display standard ACLs in an out-of-order jumbled mess?

Switch#show access-lists ACCESS_ACL
Standard IP access list ACCESS_ACL
    80 permit 192.168.0.7
    100 permit 192.168.0.11
    120 permit 192.168.0.12
    30 permit 10.10.10.20
    70 permit 192.168.1.14
    10 permit 10.10.10.123
    170 permit 192.168.0.151
    140 permit 192.168.0.153
    150 permit 192.168.0.155
    110 permit 192.168.1.11
    130 permit 192.168.1.12
    90 permit 192.168.1.177
    160 permit 192.168.54.144
    60 permit 192.168.0.14
    20 permit 10.10.23.131
    180 permit 192.168.1.151
    40 permit 10.10.140.186
    50 permit 10.10.140.187
    190 permit 192.168.8.0, wildcard bits 0.0.0.255
    200 permit 192.168.9.0, wildcard bits 0.0.0.255
    210 permit 192.168.18.0, wildcard bits 0.0.0.255
    220 deny   any log


Switch#show running-config
!
ip access-list standard ACCESS_ACL
 80 remark TACACS Servers
 80 permit 192.168.0.7
 100 remark RADIUS Servers
 100 permit 192.168.0.11
 120 permit 192.168.0.12
 30 remark Security Servers
 30 permit 10.10.10.20
 70 permit 192.168.1.14
 10 remark File Servers
 10 permit 10.10.10.123
 170 permit 192.168.0.151
 140 remark Network MGMT Servers
 140 permit 192.168.0.153
 150 permit 192.168.0.155
 110 permit 192.168.1.11
 130 permit 192.168.1.12
 90 permit 192.168.1.177
 160 permit 192.168.54.144
 60 remark Scanning Servers
 60 permit 192.168.0.14
 20 permit 10.10.23.131
 180 permit 192.168.1.151
 40 permit 10.10.140.186
 50 permit 10.10.140.187
 190 remark MGMT subnets
 190 permit 192.168.8.0 0.0.0.255
 200 permit 192.168.9.0 0.0.0.255
 210 permit 192.168.18.0 0.0.0.255
 220 deny   any log
!

At least the two match.
Again, extended ACLs look just fine with both commands and display in correct numerical order.
I have seen this in a few other 16 versions as well.  
I haven't tested to see if they are at least being processed in the right order, but I would certainly hope so.
The numbering at least matches the order in which they were written.

Just a bug? Hopefully it's fixed soon as it makes them really hard to read.

[balaji.bandi]

Looks like cosmetic bug, not operational impact, as you mentioned hard to read related to ACL with remarks, not that i aware of any bug reported, we are running 16.12.4 - never seen this issue.

[hemmerling]

Do you see the same thing in your 16.12.4 configs now that you know what to look for?

[balaji.bandi]

as i mentioned we have not seen the issue on our switches.

[paul driver]

Hello
Try the following:
ip access-list resequence ACCESS_ACL 10 10

[Richard Burts]

I believe that I have seen this behavior before in multiple versions of code where a standard access list rearranges the entries so that host specific entries come before network entries. I believe this is an intended behavior and not a bug.

[hemmerling]

That did the trick.
I've never seen that command before, thank you.
I wonder why is was doing it only on standard ACLs only. It was also a brand new switch and the ACL was being put it fresh.

Either way thank you again.

Edit:

I thought that it worked, and it did work in a way, but what it really did was reorder the list to the mixed up way it was showing me at first, now with the numbers in correct order.
It didn't keep the original order in which it was entered, it just fixed the numbers. 
So I wouldn't advise that anyone run that, it will fix the numbers displayed, but actually screw up the order, at least without it the order is at least correct, even if it's hard to read.
This is going to have to be fixed in software.

[Richard Burts]

There is a significant aspect of standard access lists that is not present in extended access lists. In standard access list some entires can be processed much more efficiently than other entries. Matching on a specific 32 bit IP address requires much less processing than matching where you must consider both the address and the prefix length. So Cisco made a decision: in processing a standard access list position the easier entries before the more difficult entries. It may be more difficult from a management perspective when the order of entries is not the same as the order in which they were entered. But the difference in performance is real. I do not expect that Cisco will change the software to make standard access list process in the order in which they were entered when that would result in increased effort to process the access list.

[paul driver]

Hello

---

@hemmerling wrote:

That did the trick.
I've never seen that command before, thank you.
I wonder why is was doing it only on standard ACLs only. It was also a brand new switch and the ACL was being put it fresh.

Either way thank you again.

Edit:

 it will fix the numbers displayed, but actually screw up the order, at least without it the order is at least correct, even if it's hard to read.

---

Well it shouldn't have done that, All it should have done was to re-order the acl numbering the ace entries should be exactly in the same order?

[paul driver]

Hello

@hemmerling 
Just like to add , Your comments got me curious so I went a head and tested this and it does it does exactly how I expected.

sh access-lists ACCESS_ACL

Standard IP access list ACCESS_ACL
30 permit 10.10.10.20
40 permit 10.10.140.186
50 permit 10.10.140.187
110 permit 192.168.1.11
100 permit 192.168.0.11
120 permit 192.168.0.12
130 permit 192.168.1.12
60 permit 192.168.0.14
70 permit 192.168.1.14
80 permit 192.168.0.7
10 permit 10.10.10.123
20 permit 10.10.23.131
160 permit 192.168.54.144
90 permit 192.168.1.177
140 permit 192.168.0.153
150 permit 192.168.0.155
180 permit 192.168.1.151
170 permit 192.168.0.151
190 permit 192.168.8.0, wildcard bits 0.0.0.255
200 permit 192.168.9.0, wildcard bits 0.0.0.255
210 permit 192.168.18.0, wildcard bits 0.0.0.255
220 deny any log

ip access-list resequence ACCESS_ACL 10 10

sh access-lists ACCESS_ACL
Standard IP access list ACCESS_ACL
10 permit 10.10.10.20
20 permit 10.10.140.186
30 permit 10.10.140.187
40 permit 192.168.1.11
50 permit 192.168.0.11
60 permit 192.168.0.12
70 permit 192.168.1.12
80 permit 192.168.0.14
90 permit 192.168.1.14
100 permit 192.168.0.7
110 permit 10.10.10.123
120 permit 10.10.23.131
130 permit 192.168.54.144
140 permit 192.168.1.177
150 permit 192.168.0.153
160 permit 192.168.0.155
170 permit 192.168.1.151
180 permit 192.168.0.151
190 permit 192.168.8.0, wildcard bits 0.0.0.255
200 permit 192.168.9.0, wildcard bits 0.0.0.255
210 permit 192.168.18.0, wildcard bits 0.0.0.255
220 deny any log

[Richard Burts]

Paul if I am understanding the original post correctly the concern is less about the fact that the sequence numbers are not in order and is more about the fact that the IP addresses in the access list are not in the order in which they were entered. (in the configuration all host specific addresses are before any subnet/network address). You are correct that the sequence numbers can be updated. But this does not address the concern that the access list entries are not in the order in which they were entered. I do not believe that there is any way to achieve what the original poster wants - which is to have access list entries in the order in which they were entered.

[hemmerling]

---

@paul driver wrote:

Hello

@hemmerling 
Just like to add , Your comments got me curious so I went a head and tested this and it does it does exactly how I expected.

sh access-lists ACCESS_ACL

Standard IP access list ACCESS_ACL
30 permit 10.10.10.20
40 permit 10.10.140.186
50 permit 10.10.140.187
110 permit 192.168.1.11
100 permit 192.168.0.11
120 permit 192.168.0.12
130 permit 192.168.1.12
60 permit 192.168.0.14
70 permit 192.168.1.14
80 permit 192.168.0.7
10 permit 10.10.10.123
20 permit 10.10.23.131
160 permit 192.168.54.144
90 permit 192.168.1.177
140 permit 192.168.0.153
150 permit 192.168.0.155
180 permit 192.168.1.151
170 permit 192.168.0.151
190 permit 192.168.8.0, wildcard bits 0.0.0.255
200 permit 192.168.9.0, wildcard bits 0.0.0.255
210 permit 192.168.18.0, wildcard bits 0.0.0.255
220 deny any log

ip access-list resequence ACCESS_ACL 10 10

sh access-lists ACCESS_ACL
Standard IP access list ACCESS_ACL
10 permit 10.10.10.20
20 permit 10.10.140.186
30 permit 10.10.140.187
40 permit 192.168.1.11
50 permit 192.168.0.11
60 permit 192.168.0.12
70 permit 192.168.1.12
80 permit 192.168.0.14
90 permit 192.168.1.14
100 permit 192.168.0.7
110 permit 10.10.10.123
120 permit 10.10.23.131
130 permit 192.168.54.144
140 permit 192.168.1.177
150 permit 192.168.0.153
160 permit 192.168.0.155
170 permit 192.168.1.151
180 permit 192.168.0.151
190 permit 192.168.8.0, wildcard bits 0.0.0.255
200 permit 192.168.9.0, wildcard bits 0.0.0.255
210 permit 192.168.18.0, wildcard bits 0.0.0.255
220 deny any log

---

Your example did exactly what I said, which is actually change the order that it's processed, I have no idea how it would treat a list that would allow a single IP then deny subnet of the group later, the order is important in certain situations and the resequencing command seems to be sorting by whatever weird mechanism it's sorting it in the show command. Without knowing the reasons it is doing it is there any way to tell how it's going to treat the order?

I would expect the resequence command to fix the order from in-between adds after the list was created, like 

10 permit 10.10.10.20
15 permit 10.10.140.183
16 permit 10.10.140.184
17 permit 10.10.140.185
20 permit 10.10.140.186
40 permit 10.10.140.187

and not change the actual order the entries were entered.

The example you post shows that what was once your first entry "10" has now become entry "110". I don't know what order it really was processing before, but I would guess that it is definitively processing it wrong after the command.

So I guess the questions are why is it showing standard lists out of order and not extended, and then by what logic is it doing the sorting?

I also tried to input the ACLs with specific numbers in the command and it still shows them in whatever weird order it wants.

I feel like Cisco needs to answer why so that we know they themselves know why and explain the logic in sorting this way, or acknowledge it as a bug and get it on it's way to being fixed.