Intent inference: A step into the automated future

In order to serve the growing infrastructural needs of any company, networks today are much bigger and vastly more complex than they have ever been. Hybrid networks including the cloud (Amazon Web Services, Azure etc.), network virtualization technologies, software-defined networks, mobile devices, Internet of Things and similar technologies are gaining wider acceptance in the community, adding further complexity to traditional physical topologies. Organizations not only have to worry about managing their existing network, but also about other factors like how resilient their network is to failure, how vulnerable their network is, traffic segmentation across their sites, etc. In addition to all this, continual change gets in the way: according to a survey of 315 networking professionals, 74% said changes cause network outages or performance problems multiple times a year – with many reporting these problems on a weekly or daily basis.

Intent Based Networking (IBN) offers a way to manage such complicated and rapidly-changing environments by making the high-level business goal paramount. More precisely, the intent of the architect, owner, or operator of the network is the goal they want the network to achieve. For example:

  • “Servers in the data center should have two independent network paths via which they can communicate with Internet providers.”
  • “All wireless access points should be able to access the Internet.”
  • “ATMs should only be accessible from secure zones within data centers.”

With the intent defined, IBN software can then — depending on its capabilities — create and deploy configurations to realize the intent, or verify that a multi-vendor collection of devices are achieving the intent.

So in any IBN software, defining the intent is essential. But where does that intent come from?

While the above intent statements appear straightforward, obtaining the intent may be challenging for multiple reasons. The user of the verification system may need to learn how to use the system to describe intent, since natural language (as in the English descriptions above) is imprecise and IBN systems are not capable of accepting it as input. Even if the user knows how to describe the intent, the network may be very large and have many goals, so it would take significant time to describe all intent rules, which may number in the hundreds or thousands, and the information to which they refer (e.g., in the examples above, where are the “secure zones”, “Internet providers”, “ATMs”, etc.?). Finally, the user may not be aware of what the intent is, for example, because they may be a novice user, or because the original architects of the network are no longer available (after a change of staff or a merger between firms) and documentation was poor. Contextual information, like grouping of devices into zones, may be written in hand-drawn diagrams but not available in machine-readable form.

But what if the system could automatically infer the intents, with very little to no input from the user?

Developing this kind of software technology in itself is a hard problem to solve, as networks of today are extremely complicated, running multiple protocols (like BGP, MPLS, NAT, HSRP/VRRP etc.) and connecting multiple data centers. Moreover, inferring intents could include state information that is currently not even present in the network. However, once solved, it could be a huge timesaver for the network operators (which would translate to real dollars for the organization), and could also remove the element of human error in manually defining these intents. Let’s dive into an example of how a network operator would go about his day without automatic intent inference.

Let’s say that a particular network is operating some devices which are running some kind of redundancy protocol like HSRP or VRRP, and the network operator responsible for this network wants to define intents in order to validate the proper functioning of these protocols. The main point of having a redundancy pair is that, if the master device fails, the traffic should fail over to the standby device and there should be no interruptions in any service. In machine language, this translates to a multipath intent stating that certain traffic should be able to flow over both of these redundancy pairs. In order to achieve this, the operator would have to identify each and every redundancy pair in their network (there could be a decent number) as a first step. Next, they would have to define the multipath intent for traffic flowing through each of those pairs, a step that requires identifying the correct devices that are connected to this redundancy pair. This is a very time consuming process and prone to human error. While defining these intents the operator might just miss one pair, or might miss one of the cases to validate the behavior, which could cost a huge amount of monetary loss if the network were to fail in a way involving that pair of devices.

This is just one example, involving one networking protocol and one intent. It soon gets vastly more complicated when there are multiple devices which are connected in arbitrary topologies and running multiple interdependent protocols on which multiple types of intents need to be defined. Maintaining consistency of ACLs across firewall devices faces similar issues and much bigger implications because even just one ACL being inconsistent could result in the failure of a critical service or the network being vulnerable to hacking attacks.

Thus, inferring intent becomes a very critical part of ensuring that the network is indeed fully functional and is resilient to any sort of data plane state change. Veriflow’s patent-pending technology can automatically infer various types of intents on your network and provide value directly out of the box. Hundreds of thousands (or more!) of individual paths, possible data flows, devices, and interfaces are checked automatically, without needing any kind of input by the user, in order to validate if the network is following best practices. At the end of running these checks, Veriflow provides a health score for the network’s adherence to intended behavior. This technology has been applied in real world production networks, and issues (which could have been potential outages in the future) have been identified. In order to know more, check out Veriflow’s presentation at Network Field Day 2017 or a brief demo of automated inference, in which CTO Brighten Godfrey provides an example of how HSRP, in conjunction with OSPF, can misbehave, and how Veriflow is able to catch such issues. In addition to this, with Veriflow’s patent-pending CloudPredict technology, we can also model hybrid cloud deployments and auto-infer many best practice policies for the hybrid network.

In what we’ve discussed here, we’re only scratching the surface of the potential of automatic inference and machine learning in intent-based networks. With networks growing in size and complexity each day, it is just unrealistic to expect that it can be managed manually. The faster we move to automated processes with intent inference, the faster network operators will be able to afford a comfortable night’s sleep.