Showing results for 
Search instead for 
Did you mean: 
Cisco Employee
Cisco Employee



Cisco AI Endpoint Analytics (EA) has 3 primary responsibilities. 

1. EA aggregates meta data from various sources such as SDAVC, machine learning, ISE probes, asset information from Service Now, and others in the future.

2. To evaluate data from these multiple sources to profile and label the endpoint by endpoint type, OS type, hardware model, and hardware manufacturer with greater granularity. These labels are sent as attributes over to ISE for use In authorization rules.
3. To reduce the number of net unknowns by constantly using AI to group endpoints having common attributes that helps admin to label them. The groups and labels is shared with others customers(crowd sourcing) for better usability and to improve efficacy.


Before getting into further details, let’s start by explaining some fundamental terms:

  • Probe – Examines communications on a specific TCP and/or UDP port
  • Rules - Classification logic that maps raw data into device identities
  • Profiler – Classify devices based on Probe data and Rules
  • Multi-factor classificationProfiling a device based on different aspects of the Endpoint such as Endpoint Type, Manufacturer, Model and OS Type.
  • Label – a name applied to classify endpoints into a category
  • NBAR2 - Network-Based Application Recognition, is a classification engine that recognizes and classifies a wide variety of protocols and applications, including web-based and other difficult-to-classify applications and protocols that use dynamic TCP/User Datagram Protocol (UDP) port assignments
  • SDAVC – application visibility service on Cisco DNA Center (aka Software-Defined Application Visibility)


Endpoint Meta Data Sources

Software Defined Application Visibility and Control (SDAVC)

SDAVC is the application visibility services that runs on Cisco DNA Center, also refered to as “the controller”.  AVC uses Network Based Application Recognition2(NBAR2), an embedded technology built-in to Cat9K that utilizes deep packet inspection (DPI) across several protocols, to identify over 1400 applications within the network traffic flow, using L4 to L7 data.


A new functionality in NBAR2 on the Catalyst 9000 series switches and Cisco 9800 wireless controller provides a quick identification of application ports and protocols and can do quick classification based on for eg: DHCP class ID or DICOM. It uses this as a pointer to further do deep packet inspection to gather asset information from different protocols. NBAR2 support application protocol that cuts across IT, Building automation, IOT, Healthcare etc. Further it will collect information based on discovery protocols such as CDP, LLDP, SNMP etc.  It will then pack the probe data and send it to the AI Endpoint Analytics Engine for more comprehensive and complex classfication that will identify multiple profile labels.

ISE Discovery Mechanism and probe data


ISE profiler collects endpoint meta data using traditional protocols such as RADIUS, DHCP, SNMP etc. to fingerprint IT assets.  Endpoint data can also include ACIDEX information (AnyConnect scan of the endpoint), Active Directory attributes such as AD Operating-system, AD-OS-version, AD-Service-pack, AD-join-point, AD-Host-exists,  and MDM attributes such as model, OS-Version, IMEI, etc.


This data is sent from ISE to EA as additional context from endpoints that are connected to non-NBAR2 capable access switches and wireless lan controllers or the Cisco Telemetry Sensor.

Service NOW

EA will have the capability to only receive asset information from Service NOW currently. This will be augmented to bi-directional communication in future with support for other configuration management databases.




Rule Management

Cisco AI Endpoint Analytics granular multi-faceted device classification which is based on DPI (NBAR2), AI/ML taken from the network as well as leveraging various probe data attributes which are collected from different sources, like ISE or 3rdparties like Service Now.


The following types of rules are supported in first release. The classification happens at AI Endpoint Analytics Engine in DNAC (is based on these rules).


System rules - These are the rules which are built-in and defines most of the standard known devices based on attributes gathered from the network devices directly.  NBAR / SDAVC enabled devices run an SDAVC agent on the device which connects to the SDAVC controller on DNAC. The protocol packs that is used by NBAR is fed by the controller from the cloud. System rules are updated at regular intervals.

System rules - System rules are bulti-in to AI Endpoint Analytics product. This gets updated at frequent intervals.

  • Static - This is created based on probes/values already known and should have parity with ISE.
  • Dynamic - This is based on dynamically learning information from protocols such as DICOM/HL7 where the values could be different based on the type of the device.

Custom rules – These are user definded rules defined by the Administrator by choosing attributes and values to match for static mapping. These rules can be exported to a different DNAC system.
ML rules – based on active labeling handled by ML cloud. The user will be presented with clusters of unknown endpoints and rules. After providing a label for a group, a corresponding rule will be added to EA and unknown endpoints will be classified accordingly. ML rules are instantly applied to a set of already grouped endpoints. This is semi-automated user driven rule.


Rules are prirotized in the following order: Custom rules, System Rules and AI/ML Rules.


Endpoints can be registered in bulk and these appear as registered endpoints by administrators. When this happens UI updates the "Registration" column in the Endpoint inventory screen.

ISE Parity

EA System rules will have parity with ISE profiles and the number of system rules is much more than ISE system profiles


Custom profiles in ISE can be exported to a CSV but cannot be imported in AI Endpoint Analytics due to its nature and difference. AI Endpoint Analytics supports dynamic way of profiling based on actively listening to protocol traffic and analyzing the.  This will reduce the need to use custom profiles while you are transitioning. The solution will be able to quickly identify endpoints, that was not idenfiable by ISE and where you had to create custom profile. IAs and when these endpoints start talking to the network it will be idenfied quickly.


You can still use EA custom rules if you know the probes and attributes to create something similar to ISE custom profiles. However, the goal is for the product to automatically classify it and not need much user intervention.

Triggering classification/re-classification

The events that trigger classification/re-classification in SDAVC controller are:

  1. New device with attributes connected/authenticated to network.
  2. Attribute update. This includes any new attributes received from the endpoint upon reconnect or any old attribute with new value received from the endpoint.
  3. Custom/ML/feed rule updated in the system triggering reclassification of endpoints. The ML rules are the lowest priority in the system and hence if a device is already classified, EA would skip reclassification, thus leading to reclassification of previously “unknown” endpoints.
  4. New system rules and protocol packs are updated from SDAVC Cloud at regular intervals


In situations where data from the various data sources result in different classification result, EA will provide the “conflict resolution” function to retain or discard the older known classification result.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: