Solved: Order of statements in a standard ACL

michael.martens · ‎06-09-2009

I am attempting to determine how entries in a standard ACL are actually added to a router's config.

I have read that the ACL statements are entered into the config in the order that they were typed, or that they are in a descending IP order, but I have tested this and see that it is not the case.

For example, if I create the following new ACL:

SPARE6509(config)#access-list 50 permit 170.50.11.3

SPARE6509(config)#access-list 50 permit 170.50.10.7

SPARE6509(config)#access-list 50 permit 184.5.1.149

SPARE6509(config)#access-list 50 permit 184.7.17.223

SPARE6509(config)#access-list 50 permit 170.50.26.83

SPARE6509(config)#access-list 50 deny any log

SPARE6509(config)#access-list 50 permit 170.50.68.0 0.0.0.255

SPARE6509(config)#exit

the order of the statements in the config are as follows, as per the show commands (they are in a different order than how they were entered - I cannot see any reason why they were added in this order):

SPARE6509#sho access-list 50

Standard IP access list 50

30 permit 184.5.1.149

40 permit 184.7.17.223

10 permit 170.50.11.3

20 permit 170.50.10.7

50 permit 170.50.26.83

60 deny any log

70 permit 170.50.68.0, wildcard bits 0.0.0.255

SPARE6509#show run (excerpt)

access-list 50 permit 184.5.1.149

access-list 50 permit 184.7.17.223

access-list 50 permit 170.50.11.3

access-list 50 permit 170.50.10.7

access-list 50 permit 170.50.26.83

access-list 50 deny any log

access-list 50 permit 170.50.68.0 0.0.0.255

This is a Catalyst 6509 w/Sup32, with IOS 12.2(18)SXF6.

Can anyone confirm how the lines of a standard ACL are added to the config?

Thanks.

Alvaro Garcia · ‎06-09-2009

I am sorry I did not noticed that you were using standard ACLs for host entries.

Looking more closely I found the exact bug and issue. There's no fix for it because this is expected behaviour.

CSCdu55701 standard access-list is not in order in show run

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCdu55701

The DDTS was junked due to the reason that it has been proved that it is a normal behavior. Host-specific ACL's are hashed for optimization hence the

show command display is in a different order than configured as what we experienced.

In your config the most of the routes that you're adding are host statements. You may use extended ACLs.

View solution in original post

Alvaro Garcia · ‎06-09-2009

Michael,

The ACL statements are applied as they were typed. In the show access-list output what you need to look is at the numbers in the begining of the lines. each line has its order number, the very first line starts with 10, the second line to be applied begins with 20, and so on.

The router (L3 switch) follows that order when a packet reach the interface; first compares the source and destination of the packet with the line 10, then with the 20, the 30, etc etc

michael.martens · ‎06-09-2009

Hi,

If this is true, then why did this ACL allow traffic to pass matching sequence number 140, which is after sequence number 110, a "deny any"?

If what you say is true, sequence number 110 should have been matched and dropped the traffic.

If you disregard the sequence numbers and follow the ACL as it appears in the config, then it works as expected - the matched statement is before the "deny all".

Therefore, I believe the ACL is matched according to how it appears in the config, and the sequence numbers only indicate the order in which the statements are entered.

Standard IP access list 90

130 permit 184.5.1.149

10 permit 184.12.17.241

20 permit 184.7.17.223

140 permit 170.50.141.111 (1416 matches)

30 permit 170.50.136.144 (32 matches)

40 permit 191.252.15.251

50 permit 170.50.208.186

60 permit 170.50.208.179 (496 matches)

70 permit 170.50.208.181

80 permit 170.50.208.182

90 permit 170.50.140.0, wildcard bits 0.0.0.255 (970906 matches)

100 permit 170.50.68.0, wildcard bits 0.0.0.255 (107086740 matches)

110 deny any log (4 matches)

120 permit 170.50.141.0, wildcard bits 0.0.0.255

Alvaro Garcia · ‎06-09-2009