A four-member link aggregation group connecting a hospital's biomedical engineering lab to the core has been running normally, but staff now report noticeably slower transfers, and the technician finds that one of the four member interfaces has gone down. What is the most accurate description of the resulting condition?
Select an answer to reveal the explanation.
Short Explanation
Losing one leg out of four doesn't take the whole bundle down, it just shrinks how much pipe you have left. Traffic keeps flowing across the surviving members, there's just less total bandwidth to share now. That's the whole point of aggregation, graceful degradation instead of an outright outage.
Full Explanation
A link aggregation group is designed so that the loss of one member link reduces the group's total available bandwidth and may cause traffic to be redistributed across the remaining active members, but it does not normally bring the entire aggregate down, provided at least one member link remains up and the aggregation still meets its minimum configured requirements. This matches the described symptom precisely: continued connectivity with noticeably reduced throughput, which is the expected behavior of a degraded but still-functional LAG. The claim that the entire LAG stops forwarding until all four members are restored misunderstands the purpose of aggregation, which is specifically to tolerate a partial member failure rather than fail as a single unit. There is no concept of a LAG automatically failing over to a separate backup VLAN; VLANs and link aggregation are different mechanisms, and a VLAN is not a fallback bandwidth pool. A switch does not reboot itself in response to one interface going down within an aggregate; that would be a disproportionate and disruptive response to a routine partial link failure. A concrete check is confirming the LAG's active member count and total available bandwidth, then investigating the specific failed member's cabling, transceiver, or port status to restore full capacity.