VCP-NV common mistakes
VCP-NV · Understand the traps and how to avoid them.
Revising with NSX-V vocabulary and mapping it one-to-one onto NSX-T/NSX objects (VXLAN→GENEVE, VTEP→TEP, DLR+ESG→Tier-0/Tier-1, logical switch→segment, distributed logical router→distributed router component).
A large amount of free blog and video material still describes NSX-V, and the concepts look superficially identical, so candidates answer questions using the wrong object name or the wrong component boundary.
What to do instead
Build a single translation table and rehearse it: segment = logical switch, GENEVE encapsulation with a TEP per transport node, Tier-0 is the provider/router-to-physical layer with a service router, Tier-1 is the tenant router with distributed forwarding, and DFW/Edge firewall keep their names. When reading any study material, first confirm which product generation it targets.
Assuming the NSX Manager cluster is in the data plane, i.e. that traffic stops or forwarding breaks if all Manager nodes are down.
The Manager is the only UI/API surface candidates ever touch, so it feels like the 'brain' that must be online for packets to flow.
What to do instead
Separate the planes explicitly: NSX Manager is management/control-plane configuration and API; the local control plane runs on transport nodes and Edge nodes; forwarding is done by the host/Edge data plane. If the Manager cluster is unavailable, existing workloads keep forwarding on their last configuration but no new configuration, and some control-plane updates, can be pushed. Only a data-plane or transport-node failure actually stops traffic.
Treating the underlay as an afterthought: designing an overlay while ignoring TEP-to-TEP routability and MTU, and leaving underlay MTU at the default 1500.
GENEVE is presented as 'decoupled from the physical network', so candidates assume the underlay only needs basic reachability and never size the extra encapsulation overhead.
What to do instead
Always size for the overhead: the underlay path between TEPs (and the uplink profiles in NSX) must support a larger MTU than the guest MTU - the common recommendation is at least 1600 bytes on the underlay/transport path for a 1500-byte workload MTU - and the TEP addresses must be routable to every other TEP. When a question describes large pings failing but small ones succeeding, reach for MTU, not routing.
Skipping or mis-ordering host preparation: trying to create transport nodes before registering the compute manager, or applying a transport node profile to a cluster without first creating the VLAN and overlay transport zones and the uplink profile.
The workflow is a strict dependency chain (compute manager → transport zones/uplink profile → transport node profile → cluster/host), and lab guides often assume some of it already exists.
What to do instead
Memorise the order and verify each step before moving on: register vCenter (accept the thumbprint), confirm it shows 'Up' in Fabric > Compute Managers, create the host switch/uplink profile and both transport zones, then apply the transport node profile to the cluster and confirm each host reports transport node state 'Success' rather than 'Degraded' or 'Partial Success'.
Building a Tier-1 gateway with a downlink segment and expecting north-south connectivity without configuring route advertisement to the Tier-0 or giving the Tier-0 a working uplink path to the physical network.
In the UI the Tier-1 looks complete once it has a segment attached; the advertisement toggles and the Tier-0 uplink/peering are separate screens that are easy to leave at defaults.
What to do instead
Trace three links in every routing scenario: segment → Tier-1 downlink (interface must have an IP and the segment must have a gateway), Tier-1 → Tier-0 (connected/static/NAT/LB VIP route advertisement toggles enabled as required, and the Tier-1 must be logically attached to the Tier-0), and Tier-0 → physical (uplink, uplink IP, and static route or BGP peering). A missing advertisement explains most 'the VM can ping its gateway but nothing beyond it' questions.
Confusing distributed and centralized routing: expecting a Tier-1 to perform NAT, load balancing, VPN or gateway-firewall functions with no Edge cluster or no service router, or assuming all Tier-1 traffic is distributed.
The Tier-1 object looks like a single router in the UI, but it is a distributed router for east-west plus an optional centralized service router on an Edge node for stateful services.
What to do instead
For every Tier-1, ask 'does this service need state that cannot live on every host?' NAT, LB, VPN and gateway firewall need the centralized SR on an Edge cluster; plain east-west between segments on the same Tier-1 is handled by the distributed router on the hosts. Similarly, a Tier-0 always needs an Edge cluster for its service router to talk to the physical network.
Creating a distributed firewall rule, seeing no effect, and assuming DFW is broken instead of checking the rule's 'Applied To' scope and the actual membership of the source/destination groups.
DFW rules are evaluated per vNIC based on where the rule is applied, and group membership can be static, tag-based or criteria-based - an empty or wrong group silently produces a rule that never matches.
What to do instead
For any DFW problem, check in order: the rule's Applied To field, the effective members of each group (and for dynamic groups, whether the tag/criteria is actually present on the VM), the rule order and section, and then the DFW rule/packet statistics to prove whether the rule was hit. Also remember the DFW default rule's action is a configurable setting (allow by default) so 'everything is blocked' usually points at a user rule, not the default.
Assuming the distributed firewall protects all traffic, including traffic to and from unmanaged or unprepared hosts, physical workloads, and traffic that is handled by Edge services.
DFW is marketed as 'kernel-level everywhere', which leads candidates to treat it as a network-wide guarantee rather than a per-transport-node enforcement point.
What to do instead
Scope enforcement correctly: DFW only enforces on prepared transport nodes and only sees that host's traffic; traffic to remote subnets goes through a Tier-0/Tier-1 service router where the gateway firewall applies, and any trusted/unprepared host is not covered by DFW. In questions about traffic entering from the physical network or a legacy VLAN without host prep, the gateway firewall or an Edge-based service is the correct answer, not DFW.
Reaching for the wrong tool during troubleshooting - using vSphere/vCenter networking views or esxcli alone to diagnose overlay problems, or expecting nsxcli-style commands on a Manager node.
Candidates learn one CLI in the lab and then apply it indiscriminately to hosts, Edge nodes and Managers, which all expose different command sets and different views of the same object.
What to do instead
Know the layers: vCenter/esxcli for the underlay, VMkernel/TEP and physical NIC state; the NSX CLI on transport nodes and Edge nodes for logical ports, segments, tunnels and router state; the Manager API/UI for desired configuration and alarms; and Traceflow to prove the actual path and the drop point. When a question gives you a symptom, first decide which layer it belongs to, then pick the tool.
Reading tunnel or node status as binary - treating 'Up' tunnel status or a green node as proof that the data path works, and ignoring alarms, degraded states and control-plane connection status.
Dashboards lead with green icons, but a transport node can be 'Degraded' or have stale control-plane connections, and a tunnel can be Up while MTU or routing in the underlay silently drops encapsulated traffic.
What to do instead
Correlate several signals before concluding: transport node state (Success/Degraded/Partial Success), tunnel/control-plane connection status, the alarms list, and then an active test such as Traceflow or a large-payload ping between TEPs. If overlay traffic fails while tunnels look Up, suspect MTU or TEP routing and verify with an actual packet test rather than the status icon.