Intent-Based Analytics

Dynamically and Quickly Extract Insights from Raw Telemetry

Clear as a Pane of Glass: The Benefits of Apstra Intent-Based Analytics

Apstra Intent-Based Analytics is different from traditional solutions: 

  •       Simple, Clear Insights. Identifies significant conditions and situations to watch and eliminates noise in real time using a “simple pane of glass.”
  •       Storage and Processing Cost Savings. Enables storage and processing cost savings by extracting more information while collecting and storing less data.
  •       Automated Troubleshooting. Empowers you to automate effective, complex, context-rich troubleshooting workflows, saving time and money.
  •       Zero-Touch Maintenance. Provides zero-cost and zero-touch maintenance when changes occur.
  •       No Integration Necessary. Increased flexibility and cost savings by eliminating high-cost, fragile data-processing pipeline integration efforts.
  •       Meticulous Accuracy. More accurate than ML/AI approaches, making you more effective and agile while saving time and money.

Simple, Clear Insights

Apstra Intent-Based Analytics informs you of conditions and insights that need attention, just like traditional single pane of glass approaches. The difference is that Apstra’s “simple” pane of glass also filters out the noise, correlating information and removing conditions that are merely artifacts. This makes it easy for you to see what’s most important quickly and easily. It’s customizable too, so you can influence and define the important situations to watch.

Extracting Knowledge

Raw telemetry data is aggregated across time and — more importantly — domain. While the time dimension does not require additional context, time aggregation usually goes hand in hand with the domain space.

Example: Imagine you need the answer to two questions: “What was the traffic average and max over the last hour?” and “What was the average and max over the last hour across all my fabric interfaces in Pod 27?” Intent inherently answers the question “What are all my fabric interfaces in Pod 27?” When the system has the knowledge of the intent as part of a single source of truth, it can provide answers in real time to these questions. Without inherent intent aggregating raw telemetry across the domain space is impossible.

Alternative approaches based on big data analytics are costly and fragile, as most of the processing effort in analyzing big data is in identifying this context and extracting it from a sea of information.

Storage and Processing Cost Savings

Apstra Intent-Based Analytics is intent driven. That means it knows what it’s looking for and collects only that information. Deviation from expected behavior comes from knowledge of the design (as the intent is known) and not from statistical inference. Uninteresting data is thrown away.

The More Intent You Have, the Less Data You Need

Apstra Intent-Based Analytics can result in a reduction of 5-6 orders of magnitude in storage and post-processing. Massive amounts of data require a lot of human and computer processing — big data is an invitation for an OpEx explosion. That can be useful for learning but not useful when the intent is defined. 

Knowledge of intent allows Apstra Intent-Based Analytics to collect only relevant data and keep only interesting data. The rest is filtered out or thrown away. Only solutions that model intent can be precise in telemetry collection.

Automated Troubleshooting

Apstra Intent-Based Analytics automates complex troubleshooting workflows. Tracing and understanding how mechanisms are stitched together can take hours. Apstra Intent-Based Analytics automates this painful process, which is auto-triggered by the presence of an anomaly.

The most complex part of troubleshooting is extraction of context from the intent. Knowledge of intent and reference design (a behavioral contract specifying how intent is being implemented), are the only way to automate these workflows. It’s inefficient to perform validations all the time on all resources, so you need a real-time reactive system such as Apstra Intent-Based Data Center Automation to trigger these workflows only when an anomaly occurs. 

Zero-Touch Maintenance

Apstra Intent-Based Analytics is automatically kept in sync with the user’s intent. Once the Apstra Intent-Based Analytics probe is set up, there is no need to maintain it. That makes it resilient – it automatically responds to changes, saving the huge costs associated with maintaining data processing pipelines.

Apstra Intent-Based Analytics probes use automated live queries that interact with the single source of truth in pub/sub to derive information. In other words, any change in the intent − including design, build, deploy, operation − is automatically reflected in the probe.

No Integration Necessary

What do you need to start running probes? Not much.  Apstra Intent-Based Analytics eliminates what Adrian Cockcroft, Vice President of Amazon Web Services, calls “undifferentiated heavy lifting,” setting your software developers free so they can focus on your business goals. What do you need to run a probe? Not much.

  •   Apstra Intent-Based Analytics comes free with the Apstra Operating System, which includes a set of built-in Apstra Intent-Based Analytics probes.
  •   There is a repository of probes on GitHub that third-parties can develop and you can download.
  •   You can create probes yourself using UI or with a simple REST post call.

In contrast, alternative solutions require a tremendous amount of work to do the same thing Apstra Intent-Based Analytics does simply and easily. configuring collection framework, configuring a processing pipeline, developing a DIY context-extraction process, configuring event processing tool and configuring visualization.

100% Accurate

“It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so.” – Author Unknown

Apstra Intent-Based Analytics is eliminating the longstanding problem of inaccurate assumptions and knowledge. Through intent, Apstra ensures that what you know is 100% accurate. Intent becomes the single source of truth and grants the ability to reason about it in the presence of change.

Apstra Intent-Based Analytics works by allowing you to use quality information (patterns you know or expect)that is available to you through intent (what you are trying to achieve) and reference design (how you are going to achieve it).

How is Apstra Different than Artificial Intelligence or Machine Learning?

In AI/ML, some quality information is mixed with noise, which contaminates the good information. As a result accuracy is relatively low (90%). ML/AI may help you identify new patterns, and add to quality knowledge. Once that knowledge is acquired, it can be embedded in your intent and fed into Apstra Intent-Based Analytics for to accurately identify conditions of interest 

