A Nutanix AHV cluster is configured with a bridge using jumbo frames and an MTU of 9000. The physical switch ports connecting the cluster remain at the default MTU of 1500. Large storage I/O from VMs attached to the bridge intermittently fails. Which requirement explains this behavior?
Select an answer to reveal the explanation.
Short Explanation
Think of MTU like a hallway: if one door is narrower than the furniture, the packet gets stuck. You can set jumbo frames on AHV, but if the physical switch still expects 1500 bytes, the big frames get dropped. That mismatch is the trap, so don't blame Flow or CVM magic.
Full Explanation
Jumbo frames work only when every forwarding device on the path supports the same maximum frame size. AHV can set a bridge or bond MTU above 1500, but that setting changes only the virtual switching layer. If physical switch ports, router interfaces, or intermediate NICs remain at 1500, packets larger than 1500 bytes are dropped or fragmented inconsistently, causing storage or application failures. The correct requirement is therefore an end-to-end MTU match across the VM NIC, AHV networking, and physical network. Flow is a software-defined networking security and segmentation feature; disabling Flow does not enlarge the physical frame limit or repair an MTU mismatch. Storage traffic through CVM and Stargate still traverses the same physical fabric, so it cannot bypass the physical network MTU. Prism Central and VM NIC settings do not replace physical switch MTU configuration; jumbo frames are not enabled only inside the guest. Exam caveat: Nutanix supports jumbo frames on supported AHV networks, but exam questions expect the administrator to verify the full path, not just the AHV bridge. Operational check: compare the MTU configured on the AHV bridge or bond with the physical switch port, then test connectivity using a large ICMP payload or packet capture to confirm frames larger than 1500 bytes pass.