This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
- Extreme Networks
- Community List
- Switching & Routing
- ExtremeSwitching (VSP/Fabric Engine)
- SLPP best practice for triangle or square or topol...
Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
SLPP best practice for triangle or square or topology
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
03-02-2022 10:16 AM
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
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
Solved! Go to Solution.
1 ACCEPTED SOLUTION
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
03-03-2022 03:13 AM
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.
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.
5 REPLIES 5
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
09-26-2024 03:00 AM
Hi Ludovico.
What's the best practice for implementing SLPP in a network design where there are 2 SMLT pairs connected together via NNI ports?
Reading through various articles and threads, I've only found references to single SMLT pair setups (like with only 2xVSP). My situation is that I have 2x7520 in one datacenter and another 2x7520 in a different datacenter - interconnected via 2x100G NNI links.
Routing is not done on the Fabric switches but is handled by a Fortigate firewall cluster which is also stretched over the 2 datacenters (one datacenter is the primary/active unit, the other is the secondary).
I presume that my setup is called a "square setup" - correct me if I'm wrong. Here I'm struggling to understand which switch (or switches) will be SLPP TX switch:
- is it one switch for each SMLT pair?
- is it one switch only?
- is it both switches of one SMLT pair (only one SMLT pair sending SLPP TX)?
Relating to the above, which switch/es will be considered SLPP primary? And which secondary?
Thanks in advance for your reply and best regards.
F.
