cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
25803
Views
78
Helpful
21
Replies

Access-list wrong order

steuwissen
Beginner
Beginner

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.

21 Replies 21

Julio E. Moisa
VIP Mentor VIP Mentor
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. <<

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?

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. <<

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

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. <<

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.

Anyone else?

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.

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

This was exactly what I needed to fix my mis-numbered ACL, thanks!!

Drifterhawk
Beginner
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!

Peter Paluch
Hall of Fame Cisco Employee Hall of Fame Cisco Employee
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

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.

 

 

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

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers