Practical Network Automation, Part 3: Terms and Concepts

A quick explanation of terms and concepts that automation-focused engineers should know.

Terms to Understand

It is important for us to understand a few key terms before diving deep into automation. There are hundreds of ways to automate your network, and some are better than others.

IMO, the best way to automate your configs could be described as DECLARATIVE, IDEMPOTENT, and ATOMIC. Understanding these concepts will help inform future automation decisions.

Declarative vs Imperative

When you describe something declaratively, you’re only describing the desired end state.

In terms of configuration automation, a declaratively defined network config would be ONLY the final configuration state, rather than the steps needed to achieve the final state. This is a key component of “intent based” automation.

Let’s say your current VLAN config looks like this:

vlan 10
  name iot
vlan 20
  name wifi
vlan 30 
  name wired

And you need to add one VLAN (vlan 50) and remove one VLAN (vlan 10). How do you approach this?

When operating declaratively, you would only need to define the intended state of the new config, which would be this:

vlan 20
  name wifi
vlan 30 
  name wired
vlan 50
  name new_example_vlan

Here, the way to reconcile the difference between ACTUAL (existing, current) state and INTENDED state would be to REPLACE the configuration. We will be using the replace method in our final solution in this series!

Config replace is a key feature of a good modern network operating system. There are a few NOSs that don’t have configure replace functionality and I will complain about them later. For those use cases, heir config may be an alternate approach.

The opposite approach of declarative configuration is IMPERATIVE. This approach is sequence based and outlines the steps to get from ACTUAL state to INTENDED state. There are many downsides - it can be clunky, order of operations becomes extremely important, and it’s overall more difficult to execute.

The imperative version of the VLAN change in our example involves sending the correct commands to delete the unwanted VLAN and add the new VLAN:

no vlan 10
!
vlan 20
  name wifi
vlan 30 
  name wired
vlan 50
  name new_example_vlan

It may not seem like a big deal now, but at scale this can become difficult. A primary challenge is that you must track the current state so you know what things need to be removed or changed. When operating declaritively the existing state doesn’t need to be tracked.

Idempotent

Things that don’t need to change stay unchanged.

When you declaratively define and push a device configuration, you shouldn’t push/re-implement config lines that already exist. For example, there’s no need to re-configure VLANs that are already configured on a switch.

When working with a network operating system that supports configure replace, idempotency is naturally implemented by the replace method. The NOS will see the config you have sent as the new desired state, compare it against its existing state, and only implement the deltas between them.

Atomic

An atomic change can only be deployed 100% successfully. If there is any failure in the change, it is all reverted to initial state.

Have you ever pushed a large amount of changes and encounter a failure someway through the process? In the worst case scenario, some changes were successfull, some weren’t, and there’s no obvious way to know. Now you have to investigate what changes need to be rolled back or which changes need to be manually implemented.

When using the declarative configuration approach and a good network OS, you won’t need to deal with non-atomic changes. Either the configuration was replaced or it failed and was reverted to original state. There’s no in-between.

What’s Next?

These are very important things to consider when choosing your network operating system and automation methods. In the next post we’ll build on the nornir configuration example from part 2 using the concepts introduced in this post.