Normalizing ACLs to Support Automated Changes

Although I look forward to network fabric management seeing broad deployment, the fact is that many networks (and especially enterprise LAN/WAN) will be managed with traditional methods for some time yet. Inconsistencies in device configurations can present a barrier to some types of automation. In this article, we’ll explore that very challenge and a resolution I came up with to handle it.

Not long ago, I was trying to automate an ACL line insertion task with a popular network configuration push tool that basically does CLI interaction with something like Expect. I needed to push a similar change to about 20 devices with minimal effort. Unfortunately, when looking at the ACL on several sample devices out of the target device pool, I saw things like this:
R1(config)#do sh access-list NAT
Extended IP access list NAT
14 deny ip
20 deny ip
25 permit ip
30 permit ip any
43 permit ip any
You can see from the line numbers that various line item inserts have been done over time. This was the case with several of the devices, making me less than confident that simply inserting a specific line number ACE into the ACL would work reliably. For example, given the ACL above, trying to insert a line with entry number 25 (which worked on several of the devices) would result in this:
R1(config)#ip access-list ext NAT
R1(config-ext-nacl)# 25 deny ip
% Duplicate sequence number
Unlike the Cisco ASA, where inserting a duplicate line number has a true “insert” effect pushing the rest of the ACL down, on IOS the insert fails and I’m left to either go look at each unit’s ACL and pick a device-specific number I can use, or try the config push over and over guessing numbers.
Luckily, IOS has a feature to relabel the ACEs in an ACL using whatever starting index and increment value you wish. By using this “resequence” command at the start of my script, I was able to normalize each ACL to a predictable set of sequence numbers and do my insert in the right spot using a sequence number that I now knew couldn’t conflict. I then had my script run the resequence again to normalize the ACL following the insert, so that next time around I’d be less likely to his this issue.
!--- This command renumbers the ACEs in Access List "NAT", starting at entry number 10 and incrementing each line number by 10.
R1(config)#ip access-list resequence NAT 10 10
R1(config)#do sh access-list NAT
Extended IP access list NAT
10 deny ip
20 deny ip
30 permit ip
40 permit ip any
50 permit ip any
You can see from the above output that the resequence command normalized my ACE numbering. Now, I can make my tweaks using line numbers that won’t conflict with the existing entries:
R1(config)#ip access-list ext NAT
R1(config-ext-nacl)# 25 deny ip
R1(config-ext-nacl)#ip access-list resequence NAT 10 10
!--- Now we check the ACL again to make sure our new ACE landed in the right spot:
R1#show access-list NAT
Extended IP access list NAT
10 deny ip
20 deny ip
30 deny ip
40 permit ip
50 permit ip any
60 permit ip any
This worked perfectly, and it occurred to me that it’s probably not a bad idea at all to add this normalization process to just about any automated ACL tweak, just to ensure I don’t hit an unexpected sequence number conflict. This experience is a good reminder that in all forms of network automation, we make assumptions about the consistency of all our device configurations. It’s important to validate these assumptions and correct inconsistencies if we want network automation to work. Even in a future world where we’re a less bound by CLI behaviors, what if one of the devices had a different ACL name, or the NAT was configured with a route-map instead of a simple ACL? Inconsistencies are a real enemy for automation, so we should always be on the lookout for them, testing scripts in a non-invasive manner to validate what they do, correcting inconsistencies in our environments before they pose automation problems, and monitoring/auditing configurations to identify when inconsistencies creep in.
Tagged , , ,

One thought on “Normalizing ACLs to Support Automated Changes

  1. Mike says:

    This sounds like the old DOS BASIC “renum” command. Oh how I loved that back in the day….

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


Virtualization, Storage, and other techy stuff

The Stupid Engineer

I ask those questions you're too clever to.

Sunay Tripathi's Blog

Pluribus Networks Founder's Blog on OS, Networking, Virtualization, Cloud Computing, Solaris Architecture, etc

Ed Koehler's Blog

Just another weblog

Data networking, stray thoughts, nerdy fun...

Network Heresy

Tales of the network reformation

The Borg Queen

Jottings on the intersection of tech and humanness

Networking From The Trenches

Ramblings about my thoughts, experiences, and ideas.

Networking 40,000

Attaining my CCIE with the help of Warhammer 40k

Network Shenanigans

Making Packets Do Silly Things

It must be the network...

Ramblings of JD (@subnetwork)

Not Another Network Blog

Musings from yet another IT nerd

rsts11 - Robert Novak on system administration

Resource sharing, time sharing, (20)11 and beyond. A retired sysadmin's blog.

%d bloggers like this: