Cisco Nexus Dashboard and Data Center Network Management Automation
Cisco Nexus Dashboard and Data Center Network Management Automation covers how Cisco's data center controllers are structured, which app owns which job, and how to drive them by API instead of the GUI.
The platform and its apps
- Nexus Dashboard is the common platform: a one- or three-node cluster providing single sign-on, RBAC and shared services that hosts the applications below.
- Nexus Dashboard Orchestrator (NDO) manages intent across sites for multi-site ACI and NX-OS VXLAN EVPN fabrics, using templates and schemas pushed to each site's controller.
- Nexus Dashboard Insights is the assurance app: telemetry-based anomaly detection, advisories, flow and compliance analysis.
- Nexus Dashboard Fabric Controller (NDFC, formerly DCNM) is the lifecycle manager for NX-OS fabrics: discovery and POAP, image management, interface and overlay configuration, configuration compliance.
Automation surfaces
NDFC exposes REST endpoints under /rest/...; you authenticate with a POST and receive a token (for example a Dcnm-Token header) that must accompany later calls and that expires. ND/NDO and NDFC both have Ansible collections (cisco.nd, cisco.dcnm) and Terraform providers. In NDFC a change is usually two steps: define the policy or config, then explicitly deploy it to the switches.
Worked example
Bring 20 new leaf switches into a VXLAN EVPN fabric and give them a new network.
Reasoning: rack and cable, then let POAP bootstrap - DHCP with the boot option pointing at the NDFC-managed image/PnP server so each leaf receives the right image and a temporary address. Add devices to the fabric inventory, assign role (leaf/spine, access/core) and interface policies, then deploy. Create the overlay VRF and network and deploy again. Only then does NDO matter: if the network must span sites, model it once in an NDO template and let NDO push per-site configuration. Automation order follows dependency: image, fabric membership, underlay, overlay, cross-site intent.
Traps that cost marks
- Treating NDO as the tool that configures switches directly, or NDFC as the multi-site orchestrator.
- Assuming a saved or staged change is live; the deploy step is separate and frequently tested.
- Hard-coding credentials instead of using the token/SSO flow, and ignoring token expiry.
- Forgetting that the platform app layer adds no configuration by itself - the app does the work.