Назад | Перейти на главную страницу

Машина Linux не может отправлять пакеты IPv6 в течение пяти минут примерно раз в день

Я использую маршрутизатор на базе 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), сохранив их вывод и сопоставив их со временем. Вот что я могу сказать на данный момент:

В любой момент 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), и посмотрю, может ли она уже быть исправлена ​​в более поздней версии ядра.