Site icon Digital Thought Disruption

How to Install and Configure VMware NSX with an NVIDIA Spectrum Network Fabric

Paul Bryant

TL;DR

A reliable VMware NSX deployment on NVIDIA networking depends less on clicking through the NSX Manager wizard and more on getting the physical underlay right first. The NVIDIA Spectrum fabric must provide stable Layer 3 reachability between every ESXi and NSX Edge tunnel endpoint, consistent jumbo MTU, predictable uplink behavior, and resilient routing to the Tier-0 gateway.

This guide modernizes NVIDIA’s original NSX-T installation sequence for current NSX 4.x environments. It uses VDS-backed ESXi transport nodes, Cumulus Linux 5.x with NVUE, routed TEP subnets, redundant NVIDIA leaf switches, and numbered BGP adjacencies between the NSX Edge cluster and the physical fabric.

Introduction

Installing NSX on top of an NVIDIA network fabric is not a simple overlay exercise. It is a coordinated design across two control domains.

NSX owns logical segments, Geneve encapsulation, distributed routing, gateway services, and security policy. The NVIDIA Spectrum fabric owns physical link resiliency, routed underlay reachability, MTU consistency, TEP subnet gateways, and external routing adjacency. Neither layer can compensate for a broken design in the other.

The most common deployment failures happen at the boundary between those domains. A host can show as successfully prepared while its TEP cannot reach another rack. An Edge node can be healthy while its BGP session remains idle. A fabric can pass normal ping tests while silently dropping large Geneve packets because one interface still uses a smaller MTU.

This walkthrough focuses on that boundary. It provides a practical deployment order, reference configuration patterns, validation gates, and troubleshooting guidance for building NSX on NVIDIA Spectrum switches running Cumulus Linux.

What You Will Build

By the end of this guide, you will have a deployment pattern that includes:

This is an implementation pattern, not a substitute for the Broadcom interoperability matrix, NVIDIA hardware support information, or your approved low-level design.

Version and Scope Guardrails

The original NVIDIA walkthrough was written for ESXi 7.0 Update 3d, vCenter Server 7.0 Update 3d, and NSX-T Data Center 3.2.1. The architecture remains useful, but several implementation details have changed.

For a current deployment, keep these guardrails in place:

The article uses the term NSX-T where it improves searchability or describes the historical product lineage. Current product documentation generally uses VMware NSX or VCF Networking depending on the platform release.

Reference Architecture

The physical fabric should remain simple from the NSX perspective. It does not need to learn every workload MAC address or tenant segment. Its primary job is to route packets between TEP IP addresses and provide reliable external reachability for the NSX Edge cluster.

The important distinction is that the NVIDIA fabric routes the outer IP header between TEPs. NSX owns the Geneve encapsulation and the logical topology carried inside it.

For north-south traffic, the NSX Edge service router terminates the logical routing path and exchanges routes with the NVIDIA fabric through numbered BGP adjacencies. That routing boundary should be explicit, filtered, monitored, and tested independently from host TEP reachability.

Prerequisites

Platform and Access Requirements

RequirementProduction expectation
vSphere and vCenterSupported versions with a prepared VDS and available uplinks
VMware NSXSupported release media, entitlement, and verified interoperability
NSX ManagersThree nodes for production, placed across appropriate failure domains
ESXi hostsAt least two hosts for validation, with supported NICs and firmware
NVIDIA fabricRedundant Spectrum leaf switches, optional spines, and Cumulus Linux 5.x
Management servicesWorking DNS, NTP, default gateways, certificates, and administrative access
RoutingUnderlay BGP design plus numbered BGP plan for Tier-0 uplinks
AddressingManager, host TEP, Edge TEP, Edge uplink, and workload segment ranges
MTUA documented end-to-end target, normally 9000 at the VMware layer and 9216 on the physical switch interfaces
RecoveryNSX backup destination, switch configuration backups, and an approved rollback window

Information to Record Before Deployment

Do not begin the build with only a list of VLAN IDs. Capture the complete relationship between the physical and virtual networks.

PurposeExampleDesign note
NSX management192.168.10.0/24Routed management network with DNS and NTP
Rack A host TEPsVLAN 110, 10.110.0.0/24VRR gateway on Rack A leaf pair
Rack B host TEPsVLAN 120, 10.120.0.0/24Separate routed subnet and failure domain
Edge TEPsVLAN 130, 10.130.0.0/24Size for all current and planned Edge nodes
Tier-0 uplink AVLAN 210Numbered adjacency to NVIDIA leaf A
Tier-0 uplink BVLAN 220Numbered adjacency to NVIDIA leaf B
NSX local ASN65050Example only, use the approved ASN plan
Fabric leaf ASNPer rack or per leafMatch the underlay routing standard
Overlay segments172.16.0.0/24 and laterNot configured as physical fabric VLANs

