SLPP best practice for triangle or square or topology

[Teodor]

Hello to all,

I have a question if you can help me out with - it's about SLPP best practice for my topology.

We have right now a customer who has kind of brownfield deployment (long time Extreme customer since Enterasys acquisition) with 2 pcs of 7400 switches with SMLT and L2VSNs only (all layer 3 inter-Vlan routing is done on the firewalls) and also there is one LACP link with 4 10G ports between the VSP 7400 series cluster and the S6 bonded chassis (single control plane).

In the near future there will be VOSS switches connected to both of the 7400 series within the SPBm fabric (so NNI links between universal switches with the new VOSS core) but also there will be connected quite a few EXOS x450-G2 switches with LACP and FA enabled to the VOSS core. So a triangle configuration.
In a later stage this year I think we will get additional 2 pcs of VSP 7400 series (so we will end up in a square configuration with 4 pcs of VSP 7400 switches). At this moment we have around 15 VLANs but it might get to 20 or even more.

From what I know for SLPP implementation is the following
- SLPP enabled on all VLANs
- SLPP NOT enabled on the vIST ports or on the CORE SMLT/SLT ports for square/full mesh core design
- SLPP is to protect the CORE at all costs.
- SLPP enabled per switch globally, per port with RX settings and per VLAN...

My questions to you is:

- should I put the RX threshold above 50 SLPP packets? On VOSS docs it says "to configure the rx-threshold above 50 SLPP packets only on lightly loaded switches. If you configure the rx-threshold to a value greater than 50 on a heavily loaded switch and a loop occurs, the system can experience high CPU utilization.". I think that right now the switches are not heavy utilized but not all edge switches are yet connected to the new core switches, we're still waiting for some new universal switches to come from Extreme. Based on best practice and number of Vlans I was thinking with RX threshold with 100 on primary and 1000 on secondary
- should I enable or not the auto-recovery on the uplinks from the EXOS switches as it says that the primary goal of SLPP is to protect the Core at all costs?

- maybe because in the near future will move to a square type of topology I found a KB article that recommend to enable SLPP on the primary switch only. Should I go directly to this path and enable SLPP only on the primary?
https://extremeportal.force.com/ExtrArticleDetail?an=000083496
- should I enable SLPP also on the LACP link between the S6 and the 7400 cluster? There is not a lot of move-add-change in this link but just to be sure...

I hope I was clear enough. Let mw know if there is any additional information to add from my part.

Many thanks,

Teodor

[Teodor]

Thanks Ludovico,

as always - appreciate your help and sharing of knowledge within the Extreme VOSS community.

With best regards,

Teodor

[Ludovico_Steven]

