cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
13552
Views
58
Helpful
19
Replies
Highlighted
Beginner

Access-list wrong order

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.

19 REPLIES 19
Highlighted
VIP Mentor

Hi

If you remove a line of a numbered ACL, all the ACL will be removed, in order to avoid it you can use the following sintaxis:

ip access-list standard

*It will be treated as a named ACL without lose its structure (numbered), I mean you will see always the ACL as numbered, it is used to modify an ACL only.

then modify the ACL using sequence number, so you will be able to move up or down, or insert a new line before or after other line, or remove an ACL without affect the entire ACL, example

6 permit host 10.10.10.10   (sequence number 6)

no 6 permit host 10.10.10.10   (removing sequence 6)

Also you can use the following command to verify the current sequence into the ACL:

show access-list 1

Please rate the comment if it is useful or answered the question.

:-)




>> Marcar como útil o contestado, si la respuesta resolvió la duda, esto ayuda a futuras consultas de otros miembros de la comunidad. <<
Highlighted

Hello Julio,

Thanks for your reply.

I have tried your solution; unfourtunately it does not work completely. I noticed the sequence numbers are there when executing show access-list 1. But the out of order issue is still present when executing the show run command. There are not seq. numbers available for the remarks, could that be a problem?

Highlighted

Hi

Yes, through show run the sequence will not be displayed just using show access-list, I recommend insert sequence between number in multiples, for example insert the new line between 10 and 15 (11,12,13,14) or remove first the line what you want to move and create it again with the sequence, for example:

no 10 permit host 10.1.1.1
4 permit host 10.1.1.1

Please keep me posted. 

:-)




>> Marcar como útil o contestado, si la respuesta resolvió la duda, esto ayuda a futuras consultas de otros miembros de la comunidad. <<
Highlighted

Please have a look; after removing the standard access-list 1, I execute these commands:

remark s1
10 permit IP ADDRESS 1
remark s2
remark s3
20 permit IP ADDRESS 2
30 permit IP ADDRESS 3
remark s4
remark s5
40 permit IP ADDRESS 4
50 permit IP ADDRESS 5
remark s6
60 permit IP ADDRESS 6
remark s7
70 permit IP ADDRESS 7
80 permit IP ADDRESS 8
90 permit IP ADDRESS 9
remark s8
110 permit IP ADDRESS 10
120 permit IP ADDRESS 11
remark s9
130 permit IP ADDRESS 12
140 permit IP ADDRESS 13
150 permit IP ADDRESS 14
160 permit IP ADDRESS 15
remark s10
170 permit IP ADDRESS 16
180 permit IP ADDRESS 17
remark s11
190 permit IP ADDRESS 18
200 deny any log

show ip access list 1

10 permit 10.25.5.28
20 permit 10.61.3.10
30 permit 172.16.10.251
40 permit 10.18.240.177
60 permit 10.18.35.96
50 permit 10.18.241.139
70 permit 10.18.240.139
80 permit 172.16.10.200
90 permit 172.16.10.201
100 permit 10.18.240.100 (33 matches)
110 permit 10.18.241.101
120 permit 10.18.241.100
130 permit 10.18.240.101 (142 matches)
140 permit 172.16.10.10
150 permit 172.16.10.11
160 permit 10.18.241.51
170 permit 10.18.240.50
180 permit 10.18.241.50
190 permit 10.18.240.51
200 deny any log

sh run 

same problem as first..

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

Highlighted

Hi

Please check this link:

IP Access List Entry Sequence Numbering

Benefits

The ability to apply sequence numbers to IP access list entries simplifies access list changes. Prior to the IP Access List Entry Sequence Numbering feature, there was no way to specify the position of an entry within an access list. If a user wanted to insert an entry (statement) in the middle of an existing list, all of the entries after the desired position had to be removed, then the new entry was added, and then all the removed entries had to be reentered. This method was cumbersome and error prone.

This feature allows users to add sequence numbers to access list entries and resequence them. When a user adds a new entry, the user chooses the sequence number so that it is in a desired position in the access list. If necessary, entries currently in the access list can be resequenced to create room to insert the new entry.

Sequence Numbering Behavior

For backward compatibility with previous releases, if entries with no sequence numbers are applied, the first entry is assigned a sequence number of 10, and successive entries are incremented by 10. The maximum sequence number is 2147483647. If the generated sequence number exceeds this maximum number, the following message is displayed:

	Exceeded maximum sequence number.

If the user enters an entry without a sequence number, it is assigned a sequence number that is 10 greater than the last sequence number in that access list and is placed at the end of the list.

If the user enters an entry that matches an already existing entry (except for the sequence number), then no changes are made.

