Cisco Catalyst Center (DNA Center) extension

  • Latest Dynatrace
  • Extension
  • Published Oct 27, 2025

Get insights into your Cisco Catalyst Center infrastructure.

Get started

Overview

Cisco Catalyst Center is formerly known as Cisco DNA.

Collect information about networks that are managed by the Cisco Catalyst Center.

This extension assumes that you:

  • Use Dynatrace for infrastructure monitoring.
  • Run Cisco Catalyst Center in their environment.
  • Look to extend Dynatrace insights into the Cisco Catalyst platform.

The Cisco Catalyst Center extension uses the Cisco Catalyst API to collect information about networks that are managed by Cisco Catalyst Center.

Cisco Catalyst Center dashboard

Cisco Catalyst Center device characterization

Cisco Catalyst Center inventory in Infrastructure and Operations

Use cases

  • Integrate operational monitoring of the infrastructure, including Cisco Catalyst and leveraging additional organization, network and device metadata.
  • Get root cause analysis of network issues, in the light of the entire application and infrastructure landscape observed by Dynatrace.
  • Collect network infrastructure data without having to poll individual devices.

Requirements

  • Network access from a Dynatrace ActiveGate to the Cisco Catalyst Center.

  • You have configured the Cisco Catalyst Center.

  • Optional You have created a read-only role specific for API access. A specific role is not required, but is necessary for privilege management. If not used, the pre-defined role is used by default.

    To create a role:

    • Go to System > Users & Roles > Role Based Access Control > Create a New Role.
    • Define the name (for example, API-READONLY-ROLE) and an optional description.
    • For all privileges, select READ.
  • You have created a user for API integration. To create a user:

    • Go to System > Users & Roles > User Management > Add User.
    • Select a role, whether the read-only role or the pre-defined role.
  • Optional Check access control.

    • Go to System > Trust & Privacy > IP Access Control
    • If access control filtering is enabled, add the IP address of your Dynatrace system.

Compatibility information

  • Cisco Catalyst Center (DNA) version 2.3.7.6+ (For more information on API compatibility, see FAQ.)

Activation and setup

To enable the extension, find Cisco Catalyst Center (DNA Center) in the Dynatrace Hub.

Details

This extension can monitor the following entities:

  • Catalyst Center
  • Catalyst Site
  • Catalyst Device
  • Catalyst Interface

The extension offers the following features:

  • Insights into the configuration, locations, and health status of devices and their interfaces.
  • Analysis screens present data hierarchically, helping to quickly diagnose issues by site, role or by device platform.
  • Performance and health metrics as well as Cisco Catalyst issues/events. Basic statistics of client devices are also available.
  • Extension code (Python) that connects to the Cisco Catalyst API endpoints and scrapes the metrics.
  • A dashboard offering high-level Cisco Catalyst platform overview.
  • Unified Analysis pages for Cisco Catalyst Center, devices, sites and interfaces.
  • Analysis screens integrated with Infrastructure & Operations Infrastructure & Operations.
  • Optional issue reporting and event generation based on Catalyst Center issues, configurable to fit your environment.
  • Optional tag-based metric reporting frequency control using Catalyst device tags.

Issue reporting and event integration

The extension includes support for ingesting issues from Catalyst Center.

Issues are either reported as log messages or raised as Dynatrace events.

  • Issues can be reported as log messages. You can configure filtering by issue priority to report only the relevant ones.

  • Issues can be raised as Dynatrace events. This enables the following advanced capabilities:

    • Custom event type mapping: Map issue priorities or device families to specific Dynatrace event types (e.g., ERROR_EVENT, CUSTOM_ALERT, CUSTOM_INFO).
    • Default and conditional event overrides: Use a default event type (ERROR_EVENT) with support for condition-based overrides.
    • Event Suppression: Optionally suppress certain events entirely using a special suppression value.

    Event generation applies only to issues that are already enabled for log message reporting.

Report metrics based on Catalyst tags

Cisco Catalyst API version 2.3.7.6+

