Skip to technology filters Skip to main content
Dynatrace Hub

Extend the platform,
empower your team.

Popular searches:
Home hero bg
Cisco Catalyst SD-WAN Manager (Viptela)Cisco Catalyst SD-WAN Manager (Viptela)
Cisco Catalyst SD-WAN Manager (Viptela)

Cisco Catalyst SD-WAN Manager (Viptela)

Get insights into the Cisco SD-WAN performance through the vManage API.

Extension
Free trialDocumentation
Cisco SD-WAN sample dashboardCisco SD-WAN sample dashboardSD-WAN infrastructure health screen in the I&O appDevice interfaces screen in the I&O appSelf-monitoring dashboard
  • Product information
  • Release notes

Overview

Cisco SD-WAN Extension uses Cisco Catalyst SD-WAN Manager API to collect performance metrics for the Cisco SD-WAN fabric managed by one or multiple Cisco SD-WAN Managers (vManage).

Use cases

  • Use Dynatrace for the entire network infrastructure monitoring
  • Get Cisco Catalyst SD-WAN infrastructure information into the Dynatrace
  • Extend Dynatrace insights into the Cisco SD-WAN fabric performance

Get started

Follow the Cisco SD-WAN Manager Configuration procedure described on the Documentation page.

For more information on the installation and configuration, please see Cisco Catalyst SD-WAN Manager (Viptela) extension in the Dynatrace Documentation.

Dynatrace
Documentation
By Dynatrace
Dynatrace support center
Subscribe to new releases
Copy to clipboard

Feature sets

Below is a complete list of the feature sets provided in this version. To ensure a good fit for your needs, individual feature sets can be activated and deactivated by your administrator during configuration.

Feature setsNumber of metrics included
Metric nameMetric keyDescriptionUnit
Certificate Days Remainingcisco.sdwan.device.certificate.days_remainingDays until this device's certificate expires. The value is SIGNED - it goes NEGATIVE once the certificate has expired, so -30 means it expired 30 days ago. Reported only for devices that actually have a certificate; unprovisioned inventory rows are skipped.Day
Metric nameMetric keyDescriptionUnit
SD-WAN Event Countcisco.sdwan.device.event_count.gaugeSD-WAN Device Event Count. Counts SD-WAN events reported by Cisco SD-WAN Manager (these are SD-WAN events, not Dynatrace events) per device and severity, per 5-minute interval. Each data point is timestamped with the interval it covers. Aggregate this metric with SUM, not AVG - averaging divides the count across devices and understates it heavily. Counts every severity, including those the Event Severity Filter excludes from the event log records. Event component is reported on the event log record, not as a metric dimension.Count
Metric nameMetric keyDescriptionUnit
TLOC Control Conns Upcisco.sdwan.device.circuit.control_connections_upNumber of active control connections from this transport to controllersCount
TLOC Control Conns Downcisco.sdwan.device.circuit.control_connections_downNumber of failed control connections from this transport to controllersCount
TLOC BFD Sessions Upcisco.sdwan.device.circuit.bfd_sessions_upActive BFD sessions on this transport (edge routers only; absent on controllers)Count
TLOC BFD Sessions Downcisco.sdwan.device.circuit.bfd_sessions_downInactive BFD sessions on this transport (edge routers only; absent on controllers)Count
TLOC Control Conns to vSmartscisco.sdwan.device.circuit.control_connections_to_vsmartsNumber of active control connections to vSmart controllers (controllers only; absent on edge routers)Count
TLOC Expected Control Connscisco.sdwan.device.circuit.expected_control_connectionsExpected number of control connections from this transport (sparse; present on vSmarts and vManage)Count
Metric nameMetric keyDescriptionUnit
Total duration of all rate-limited executed queries to all connection urls to collect data reported as metricssfm.cisco.sdwan.monitor.run.total.duration-Second
Total duration of all rate-limited synchronously executed queries to all connection urls to collect data reported as metricssfm.cisco.sdwan.monitor.run.sync.duration-Second
Metrics Data Collection Overall Asynchronous Timesfm.cisco.sdwan.monitor.run.async.durationTotal duration of all rate-limited asynchronously executed queries to all connection urls to collect data reported as metricsSecond
Metrics Data Collection Errorsfm.cisco.sdwan.monitor.run.errorIndicates whether an unhandled error occurred during execution of Metrics Data Collection.Count
get_site_health_stats Query Timesfm.cisco.sdwan.get_site_health_stats.duration-Second
get_site_health_stats Errorsfm.cisco.sdwan.get_site_health_stats.errorIndicates whether an error occurred during get_site_health_stats QueryCount
report_site_health_stats Overall Timesfm.cisco.sdwan.report_site_health_stats.durationWall-clock time of report_site_health_stats(). Unlike every other report_*.duration this one IS the real cost of the method: it runs alone, before the ThreadPoolExecutor, because it builds the site and device maps every other method depends on. Measured 2026-08-31 at 0.12s, matching its own get_*.duration - which is what proves the other report_* values are pool wall-clock, not per-method cost.Second
report_site_health_stats Errorsfm.cisco.sdwan.report_site_health_stats.errorIndicates whether an error occurred during report_site_health_statsCount
get_vedge_inventory_summary Query Timesfm.cisco.sdwan.get_vedge_inventory_summary.duration-Second
get_vedge_inventory_summary Errorsfm.cisco.sdwan.get_vedge_inventory_summary.errorIndicates whether an error occurred during get_vedge_inventory_summary QueryCount
report_vedge_inventory_summary Overall Timesfm.cisco.sdwan.report_vedge_inventory_summary.durationWall-clock time of report_vedge_inventory_summary(), measured inside the parallel collection phase - NOT the cost of the method itself. Most report_* methods run together in a thread pool, so under the GIL this value is dominated by the other threads and converges on the length of the whole parallel phase. Measured 2026-08-31: every get_*.duration was below 1s while report_* values formed a ladder up to 37s. Read the matching get_*.duration for the real API cost.Second
report_vedge_inventory_summary Errorsfm.cisco.sdwan.report_vedge_inventory_summary.errorIndicates whether an error occurred during report_vedge_inventory_summaryCount
get_device_health_overview_stats Query Timesfm.cisco.sdwan.get_device_health_overview_stats.duration-Second
get_device_health_overview_stats Errorsfm.cisco.sdwan.get_device_health_overview_stats.errorIndicates whether an error occurred during get_device_health_overview_stats QueryCount
report_device_health_overview Overall Timesfm.cisco.sdwan.report_device_health_overview.durationWall-clock time of report_device_health_overview(), measured inside the parallel collection phase - NOT the cost of the method itself. Most report_* methods run together in a thread pool, so under the GIL this value is dominated by the other threads and converges on the length of the whole parallel phase. Measured 2026-08-31: every get_*.duration was below 1s while report_* values formed a ladder up to 37s. Read the matching get_*.duration for the real API cost.Second
report_device_health_overview Errorsfm.cisco.sdwan.report_device_health_overview.errorIndicates whether an error occurred during report_device_health_overviewCount
get_hardware_health_summary Query Timesfm.cisco.sdwan.get_hardware_health_summary.duration-Second
get_hardware_health_summary Errorsfm.cisco.sdwan.get_hardware_health_summary.errorIndicates whether an error occurred during get_hardware_health_summary QueryCount
report_hardware_health_summary Overall Timesfm.cisco.sdwan.report_hardware_health_summary.durationWall-clock time of report_hardware_health_summary(), measured inside the parallel collection phase - NOT the cost of the method itself. Most report_* methods run together in a thread pool, so under the GIL this value is dominated by the other threads and converges on the length of the whole parallel phase. Measured 2026-08-31: every get_*.duration was below 1s while report_* values formed a ladder up to 37s. Read the matching get_*.duration for the real API cost.Second
report_hardware_health_summary Errorsfm.cisco.sdwan.report_hardware_health_summary.errorIndicates whether an error occurred during report_hardware_health_summaryCount
get_remote_system_cardinality Query Timesfm.cisco.sdwan.get_remote_system_cardinality.duration-Second
get_remote_system_cardinality Errorsfm.cisco.sdwan.get_remote_system_cardinality.errorIndicates whether an error occurred during get_approute_statistics_remote_system_cardinality QueryCount
report_remote_system_cardinality Overall Timesfm.cisco.sdwan.report_remote_system_cardinality.durationWall-clock time of report_remote_system_cardinality(), measured inside the parallel collection phase - NOT the cost of the method itself. Most report_* methods run together in a thread pool, so under the GIL this value is dominated by the other threads and converges on the length of the whole parallel phase. Measured 2026-08-31: every get_*.duration was below 1s while report_* values formed a ladder up to 37s. Read the matching get_*.duration for the real API cost.Second
report_remote_system_cardinality Errorsfm.cisco.sdwan.report_remote_system_cardinality.errorIndicates whether an error occurred during report_remote_system_cardinalityCount
get_tunnel_health_overview Query Timesfm.cisco.sdwan.get_tunnel_health_overview.duration-Second
get_tunnel_health_overview Errorsfm.cisco.sdwan.get_tunnel_health_overview.errorIndicates whether an error occurred during get_tunnel_health_overview QueryCount
report_tunnel_health_overview Overall Timesfm.cisco.sdwan.report_tunnel_health_overview.durationWall-clock time of report_tunnel_health_overview(), measured inside the parallel collection phase - NOT the cost of the method itself. Most report_* methods run together in a thread pool, so under the GIL this value is dominated by the other threads and converges on the length of the whole parallel phase. Measured 2026-08-31: every get_*.duration was below 1s while report_* values formed a ladder up to 37s. Read the matching get_*.duration for the real API cost.Second
report_tunnel_health_overview Errorsfm.cisco.sdwan.report_tunnel_health_overview.errorIndicates whether an error occurred during report_tunnel_health_overviewCount
get_approute_statistics_aggregation Query Timesfm.cisco.sdwan.get_approute_statistics_aggregation.duration-Second
get_approute_statistics_aggregation Errorsfm.cisco.sdwan.get_approute_statistics_aggregation.errorIndicates whether an error occurred during get_approute_statistics_aggregation QueryCount
report_statistics_approute Overall Timesfm.cisco.sdwan.report_statistics_approute.durationWall-clock time of report_statistics_approute(), measured inside the parallel collection phase - NOT the cost of the method itself. Most report_* methods run together in a thread pool, so under the GIL this value is dominated by the other threads and converges on the length of the whole parallel phase. Measured 2026-08-31: every get_*.duration was below 1s while report_* values formed a ladder up to 37s. Read the matching get_*.duration for the real API cost.Second
report_statistics_approute Errorsfm.cisco.sdwan.report_statistics_approute.errorIndicates whether an error occurred during report_statistics_approuteCount
get_devices_health Query Timesfm.cisco.sdwan.get_devices_health.duration-Second
get_devices_health Errorsfm.cisco.sdwan.get_devices_health.errorIndicates whether an error occurred during get_devices_health QueryCount
report_devices_health Overall Timesfm.cisco.sdwan.report_devices_health.durationWall-clock time of report_devices_health(), measured inside the parallel collection phase - NOT the cost of the method itself. Most report_* methods run together in a thread pool, so under the GIL this value is dominated by the other threads and converges on the length of the whole parallel phase. Measured 2026-08-31: every get_*.duration was below 1s while report_* values formed a ladder up to 37s. Read the matching get_*.duration for the real API cost.Second
report_devices_health Errorsfm.cisco.sdwan.report_devices_health.errorIndicates whether an error occurred during report_devices_healthCount
get_statistics_system_aggregation Query Timesfm.cisco.sdwan.get_statistics_system_aggregation.duration-Second
get_statistics_system_aggregation Errorsfm.cisco.sdwan.get_statistics_system_aggregation.errorIndicates whether an error occurred during get_statistics_system_aggregation QueryCount
get_interface_statistics Query Timesfm.cisco.sdwan.get_interface_statistics.duration-Second
get_interface_statistics Errorsfm.cisco.sdwan.get_interface_statistics.errorIndicates whether an error occurred during get_interface_statistics QueryCount
report_statistics_system Overall Timesfm.cisco.sdwan.report_statistics_system.durationWall-clock time of report_statistics_system(), measured inside the parallel collection phase - NOT the cost of the method itself. Most report_* methods run together in a thread pool, so under the GIL this value is dominated by the other threads and converges on the length of the whole parallel phase. Measured 2026-08-31: every get_*.duration was below 1s while report_* values formed a ladder up to 37s. Read the matching get_*.duration for the real API cost.Second
report_statistics_system Errorsfm.cisco.sdwan.report_statistics_system.errorIndicates whether an error occurred during report_statistics_systemCount
report_statistics_interface Overall Timesfm.cisco.sdwan.report_statistics_interface.durationWall-clock time of report_statistics_interface(), measured inside the parallel collection phase - NOT the cost of the method itself. Most report_* methods run together in a thread pool, so under the GIL this value is dominated by the other threads and converges on the length of the whole parallel phase. Measured 2026-08-31: every get_*.duration was below 1s while report_* values formed a ladder up to 37s. Read the matching get_*.duration for the real API cost.Second
report_statistics_interface Errorsfm.cisco.sdwan.report_statistics_interface.errorIndicates whether an error occurred during report_statistics_interfaceCount
-sfm.cisco.sdwan.get_alarms_count.duration--
-sfm.cisco.sdwan.get_alarms_count.error--
-sfm.cisco.sdwan.get_alarms_aggregation.duration--
-sfm.cisco.sdwan.get_alarms_aggregation.error--
-sfm.cisco.sdwan.get_alarms.duration--
-sfm.cisco.sdwan.get_alarms.error--
-sfm.cisco.sdwan.report_alarm_counts.duration--
-sfm.cisco.sdwan.report_alarm_counts.error--
-sfm.cisco.sdwan.report_alarm_log_events.duration--
-sfm.cisco.sdwan.report_alarm_log_events.error--
get_events Query Timesfm.cisco.sdwan.get_events.duration-Second
get_events Errorsfm.cisco.sdwan.get_events.errorIndicates whether an error occurred during get_eventsCount
report_event_log_events Overall Timesfm.cisco.sdwan.report_event_log_events.durationWall-clock time of report_event_log_events(), measured inside the parallel collection phase - NOT the cost of the method itself. Most report_* methods run together in a thread pool, so under the GIL this value is dominated by the other threads and converges on the length of the whole parallel phase. Measured 2026-08-31: every get_*.duration was below 1s while report_* values formed a ladder up to 37s. Read the matching get_*.duration for the real API cost.Second
report_event_log_events Errorsfm.cisco.sdwan.report_event_log_events.errorIndicates whether an error occurred during report_event_log_eventsCount
get_event_counts Query Timesfm.cisco.sdwan.get_event_counts.duration-Second
get_event_counts Errorsfm.cisco.sdwan.get_event_counts.errorIndicates whether an error occurred during get_event_countsCount
report_event_counts Overall Timesfm.cisco.sdwan.report_event_counts.durationWall-clock time of report_event_counts(), measured inside the parallel collection phase - NOT the cost of the method itself. Most report_* methods run together in a thread pool, so under the GIL this value is dominated by the other threads and converges on the length of the whole parallel phase. Measured 2026-08-31: every get_*.duration was below 1s while report_* values formed a ladder up to 37s. Read the matching get_*.duration for the real API cost.Second
report_event_counts Errorsfm.cisco.sdwan.report_event_counts.errorIndicates whether an error occurred during report_event_countsCount
get_tloc_status Query Timesfm.cisco.sdwan.get_tloc_status.duration-Second
get_tloc_status Errorsfm.cisco.sdwan.get_tloc_status.errorIndicates whether an error occurred during get_tloc_status QueryCount
report_tloc_status Overall Timesfm.cisco.sdwan.report_tloc_status.durationWall-clock time of report_tloc_status(), measured inside the parallel collection phase - NOT the cost of the method itself. Most report_* methods run together in a thread pool, so under the GIL this value is dominated by the other threads and converges on the length of the whole parallel phase. Measured 2026-08-31: every get_*.duration was below 1s while report_* values formed a ladder up to 37s. Read the matching get_*.duration for the real API cost.Second
report_tloc_status Errorsfm.cisco.sdwan.report_tloc_status.errorIndicates whether an error occurred during report_tloc_statusCount
get_certificates Query Timesfm.cisco.sdwan.get_certificates.duration-Second
get_certificates Errorsfm.cisco.sdwan.get_certificates.error-Count
report_certificates Query Timesfm.cisco.sdwan.report_certificates.durationWall-clock time of report_certificates(), measured inside the parallel collection phase - NOT the cost of the method itself. Most report_* methods run together in a thread pool, so under the GIL this value is dominated by the other threads and converges on the length of the whole parallel phase. Measured 2026-08-31: every get_*.duration was below 1s while report_* values formed a ladder up to 37s. Read the matching get_*.duration for the real API cost.Second
report_certificates Errorsfm.cisco.sdwan.report_certificates.error-Count
Metric nameMetric keyDescriptionUnit
-com.dynatrace.extension.network_device.if.in.pkts.count--
-com.dynatrace.extension.network_device.if.out.pkts.count--
Metric nameMetric keyDescriptionUnit
-com.dynatrace.extension.network_device.cpu_usage--
-com.dynatrace.extension.network_device.memory_usage--
-com.dynatrace.extension.network_device.sysuptime--
-com.dynatrace.extension.network_device.memory_used--
-com.dynatrace.extension.network_device.memory_free--
-com.dynatrace.extension.network_device.if.status--
-com.dynatrace.extension.network_device.if.bytes_in.count--
-com.dynatrace.extension.network_device.if.bytes_out.count--
-com.dynatrace.extension.network_device.if.in.errors.count--
-com.dynatrace.extension.network_device.if.out.errors.count--
-com.dynatrace.extension.network_device.if.in.discards.count--
-com.dynatrace.extension.network_device.if.out.discards.count--
Monitoring Statuscisco.sdwan.fabric_infra.monitoring_statusPer-connection availability of the SD-WAN Manager (1 = client connected and reachable, 0 = not). One data point per configured connection URL.Unspecified
Metric nameMetric keyDescriptionUnit
CPU Loadcisco.sdwan.device.cpu_loadSD-WAN Device CPU LoadPercent
Memory Utilizationcisco.sdwan.device.memory_utilizationSD-WAN Device Memory UtilizationPercent
Device Healthcisco.sdwan.device.healthSD-WAN Device Health Code Value (1 - green, 3 - yellow, 5 - red)Unspecified
Device Reachabilitycisco.sdwan.device.reachabilitySD-WAN Device Reachability Code Value (1 - reachable, 0 - unreachable)Unspecified
Device QoEcisco.sdwan.device.qoeSD-WAN Device QoE ScoreUnspecified
Metric nameMetric keyDescriptionUnit
CPU Systemcisco.sdwan.device.cpu_systemSD-WAN Device CPU System UtilizationPercent
CPU Usercisco.sdwan.device.cpu_userSD-WAN Device CPU User UtilizationPercent
CPU Idlecisco.sdwan.device.cpu_idleSD-WAN Device CPU IdlePercent
Memory Usedcisco.sdwan.device.mem_usedSD-WAN Device Memory UsedByte
Memory Freecisco.sdwan.device.mem_freeSD-WAN Device Memory FreeByte
Memory Bufferscisco.sdwan.device.mem_buffersSD-WAN Device Memory BuffersByte
Memory Cachedcisco.sdwan.device.mem_cachedSD-WAN Device Memory CachedByte
Processes Totalcisco.sdwan.device.totalpSD-WAN Device Total ProcessesCount
Processes Runningcisco.sdwan.device.runningpSD-WAN Device Running ProcessesCount
Disk Usedcisco.sdwan.device.disk_usedSD-WAN Device Disk UsedByte
Disk Availablecisco.sdwan.device.disk_availSD-WAN Device Disk AvailableByte
Metric nameMetric keyDescriptionUnit
Control Connscisco.sdwan.device.control_plane.control_connectionsTotal control connections this device has to controllers (vSmart, vBond and vManage), as reported by the device health response. vManage omits a counter rather than reporting zero, so this series can be absent for a device - absent is not 0. An alert pairing this metric with its counterpart must tolerate the counterpart being missing. Device total from the device health response - NOT the same scope as cisco.sdwan.device.circuit.* which is per transport colour from the TLOC API; the two can legitimately differ, for example a vBond has control connections but no TLOC rows.Count
Control Conns Upcisco.sdwan.device.control_plane.control_connections_upControl connections currently up to controllers. Compare against control_connections to detect a partial control-plane failure. vManage omits a counter rather than reporting zero, so this series can be absent for a device - absent is not 0. An alert pairing this metric with its counterpart must tolerate the counterpart being missing. Device total from the device health response - NOT the same scope as cisco.sdwan.device.circuit.* which is per transport colour from the TLOC API; the two can legitimately differ, for example a vBond has control connections but no TLOC rows.Count
vSmart Control Connscisco.sdwan.device.control_plane.vsmart_control_connectionsControl connections this device has to vSmart controllers. Populated for edges as well as controllers. vManage omits a counter rather than reporting zero, so this series can be absent for a device - absent is not 0. An alert pairing this metric with its counterpart must tolerate the counterpart being missing. Device total from the device health response - NOT the same scope as cisco.sdwan.device.circuit.* which is per transport colour from the TLOC API; the two can legitimately differ, for example a vBond has control connections but no TLOC rows.Count
Expected vSmart Connscisco.sdwan.device.control_plane.expected_vsmart_connectionsControl connections to vSmart controllers this device is expected to have. Compare against vsmart_control_connections to detect a missing controller session. vManage omits a counter rather than reporting zero, so this series can be absent for a device - absent is not 0. An alert pairing this metric with its counterpart must tolerate the counterpart being missing. Device total from the device health response - NOT the same scope as cisco.sdwan.device.circuit.* which is per transport colour from the TLOC API; the two can legitimately differ, for example a vBond has control connections but no TLOC rows.Count
OMP Peerscisco.sdwan.device.control_plane.omp_peersTotal Overlay Management Protocol (OMP) peers configured for this device. vManage omits a counter rather than reporting zero, so this series can be absent for a device - absent is not 0. An alert pairing this metric with its counterpart must tolerate the counterpart being missing. Device total from the device health response - NOT the same scope as cisco.sdwan.device.circuit.* which is per transport colour from the TLOC API; the two can legitimately differ, for example a vBond has control connections but no TLOC rows.Count
OMP Peers Upcisco.sdwan.device.control_plane.omp_peers_upOMP peers currently in an up state. Compare against omp_peers to detect a lost overlay routing session. vManage omits a counter rather than reporting zero, so this series can be absent for a device - absent is not 0. An alert pairing this metric with its counterpart must tolerate the counterpart being missing. Device total from the device health response - NOT the same scope as cisco.sdwan.device.circuit.* which is per transport colour from the TLOC API; the two can legitimately differ, for example a vBond has control connections but no TLOC rows.Count
BFD Sessionscisco.sdwan.device.control_plane.bfd_sessionsTotal Bidirectional Forwarding Detection (BFD) sessions on this device. Controllers have none, so the value is often absent for them. vManage omits a counter rather than reporting zero, so this series can be absent for a device - absent is not 0. An alert pairing this metric with its counterpart must tolerate the counterpart being missing. Device total from the device health response - NOT the same scope as cisco.sdwan.device.circuit.* which is per transport colour from the TLOC API; the two can legitimately differ, for example a vBond has control connections but no TLOC rows.Count
BFD Sessions Upcisco.sdwan.device.control_plane.bfd_sessions_upBFD sessions currently up. Compare against bfd_sessions to detect data-plane tunnel loss. vManage omits a counter rather than reporting zero, so this series can be absent for a device - absent is not 0. An alert pairing this metric with its counterpart must tolerate the counterpart being missing. Device total from the device health response - NOT the same scope as cisco.sdwan.device.circuit.* which is per transport colour from the TLOC API; the two can legitimately differ, for example a vBond has control connections but no TLOC rows.Count
TLOCs Totalcisco.sdwan.device.control_plane.total_tloc_numTotal Transport Locators (TLOC) on this device. vManage omits a counter rather than reporting zero, so this series can be absent for a device - absent is not 0. An alert pairing this metric with its counterpart must tolerate the counterpart being missing. Device total from the device health response - NOT the same scope as cisco.sdwan.device.circuit.* which is per transport colour from the TLOC API; the two can legitimately differ, for example a vBond has control connections but no TLOC rows.Count
TLOCs Upcisco.sdwan.device.control_plane.up_tloc_numTransport Locators currently up. Compare against total_tloc_num to detect a failed transport. vManage omits a counter rather than reporting zero, so this series can be absent for a device - absent is not 0. An alert pairing this metric with its counterpart must tolerate the counterpart being missing. Device total from the device health response - NOT the same scope as cisco.sdwan.device.circuit.* which is per transport colour from the TLOC API; the two can legitimately differ, for example a vBond has control connections but no TLOC rows.Count
Metric nameMetric keyDescriptionUnit
TLOC QoEcisco.sdwan.tloc.vqoe_scoreSD-WAN TLOC QoE Score aggregated as average across all mapped tunnelsUnspecified
TLOC Losscisco.sdwan.tloc.loss_percentageSD-WAN TLOC Loss Percentage aggregated as average across all mapped tunnels. Tunnels reporting exactly 100% loss (unreachable remote end, carrying only BFD probes and no payload traffic) are excluded from the average.Percent
TLOC Latencycisco.sdwan.tloc.latencySD-WAN TLOC Latency aggregated as average across all mapped tunnelsMilliSecond
TLOC Jittercisco.sdwan.tloc.jitterSD-WAN TLOC Jitter aggregated as average across all mapped tunnelsMilliSecond
TLOC TX Octetscisco.sdwan.tloc.tx_octetsSD-WAN TLOC TX Octets aggregated as sum across all mapped tunnelsByte
TLOC RX Octetscisco.sdwan.tloc.rx_octetsSD-WAN TLOC RX Octets aggregated as sum across all mapped tunnelsByte
TLOC Tunnelscisco.sdwan.tloc.tunnel_count.gaugeSD-WAN TLOC Tunnels determined by the cardinality of the Remote System IPsCount
Metric nameMetric keyDescriptionUnit
Sites Healthcisco.sdwan.fabric_infra.site_health_count.gaugeNumber of Sites per Health CodeCount
Devices Healthcisco.sdwan.fabric_infra.device_health_count.gaugeNumber of Devices per Health CodeCount
Hardware Statuscisco.sdwan.fabric_infra.hardware_summary_count.gaugeNumber of Devices per Hardware Status CodeCount
Inventory Statuscisco.sdwan.fabric_infra.inventory_summary_count.gaugeNumber of Devices per Inventory Status CodeCount
Tunnels Healthcisco.sdwan.fabric_infra.tunnel_health_count.gaugeNumber of Tunnels per Health CodeCount
Site Healthcisco.sdwan.site.site_healthSite Health Code Value (1 - Good, 3 - Fair, 5 - Poor)Unspecified
Site's Devices Healthcisco.sdwan.site.devices_healthSite's Devices Health Code Value (1 - Good, 3 - Fair, 5 - Poor)Unspecified
Site's Tunnels Healthcisco.sdwan.site.tunnels_healthSite's Tunnels Health Code Value (1 - Good, 3 - Fair, 5 - Poor)Unspecified
Site's Apps Usagecisco.sdwan.site.apps_usageSite's Apps UsageByte
Site's Apps Healthcisco.sdwan.site.apps_healthSite's Apps Health Code Value (1 - Good, 3 - Fair, 5 - Poor)Unspecified
Metric nameMetric keyDescriptionUnit
Admin Statuscisco.sdwan.interface.admin_statusSD-WAN Interface Admin StatusUnspecified
Oper Statuscisco.sdwan.interface.oper_statusSD-WAN Interface Oper StatusUnspecified
RX Packetscisco.sdwan.interface.rx_pktsSD-WAN Interface Packets RecievedCount
RX Octetscisco.sdwan.interface.rx_octetsSD-WAN Interface Octets RecievedByte
RX Errorscisco.sdwan.interface.rx_errorsSD-WAN Interface RX ErrorsCount
RX Dropscisco.sdwan.interface.rx_dropsSD-WAN Interface RX DropsCount
RX Packets Per Secondcisco.sdwan.interface.rx_ppsSD-WAN Interface Recieved Packets Per SecondPerSecond
RX KiloBit Per Secondcisco.sdwan.interface.rx_kbpsSD-WAN Interface Recieved KiloBit Per SecondKiloBitPerSecond
TX Packetscisco.sdwan.interface.tx_pktsSD-WAN Interface Packets TransmittedCount
TX Octetscisco.sdwan.interface.tx_octetsSD-WAN Interface Octets TransmittedByte
TX Errorscisco.sdwan.interface.tx_errorsSD-WAN Interface TX ErrorsCount
TX Dropscisco.sdwan.interface.tx_dropsSD-WAN Interface TX DropsCount
TX Packets Per Secondcisco.sdwan.interface.tx_ppsSD-WAN Interface Transmitted Packets Per SecondPerSecond
TX KiloBit Per Secondcisco.sdwan.interface.tx_kbpsSD-WAN Interface Transmitted KiloBit Per SecondKiloBitPerSecond
Uplink Capacity Utilizationcisco.sdwan.interface.up_cap_percSD-WAN Interface Uplink Capacity UtilizationPercent
Downlink Capacity Utilizationcisco.sdwan.interface.down_cap_percSD-WAN Interface Downlink Capacity UsagePercent
Metric nameMetric keyDescriptionUnit
Alarm Countcisco.sdwan.device.alarm_count.gaugeSD-WAN Device Alarm Count. Alarms counted per interval (Alarm Count Resolution, 15 minutes by default), each data point timestamped with the interval it covers. Aggregate this metric with SUM, not AVG - averaging divides the count across devices, components and rule names and understates it heavily.Count