Intent is about using known, intended causality to reason about operational state, not about deriving causality.

With Apstra Intent-Based Analytics there is no inference, such as used in observability, so it doesn’t have the inaccuracy that is associated with inference.

Accuracy in Action

Imagine a user has defined the roles of devices in the user’s reference design (i.e., leafs and spines). The user configures devices according to those roles, and the user knows the IP endpoints that need to be reachable. Once complete, the user can then calculate with 100% accuracy the routing table entries that should be present on each of the devices and flag any deviations as anomalies.

 Since the user knows exactly what should be there, even if deviations happen because of misconfiguration, bugs and failures, anomalies will be the symptom of a root cause that the user knows needs to be addressed. (And by the way, the Apstra Operating System does Root Cause Identification too!)

Without intent, you’re stuck trying to infer if the routing table content is correct, and if the missing (or extra, or wrong) entry was the result of a bug, failure or unknown intent.

White Paper:

Download: Understanding Analytics

Intent-Based Analytics White Paper

Get White Paper

Financial Services Technical Use Case

This financial services company uses Apstra Intent-Based Data Center Automation to perform extensive validation of the following:

  • Physical infrastructure (6000 interface status validations, 1000 cabling validations, 36000 error counters, 10000 power, temperature, voltage metrics validations)
  • L2/L2 data plane (12000 queue drops counters, sanity of 100s of MLAGs, 3000 STP validations, notifications of status changes)
  • Control plane (1500 BGP sessions health, ~500 expected next hops/default routes)
  • Capacity plan ( ~500 trending analyses with configured thresholds for the usage of routing tables, ARP tables, multicast tables per VRF, 6000 link usage validations )
  • Compliance (ensuring expected OS versions running on all ~100 switches )
  • Multicast (2500 validations for expected PIM neighbors, 300 rendezvous point checks, 25 validations regarding detection of abnormal patterns in count of sources, groups, source-group pairs on RPs)

Some of the Apstra Intent-Based Analytics probes performing these validations are built in, some were custom developed by simply translating requirements into Apstra Intent-Based Analytics probes.

This financial services company leverages all the benefits of Apstra Intent-Based Analytics from earlier in this paper. Instead of “single pane of glass” with 82,000 entries the financial services company is presented with a simple pane of glass 

  • showing only anomalies, 
  • categorized into a dashboard, 
  • which were 100% accurate (and not statistically inferred), 
  • were in constant sync with the user’s topology and intent and 
  • require zero ongoing maintenance. 

These steps provide the financial services company with the relevant actionable context (what deviated, the nature of deviation, desired state), saved on storage and processing needs (only 9GB RAM, 96GB disk required) and the user didn’t create internal lock-in and legacy by writing complex and fragile data processing pipelines.

Intent-Based Analytics

How to Prevent Network Outages and Gray Failures

White Paper:

Understanding Intent-Based Analytics

Intent-Based Analytics White Paper

Get White Paper

Webinar:

Prevent Outages & Grey Failures

View On-Demand

Demo:

See How Apstra Can Help You

Request a Demo

Intent-Based Analytics Probes on Github

Layer1

  • fabric_interface_flapping
  • sfp

Layer2

  • mlag_domain_config_sanity_anomalies
  • stp_state
  • stp_state_change
  • mlag_domain_state_anomalies

Layer3

  • border_leaf_default_gateway_anomalies
  • non_border_leaf_default_gateway_anomalies
  • border_device_default_gateway_anomalies

Device Health

  • memory_usage_threshold_anomalies
  • power_supply_anomalies
  • system_memory_usage_threshold_anomalies

Compliance

  • os_version_anomalies

Overlay

  • bum_to_total_traffic_anomalies
  • bum_traffic_on_unlearnt_vteps_anomaly
  • hardware_vtep_counters_enabled
  • vxlan_status
  • static_vxlan_vtep_anomalies
  • vxlan_address_table_anomalies

Security

  • acl_stat_anomalies

EVPN

  • evpn (VTEP floodlist)
  • evpn (VXLAN Routing)
  • evpn (Floodlist limit)
  • evpn (VRF limit)

Data Plane

  • fabric_ecmp_imbalance
  • ecmp_imbalance_external_interfaces
  • mlag_imbalance
  • drain_node_traffic_anomaly
  • counters_error_anomalies
  • pkt_discard_anomalies
  • interface_queue_drops_anomalies
  • monitor_packet_loss
  • server_rtt
  • fabric_bgp_anomalies
  • interface_status_anomalies
  • leaf_bgp_vrf_anomalies

Traffic Patterns

  • fabric_hotcold_ifcounter
  • eastwest_traffic
  • bandwidth_utilization_history

Troubleshooting

  • Headroom

Virtual Infrastructure

  • virtual_infra_vlan_match
  • missing_vlan_vms
  • virtual_infra_lag_match
  • virtual_infra_missing_lldp_config
  • virtual_infra_hypervisor_redundancy_checks
  • hypervisor_mtu_checks
  • hypervisor_mtu_mismatch

Capacity Planning

  • arp_usage_anomalies
  • unicast_route_usage_anomalies
  • multicast_route_usage_anomalies
  • interface_bandwidth_anomalies

Multicast

  • anycast_rp_anomalies
  • anycast_rp_peer_count_anomalies
  • mroute_count_anomalies
  • pim_neighbor_anomalies
  • pim_rp_anomalies
  • vrfs_missing_rp