A police records bureau sees backup flows hashing unevenly across a port-channel even though all members are up. Which factor most directly governs how frames are distributed across members?
Select an answer to reveal the explanation.
Short Explanation
Port-channel members don’t round-robin like grocery checkout lanes by default—they hash. If every big backup flow looks the same to the hash, one link gets fat and the others stay skinny. Pick a load-balance method that sees enough header diversity for those flows.
Full Explanation
EtherChannel does not round-robin frames by default; it distributes them according to a configured load-balancing hash such as source-destination IP or Layer-4 ports. When a police records bureau sees backup flows hashing unevenly across members that are all up, the hash algorithm and the entropy of the flow five-tuples are what most directly govern member selection. If large backups share the same addresses and ports from the hash’s perspective, one link carries the bulk while others stay idle.
STP root priority on distribution switches influences which bridges and ports forward for loop prevention; it does not select which EtherChannel member carries a given frame once the port-channel is forwarding. The VTP domain name is unrelated to frame distribution across bundle members. UDLD normal versus aggressive mode affects unidirectional-link detection and errdisable behavior, not the load-balance hash.
Exam caveat: perfect balance is not guaranteed—hashing follows flow entropy; elephant flows can still pin to one member even with a good algorithm. Operational check: show etherchannel load-balance (or platform equivalent), review counters per member during backup windows, consider including L4 ports in the hash if supported and safe, and redesign backup source/destination diversity if a single flow dominates.