Full version history

To have more information on how to install the downloaded package, please follow the instructions on this page.
ReleaseDate

Full version history

Update the certifi dependency to address CVE-2026-111943

Full version history

New in this version

  • This extension is now using all rich visualization features of Grail within Infrastructure & Operations App.

  • Alarm reporting improvements. Cisco SD-WAN raises a new alarm every day for a lasting problem, such as an expired certificate, and for many alarm types it never clears one. The extension now groups alarms by the condition they describe, so one condition raises one problem instead of one per alarm record. The problem stays open while the condition keeps being reported, and closes when the alarm clears or when it stops being reported. Each closing log record says which of the two happened.

    Note: Cisco SD-WAN alarms carry no correlation ID, so the extension works out which alarms belong to the same condition on a best-effort basis. If the grouping does not match what you expect, rely on the alarm log records: they hold the alarm payload exactly as Cisco SD-WAN Manager reported it.

  • Certificates. A new optional certificates feature set reports how many days are left before each device certificate expires. It covers controllers and edge routers.

    MetricDescription
    cisco.sdwan.device.certificate.days_remainingDays left until this device certificate expires

    It is split by fabric_infra, system_ip, host_name, site_id, site_name, device_model and device_type.

    A negative value means the certificate has already expired. For example, -30 means it expired 30 days ago.

    Three alert templates come with it: Certificate Expired, Expiry Imminent (7 days) and Expiring Soon (30 days). They do not overlap, so one certificate raises only one problem.

    The new Certificate Collection Frequency setting controls how often certificates are queried: every 30 minutes by default, from 15 to 1440 minutes.

  • Site names and coordinates on Smartscape nodes. You can now group a Smartscape segment by a readable site name instead of a site ID. Devices and sites also carry map coordinates, so you can place them on a Dynatrace map with no extra work.

    ⚠ Breaking change. The coordinate fields were renamed from latitude and longitude to geo.location.latitude and geo.location.longitude. Update any query or dashboard that reads the old names. Classic entities and the site screen are not affected.

  • Device control plane. A new optional device_control_plane feature set turns ten control-plane values into metrics. Each total has a matching up counter — compare the two to find a session that is down. Until now these values were only static device properties. You can now chart them, alert on them and use them in SLOs.

    MetricDescription
    cisco.sdwan.device.control_plane.control_connectionsTotal control connections this device has to vSmart, vBond and vManage
    cisco.sdwan.device.control_plane.control_connections_upControl connections that are currently up
    cisco.sdwan.device.control_plane.vsmart_control_connectionsControl connections to vSmart controllers
    cisco.sdwan.device.control_plane.expected_vsmart_connectionsControl connections to vSmart controllers this device should have
    cisco.sdwan.device.control_plane.omp_peersTotal OMP peers of this device
    cisco.sdwan.device.control_plane.omp_peers_upOMP peers that are currently up
    cisco.sdwan.device.control_plane.bfd_sessionsTotal BFD sessions of this device
    cisco.sdwan.device.control_plane.bfd_sessions_upBFD sessions that are currently up
    cisco.sdwan.device.control_plane.total_tloc_numTotal transport locators (TLOCs) of this device
    cisco.sdwan.device.control_plane.up_tloc_numTransport locators that are currently up

    All ten are split by fabric_infra, system_ip, host_name, site_id, site_name, friendly_site_name, device_model and device_type.

    New charts show them on the device and SD-WAN infrastructure screens.

    These are totals for the whole device. The Circuit availability metrics count similar sessions per transport, so the two sets of numbers do not add up to each other. That is expected.

    ⚠ Existing monitoring configurations must enable Device control plane before the metrics start to flow. New configurations have it on by default.

  • SD-WAN events as log records. Cisco SD-WAN Manager reports events as single points in time. Each one is now a Dynatrace log record with its severity, component, name, device and site, shown in a new SD-WAN Events card on the SD-WAN infrastructure, site and device screens. Events never become Dynatrace problems.

    ⚠ Collection is off by default. Turn on Report SD-WAN Events as Logs in the monitoring configuration, and set the SD-WAN Event Severity Filter before you do. All severities are collected unless you narrow it, and Minor events such as logins and logouts can be very frequent. Cisco SD-WAN Manager applies the filter itself, so excluded events are never transferred.

    The new SD-WAN Events Collection Frequency setting controls how often events are queried: every 15 minutes by default, from 5 to 360 minutes. It also sets how often the event count metric below is reported.

  • Event volume metric. A new optional events feature set, shown as SD-WAN events, counts the events Cisco SD-WAN Manager reports, so you can chart and alert on event volume.

    MetricDescription
    cisco.sdwan.device.event_count.gaugeNumber of SD-WAN events reported for this device, per severity and per 5-minute interval

    Note: In DQL, use the key cisco.sdwan.device.event_count, without .gauge. The FAQ Why do some metric keys end in .gauge or .count, and which key do I use in DQL? in the extension documentation explains why.

    It is split by fabric_infra, system_ip, host_name, site_id, site_name, friendly_site_name, device_model, device.address and event_severity.

    A new SD-WAN Events by Severity chart shows it on the SD-WAN infrastructure, site and device screens.

    ⚠ It is off by default and adds one API call per collection cycle. Existing monitoring configurations must enable SD-WAN events before the metric starts to flow.

    ⭐ Reporting SD-WAN events as log records is a separate thing and is not affected by this feature set. Log records are controlled only by the Report SD-WAN Events as Logs configuration property. You can have the log records without the metric, or the metric without the log records.

  • Davis event Smartscape enrichment. Every Cisco SD-WAN alarm Davis event is now enriched with the Smartscape source properties (dt.smartscape_source.id, dt.smartscape_source.type, dt.smartscape.ext_network_device) so that the event links to the correct EXT_NETWORK_DEVICE Smartscape node for RCA and entity-centric views. The node ID is computed deterministically with smartscape_id() from dt-ppx-utils.

