Quick answer: east-west vs. north-south traffic
East-west traffic moves between workloads, services, or network segments inside a data center or cloud environment. North-south traffic crosses that environment’s boundary to reach users, the internet, another site, or another external network. In VMware NSX, east-west forwarding is often distributed across the host data path, while north-south connectivity normally reaches an NSX Edge before crossing a physical uplink. Those are useful defaults—not universal laws—because NAT, gateway firewalling, service insertion, bridging, load balancing, and topology choices can change the path.
The fastest way to troubleshoot either direction is to classify the flow before collecting data: same host or different hosts, same segment or different segments, internal destination or external destination, and distributed service or centralized service. That classification tells you whether to start at the workload vNIC, distributed firewall, distributed router, TEP/underlay path, service router, Edge uplink, or physical network.
| Question | East-west traffic | North-south traffic |
|---|---|---|
| Plain-language meaning | Communication inside the workload domain | Communication entering or leaving the workload domain |
| Typical example | Application VM to database VM | Internet user to web application, or workload to an external API |
| Common NSX path | Host switching, distributed firewall, distributed routing, and possibly GENEVE between host TEPs | Host data path, host-to-Edge overlay, service-router functions, Edge uplink, and physical network |
| First fault domains to compare | Same host vs. cross-host; same segment vs. routed segments | Host-to-Edge tunnel; gateway/service state; Edge uplink; upstream and return routing |
VMware NSX-T Data Center was renamed VMware NSX. This guide uses “NSX-T” once for search and product-line continuity, but uses the current VMware NSX name throughout. Features and command behavior can vary by release, including NSX in VMware Cloud Foundation 9.x.
Table of contents
- What east-west and north-south mean
- Four VMware NSX packet paths
- Distributed router, service router, and Edge roles
- East-west and north-south diagrams
- Distributed and gateway firewall policy
- Design decisions that change the path
- Troubleshooting workflow
- Symptom-to-fault-domain matrix
- Traceflow and packet capture
- Frequently asked questions
- Official Broadcom references
What east-west and north-south traffic mean
The terms describe a traffic relationship, not a protocol. A TCP session, UDP flow, ICMP test, storage connection, or API call can be east-west or north-south depending on the source, destination, and boundary used by the architecture team.
East-west traffic
East-west traffic is lateral communication inside the environment. Common examples include a web tier calling an application tier, an application tier querying a database, nodes in a cluster replicating data, or two internal services exchanging messages. The workloads can share one subnet or sit on different routed segments. They can also be on the same host or on different hosts.
North-south traffic
North-south traffic crosses the chosen workload-domain boundary. Examples include a user reaching a published application, a VM calling a public SaaS API, a branch office connecting to a private application, or an external backup target receiving data. “North” is not limited to the public internet: the external side can be a campus, WAN, cloud, partner network, or another routing domain.
The boundary must be explicit in diagrams and runbooks. A flow can be east-west from an application owner’s point of view but north-south relative to a tenant, VPC, security zone, or private-cloud region. Agree on the boundary before using the label as a troubleshooting conclusion.
Four common VMware NSX packet paths
| Source and destination | Expected path | What a failure isolates |
|---|---|---|
| Same segment, same host | Local host switching and applicable distributed-firewall processing; no physical TEP path in a standard distributed flow | Guest, vNIC, port, local switching, or policy |
| Same overlay segment, different hosts | Host switching and policy, then GENEVE from source host TEP to destination host TEP | TEP reachability, transport VLAN, uplink, underlay, MTU, or destination host |
| Different overlay segments, internal destination | Distributed routing can occur in the host data path; cross-host delivery can then use GENEVE | Gateway realization, route/policy state, distributed firewall, or overlay transport |
| External destination from an overlay segment | Distributed path toward an Edge TEP, then the appropriate service router, uplink, and physical network | Host-to-Edge overlay, centralized service, gateway route, uplink, upstream, or return path |
1. East-west on the same host
When two VMs are on the same ESXi host, NSX can switch or route the packet locally. Distributed firewall policy is evaluated at the workload interfaces as applicable, and distributed routing can move traffic between connected segments without sending it to the physical network. This is why a same-host test is valuable: if the flow works locally but fails after one VM moves to another host, the evidence points away from the application and toward the transport path.
2. East-west across hosts
For an overlay-backed segment spanning hosts, the source host TEP encapsulates the workload frame in GENEVE and the underlay forwards the outer packet to the destination host TEP. The destination removes the wrapper and delivers the original frame. For traffic between routed overlay segments, distributed routing can occur on the source host before transport to the destination host. See the companion VMware NSX GENEVE overlay guide for TEP, BFD, and MTU detail.
3. Routed east-west between segments
A Tier-0 or Tier-1 gateway is a logical construct, not a guarantee that every packet visits an Edge appliance. The distributed-router component can be realized in the transport-node data path, allowing internal inter-segment routing close to the source workload. Whether an Edge becomes part of the flow depends on the topology and services: a centralized firewall, NAT rule, service insertion chain, load balancer, bridge, or other stateful function can intentionally pull an internal flow through an Edge.
4. North-south through an NSX Edge
For a typical outbound flow, the source workload sends toward its NSX gateway. Distributed firewall and routing are applied according to policy and topology. The host sends overlay traffic to the Edge TEP selected for the path. The relevant service-router function on the Edge applies centralized services such as gateway firewalling or NAT when configured, and the packet exits a Tier-0 external interface toward the physical network. The return packet must find a valid route back through the correct NSX path and stateful service instance.
This explains two common diagnoses. If Traceflow drops before the Edge, inspect workload policy, routing, gateway connectivity, and the host-to-Edge overlay. If Traceflow reports delivery to the Tier-0 Edge uplink but the real application still fails, move the investigation to the Edge capture point, upstream route, physical firewall, destination, and return path.
Distributed router, service router, and Edge roles
- Distributed router (DR): Provides distributed logical routing in the NSX data path. It helps avoid unnecessary centralized forwarding for eligible traffic.
- Service router (SR): Runs on an NSX Edge when the gateway design needs centralized services or external connectivity. Edge CLI output identifies objects such as
DISTRIBUTED_ROUTER_TIER0andSERVICE_ROUTER_TIER0. - Tier-1 gateway: Commonly connects application or tenant segments and can be distributed-only or backed by an Edge cluster, depending on required services and design.
- Tier-0 gateway: Commonly provides the routing boundary to the physical network and exchanges routes through static routing, BGP, or OSPF where supported and configured.
- NSX Edge transport node: Supplies capacity for service-router functions, centralized network services, and overlay-to-physical connectivity. It also has TEP interfaces for overlay communication.
Use get logical-routers on the appropriate Edge to inventory realized DR and SR instances during troubleshooting. Do not change VRFs, interfaces, routing, or HA state until the intended object and rollback path are documented. For a fuller architecture treatment, see NSX Tier-0 and Tier-1 routing design and failover.
East-west and north-south traffic diagrams
These diagrams are simplified orientation views. A production diagram should add host placement, segment type, TEP subnets, transport VLANs, Tier-0/Tier-1 relationships, active Edge placement, external interfaces, route sources, NAT, firewall policy, and every stateful service that can affect symmetry.
East-west traffic
North-south traffic
How distributed and gateway firewall policy fit
The distributed firewall (DFW) protects workload interfaces and can evaluate both east-west and north-south flows. It is not limited to “internal traffic.” Gateway firewall policy runs at the gateway service boundary on an Edge and is useful for controls associated with centralized routing and ingress or egress. A flow can encounter one, both, or neither policy layer depending on configuration.
- Use DFW when policy should follow workload identity, application membership, or fine-grained lateral segmentation.
- Use gateway firewalling when policy belongs at a routed, tenant, or external-connectivity boundary.
- Document intentional overlap. Duplicating broad rules at both layers without clear ownership makes hit counts and incident triage harder to interpret.
- Prove the applied rule. Traceflow observations, rule statistics, logs, and a time-bounded test are stronger evidence than assuming the newest policy is the one in force.
For policy design, continue with VMware NSX microsegmentation design, policy, and automation.
Design decisions that change the traffic path
| Decision | Why it matters | Evidence to record |
|---|---|---|
| Overlay or VLAN-backed segment | Changes switching, gateway attachment, TEP use, and Traceflow capability | Transport zone, segment type, gateway/interface connection, VLAN, and release |
| Distributed-only or Edge-backed gateway | Determines where routing and centralized services can be realized | Gateway HA mode, Edge cluster, DR/SR realization, and locale service |
| NAT, gateway firewall, VPN, load balancing, or service insertion | Adds stateful or centralized processing and can require path symmetry | Rule/service owner, active node, before/after addresses, and return route |
| Tier-0/Tier-1 route advertisement | Controls which internal prefixes reach upstream networks and how return traffic finds NSX | Connected/static/dynamic routes, advertisements, BGP/OSPF neighbors, and defaults |
| TEP and underlay design | Determines cross-host and host-to-Edge reachability | TEP IPs, VLANs, uplinks, MTU, BFD state, routing, and ECMP/failover paths |
| Bridging or HCX extension | Can cross an overlay/VLAN boundary that Traceflow cannot represent end to end | Bridge endpoint, active Edge, VLAN path, HCX state, and real-packet capture points |
Capacity planning also differs. East-west performance depends on host data-path capacity, uplinks, TEP distribution, and underlay fabric when traffic crosses hosts. North-south performance adds Edge sizing, active/active or active/standby behavior, service overhead, external uplinks, and upstream devices. Either direction can encounter a bottleneck. Measure the actual path, packet size, flow count, and enabled services.
A repeatable VMware NSX traffic troubleshooting workflow
- Define the exact failed flow. Record source and destination IP, protocol, ports, time, expected result, and whether failure is one-way or bidirectional. Confirm the workload actually sends the traffic.
- Classify the path. Is it same host or cross-host, same segment or routed, east-west or north-south, overlay or VLAN-backed, and free of centralized services or dependent on them?
- Check endpoint basics. Verify vNIC connection, IP address, mask, default gateway, DNS where relevant, guest firewall, neighbor resolution, and the destination service. A network trace cannot compensate for a listener that is down.
- Compare a known-good path. Test same host versus different host, same segment versus different segment, and internal versus external. Change one dimension at a time so the result isolates a boundary.
- Run Traceflow inside NSX. Use Plan & Troubleshoot → Traffic Analysis → Traceflow in versions that present that path. Check the selected source, destination, protocol, and observations for DFW, routing, transport, and Edge handling.
- For cross-host east-west failure, validate the overlay. Check source and destination transport-node health, host TEP reachability, transport VLANs, uplinks, BFD state, and end-to-end MTU. Broadcom’s connectivity workflow specifically recommends comparing same-host behavior and testing TEP-to-TEP reachability with the required MTU.
- For north-south failure, validate host-to-Edge transport. Check host TEP to Edge TEP reachability and MTU, gateway connectivity, DR/SR realization, active Edge selection, route tables, NAT, and gateway-firewall state.
- Follow the packet beyond the Edge. If NSX delivers the synthetic path to the Tier-0 uplink, inspect the Edge uplink, physical switch/router/firewall, destination, and return route. Confirm that upstream routing advertises or otherwise knows the workload prefixes.
- Capture only after the fault domain is narrow. Capture the same five-tuple at adjacent points and compare request and response. Stop capture sessions promptly and document the nodes, interfaces, directions, filters, and timestamps.
- Correlate with change and HA history. Check DRS moves, Edge failover, route or firewall changes, transport-node updates, and underlay maintenance. Repeat tests across alternate ECMP and failover paths when the symptom is intermittent.
Symptom-to-fault-domain matrix
| Observed symptom | Most useful interpretation | Next evidence |
|---|---|---|
| Same host and same segment fail | The physical underlay is not yet implicated | Guest, vNIC, DVS port, DFW, local switching, destination listener |
| Same host works; cross-host fails | The host-to-host transport boundary is suspect | TEP reachability, BFD, VLAN, uplink, underlay route, MTU, packet capture |
| Same segment works; inter-segment fails | Switching works, but routing or routed-flow policy may not | Gateway connection, DR realization, route table, DFW, address/mask/gateway |
| East-west works; north-south fails before Edge uplink | External service path is suspect | Host-to-Edge TEP, Edge health, SR, NAT, gateway firewall, external route |
| Traceflow reaches Tier-0 uplink; application fails | NSX internal forwarding may be working, but real traffic or the external/return path is not proven | Edge uplink capture, upstream ACL/firewall, next-hop route, destination, return route |
| Small packets work; large packets fail | Possible MTU inconsistency | Don’t-Fragment testing across every TEP and physical path; capture for fragmentation/drop evidence |
| Only after Edge failover or on some flows | Possible path parity, state, asymmetry, or ECMP issue | Active node, BFD, route/neighbor state, uRPF, NAT/firewall state, both underlay paths |
| Bridge path lacks “delivered” in Traceflow | May be a documented telemetry limitation, not proof of packet loss | Real ICMP/application traffic and captures on both sides of the bridge |
Use Traceflow first, then a scoped packet capture
Broadcom recommends trying Traceflow before packet capture. Traceflow injects a specially crafted packet and shows observations across NSX components. It is excellent for identifying a distributed-firewall drop, selected Edge, or NSX-internal path. It does not prove that the guest sent a real packet, that the destination application responded, or that an external return path is correct.
- The source and destination guests do not see Traceflow’s crafted packet.
- Traceflow does not work with HCX extended networks.
- VLAN-backed Traceflow depends on release and In-band Network Telemetry configuration; overlay behavior should not be assumed for VLAN segments.
- Traceflow metadata does not cross an NSX Edge bridge into a VLAN network, so a missing “delivered” observation can be misleading in that topology.
- An external destination is visible only to the NSX boundary; validate the physical and return path separately.
For a real-packet investigation, Broadcom documents pktcap-uw at ESXi switchport and uplink capture points and the Edge start capture interface workflow. The following commands are read-only capture examples; substitute verified identifiers and use narrow filters to avoid collecting unrelated traffic.
# ESXi: inspect NSX-prepared switch instances
nsxdp-cli vswitch instance list
# ESXi: observe a workload switchport in both directions
pktcap-uw --switchport <switchport-id> --capture VnicTx,VnicRx -o - | tcpdump-uw -r - -nne
# NSX Edge: inventory logical routers, then enter the verified service-router VRF
get logical-routers
vrf <service-router-vrf>
get interfacesDo not use guessed credentials, disable TLS verification, or paste production secrets into a script. The older examples on this page used legacy Manager API paths and an embedded password with certificate verification disabled; those examples have been removed. For a deeper tool comparison, use the NSX Traceflow and port-mirroring troubleshooting guide.
East-west vs. north-south traffic FAQ
What kind of traffic is called north-south in a data center?
North-south traffic enters or leaves the data center or workload domain. Examples are an internet user reaching a web service, an internal VM calling an external API, or a branch connecting to an application through a WAN or VPN.
What are examples of east-west traffic?
Web-to-application calls, application-to-database sessions, storage replication, cluster heartbeats, and service-to-service API calls inside the chosen environment are common east-west flows.
Does east-west traffic always stay on one host?
No. It can remain local when both workloads are on one host, or cross the physical fabric as GENEVE traffic between host TEPs when the workloads are on different hosts. Centralized services can also make an internal flow traverse an Edge.
Does north-south traffic always use Tier-0 and an Edge?
In a typical NSX overlay design, external connectivity reaches an Edge and a Tier-0 external interface. The complete path can also include a Tier-1, NAT, gateway firewall, VPN, service insertion, or cloud-specific gateways. VLAN-backed and provider-managed designs may use different boundaries, so verify the realized topology.
What is a north-south proxy?
A north-south proxy is a generic ingress or egress proxy that intermediates traffic crossing the environment boundary—for example, a reverse proxy, application delivery controller, secure web gateway, or API gateway. It is a traffic role, not another name for an NSX Tier-0 or Tier-1 gateway.
Is NSX Traceflow the same as traceroute?
No. Traceflow injects a synthetic packet and reports observations inside NSX. Traceroute is generated by an endpoint and reports responsive Layer 3 hops. Use Traceflow to inspect the NSX path, then real application tests, traceroute, counters, and captures to prove behavior beyond that boundary.
Official Broadcom references
- Troubleshooting NSX Network Connectivity Issues
- Troubleshooting NSX Traceflow
- Current NSX Traffic Analysis and Traceflow UI path
- Troubleshooting Packet Captures for VMware NSX
- Traceflow behavior across an NSX Edge bridge
- Traceflow and In-band Network Telemetry for VLAN-backed segments
- North-south drops, asymmetric routing, and uRPF
- Overlay and VLAN segment gateway-connectivity differences
- Tier-0 and Tier-1 route behavior
- VMware NSX-T Data Center renamed VMware NSX
- VMware NSX Reference Design Guide 4.2
Validate commands, UI paths, limits, and feature behavior against the documentation for your exact VMware NSX and VMware Cloud Foundation release before making a production change.