If the user enters a sequence number that is already present, the following error message is generated:

	Duplicate sequence number.

If a new access list is entered from global configuration mode, then sequence numbers for that access list are generated automatically.

Distributed support is provided so that the sequence numbers of entries in the Route Processor (RP) and line card (LC) are in synchronization at all times.

Sequence numbers are not nvgened. That is, the sequence numbers themselves are not saved. In the event that the system is reloaded, the configured sequence numbers revert to the default sequence starting number and increment. The function is provided for backward compatibility with software releases that do not support sequence numbering.

This feature works with named standard and extended IP access lists. Because the name of an access list can be designated as a number, numbers are acceptable.

http://www.cisco.com/c/en/us/td/docs/ios/12_2s/feature/guide/fsaclseq.html#wp1042954

Hope it is useful

:-)




>> Marcar como útil o contestado, si la respuesta resolvió la duda, esto ayuda a futuras consultas de otros miembros de la comunidad. <<
Highlighted

Unfortunately it is not. I am removing the entire access-list and put all the seq. numbers in order, but the result from show run is different. 

Please note the following commands are in order with seq. numbers.

remark s1
10 permit IP ADDRESS 1
remark s2
remark s3
20 permit IP ADDRESS 2
30 permit IP ADDRESS 3
remark s4
remark s5
40 permit IP ADDRESS 4
50 permit IP ADDRESS 5
remark s6
60 permit IP ADDRESS 6

The result is very different:

access-list 1 remark s1
access-list 1 permit ip address 1
access-list 1 remark s2
access-list 1 remark s3
access-list 1 permit ip address 2
access-list 1 permit ip address 3
access-list 1 remark s4
access-list 1 remark s5
access-list 1 permit ip address 5
access-list 1 s6
access-list 1 permit ip address 4
access-list 1 permit ip address 6

ip address 4 is out of order compared with the seq. numbers, same for ip address 5.

Highlighted

Anyone else?

Highlighted

I found out, by accident, that entering ACL lines with sequence numbers following a standard I've always worked with (where I start with 10 and then increment by 10), leads to the sequence numbers not appearing in the show running-config output.  That happens to match the default sequencing when entered without sequence numbers.

Yet, if I stray from the default, the sequence numbers appear.  I cannot figure out why this is a good thing.

Highlighted

In addition to Julio's comments, the command below can be used to give a certain starting sequence number with a desired incremental value between the sequence numbers. This command is non-disruptive.

ip access-list resequence 1 10 10

1 - number of access-list

10 - Sequence number will begin at this number. You can choose any value between 1-2147483647

10 - Incremental value between sequence numbers. You can choose any value between 1-2147483647

Highlighted
Beginner

I believe I'm having the same issue as Steuwissen. Even though the sequence order is correct, it is still not displaying correctly when looking at the running-config and 'show access-list standard [name]'.

 

 

Spoiler

Running-Config

ip access-list standard Network_ACL
permit 10.1.5.1
remark Remark 5
permit 10.1.5.2
remark Remark 2
permit 10.1.2.1
permit 10.1.5.3
remark Remark 3
permit 10.1.3.1
remark Remark 4
permit 10.1.4.1
remark Remark 5
permit 10.1.5.1

Spoiler
show ip access-list Network_ACL
51 permit 10.1.5.2
50 permit 10.1.5.1
10 permit 10.1.1.1
52 permit 10.1.5.3
20 permit 10.1.2.1
30 permit 10.1.3.1
40 permit 10.1.4.1

What it is supposed to look like is this:

Spoiler
ip access-list standard Network_ACL
remark Remark 1
permit 10.1.1.1
remark Remark 2
permit 10.1.2.1
remark Remark 3
permit 10.1.3.1
remark Remark 4
permit 10.1.4.1
remark Remark 5
permit 10.1.5.1
permit 10.1.5.2
permit 10.1.5.3

show ip access-list Network_ACL
10 permit 10.1.1.1
20 permit 10.1.2.1
30 permit 10.1.3.1
40 permit 10.1.4.1
50 permit 10.1.5.1
51 permit 10.1.5.2
52 permit 10.1.5.3

The ACL works but it makes it difficult visually when it doesn't line up like it is supposed to. Is there any reason why or is it just what it is?

 

Thank you!

Highlighted
Hall of Fame Cisco Employee

Dear friends,

I believe I have the answer. Bear with me as I explain.

In a standard ACL, the entries (we call them Access Control Entries, ACEs) are of two types: fastitem and fasthash. The fasthash entries are those whose wildcard mask is 0.0.0.0, in other words, fasthash entries are host entries. The fastitem entries are ACEs that have a wildcard mask different from 0.0.0.0; you could call them network entries, as they are commonly used to describe entire ranges of addresses.

