I85PREP
⌘ K
Nutanix NCA study materials
Nutanix NCA study resources

Adding a Tagged VLAN to a Production AHV Cluster

Nutanix NCA · Put your knowledge to work in context.

All case studies

Adding a Tagged VLAN to a Production AHV Cluster

A four-node AHV cluster connects each host with two 10 GbE interfaces in an active-backup bond. The top-of-rack ports are configured as access ports in VLAN 10, and every CVM and VM sits on the default VLAN-backed network. The team must onboard an appliance that has to live on VLAN 40 (10.40.0.0/24) and must not be reachable from VLAN 10. The switch team insists the ports are 'already trunked and it just works'. A consultant proposes converting the bond to LACP active-active during the same change to double throughput, and also suggests moving CVM traffic onto the new VLAN 40 network 'to keep things tidy'. The cluster carries 24x7 clinical workloads and change windows are two hours long.

1. What must be true on the host and switch sides for the VLAN 40 network to carry traffic, and how do you prove it without risking all four hosts at once?

Read the worked answer

How AHV does it: the VLAN ID you set on an AHV network is an 802.1q tag applied to the guest's virtual NIC. The physical switch port therefore has to carry that tag - which is a trunk configuration, not an access port.

Required state:

  • Switch ports toward the hosts must trunk VLAN 40 (tagged) and VLAN 10 in whatever form matches AHV - native/untagged VLAN 10 is fine only if the AHV network for VLAN 10 is untagged; if AHV tags VLAN 10, the switch must tag it too.
  • The bond members on the host must both be in the same L2 domain and both allowed on the trunk, or you get asymmetric flooding and intermittent loss.

Proof before the window:

  1. On one host, create the VLAN 40 network in Prism Element and confirm the CVM sees it (interface/OVS inspection from the CVM).
  2. Attach a throwaway test VM to that network, set 10.40.0.x, ping the VLAN 40 gateway and a permitted peer.
  3. Rule out the classic silent failure: a native-VLAN mismatch. If the ping fails but the switch shows the VLAN up, suspect tagging, not routing.

Rollout: host by host, validating after each, so a bad trunk affects one host's new network - not the clinical workloads on the others. Do not accept 'it just works' as evidence.

2. Evaluate the two consultant suggestions: converting to LACP during this change, and moving CVM traffic onto VLAN 40.

Read the worked answer

LACP in the same window - reject.

  • It requires a matching LAG on the switch; the host bond mode, the switch LAG and the hashing must all be changed together, and each host transition briefly interrupts its networking.
  • Even when it works, 'double throughput' is a hashing-dependent assumption, not a guarantee - a single TCP flow does not get 2x.
  • Onboarding one appliance is not a bandwidth problem. Bundling a bond re-architecture into a two-hour clinical change window multiplies blast radius for no benefit to the requirement. Schedule it separately, per host, with the switch team live.

CVM on VLAN 40 - reject.

  • The CVM network carries Prism Element access, inter-CVM and replication traffic, Prism Central registration, NCC, AD/LDAP, and DNS/NTP. Re-IPing it is a cluster-level operation with a real chance of losing management access, and at minimum breaks replication and PC connectivity mid-change.
  • Placing CVMs on an isolated guest segment designed to be unreachable from corporate VLAN 10 directly contradicts how the cluster is administered.
  • CVM traffic also should not share a broadcast domain with untrusted guest appliances.

Scope control: the requirement is one appliance on one VLAN. Change only what that needs.

3. The appliance team asks whether VLAN 40 now gives them the isolation the security policy requires. How do you answer, and what else is needed?

Read the worked answer

VLAN 40 is a Layer 2 segmentation construct, not an enforced security boundary.

  • It separates broadcast domains. It does not stop traffic that is routed between VLANs, and it does not stop anyone with access to a host NIC or the switch from bridging the two.
  • If the L3 device or firewall currently routes VLAN 10 <-> VLAN 40, the appliance is reachable from VLAN 10 no matter how you tag the AHV network.
  • Two VMs on the same AHV host on different VLANs are separated by the virtual switch tagging, but that is datapath configuration, not an audited control.

What the answer must include:

  1. Confirm with the network team whether inter-VLAN routing exists and either remove it or apply explicit deny/allow ACLs on the L3 device or firewall.
  2. Use the platform's own security controls for VM-to-VM rules (security/flow policies in Prism Central) if east-west restriction is required - ACLs on the switch do not see intra-host traffic.
  3. Record the control in the design: which device enforces the rule, what the rule is, and how it is tested (e.g. an attempted connection from a VLAN 10 VM that must time out).
  4. Do not let 'we put it on a different VLAN' be written down as 'isolated' without the enforcement point named.