During a maintenance window, one physical uplink in an AHV Linux bond operating in active-backup mode fails while VMs are running. What should the administrator expect?
Select an answer to reveal the explanation.
Short Explanation
Think of active-backup like a single-lane road with a bypass lane: one path carries your traffic, and the other waits. If you see the active link drop, the bond switches to the standby path without needing LACP or manual intervention. The trap is treating active-backup like a load-balancing mode and expecting your traffic to split across the remaining links.
Full Explanation
Active-backup bonding keeps exactly one slave active for data traffic while the other slave is a standby path. When the active slave's physical link goes down, the bonding driver detects link-state loss and promotes the standby slave, so guest traffic continues over the remaining uplink. This mode is switch-independent: the peer switch does not need to participate in LACP, and the failed physical port does not need to be re-enabled for the surviving link to carry traffic. The load-balancing expectation describes balanced modes such as round-robin, XOR, or LACP-based modes, not active-backup. The blocked-traffic expectation confuses physical port recovery with failover behavior; the bond can carry traffic on the standby link while the failed port remains down. The Flow-disabled expectation misplaces the control plane: Flow affects network policy and microsegmentation, not the kernel bonding failover path. Exam caveat: always identify the bond mode first, because LACP modes add switch negotiation and balanced modes change traffic distribution. Operational check: confirm the configured bond mode and the active/slave link states from the cluster's networking view or host networking command output before declaring a failover event abnormal.