I have extended access-list BLOCK, where each entire has its own special number. EX:
1038047 deny ip any host 192.168.38.47
1038048 deny ip any host 192.168.38.48
1038049 deny ip any host 192.168.38.49
1038069 deny ip any host 192.168.38.69
1038077 deny ip any host 192.168.38.77
1038080 deny ip any host 192.168.38.80
Formula is 1 000 000 + 1 000*3_octet+4_octet , and the last one is
3 000 000 permit ip any any
But after reboot they become:
2020 deny ip any host 192.168.38.27
2030 deny ip any host 192.168.38.32
2040 deny ip any host 192.168.38.37
2050 deny ip any host 192.168.38.38
2060 deny ip any host 192.168.38.43
It is bad. Is there any command to prohibit cisco resequencing entires?
I might be wrong but I don't think you can use ACL numbers that high, the actual list numbers are defined by their type, i.e IP ACLs must be between certain ranges, extended IP another range etc. (see HERE for details).
I think that you just can't because the numbers are not stored in the configuration file. This is just intended to be used to be able to insert a line where you want in the ACL. And for Chopper3 (I can't yet add comment), here is talking about ACL line ordering, not ACL numbers as describe in the link you given.
According to Cisco, the maximum valid sequence number in an IOS access list is 2147483647. Can you confirm what platform/code version you are running?
In terms of persistence across reboots, as mentioned by Jeb, sequence numbers are not stored in the configuration file. (do a 'show startup-config' to verify this) I don't think this is a bug, simply a known limitation.
What is the requirement for having your specific sequence numbers? In newer versions of IOS, there is always an implicit 'deny any any' at the end of any non-empty access list. Unless you are inputting a 'deny any log' so that you can log unauthorised traffic to syslog, you can simply append to your existing ACL, and the implicit deny will always be at the end?
EDIT:
I don't believe there's a way to change the implicit deny behaviour. One solution might be to store your configuration (including sequence numbers) remotely, and then to delete and recreate the entire ACL when you make changes? Unfortunately, Cisco's ACL implementation is designed around the, 'permit what you need, deny the rest' approach.
One way around the issue, assuming you are running a recent enough code version, might be to use Object Group-Based ACLs. You could then have a policy as follows.
Note: hand cut config; ensure you test before you deploy!
This would then allow you to modify the list of denied hosts independently of the 'BLOCK' ACL, and would ensure that your 'permit' statement was always the last entry.