This feature lets you control how often metrics are reported for devices and interfaces, based on Catalyst tags. It does not affect how often data is polled from Cisco Catalyst Center; it only controls how often metrics are reported to Dynatrace.

Key capabilities:

  • Tag-based frequency control: Set custom reporting intervals for metrics based on Catalyst device tags.
  • Untagged device handling: Define how often to report metrics for devices without Catalyst tags.
  • Flexible tag mapping: Configure multiple tag-to-frequency mappings.
  • Selective suppression: Metric reporting for devices and their interfaces can be fully disabled based on specific Catalyst tags.

Extension metrics grouping via feature sets

Metrics collected by the Cisco Catalyst extension are categorized in the following feature sets:

  • Default: Provides an overview of the overall health status in Cisco Catalyst Center. Includes interface NAD device-specific metrics used in Infrastructure & Operations Infrastructure & Operations.
  • Site: Contains metrics related to Catalyst Sites managed by Cisco Catalyst Center.
  • Device: Covers metrics for Catalyst Devices managed by Cisco Catalyst Center.
  • Interface: Captures metrics for Catalyst Interfaces on managed devices.
  • Client: Overall statistics for clients as reported by the Catalyst Center.
  • Self-monitoring: Optional Metrics for fine-tuning and diagnostics of the extension itself.

Discovery frequencies adjustment

If you reduce the metrics collection frequency (for example, when adapting to a large environment constraints), it is also recommended to adjust discovery-related configuration parameters accordingly. These parameters should be increased proportionally, since they track semi-static attributes that do not need to be refreshed as frequently. Entity attributes and metrics dimension values are then updated according to the defined discovery frequencies.

These discovery intervals determine how often relatively static attributes are queried from Cisco Catalyst Center. By increasing these values proportionally, you reduce unnecessary load without compromising data accuracy.

ParameterRecommended multiplierRecommended frequency, based on a five-minute metric frequency
Sites discovery frequency1260 minutes
Devices discovery frequency630 minutes
Interfaces discovery frequency315 minutes

Licensing and cost

The use of this extension incurs consumption of your Dynatrace license based on the data that the extension ingests. The details of license consumption will depend on which licensing model you are using, whether DPS or a Classic License.

Metrics powered by Grail (DPS)

DPS license consumption is based on the number of metric data points ingested. The following formula provides an approximate amount of annual data point ingest, assuming all feature sets are enabled.

(
( 29
+ ( 7 * <Number of sites> )
+ ( 14 * <Number of monitored devices> )
+ ( 3 * <Number of monitored interfaces> )
+ ( 11 * <Number of monitored interfaces with operational status `UP`> )
) / <metrics collection interval>
+ 2 * Number of sites / <sites discovery interval>
+ 2 * Number of monitored devices / <devices discovery interval>
+ 1 * Number of monitored interfaces / <interface discovery interval>
+ 25 // optional - self-monitoring metrics
+ 13 // optional - self-monitoring metrics (tracking communication errors with Catalyst Center - reported only if errors occur)
) * 60 minutes * 24 hours * 365 days data points per year

Classic licensing

For Dynatrace classic licenses, metric ingestion consumes Davis Data Units (DDUs) at the rate of .001 DDUs per metric data point. For more information, see DDUs for metrics.

To estimate annual DDU consumption, multiply the result of the formula in Metrics powered by Grail (DPS) by .001.

Feature sets

When activating your extension using monitoring configuration, you can limit monitoring to one of the feature sets. To work properly the extension has to collect at least one metric after the activation.

In highly segmented networks, feature sets can reflect the segments of your environment. Then, when you create a monitoring configuration, you can select a feature set and a corresponding ActiveGate group that can connect to this particular segment.

All metrics that aren't categorized into any feature set are considered to be the default and are always reported.

A metric inherits the feature set of a subgroup, which in turn inherits the feature set of a group. Also, the feature set defined on the metric level overrides the feature set defined on the subgroup level, which in turn overrides the feature set defined on the group level.

