Intent-Based Networking and Security

Apstra Blog
Intent-Based Networking and Security

It is an exciting time in networking, and Apstra is leading innovation in the area of Intent-Based Networking. Apstra pioneered this concept and was the first to bring it to market with the Apstra Operating System (AOS). The reason behind this excitement is that businesses need to be responsive and agile to key initiatives; and networking is critical to most of these key initiatives. Business leaders also realize that they need to think of networking in a fundamentally different way. They must move towards a massive simplification of their network operations, enabled by autonomous self-operations. I wanted to be a part of the effort along with the passionate team at Apstra. This is why I am at Apstra. Exciting!

In my debut blog at Apstra, having spent the past 6+ years at Palo Alto Networks, I thought I’d share a few thoughts on how network security fits into this new networking paradigm.

Control and Visibility

I like to think of network security in the context of “control” and “visibility”. It is very hard to secure something you do not have visibility into and you cannot secure things you cannot control.

But before jumping into these aspects of network security, let me highlight some key concepts of the AOS Network Operating System (AOS™) which I’m particularly excited about. AOS is a distributed network operating system that allows users to specify intent, and is responsible for configuring the network to operate according to the specified intent. In addition it monitors the network and ensures network operation is compliant with the specified intent. The user specified intent is used to build a network reference design that is represented as a graph in the AOS store. The network reference design graph models the network elements and relationships between network elements.

AOS then establishes “expectations” for network operation to be compliant to the specified intent. Expectations in AOS are representations of network state expressed as telemetry from network elements. For example interface status, MAC addresses, ARP information and route information are some examples of raw telemetry that is collected from network elements. Since the network is represented as a graph, applications can use graph queries to get network state information.

We call this concept Live Queries and it offers the ability to query the network topology, set up notifications to detect change in the network and register callbacks to process these notifications. In order to ensure that the network operates in compliance with the specified intent, AOS collects telemetry from network elements and detects anomalies and processes anomalies (remedial action) using the specified handlers.

As is hopefully clear from my description above, AOS provides unprecedented control and visibility into the network state and network operation.

Now to focus on the security aspect, AOS allows users to specify policy and constraints on various network elements in the network reference design graph. Security is essentially a part of intent. For example, a policy to add a set of allowed destination IP addresses/ports traversing a switch interface can be part of the intent. Another example that is fairly simple but very important is to specify intent based on network element artifacts like NOS version, patch level for software on the device, or other custom artifacts. Once these are specified, any deviations will be tracked and reported as anomalies with associated remedial action, take the device offline, send an alert or trigger a patch update. This is key in today’s environment where keeping network devices updated to have the right level of software and vulnerability patches is critical to network security.

Specifying and extending security constructs with ease

AOS provides built-in services that collect raw telemetry from network elements (e.g. MAC addresses, ARP tables, route tables, etc.) and set up expectations and monitor the state of the network based on the collected telemetry. Telemetry collection is extensible: it allows collection of custom telemetry from elements, and provides the ability to associate the telemetry with the network reference design graph. This could be done by running a live query that is associated with the custom telemetry and setup expectations and anomalies based on the telemetry. This capability is very powerful as the live query provides notifications, and an ability to react to the same in real-time as network state changes. The blog post Apstra AOS 2.0 for Custom Telemetry Applications explains this concept in detail.

The ability to set up Custom Telemetry Applications allows users to specify several security constructs for network activity in a data center network that is typically behind a firewall or in a secure zone. For example, it can facilitate detection of lateral movement inside the network, detect traffic flows that should not be present, movement of mac addresses, interface statistics, etc. All these can be defined with ease in AOS. This way you do not have to deal with the complexity of collecting all network counters, and processing the same using big data analytics to detect anomalies.

The ease with which users can add security constructs to intent makes handling complex security tasks very easy. Consider the above example of lateral movement of data in a virtual network where nodes are moving around or being brought up/down on demand. Since AOS creates the network reference design and ensures operation of the network, it has the context to be able to respond to various questions about the network (regardless of the complexity) in the presence of constant change. AOS enables applications to be notified only about the changes that the application cares about in real-time with associated network context. This is a huge shift in the way networks are monitored!

Unprecedented visibility

In AOS 2.1, Apstra introduced Intent-Based Analytics and it is available to customers. This extends the concept of raw telemetry described above. It allows users to aggregate raw telemetry from network elements, and supports analytics constructs like thresholding and pipelines of data across processing stages. This concept also allows users to create constructs related to the state of network devices along with network data patterns or other network parameters.

An example of that would be to detect server activity (e.g. CPU, I/O, application metrics) and correlate that with the network activity of the server (traffic patterns, interface stats, ports used etc). The ability to leverage rich context from elements in a network and co-relate across network element parameters, data flows and network operations to detect anomalies provides unprecedented visibility.

