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 II

 

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!




2 ACCEPTED SOLUTIONS

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.

View solution in original post

manny1811
New Contributor II

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.

View solution in original post

6 REPLIES 6

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.

The Dell device is single homed. I will run a packet capture to see what's going on. Thank you!

GTM-P2G8KFN