A logistics company runs three VXLAN fabrics and wants the same tenant network intent applied to all three from one controller. Which tool is built for that multi-fabric job?
Select an answer to reveal the explanation.
Short Explanation
One clipboard for three warehouses beats walking into each warehouse with a different note. You push the same tenant intent from Nexus Dashboard orchestration instead of typing it on a single leaf. A leaf session, an applet, or a packet copy does not fan that intent out to the other fabrics.
Full Explanation
Nexus Dashboard is the platform that hosts fabric control and orchestration for more than one fabric. Its orchestration service holds the tenant intent once and deploys that intent to each fabric controller, which is the workflow the logistics company described. Typing the same configuration on one leaf only changes that switch. Other fabrics do not learn a tenant network by copying a peer's running configuration across a vPC peer-link, and a peer-link does not connect three separate fabrics. An EEM applet reacts to an event on the switch where it is configured and runs a local action. It is not a multi-site orchestration database. A SPAN session copies frames to an analyzer. The analyzer does not compile those frames into tenant configuration and push it back to the leaves. Caveat: the dashboard programs the fabrics through their controllers, and a fabric that was never added to the orchestration domain will not receive the intent. Operational check: confirm all three fabrics are attached to the orchestration service, deploy the tenant once, and verify each fabric shows the same network rather than a one-off CLI change on a single leaf.