interface
Metric nameMetric keyDescription
Interface Countcisco.cc.device.total_interface_count.gaugeTotal Number of Interfaces for Device
Admin Statuscisco.cc.interface.admin_statusInterface's Admin Status (1: UP | 0: DOWN)
Oper Statuscisco.cc.interface.oper_statusInterface's Status (1: UP | 0: DOWN)
Speedcisco.cc.interface.speed
TX Ratecisco.cc.interface.txRate
TX Utilizationcisco.cc.interface.txUtilization
TX Discardscisco.cc.interface.txDiscards
TX Errorscisco.cc.interface.txError
RX Ratecisco.cc.interface.rxRate
RX Utilizationcisco.cc.interface.rxUtilization
RX Discardscisco.cc.interface.rxDiscards
RX Errorscisco.cc.interface.rxError
default
Metric nameMetric keyDescription
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_total
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
self-monitoring
Metric nameMetric keyDescription
Overall Metrics Data Collection Timesfm.cisco.cc.monitor.run.durationTotal duration of all Statistics Data Queries to collect data reported as metrics (excluding Discovery Data Queries for retrieving entity attributes)
Metrics Data Collection Errorsfm.cisco.cc.monitor.run.errorIndicates whether an error occurred during the most recent data collection.
Rejected Statistics Data Queriessfm.cisco.cc.collection.timeoutNumber of Statistics Data Queries not executed during the most recent data collection to prevent overlap. Refers to Statistics Data Queries used to collect metric data.
Device Discovery Data Query Durationsfm.cisco.cc.devices.get_network_device_by_pagination_range.durationDuration of the paged query devices.get_network_device_by_pagination, used to discover devices and collect their attributes.
Device Discovery Data Query Errorssfm.cisco.cc.devices.get_network_device_by_pagination_range.errorNumber of errors that occurred during the most recent device discovery run of the paged queries devices.get_network_device_by_pagination, used to discover devices and collect their attributes.
Device Statistics Data Query Durationsfm.cisco.cc.devices.devices.durationDuration of the paged query devices.devices, used to collect device metrics.
Device Statistics Data Query Errorssfm.cisco.cc.devices.devices.errorNumber of errors that occurred during the most recent data collection for the paged query devices.devices, used to collect device metrics.
Devices Count Query Durationsfm.cisco.cc.devices.get_device_count.durationDuration of the query devices.get_device_count, used to get number of devices
Devices Count Query Errorssfm.cisco.cc.devices.get_device_count.errorNumber of errors that occurred during the most recent data collection or device discovery run for the query devices.get_device_count, used to retrieve the number of devices.
Submitted Device Statistics Query Taskssfm.cisco.cc.endpoint.get_devices_statistics_async.submittedNumber of submitted tasks to run the paged query devices.devices, used to collect device metrics.
Submitted Device Discovery Query Taskssfm.cisco.cc.device_cache.cache_network_device_by_page.submittedNumber of submitted tasks to run the paged query devices.get_network_device_by_pagination, used to discover devices and collect their attributes.
Interface Discovery Data Query Durationsfm.cisco.cc.devices.get_all_interfaces.durationDuration of the paged query devices.get_all_interfaces, used to discover interfaces and collect their attributes.
Interface Discovery Data Query Errorssfm.cisco.cc.devices.get_all_interfaces.errorNumber of errors that occurred during the most recent interface discovery run of the paged queries devices.get_all_interfaces, used to discover interfaces and collect their attributes.
Interface Statistics Data Query Durationsfm.cisco.cc.devices.gets_interfaces_along_with_statistics_data_from_all_network_devices.durationDuration of the paged query devices.gets_interfaces_along_with_statistics_data_from_all_network_devices, used to collect interface metrics.
Interface Statistics Data Query Errorssfm.cisco.cc.devices.gets_interfaces_along_with_statistics_data_from_all_network_devices.errorNumber of errors that occurred during the most recent data collection for the paged query devices.gets_interfaces_along_with_statistics_data_from_all_network_devices, used to collect interface metrics.
Total Interface Statistics Queries Durationsfm.cisco.cc.endpoint.fetch_ifaces_statistics.durationTotal duration of all paged queries, used to collect interface metrics.
Interfaces Count Query Durationsfm.cisco.cc.devices.get_device_interface_count.durationDuration of the query devices.get_device_interface_count, used to retrieve number of interfaces
Interfaces Count Query Errorssfm.cisco.cc.devices.get_device_interface_count.errorNumber of errors that occurred during the most recent data collection or interface discovery run for the query devices.get_device_interface_count, used to retrieve the number of interfaces.
Submitted Interface Discovery Query Taskssfm.cisco.cc.interface.cache_ifaces_by_page.submittedNumber of submitted tasks to run the paged query devices.get_all_interfaces, used to discover interfaces and collect their attributes.
Submitted Interface Statistics Query Taskssfm.cisco.cc.endpoint.get_ifaces_data_by_view_async.submittedNumber of submitted tasks to run the paged query devices.gets_interfaces_along_with_statistics_data_from_all_network_devices, used to collect interface metrics.
Total Interface Statistics Data Recordssfm.cisco.cc.endpoint.fetch_ifaces_statistics.fetched_statisticsNumber of interface statistics data records in the responses of all paged queries devices.gets_interfaces_along_with_statistics_data_from_all_network_devices, used to collect interface metrics.
Total Device Statistics Queries Durationsfm.cisco.cc.endpoint.get_device_statistics_dict.durationTotal duration of all paged queries, used to collect device metrics.
Total Device Statistics Data Recordssfm.cisco.cc.endpoint.get_device_statistics_dict.reported_devicesNumber of device statistics data records in the responses of all paged queries devices.devices, used to collect device metrics.
Site Discovery Data Query Durationsfm.cisco.cc.sites.get_site.durationDuration of the paged query sites.get_site, used to discover sites and collect their attributes.
Site Discovery Data Query Errorssfm.cisco.cc.sites.get_site.errorNumber of errors that occurred during the most recent site discovery run of the paged queries sites.get_site, used to discover sites and collect their attributes.
Sites Count Query Durationsfm.cisco.cc.sites.get_site_count.durationDuration of the query sites.get_site_count, used to retrieve number of sites
Sites Count Query Errorssfm.cisco.cc.sites.get_site_count.errorNumber of errors that occurred during the most recent data collection or site discovery run for the query sites.get_site_count, used to retrieve the number of sites.
Site Health Statistics Data Query Durationsfm.cisco.cc.sites.get_site_health.durationDuration of the paged query sites.get_site, used to collect site health metrics.
Site Health Statistics Data Query Errorssfm.cisco.cc.sites.get_site_health.errorNumber of errors that occurred during the most recent data collection for the paged query sites.get_site, used to collect site health metrics.
Site Health Summaries Statistics Data Query Durationsfm.cisco.cc.sites.read_list_of_site_health_summaries.durationDuration of the paged query sites.read_list_of_site_health_summaries, used to collect site health summaries metrics
Site Health Summaries Statistics Data Query Errorssfm.cisco.cc.sites.read_list_of_site_health_summaries.errorNumber of errors that occurred during the most recent data collection for the paged query sites.read_list_of_site_health_summaries, used to collect site health summaries metrics
Network Health Statistics Data Query Durationsfm.cisco.cc.topology.get_overall_network_health.durationDuration of the query topology.get_overall_network_health, used to collect overall network health metrics
Network Health Statistics Data Query Errorssfm.cisco.cc.topology.get_overall_network_health.errorNumber of errors that occurred during the most recent data collection for the query topology.get_overall_network_health, used to collect overall network health metrics
Client Health Statistics Data Query Durationsfm.cisco.cc.clients.get_overall_client_health.durationDuration of the query clients.get_overall_client_health, used to collect overall clients health metrics
Client Health Statistics Data Query Errorssfm.cisco.cc.clients.get_overall_client_health.errorNumber of errors that occurred during the most recent data collection for the query clients.get_overall_client_health, used to collect overall clients health metrics
Issues Data Query Durationsfm.cisco.cc.issues.issues.durationDuration of the query issues.issues, used to collect issues data
Issues Data Query Errorssfm.cisco.cc.issues.issues.errorNumber of errors that occurred during the most recent data collection for the query issues.issues, used to collect issues data.
site
Metric nameMetric keyDescription
Wired Clients Scorecisco.cc.site.client_health_wiredSite's Wired Clients Health Score
Wireless Clients Scorecisco.cc.site.client_health_wirelessSite's Wireless Clients Health Score
Clientscisco.cc.site.client_count.gaugeSite's Clients Summary Count
Wired Clientscisco.cc.site.wired_client_count.gaugeSite's Wired Clients Summary Count
Wireless Clientscisco.cc.site.wireless_client_count.gaugeSite's Wireless Clients Summary Count
Healthy Clientscisco.cc.site.client_good_health_percentageSite's Healthy Clients Summary Percentage
Devicescisco.cc.site.network_device_count.gaugeSite's Devices Summary Count
Healthy Devicescisco.cc.site.network_device_good_health_percentageSite's Healthy Devices Summary Percentage
Site Issuescisco.cc.site.issue_count.gaugePending Site Issues
center
Metric nameMetric keyDescription
Health score (Center)cisco.cc.center.health_scoreCisco Catalyst Network topology - Overall health score
Healthy devicescisco.cc.center.healthy_devicesCisco Catalyst Network topology - Healthy devices
Unhealthy devicescisco.cc.center.unhealthy_devicesCisco Catalyst Network topology - Unhealthy devices
Clients health scorecisco.cc.client.health_scoreCisco Catalyst Client - Overall client health score
Clients Countcisco.cc.client.client_count.gaugeCisco Catalyst Client - Clients count
Unique Clients Countcisco.cc.client.client_unique_count.gaugeCisco Catalyst Client - Unique Clients Count
Clients health score countcisco.cc.client.health_score_count.gaugeCisco Catalyst Client - Clients health score by score type
device
Metric nameMetric keyDescription
Healthcisco.cc.device.healthDevice's Health
CPUcisco.cc.device.cpuDevice's CPU consumption
Memorycisco.cc.device.memoryDevice's Memory consumption
Average Temperaturecisco.cc.device.temperatureDevice's Avg Temperature
Device Issuescisco.cc.device.issue_count.gaugePending Device Issues
Reachabilitycisco.cc.device.reachabilityDevice's Reachability (1: Reachable | 0: Not Reachable)
Uptimecisco.cc.device.uptime.gaugeDevice Uptime
Memory Sizecisco.cc.device.memory_size.gaugeDevice Memory Size
Issue Eventscisco.cc.device.issue_events.gaugeIssue events over selected timeframe

