SLPP Config

[TylerS]

We are trying to implement SLPP into our environment and it doesn’t seem to be behaving as it should.

From my understanding after reading some of the best practices in a scenario where an edge switch is connected back to the fabric core (in our case VSP7400s) via a lag group (2 ports shared) if SLPP is configured correctly, it should disable ONE of the uplink ports back to the fabric core upon receiving PDU packets in the amount defined on the core interface (one set to a lower limit, one set to a higher limit).

On our 2 VSP fabric switches we have SLPP configured like this:

Switch 1: 

slpp enable
slpp vid <vlan ID>

interface gig <interface> (Fabric Attached)

slpp port <Interfaces> packet-rx-threshold 5

Switch 2:

slpp enable
slpp vid <vlan ID>

interface gig <interfaces> (Fabric Attached)
slpp port <Interfaces> packet-rx-threshold 50
 

I setup a test edge switch which is an x450 24 port switch running EXOS 30.7 code. Then configured:

enable slpp guard ports 1:25-26 (the two uplink ports back to core)

Upon connecting up just ONE of the links to the VSP7400s, it is immediately disabled by SLPP. It does this every time. I do not understand how that is happening when only one of the links is connected. I intended to also connect the second un-lagged uplink port (thereby creating a loop) as a test but couldn’t even get to that point.

I then did more research and found a KB instructing NOT to enable SLPP on uplink ports, so I removed that config, re-lagged the uplink ports, and instead enabled SLPP on ports 1-12 and put those ports untagged in the same vlan that is enabled on the fabric for SLPP. I then induced a loop (plugged two ethernet cables into an IP phone and connected them both into the switch). Both of those ports were immediately disabled by SLPP but neither uplink port was affected. 

With that same configuration, I also tried breaking the lag group on the access switch and then connecting both ports (thus creating a loop back to the core). I gave it about 10-15 seconds and neither port was disabled so I manually removed them.

What am I missing? This seems like it should be very straightforward to implement and it has not turned out that way. Any insight would be greatly appreciated.

[WillyHe · Accepted solution]

Hello Tyler,

SLPP in the beginning was only supported on SMLT cluster switches to protect against loops that can bring down communication in the whole network.
The idea was, and still is, to let both cluster members generate SLPP packets in some vlan’s and configure thresholds on the SMLT ports, the threshold should have a different value on both cluster members for a specific SMLT to let them not go down at the same time (for some loops, the loop is solved when there is only one port active in the SMLT).
Then as a result the switch(es) having a loop become isolated after some time and normal communication is possible in the rest of the network.

To solve the problem having this isolation happening often, due to users playing with network connections or wrong patching or whatever reason, for access switches SLPPedge was developed.
The SLPPedge functionality allows an access switch to recognize SLPP packets generated by SMLT cluster switches on access ports (never enable SLPPedge on up-link ports) and blocks the SLPP packet incoming port immediately and this way protecting the threshold counters on the SMLT cluster to reach their threshold value.

As a result the access port(s) become disconnected and so protecting the access switch from becoming disconnected (isolated) from the SMLT cluster core.
This way only the users that are connected to the shut down port(s) are affected and not all users on the particular access switch(es).

hope it helps, regards

WillyHe

[WillyHe]

Hello Tyler,

Never enable SLPP guard on the uplink ports of an access switch, it will disable the port(s) on reception of the first SLPP packet from the core switch(es).

SLPP guard is meant for access ports .

The threshold configured on the ports of the SMLT cluster Fabric/core switches to block a/the port(s) when the specified amount of SLPP packets is returned on that port due to a loop between SLPP guard unprotected access ports.

hope it helps, regards

WillyHe