The values above are illustrative. A production low-level design should also define route filters, BFD policy, default-route ownership, failure domains, oversubscription, Edge placement, and IP exhaustion thresholds.

NVIDIA documents two useful host attachment patterns:

Both can work. The wrong choice is configuring the physical switches for one model and the VDS or NSX uplink profile for the other.

Active-Active LACP Through MLAG

Use this pattern when you need both links forwarding, the VDS LAG is part of the approved design, and the network team is comfortable operating MLAG and LACP as one failure domain.

The following example creates an MLAG bond for one ESXi host on an NVIDIA leaf. Change the physical port, bond name, and MLAG ID to match the actual cabling plan.

nv set interface esxi01 bond member swp1
nv set interface esxi01 type bond
nv set interface esxi01 bond mode lacp
nv set interface esxi01 bond mlag id 1
nv set interface esxi01 bridge domain br_default
nv set interface esxi01 bridge domain br_default stp bpdu-guard on
nv set interface esxi01 bridge domain br_default stp admin-edge on
nv set interface esxi01 bond lacp-bypass on
nv config apply -y
nv config save

A successful result should show the bond up on both MLAG peers with no conflict or protocol-down reason. The VDS must use a matching LAG configuration, and the NSX transport node profile must map its uplinks to the correct VDS LAG.

Use this pattern when operational simplicity and deterministic failover matter more than using both links simultaneously. Each ESXi-facing switch port remains an independent trunk port.

nv set interface swp1 bridge domain br_default
nv config apply -y
nv config save

Repeat the configuration on the peer leaf for the second physical NIC. In NSX, the uplink profile then defines which uplink is active and which is standby.

Do not create an MLAG host bond on the switches for this design. An active-standby NSX or VDS policy connected to an MLAG LACP bond is not a harmless mismatch. It creates inconsistent forwarding and difficult failure behavior.

Configure the NVIDIA Underlay

Validate Physical Connectivity

Use LLDP before configuring logical constructs. It is much faster to correct a crossed cable or unexpected switch port now than after NSX host preparation.

net show lldp
nv show interface

Confirm:

Set and Verify Jumbo MTU

NVIDIA’s current NSX-T fabric guide recommends jumbo MTU end to end and notes that Cumulus Linux data interfaces default to 9216 bytes. NSX Geneve traffic requires additional encapsulation headroom, so a normal 1500-byte path is not enough for full-size workload frames.

Use a consistent design such as:

Verify the switches rather than assuming the default is unchanged:

nv show interface

MTU must be correct on every hop. One smaller inter-switch link can produce intermittent packet loss that only appears under larger frames or specific application traffic.

Configure MLAG and VRR

MLAG provides the paired-leaf system needed for dual-attached hosts. VRR provides a shared active-active gateway address for routed TEP subnets.

The following example creates the TEP VLAN and a VRR gateway on the first leaf in a pair:

nv set bridge domain br_default vlan 110
nv set interface vlan110 ip address 10.110.0.252/24
nv set interface vlan110 ip vrr address 10.110.0.254/24
nv set interface vlan110 ip vrr mac-address 00:00:00:00:01:10
nv set interface vlan110 ip vrr state up
nv config apply -y
nv config save

On the peer leaf, use a unique physical SVI address such as 10.110.0.253/24, but configure the same VRR gateway address and VRR MAC.

Verify both MLAG and VRR before moving forward:

nv show mlag
nv show interface
net show clag

The peer must be alive, the peer link must be healthy, and the SVI plus VRR interfaces must show up.

Configure the Routed BGP Underlay

NVIDIA’s reference design uses eBGP, Auto BGP, and BGP unnumbered between leaf and spine interfaces. The pattern keeps the underlay simple while providing equal-cost paths between racks.

A leaf example looks like this:

nv set router bgp enable on
nv set vrf default router bgp autonomous-system leaf
nv set vrf default router bgp neighbor peerlink.4094 remote-as external
nv set vrf default router bgp neighbor swp51 remote-as external
nv set vrf default router bgp neighbor swp52 remote-as external
nv set vrf default router bgp router-id 10.10.10.1
nv config apply -y
nv config save

Use explicit ASNs instead of Auto BGP when that better fits enterprise routing policy, logging, troubleshooting, or route-governance requirements. The architectural requirement is not Auto BGP itself. The requirement is stable routed reachability between every TEP subnet with predictable equal-cost paths.

Advertise the TEP subnets into the underlay and verify that each rack learns the remote TEP routes.

net show bgp summary