Changed in this version

  • ⚠ The alarm count metric now reports one data point per time interval, timestamped with the interval it covers. Charts now line up with the alarm histogram in Cisco SD-WAN Manager, and intervals missed during a short outage are filled in afterwards. Please re-check any dashboard or alert built on this metric — it produces fewer data points than before.

    The interval is set by Alarm Count Resolution, 15 minutes by default. This setting was previously called Alarms Collection Frequency, which was misleading: it never changed how often alarms are collected. Renamed only, the behaviour is the same.

    Alarm log records and alarm-driven Dynatrace problems are not affected.

  • The alarm filter field Rule Name is now called Alarm Type, the name Cisco SD-WAN Manager uses in its alarms table. Renamed only: existing filters keep working.

  • Alarms and SD-WAN events are now grouped into tabs on the SD-WAN infrastructure, site and device screens, instead of five cards stacked down the page.

  • The alarm distribution charts are now stacked columns over time.

Fixed in this version

  • ⚠ TLOC octets are now reported as a delta metric. cisco.sdwan.tloc.rx_octets and cisco.sdwan.tloc.tx_octets count the bytes received and sent, so they are now reported as a delta instead of a gauge.

    • Latest Dynatrace (Grail): no impact.
    • Dynatrace classic (Data Explorer, classic dashboards and screens): after the upgrade, newly collected data points must be accessed using the keys cisco.sdwan.tloc.rx_octets.count and cisco.sdwan.tloc.tx_octets.count. Use these keys in Data Explorer and in your own charts; the extension's screens already use them. Data from before the upgrade is not lost: read it in Data Explorer with cisco.sdwan.tloc.rx_octets and cisco.sdwan.tloc.tx_octets.
  • An invalid Friendly Site Name Pattern no longer breaks collection. Patterns are checked when the extension starts and any problem is reported as a warning.

  • TLOC Smartscape node name fixed. It now reads host:colour:protocol — for example SDW_BR4:biz-internet:IPSEC. Existing nodes are renamed on the next entity report; no new TLOC nodes are created.

  • Lower memory use. The extension now needs less memory to collect statistics. This avoids the ActiveGate python memory limit. Nothing changes about which metrics are reported, or their values.

    If you still see memory problems, lower the page size in the expert settings. A smaller page needs less memory. But it also sends more requests to Cisco SD-WAN Manager, so you may need a longer metrics collection frequency. The FAQ in the documentation explains how to choose a value.

Full version history

New in this version

  • "Cisco SD-WAN — ISP Circuit Down" alert template. Raises an availability event when both the BFD sessions and the control connections of a WAN transport drop to zero at the same time, indicating that the ISP circuit itself is no longer operational rather than an individual tunnel failing. Controller transports are excluded. The template requires the circuit_availability feature set to be enabled. Its sliding window is sized for the default 5-minute collection frequency — if you change metrics_collection_frequency_minutes, set the template's slidingWindow to 3 × frequency + 1.

Fixed in this version

  • Fixed an invalid TLOC loss percentage calculation. Tunnels whose remote end is unreachable report exactly 100% loss while carrying only BFD probe packets and no payload traffic. These tunnels were included in the average and dominated it, so the reported loss was far higher than the actual loss on the transport. They are now excluded from the aggregation. On fabrics that have unreachable remote sites, cisco.sdwan.tloc.loss_percentage will drop substantially after this upgrade.
  • TLOC statistics are now aggregated into 10-minute buckets instead of 5-minute ones, matching the native SD-WAN statistics cycle.
  • The TLOC statistics aggregation window is now shifted 15 minutes into the past, so that only fully populated statistics buckets are aggregated. Previously the most recent bucket was still being filled while it was read, which produced values calculated from an incomplete dataset.

