VLAN 240 Works Locally but Not Across Hosts
In a four-node AHV cluster, each host has two 25 GbE NICs in an LACP bond (bond0) connected to a pair of MLAG switches. VLAN 100 is the AHV management network, VLAN 200 carries production VM traffic, and VLAN 240 was just added for a new DMZ workload. The switch team confirms VLAN 240 is allowed on the MLAG trunk. A new VM on host A with IP 172.16.240.10/24 can ping another new VM on the same host, but cannot ping 172.16.240.11 on host B or the gateway 172.16.240.1. The VM’s virtual NIC is on network “DMZ-240,” created in Prism Element with VLAN ID 240. Existing VLAN 200 VMs work across all hosts. The physical switch ports are configured with MTU 9216; AHV uplinks are 9000; the guest VM uses MTU 1500.
1. What is the most likely configuration gap, and how would you verify it on AHV and the switch?
Read the worked answer
Same-host pings working while cross-host and gateway pings fail points to a Layer 2 path problem on the uplink, not a guest IP problem. The most likely gap is that VLAN 240 is not actually carried on both bond members or on both MLAG peers, even though the trunk is documented as allowing it. On each CVM, run ovs-vsctl show and confirm br0 has the VLAN 240 tag on the correct ports and that both uplinks are active in bond0. Check that the network was created as a VLAN-backed network with ID 240, not as a trunked network with a mismatched range. On the switches, verify show vlan brief, trunk allowed lists on every bond member, and MLAG consistency. Also confirm the gateway is on a switch or router that has VLAN 240 configured and an SVI. Since VLAN 200 works everywhere, compare its trunk configuration directly with VLAN 240.
2. Could the MTU settings explain the failure? Explain how you would test.
Read the worked answer
MTU mismatch normally affects large packets, not basic ARP and small ICMP. The VM is at 1500, AHV uplinks at 9000, and switch ports at 9216, so the VM path should be fine for 1500-byte traffic. If one host’s uplink were left at 1500 while another was 9000, large frames could drop, but small pings would usually still work. Test with ping -M do -s 1472 and then ping -M do -s 8972 from the VM to the gateway. If 1472 succeeds and large frames fail, investigate jumbo MTU end to end. Here, even small pings fail across hosts, so MTU is not the primary cause. Use the MTU test to rule it out, then focus on VLAN tagging, trunk allowed lists, and MLAG forwarding.
3. What would you change to keep the DMZ Layer 2 isolated while using the same bond?
Read the worked answer
Keep VLAN 240 as a separate VLAN-backed network on the existing bond rather than making the DMZ an access port or putting it in VLAN 200. Ensure the VLAN is allowed on every bond member and both MLAG peers, and that the upstream gateway has a matching SVI. If isolation beyond VLAN separation is required, add AHV Flow Network Security policies or a dedicated VLAN/VRF at the perimeter; VLANs alone are not a security boundary. Validate from a CVM that OVS has the tag on all hosts, then test same-host, cross-host, and gateway pings in that order. Document the allowed VLAN list so future switch changes do not silently remove VLAN 240 from one member.