Having spent my entire career with Cisco (working with IOS and NX-OS), until recently, I never realized there was a difference between the state of a system and the configuration applied to it.
Now that I spend my days in Linux I see there is a difference between the two.
When I say “configuration” what I’m talking about are commands placed in a file that are loaded by the system. In IOS you could think of the running or startup configuration. This describes what should happen to the system. For example, I want to apply an IP address to interface e0/1 I would create a configuration that looks like this
interface ethernet0/1 ip address 192.168.1.1 255.255.255.0
In (Debian based) Linux I’d do the same sort of thing in the /etc/network/interfaces file
iface eth0 address 192.168.1.1/24
In both cases I’m simply putting text into a file. If I copied the IOS example to the flash of a Cisco router I wouldn’t actually apply any changes to the system. I’ve only defined configuration.
State is what is actually going on in the system. This is the output of show ip interfaces on a Cisco device. You are asking the box “what is the current running state?” Using the previous example, if I copy the IP address configuration to the flash it does not change the state until it is applied with copy flash:ip_address.txt run Only when I do this do I push the configuration into the state.
This is the same in Linux. Simply configuring the text file does not change the state of the system. I need to apply this state using a command like ifreload.
Where Configuration is State
As I mentioned earlier, in IOS, with only a few exceptions, the configuration of a router is the state of that router. When I issue the command ip addresss 192.168.1.1 255.255.255.0 I am assigning this piece of configuration to the running config AND changing the state of the system by assigning an address.
Where Configuration != State
In Linux things get interesting as there is is always more than one way to do something. In Linux the state of the system is what is applied to the kernel. This means any way you can get something into the kernel is how to apply state. One way to apply state is configuring the /etc/network/interfaces file (configuration) and applying it with ifreload (state). I can also cut out a step and just create state directly with a command like ip addr add 192.168.1.1/24 dev eth0. Now I have the opposite of what is normal in Cisco-land. I have state without configuration.
The Value of Configuration
Applying state directly is a nice feature to have however the value of configuration doesn’t go away. Simply changing state does not create a record or memory of that state. If the device is reloaded this state is not saved. This is exactly the point of configuration. It is a persistent image of what we want state to look like. If I write down the state and save it, then I can always re-apply my intended state.
The Value of Configuration != State
One of the challenges with the original IOS model of configuring and state being one in the same is that there is no way to validate a change or syntax. My only way to do this is trial and error. I must apply configuration and then hope the state is accurate. This doesn’t seem like a big issue for single commands where errors are reported but what about multi-step changes with dependancies? For example, let’s create a new bond/etherchannel. I need to change settings on the member ports then I need to configured the bond. If I misconfigure the individual ports I can’t configure the bond.
When configuration and state are the same, I can copy and paste all of the configuration and hope it works. You know when you paste in a config change and see the syntax error on line 2 and watch the next 20 lines half-apply while your heart sinks? That’s configuration and state being one.
When configuration and state are not the same it allows for syntax or dependency checking. This is a feature that exists in IOS-XR and JunOS. In Linux applications can do this checking, for example I can create configuration and before applying state use an application to check this state for me.
iface swp11 addres 10.1.1.1/24
cumulus@leaf1$ sudo ifquery -ca error: /etc/network/interfaces: iface swp11: unsupported keyword (addres)
I can validate my configuration without impacting state. These are trivial examples but what if you configure a new WAN interface and the only misconfiguration is an ACL or route filter? The impact of small problems can be very large.
The Future of State Without Configuration
If I no longer need configuration to apply state I can now have highly dynamic networks being driven by software. I can have software create VxLAN tunnels or apply ACLs based on some sort of external factors. It may not make sense to save these configuration since those external factors may change after a device reloads. For example, a service may be brought down or a VM moved as a result of the failure, so the VxLAN tunnel may no longer be needed.
A device’s saved configuration can be a baseline. What are the required IP addresses, ACLs or security policies no matter what changes? This becomes my configuration.
The dynamic tunnels, ACLs, route filters, routing peers or anything else can be simply state applied by on box or off box applications.
It’s important to understand that state and configuration are different ideas. In software like IOS the configuration is always the state. In software like IOS-XR or Linux you can have configuration somewhat independent from state allowing for syntax or dependency checking first, before applying state. Finally Linux can take it a step further and allow for state to be applied without configuration.
At the least vendors should be pushed for the ability to validate changes before making these changes, but the future lies in the ability to have state without configuration.