Sep 19, 2017

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

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

In our first blog “Intent-Based Networking Automation: 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 Automation: 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 automation 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.

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:

specific nodes and routes 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:

a cabling mistake that has violated the intent, causing an error

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

No configuration error is present

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 is auto-collected based on the intent.

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

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, is 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.