A network engineer bundles two physical ports on the FortiGate with two ports on the NOC's core switch into an aggregate interface, but after cabling both links the interface still shows only one member port as active and traffic never balances across both. What is the most likely cause?
Select an answer to reveal the explanation.
Short Explanation
An aggregate bundle only really forms when both ends agree to it — one side alone can't make it happen. If the switch's matching ports aren't running the same aggregation settings, the negotiation stalls and the FortiGate falls back to treating just one of your cables as active.
Full Explanation
Link aggregation, typically using LACP, requires both connected devices to independently configure their ports for aggregation with compatible settings before the bundle forms and traffic distributes across member links; if negotiation between the FortiGate and the switch hasn't completed, the aggregate interface won't bring up the additional member, and only the one link that already established a basic connection appears active. That negotiation mismatch is the likely explanation, since both cables are confirmed connected but the software layer of aggregation never completed on both sides. The claim that FortiGate aggregate interfaces only ever use one member link by design is incorrect and contradicts the entire purpose of aggregation, which is to combine multiple links for higher throughput and redundancy. Cable length isn't a plausible aggregation-forming issue unless the cable is wildly out of spec, and nothing suggests a physical Layer 1 fault, since one link did come up over presumably the same cabling. To resolve this, verify the corresponding switch ports are configured in a matching aggregation group with the same protocol and mode as the FortiGate side, and check both devices' aggregation status logs for a completed negotiation.