Module 6: Networking and Microsegmentation

The Promise

By the end of this module you will:

1. Configure AHV networking from vSphere muscle memory. AHV uses different vocabulary (Open vSwitch, bridges, bonds, virtual networks) for largely equivalent concepts. By the end of this module the mapping is automatic.
2. Pass roughly half of NCP-NS (Nutanix Certified Professional, Network and Security). The 7.5 version opened for public scheduling on April 4, 2026. Roughly half of its blueprint is the material in this module.
3. Build a microsegmentation policy using categories and explain why category-driven policy is operationally cleaner than the IP-based ACL world.
4. Defend Flow against an NSX-T-loyal architect. Flow Network Security is competitive with NSX-T's distributed firewall for VM microsegmentation, often simpler. Flow Virtual Networking is younger than NSX-T and behind it for advanced routing. Draw the comparison without flinching.
5. Make the network economics case. Flow Network Security is licensed via NCI Ultimate or the Security Add-On for NCI Pro; FVN is bundled at the platform level. NSX-T is a separate VMware product with its own licensing.
6. Diagnose AHV networking issues from the CLI. OVS bridges, bonds, virtual networks, Flow policy state.

The network is the dimension where customers diverge most. Some come from a Cisco-only world and don't trust software-defined networking. Some come from heavy NSX-T deployments and want to know what they lose. Some treat the network as commodity. Read the customer; pick the framing.

Foundation: What You Already Know

Picture a vSphere host. Physical NICs (vmnics) are aggregated into a vSwitch (vSS for standard, vDS for distributed). Port groups define VLAN tagging and policy. Each VM connects to a port group. NIC teaming is configured at the vSwitch level (active-active, active-standby, route-based-on-IP-hash, etc.). vCenter centralizes this on vDS: one configuration deployed across many hosts.

You also know the limits. vSS is per-host configuration. vDS used to require Enterprise Plus (post-Broadcom: bundled into Foundation/Cloud Foundation tiers). NIC teaming policies are well-defined but bonded across many configurations.

Now switch underneath. AHV networking uses Open vSwitch (OVS): an open-source production-grade software switch that runs in the Linux kernel of every AHV host. The same OVS used in Red Hat OpenStack, OVN, and many Linux-based virtualization platforms.

Core Content

Open vSwitch: The Substrate

OVS is the software switch underneath every AHV host. It runs in the Linux kernel. Each AHV host has at least two bridges by default:

• br0 (the data bridge). Carries user VM traffic. Connected to the host's physical NICs (typically via a bond). This is where your VMs' NICs land.
• br0.local (the local management bridge). Used for CVM-to-hypervisor traffic and internal management. Not exposed to user VMs.

Inside br0, OVS handles VLAN tagging, MAC learning, broadcast/multicast, and (for Flow Network Security) flow rules that implement the firewall.

Bonds: NIC Teaming for AHV

A bond in AHV is a Linux bonding interface (or, more recently, OVS bond) that aggregates multiple physical NICs into a single logical link. Bonds provide redundancy and (for some modes) load balancing.

The default for new clusters is typically active-backup. Most production deployments upgrade to balance-slb (no switch-side change needed). LACP / balance-tcp is supported but Nutanix's official recommendation has historically leaned away from LACP because misconfigured upstream switches can disable cluster connectivity in ways that are hard to recover from in the field. If you choose LACP, document the switch-side configuration carefully and validate before go-live.

Virtual Networks (the Port Group Equivalent)

A Virtual Network in Nutanix vocabulary is the equivalent of a vSphere port group. It carries:

• VLAN tag (or none, for untagged traffic).
• Optional IPAM: the cluster can act as DHCP for VMs on this network.
• Connection to a bridge (typically br0).

When you create a VM and attach it to a Virtual Network, the VM's vNIC lands on br0 with the configured VLAN. Inter-VM traffic on the same VLAN flows at OVS speed (in-host, kernel-level). Inter-VLAN traffic exits via the bond uplink to the physical network.

Naming convention: virtual networks in Prism are commonly named vlan.<id> (e.g., vlan.100), though arbitrary names are allowed.

IPAM: When Nutanix Acts as Your DHCP

For each Virtual Network, you can enable IPAM. When IPAM is enabled, AHV provides DHCP services for VMs on that network. You configure the subnet, default gateway, DNS servers, and DHCP pool range.

This is useful for self-contained tenant networks (test/dev, isolated environments, VDI floating pools) where you don't want to rely on external DHCP. For production environments connected to the corporate network, you typically disable IPAM and let the physical network's DHCP serve VMs.

Diagram: AHV Networking Stack

The Cycle, Frame Two: AHV Networking as Linux Plus OVS

For network engineers from the Linux world, AHV networking is just Linux networking with Open vSwitch as the switch. The CLI tools you would use on any Linux host (ip, ovs-vsctl, ovs-ofctl, ip link) work on the AHV hypervisor.