Full version history

⚠️ WARNING ⚠️️: Possible breaking changes and warnings — PLEASE READ before upgrading

  • This version requires a minimum Dynatrace version of 1.338.0 and a minimum EEC version of 1.333.0.
  • This version includes a possible breaking change for Dynatrace on Grail.
    • With the inclusion of OpenPipeline processing rules, any metrics ingested from the extension will be processed by a dedicated OpenPipeline pipeline instead of the default pipeline.
    • This means that any custom dynamic rules you created will no longer apply to metrics from this extension. To keep enforcing them, please create pipeline groups.
    • Additionally, some field names are handled differently in OpenPipeline (e.g. capitalization). Please double-check any custom dashboards and alerts you created for this extension.
    • You must opt-in to OpenPipeline configuration via Settings API — see the documentation.

New in this version

  • Smartscape on Grail. This extension will populate new Smartscape nodes and edges via OpenPipeline extraction.
  • Primary tags and Primary fields (monitoring configuration): two new optional sections on the endpoint configuration make this release ready to support the upcoming global entity tagging functionality.

Full version history

New in this version

  • Added SD-WAN alarm observability:
    • alarm count metric cisco.sdwan.device.alarm_count.gauge
    • optional alarm reporting as logs with severity-based filtering
    • optional creation of Dynatrace events with configurable rules, including per-condition overrides and suppression
    • Infrastructure, Site, and Device screens now include alarm coverage: Alarm Severity, Alarm Component, Alarm Rule Name, and Active/Inactive status
  • Added documentation note for Cisco SD-WAN alarm API RBAC:
    • to enable SD-WAN alarms, update the custom monitoring role to include Alarms: Read
    • required custom-role read permissions are documented in the Cisco SD-WAN extension documentation

