NSX Deep Dive — Architecture Series
NSX Profiles: The Complete Reference
from 4.x to VCF 9
If you have spent any time deploying NSX, you will have encountered profiles — and you will know that the variety and overlap between them can be genuinely confusing the first time you map them all out. Which profile controls my TEP VLAN? Where do I enforce anti-spoofing? Why do I have both a Segment Security profile and a SpoofGuard profile?
This post cuts through that confusion with a structured walkthrough of every profile type, what it does, and how it fits into the broader fabric of an NSX deployment. We also cover what has changed — and what has been confirmed as different — with the arrival of VCF 9 and NSX 9.
1Fabric and infrastructure profiles
These profiles define how physical and virtual hardware form the NSX data plane. Getting these right is the foundation of any healthy deployment — everything from tunnel endpoint reachability to edge failover timing lives here.
Uplink profile
FabricDefines how a Transport Node connects to the physical network. Configures MTU, the transport VLAN for TEPs, and the teaming policy governing how physical NICs are used. Multiple named teaming policies can be defined within a single profile — essential for pinning TEP and workload traffic to different uplinks in a converged VDS deployment.
MTU · TEP VLAN · Failover / Load Balance Source
Transport Node Profile (TNP)
FabricA master template applied to an entire ESXi cluster. When attached, NSX automatically installs data plane components and configures the vDS on every host. A Sub-TNP variant handles stretched or multi-rack L3 topologies where different racks need distinct TEP VLANs.
Contains: Uplink Profile · Transport Zones · IP Assignment · vDS mappings
Edge Cluster Profile
FabricControls liveness detection across Edge nodes. Configures BFD timers to determine how quickly the control plane declares an Edge node dead and triggers failover to its standby peer.
BFD probe interval · BFD declare dead multiple
Uplink profile tip: Named teaming policies are only usable with VLAN-backed segments. In a converged VDS environment, use them to pin TEP traffic to one NIC pair and workload traffic to another — without deploying a separate N-VDS. This is a common design pattern for management and compute clusters sharing a single VDS.
2Segment profiles
Segment profiles are applied to logical segments and their ports to govern how traffic is admitted, tracked, classified, and secured at the virtual port level. This is where the majority of day-to-day operational tuning happens.
IP Discovery profile
SegmentDetermines how NSX learns the IP addresses of VMs attached to a segment. Uses ARP snooping, DHCP/DHCPv6 snooping, VMware Tools, and IPv6 ND snooping. Discovered bindings drive ARP suppression and are the authoritative source for DFW policy resolution.
Includes two trust models: Trust on First Use (TOFU), where the first discovered IP is pinned permanently, and Trust on Every Use (TOEU), where bindings age out dynamically.
Feeds: ARP suppression · SpoofGuard · DFW rule evaluation
MAC Discovery profile
SegmentControls MAC address learning at the port level. MAC learning must be enabled for scenarios where more than one MAC appears behind a vNIC — nested hypervisors, Kubernetes CNIs, software bridges, and NFV appliances. Also controls whether a VM is permitted to change its own MAC address.
Critical for: Nested virt · Containers · NFV workloads
SpoofGuard profile
SegmentActively enforces the IP and MAC bindings discovered by the IP Discovery profile. When a VM sends traffic whose source IP or MAC does not match its realised bindings, SpoofGuard drops the packet at the vNIC — before it reaches the segment. Enforced at both port and segment scope; both levels must pass.
Validates: MAC source · IP source · ARP/GARP/ND payload
Segment Security profile
SegmentLayer 2 security enforcement at the segment level. Controls BPDU filtering (preventing STP propagation into the overlay), DHCP server filtering (blocking rogue DHCP servers), and rate limiting on broadcast and multicast traffic. Works alongside SpoofGuard, not in place of it.
BPDU filter · DHCP server guard · Broadcast/multicast rate limits
QoS profile
SegmentApplies traffic marking and bandwidth shaping to tunnelled overlay traffic. Supports Layer 2 CoS (802.1p) and Layer 3 DSCP marking in trusted or untrusted mode. Bandwidth limiting sets average and peak (burst) transmit rates. Applies only to tunnelled traffic — intra-host VM-to-VM traffic bypasses this entirely.
Note: Does not apply to intra-host traffic
3Security and gateway profiles
These profiles configure advanced inspection, threat prevention, and QoS behaviour for the gateway and firewall layers. They are consumed by the Distributed Firewall, NSX Gateway Firewall, and the Intrusion Detection and Prevention engine.
Context profile (L7)
SecurityEnables the DFW to make decisions based on Layer 7 application identity rather than port and IP alone. NSX ships with a large library of FQDN-based, domain-based, and protocol-based application signatures — allowing policy that reflects business intent rather than network topology.
Used in: DFW rules as the App ID condition
IDS/IPS profile
SecurityConfigures the NSX Distributed IDS/IPS engine. Defines which signature sets are active, severity thresholds, and whether the engine runs in detect-only or active-block mode. Signatures can be scoped by CVE severity, CVSS score, or affected product family.
Modes: Detect only · Detect and Prevent
Malware Prevention profile
SecurityControls how the NSX malware detection engine extracts files from east-west flows and submits them for sandbox analysis via NSX Advanced Threat Prevention. Configures file type filters and the action taken on a positive verdict.
Requires: NSX Advanced Threat Prevention licence
Gateway QoS profile
SecurityApplies bandwidth shaping to north-south traffic flowing through Tier-0 or Tier-1 gateway uplinks. Distinct from Segment QoS which operates on east-west overlay traffic. Used to enforce CIR and burst rates per gateway uplink — important in multi-tenant environments to prevent a single tenant saturating shared edge uplinks.
Scope: Gateway uplink interfaces only
4What changed: NSX 4.x vs VCF 9
The profile types themselves are largely consistent across versions. What VCF 9 changes is the ownership and governance model around them. The single most important confirmed change: NSX is no longer available as a standalone product.
| Area | NSX 4.x | VCF 9 / NSX 9 | Status |
|---|---|---|---|
| Deployment model | Deployable standalone or within VCF | Exclusively delivered within VCF stack; standalone deployment blocked | Breaking change |
| Lifecycle management | NSX upgradeable independently via NSX Manager UI | All upgrades orchestrated by SDDC Manager as part of VCF lifecycle | Removed |
| Policy API | Policy API preferred; Manager API legacy objects still accessible | Policy API is the exclusive standard; deprecated and removed APIs formally catalogued in NSX API Guide | Tightened |
| Transport Node Profile | Managed via NSX Manager UI or SDDC Manager | TNP lifecycle owned by SDDC Manager; out-of-band changes risk drift flagged by the platform | VCF-owned |
| Edge deployment | Edge VMs deployed via SDDC Manager JSON/UI | New vCenter UI wizard available; Tier-1 replaced by Transit Gateway in VPC networking model | New capability |
| Networking models | Segment networking only (T0 / T1 / Segments) | Two models: Segment Networking (unchanged) and VPC Networking (new cloud-native model) | VPC model added |
| IWA authentication | Integrated Windows Authentication supported | IWA deprecated; LDAP/S is the replacement | Deprecated |
| Segment profiles | Full profile set (IP Discovery, MAC, SpoofGuard, Security, QoS) | All segment profile types confirmed present and unchanged in NSX 9 | Confirmed |
| Certificate management | Manual certificate rotation | Upgrade precheck for expiring Transport Node SSL certs (90-day warning); CARR script integration | New precheck |
Architect's note on the VPC networking model: VCF 9 introduces VPC Networking alongside the familiar Segment Networking model. Segment Networking remains fully supported and is the right choice where centralised admin control is required. VPC Networking aligns with public-cloud consumption patterns and enables self-service for tenants via NSX Projects. The Transit Gateway is the key new construct — interconnecting VPCs and connecting them to physical infrastructure either via a Tier-0 (centralised, requires Edge VMs) or directly via an external VLAN (distributed connectivity, no Edge VMs required).
5Practical design principles
Keep Uplink Profiles minimal
Create one Uplink Profile per physical hardware pattern. If all hosts share the same NIC speed, TEP VLAN, and MTU, a single profile should cover your entire compute fabric. Proliferating profiles for minor differences makes lifecycle management harder under SDDC Manager.
Treat TNPs as immutable once applied
In VCF 9, SDDC Manager owns the TNP lifecycle. Make changes through a change-controlled TNP update process via SDDC Manager — not ad-hoc in the NSX UI. Configuration drift between the TNP and host state is now flagged by the platform and will block upgrade operations.
Always pair IP Discovery with SpoofGuard
IP Discovery alone is passive — it discovers and logs. SpoofGuard is what enforces. For production segments carrying sensitive workloads, enable both. Use TOFU mode for stable workloads; use TOEU for dynamic environments where IP churn is expected and binding permanence would cause operational friction.
Enable MAC learning intentionally
MAC learning is off by default for good reason — enabling it on a general-purpose workload segment weakens address-based policy enforcement. Enable it only on segments explicitly designed for nested hypervisors, containers, or network appliances. When you do, enable SpoofGuard in parallel to compensate.
Summary
NSX profiles have remained structurally consistent from NSX-T 3.x through NSX 4.x and into VCF 9. The fabric layer (Uplink, TNP, Edge Cluster), segment layer (IP Discovery, MAC, SpoofGuard, Segment Security, QoS), and security layer (Context, IDS/IPS, Malware Prevention, Gateway QoS) are all present in the current release. What VCF 9 changes is not the profile taxonomy — it is the ownership model. SDDC Manager is now the authoritative orchestrator for profile lifecycle, the Policy API is the only sanctioned management path, and NSX can no longer be deployed or upgraded in isolation. For architects migrating from 4.x, the profile knowledge transfers directly; the operational shift is in governance, not configuration.
No comments:
Post a Comment