My monitoring has been alerting on and off a couple of times per hour due to rx errors on the interface.
Couldn't find any tx errors on the other end, but sent out a guy to mount a attenuator, since the sfp reported the signal to be just over the warning threshold. When this didn't work, I managed to find a reference to this issue on the freebsd mailing list.
https://lists.freebsd.org/archives/dev-commits-src-all/2023-February/022083.html
ixgbe: Do not count L3/L4 checksum errors as input errors
NIC input errors have traditionally indicated problems at the link
level (crc errors, runts, etc). People tend to build monitoring
infrastructure around such errors in order to monitor for bad network
hardware. When L3/L4 checksum errors are included in the category of
input errors, it breaks such monitoring, as these errors can originate
anywhere on the internet, and do not necessarily indicate faulty
local network hardware.
Why is it like this? Can it be fixed in this driver as well?
Hi
My monitoring has been alerting on and off a couple of times per hour due to rx errors on the interface. Couldn't find any tx errors on the other end, but sent out a guy to mount a attenuator, since the sfp reported the signal to be just over the warning threshold. When this didn't work, I managed to find a reference to this issue on the freebsd mailing list. https://lists.freebsd.org/archives/dev-commits-src-all/2023-February/022083.html
Why is it like this? Can it be fixed in this driver as well?
https://github.com/intel/ethernet-linux-ixgbe/blame/4cde18977f9e8d131d29fb046b98e16592c71046/src/ixgbe_main.c#L9757