For many VMware administrators, networking is the point where VMware Cloud Foundation starts to feel different.
Most of us entered the VMware world through vSphere. We became comfortable with ESX, vCenter, clusters, DRS, HA, vMotion, datastores and virtual machines. That was the world we knew. We could build clusters, troubleshoot hosts, move workloads, manage capacity and keep platforms running.
Then VMware Cloud Foundation brings NSX into the centre of the conversation.
Suddenly the language changes.
People start talking about Tier-0 Gateways, Tier-1 Gateways, Segments, Distributed Firewall, Edge Nodes, Transport Zones, VPCs, Transit Gateways, North-South traffic and East-West traffic.
At first, it can feel like a different discipline altogether.
But it is not.
NSX is not there to make networking complicated.
NSX exists because traditional data centre networking was not designed for the speed, automation and security model required by modern private cloud.
To understand NSX properly, we need to step back and look at the problem VMware was trying to solve.
Why Traditional Networking Became a Bottleneck
In a traditional VMware environment, the virtualisation team could build servers quickly.
A project team asks for five virtual machines. The VMware administrator creates the VMs, attaches them to port groups, allocates CPU and memory, connects storage, installs the operating system, and the compute side is largely complete.
But the application is not ready yet.
The team still needs VLANs.
They need firewall rules.
They need routing.
They may need load balancing.
They may need isolated networks for testing.
They may need connectivity between environments.
They may need security policies between application tiers.
This is where delivery slows down.
The VMware administrator can create the VM in minutes, but the network change may take days or weeks because the configuration often sits outside the virtualisation platform. It requires coordination with network teams, firewall teams, security teams and sometimes external providers.
This is not because those teams are slow.
It is because physical networking was built for stability and control, not rapid application delivery.
Cloud changed the expectation.
In AWS, Azure or Google Cloud, teams expect to create networks, subnets, routing, firewalls and isolated environments through software. Nobody raises a ticket to configure a physical switch every time a new application environment is required.
VMware needed to bring that same operating model into the private data centre.
That is the background to NSX.
What NSX Really Means
The simplest way to understand NSX is this:
NSX virtualises the network in the same way ESX virtualised compute.
Before ESX, an application usually depended on a physical server. If you needed another application environment, you often needed another server. ESX changed that model by abstracting compute from hardware. Virtual machines could run on shared physical infrastructure while still behaving like independent servers.
NSX applies the same idea to networking.
Before NSX, network services were strongly tied to physical infrastructure. VLANs lived on switches. Routing lived on routers. Firewalls lived on firewall appliances. Load balancing lived on load balancer appliances.
NSX abstracts those services into software.
That means networking becomes programmable.
Security becomes programmable.
Routing becomes programmable.
Firewalling becomes programmable.
This is the foundation of software-defined networking.
The physical network still matters. NSX does not remove the need for physical switches, uplinks, routing or resilient underlay design. What NSX does is reduce the dependency on physical change every time the application environment needs to evolve.
In a VMware Cloud Foundation environment, this becomes critical because VCF is designed to operate as a private cloud platform, not just a virtualisation estate.
Why NSX Is So Important in VMware Cloud Foundation
In older VMware environments, NSX was often seen as an optional product.
Some customers used it for micro-segmentation.
Some used it for overlay networking.
Some used it for security.
Some did not use it at all.
In VMware Cloud Foundation, that mindset changes.
NSX becomes part of the platform architecture.
VCF is trying to deliver a cloud operating model. A cloud operating model needs automated networking, consistent security, workload mobility, tenant isolation and predictable lifecycle management.
Without software-defined networking, VCF would still depend heavily on manual physical network change. That would break the promise of cloud-like operations.
This is why NSX is so central to VCF.
vCenter gives you the compute control plane.
vSAN gives you software-defined storage.
SDDC Manager gives you lifecycle and domain management.
NSX gives you the network and security fabric.
Once you understand that, NSX stops looking like a separate product and starts looking like a core layer of the private cloud.
The Three Planes of NSX
One of the most important concepts to understand in NSX is the idea of planes.
This is common in networking architecture, but it can feel abstract at first.
NSX is easier to understand when you separate it into three areas: the management plane, the control plane and the data plane.
Each plane has a different job.
If you understand which plane is responsible for which job, troubleshooting becomes much easier.
The Management Plane
The management plane is where configuration is created and stored.
When an administrator logs into NSX Manager and creates a Segment, configures a Gateway, defines a firewall policy, creates a VPC or changes routing configuration, they are working with the management plane.
The management plane is about intent.
It records what you want the network to look like.
For example, you might say:
I want a Segment called App-Web.
I want it connected to a Tier-1 Gateway.
I want that Tier-1 Gateway connected to a Tier-0 Gateway.
I want a firewall rule that allows web traffic from the internet to the web tier.
I want database traffic only from the application tier.
The management plane stores those decisions.
In traditional networking, these decisions might be spread across multiple switches, routers and firewalls. In NSX, the configuration is centralised and policy-driven.
NSX Manager is the most visible part of the management plane. It provides the interface and API through which administrators and automation tools define the desired state of the network.
In VCF environments, some NSX capabilities are also surfaced through vCenter and VMware Cloud Foundation workflows. This is part of VMwareโs broader direction, making private cloud operations more integrated and less fragmented.
For the VCF exam, it is important to remember that the management plane is not where packets are forwarded. It is where configuration is defined.
That distinction matters.
If an administrator creates the wrong policy, that is a management plane problem.
If the policy is correct but not distributed properly, that may involve the control plane.
If everything is configured correctly but traffic still does not flow, the issue may be in the data plane, routing, firewall enforcement or the underlying physical network.
The Control Plane
The control plane is responsible for distributing network state and making forwarding information available across the NSX environment.
If the management plane says what the network should look like, the control plane helps the environment understand how to make that happen.
It deals with questions such as:
Where does this workload live?
Which ESX host is running this virtual machine?
Which routes should be known?
Which tunnel endpoints are involved?
Which Gateway should handle this traffic?
Which distributed components need updated forwarding information?
The control plane is not the user interface.
It is also not the place where the actual application traffic is forwarded.
Its job is to distribute intelligence.
A good analogy is air traffic control.
The management plane decides that a new airport route exists.
The control plane ensures that the relevant towers and systems know how flights should be directed.
The data plane is the actual aircraft moving passengers.
In NSX, the control plane is what allows a distributed software network to behave consistently across many ESX hosts and Edge Nodes.
This is extremely important because modern VCF environments are distributed by design. Workloads may live across multiple hosts, clusters or workload domains. The network must understand where those workloads are and how traffic should reach them.
For the exam, remember that the control plane is about network state, route distribution and communication between NSX components. It is the layer that helps translate desired configuration into usable network behaviour.
The Data Plane
The data plane is where traffic actually moves.
When a virtual machine sends traffic to another virtual machine, that is data plane traffic.
When a workload reaches an external network, that is data plane traffic.
When a packet is routed, switched, filtered or forwarded, the data plane is involved.
In NSX, the data plane exists across ESX hosts and NSX Edge Nodes.
This is one of the most powerful parts of the architecture.
Instead of forcing all traffic through a central physical appliance, NSX can perform many services in a distributed way. Routing and firewalling can happen close to the workload, directly in the hypervisor.
This is why NSX scales well.
Traffic does not always need to hairpin through a central device. East-West traffic between workloads can often be handled locally and efficiently.
For troubleshooting, the data plane is where you ask practical questions.
Can the VM reach its default gateway?
Is the Segment connected correctly?
Is the distributed firewall allowing the traffic?
Is routing working between Tier-1 and Tier-0?
Is the Edge Node forwarding North-South traffic?
Is the physical network receiving the advertised routes?
This is where architecture becomes real.
Segments, The New Starting Point for Workload Networking
When you connect a virtual machine to a network in NSX, you usually connect it to a Segment.
A Segment is a logical Layer 2 network.
For VMware administrators, the easiest comparison is a port group or VLAN-backed network, but that comparison only goes so far.
A traditional VLAN depends on the physical network.
The VLAN must exist on the physical switch.
The trunk must carry the VLAN.
The upstream network must understand the VLAN.
A Segment, by contrast, is created in software.
The physical network still provides transport, but the logical network exists inside NSX. This allows administrators to create application networks quickly without waiting for physical switch configuration every time.
For example, you might create a Segment for web servers, another for application servers and another for database servers. Each Segment provides network separation. Each Segment can have its own security rules and connectivity model.
This is the beginning of cloud-like networking.
Instead of asking the network team to build every network manually, platform teams can define logical networks as part of the environment.
Tier-1 Gateways, The Local Gateway for Applications
Once workloads are connected to Segments, they usually need routing.
This is where Gateways come in.
A Tier-1 Gateway is typically the first routing point for application networks.
Think of Tier-1 as the local router for a group of application Segments.
For example, an application may have a web Segment, an app Segment and a database Segment. Those Segments may all connect to the same Tier-1 Gateway. The Tier-1 Gateway provides routing between those networks and connects them upward toward the rest of the environment.
This gives administrators a clean way to organise applications.
A development environment can have its own Tier-1 Gateway.
A production application can have its own Tier-1 Gateway.
A DMZ environment can have its own Tier-1 Gateway.
This design creates separation and control.
The Tier-1 Gateway can also be associated with services such as NAT, load balancing and firewalling depending on design and licensing. From an exam point of view, the most important idea is that Tier-1 usually sits close to the workload and connects application networks upward toward Tier-0.
Tier-0 Gateways, The Bridge to the Outside World
The Tier-0 Gateway sits above the Tier-1 Gateway.
If Tier-1 is close to the application, Tier-0 is close to the physical network.
Tier-0 provides North-South connectivity. That means traffic entering or leaving the NSX environment usually passes through Tier-0.
A Tier-0 Gateway commonly connects to the physical network using dynamic routing such as BGP. It can advertise routes from NSX to the physical network and learn routes from the physical network into NSX.
This is one of the most important NSX concepts for VCF administrators.
Traffic from a VM to the internet may follow this path:
The VM sends traffic to its Segment.
The Segment connects to a Tier-1 Gateway.
The Tier-1 Gateway forwards upward to Tier-0.
Tier-0 forwards toward the physical network through Edge Nodes.
The physical network then routes the traffic to the next destination.
This hierarchy is central to NSX.
If you understand Segment to Tier-1 to Tier-0 to physical network, you understand the foundation of NSX routing.
NSX Edge Nodes, Where Centralised Services Live
When people first learn NSX, they often ask where Tier-0 and Tier-1 Gateways actually run.
The answer depends on the type of service.
Some routing is distributed and happens on the ESX hosts.
Some services require Edge Nodes.
An NSX Edge Node is an appliance that provides centralised networking services. Edge Nodes are commonly used for North-South routing, NAT, VPN, load balancing and connectivity to the physical network.
In a production design, Edge Nodes are usually deployed in clusters for resilience.
This matters because not every NSX function is distributed across all ESX hosts. Some services need a centralised service router component, and that is where Edge Nodes become important.
For the exam and for real environments, always ask:
Is this traffic handled in a distributed way on the ESX host, or does it need to go through an Edge Node?
That question often leads you to the correct troubleshooting path.
Distributed Routing, Why NSX Does Not Behave Like Traditional Networks
Distributed routing is one of the most powerful ideas in NSX.
In traditional networking, routing usually happens on a physical router or Layer 3 switch. Traffic must travel to that device before it can be routed.
NSX changes this model.
With distributed routing, routing can happen directly in the hypervisor, close to the virtual machine.
This is especially useful for East-West traffic, which is traffic moving between workloads inside the data centre.
Imagine a web server and an application server running on the same ESX host but on different logical networks. In a traditional model, traffic might leave the host, reach a router, then come back. That is inefficient.
With distributed routing, NSX can route that traffic locally.
This reduces latency.
It reduces unnecessary network hops.
It improves scale.
It also means the network becomes much more closely tied to the hypervisor.
For vSphere administrators, this is the mental shift.
The ESX host is no longer just running virtual machines.
It is participating in the network fabric.
Distributed Firewall, Security at the Workload Level
Traditional firewalls protect the edge of the network.
They are very good at inspecting traffic entering or leaving an environment.
But modern threats do not always stay at the edge.
Once an attacker compromises one system, they often try to move laterally. They move from server to server, from application tier to database tier, from user subnet to management subnet.
This lateral movement is difficult to control with only perimeter firewalls.
NSX Distributed Firewall solves this by placing firewall enforcement close to the workload, inside the hypervisor.
Instead of sending traffic to a central firewall, policy can be enforced at the virtual NIC level.
This is a major architectural shift.
Every workload can have its own security boundary.
A web server can be allowed to talk to an application server on a specific port.
The application server can be allowed to talk to a database server.
Everything else can be denied.
This is the foundation of micro-segmentation.
Micro-Segmentation, Security Designed for Modern Threats
Micro-segmentation is often explained badly.
It is not simply โmore firewall rules.โ
It is the practice of reducing unnecessary communication between workloads.
The old data centre model often trusted everything inside the network. Once traffic was internal, it was often allowed more freely.
That model no longer works.
Modern security assumes that compromise is possible. The goal is to reduce the blast radius.
If one server is compromised, it should not automatically be able to talk to every other server.
Micro-segmentation allows organisations to define security based on application behaviour rather than network location alone.
This is why NSX became so important to VMwareโs security story.
Security is no longer only at the perimeter.
Security follows the workload.
For VCF administrators, this matters because networking and security are now joined together. You cannot fully understand NSX networking without understanding distributed security.
North-South and East-West Traffic
Two terms appear constantly in NSX conversations: North-South and East-West.
North-South traffic is traffic entering or leaving the environment.
A user accessing an application from outside the data centre is North-South traffic.
A VM reaching the internet is North-South traffic.
An application calling an external API is North-South traffic.
This traffic usually involves Tier-0, Edge Nodes and the physical network.
East-West traffic is traffic that stays inside the data centre.
A web server talking to an application server is East-West traffic.
An application server talking to a database server is East-West traffic.
A Kubernetes node talking to another Kubernetes node is East-West traffic.
This traffic often benefits from distributed routing and distributed firewalling.
Understanding the difference between North-South and East-West traffic helps you troubleshoot faster.
If the issue is external access, think Tier-0, Edge Nodes, BGP, NAT, upstream routing and physical connectivity.
If the issue is workload-to-workload traffic, think Segments, Tier-1, distributed routing, distributed firewall and local workload connectivity.
VPCs in VMware Cloud Foundation 9.1
VCF 9.1 continues VMwareโs move toward a more cloud-like operating model, and one of the most important concepts in that direction is the Virtual Private Cloud, or VPC.
Many people already know the term from AWS.
A VPC is an isolated logical network environment. It gives a team, tenant or application group its own private networking space inside a larger shared platform.
In a traditional enterprise environment, creating this level of isolation could involve multiple VLANs, firewall contexts, routing changes and manual coordination.
With VPCs, the goal is to make that experience simpler and more self-service.
A platform team can provide isolated network environments to application teams without giving each team direct control over the underlying infrastructure.
This is important for large enterprises, service providers and internal platform teams.
It allows VCF to behave more like a private cloud platform rather than a traditional virtualisation environment.
In simple terms, VPCs help VMware Cloud Foundation move from โthe infrastructure team builds everything manuallyโ toward โthe platform provides controlled self-service.โ
Transit Gateways, Connecting VPCs Without Creating Chaos
As soon as you create multiple VPCs, another question appears.
How do they communicate?
If every VPC connects directly to every other VPC, the design quickly becomes messy.
This is where Transit Gateway concepts become useful.
A Transit Gateway acts as a central routing point between multiple isolated environments.
Instead of building many individual connections, traffic can pass through a central routing hub.
This simplifies connectivity.
It improves control.
It makes routing easier to manage at scale.
For VCF 9.1, this matters because VMware is strengthening the private cloud networking model. VPCs provide isolated environments. Transit Gateway capabilities help connect those environments in a controlled way.
For administrators, the key is not to memorise terminology.
The key is to understand the design pattern.
Isolation is useful.
Connectivity is also required.
Transit Gateway helps balance both.
How to Troubleshoot NSX Like an Architect
Many administrators troubleshoot NSX by jumping straight into the interface and clicking around.
That usually wastes time.
A better method is to follow the traffic.
Start with the workload.
Can the VM reach its own default gateway?
If not, check the VM network adapter, Segment connection, IP configuration and local firewall.
If the VM can reach the gateway, check whether it can reach another workload on the same Segment.
If same-Segment traffic works but routed traffic fails, look at Tier-1 connectivity and distributed routing.
If internal routing works but external access fails, move upward to Tier-0, Edge Nodes, NAT, BGP and the physical network.
If routing looks correct but traffic still fails, check the Distributed Firewall and Gateway Firewall policies.
If everything looks correct inside NSX, do not forget DNS, upstream routing, physical switch configuration and external firewalls.
The best NSX administrators do not guess.
They follow the packet.
That mindset is also extremely useful for the VCF exam.
What the VCF Exam Is Really Looking For
The VCF Admin exam is not trying to turn every VMware administrator into a network architect.
But it does expect you to understand how networking works inside a modern private cloud platform.
You should understand what NSX does.
You should understand why Segments exist.
You should understand why Tier-1 and Tier-0 Gateways are separate.
You should understand when Edge Nodes are involved.
You should understand the difference between distributed and centralised services.
You should understand why distributed firewalling matters.
You should understand how VPCs support cloud-like networking in VCF 9.1.
Most importantly, you should understand traffic flow.
Because once you understand traffic flow, the terminology becomes easier.
NSX is not just another networking product.
It is the layer that allows VMware Cloud Foundation to behave like a true private cloud platform.
In Part 4, we will move into storage and vSAN, looking at how VMware Cloud Foundation delivers software-defined storage, why storage policies matter, how stretched clusters fit into the design, and what administrators should understand before sitting the VCF 9 exam.
