Apstra Blog

Intent-Based Networking Part 3: Examples of Closed-loop Telemetry

Updated Sep 19, 2017

This is the second blog in a three-part series on “Examples of Intent-Based Networking”.

In our first blog “Intent-Based Networking: Examples of Intent” we illustrated that an intent should have three distinct characteristics:

  1. Natural language, which is auditable, as the single source of truth for SLA and compliance purposes.
  2. Service-level, which allows you to manage the network as a system, vs. individual components.
  3. The what, not the how — so network engineers are elevated from how to configure vendor A devices, how to collect SNMP MIB ABC from device XYZ, and so much more.

Then in our second blog “Intent-Based Networking: Examples of Rendered Configurations” we show how to decouple your intent from vendor-specific configuration syntax and procedures, so you don’t spend your precious time hard coding your intent into static configurations.

In this blog, we show examples of “closed-loop telemetry”.

“Closed-loop telemetry” continuously validates your configurations, and the operational state of the network. Apstra Chief Scientist David Cheriton explains, “A ‘network operating system’ can collect telemetry that continuously validates this intent is being achieved, or else can notify the operator if the situation cannot be automatically corrected.”

Let’s break that down into a few examples:

Example: Continuous validations of the configurations of the network

This means whenever there is a misconfiguration or cabling error, we are notified immediately. This actual product UI below immediately shows the symptoms, in this case, BGP routing anomalies and IP fabric cabling errors.



We are also presented with the specific nodes and routes (i.e. blast radius) that are impacted:




So there is no guesswork. We don’t do random things, we know exactly where to see the root cause — a cabling mistake that has violated the intent, in this case:


And therefore we don’t have to wade through thousands of lines of configuration — because we know there is no configuration drift.




How can the correlation be automated between intent, configurations, and telemetry?

The intent of the network is represented in a graph-based repository — where the relationships between all nodes, interfaces, and links are stored. The configurations are automatically derived from the intent, and the telemetry are auto-collected based on the intent.

The following actual product UI shows the complex relationships between nodes, interfaces, and links, for a live network.


This graph-based database allows you to perform instant query and reasoning about the network.

To bring all the above together, we now have the chance, and confidence, to achieve continuous delivery of network changes. Because our network state, both desired and actual, are rendered from our intent (the single source of truth) and validated by continuous testing of all nodes, interfaces and links, we can respond to changing business needs on-demand.

Stay tuned, there will be a lot of innovations coming from Apstra.

Follow Apstra