An administrator configures an AHV host bond in active-backup mode to provide link redundancy. If the active NIC loses its physical link, what behavior should be expected?
Select an answer to reveal the explanation.
Short Explanation
Think of active-backup like a one-lane road with a spare lane ready: only one NIC carries traffic, and if it fails, the bond hops to the backup. You don’t need the switch to bundle ports or run LACP—that’s the trap. Load balancing needs more than simple redundancy.
Full Explanation
In active-backup bonding, the bond presents a single logical interface while one physical slave is active and the remaining slaves are standby. When the active slave’s link fails, the bond selects a standby slave and continues sending traffic through the new active slave, preserving the guest network path and avoiding manual intervention. Because only one slave transmits at a time, the switch does not need an aggregate group or LACP; it sees a single MAC address moving to another port. The misconception that traffic is distributed across both NICs confuses active-backup with load-balancing modes such as LACP or hash-based modes, which require different switch behavior and distribute flows rather than provide pure standby redundancy. The idea that the failed NIC remains active describes link retry or a broken failover assumption; active-backup is designed to move traffic away from the failed slave. The notion of choosing a NIC by source and destination IP hash describes flow-based balancing, not active-backup, where the active slave is selected for the bond rather than per-flow hashing. Exam caveat: active-backup protects against link or NIC failure, not against a misconfigured switch port, VLAN mismatch, or total loss of the shared network path. Operational check: verify the bond status shows one active slave and standby slaves, then simulate or observe a link-down event and confirm the bond switches to a standby slave while the VM network remains reachable.