Karl Erik Filip Modén
Guides 3 min read

NSX for Dummies, Part 5: Day-Two Operations Without the Panic

A calm operational model for NSX: what to monitor, how to troubleshoot a broken flow, and how to make changes without turning policy or routing into archaeology.

NSX feels complicated when a problem is described as “the network is broken.” It becomes manageable when you identify which plane is unhappy: management, control, data, or policy.

Four questions before changing anything

Can I change configuration?        -> NSX Manager and management plane
Can hosts learn what to do?        -> control-plane and transport health
Can packets move?                  -> data path, TEP connectivity, routing
Are packets being intentionally stopped? -> DFW or gateway policy

This distinction matters because an NSX Manager outage normally prevents configuration changes; it does not automatically stop already-programmed traffic. Do not restart components just because the UI is unavailable. First establish whether the workload traffic is actually affected.

Troubleshooting a failed connection

Use a path, not a hunch:

VM NIC -> segment -> distributed firewall -> T1 route -> T0 / edge -> upstream network

For each hop, ask one binary question:

  1. Does the source VM have the correct address, gateway, and DNS?
  2. Is the VM attached to the intended segment and included in the intended NSX group?
  3. Does a firewall rule allow the exact source, destination, service, and direction?
  4. Does the T1/T0 have a route for the destination and a return path?
  5. If the path crosses hosts, do the tunnel endpoints have healthy underlay reachability?
  6. If it exits NSX, is BGP or the physical return route correct?

The order is important. Troubleshooting BGP when a DFW rule drops the first packet is a very expensive way to learn that policy order matters.

Policy hygiene that stays readable

Rules become difficult when their intent is hidden. Keep a few habits:

  • Build groups around application roles and tags, rather than individual IP addresses.
  • Name policies by purpose and owner, such as payments-prod-east-west.
  • Keep emergency or temporary rules visibly marked and time-bound.
  • Use logging deliberately on denies and during rollouts; disable noisy, unhelpful logs.
  • Review rule hit counts and remove policy that no workload uses.

Upgrades and change windows

NSX upgrades touch managers, edges, and hosts in a defined sequence. Treat the current Broadcom upgrade guide as the source of truth for your installed version and run the pre-checks before the maintenance window, not while people are waiting for services to return.

Before a meaningful change, capture these facts: manager health, edge health, transport node state, active alarms, BGP neighbour state, current firewall policy, and a test flow for a known application. That gives you both a go/no-go decision and a way to tell if the change had an effect.

The operational takeaway

NSX is not a different kind of network so much as a network with better context: the system knows which VM, group, policy, segment, and route a packet belongs to. Use that context in the same order every time. Observe the path, identify the plane, make one change, and validate the flow. That rhythm is how NSX becomes ordinary infrastructure.

Official references