12.2 Network Visualizer, Physical Switch Monitoring, and Network Segmentation

12.2 Network Visualizer, Physical Switch Monitoring, and Network Segmentation

Sections 7.1 to 7.3 covered how AHV networking is built. This section covers how you see it, which is what Objective 2.2 asks for in its last two knowledge statements.

The Problem Network Visualizer Solves

When an application team reports a network problem, the administrator has to reason across a chain that spans two teams' equipment:

VM → vNIC → subnet/VLAN → virtual switch → bond → host uplink NIC → cable → physical switch port

Historically, the Nutanix administrator could see the left-hand side and the network team could see the right-hand side, and the join between them was a conversation. Network Visualizer renders the whole chain in one view.

What it shows

• Each VM and its virtual NICs.
• The subnet or VLAN each vNIC uses.
• The virtual switch carrying the traffic.
• The host uplinks and the bond they belong to.
• The physical switch and switch port each uplink connects to.

Typical uses: confirming that a host's two uplinks actually land on two different physical switches rather than both on one — a redundancy assumption that is wrong more often than anyone expects; tracing which switch port to examine when a VM has connectivity problems; and verifying a cabling change matches the design.

[!IMPORTANT] Network Visualizer is a Prism Central feature, and it is for visibility and troubleshooting, not configuration. You do not create subnets or virtual switches in it. If an exam option describes configuring networking through Network Visualizer, that option is wrong.

Monitoring Physical Switches

For the physical half of that picture to appear, the cluster must learn about the switches. Two protocols do the work, and knowing which does what is the examinable detail:

The workflow, corresponding to the blueprint reference "Creating a Network Switch":

1. Enable LLDP on the physical switches so uplink neighbours are discoverable.
2. Add the switch in Prism with its address and SNMP credentials — a community string for v2c, or a user with authentication and privacy for v3.
3. Prism then collects port statistics and correlates them with the host uplinks LLDP identified.

The payoff is diagnostic. When a VM has intermittent packet loss, you can see error and discard counters climbing on the specific switch port carrying its traffic, in the same console as the VM — instead of raising a ticket and waiting for someone else to look.

[!TIP] Remember the split: LLDP tells you what is connected where. SNMP tells you how that connection is behaving. Questions about discovering topology point to LLDP; questions about port counters and statistics point to SNMP.

Network Segmentation

Objective 2.2 also asks you to "identify types of networking," and the blueprint reference list includes Network Segmentation. It answers a different question from managed versus unmanaged networks (section 7.3) — not how guest VMs get addresses, but whether different kinds of cluster traffic share a network.

By default, several traffic types can share the same network:

• Management traffic — Prism, SSH, and API calls.
• Backplane traffic — CVM-to-CVM communication, including RF replication writes and rebuild traffic.
• Guest VM traffic — the workloads themselves.
• Optionally Volumes traffic, and disaster recovery replication to a remote site.

Network segmentation separates these onto distinct VLANs or distinct physical interfaces. Two motivations:

1. Security. Backplane traffic is the cluster's internal storage conversation. It should not be reachable from a general user VLAN.
2. Performance and predictability. A node rebuild after a drive failure generates significant replication traffic. Kept on its own segment, that burst cannot contend with production application traffic.

At NCA level, recognize what it is and why it is done. Designing a segmentation scheme is professional-level work.

Putting the Three Together