Network and security engineers live in a world where they constantly work to preserve order in a world of digital chaos. A world where success or failure, on or off, allow or deny, up or down, working or degraded (I could go on and on with the analogies here) always hangs in the balance.
I’m not talking about defending the infrastructure from the evildoers outside of the network. While that is also an important and never-ending process, I’m actually referring to the constant battle to ensure that critical configurations on a multitude of devices never shift from order to disorder.
To fight this war, these brave souls spend hours manually battling through configurations character by character, line by line, to ensure that everything is arranged precisely. Manual review and manual changes to these configurations has been the process that’s always been followed, but as the network has expanded, modernized, and become more critical to the business, teams need to be equipped with new tools to help them confidently move to automating these processes.
The Configuration Challenges of Ordered Lists
A general term for these types of critical configurations is called “ordered lists.” If that still doesn’t make much sense, I can at least translate it for practitioners by providing a list of my own: Access Control Lists (ACLs), Policy routing, Filters, Firewall Rules, and Services are all good examples of ordered lists in device configurations.
These types of ordered configurations control some of the most critical features in the network, from security to performance, and must be arranged in a very specific way for the network to operate securely, function optimally, or even work at all.
There are many configurations that allow you to loosely configure features, or sub-features, in nearly any order without penalty. For instance, if you were to set up an Ethernet interface for most router vendors, you would be able to freely configure the description before the IP address, or vice versa, without any problems. The underlying network operating system will happily accept the configuration lines in either order, apply them, and everything works as expected. It will even standardize the order they are displayed when you look at the resulting saved configuration later. In these types of cases, the feature is important, but the order doesn’t matter.
Now, contrast that to configurations that operate as ordered lists. Imagine configuring an access control list or firewall rule that’s applied to an interface. Order matters here, so what happens if we get the order of lines wrong, and I start with a “DENY ALL” line before all of the “ALLOW” lines? That’s basically saying, close the door and deadbolt it, because no one is coming in no matter who is on the guest list. In network terms, all traffic stops, the wires get cold, and an instant bad time is delivered to the team.
We want to avoid that and put tools in place to give teams the flexibility to define ordered lists the way they would manually operate on them. Then, they can automate configuration audits for compliance processes and even validate proposed configuration changes as a pre-check to ensure everything remains in compliance. With that in mind, let’s talk about some of the features available to you in Itential Configuration Manager that enable you to do just that for both traditional CLI managed network devices and more modern network solutions and services that operate using API methods.
Itential Configuration Manager Features for Ordered Lists
Configuration Manager allows you to define Golden Configuration templates that serve as the standard, or baseline, configuration that you want to compare a running device’s configuration to in order to determine if it is currently operating in compliance with your processes and best practices. These templates can support any vendor CLI are using in the network, and, unlike many legacy NCCM tools, we can also support more modern network solutions that use APIs to controllers (like SD-WAN) or cloud services (AWS, Azure, GCP). For those solutions, we store configurations as JSON objects and can use the same ordered list operations on arrays.
As we’ve discussed, ordering is important for these types of configurations, but to what degree is ordering important? Or to put it another way, do we want to allow some flexibility to include new elements in the list as along as certain pre-defined elements always appear in a specific order in the list?
If this flexibility is allowable for this feature, then you would implement loose ordering in the template for this list. With loose ordering, you can define a list in a particular order, and as long as the order for that list is preserved, intermediate elements can occur in the configuration that will not violate compliance. So, we can define 3 elements in a list, ordered loosely, as our Golden Config. Then when we compare that to a running device’s configuration, it can have more elements between these 3 elements, but as long as those elements exist and are in the same top to bottom order it’s considered compliant. This kind of flexibility is useful for lists that need to have something like an allow or deny all at the top or bottom of the list, but we expect the list to grow over time with new entries.
The other end of the spectrum is “strict” ordering, which is basically exactly what it sounds like. There is no deviation from the defined rules, what appears in a strictly ordered list template must appear precisely in the device configuration you are comparing to, and if they do not match line for line, character for character, it is considered not in compliance. Other elements can appear in the list, but the elements that are strictly defined must have the same elements appearing consecutively.
For more flexibility when building rules for ordered lists, you can also define lines that can be excluded from the list ordering validation process. This allows for checking the existence of the line, but without including it in the ordering check. This can be handy for checking for descriptions or remarks where it’s acceptable to have them anywhere in the list itself.
And finally, for the strictest of strict ordering, you can enable that the elements are exclusive, meaning that the list elements that are defined are the only ones allowed to exist in the list you are comparing them to. No other items in the list are tolerated and doing so makes the list non-compliant.
Order Over Chaos: Configuration Management as Networks Scale
These features enable teams to build flexible templates for any type of ordered list configurations for both CLI and API infrastructure, so they automate scheduled compliance audits and changes and get away from the manual job of stare-and-compare that can steal away hours of time.
This process will continue to grow as the network expands in every domain — Data Center, Cloud, SD-WAN, wireless with more complex configurations.
With Itential, you can supply the team with the tools and armaments it needs to efficiently and effectively continue to win the battle of order over chaos. You can catch a demo of how it works here.
Rich Martin
Director of Technical Marketing ‐ Itential
Rich Martin is the Director of Technical Marketing at Itential. Previously, Rich has worked at several networking vendors as a both a Pre-Sales Systems Engineer and Systems Engineering Manager but started his career with a background in software development and Linux. He has a passion for automation in the networking domain, and at Itential he helps networking teams to get started quickly and move forward successfully on their network automation journey.