Compare this to sending all your network/server data all the time to external systems. The external system has to process a large amount of data offline and then, if you’re lucky, detect anomalies and come up with remedial actions. This results in a time lag between the time of the anomaly and detection, and renders the anomaly detection and remedial actions ineffective in the context of network security. The blog post, Intent-Based Analytics: How can I use them Now? describes how you can configure and use IBA probes.

Massive simplification of network operations through autonomous self-operation

Last but not least, AOS allows the user to specify intent, and then simply operates the network for the user. You could say “build a network with 25 racks and 20 servers in each rack with 10G links and 2:1 oversubscription and ensure that there is no ssh or ftp activity between a set of servers and trigger alerts and deny access if there is a traffic burst from any server that violates the standard deviation of the “tx_bytes” by 30%”. AOS will build a reference design for you and once this is deployed, the network will setup expectations based on the intent and trigger alerts and remedial actions specified. This is the closest the industry has gotten to autonomous network self-operation. Sounds too good to be true? Try this new “refreshingly simple” approach to network operations. Check out AOS.

Intent-Based Analytics: How can I use them Now?

Apstra Blog
Intent-Based Analytics: How can I use them Now?

AOS 2.1 is now available, and you can take advantage of our new technology that gives you service aware active insight across your data center infrastructure.  At Apstra we call this new technology Intent-Based Analytics.   Last October, Sasha Ratkovic, our CTO, introduced the concept of IBA in his blog titled “Intent-Based Analytics: What Is It?”.  Josh Saul, our Solutions Architect, recently presented real-world uses cases in his webinar illustrating how IBA probes are compositions of computational stages that bring together elements of the data center Intent store and the active collection of network telemetry state.

Prevent Network Outages and Gray Failures with Intent-Based Analytics

Apstra Blog
Prevent Network Outages and Gray Failures with Intent-Based Analytics

We recently released version 2.1 of our AOS network application, and it includes a new set of features called Intent-Based Analytics. IBA is included in AOS and can be used by all customers immediately. These analytic capabilities have been part of AOS since the first release, but we are now exposing these features for customers to leverage. You can see a demo of IBA features in our on-demand webinar “Intent-Based Analytics: Prevent Network Outages and Gray Failures“.

iba_1.pngYou may have heard recent announcements about IBA or assurance functionality from a large vendor, and we’re proud of the fact that our vision is being validated by the largest names in the industry. Unlike other solutions, our platform is multi-vendor and hardware independent, so IBA works across all systems without the operator needing to know the differences between the specific syntax of commands, output, or operating guidelines. Everything is normalized so you can simply interact with the data in a meaningful and visual manner. IBA is NOT a legacy network management system, it is a totally new way of operating your network.

This is where we think today’s network experts will be able to apply their custom troubleshooting and best practices and maximize their value to their organization. We’re providing several complex checks to get customers up and running with IBA immediately.

IBA allows operators to logically link the intent of the system to the desired operating parameters. It does this in a very generic and vendor-agnostic fashion, so the IBA will automatically update itself when changes occur. If we define some normal behavior for the spine switches, every time we add a spine the system should know how to monitor it and what the addition of that device means to the rest of the network.

We can also create baselines that support statistical analysis, with the ability to watermark the normal behavior of the system. Any change to the design or policy of the system should update the analytics and expectations for the desired running state.

IBA uses mathematical processors to take data and transform it into something understandable by a human. Network engineers already know how to do this, in fact they’re doing most of this analysis in their heads.

But what is groundbreaking about IBA is that these processors can be assembled into larger units, called probes. Probes can connect multiple processors in many different ways. This is exactly how an engineer thinks through the troubleshooting process. At my desk, I might take one bit of data from the screen on the left, and compare it to something on the screen on the right. If these two sources tell me something interesting, perhaps I will open a new application to gather more data. Sometimes I call my peer in the NOC to see if they are seeing something related on their instruments. These pieces are all disconnected, and are assembled in the mind of the engineer only when alerted that there is an issue.

IBA has all of the tools to collect and analyze these disparate bits of data, and you can put them into a probe so the condition we are looking for is always being checked. Perhaps we want to know if our MLAG peers are receiving an unbalanced amount of traffic from a host. Wouldn’t it be great if we could check this every five minutes on every single MLAG pair? Better yet, if we add more MLAG pairs in the future, they should automatically be added to these system checks.


So IBA is a toolset you can use to put your expertise directly into the system and not have to perform these steps manually. You can do virtually sort of analysis, you can even connect sources of data that might have previously been unrelated.

IBA helps to identify issues in your network but also cuts down on false positives. You can set baselines, perform statistical analysis, and create unions of conditions. It is totally customizable for your business needs and you can create these system checks in minutes rather than months.

IBA is a next generation technology. Is it not a traditional Network Management System (NMS). It gives you familiar tools to quickly put your mental model into the system and then gradually build more connections to create advanced troubleshooting and reactive elements.

This first release of IBA contains everything needed to get up and running, and we’re providing complex probes as examples in our Github repo.

For more information on IBA or AOS, please feel free to contact us directly.