Recently, I wrote an article about the source of truth in a modern network. Many things complicate this because we have two different truths in the world when it comes to state. The ideal truth is what we want things to look like. We declare that we want the network to be configured a certain way. We state the intent for the network to behave and perform as we would expect. When we put that into play, we assume our wishes are carried out as we would expect.
However, the reality is that there is another truth at play in the network: actual truth. This truth exists whether we want it to exist or not. That’s because ideal truth isn’t always implemented exactly as we would like. Our plan may run into issues. As von Clausewitz is famously quoted, ‘No plan survives first contact with the enemy.’ The enemy here is the imperfect implementation of your desired state of the network.
I didn’t think deeply about this when I wrote my original article, but thankfully Daren Fulwell of IP Fabric did. His comment on my post is as follows:
I’d suggest that as you get further along the path of network automation towards Intent-Based Networking you actually need two ‘sources of truth’: one to express the intent – ‘This is how I want my network to look’ – and this is where NetBox would sit, representing the desired state of the network to act as a source of configuration data and policy information for your automation; and one to show the current state of the network – ‘This is what my network looks like now’ – where a product like IP Fabric excels.
Daren is spot on here. His reasoning is that many automation projects fail or are too complicated to succeed in the long term. Our network’s actual truth is too divorced from our ideal truth, as we would like it implemented. We can’t figure out how to reconcile the two and understand how to bridge the gap between ideal and actual. We don’t have the tools we need to make the truth universal.
Fabric of Truth
That’s why Daren’s company, IP Fabric, is a great way to explain this concept. Sources of truth are best configured as a repository of intent. They should reflect things as we would like to see them. They should not reflect the actual truth. That creates a massive issue with the intent. IP Fabric helps bridge this gap because they are a repository of actual truth in the network.
IP Fabric scans the network and ingests the current state of devices. It provides actual truth. This demo from CEO Pavel Bykov at Networking Field Day 23 does a great job of showing how that process works:
Once you know what things look like in your network, you can get to work on the fixing part. Thanks to IP Fabric, you can go in and troubleshoot when the configuration looks the way that it does. It’s important to figure out not only why it looks that way but what is blocking you from getting the correct configuration down onto the device from your Source of Ideal Truth.
This process is long and, honestly, difficult to endure. It would be really easy to ‘fix’ the problem with IP Fabric and move on to the next fire to fight. Remember, though, that the purpose of doing things this way is to understand how to automate the process and keep it functioning in the future. If there are hiccups along the way, you need to sort those out the right way. That means troubleshooting the mechanics behind what’s happening, not brute-forcing your will into reality.
Writing Down The Truth For Once
Another big piece of the puzzle that IP Fabric can assist with is the documentation of the network state. Source of Truth tools don’t like to be confused by what things look like now. They’d rather start clean with the intended state of the network and implement it from there. However, if you don’t know what things look like now or have a vague idea but no concrete proof, you aren’t going to succeed without a huge amount of pain and work.
On the other hand, IP Fabric can assist by giving you a device and configuration inventory to work from at the start. You can turn their platform loose to discover what’s hiding out there and what you need to focus on to get things working the way they should. I spent a huge part of my early career doing things just like that with different tools that had a small percentage of the capability of IP Fabric. It was always shocking to IT admins when I would find a hidden switch in the ceiling of a remote classroom or discover a hub secretly running a computer lab that was complaining about slow speeds.
I like the idea of documenting the network state before implementing intent for two reasons. The first is that you have a yardstick to measure from. You know what it used to look like before you started and you can tell why the new way is much better. It doesn’t take long for people to see your automation projects’ value when you show them what things used to look like before you started. The second reason is that you can start with the assurance that you have everything written down if it all goes wrong. If there has never been network documentation in the past, you can be sure there isn’t much in the way of a rollback plan if things go wrong. By having a self-documenting network, thanks to IP Fabric, you can plan your projects with the confidence to get back to a known-good state if you need to. That is the safety blanket your decision-makers need to proceed with confidence.
Bringing It All Together
Truth is truth. Except with truth is both what we want and what we have. Both truths exist at the same time, not unlike a certain physics cat. We need to reconcile those truths to find the ultimate truth. That reconciliation requires us to have the right tools to make it happen. That means getting the documented truth in one place where it can be acted upon. IP Fabric is a great way to ensure we have nothing but the truth, whatever that might be.
For more information about IP Fabric and their Network Assurance platform, make sure to check out their website at http://IPFabric.io.
