dmesg + UDP: неверная контрольная сумма. + rhel 7.x
Установите пакет yum-utils, затем удалите старые ядра:
# package-cleanup --oldkernels --count=2
count=2сохранит только 2 ядра. Чтобы сохранить работающее ядро :
# package-cleanup --oldkernels --count=1
Эти «ошибки UDP» являются разгрузкой контрольной суммы UDP. Сетевая карта отвечает за контрольную сумму, поэтому она не выполняется на уровне ЦП для экономии ресурсов ЦП. Это делает VMWare, и я думаю, что KVM тоже (и не только ). Следовательно, при использовании tcpdumpили просмотре системных журналов не видны правильные контрольные суммы на уровне ОС/ВМ.
см. Сегментация и разгрузка контрольной суммы :Отключение с помощью ethtool
Unfortunately sometimes what we see in Wireshark is not what we expect. One case in which this occurs is when TCP/IP operations are offloaded by the operating system to the Network Interface Card (NIC). Common operations for offloading are segmentation and checksum calculations. That is, instead of the OS using the CPU to segment TCP packets, it allows the NIC to use its own processor to perform the segmentation. This saves on the CPU and importantly cuts down on the bus communications to/from the NIC.
UDP / TCP Checksum errors in tcpdump output
if you have offload features enabled and you see cksum incorrect in tcpdump output, without any packet errors and your network is working properly: it is nothing to worry about because the checksum is actually calculated on the network adapter and the tcpdump is showing the checksum calculated on kernel level.
Из Ошибки контрольной суммы UDP/TCP из tcpdump и аппаратной разгрузки сетевой карты
After checking active NIC hardware offloading options you can see the obvious
$ sudo ethtool -k eth0 | grep on
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
generic-segmentation-offload: on
generic-receive-offload: on
rx-vlan-offload: on
tx-vlan-offload: onAfter disabling TCO (tcp offloading) for TX/RX on the NIC the problem is gone
$ sudo ethtool -K eth0 tx off rx off
Не забудьте снова включить оптимизацию после завершения отладки проблем с сетью, так как у вас будет небольшое снижение производительности, пока они отключены.
TLDR Эти «ошибки» — обычное явление на виртуальных машинах Linux, и вам не о чем зацикливаться, если вы знаете, что они являются частью вашего базового уровня. Кроме того, имейте в виду, что при просмотре журналов или отладке сетевых проблем то, что вы видите на уровне ядра, не обязательно будет видно на уровне сети.
Вы получаете неверные контрольные суммы пакетов через порт 5353, который используется для MDNS или многоадресной DNS -. Это может быть связано с тем, что у вас неисправное устройство (с ), такое как маршрутизатор, коммутатор, сетевая карта или что-то еще, что портит пакеты, или потому что в -есть человек --. ] средняя атака где-то.
Адрес 73.2.33.11 — Comcast, а адрес 82.2.33.1 — Virgin Media. В вашем случае лучше всего использовать Tcpdump или Wireshark для проверки пакетов, чтобы увидеть, что происходит. Вы также хотите увидеть, происходит ли то же самое на других системах в вашей сети. Это поможет вам понять, что это такое.
Это не вывод tcpdumpили wireshark, а часть листинга dmesg.
Эти сообщения поступают непосредственно из ядра, из функции __udp4_lib_rcv(), расположенной в net/ipv4/udp.cв исходном коде ядра Linux. Функция осведомлена об аппаратных функциях разгрузки.
Насколько я понимаю, если контрольные суммы обрабатываются аппаратно, это сообщение означает, что аппаратное обеспечение фактически обнаружило неверную контрольную сумму в полученном UDP-пакете.
UDP/5353 обычно используется MDNS :многоадресной DNS, одноранговым -и -разрешением имен узлов и протоколом обнаружения служб. Обычно его можно использовать только внутри одной организации :. Обычно нет необходимости разрешать трафик UDP/5353 через пограничный брандмауэр вашей организации, ни в -, ни в исходящий.
Если IP-адреса подлинные, плохие пакеты приходят из сети другого интернет-провайдера. Вы мало что можете сделать для этого :, в лучшем случае вы можете проверить трафик, чтобы увидеть, соответствуют ли пакеты известной атаке, и при необходимости сообщить об этом на адрес исходного интернет-провайдера.
Но тот факт, что ваш сервер, по-видимому, получает трафик UDP/5353 из Интернета, сам по себе может быть причиной для беспокойства. :Это может означать, что ваш брандмауэр дает утечку, и служба MDNS бесполезно доступна из Интернета. Если предполагается, что этот сервер защищен внешним аппаратным брандмауэром, дважды -проверьте его конфигурацию.
Если этот сервер должен быть защищен только собственным iptablesбрандмауэром, вам следует изменить настройки брандмауэра так, чтобы он принимал трафик MDNS только из собственной сети вашей организации, или полностью отключить службу MDNS, если она не нужна.