Improved in this version

  • Added periodic updates of Site, Device, and Interface properties, reported as log events with configurable frequency:
    • Site: Devices Health, Tunnels Health, Apps Health, Latitude, Longitude
    • Device: Software Version, Control Connections Up, Control Connections, vSmart Control Connections, Expected vSmart Connections, Up Since, BFD Sessions Up, BFD Sessions, OMP Peers Up, OMP Peers, Board Serial Number, Chassis Number
    • Interface: BW Up, BW Down
  • Updated alarm activation configuration:
    • Report Alarm Logs: alarm log output with severity filtering
    • Report Alarm Events: Dynatrace event creation per alarm
    • Alarm Reporting Rules: per-rule event configuration and suppression
    • Entities Reporting Frequency: entity log update frequency (default 60 minutes)
  • Added scheduling overlap detection: if a monitor run is still active when the next one is due, the new run is skipped with a warning log and DEC code. If this occurs frequently, increase the reporting frequency.
  • Added maximum limit of 30 seconds for the Single Request Timeout connection setting.
  • ⚠️ Important: If the timeout was previously configured above 30 seconds, update it to a value within the new limit (1–30 seconds) before upgrading.

Full version history

Improved in this version

  • Fixed cisco.sdwan.site.devices_health metric reporting wrong value (was using site health instead of devices health).
  • Fixed TLOC metrics reporting for devices with multiple protocols.
  • Added reporting for the dt.ip_addresses property on devices.

