Intent Based Networking: the new level of abstraction

For some time now, there has been a great deal of talk about Intent Based Networking (IBN) as the next big goal to reach in the network field, or at least in the network management field.

Everything around this idea is a encouraged by the role that companies such as Cisco are playing as promoters that point to IBN as the way to be followed.

In fact, in an article published at the beginning of 2017, Gartner referred to IBN as “the next big thing in networking”.

Now, let us take a moment to think about what Intent Based Networking is trying to solve, what it intends to correct or what it is going to improve.

Let us begin by emphasizing the fact that defining, configuring, managing and monitoring network and communication platforms has been based on the work and expertise of network analysts so far.

And for years, network analysts have configured each switch, router, firewall and access point in our platforms. In addition, it has usually been done manually and product by product.

This gives us not only a deep knowledge of the network we are managing, but also a great deal of fondness to the technical aspect associated with the equipment that makes up the platform.

In fact, when we are told that our business is required to provide a new service or a new application for a group of private users or that a new regional office will be opened, our brain starts working in a very specific way.

How does a network analyst brain work? It immediately starts listing each and every one of the activities necessary to meet the given requirement.

Activities that cover things such as creating a VLAN network, opening a TCP port, creating a group of security policies, reconfiguring routers, calculating the increase in bandwidth consumption of the links involved, etc.

Then, we organize the work and go directly to the execution of these activities, to finally deliver the ideal environment to support the original requirement.

We can say that for a long time this work scheme has worked quite well.

But, despite being getting the hang of this way of doing things, it is a fact that all network analysts recognize it is hard work, prone to human errors, that it slows down changes and that, applied on large and complex platforms, it promotes the loss of integral control of the platform.

And that is precisely the situation IBN intends to solve.

IBN and its precepts

Intent Based Networking aims to automate the activities of network analysts.

To achieve it, it proposes to create a level of abstraction that allows, through orders that point out the service or application to be added, to automate all network configuration and management activities.

That means that having a platform that supports IBN, in theory:

  1. Should allow you to tell the network what service or application you want to add (the intent) and
  2. The network should be able to automatically configure itself to achieve the ideal environment to support said intention.

Hence the name “Intent Based Networking”.

Undoubtedly, up to this point it is a very attractive idea, and it gets even more juicy when we take into account the idea that it might even feature artificial intelligence and machine learning elements when outlining necessary activities.

In the following image, there is a basic outline of IBN:

Intent based networking 1

A basic scheme of Intent Based Networking

Here, based on the intent, machine learning algorithms applied to networking will allow IBN to handle a group of suggested activities to achieve optimal implementation.

Prior to an acceptance process, IBN will execute automatically the authorized changes, without the intervention of network analysts.

Since IBN is still in its early stages, there is no standard architecture by which manufacturing companies that choose to undertake this path should abide.

However, people talk about basing solutions on IBN devices that can be integrated into existing networks and that offer a web interface to users from where the intent can be defined.

But there are still questions that remain unsolved such as: how will these IBN devices be integrated into the base network?, with what type of traffic will they communicate with all the network devices?, how will they be able to interact with schemes such as SDN (Software Defined Networking) or SDN-WAN among others?

But in any case, the fundamental precept of IBN is clear, which is to shorten the distance between business requirements and management of networks that support everything, based on a broad automation scheme of network analyst activities.


When precepts contemplated by IBN are reviewed, it is unavoidable to think that they are actually quite similar to the network organization scheme that SDN implies.

Indeed, IBN and SDN have the same goal of automating network configuration and management activities, which leads to many authors considering IBN as an SDN improvement, or the next evolutionary phase of SDN.

Considering IBN as SDN 2.0 or not, the truth is that both proposals are different regarding their own levels of abstraction.

SDN implies an organization scheme that tries to offer abstraction on individual configuration and management tasks, allowing you to think in terms of required services.

In the case of SDN, a required service may be enabling specific UDP traffic for all packets that come and go from a specific branch.

For this particular case, the activities organized or included in this level of abstraction can be things such as adapting router and firewall configuration, modifying access lists, opening or closing associated TCP and UDP ports, etc.

As we can see, we are still in the technical field, trying to automate the activities of network analysts, but starting from a purely technical requirement.

In the case of IBN, the idea is that the level of abstraction makes us get even closer to the business, to what we want or need and not how to solve it.

An intent in IBN can be enabling a specific application for the users of a particular branch.

And structuring this might include enabling a specific UDP traffic, in addition to all the relevant individual activities.

Therefore, the levels of abstraction are different and the difference is not really as slight as we might think at first.

On the other hand, it is interesting to think that, as proposed by IBN, its precepts are independent from any other network technology.

Therefore, we could have a network and communications platform ruled by an IBN solution, with a “low level” implementation both based or not on SDN.

It should not matter either whether what we have as a base are switches or OSPF as routing protocol.

We recommend this article that has been published in this blog to those of you who are interested in taking up the concepts related to SDN and the challenges involved.

Who are working at IBN?

There are several manufacturing companies that are making efforts to develop products based on IBN and which, based on this, make it clear that they see IBN as the next frontier to conquer.

Something that these companies have in common is that, generally speaking, they have products in the market associated with SDN and SDN-WAN, which in our opinion provides the base from which to develop the IBN concept.

On the other hand, IBN has been promoted by emerging companies that have emerged around the business possibilities offered by the automation of networks and technologies such as SDN.

Just to provide a little guide to those of you who are interested in reviewing the business proposals of the companies that are interest in IBN or that already grant IBN features to some of their products, we are going to mention the following companies: Cisco, Apstra, Juniper and Itential, among others.

IBN and Monitoring

The development of Intent Based Networking sounds promising from many angles, beyond its obvious advantages in terms of network management.

However, in terms of monitoring, the idea of IBN leads us to think about the challenges that may be involved.

A new level of abstraction must always be considered in the development of a monitoring platform.

Especially when the objective of this platform is offering visibility in all areas of our platform, from applications and user experience to the performance of each element of the network equipment and servers involved.

The amount of traffic generated by these types of solutions, the possibility of correctly correlating traffic with intent and the impact of this traffic on the overall performance of the insurance platforms will be points that we will focus on in case that IBN becomes an operative element in our platforms.

On the other hand, it is interesting to think about the possibilities the application of artificial intelligence implies to the network management field. And we must recognize that this idea is not new nor exclusive of IBN.

In any case, IBN makes a great promise: to manage to predict network problems before they appear and to solve them automatically.

There is no doubt that it is quite an ambitious promise that will be interesting to evaluate and compare with the efforts made by the monitoring tool market to integrate intelligence elements to its proposals.

In any case, we do not know what the scope of IBN will be in the future, but without losing sight of it, what you can do right now is:

  • On the one hand, think about how close to the business is your network management.
  • Try to evaluate the time and resource expenses devoted to managing your networks and see these activities from the automation angle.
  • And, of course, defining and installing a monitoring scheme for general purposes such as Pandora FMS, covering all business areas, including networks of course.
  • And, if you already have it, evaluate how you can increase its capabilities. Therefore, we encourage you to visit the Pandora FMS website and request information about the general features of Pandora FMS and particularly its predictive monitoring module:

Finally, remember that if you have more than 100 devices to monitor, you can contact the Pandora FMS team through the following form:

Also, remember that if your monitoring needs are more limited, the OpenSource version of Pandora FMS is available for you. Learn more about it here:

Do you want to stay updated?

Pandora FMS newsletter, will keep you informed about new releases, plugins, features and integrations. We won't ever give your email to anybody else.

You're now subscribed to Pandora FMS. Thanks!


Download the most comprehensive report on secure monitoring from IDG research