Do not proceed until all expected fabric peers are established and the remote TEP prefixes are present in the routing table.

Deploy the NSX Manager Cluster

Deploy the First NSX Manager

Deploy the first NSX Manager appliance from the supported installation media. Record the following values before starting the wizard:

After deployment, use the appliance console to verify the management interface and service state:

get interface eth0
get services

A few optional services may remain stopped by default. The important result is that the management interface is correct, core services are running, DNS resolves, NTP is synchronized, and the UI is reachable through the intended management path.

Register vCenter as the Compute Manager

In NSX Manager, add vCenter as a compute manager under the Fabric configuration. Validate the certificate thumbprint and wait until both registration and connection status are healthy.

Do not treat compute-manager registration as a formality. NSX uses that relationship for cluster discovery, VDS selection, host preparation, Edge placement, and inventory synchronization.

Add the Remaining Manager Nodes

For production, deploy two additional Manager nodes from the NSX UI and form a three-node cluster. Keep the appliance sizes consistent and place the nodes across appropriate host and storage failure domains.

After all nodes are healthy:

Take the first NSX backup before preparing any hosts.

Build the NSX Transport Configuration

Create the Transport Zones

Create at least two transport zones:

Use clear names that describe site, rack, and purpose. Avoid names that only make sense during the installation project.

The host uplink profile must match the physical attachment decision.

For a non-LAG active-standby design, define:

For an LACP design, align the NSX uplink mapping with the VDS LAG and the NVIDIA MLAG bond. Do not copy a legacy N-VDS LAG example directly into NSX 4.x host preparation.

Create Edge profiles separately from the host profile. Edge nodes have different interfaces, traffic roles, and failure behavior.

A typical Edge design needs:

Do not assume the Edge can reuse the host LACP design. The NVIDIA reference design treats Edge external paths as separate numbered links to the leaf switches.

Create TEP IP Pools

Create TEP pools that match the routed fabric design. Per-rack host TEP pools provide clear fault isolation and make route troubleshooting easier.

For each pool, define:

Use a separate Edge TEP pool when the Edge nodes use a different VLAN, subnet, or lifecycle boundary.

Create the Transport Node Profiles

Create a transport node profile for each cluster configuration that differs by VDS, uplink mapping, TEP VLAN, or IP pool.

For NSX 4.x ESXi hosts, select the VDS as the host switch. Then map:

Applying one universal transport node profile to clusters with different rack-local TEP pools is a common design mistake. The profile should express the real physical attachment and IP plan.

Prepare the ESXi Clusters

Apply the transport node profile to a pilot cluster first. Watch both installation status and transport-node health.

A successful result should show:

Do not prepare every cluster in one change window until the pilot host pair has passed MTU, tunnel, failover, and workload tests.

Deploy the NSX Edge Cluster

Deploy at least two NSX Edge nodes for production north-south routing. Place them on different ESXi hosts and, where possible, different rack or failure domains.

For each Edge node, configure:

After deployment, create an Edge cluster and add both nodes.

Validate from the UI and, when needed, the Edge CLI:

get interfaces
get managers
get controllers

The Edge nodes must have healthy management and control-plane connectivity before Tier-0 routing is configured.

Configure Tier-0 Routing to the NVIDIA Fabric

Create one VLAN-backed segment for each physical Tier-0 uplink network. Associate them with the VLAN transport zone and the correct VLAN IDs.

Keep these segments dedicated to routing adjacency. Do not mix random appliance traffic, management traffic, and Tier-0 peering on the same VLAN simply because the subnet has available addresses.

Create the Tier-0 Gateway

Create the Tier-0 gateway and attach it to the Edge cluster.

Choose the HA mode based on services:

Create external interfaces for the NVIDIA leaf adjacencies. Each interface needs an IP address on its VLAN-backed uplink segment.

Configure Numbered BGP Peering

The NVIDIA design uses numbered BGP peering between NSX Edge uplinks and the leaf switches. Do not assume the unnumbered BGP pattern used inside the leaf-spine fabric also applies to the NSX Edge boundary.

An NVIDIA leaf-side example is:

nv set vrf default router bgp neighbor 172.20.10.2 remote-as 65050
nv config apply -y
nv config save

In NSX, configure:

Avoid unrestricted redistribution. A Tier-0 should not advertise every connected object simply because the BGP session is up.

Create the Tier-1 Gateway and Overlay Segment

Create a Tier-1 gateway, connect it to the Tier-0, and create an overlay segment for the test workload.

Attach test virtual machines only after:

Understand the Packet Flow

The deployment is easier to troubleshoot when the team can describe what changes at each hop.

