A logistics company can ping a log collector from the Nexus management VRF, but a script in the guest shell cannot reach that collector. The guest shell is already enabled. What is the guest shell missing?
Select an answer to reveal the explanation.
Short Explanation
The guest shell opens in the default namespace, like standing in the wrong hallway of the same building. You run the script inside the management VRF namespace, with chvrf management, so it uses the route your switch ping already proved. Moving the script into the system root does not change which namespace it uses.
Full Explanation
Guest shell maps each NX-OS VRF to a Linux network namespace, and a command runs in the namespace that is current. Out of the box that is the default VRF namespace. A ping that succeeds from the NX-OS management VRF only proves the management VRF has a route to the collector. The script fails because it is running in a different namespace from the one holding that route. Running it inside the management namespace, for example with chvrf management or ip netns exec management, makes it use the management VRF interface and routing table, and the guest shell does not need an address of its own. Moving the script into the NX-OS system root does not change its namespace, and the system root is not a required location for a guest-shell socket. POAP is a day-0 bootstrap used when startup configuration is absent. It does not join the guest shell to the management VRF at first boot or at any other time. SPAN copies frames to a destination. It does not create a route for a Linux namespace, and reachability is not a copied frame stream. Caveat: the collector must be reachable through the management VRF, and name resolution inside the shell needs its own resolv.conf entry. Operational check: run chvrf management ping to the collector from inside the shell, then start the script the same way.