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, consider defining multiple collection configurations and assigning longer collection frequencies to some of the device groups. The total interface count in such environments can reach hundreds of thousands. Tune the balance according to your business requirements and the Catalyst Center's own performance.

One monitoring configuration should track one Catalyst Center. Use multiple monitoring configurations 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 the monitoring interval may help with scalability. This, however, is always accompanied by data fidelity loss. We don't recommend going beyond five.

Entity attribute discovery runs on its own independent schedule, and you can tune it separately. For more information, see Discovery frequencies adjustment.

While Catalyst Center still reports the issue as active, the extension keeps re-sending the same event. Each event tells Dynatrace how long to wait before closing the problem if it stops receiving the event. This is the Davis Event Timeout, 60 minutes by default.

A problem ends in one of two ways:

Which of the two you see depends on your Catalyst Center: some environments report resolutions, others let issues disappear silently.

The extension reports an issue to Dynatrace only when it reads the issue from Catalyst Center, and every event it sends carries the Davis Event Timeout. The issue has to be read again, and the event re-sent, before that timeout expires. Otherwise, Dynatrace closes the problem.

This breaks when Issues Collection Frequency is too close to Davis Event Timeout. The event expires before the issue is read again: Dynatrace closes the problem. The next collection reads the same still-active issue and reports it again, which opens a new problem. The cycle repeats for as long as the issue lasts.

Keep Issues Collection Frequency below half of Davis Event Timeout. The defaults—issues collected every 5 minutes with a 60-minute timeout—leave a wide margin, so one problem stays open for the whole issue.

The extension detects an unsafe combination and reports a warning on the monitoring configuration.

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

No, not all feature sets are required.

Each network device carries its Catalyst Center device tags in the list field cisco_cc.tags. A device without tags has the list ["-"] on purpose: every device node carries the field, which keeps DQL queries simple and ensures that a removed last tag is cleared.

To list the devices with a tag:

smartscapeNodes EXT_NETWORK_DEVICE
| filter in("LAN", cisco_cc.tags)
| fields name, cisco_cc.tags

To count the devices per tag, where - counts the devices without tags:

smartscapeNodes EXT_NETWORK_DEVICE
| filter isNotNull(cisco_cc.tags)
| expand cisco_cc.tags
| summarize devices = count(), by: {cisco_cc.tags}

If Report Physical Topology is enabled in the monitoring configuration (default), the extension reports the physical links from Catalyst Center as calls relationships between network devices and between their interfaces. Physical Topology Collection Frequency sets how often the links are collected (5 minutes by default). To follow the links, use the traverse command.

For example, to find links whose two interfaces report different speeds:

smartscapeNodes EXT_NETWORK_INTERFACE
| filter isNotNull(cisco_cc.center)
| traverse {calls}, {EXT_NETWORK_INTERFACE}, direction: forward, fieldsKeep: {name, cisco_cc.device, cisco_cc.if_speed_text}
| fields device = dt.traverse.history[0][cisco_cc.device], interface = dt.traverse.history[0][name], speed = dt.traverse.history[0][cisco_cc.if_speed_text],
    peer_device = cisco_cc.device, peer_interface = name, peer_speed = cisco_cc.if_speed_text
| filter speed != peer_speed

Extension version 3.x requires Cisco Catalyst Center version 2.3.7.6 or later. For the tested and supported versions, see Compatibility information.

If your exact version isn't listed, the extension is expected to work correctly. Cisco doesn't publish a new API specification version with every Catalyst Center release—the same API version might cover multiple consecutive platform releases. For example, Catalyst Center 3.1.3.0 has the same API surface as 2.3.7.9. The API endpoints that the extension relies on are available in all Catalyst Center versions from 2.3.7.6 onwards.

For Catalyst Center versions earlier than 2.3.7.6, use the extension version 2.x.

This indicates that the Catalyst endpoint uses a self-signed certificate. If you trust the endpoint, you can skip certificate 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 Centers, create a separate extension configuration for each. Each configuration connects to exactly one Catalyst Center and uses its own proxy setting. To ensure that each Catalyst Center uses the correct proxy, define its proxy and URL 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:

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

First, make sure that an interface filter doesn't exclude all interfaces. Filter values are case-sensitive, and a value with the wrong case matches no interface.

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.

You can reduce query volume and DPS consumption 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 can't 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's 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's 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: