Latency and Dropped Packets

[bgomberg]

Hey guys,

Trying to figure this one out. I have a 3 chassis 6850 stack that is dropping packets from directly connected hosts intermittently. I've tested from multiple hosts and they all experience the same issue, indicating the switch. Ping from directly connected hosts have higher latency than I would expect as well. Pings from this stack to other directly connected switches don't outright drop packets but do have latency spikes. Please see below for examples. Not even sure where to begin here. Please help! Thank you in advance.

From Windows server to switch:

Reply from 10.0.3.1: bytes=32 time=16ms TTL=64
Reply from 10.0.3.1: bytes=32 time<1ms TTL=64
Reply from 10.0.3.1: bytes=32 time<1ms TTL=64
Reply from 10.0.3.1: bytes=32 time<1ms TTL=64
Reply from 10.0.3.1: bytes=32 time<1ms TTL=64
Reply from 10.0.3.1: bytes=32 time<1ms TTL=64
Reply from 10.0.3.1: bytes=32 time<1ms TTL=64
Reply from 10.0.3.1: bytes=32 time<1ms TTL=64
Reply from 10.0.3.1: bytes=32 time=4ms TTL=64
Reply from 10.0.3.1: bytes=32 time=3ms TTL=64
Reply from 10.0.3.1: bytes=32 time=2ms TTL=64
Reply from 10.0.3.1: bytes=32 time=3ms TTL=64
Request timed out.
Reply from 10.0.3.1: bytes=32 time<1ms TTL=64
Reply from 10.0.3.1: bytes=32 time<1ms TTL=64
Reply from 10.0.3.1: bytes=32 time<1ms TTL=64
Reply from 10.0.3.1: bytes=32 time=1ms TTL=64
Reply from 10.0.3.1: bytes=32 time<1ms TTL=64
Reply from 10.0.3.1: bytes=32 time<1ms TTL=64

From Alcatel Stack to directly connected switch:

64 bytes from 10.0.3.5: icmp_seq=207. time=4. ms
64 bytes from 10.0.3.5: icmp_seq=208. time=23. ms
64 bytes from 10.0.3.5: icmp_seq=209. time=5. ms
64 bytes from 10.0.3.5: icmp_seq=210. time=29. ms
64 bytes from 10.0.3.5: icmp_seq=211. time=5. ms
64 bytes from 10.0.3.5: icmp_seq=212. time=22. ms
64 bytes from 10.0.3.5: icmp_seq=213. time=4. ms
64 bytes from 10.0.3.5: icmp_seq=214. time=28. ms
64 bytes from 10.0.3.5: icmp_seq=215. time=24. ms
64 bytes from 10.0.3.5: icmp_seq=216. time=25. ms
64 bytes from 10.0.3.5: icmp_seq=217. time=5. ms
64 bytes from 10.0.3.5: icmp_seq=218. time=5. ms
64 bytes from 10.0.3.5: icmp_seq=219. time=4. ms
64 bytes from 10.0.3.5: icmp_seq=220. time=4. ms
64 bytes from 10.0.3.5: icmp_seq=221. time=4. ms
64 bytes from 10.0.3.5: icmp_seq=222. time=4. ms
64 bytes from 10.0.3.5: icmp_seq=223. time=4. ms
64 bytes from 10.0.3.5: icmp_seq=224. time=4. ms
64 bytes from 10.0.3.5: icmp_seq=225. time=4. ms
64 bytes from 10.0.3.5: icmp_seq=226. time=4. ms
64 bytes from 10.0.3.5: icmp_seq=227. time=4. ms
64 bytes from 10.0.3.5: icmp_seq=228. time=23. ms
64 bytes from 10.0.3.5: icmp_seq=229. time=4. ms


CPU Health:

Device 1 Min 1 Hr 1 Hr
Resources Limit Curr Avg Avg Max
-----------------+-------+------+------+-----+----
Receive 80 01 01 01 01
Transmit/Receive 80 01 01 01 01
Memory 80 77 77 76 77
Cpu 80 12 15 16 56


Switch log lists the following every 30 seconds for eternity:

MON MAY 11 16:43:35 2020 LLDP warning lldpProcessPortIdTLV: Port ID TLV length 2 invalid

[silvio]

What about pings from client/server to client/server? Ping to an switch is not a real test. The switches do handle the reply to pings not with the highest prio. So this is normal behavior.
regards
Silvio