Я в полном замешательстве, поэтому буду признателен любой помощи.
У меня есть хост IPv6 (Linux 4.15.1-gentoo SMP x86_64), который случайно прекращает отправлять объявления соседей. Запуск tcpdump показывает множество запросов на запрос соседей и почти нулевую реакцию на эти запросы. Иногда хост все еще отправляет NA, но только после пары десятков проигнорированных запросов NS. Очевидно, что это полностью нарушает подключение IPv6.
Не знаю, относится ли это к делу, но IPv6 настроен на интерфейсе моста (на этом мосту также запущено несколько контейнеров lxc). Мост представляет собой типичный мост brctl с выключенным STP.
IPv6 настроен статически (как хост, так и шлюз).
Ручная рассылка по сети нежелательных объявлений о соседях (например, с помощью ndsendfrom vzctl) может немного смягчить проблему, но это, очевидно, не решение.
Что еще более странно, отключение и повторное включение ipv6 на интерфейсе через procfs ( /proc/sys/net/ipv6/conf/br0/disable_ipv6) и его перенастройка ( ip -6 addr add, и т.д.) временно "исправляет" проблему. Но через день или два все повторяется.
Для полноты картины, на хосте запущен брандмауэр nftables, но он явно разрешает весь трафик icmpv6 (через ip6 nexthdr ipv6-icmp acceptвезде). Отключение брандмауэра при возникновении проблемы ничего не меняет.
Итак, вот вопрос: что я могу сделать, чтобы определить основную проблему?
ОБНОВЛЯТЬ: У меня проблема исчезла после нескольких обновлений ядра, но есть сообщения о похожих проблемах в более поздних версиях ядра, особенно с большими таблицами маршрутизации и/или большим количеством соседей. Как сообщается, одним из возможных виновников здесь является небольшой предел размера кэша маршрутов/соседей ipv6 в ядре. Если у вас возникли похожие проблемы, попробуйте увеличить net.ipv6.route.max_sizeпараметр sysctl до относительно большого значения (например, 1048576), например, запустив sysctl -w net.ipv6.route.max_size=1048576и/или отредактировав /etc/sysctl.conf. Вы также, вероятно, захотите увеличить net.ipv6.route.gc_thresh, чтобы избежать слишком частого запуска сборщика мусора. Также проверьте net.ipv6.neigh.default.gc_thresh1,
net.ipv6.neigh.default.gc_thresh2и
net.ipv6.neigh.default.gc_thresh3, если у вас особенно много записей в кэше соседей. Смотритеhttps://www.kernel.org/doc/Documentation/networking/ip-sysctl.txtдля того, что делают все эти опции.
решение1
Я только что обнаружил, что в multicast_snooping в мостах Linux VLAN Aware есть ошибка. Она не затронет объявления маршрутизатора, но заблокирует обнаружение соседей, даже если включено multicast_flooding. Происходит следующее: при загрузке системы она сделает dad, и этот dad останется в базе данных multicast-пересылки. Но она истекает через 200 или 300 секунд. После этого любой многоадресный пакет обнаружения соседей будет сброшен на этот порт. Это происходит только с обнаружением соседей, а не с объявлением маршрутизатора. Вы можете убедиться в этом, выполнив:
bridge mdb show
Если он показывает вам записи, то multicast_snooping будет включен. И вы можете столкнуться с этой ошибкой. В моем случае около 80% систем, которые я настроил, начали блокировать только multicast-обнаружение соседей. Любой другой multicast затоплен или правильно отслежен.
На данный момент решением является отключение multicast_snooping:
echo 0 > /sys/net/devicename/bridge/multicast_snooping
Когда у меня будет время, я сделаю тестовую установку. Этот жук кусает меня за задницу уже 2 года, и у меня наконец-то появилось время во время аварийного обслуживания, чтобы полностью понять проблему.
решение2
У меня была та же проблема с ядром 4.16.2-gentoo. Но в моем случае это оказалось совершенно не связано с ядром.
Ящик, о котором идет речь, служил в качестве VPN-шлюза ipv6 и имел стабильное соединение. Даже подсеть-маршрутизатор за ним был в полном порядке, просто сама маршрутизируемая подсеть постоянно теряла соединение.
TL;DR;
firewalldбыл виновником в моем случае. IPv6rpfilterнастройка отфильтровала запросы соседей моего маршрутизатора подсети.
Узнал об этом, включив вход в систему/etc/firewalld/firewalld.conf
LogDenied=all
что привело к таким строкам лога (MAC и SRC сокращены и запутаны):
kernel: rpfilter_DROP: IN=enp6s0.100 OUT= MAC=XX:…:XX SRC=fe80:…:beaf DST=ff02:0000:0000:0000:0000:0001:ff00:0001 LEN=72 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=135 CODE=0
Я только что отключил ipv6 rpfilter, пока не смогу выяснить, почему это происходит. Настройка довольно проста, и все выглядит нормально, но, возможно, проблема в интерфейсе, являющемся vlan...