• Standard troubleshooting tools work. tcpdump on br0 shows VM traffic. ovs-vsctl show lists bridges and ports. ovs-appctl queries OVS internals.
• Standard automation works. Ansible, Terraform, custom scripts can manipulate OVS configuration where the Nutanix abstraction is insufficient.
• The architecture is auditable. There is no proprietary kernel module hiding what the network does. OVS is open source and well-understood.

The Cycle, Frame Three: Networking as Policy, Not Topology

In traditional networking, you secure VMs by VLAN segmentation, ACLs on switch ports, and firewall rules at gateways. Topology drives policy: a VM is in vlan.100, and policy is whatever applies to vlan.100. Move the VM, the policy changes.

Flow Network Security inverts this. Policy is defined by categories (Module 4) attached to VMs, not by topology. A VM tagged Tier: Web follows the Web-tier policy regardless of which VLAN it lives in. Move the VM to a different cluster, the policy follows.

The Cycle, Frame Four: What Comes Free vs What Costs

VMware networking scales up by license tier:

• vSS (standard switch): included.
• vDS (distributed switch): historically Enterprise Plus, now bundled in Foundation tiers.
• NSX-T microsegmentation: separate NSX licensing, per-CPU or per-workload.
• NSX-T routing/edge services: even higher NSX tiers.

Nutanix:

• AHV networking with OVS, virtual networks, IPAM: included with NCI baseline.
• Flow Network Security (microsegmentation): licensed via NCI Ultimate, or via the optional Security Add-On for NCI Pro (per usable TiB; bundles Data-at-Rest Encryption with Flow microsegmentation). It is not an NCM tier feature; do not confuse the NCM management tiers with Flow's NCI-side licensing.
• Flow Virtual Networking (VPC overlay, advanced routing): bundled at the platform level with PC / AOS; specific feature gating depends on PC and AOS version.

The customer paying separately for NSX-T microsegmentation will find Flow Network Security at NCI Ultimate (or as the Security Add-On) a meaningful licensing change. Always run the actual numbers; the answer depends on tier, workload size, and whether the Security Add-On's encryption capabilities also displace another vendor's tooling.

Flow Network Security: Microsegmentation Done Differently

Flow Network Security is Nutanix's distributed firewall and microsegmentation product. It runs across all AHV hosts in the cluster (Prism Central drives policy distribution; OVS enforces rules at each host).

• Define categories on VMs (e.g., Tier: Web, Tier: App, Tier: DB, Environment: Prod).
• Define rules that apply to category groups: "VMs with Tier: Web may receive traffic from anywhere on port 443; may send traffic to VMs with Tier: App on port 8080; may not communicate with Tier: DB directly."
• Rules are stateful (return traffic is automatically permitted for established connections).
• Enforcement is distributed: each host enforces rules for VMs running on that host. There is no central firewall bottleneck.
• Default policy is configurable: explicit-allow (whitelist, the secure default) or explicit-deny.

Web tier (VMs with Tier: Web):
  Inbound from any: 443/tcp, 80/tcp (allow)
  Outbound to App tier: 8080/tcp (allow)
  Default: deny

App tier (VMs with Tier: App):
  Inbound from Web tier: 8080/tcp (allow)
  Outbound to DB tier: 5432/tcp (allow)
  Default: deny

DB tier (VMs with Tier: DB):
  Inbound from App tier: 5432/tcp (allow)
  Outbound: deny
  Default: deny

The result: a three-tier application where each tier can only reach the next; lateral movement (a compromised Web VM directly reaching DB) is blocked at the OVS flow-rule level. No physical network changes. No VLAN reorganization. Categories assigned in Prism Central drive everything.

Diagram: Flow Microsegmentation

Flow Virtual Networking (FVN): The VPC Overlay

Flow Virtual Networking is Nutanix's overlay network product. It provides VPC-style virtual networks: isolated, multi-subnet networks with their own routing, NAT, and policy, decoupled from the underlying physical network topology.

• Virtual Private Clouds (VPCs). Create isolated network environments with their own IP space.
• Routing between VPCs. Internal routing rules, similar to AWS VPC peering.
• NAT. Inbound and outbound NAT for VPC-to-physical traffic.
• External connectivity. Connect VPCs to the physical network via gateway services.
• BGP integration. Some configurations support BGP with the upstream physical network.
• Service insertion. Insert third-party network services (firewalls, load balancers) into VPC traffic flow.

FVN is meaningfully newer than Flow Network Security (introduced in PC 2022+, with substantial maturity gains in 2024-2025). For customers with simple network requirements (flat or VLAN-segmented), FVN is overkill. For customers who want true overlay networking, multi-tenant VPCs, or hybrid-cloud network parity, FVN is the right tool.

Diagram: Flow Virtual Networking Topology

Service Insertion: Third-Party Security Integration

For customers who run third-party network security (Palo Alto VM-Series, Check Point, Fortinet, etc.) and want to insert those services into Flow's traffic flow, FVN supports service insertion:

1. Deploy the third-party security VM (e.g., a Palo Alto VM-Series instance) on the cluster.
2. Configure FVN to redirect specific traffic flows through the security VM.
3. The security VM inspects, applies its own policy, and forwards (or drops).