Full version history

This is the first release of the Cisco SD-WAN extension. Looking forward to your feedback on the Dynatrace Community.

Dynatrace Hub
Get data into DynatraceBuild your own app
Dynatrace Intelligence - The Agentic PlatformThe Dynatrace Agentic AI ecosystem
All (950)Log Management and AnalyticsKubernetesAI and LLM ObservabilityInfrastructure ObservabilitySoftware DeliveryApplication ObservabilityApplication SecurityBusiness ObservabilityDigital Experience
Filter
Type
Built and maintained by
Partner FinderBecome a partnerDynatrace Developer

Discover recent additions to Dynatrace

Arize AX logo

Arize AX

Analyze traces, latency, and evals of LLM apps through Arize OpenInference data.

AI Observability logo

AI Observability

End-to-end observability for your Agentic AI and LLM workloads.

Dynatrace Assist logo

Dynatrace Assist

Dynatrace Assist: Ask, analyze, and act with Dynatrace Intelligence.

SRE Agent logo

SRE Agent

Analyze and triage incidents.

Smartscape logo

Smartscape

Interactively explore and analyze topology and relationships in digital systems.

Clouds logo

Clouds

Gain full visibility and proactive monitoring across your cloud infrastructure.

Analyze your data

Understand your data better with deep insights and clear visualizations.

Notebooks logo

Notebooks

Create powerful, data-driven documents for custom analytics and collaboration.

Dashboards logo

Dashboards

Transform complex data into clear visualizations with custom dashboards.

Investigations logo

Investigations

Fast and precise incident response on Grail data with DQL queries.

Smartscape logo

Smartscape

Interactively explore and analyze topology and relationships in digital systems.

Logs logo

Logs

Explore all your logs without writing a single query.

Problems logo

Problems

Detect, explain and triage problems automatically using Dynatrace Intelligence.

Automate your processes

Turn data and answers into actions, securely, and at scale.

Workflows logo

Workflows

Automate tasks in your IT landscape and move towards autonomous operations.

Jira logo

Jira

Open, update, and close Jira tickets automatically from Dynatrace Workflows.

Slack logo

Slack

Automate Slack messaging for security incidents, attacks, remediation, and more.

Secure your cloud application

See vulnerabilities and attacks in your environment.

Security Posture Management logo

Security Posture Management

Detect, prioritize, and remediate security and compliance findings with SPM.

Threats & Exploits logo

Threats & Exploits

Understand, triage, and investigate detection findings and alerts.

More resources

Cursor (Live-Debugger) logo

Cursor (Live-Debugger)

Get Real time Code-Level data directly to your Cursor IDE.

Documents logo

Documents

Manage Dashboards, Notebooks and other documents in your Dynatrace environment.

GitHub Copilot Coding Agent logo

GitHub Copilot Coding Agent

Automate vulnerability remediation and boost developer productivity.

GitHub Copilot Custom Agent logo

GitHub Copilot Custom Agent

Automate your development workflows with specialized agent definitions.

Dynatrace Live Debugger on JetBrains logo

Dynatrace Live Debugger on JetBrains

Get real-time code-level data directly to your Jetbrains IDE.

Metrics logo

Metrics

Browse, search, and manage all your metrics in one central catalog.

Dynatrace Live Debugger on Windsurf logo

Dynatrace Live Debugger on Windsurf

Get real-time code-level data directly to your Windsurf IDE.

Are you looking for something different?

We have hundreds of apps, extensions, and other technologies to customize your environment

Leverage our newest innovations of Dynatrace Saas

Kick-start your app creation

Kick-start your app creation

Whether you’re a beginner or a pro, Dynatrace Developer has the tools and support you need to create incredible apps with minimal effort.
Go to Dynatrace Developer
Upgrading from Dynatrace Managed to SaaS

Upgrading from Dynatrace Managed to SaaS

Drive innovation, speed, and agility in your organization by seamlessly and securely upgrading.
Learn More
Log Management and Analytics

Log Management and Analytics

Innovate faster and more efficiently with unified log management and log analytics for actionable insights and automation.
Learn more