Cisco Catalyst how Highlight gathers information
Overview
This page shows the calls Highlight uses to gather data on a Cisco Catalyst SD-WAN network.
This documentation was written for vManage 19.2 and later.
Cisco Catalyst vManage requirements
Expected to run on port 443.
Requires agent has correct SSL root certificates installed to trust Cisco Catalyst vManage.
The vManage controller must be specified in Highlight with the DNS name listed on the SSL certificate.
The agent must support a TLS client version that matches the TLS version on the vManage controller.
Cisco Catalyst SD-WAN API calls used by Highlight: Authentication
1
/j_security_check
Occurs on startup, new controller addition and if token expires. Credentials sent
2
/dataservice/client/token
On success token requested
Cisco Catalyst SD-WAN API calls used by Highlight: Discovery
Highlight uses the following API calls to discover the devices and state of the network. Highlight only uses Read Only calls for all information collected. If you have any questions on how we use this information, please contact us.
1
/dataservice/device/
Occurs on agent startup and every 10 minutes. Obtain a list of all devices and sites. This call is also used to obtain the total CPU count for vManage to help with tuning API concurrency.
2
/dataservice/data/device/state/Interface
Obtain a list of all interfaces (Bulk API call): Cisco Catalyst OS devices.
3
/dataservice/data/device/state/CEdgeInterface
IOS XS OS devices
Process Discovery Results
If selected, locations are created within Highlight using the vManage SiteID; otherwise all watches are created in a single Highlight location.
A watch is created for each interface discovered with the following characteristics:
port-type: "transport" (Additional port types may be added in the future)
af-type: "ipv4"
if-oper-status: "Up"
Cisco Catalyst SD-WAN API calls used by Highlight: Polling
Once watches are created, they are polled for new data every 180 seconds.
The poll requests are throttled to a maximum of 10 x vManage "total_cpu_count" (obtained during discovery).
All responses from each batch of requests need to be completed before another batch of concurrent requests will be sent.
Currently the polling of all watches is scheduled within a 90 second window to allow time for delays in API replies. The time between starting each poll for a given device remains 180 seconds.
1
Device List
N/A
/dataservice/device
2
Device interfaces
deviceId
/dataservice/device/interface?deviceId={:deviceid}deviceid
3
BFD sessions
N/A
/dataservice/data/device/state/BFDSessions
4
Device status
deviceId
/dataservice/device/system/status?deviceId={deviceId}
5
Tunnel statistics
deviceId
/dataservice/device/tunnel/statistics?deviceId={deviceId}
6
App-Route statistics
deviceId
/dataservice/device/app-route/statistics?deviceId={deviceId}
7
Interfaces
N/A
/dataservice/data/device/state/Interface
8
CEdge interfaces
N/A
/dataservice/data/device/state/CEdgeInterface
Related
Admin Controllers page in Highlight
Was this helpful?

