On VOSS/FabricEngine SLPP should be configured on every VLAN at the point where it leaves the fabric and meets a non-fabric loop prevention strategy. This will prevent any loops from impacting the fabric by closing down ports where a loop is detected.
The below assumes you already have SLPP configured on your upstream switches.
If the switch(es) are going to be used to “break-out” an i-sid to a VLAN (layer 2) there exists the risk of a loop causing an issue to the fabric. Within the “fabric” there is no need for loop prevention/detection, the fabric ensures a loop free topology and traffic flow, however once an i-sid is delivered out to clients via a VLAN at the edge, there exists a risk that this layer 2 could loop to another port on the same or a different switch.
A loop could occur on ports at the Distribution Switch Layer, or a loop could occur on ports at the Edge Switch Layer, basically anywhere a VLAN (layer 2) is presented. A loop at the edge switch layer would typically be user or administrator error, incorrectly patching a cable back to the switch or via some intermediate switch or device (e.g. a phone), while loops at the Distribution Switch layer could be caused by incorrect configuration of downstream edge switches using MLAG/SMLT (or redundant phy) for example; or a downstream edge switches that use redundant phy or MLAG going into a weird state where they become a loop (e.g. stack split brain).
SLPP Guard Configuration (XOS/SwitchEngine)
All XOS/SwitchEngine switch edge ports (i.e. those facing end user devices) MUST have SLPP Guard enabled on them, IF they are uplinked into VOSS (FabricEngine) distribution switches by use of MLAG.
SLPP or SLPP Guard must not be enabled on the Uplink or Interlink ports of the switch, i.e. if an SLPP packet would normally taverse this in normal operation, you must not enable SLPP or SLPP Guard on these Uplink or Interlink.
SLPP Guard MUST be enabled on all end user facing device ports around campus. However within the Data Centre it is assumed this is a managed environment therefore SLPP Guard is only enabled on ports in very specific situations (e.g. if there is another MLAG to another layer of edge switches below, e.g. Dell ECS FE Networking.)
There are two levels of protection configured and they are described below:
- Distribution to Edge – The VOSS FabricEngine (Distribution) switches are configured to use SLPP which periodically transmits SLPP packets (SLPP PDU) from all the A side and B side distribution switches, in normal operation an A side and B side downlink port (to the XOS/SwitchEngine Edge Switches) are configured with different RX thresholds, so that in the event of a loop forming on the MLAG between the distribution and edge, if for example the MLAG fails for some reason and a loop forms, the SLPP PDUs will make their way round to the B side port which then gets administratively disabled and remains so until a System Administrator resolves the issue.
- Edge – The above protection is fine for the Distribution to Edge loop prevention, but another place a loop can form is between the switch edge ports of the same switch or between two edge switches. Within the VOSS/FabricEngine based network environment, such a loop causes major network instability as the looped traffic is not restricted into just “Distribution Area” and can instead flow everywhere and anywhere across the network that the I-SID VLAN is present. In this case SLPP Guard is enabled on the edge switch, and in the event of a any SLPP PDU packet arriving on a port, that port is administratively disabled and remains so until a System Administrator resolves the issue (assuming you have not set an automatic recovery timeout, which is typically not recommended).
The diagram below illustrates this, if an IP Phone for example is “looped”, the SLPP Guard will detect SLPP PDU packets looping from the switch (originally transmitted from the SLPP enabled on the distribution switch) through the IP phone and back to another port on that edge switch or another edge switch: SLPP Guard will then disable the port.
SLPP PDUs are not forwarded back up the port on which they were received. Image Attribution: Extreme Networks (amended with additional information).
Default SLPP Guard XOS/SwitchEngine Edge Switch Configuration
Enabling SLPP Guard on a switch is simple, let’s say you have a 48 port copper XOS Switch, edge devices use ports 1-48, the Uplinks are on ports 49 and 50 and you wish to enable SLPP Guard, then you can use the following command. We are also specifically configuring that there should be no recovery timeout, so if SLPP PDUs are detected on a port it is disabled and remains so until some System Administrator intervention takes place.
enable slpp guard ports 1-48
configure slpp guard ports 1-48 recovery-timeout none
At least version XOS SwitchEngine 22 is required to enable SLPP Guard.
Once enabled you can view if any ports have seen looped packets i.e. their status with:
show slpp guard {ports port_list} {disabled-ports}For additional information see: https://documentation.extremenetworks.com/exos_31.1/GUID-54903026-AF6E-4C79-BB2D-C85D6F34E9CC.shtml
When applying SLPP Guard to ports that are a member of a LAG, you only need to apply to the pilot port of the LAG.
Example Loop
In this example a loop was deliberately added using a Cisco phone to loop from Switch Port 1:1 via the phone and back to Switch Port 2:1.
In normal operation:
# show slpp guard ports 1:1,2:1
Enable
Port SLPP Guard State Timeout Age Last Time Disabled Flags
--------- ---------- ---------- ------- ------ ------------------------ ------
1:1 Enabled None None NA NA C-
2:1 Enabled Monitoring None NA NA C-
================================================================================
State:
Disabled: Port disabled due to SLPP PDU received.
Monitoring: Listening for SLPP PDU.
None: Port is down.
Enable Flags: (C) By CLI, (R) By Radius VSA
SLPP Guard Ethertype: 0X8102Then when the loop has been added, in under a second, the ports go into a disabled state.
# show slpp guard ports 1:1,2:1
Enable
Port SLPP Guard State Timeout Age Last Time Disabled Flags
--------- ---------- ---------- ------- ------ ------------------------ ------
1:1 Enabled Disabled None NA Thu Apr 25 16:50:52 2024 C-
2:1 Enabled Disabled None NA Thu Apr 25 16:50:52 2024 C-
================================================================================
State:
Disabled: Port disabled due to SLPP PDU received.
Monitoring: Listening for SLPP PDU.
None: Port is down.
Enable Flags: (C) By CLI, (R) By Radius VSA
SLPP Guard Ethertype: 0X8102Here’s a video of the mess that was made and what happens, notice the loop between the slot 1 port 1 and slot 2 port 1, you can see the SLPP Guard disabled port is flashing amber.
