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

[manny1811]

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!

[Roger_Lapuh · Accepted solution]

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.

[manny1811 · Accepted solution]

After running a packet capture, we discovered that the issue was caused by a faulty NIC. It appears that the Intel NIC floods the network with IPv6 packets when the computer is in sleep mode, which somehow to triggers SLPP-Guard. We are currently weighing our options, but for anyone experiencing similar issues, here are some short-term and long-term fixes to consider:

-Set the PC to never sleep.
-Disable IPv6 on the PC (Keep in mind Microsoft does not recommend this)
-Update the NIC drivers (this was the first thing we tried, but unfortunately it did not resolve the issue).
-Bypass(via USB adapter) or replace the NIC. Dell support may be able to replace it if it's still under warranty.

[WillyHe]

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]

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]

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