cancel
Showing results for 
Search instead for 
Did you mean: 

Issue with Switch Port Shutdowns Due to SLPP Guard (NIC?)

Issue with Switch Port Shutdowns Due to SLPP Guard (NIC?)

manny1811
New Contributor

 

I'm experiencing an issue on our network where certain switch ports are shutting down, and we’re unsure of the root cause. When accessing the switches' web interface, the affected ports show as being down due to "SLPP GUARD." This has happened with 3-4 ports across the network, but for simplicity, I’ll focus on interface 1/2 on our edge switch.

A Dell OptiPlex workstation is directly connected to the switch on interface 1/2 (no phone in between), and we've already tested the cable. The workstation has internet access and works fine. The ports don’t shut down immediately, but roughly every 2-3 days. If we move the connection to a different port, like 1/4, the exact same thing happens—the port shuts down within 2-3 days. As a temporary fix, we’ve set the port to recover automatically, but the switch logs show that the port is constantly turning itself off and back on (The end user does not notice this however).

We've tested by intentionally creating a loop on the switch, and it immediately shuts down BOTH ports, as expected. I’m fairly familiar with SLPP Guard, and our current configuration is aligned with best practices, which include:

On core switches, SLPP should be enabled on all VLANs except SPBM B-VLANS (NNI) and the IST VLAN.
SLPP Rx should be enabled on all ports except the IST and NNIs on core switches.
The SLPP packet-rx-threshold should be set based on port type. Typically:
For SMLT ports, use an rx-threshold of 50 on the primary IST node and 500 on the secondary IST node.
For non-SMLT ports and non-IST/V-IST enabled nodes, use a packet-rx-threshold of 50. If this threshold isn't set, the port will shut down after receiving a single packet.
SLPP Guard should be enabled on all non-MLT ports on the edge switch, but not on the uplink MLT ports.


This issue has impacted three specific ports consistently, though not all. One interesting finding is that the problem does not occur at all when we bypass the Dell’s NIC using an Ethernet to USB-A adapter. Could it be that the Dell NIC is causing the issue? The Dell NIC drivers are fully updated, but this hasn’t resolved the problem. We have other Dell PCs on the network with the same NIC that are not experiencing this issue.

Any insights or suggestions would be greatly appreciated!




4 REPLIES 4

WillyHe
Contributor

Many years ago (before SLPP even existed) I had to debug a network loop issue at a customer.
It turned out to be a notebook witch had an active WLAN- and LAN- connection and on top of that bridging enabled in Windows.

Don't know if it is the case here but, a Dell OptiPlex workstation can have also a WLAN interface .....

MJS
New Contributor III

I concur with Roger here. Best bet for troubleshooting this would be to capture the traffic on the port that is giving you trouble. Mirror the port and use Wireshark to make the capture. Wireshark has the ability to create a ring buffer that will record the capture to multiple files (size and number of files is up to you). Once the incident occurs you can stop the capture and see exactly what the offending traffic/event is.

manny1811
New Contributor

This is a zoomed-in view of our fabric. The network includes more switches, but the graphic shows key physical connections. 

manny1811_1-1728332956262.png

 

the Dell device is only single homed to 1/2 or is there a LAG/MLT trunk with multiple ports? If only one port shuts down and not both, then you could have a unidirectional loop - not sure how a singe port on a Dell device could cause this though, but I suggest to mirror traffic to figure out what is going on.

GTM-P2G8KFN