Hi Milan,
Sequence numbers are indeed not supported if you define a numbered access list. With both standard and extended numbered ACLs, however, it is possible to do a trick: if you refer to them as named ACLs (use their number as their name), you actually are able to use the sequence numbers.
For example:
R1(config)# do show run | i access-list
access-list 1 deny 192.0.2.1
access-list 1 permit any
access-list 100 deny ip host 192.0.2.1 any
access-list 100 permit ip any any
R1(config)# do show ip access-l
Standard IP access list 1
10 deny 192.0.2.1
20 permit any
Extended IP access list 100
10 deny ip host 192.0.2.1 any
20 permit ip any any
R1(config)# ip access-list standard 1
R1(config-std-nacl)# 15 deny 192.0.2.15
R1(config-std-nacl)# exit
R1(config)# do show access-list
Standard IP access list 1
10 deny 192.0.2.1
15 deny 192.0.2.15
20 permit any
Extended IP access list 100
10 deny ip host 192.0.2.1 any
20 permit ip any any
R1(config)# ip access-list extended 100
R1(config-ext-nacl)# 15 deny ip host 192.0.2.15 any
R1(config-ext-nacl)# exit
R1(config)# do show access-l
Standard IP access list 1
10 deny 192.0.2.1
15 deny 192.0.2.15
20 permit any
Extended IP access list 100
10 deny ip host 192.0.2.1 any
15 deny ip host 192.0.2.15 any
20 permit ip any any
The router is even smart enough to disallow to refer to a named ACL whose name is a number of the opposite type than stated on the command line:
R1(config)# ip access-list standard 101
%
% Invalid access list name.
R1(config)# ip access-list extended 2
%
% Invalid access list name.
What Collin may have in mind, though, is that host entries in standard ACLs are reorganized to a different order than entered:
R1(config)# ip access-list standard Test
R1(config-std-nacl)# permit 10.0.0.1
R1(config-std-nacl)# deny 10.0.0.2
R1(config-std-nacl)# permit 10.0.0.3
R1(config-std-nacl)# deny 10.0.0.4
R1(config-std-nacl)# permit 10.0.0.5
R1(config-std-nacl)# deny 10.0.0.6
R1(config-std-nacl)# permit 10.0.0.7
R1(config-std-nacl)# deny 10.0.0.8
R1(config-std-nacl)# permit any
R1(config-std-nacl)#exit
R1(config)# do show access-list Test
Standard IP access list Test
80 deny 10.0.0.8
20 deny 10.0.0.2
30 permit 10.0.0.3
10 permit 10.0.0.1
60 deny 10.0.0.6
70 permit 10.0.0.7
40 deny 10.0.0.4
50 permit 10.0.0.5
90 permit any
R1(config)# do show run | section Test
ip access-list standard Test
deny 10.0.0.8
deny 10.0.0.2
permit 10.0.0.3
permit 10.0.0.1
deny 10.0.0.6
permit 10.0.0.7
deny 10.0.0.4
permit 10.0.0.5
permit any
This reordering happens only with standard ACLs and is a result of indexing the host entries in the ACL into a hash table (the hash function being XOR of individual octets of the IP address in the host entry) for faster access. When printing out the ACL, first the host items are printed out in the order they are stored in the hashing table, and only then the remaining entries that use wildcards. Wildcard entries are not reordered.
The funny thing is that the ACL is actually even stored in the configuration in the reordered form, and thus evaluated in a reordered form, which can be confusing. However, you may have noticed that the router will prohibit you from entering a host ACL after entering a wildcard ACL that also matches the IP address in a wildcard entry:
R1(config)# ip access-list standard Test2
R1(config-std-nacl)# permit 10.0.1.0 0.0.0.255
R1(config-std-nacl)# deny 10.0.1.1
% Access rule can't be configured at higher sequence num as it is part of the existing rule at sequence num 10
R1(config-std-nacl)#
Why is this? Obviously, a host entry can either select the same action for a packet that would be taken by a more general wildcard entry (in which case it is not necessary for the host entry to be entered at all), or it can override the action that would be chosen by a more general wildcard entry. In this second case, it is necessary for this host entry to be placed in the ACL first, otherwise it would never be reached. Ordering of host entries themselves can be arbitrary, as they do not influence each other. This leads us to a general logic in standard ACLs - it is required to put all host entries first, and wildcard entries last. Now it is completely logical to visit all host entries first (indexed by a hash for rapid access), and then visit the wildcard entries.
Quite a long post... sorry for that. Hopefully, we've resolved some of the doubts.
Best regards,
Peter
