A systems administrator creates a bond0 interface in 802.3ad mode on a Linux file server to combine two 10 GbE adapters for higher throughput and link-level redundancy. After restarting networking, only one adapter is active and the bond reports that the second slave is "partner not aggregatable." What prerequisite for link aggregation was MOST likely missed during the implementation?
Enable spanning-tree port-fast (edge) on the switch interfaces that connect to the server.
Configure the two switch ports as an LACP link aggregation group before bringing the bond online.
Increase the MTU to 9000 bytes on both the server NICs and the switch ports.
Place each physical link in a different access VLAN to prevent loops while the bond forms.
When a server bond is placed in 802.3ad (dynamic LACP) mode, the switch ports at the other end of the cables must also be placed into the same LACP link aggregation group. Until the switch negotiates LACP, it treats each port as an individual interface, so the server cannot form a true aggregate and will mark one or both slaves as ineligible ("not aggregatable").
Configuring the switch for LACP solves the problem by allowing both ends to exchange LACPDU frames, agree on a common key, and activate all eligible links in the bundle.
Simply enabling STP edge/port-fast, putting the links on different VLANs, or turning on jumbo frames does nothing to satisfy the protocol requirements and therefore will not allow the bond to form or provide redundancy.
Changing the team to an active-standby (switch-independent) mode would restore connectivity, but it would sacrifice the simultaneous bandwidth that 802.3ad is meant to provide and therefore is not the best fix when link aggregation is the stated goal.