For east-west traffic, the NVIDIA fabric sees routed traffic between TEP IP addresses. It does not need the tenant segment configured as a physical VLAN.

For north-south traffic, the Edge removes the NSX overlay context and forwards traffic through the Tier-0 external interface. The NVIDIA leaf then routes the packet based on the prefixes exchanged through BGP.

Validate the Deployment

Validate the NVIDIA Fabric

Run the following checks on each leaf and spine:

net show lldp
nv show interface
nv show mlag
net show clag
net show bgp summary

Confirm:

Validate TEP MTU from ESXi

Identify the NSX TEP VMkernel interface and test a remote TEP with the do-not-fragment flag. Replace the VMkernel interface and destination IP with values from the environment.

esxcli network ip interface list
vmkping ++netstack=vxlan -I vmk10 -d -s 8972 10.120.0.11

A successful 8972-byte payload validates a 9000-byte IP path. Test between racks, not only between hosts on the same leaf pair.

Validate NSX Transport Health

In NSX Manager, confirm:

Use NSX Traceflow to validate the logical forwarding path before assuming the issue is physical.

Validate Routing and Failure Behavior

Test more than a single successful ping.

TestExpected result
Same-segment VM traffic across hostsGeneve tunnel forwards without loss
Inter-segment traffic through Tier-1Distributed routing remains local to the hypervisor where possible
VM to external networkTraffic exits through Tier-0 and NVIDIA leaf routing
Remote network to VMReturn route is present and symmetric enough for the active services
Disable one ESXi uplinkHost remains reachable according to the selected teaming policy
Disable one leaf-facing Edge pathBGP reconverges and traffic uses the surviving path
Reboot one Edge nodeTier-0 behavior matches the selected HA mode
Large-packet testNo fragmentation or silent MTU drop occurs

Capture routing tables, BGP summaries, interface state, NSX alarms, and packet-loss measurements before and during each failure test.

Troubleshooting Common Failures

Hosts Prepare Successfully but Tunnels Stay Down

Likely causes include:

Start with the TEP IP, VLAN, route, and MTU. Reinstalling NSX software rarely fixes an underlay reachability problem.

BGP Remains Idle or Active

Check:

Establish basic IP reachability before changing BGP timers or adding BFD.

This may be correct for an active-standby design. Confirm the NSX uplink profile and VDS teaming policy before treating it as a fault.

For LACP, confirm:

Traffic Fails During Leaf Maintenance

Inspect MLAG peer-link health, VRR state, BGP convergence, and the host attachment model. A dual-cabled server is not automatically resilient if the switch pair does not agree on VLANs, bond state, or gateway ownership.

East-West Works but North-South Fails

That result usually means the overlay is healthy and the problem is at the Edge boundary.

Check:

Small Pings Work but Applications Fail

Suspect MTU first. Validate a large do-not-fragment packet between actual TEPs across the complete path. Also check that the physical switch MTU, VDS MTU, NSX profile MTU, and Edge data-path MTU are aligned.

Operational Handover and Rollback

A successful installation is not complete until the network and virtualization teams can operate it together.

Record:

Use a staged rollback sequence. Do not unprepare hosts while workloads still depend on NSX segments.

A safe rollback plan normally reverses the deployment in dependency order:

  1. Move or disconnect test workloads from NSX segments.
  2. Remove Tier-1 attachments and routing advertisements.
  3. Remove Tier-0 BGP neighbors and external interfaces.
  4. Remove Edge cluster dependencies before deleting Edge nodes.
  5. Unprepare only the pilot cluster after confirming no NSX-backed workloads remain.
  6. Revert NVIDIA switch changes from a known saved configuration.

Take NSX and switch backups before each major phase. A rollback should restore a known state, not create a third partially configured state.

Conclusion

Installing VMware NSX with an NVIDIA Spectrum network fabric is a cross-platform architecture exercise disguised as an installation wizard. The Manager appliances, transport zones, TEP pools, and Edge cluster are important, but they only work when the underlay provides deterministic reachability, MTU consistency, resilient gateway behavior, and clean routing boundaries.

The most reliable deployment order is to validate the NVIDIA fabric first, prepare a small NSX pilot second, prove TEP and Edge routing third, and only then scale host preparation across the environment. That sequence exposes physical and virtual mismatches while the blast radius is still small.

Keep the design boundaries explicit. Use VDS-backed host transport nodes on NSX 4.x, route TEP subnets through the NVIDIA fabric, keep the host and Edge uplink models separate, and use numbered BGP adjacencies at the Tier-0 boundary. When those decisions are documented and tested, NSX and Cumulus Linux form a clean, scalable network stack rather than two independent systems that happen to share cables.

External References

Exit mobile version