Cisco Catalyst Center (DNA Center) extension

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

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

The primary limiting factor in such estimations is the performance of the Catalyst Center itself. In large environments—particularly those with devices carrying many interfaces, where the total interface count reaches the order of hundreds of thousands—consider defining multiple collection configurations, assigning longer collection frequencies to some of the device groups. The right balance should be tuned according to your business requirements and the Catalyst Center's own performance.

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.

We recommend a one-minute monitoring interval to retain high data fidelity for alerting and Dynatrace Intelligence 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.

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

No, not all feature sets are required.

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.

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.

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.

If you see a Read timed out message, it means the extension opened a connection to the Catalyst Center but didn't receive a response within the configured timeout. A common cause is that the extension is sending too many requests in a short time, causing the Catalyst Center to rate-limit or delay responses.

To troubleshoot:

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:

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.

Query volume and DPS consumption can be reduced in several ways.

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

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

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

By default, the extension collects Center and Site health metrics every 5 minutes, as configured in Polling > Center and Site Metrics Collection Frequency. Device and interface metrics are collected separately, each on its reporting group frequency, which by default is 5 minutes as well. Each collection runs as its own scheduled task. When a scheduled collection takes longer than its configured interval, the extension detects it and automatically skips the next scheduled run to prevent concurrent data collections.

To analyze this further, you can use the Cisco Catalyst Extension Self-Monitoring dashboard (provided that you've activated the self-monitoring feature set). This dashboard provides insights into data collection durations and even individual paged queries with the page offset as a dimension.

Recommended actions:

After making the adjustment, recheck the data collection times to ensure the issue is resolved.

The performance impact cannot be estimated with precision as it depends on how your Catalyst Center is configured. The rate limit default is 100 API calls per minute, however it can be adjusted for individual endpoints and the maximum amount varies by API type, ranging from 20 to 500. When a limit is reached, the system returns an HTTP 429 (Too Many Requests) response.

To keep its own impact within those limits, the extension uses pre-calculated API endpoints and paginated queries to reduce the total number of calls. It also has built-in rate limiting: by default, it sends at most 100 API calls per minute, matching the Catalyst Center default. When this limit is reached, the extension automatically waits before retrying.

One pattern that can still affect the Catalyst Center GUI is the extension peak load at the start of each collection cycle. When data collection runs (for example, every 5 minutes), the extension sends multiple paged queries as quickly as possible to capture data for that specific timestamp. Because queries are not spread evenly across the interval, the controller receives more requests at once at the start of each cycle. If this is the cause of the issues you observe, consider:

No, especially in larger environments.

A filter that is empty or broad enough to match all remaining devices causes a full-table scan. The Catalyst Center response returns all devices regardless of the filter position in the group, whether a device is already claimed by an earlier group, or whether you intend to report its metrics. After the response arrives, the extension ownership logic filters out already-claimed devices, however the full fetch and its load on your Catalyst Center are unavoidable. The performance impact grows linearly with the number of managed devices.

Instead of a catch-all group: