TL;DR · Key Takeaways
- A segment is the logical switch your VMs plug into. The NSX-T term “logical switch” is retired; in NSX 9 Policy it is a segment.
- Two kinds: overlay segments ride GENEVE and span every host with no physical VLAN, and VLAN segments map to a VLAN on the physical fabric.
- A segment is isolated Layer 2 until you connect it to a gateway. Attach it to a Tier-1 for routing, and the Tier-1 to a Tier-0 for north-south.
- Segment profiles (SpoofGuard, IP Discovery, MAC Discovery, Segment Security, QoS) control how the segment behaves. The defaults are sane; changing them blindly causes outages.
- For multi-rack overlays, leave BUM replication on Hierarchical Two-Tier. It is the efficient default and almost no one should switch to Head replication.
Everything so far has been plumbing. Transport zones, TEPs, Edges, the control plane: all of it exists so that you can do the one thing your workloads actually care about, which is plug into a network. That network is a segment. It is the most-used object in NSX and the one people understand least precisely, because it looks deceptively like a port group. It is not. A segment is a logical switch that can stretch across every host in your fabric without a single VLAN trunked between them, and understanding how it does that, and the knobs that quietly change its behaviour, is the difference between a network that just works and one that floods, blocks, or leaks.
Overlay segments vs VLAN segments
A segment comes in one of two flavours, and the difference is where its Layer 2 lives. An overlay segment is backed by the overlay transport zone and carried in GENEVE between host TEPs. Two VMs on the same overlay segment can sit on hosts in different racks, different subnets, even different workload domains, and still share a broadcast domain, because NSX tunnels their Layer 2 over your routed Layer 3 underlay. No VLAN is trunked end to end; the physical network only has to carry the TEP traffic. This is the magic that decouples logical networks from physical topology, and it is why an overlay segment can follow a VM anywhere the overlay reaches.
A VLAN segment is the bridge back to the physical world. It maps to a specific VLAN ID on the VDS and the fabric, so it behaves like a traditional VLAN-backed port group that NSX happens to manage. You use VLAN segments for the Edge uplinks to the Tier-0, for connecting to physical appliances that cannot live on the overlay, and for any workload that genuinely needs to share Layer 2 with something outside NSX. Most tenant workloads belong on overlay segments; VLAN segments are for the edges of the system where NSX meets hardware.
Connecting a segment to the rest of the world
A freshly created overlay segment is an island. VMs on it can talk to each other at Layer 2, and that is all, until you give it a gateway. Connect the segment to a Tier-1 gateway and it gains a default gateway and can route to other segments on that Tier-1, all distributed in the host kernel with no trip to an Edge. Connect that Tier-1 up to a Tier-0, and the segment can reach the physical world north-south. The segment itself does not change; what changes is what it is plugged into. This layering is deliberate: you decide isolation by what you do, or do not, attach a segment to, which is a cleaner model than hoping a VLAN was not trunked somewhere it should not have been.
Segment profiles: the knobs that change behaviour
Every segment carries a set of profiles that govern how it handles addresses, security, and quality of service. The defaults are deliberately conservative and right for most workloads, which is exactly why you should understand them before you override one. A wrong profile change is a subtle outage: traffic that used to pass now silently drops, or addresses that should be blocked now leak.
| Profile | What it controls | Watch out for |
|---|---|---|
| IP Discovery | How NSX learns VM IPs (DHCP/ARP/ND snooping, VMware Tools). | Disabling it breaks features that rely on learned IPs. |
| MAC Discovery | MAC learning and unknown-unicast handling. | Enabling MAC learning where you do not need it adds flooding. |
| SpoofGuard | Blocks traffic from a wrong IP or MAC (anti-spoofing). | Turning it on with bad discovery data blocks real VMs. |
| Segment Security | BPDU filter, DHCP server block, rate limits. | Loosening it can let a rogue DHCP server onto the segment. |
| QoS | DSCP marking and traffic shaping per segment. | Marking that the fabric ignores does nothing; coordinate it. |
BUM replication: leave it on Hierarchical
Broadcast, unknown-unicast, and multicast traffic, BUM for short, has to reach every host that has a VM on the segment, and the overlay has two ways to do that. Head replication makes the source host send a separate copy directly to every other host TEP. It is simple and fine on a small, flat fabric. Hierarchical Two-Tier replication is smarter: the source sends one copy to a single host in each remote TEP subnet, and that host re-replicates locally to its neighbours. On a multi-rack fabric this cuts the cross-rack copies dramatically and is the recommended default. Unless you have a specific, unusual reason, leave segments on Hierarchical Two-Tier and do not think about it again.
Overlay or VLAN: choosing per workload
Most segments should be overlay, but the choice is worth making consciously per workload rather than by reflex. The question is simple: does this workload need to share Layer 2 with something NSX does not manage? If yes, it is a VLAN segment. If no, make it overlay and gain mobility, scale, and independence from the physical VLAN plan. The table below is the quick decision I run in design reviews.
| Dimension | Overlay segment | VLAN segment |
|---|---|---|
| Spans hosts/racks | Yes, anywhere the overlay reaches. | Only where the VLAN is trunked. |
| Needs a physical VLAN | No. Just TEP reachability. | Yes, a VLAN ID on the fabric. |
| VM mobility | Free; the network follows the VM. | Bounded by VLAN reach. |
| Shares L2 with physical | No, unless bridged deliberately. | Yes, that is the point. |
| Use it for | Tenant and app workloads. The default. | Edge uplinks, physical appliances, bridging. |
How a VM actually joins a segment
Once a segment exists, attaching a workload is the part that feels familiar: the segment shows up in vCenter as a network you connect the VM’s vNIC to, exactly like a port group. Behind that familiar action, NSX creates a logical port on the segment for that vNIC, applies the segment’s profiles to it, and realizes the configuration down to the host where the VM runs. If you later vMotion the VM to another host, the logical port and all its policy move with it, which is the whole reason the overlay exists. The VM never knows it changed racks; its segment, its firewall rules, and its IP all follow.
This is also where the Distributed Firewall hooks in, at the logical port, right at the vNIC, which is why micro-segmentation can follow a VM the way it does. For now the point to hold onto is that the segment is the anchor: create it, set its profiles, connect it to a gateway if it needs to route, and attach VMs. Everything else in NSX, the firewall rules in Parts 12 to 15, the routing in Parts 9 and 10, builds on this one object being right. If your segments are clean and deliberately connected, the rest of the design has somewhere solid to stand.
The segment mistakes I see most
Three patterns account for most segment trouble. The first is putting workloads on VLAN segments out of habit when an overlay segment would decouple them from the physical network and save a future renumbering. The second is enabling SpoofGuard or tightening Segment Security without first trusting the IP and MAC discovery data, which turns a hardening step into an outage. The third is overusing tiny, single-purpose segments until the count balloons and the design becomes hard to reason about; segments are cheap, but a thousand of them with no naming discipline is its own kind of debt. None of these are exotic. They are the ordinary ways a powerful, flexible object gets misused when people treat it like the port group it resembles.
What I’d Do
Default to overlay segments for tenant workloads and reserve VLAN segments for uplinks and physical neighbours. Attach segments to gateways deliberately, one tier at a time, and treat isolation as a design choice you make on purpose rather than a setting. Leave the segment profiles on their defaults unless you can articulate exactly why a change is safe, and stage any SpoofGuard or Segment Security tightening on a test segment first. Leave BUM replication on Hierarchical Two-Tier. Get a naming convention agreed before you create the tenth segment, not the thousandth. Do all that and segments become the boring, reliable building block they should be, which lets the firewall and routing work in later parts sit on solid ground. Next up is Part 9: Tier-0 gateways and north-south routing with BGP. How many of your segments could be overlay that are VLAN today?
Segment profiles are where switching quietly goes wrong
A segment is rarely just an address range; it carries a set of profiles, and the defaults on those profiles are responsible for a surprising share of confusing connectivity problems. Segment security, MAC discovery, IP discovery and QoS profiles each shape what the segment will and will not allow, and the IP and MAC discovery behaviour in particular decides which addresses NSX learns and trusts. A workload that is not being learned correctly, or that trips a MAC limit, fails in ways that look like a firewall problem but are really a profile setting nobody reviewed.
The other quiet decision is overlay versus VLAN-backed segments. Overlay segments give you portable, distributed Layer 2 that follows the workload anywhere in the transport zone, and that is the right default for almost everything. VLAN-backed segments exist to bridge into the physical network, and reaching for them when an overlay segment would do is how you tie a workload to a piece of physical infrastructure you were trying to abstract away. Choose overlay unless a specific bridging requirement forces VLAN, and review the profiles on every segment that misbehaves before you blame the firewall.
How overlay handles broadcast, and why that scales
One of the quieter reasons overlay segments scale where VLANs do not is how they handle broadcast, unknown-unicast and multicast traffic. On a traditional VLAN, that flooded traffic touches every port in the broadcast domain, which is exactly why large flat VLANs become fragile at scale. In an NSX overlay, that same category of traffic is replicated in a controlled way between transport nodes rather than flooded across a physical segment, so the segment can span the whole transport zone without dragging the physical fabric into a single enormous broadcast domain. The workload sees ordinary Layer 2, but the underlay never has to.
That decoupling is the whole point. Your segments are bounded by the transport zone and by NSX, not by the reach and the limits of a physical VLAN, so you can give applications the Layer 2 adjacency they expect without the physical sprawl and the failure radius that flat VLANs imply. The design lesson is to stop thinking in terms of how far a VLAN can safely stretch and start thinking in terms of transport-zone span. The overlay was built precisely so that the question how big can this Layer 2 domain get stops being answered by the limits of your physical switching.
References
- NSX 9.0 Administration Guide (Broadcom TechDocs)
- NSX 9 Design and Planning: Transport Zones, MTU, TEP Pools and EDP (NSX Series, Part 4)
- NSX 9 Architecture (NSX Series, Part 2)
About The Author