This lets customers leverage their existing security tooling without giving up Flow Network Security for VM-level microsegmentation. The two layers complement: Flow does VM-tier microsegmentation; the third-party service does deep packet inspection, IDS/IPS, threat prevention.

The honest framing: Flow Network Security is competitive for microsegmentation. FVN provides VPC-style overlays. For deep packet inspection and advanced threat prevention, you typically still want a specialized security product. Service insertion lets you have both.

What Networking Genuinely Lacks Compared to NSX-T

1. Advanced routing patterns. NSX-T has years of depth in distributed routing, BGP integration, OSPF, dynamic routing protocols. FVN handles common cases well but does not match NSX-T's full routing feature set.
2. Edge services maturity. NSX-T's edge services (load balancing, VPN, gateway firewall, IDS/IPS) are mature and well-integrated. Nutanix relies more on service insertion for advanced services.
3. Third-party ecosystem depth. NSX-T has had more time to develop integrations with third-party security and networking products.
4. Geographic / multi-cluster networking. NSX-T Federation provides multi-site network policy with strong consistency. FVN is increasingly capable here but not yet at NSX-T Federation parity.
5. Some performance-tuning depth at the network plane for very large, very dense deployments.

For typical mid-market and enterprise general-purpose deployments, none of these are deal-breakers. For customers running deep NSX-T deployments or with hyperscale requirements, the gaps are real.

What Networking Has That Differentiates Nutanix

1. Open vSwitch as the substrate. Open standard, auditable, well-understood.
2. Category-driven policy. Operationally cleaner than IP-based ACLs for typical enterprise use.
3. Bundle-friendly licensing for microsegmentation. Flow Network Security ships with NCI Ultimate or the Security Add-On for NCI Pro; NSX-T microsegmentation is separately licensed.
4. Single management plane. Network configuration, microsegmentation, and policy all live in Prism Central alongside compute and storage.
5. Native integration with categories from compute and storage. A single category like Environment: Production drives backup policy, microsegmentation, quotas, and reporting.

Lab Exercise: Build a Microsegmentation Policy

1. Inventory existing networking. From a CVM:

   manage_ovs show_uplinks
   manage_ovs show_bridges
   manage_ovs show_bonds

2. Create three Virtual Networks in Prism Element:
   • vlan.100 for Web tier (VLAN 100, IPAM disabled)
   • vlan.200 for App tier (VLAN 200, IPAM enabled, 10.20.30.0/24)
   • vlan.300 for DB tier (VLAN 300, IPAM enabled, 10.20.40.0/24)
3. Deploy three VMs (one per tier). Use any small Linux image. Boot them.
4. Define categories in Prism Central: Key Tier, Values Web, App, DB.
5. Apply categories to VMs from Prism Central VM list.
6. Create a Flow Network Security policy in Prism Central → Policies → Security Policies → Create. Application Type: 3-tier (Web/App/DB). Define rules per the data path; default deny.
7. Test the policy. Web → App on 8080 should succeed; Web → DB direct should fail; App → DB on 5432 should succeed.
8. Inspect OVS flow rules on an AHV host: ovs-ofctl dump-flows br0. You should see flow entries that implement the firewall rules.
9. Optional: enable monitor mode first to capture traffic without enforcing, then enable enforcement. This is the recommended customer pattern.

Practice Questions

Twelve questions. Six knowledge MCQ, four scenario MCQ, two NCX-style design questions.

What You Now Have

You can translate vSphere networking vocabulary to AHV/OVS terminology fluently. vDS port group becomes Virtual Network, vSwitch becomes OVS bridge, NIC teaming becomes bond mode.

You know the OVS substrate: br0 for VM data traffic, br0.local for management. Bonds with active-backup, balance-slb, balance-tcp, and LACP. VLAN configuration on virtual networks. IPAM as an optional per-virtual-network DHCP service.

You know Flow Network Security: distributed firewall, category-driven policy, stateful rules, OVS-level enforcement, and the operational pattern of "monitor first, then enforce" for production. You can build a three-tier microsegmentation policy in 90 seconds and demo it.

You know Flow Virtual Networking: VPC-style overlays, internal routing, NAT, BGP, service insertion. You know FVN is younger than NSX-T but increasingly capable.

You have the honest comparison to NSX-T: Flow Network Security is competitive for microsegmentation; FVN is behind on advanced routing, edge services, L2VPN, and third-party ecosystem. NSX-T-on-Nutanix-on-ESXi is the durable answer for customers with established NSX-T investment.

You know the licensing reality: Flow Network Security at NCI Ultimate (or via the Security Add-On for NCI Pro) is included; NSX-T microsegmentation is separately licensed. The economics matter and you can walk through them.

You are now ready for data protection and DR. Module 7 covers Protection Domains, Async/NearSync/Metro replication, Recovery Plans (Nutanix Disaster Recovery, formerly Leap), and the durable DR story that frequently decides enterprise deals.