Я использую маршрутизатор на базе Linux-сервера под управлением стабильного Debian (Buster). Он использует Quagga для передачи BGP4 четырем одноранговым узлам (один из которых отправляет всю таблицу Интернет-маршрутизации для IPv4 и IPv6, другие отправляют значительно меньше маршрутов).
Примерно один или два раза в день сервер теряет возможность подключения по IPv6 примерно на пять минут.
Когда это происходит, оказывается, что сервер не может отправлять пакеты на адреса IPv6. Похоже, это влияет на любые адреса и интерфейсы - основной адаптер Ethernet, который подключается к Интернету, а также специальный интерфейс «Ethernet-over-USB», который подключается к встроенному адаптеру управления (контроллер Lenovo XClarity). Однако он может пинговать :: 1 так же, как и любой из своих собственных адресов (локальный для ссылки и маршрутизатор).
Кроме того, «ip -6 neigh ls» ничего не показывает как «REACHABLE», только «STALE» или «DELAY». Тем не менее, tcpdump на самом маршрутизаторе, похоже, не показывает выходящих пакетов запроса соседей. Когда я пытаюсь подключиться к другой машине в той же локальной сети, tcpdump на целевой машине также не показывает никаких полученных пакетов запроса соседей.
Это состояние длится около пяти минут, после чего все возвращается в нормальное состояние без какого-либо ручного вмешательства.
На подключение IPv4 это не влияет.
Я попытался проанализировать это еще раз, запустив аналитические инструменты (ping, vmstat, perf record), сохранив их вывод и сопоставив их со временем. Вот что я могу сказать на данный момент:
Когда возникает проблема, не возникает чрезмерного объема сетевого трафика.
Похоже, что нет никакого всплеска использования ОЗУ или ЦП.
нормальные операции в Интернете вызывают некоторые инкрементальные изменения таблицы маршрутизации время от времени, которые выполняются quagga; они, похоже, не связаны с отключениями; такие простои случаются и после периодов относительно небольших изменений
В любой момент perf показывает fib6_walk_continue как один из верхних символов; обычно около 5% накладных расходов. Однако примерно в тот момент, когда соединение IPv6 прекращается, наверху появляются следующие символы:
fib6_walk_continue (около 30%) native_queued_spin_lock_slowpath (около 10%) fib6_age (около 10%)
Изначально кажется, что все они принадлежат cmd "swapper". Примерно через минуту quagga замечает, что больше не может связаться с пирами, и начинает удалять маршруты IPv6; когда это происходит, в выводе perf появятся те же три символа, что и принадлежащие zebra.
Практически точно, когда возвращается нормальный вывод perf (с intel_idle вверху), соединение возвращается.
Кто-нибудь видел что-то подобное раньше?
Программное обеспечение: Debian Buster с последними пакетами, в частности linux-image-4.19.0-9-amd64 и quagga-core, а также quagga-bgpd 1.2.4-3
Аппаратное обеспечение: Lenovo SR550 с 6-ядерным процессором Intel (R) Xeon (R) Bronze 3104 CPU @ 1,70 ГГц и 32 ГБ ОЗУ
Изменить: этот вопрос был закрыт ServerFault с комментарием «Вопросы, требующие помощи по установке, настройке или диагностике, должны включать желаемое конечное состояние, конкретную проблему или ошибку, достаточную информацию о конфигурации и среде для ее воспроизведения, а также попытки решения».
Я считаю, что «конкретная проблема или ошибка, достаточная информация о конфигурации и среде для ее воспроизведения» уже были представлены в исходном описании.
«желаемое конечное состояние» будет заключаться в том, что машина не теряет возможность подключения по IPv6.
Для «попытки решения»: на данный момент я вернул ядро Linux к версии из Debian 9 «Stretch» (linux-image-4.9.0-13-amd64 версия 4.9.228-1), сохранив остальную часть пакеты в их текущих версиях в Debian 10 «Buster».
Пока что симптомы исчезли.
Если это сохранится в течение нескольких недель, я предполагаю, что это ошибка ядра Linux, появившаяся где-то между Linux 4.9 (от Stretch) и 4.19 (от Buster), и посмотрю, может ли она уже быть исправлена в более поздней версии ядра.