Reset Search
 

 

Article

Design Considerations when using EXOS MLAG to connect to EOS stp enabled switches

« Go Back

Information

 
TitleDesign Considerations when using EXOS MLAG to connect to EOS stp enabled switches
Objective
To Understand the design considerations and recommendations when using EXOS MLAG to connect to EOS switches running Spanning Tree
Environment
  • Summit Series switches
  • SecureStack C-Series
  • SecureStack B-Series
  • S-Series
  • MLAG
  • LACP
Procedure
The following considerations are recommended when configuring MLAG to connect to EOS switches ( also applies for any 3rd party STP switch ) via LACP

Spanning Tree

N.B. EXOS does not currently support spanning-tree (STP) on MLAG ports

- STP  should not be enabled on MLAG ports. 
- STP should not be enabled on the ports present on the remote node (EOS or 3rd party)  which connects to the MLAG ports. 
- You should ensure that the ISC port is never blocked by STP. 

MLAG’s ISC is not an MLAG port so STP can technically be configured on it. However, whatever the design/configuration one must ensure MLAG’s ISC is always forwarding, never blocked by STP/ELRP

In summary, ensure that we prevent STP BPDUs being forwarded to the MLAG ports, and ensure that ISC ports are never blocked by STP 

On the EOS (or 3rd party ) switch STP must be admin disabled on the LAGs AND the physical LACP  member ports towards MLAG.

The following article describes basic configuration of MLAG for EXOS to connect to EOS including the necessary spanning tree changes:
How to configure MLAG with EXOS core switches to EOS edge switch



ELRP for Loop Prevention

In order to resolve unintended L2 loops the loop prevention mechanism that should be employed in such circumstances is ELRP on EXOS (with port egress action). ELRP is only supported on EXOS and is not supported on EOS. EOS would continue to use spanning tree except for the uplink lag ports where it is disabled. 

For loop protection on MLAG ports one should configure ELRP on MLAG ports and ISC ports (master port in a sharing group) and the ISC must be excluded from ELRP disabling action

Introduced in EXOS 16.1, disabling the ELRP egress port, adds another layer of flexibility to the ELRP design.  In many ways this is an alternative approach to the exclude-list to prevent the ISC from being disabled.It is strongly recommended to use blocking on EGRESS.

This article explains ELRP in more detail:   How to Configure ELRP to Disable Ports

If enabled on all Vlans,  ELRP multicast has the possibility to be intensive on the CPU with the default “Interval” (time interval between successive ELRP PDUs = 1 second). If this is the case it is recommended to increase the interval.


Port Egressing on EOS (or 3rd party)

In order to prevent the unlikely instance where in transient conditions traffic could be sent on the lacp member ports instead of the logical lag port, causing ELRP packets to be leaked and potentially ELRP disabling a port, it is recommended to make sure that only the lag port egresses the vlans and not the lacp physical member ports on the EOS side. 

Where available use the "set spantree portenable disable" command to make sure that traffic cannot be forwarded independently of the lag.


Configure Static LACP MAC

Configure a static LACP-MAC so that there won’t be any LAG ID change during an MLAG peer reboot. 

When running LACP it is important that each MLAG peer be configured with the same static MAC for the LACP actor port. You can use an admin MAC for example:

configure mlag peer <peer-name> lacp-mac 02-00-01-01-01-01

This article explains in more detail:
LACP sharing ports connected to one MLAG peer flaps during the reboot of the other MLAG peer


Disable EDP

As for most environments where EXOS connects to non-EXOS switches we recommend that you disable EDP on the ports to non-EXOS switches
S-Series 00-E0-2B-00-00-01 moved to port syslog message


Other Recommendations
  • Enable Rate Limiters for broadcast and multicast on every EXOS port on the mlag peers to help protect services in the event of a loop. I believe this was also already done at other sites (wieland and vetter ) 
  • in order to avoid links coming up faster than they should one good safety measure is to configure LACP on EXOS as passive that means EXOS will try adding ports into an LACP LAG only after it has got LACP PDUs from the other end not before.

 
Additional notes
If using Alternate IP in the MLAG config then please bear in mind the following issue:

With alternate IP configured, MLAG ports may be disabled momentarily when other MLAG peer comes Up after reboot

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255