FAQ and troubleshooting

How many devices/interfaces/sites can I monitor with this extension?

Practical tests reveal the following rule of thumb: 1000 devices per each one minute monitoring interval.

This means that with a five-minute monitoring interval, it should be achievable to monitor 5000 devices with a single ActiveGate.

This is an estimation. Results in your environment may vary, depending on:

  • The number of interfaces on each of the monitored devices.
  • The number of sites that the Catalyst Center manages.
  • Your Catalyst Center response time and network connection throughput between Catalyst Center and the ActiveGate.

The estimation assumes that

  • You have six interfaces per device, or 30,000 interfaces per five-minute monitoring interval.
  • You have 500 sites.
  • Catalyst Center responds within the single seconds.
  • The connection from Catalyst Center to ActiveGate is via a local area network.
  • The Catalyst Center extension runs on an ActiveGate with the dedicated performance profile. See About Extensions for more details on performance profiles.
Should I split monitoring configuration into many instances to scale the extension out?

One monitoring configuration should track one Catalyst Center. Multiple monitoring configurations should be used to track multiple Catalyst Centers.

This is important to retain consistency in the Catalyst Center locations reporting. If you split a single Catalyst Center instance between more than one monitoring configuration, for example by using tag-based filters, you may end up with duplicate entities representing individual Catalyst Center locations. This results in double-counted metrics for these locations.

