On this page
You have a VXLAN EVPN fabric that works. It was built by hand, or by Ansible, or by a generator script, and it carries production traffic. Now it has to live under Nexus Dashboard Fabric Controller. NDFC can adopt a running fabric without rebuilding it: you create a fabric, discover the switches with their configuration preserved, and let NDFC learn what is already there. That is the brochure. In practice NDFC runs a brownfield check against every switch, refuses to leave migration mode until the parts it checks match its own templates, and then shows you a diff of everything it wants to change. This post walks through one real migration end to end: every error it threw, what each one actually meant, and how the fabric went from unmanaged to In-Sync without a single lost ping during the deploy.
The fabric NDFC inherited
Ten Nexus 9300v switches on NX-OS 10.6(1)F, carrying the frontend network of an AI cluster. Two spines acting as BGP route reflectors, six leaves in three vPC Fabric Peering pairs, and a border pair with no vPC that routes each VRF to a Palo Alto firewall. The underlay is OSPF with IP unnumbered links borrowing loopback0, the overlay is iBGP EVPN in AS 65100, BUM traffic uses ingress replication. None of it was built by NDFC: a Python generator writes every switch config, and the Nexus section of its validation script runs 134 checks against the live fabric, including "every generated line is in the running-config" for each switch.
The controller is Nexus Dashboard 4.3.1.175 with NDFC, reaching the switches through their management interfaces. Every NDFC step below was an ND REST API call rather than a GUI click, so each one is a request you can repeat. The Nexus Dashboard screenshots were taken in the GUI after the migration, to show where each step left the fabric.
show interface brief across the ten switches gives the same 518.The rest of this post is how it got there.
