Network validation a first step to intent-based architecture
Network validation is an important first step for enterprises evaluating intent-based networking. Unless you know how things really work, you won't succeed.
If intent-based networking, or IBN, is to gain traction, then network validation and automation have to be part of the mix. IBN certainly seems to be the latest big thing in networking, so what do you need to know to start, and how can IBN help?
Consider this: You're responsible for a network and would like a way to automatically verify that it is functioning correctly. If your network is like most enterprise organizations, you're still running a multi-tier network design -- core-distribution-access. Fortunately, IBN doesn't solely rely on leaf-spine technology, though you'll frequently find some tools work only on leaf-spine networks.
Let's break IBN into two smaller objectives. The first is determining what the network should be doing -- the intent. The second is determining if the actual functionality matches the desired functionality -- network validation.
Determining network intent
At NetCraftsmen, we do a lot of network assessments. The customer rarely has detailed network design documentation, and even if he did, I don't recall ever seeing documentation in a form that could be used to automatically check network intent. Yet, there are several sources of information that can be used to determine the intent of the network.
Intent from the initial network design. The design should specify basic things, such as physical connections; Layer 2 broadcast domains, like spanning tree domains; hub-and-spoke topology; routing summarization domains; redundancy; security boundaries; diagnostic taps, like packet broker taps and troubleshooting tool locations; and business connectivity, both desired and disallowed connectivity.
Intent from the network configuration. The initial design criteria will drive the network configuration. You have to assume there will be bugs in the translation of the network design into the network configuration. You will need to validate the configuration's implicit intent matches the design intent.
Security intent -- both positive, or allowed connectivity, and negative, or denied connectivity. You should plan to collect information about both packet connectivity and routing connectivity.
Business intent. The ultimate intent is whether certain business IT entities can communicate with each other. A typical customer web application will require the web tier to communicate with the application tier, which will need to communicate with the database tier. But you wouldn't want the building facilities network to be able to access any part of the customer web application.
The intent information should be stored in a design repository, typically a database, where it can be used by the validation system.
The intent information should be stored in a design repository, typically a database, where it can be used by the validation system. Two open source tools provide the basic functionality needed for parts of an intent-based system: Network Source of Truth and NetBox. The NetBox documentation emphasizes the point about the source of its information:
NetBox intends to represent the desired state of a network versus its operational state. As such, automated import of live network state is strongly discouraged. All data created in NetBox should first be vetted by a human to ensure its integrity. NetBox can then be used to populate monitoring and provisioning systems with a high degree of confidence.
Note that the network itself shouldn't be used to determine the intent. For example, if we examine the network and find that Switch A, Gig0/1 is connected to Switch B, Gig0/48, we can't determine if that was the intent. What if the intent was Switch A, Gig01 > Switch B, Gig0/49, but the cabling was installed incorrectly?
The database schema of a basic system like those mentioned above will need to be extended to encompass all the sources of intent. I recommend starting with Layer 1 through Layer 3 network design intent, which the above systems can provide. Unfortunately, there is little in the way of automation that can help with the process of determining the original design intent of a large network.
You'll also find that some things get very complicated, such as when business processes require certain connectivity, while security practices require separation. When systems get so complex that you can't easily explain how they should work together, then it needs to be redesigned in a way that separates the complexity. (See talks by Russ White on network complexity.)
Validating the network
Once you have the network intent data, you need network validation to determine it is functioning as you intended.
Check physical connectivity first and work up the protocol stack. The following is a good sequence. Automation can be brought to bear on these tasks. I've found that systems like these should only report failures. Chatty output just adds to the workload; quiet success reduces the volume of data generated and makes it easier to prioritize and handle failures.
Layer 1 and Layer 2 connectivity. Are things cabled correctly and in the correct virtual LAN-subnet-virtual routing and forwarding order? These are basic interface and neighbor relationship checks. Include EtherChannel and hot standby or virtual router protocol checks.
Layer 3. Is routing working correctly? Check that the desired routes exist, as well as routes that should not exist. For example, networks may have many routers originating the default route as a static routing table entry, which is not good, versus a dynamic entry at a stub network boundary, which is good. Equal-cost multipath routing should also be verified.
Layer 4 and up. Active path testing and synthetic transactions can be used to validate business connectivity and to provide alerting if the transaction times exceed the design criteria. These checks can also provide alerts about undesirable connectivity that may not be visible through basic routing checks.
Network validation can be implemented using several different mechanisms:
A manual process. This is obviously not a very useful mechanism. It is useful to identify the process to use to validate something complex, but then the process itself should be automated in some way.
A network management system. Many network management systems allow custom rules to be configured for generating alerts. Look for ways to automate the maintenance of Layer 1 and Layer 2 connectivity checks within the NMS, driven by the Source of Truth database.
Automation scripts. Python, Ansible, SaltStack and REST APIs are all tools for automating the validation of networks. Since these tools can also be used for automating the change process, it makes sense to use them for validation, too.
Some other mechanism? There are new tools and technologies that provide mechanisms at higher levels of the network validation stack. One example is Veriflow, whose software contains a language that allows creation of simple network relationship checks.
The road is just beginning
We are at the early-adopter phase of intent-based networking and network validation. For now, the tools are basic and require extra effort to use. The good news is this allows us to take the first few steps in the process of validating network intent against the network as built. There are new processes that we need to learn. Think of it as a journey that will eventually allow us to run our networks in a more robust manner.
