08-06-2020 11:30 AM
Hi!
In some switches where some 10 new Dell PCs are connected we see this (filtered for only one port):
# show upm history | include 31
965 Device-Detect device-detect-p 31 Pass 2020-08-06 13:07:17
964 Device-Detect device-detect-p 31 Pass 2020-08-06 13:07:10
963 Device-Detect device-detect-p 31 Pass 2020-08-06 13:07:03
962 Device-Detect device-detect-p 31 Pass 2020-08-06 13:06:56
961 Device-Detect device-detect-p 31 Pass 2020-08-06 13:06:49
960 Device-Detect device-detect-p 31 Pass 2020-08-06 13:06:42
959 Device-Detect device-detect-p 31 Pass 2020-08-06 13:06:35
958 Device-Detect device-detect-p 31 Pass 2020-08-06 13:06:28
We can see that the TTL in the LLDP packets received from the PCs is set to 3601. The problem is that the PC immediately after a normal LLDP packet sends out packet with TTL=0, which is the standard way of telling the switch/neigbour that it should remove the entry. This causes a queue of UPM scrips that builds up and the switch gets slow to respond due to high CPU utilisation.
Has anyone seen this before? We have thousands of PCs, but the ones acting up are a new model of Dell Optiplex 7480 All In One PCs. One issue is to have Dell fix their drivers or hardware, the other is that the switch is vulnerable to LLDP overload attacks. We see this both in unsupported X450e switches and supported X440, running the recommended EXOS 16. I’m pretty sure we’d see it in the newer switches as well but these PCs have only been deployed in one location so far.
It seems the PCs acting up only do so when in sleep mode. As soon as they wake up, they go back to a normal LLDP transmission behaviour.
I see lots of packet dumps and the likes in the Internet where TTL is set to 3601 when computers advertise LLDP, but often 120 seconds when networking gear do it (which seems to be a more normal value). Why do PCs advertise 3601?
Lots of questions… Any help is appreciated.