Cisco Crosswork Network Controller 7.2.x Administration Guide

PDF

Cisco Crosswork Network Controller 7.2.x Administration Guide

Recommendations for efficient configuration

Want to summarize with AI?

Log in

Explains the device onboarding methods supported by Cisco Crosswork Network Controller, including API imports, CSV uploads, UI entry, auto-onboarding, and Zero Touch Provisioning, and outlines their prerequisites and considerations for successful device registration.


Prioritize consistent and secure device configuration

While configuring your devices for onboarding, review these guidelines:
  • Use a common configuration file for all devices to enable reachability checks and consistent event collection.

  • Plan for link discovery as part of the onboarding workflow. This approach requires necessary configuration work upfront, rather than addressing it incrementally. This is especially important to leverage configuration templates. Onboard devices without all the desired configurations initially and later push a standardized configuration to the devices. This ensures they are fully compatible with Crosswork Network Controller.

  • Create unique SNMP EngineIDs for each device in the network.

  • If a device's SNMP EngineID is reconfigured, recreate SNMP user accounts for that device.

  • Limit NETCONF API access to users with privilege level 15. On XE devices where privilege level 15 is granted via Enable Password, do not use NETCONF for reachability or state verification.

Caution

Do not onboard a large number of devices by using individual /32 routes. Internal scale testing for static route count is less than approximately 100.

In deployments with thousands of device-specific static routes, orchestrator initialization can be significantly delayed during restart or switchover because the system checks routes during startup. This delay can prevent DLM initialization from completing and can lead to cluster recovery issues.

To help avoid this issue:

  • Group similar devices in the same subnet.

  • Use the corresponding subnet mask group, such as /24, /16, or /8, instead of individual /32 routes.

If a temporary recovery workaround is used, the issue can occur again after orchestrator restart or switchover until the route subnet design is changed.

Protect network access and validate device support

  • If you are using TELNET in your network environments, implement security measures, such as firewall protections and ACLs to reduce any potential risks.

  • If a device is onboarded with an unknown Sys Object ID, contact Cisco Customer Experience as the hardware may not be certified.