Can I increase monitoring intervals to five minutes, or 10 minutes, or 15 minutes?

We recommend a one-minute monitoring interval to retain high data fidelity for alerting and Davis AI reasoning. In very large environments, increasing monitoring interval may help with scalability; this however is always occupied with data fidelity loss. We don't recommend going beyond five.

Please note that data on entities that do not change often. This data is already collected less frequently and you can adjust it further. For more information, see Discovery frequencies adjustment.

Why are health, CPU, or memory values for some devices on the dashboard negative?

The Catalyst API returns negative values for non-reachable devices.

Do I need to enable all feature sets?

No, not all feature sets are required.

  • The self-monitoring feature set is optional. It is only needed for fine-tuning and diagnostics of the extension itself.
  • If you want to view platform screens (for generic network device and interface metrics) within Infrastructure & Operations Infrastructure & Operations, only the default feature set is needed.
  • If you want to view both classic screens and all platform screens (for generic network device and interface metrics and for Cisco Catalyst device and interface metrics), enable all feature sets except self-monitoring.
Does the extension support other versions of Cisco Catalyst Center not listed in the Compatibility Information?

Yes, but with limitations. In the extension configuration, select the Cisco Catalyst Center Version that matches your installed version. If your exact version is not listed, choose the closest lower version available.

Please note that when connecting to versions of Cisco Catalyst Center other than those listed in Compatibility information, some metrics may be missing or unavailable. Specifically, older API versions are not reliable as a source of the interface-related metrics, due to API scalability limitations. Therefore, when extension is connected to DNA Center 2.3.6.x or DNA Center 2.3.5.x or earlier, there will be no interface-level metrics available on charts and in the Infrastructure & Operations Infrastructure & Operations. Other metrics gaps may also exist. We strongly recommend connecting to API versions listed in the Compatibility Information section.

I am getting a "`SSL: CERTIFICATE_VERIFY_FAILED` certificate verify failed" error (self-signed certificate in certificate chain error).

This indicates that the Catalyst endpoint uses a self-signed certificate. If you trust the endpoint, you can skip certification verification. To do this, in the connection settings, set Check SSL Certificate to false.

Do I need to configure separate proxy servers for different Catalyst endpoints?

If you need to use different HTTP proxy servers for different Catalyst endpoints, you should create a separate extension configuration for each proxy. The proxy defined in a configuration applies to all Catalyst endpoints within that configuration. To ensure that the correct proxy is used for each endpoint, define each proxy-endpoint pair in its own dedicated configuration.

Does the extension support monitoring of other entities, such as SSIDs or details on the access points?

Not yet.

We look forward to your feedback on the enhancements that would make this extension better fitted to your environment. Post your product idea in the Dynatrace community.

In the Python 3 log file, I see the error "Read timed out".

If you see RateLimitError messages, it means the extension is sending too many requests to the Catalyst Center, causing it to return RateLimitError and temporarily block connections from the extension. This leads to timeouts.

To troubleshoot:

  1. Confirm that the network connection between the extension and the Catalyst Center is allowed.
  2. If RateLimitError while calling client method appears before the Read timed out error, a potential solution is to increase the Metrics Collection Frequency in the configuration, for example to 15 minutes. If increasing the value helps, fine-tune it as needed. Also check that the Page size in the configuration is set to the default values. The default values are the maximum allowed and reduce the number of requests. Smaller page sizes mean more requests.
  3. If RateLimitError while calling client method does not appear before the Read timed out error, open the Cisco Catalyst Extension Self-Monitoring dashboard and look at the Overall Metrics Data Collection Time graph. Based on the value in the graph, increase the Single Request Timeout setting in the extension configuration to a value higher than the one shown in the graph.
The Dynatrace gateway reports the error "Memory threshold exceeded" in the ruxitagent_extensionmodule log.

This issue can be resolved in several ways. In some cases, applying just one of the following steps is sufficient, while in others a combination may be needed:

  1. Separate configurations for multiple endpoints. If a single extension configuration connects to multiple Catalyst Centers, all cached data from these endpoints is stored in one OS process. Create a dedicated configuration for each endpoint. Each configuration runs as a separate OS process, so the cached data from each endpoint is split across multiple processes.

  2. Increase RAM on the ActiveGate server. Allocating more RAM to the ActiveGate machine can help prevent memory limit breaches.

  3. Increase Extension Execution Controller limits. Adjust the limits in the extensionsuser.conf file as described in the Dynatrace documentation, see Extension Execution Controller custom configuration. For example, you can add:

    # Memory settings
    dslimit_python_mem=3000
    mem_soft_limit_percent=70.0
    mem_hard_limit_percent=80.0
On the Cisco Catalyst Center Monitoring Overview dashboard, I can see data for sites and devices, but there is no data at all for interfaces.

The Dynatrace entity instance limit for interfaces is 100,000.

If your Catalyst Center contains more than 100,000 interfaces, you may have reached the Dynatrace entity instance limit for Network Interface and Catalyst Interface entities.

To verify this, run the following DQL query:

timeseries entity_count_per_entity_type =
sum(
dt.sfm.server.monitored_entities.entity_count_per_entity_type,
filter: in(dt.me_type_name, array("network:interface", "cisco_cc:interface"))
),
by: { dt.me_type_name }
| fieldsAdd entity_count_per_entity_type.single_value = arrayLast(entity_count_per_entity_type)
| fields `entity type`=dt.me_type_name, `entity count`=entity_count_per_entity_type.single_value

If the value is greater than 100,000, contact Dynatrace Support and request an increase of the entity limit for network interfaces (network:interface) and Catalyst interfaces (cisco_cc:interface) to 2.4 million for your tenant.

I have a high number of queries from the extension to the Catalyst Center. How can I reduce them?

Query consumption can be reduced in several ways:

  1. Increase the value of Metrics Collection Frequency in the extension configuration. This interval has the most significant impact on query usage for this extension.

  2. Increase the intervals for Sites Discovery Frequency, Devices Discovery Frequency, and Interfaces Discovery Frequency in the configuration.

  3. Disable certain feature sets in the extension configuration. This will reduce the amount of data collected, which in turn lowers query usage.

    Disabling feature sets will result in missing data on Classic Analytic and Platform screens.

We have high DDU consumption for the Catalyst Extension. How can I reduce consumption?

Query consumption can be reduced in several ways:

  1. Increase the value of Metrics Collection Frequency in the extension configuration. This interval has the most significant impact on query usage for this extension.

  2. Increase the intervals for Sites Discovery Frequency, Devices Discovery Frequency, and Interfaces Discovery Frequency in the configuration.

  3. Disable certain feature sets in the extension configuration. This will reduce the amount of data collected, which in turn lowers query usage.

    Disabling feature sets will result in missing data on Classic Analytic and Platform screens.

After upgrading Cisco Catalyst to the next version, metrics data are no longer reported. In the Python 3 log file, I see the error: "error: BAPI not found with technicalName `<url path>` and restMethod GET".

This issue typically occurs because the Cisco DNA Center REST API bundle was not automatically upgraded, even though the platform itself was.

To resolve this issue, disable and then re-enable the Cisco DNA Center REST API bundle. This forces a refresh and restores access to the affected endpoints.

  1. Log in to your Cisco Catalyst (DNA) Center system menu, go to Platform > Manage (or the equivalent path for your version).
  2. In the Bundles tab, locate the Catalyst Center REST API bundle.
  3. Disable the bundle, wait a few seconds, and then re-enable it.
  4. Restart the extension. Disable and then re-enable its configuration.

To troubleshoot the Catalyst endpoint itself and validate the REST API bundle:

  1. In the Cisco Catalyst (DNA) Center system menu, go to Platform > Developer Toolkit.
  2. In the APIs tab, locate the <url path> API endpoint in question by searching in the URL column. Ensure that GET is specified in the Method column.
  3. Select Try at the end of the line in the Actions column.
  4. Execute the query. Typically, deselect all query parameters and select Run.
Related tags
NetworkPythonNetwork managementCiscoInfrastructure Observability