Hi Teodore
Yes, you really need to enable loop protection on all VLANs for it to be effective, unless you have a network where 1 VLAN is present on all access port..
ELRP is a valid option for EXOS, but it is fully contained on each and every EXOS switch.
But in a Fabric environments it makes more sense to use SLPP and SLPP-Guard, as it is distributed on the network.
With SLPP you only need 1 or 2 central switches to emit the SLPP PDUs in the VLANs, and then all access ports will act on them with SLPP-Guard.
Enabling SLPP transmission is typically not a big drain on CPU resources; maybe if you have thousand of VLANs then it can make sense to either increase the default transmit timer to a valuer higher than 500ms, or to let different VSPs source the SLPP PDUs for different VLANs.
For your S6 switch, yes I would enable SLPP-packet-rx on the VSP distribution it is connected to; but in this case those VSPs have to be (also ?) generating the SLPP PDUs for the VLANs tagged to the S6 (else slpp-packet-rx won't trigger).
Best regards
Ludovico

[Teodor]

Hello Ludovico,

really appreciate your help and thorough explanations on this topic.

I wanted to grasp a little bit more on the SLPP topic based on your detailed explanations.
I was getting the information on the SLPP feature from the VOSS 8.4 & 8.5 User Guide and I felt that is not very clear to me and that is why I tried to get some help from the Extreme community.

I have more previous experience working with EXOS and there is this similar feature to SLPP that is called ELRP and there is not recommended to go with ELRP on all VLANs because of CPU overhead - https://extremeportal.force.com/ExtrArticleDetail?an=000063093&q=elrp and that is why i asked what's the best practice to go with SLPP on all VLANs or just a few of them and what's best for the timers for the Rx Thresholds.
It seems that for the Rx thresholds there is a minim of 5 and a maxim of 500 so my picture is not correct.

As for the VSPs we do have IP addresses on them only for in-band management, the other VLANs are for pure L2 transport and VSNs into the fabric, and all the inter-vlan is done on the firewalls (is one big building/campus).

All the switches connected to the VSP 7400 will be Extreme switches - VOSS and EXOS so i think that the SLPP Guard will do the trick and help a lot. Only the LACP link between the VSP 7400 and the S6 is not capable of working with SLPP Guard so I think is better to have SLPP enabled just to make sure we're covered, right ?

Regarding your last paragraph - yes, in the near future there will be added another additional vIST cluster with 2 additional VSP 7400 switches, so all NNI ports will be without slpp-packet-rx on these as you mentioned.

With best regards,

Teodor

[Ludovico_Steven · Accepted solution]

I think there may be some confusion with some older docs, which might be referring to older SMLT only designs.
There are two sides to SLPP.
First you need some switches to emit (TX) the SLPP PDUs on the VLANs you want to protect.
With FabricConnect, usually it is enough to only activate SLPP TX on a pair of VSPs; as a guide line, enable it on the same VSPs which have an IP address on the VLAN (or on the VSPs which hand off the VLAN to its default gateway, e.g. external Firewall).

Then you need to decide where you want to act (RX) on those SLPP PDUs; and there are two levels where you can do that.
The first and most important is on all your access ports (where end-stations are connected; i.e. your EXOS FA Proxy access ports, and also any non-SMLT UNI VSP access port) you enable SLPP-Guard. This is the most important protection, as if an SLPP PDU is seen coming back in on an access port, you can be sure something is wrong and you want to knock down that access port only and get an alert. Here you can choose whether to have the port disabled temporarily, or for the duration of a configurable timer.

The other protection you can use is on VSP SMLT UNI ports (only), and is the slpp-packet-rx config. This protection however is really a 2nd line of defense, in case you do not have SLPP-Guard on the access switch connected to those SMLT ports (like say a non-Extreme L2 switch) or a protection in case, for whatever reason, your access switch were to lose its LAG uplink configuration (EXOS has never had any issues in this area, but the older ERS/Baystack products, in the past, had some not very nice issues where the stack would occasionally disable its MLT uplink config..)
If the slpp-packet-rx detects SLPP PDUs coming back, it is going cut off an access switch uplink, which is a bit drastic; so you don't want both VSPs doing that for the same access switch, if possible; hence slpp-packet-rx has a configurable threshold value; typically the threshold values are set to 5 on one VSP and 50 on the other. But this protection works well if indeed the access switch did lose its LAG uplink config, as one VSP (the one with threshold 5) would cut one SMLT uplink, and the other VSP (with threshold 50) would then not have to do the same, as the looping condition would now be resolved. If instead the loop is on some access ports of the access switch (and we have no SLPP-Guard to fix that), cutting one uplink to that switch will not resolve the loop, and then both VSPs will end up severing the SMLT uplinks to the access switch anyway. Which is still arguably the best action possible: if we cannot stop the loop on the access switch (because there is no SLPP-Guard there), then just cut off the entire access switch.
Using auto-recovery with slpp-packet-rx is usually not a good idea. If you are shutting off switch uplinks it is probably better to get an administrator to see what is going on, rather than have those uplinks flap all the time.
If you are interested in using this slpp-packet-rx protection then there is another thing to keep in mind. slpp-packet-rx will act only on SLPP PDUs emitted by the same VSP where slpp-packet-rx is configured, or the vIST peer of that VSP. So in this case SLPP (TX) would need to be enabled on all VSPs configured with slpp-packet-rx (on all the VLANs that are configured on these VSPs).

Whereas SLPP-Guard will act on any SLPP PDU.

Another distinction between slpp-packet-rx and SLPP-Guard is that the former can tell the difference between a loop on the same VLAN (SLPP PDU is received on same VLAN it was emitted on) and two VLANs getting collapsed together (SLPP PDU is received on a different VLAN from the one it was sent on). slpp-packet-rx only shuts down the port in the former case, and only generates a warning in the latter (technically you don't have a loop here, just 2 different access VLANs are being bridged together).
Whereas SLPP-Guard makes no such distinction and will always take out the port.

Another thing to remember is that you do not activate SLPP-Guard nor slpp-packet-rx on Fabric NNI ports (even if you did they would not be effective).
Looking at one of your diagrams I see 2 separate VSP7400 SMLT pairs, connected together in a square topology; but typically with Fabric the side links will be NNI ports (not SMLT ports) so there certainly is no slpp-packet-rx config on those ports.