NSX for Dummies, Part 1: Networks Made of Software (Explained Without the Fog)

NSX has a reputation for being impenetrable, and it’s half-deserved — the product’s vocabulary (segments, tier-1s, transport zones, TEPs) sounds like it was designed to keep outsiders out. But underneath sits one idea, and once it clicks, the vocabulary sorts itself into place. This series assumes you know roughly what a VLAN and a router are, and nothing about NSX.

The problem NSX exists to solve

In a traditional datacenter, when an application team needs a new network, this happens: a ticket to the network team, a VLAN allocated from a spreadsheet, switch ports configured, a gateway added on the physical router, maybe firewall rules on a central appliance. Days or weeks — for a construct the VMs will treat as “a wire.”

Meanwhile, compute solved this exact problem years ago. Nobody files a ticket to “allocate a server” anymore; a VM appears in minutes because the physical thing (a host) was abstracted into a software thing (a VM). NSX applies the same move to the network: the physical network becomes dumb, fast plumbing, and the interesting parts — switching, routing, firewalling — become software running on your ESXi hosts.

The one mental model: the postal system

Here’s the mechanism, and it’s the only genuinely new concept in the entire product. Everything in later parts is built from it.

When VM-A (on host 1) sends a packet to VM-B (on host 5), NSX doesn’t ask the physical network to understand VM networks at all. Instead, host 1 takes VM-A’s entire packet and puts it inside an envelope — a second, outer packet addressed from host 1 to host 5. The physical network delivers the envelope like any other traffic between two hosts. Host 5 opens it and hands the original packet to VM-B.

  VM-A ──packet──▶ [host 1 wraps it]  ═══ physical network ═══▶  [host 5 unwraps] ──▶ VM-B

  outer packet:  host1-IP → host5-IP      (all the physical network ever sees)
  inner packet:  VM-A → VM-B              (the "real" traffic, invisible in transit)

This is overlay networking (the envelope format is called Geneve; its ancestor VXLAN you may have heard of). The consequences fall out immediately:

• The physical network only needs to do one job: move packets between host IPs, quickly. No VLANs per app, no spreadsheet, no tickets.
• A “network” for VMs is now just an agreement between hosts about which envelope markings belong together. Creating one is a software operation — an API call, a second of work.
• Two VMs on the same NSX network can sit anywhere the overlay reaches — different racks, different rows — and believe they share a cable.

The pieces, now that the model exists

With the postal system in your head, NSX’s architecture is four short introductions:

Segments are the networks VMs plug into — the software replacement for “a VLAN.” Layer 2 domains built from envelope agreements. Part 2 explains where they fit in the rest of the overlay architecture.

Gateways do routing between segments and out to the physical world. They come in two tiers — Tier-1 (routing between your app’s segments) and Tier-0 (the border crossing where overlay traffic exits to the physical network, usually speaking BGP to your real routers). Why two tiers? Delegation: the infrastructure team owns the border (T0) once; app environments get their own T1s without anyone touching the border again. It’s the network equivalent of resource pools.

The Distributed Firewall (DFW) is the piece that justifies NSX economically for many shops, and it’s barely about networking at all: firewall rules enforced at every VM’s virtual NIC, by the hypervisor, regardless of what network the VM sits on. Traffic between two VMs on the same segment — which a traditional perimeter firewall never even sees — passes through policy. This is what people mean by “microsegmentation,” and it’s the subject of most of part 2 (and, at production scale, the architecture notes on rolling it out without boiling the ocean).

NSX Manager is the control plane — a VM appliance (clustered in production) holding desired state and programming the hosts. Crucial architectural fact: it’s not in the data path. Manager down means you can’t change the network; traffic flows on, unbothered.

What NSX costs you (honesty section)

The trade-offs, before you fall in love: it’s a licensed product with real cost; it adds a control plane your team must operate and upgrade; troubleshooting gains a layer (is the problem in the overlay or the underlay?); and your network team needs to be in the room from day one — NSX repositions their job, and a deployment they’re hostile to will fail organizationally long before it fails technically.

What you get back: networks and firewall policy at software speed, security that travels with the VM, and a datacenter network whose physical layer becomes radically simpler — fast, dumb, stable plumbing.

What’s next

In Part 2 we map the overlay architecture: NSX Manager, transport zones, tunnel endpoints, segments, gateways, and the distributed firewall. The goal is to understand what each component owns before you ever need to implement or troubleshoot one.