Транзит теряет маршрут, дежурный перезапускает Kubernetes. Отличный способ добавить вторую аварию к первой. Разберём типовой отказ: мониторинг кричит о таймаутах ingress, systemctl is-active bird2 возвращает active. Это состояние сервиса. В birdc show protocols all проверяем отдельно BGP: Active означает попытку установить сессию; даже Established не гарантирует доставку через сеть соседа. Механика: у провайдера флапает удалённый префикс, а нам он продолжает отдавать default. Локальная таблица Linux может вообще не меняться. Проверяем birdc 'show route for 203.0.113.10 all', затем ip route get 203.0.113.10 и ip -ts monitor route. Здесь 203.0.113.10 — пример: подставьте адрес сбоя и выполняйте проверку в нужном network namespace. Таблица BIRD и таблица ядра — отдельные объекты, их синхронизирует kernel protocol. Документация BIRD. На узле, который инициирует TCP, снимаем два замера nstat -az TcpRetransSegs TcpExtTCPSynRetrans IpOutNoRoutes. Рост ретрансмитов при неизменном IpOutNoRoutes совместим с потерями за пределами узла: маршрут у ядра есть, ответа нет. Эти счётчики не доказывают flapping и не учитывают транзитный TCP как локальную сессию. Для диагноза нужны совпадающие по времени withdrawals/announcements у провайдера и проверки доставки с независимых точек. Счётчики Linux. Исправление — переключение на проверенный независимый транзит с задержкой обратного переключения, чтобы самому не устроить flapping. BFD до ближайшего соседа не проверяет весь дальнейший путь. Второй BGP-пир через тот же аварийный транзит — две строки конфигурации вместо резервирования. Ещё один оператор K8s маршрут провайдеру не вернёт. Эксплуатация начинается с проверки доставки: https://ftops.space/?utm*source=telegram&utm*medium=smm&utm*campaign=ftops&utm*content=bgp-route-flapping-v-tranzite-prova