For efficiency reasons, fasthash entries are internally stored in a hash table. This allows them to be searched very quickly when searching for a match. However, due to hashing, their order will appear to be different from the order in which they have been entered when printing out the ACL.

Consider the following ACL:

Router(config)#access-list 1 permit 10.10.10.1
Router(config)#access-list 1 permit 10.10.10.2
Router(config)#access-list 1 permit 10.10.10.3
Router(config)#access-list 1 permit 10.10.10.4
Router(config)#access-list 1 permit 10.10.10.5
Router(config)#access-list 1 permit 10.10.10.6
Router(config)#access-list 1 permit 10.10.10.7
Router(config)#access-list 1 permit 10.10.10.8
Router(config)#do show access-list 1
Standard IP access list 1
    80 permit 10.10.10.8
    20 permit 10.10.10.2
    30 permit 10.10.10.3
    10 permit 10.10.10.1
    60 permit 10.10.10.6
    70 permit 10.10.10.7
    40 permit 10.10.10.4
    50 permit 10.10.10.5
Router(config)#do show run | i access-list
access-list 1 permit 10.10.10.8
access-list 1 permit 10.10.10.2
access-list 1 permit 10.10.10.3
access-list 1 permit 10.10.10.1
access-list 1 permit 10.10.10.6
access-list 1 permit 10.10.10.7
access-list 1 permit 10.10.10.4
access-list 1 permit 10.10.10.5

Obviously, it has been reordered from the order I have used when creating it. The ordering corresponds to the internal ordering of the hash table in which these fasthash items have been indexed, and as it turns out, the hash function that determines the ordering is a simple XOR of all four octets of the IP address.

I've concocted a quick and dirty Python script XORing the four octets of an IP address together:

#!/usr/bin/python

while True:
   IP=raw_input('Enter IP to be hashed: ').split(".")
   print "Hashing index is: ",int(IP[0])^int(IP[1])^int(IP[2])^int(IP[3])
   print

And this is what it tells me when I enter the IP addresses in the order they show up in the outputs above:

Enter IP to be hashed: 10.10.10.8
Hashing index is:  2

Enter IP to be hashed: 10.10.10.2
Hashing index is:  8

Enter IP to be hashed: 10.10.10.3
Hashing index is:  9

Enter IP to be hashed: 10.10.10.1
Hashing index is:  11

Enter IP to be hashed: 10.10.10.6
Hashing index is:  12

Enter IP to be hashed: 10.10.10.7
Hashing index is:  13

Enter IP to be hashed: 10.10.10.4
Hashing index is:  14

Enter IP to be hashed: 10.10.10.5
Hashing index is:  15

Note that the hashing index computed here creates a monotonous increasing sequence that perfectly corresponds to the ordering of entries as displayed in the show outputs above.

It is important to realize here that even though the fasthash entries are reordered, it has no impact on the logic of the access list. This is because the fasthash entries are entries that match the complete address, they do not overlap, and so their mutual order does not matter.

When fasthash (host entries) and fastitem (network entries) are combined, the CLI will not allow entering a host ACE placed after an existing network ACE that would also match the host address in the host ACE:

Router(config)#access-list 2 permit 10.0.0.0 0.255.255.255
Router(config)#access-list 2 deny 10.10.10.10
% Access rule can't be configured at higher sequence num as it is part of the existing rule at sequence num 10

Why is this? Obviously, a host ACE can either select the same action (permit or deny) for a packet that would be taken by a more general network ACE later, in which case it is not necessary for that host ACE to be entered at all but not prohibited at the same time, or it can override that action. In the second case, it is necessary for this host ACE to be placed in the ACL first, before the network ACE, otherwise it will never be reached. This leads us to a general logic in standard ACLs - it only makes sense to put all host (fasthash) ACEs first, and network (fastitem) ACEs last. Of course, the network ACEs can not be easily optimized in their ordering anymore because their potential overlaps may be very complicated. For network ACEs, their ordering as configured must be preserved.

So a standard ACL indeed consists of the set of fasthash host ACEs sorted by their hashing values and evaluated first (and also printed out first), and the fastitem network ACEs evaluated after the host ACEs in the order they have been entered:

Router(config)#access-list 3 permit 10.15.0.0 0.0.255.255
Router(config)#access-list 3 deny 10.14.0.0 0.0.255.255
Router(config)#access-list 3 permit 10.13.0.0 0.0.255.255
Router(config)#access-list 3 deny 10.12.0.0 0.0.255.255
Router(config)#access-list 3 permit 10.11.0.0 0.0.255.255
Router(config)#access-list 3 deny 10.10.0.0 0.0.255.255
Router(config)#access-list 3 permit 10.0.0.1
Router(config)#access-list 3 permit 10.0.0.2
Router(config)#access-list 3 permit 10.0.0.3
Router(config)#access-list 3 permit 10.0.0.4
Router(config)#access-list 3 deny 10.0.0.5
Router(config)#access-list 3 deny 10.0.0.6
Router(config)#access-list 3 deny 10.0.0.7
Router(config)#access-list 3 deny 10.0.0.8
Router(config)#
Router(config)#do show access-list 3
Standard IP access list 3
    140 deny   10.0.0.8
    80 permit 10.0.0.2
    90 permit 10.0.0.3
    70 permit 10.0.0.1
    120 deny   10.0.0.6
    130 deny   10.0.0.7
    100 permit 10.0.0.4
    110 deny   10.0.0.5
    10 permit 10.15.0.0, wildcard bits 0.0.255.255
    20 deny   10.14.0.0, wildcard bits 0.0.255.255
    30 permit 10.13.0.0, wildcard bits 0.0.255.255
    40 deny   10.12.0.0, wildcard bits 0.0.255.255
    50 permit 10.11.0.0, wildcard bits 0.0.255.255
    60 deny   10.10.0.0, wildcard bits 0.0.255.255
Router(config)#do show run | i access-list 3
access-list 3 deny   10.0.0.8
access-list 3 permit 10.0.0.2
access-list 3 permit 10.0.0.3
access-list 3 permit 10.0.0.1
access-list 3 deny   10.0.0.6
access-list 3 deny   10.0.0.7
access-list 3 permit 10.0.0.4
access-list 3 deny   10.0.0.5
access-list 3 permit 10.15.0.0 0.0.255.255
access-list 3 deny   10.14.0.0 0.0.255.255
access-list 3 permit 10.13.0.0 0.0.255.255
access-list 3 deny   10.12.0.0 0.0.255.255
access-list 3 permit 10.11.0.0 0.0.255.255
access-list 3 deny   10.10.0.0 0.0.255.255

Once again, this reordering has no impact on the overall logic of the ACL and does not change the resulting fate of the packets.

I hope this helps - and my sincere thank you if you got this far in reading this lengthy post :)

Best regards,
Peter

Highlighted

Thanks to Peter Paluch for the explanation.

 

I'm sure this is a feature that benefits someone. Sure, we want our boxes to perform quickly, but we are humans. We also need to be able to read and inspect our configurations. I trust that IOS handles the permit and deny order properly, but we like our IPs in a particular order for auditing by tools such as SolarWinds NCM.

 

This behavior of IOS reordering rules to suit itself is not what most people expect or want. To make matters worse, there are other buggy behaviors still lurking in the code.

 

We have had standard access-lists for years, and could re-do them by something like:

 

no access-list 1

access-list 1 permit 1.2.1.2

access-list 1 permit 2.1.2.1

access-list 1 deny any log

 

We could then use text tools to compare the script that creates the ACL with what the config shows. That no longer works.

 

Recently, we set about to add remarks to our standard ACLs.

 

no access-list 1

access-list 1 remark Only allow friendly bogons who have security clearance.

access-list 1 permit 1.2.1.2

access-list 1 permit 2.1.2.1

access-list 1 deny any log

 

What we see is something like:

 

access-list 1 permit 1.2.1.2

access-list 1 permit 2.1.2.1

access-list 1 remark Only allow friendly bogons who have security clearance.

access-list 1 deny any log

 

We've seen this on  3850 Denali 16.3.5b, plus we've seen it on 3750s running 12.2 series code.

 

We've also seen long access-lists replaced by short ones by 1st doing the "no access-list 1", and followed by the short list of new ACEs - most of which existed in the old ACL. The result was a mix of what should have been deleted and the new ACEs - clearly a bug in "no access-list" code.

 

So now I'm increasing our company's cost of ownership by researching this, and probably will open a case with TAC.

 

 

Highlighted

Greetings to all, I reply late to this topic, this week I saw the answer to this problem and it is not a configuration or how we put the lists, do not keep trying to find a reasonable solution because Cisco already explained it. "It's not a configuration problem, it's a BUG" and they do not plan to fix it. The problem is random, it does not always happen but it happens.

 

You can check it yourself: BUG ID CSCdu55701 which applies for all IOS platforms. Standard access-list are not shown in the order they were introduced in the

 

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCdu55701/?reffering_site=dumpcr

Highlighted

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

Content for Community-Ad