12-06-2021 11:10 AM
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.
12-06-2021 11:48 AM
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.
12-06-2021 01:34 PM
Do you see the same thing in your 16.12.4 configs now that you know what to look for?
12-06-2021 01:36 PM
as i mentioned we have not seen the issue on our switches.
12-06-2021 10:27 PM - edited 12-06-2021 10:28 PM
Hello
Try the following:
ip access-list resequence ACCESS_ACL 10 10
12-07-2021 07:33 AM
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.
12-07-2021 07:35 AM - edited 12-07-2021 04:52 PM
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.
12-07-2021 10:54 PM
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.
12-08-2021 12:16 AM
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?
12-08-2021 12:22 AM - edited 12-08-2021 12:23 AM
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
12-08-2021 06:57 AM
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.
12-13-2021 09:38 AM - edited 12-13-2021 09:47 AM
@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 logip 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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide