MCLAG DELL POWERSWITCH E3248P-ON

Hello,

Thank you for the detailed description of your environment. Based on the symptoms and configuration you have outlined, there are two primary areas of concern that are very likely contributing to the loop-like behavior you are experiencing.

The first and most likely root cause is the lack of LACP on the Fortigate uplink. You noted that you are not using any form of negotiation protocol between the Fortigate aggregate interface and the MCLAG port channel on CSWA and CSWB. In an MCLAG deployment, both peer switches present a single logical port channel to the connected device, which in your case is the Fortigate. For this to function correctly, LACP (IEEE 802.3ad) is required so that the Fortigate can recognize that Eth 1/47 on CSWA and Eth 1/47 on CSWB belong to the same logical LAG and can hash traffic accordingly across both members. LACP also allows the MCLAG peers to coordinate which switch is actively forwarding on which LAG member and properly handle failover scenarios. Without LACP, the Fortigate may treat each physical link independently, effectively sending duplicate frames, particularly broadcast, unknown unicast, and multicast (BUM) traffic, out of both links simultaneously. Both CSWA and CSWB then flood this traffic into the same VLAN domain, creating a de facto loop. This directly explains why removing one uplink resolves the issue, because you eliminate the duplicate path and the uncoordinated forwarding.

To address this, you should enable LACP on the Fortigate aggregate interface. Fortigate does support LACP on aggregate and LAG interfaces, so verify this under the interface configuration. On the CSWA and CSWB side, ensure the port channel is configured with LACP mode active, or at minimum passive with active on the Fortigate side. You should also confirm the port channel on the MCLAG pair is designated as an MCLAG interface within your MCLAG domain so both peers coordinate forwarding.

The second area of concern is your MCLAG peer link configuration. You mentioned your MCLAG peer link is configured as an L3 port channel, and this is a significant problem. The MCLAG or VLT peer link, also known as the Inter-Chassis Link or ICL, must be an L2 trunk port channel carrying all relevant VLANs. The ICL serves as the data path between the two MCLAG peers for orphan traffic, which is traffic from devices single-homed to only one peer, as well as BUM traffic flooding across the MCLAG domain. If the ICL is purely L3, no L2 frames can traverse between the peers. This means BUM traffic received on one peer cannot be forwarded to ports on the other peer, MAC address learning and synchronization across peers is disrupted, and orphan devices on one peer cannot reach VLAN gateways or devices connected to the other peer. This effectively creates a split L2 domain, which leads to inconsistent forwarding, MAC flapping, and the packet loss you are observing.

The L3 component you may be thinking of is the VLT keepalive link, which is a separate heartbeat mechanism used for peer health detection. This is typically carried over a dedicated L3 link, often the management interface or a separate routed interface, and is not the same as the ICL or peer link. You should reconfigure the MCLAG peer link as an L2 trunk port channel carrying all VLANs that participate in your MCLAG domain, and configure the VLT keepalive separately as an L3 path using the management network or a dedicated routed link.

Beyond these two primary issues, there are some additional checks and best practices worth mentioning. You should ensure STP is enabled and that both MCLAG peers share the same STP bridge priority so they appear as a single logical root to downstream devices, and consider using RSTP or MST. Verify that MAC addresses are being synchronized between MCLAG peers, which you can check using the command "show vlt mac-address-table" on OS10. All VLANs should be consistently configured on both CSWA, CSWB, and the ICL trunk, as mismatched VLANs will cause forwarding failures. On the downstream side, confirm that the port channels from the S4112T pair to CSWA and CSWB are configured as MCLAG interfaces on the E3248P-ON side and as VLT port channels on the S4112T side, with LACP active. You should also verify that both the E3248P-ON switches and S4112T switches are running the same recommended OS10 firmware version by checking the Dell Support site at https://www.dell.com/support for the latest validated release. If inter-VLAN routing is handled by the Fortigate, ensure peer-routing is enabled in the VLT domain so that both peers can forward routed return traffic correctly.

In summary, the two most likely root causes are the absence of LACP between the Fortigate and the MCLAG pair, which causes duplicate and uncoordinated forwarding resulting in a loop, and the use of an L3 peer link instead of an L2 trunk ICL, which prevents L2 BUM forwarding between peers and creates a split domain. Addressing both of these items should resolve the loop-like behavior and packet drops you are experiencing.