BGP выучил префикс, но трафик по-прежнему обходит туннель

Шлюз филиала показывает префикс облака в своей таблице BGP, сессия с провайдером установлена, и всё же запрос пользователя к этому префиксу уходит через неправильный интерфейс. Ничего не сломано так, как подсказывает мониторинг, ведь «BGP его выучил» — утверждение о плоскости управления. Между этой таблицей и пакетом есть четыре отдельных перехода, и поток останавливается ровно на одном из них. Пройдите шлюзы по порядку и остановитесь на первом, который не пройден.

Первый шлюз: что сосед действительно прислал

Начните с префикса таким, каким он получен, а не в сводке. Найдите точную сеть и маску в таблице BGP и запишите следующий хоп, путь AS и любое сообщество, с которым может совпасть политика импорта. Сводный маршрут на панели может скрыть тот факт, что конкретный префикс так и не был принят.

Политика импорта — обычное место, где маршрут исчезает без ошибки. Список префиксов, фильтр сообществ или карта входящих маршрутов могут отбросить обновление, пока сессия остаётся поднятой и здоровой, и поэтому зелёный индикатор соседа доказывает так мало. Отсутствие строки в журнале не означает отсутствия решения. Обычно это значит, что решение принято молча, ровно как настроено.

show ip bgp 10.60.20.0/24
show ip bgp neighbors 203.0.113.5 advertised-routes
show ip route 10.60.20.0
show ip cef 10.60.20.0

Читайте вывод в этом порядке. Первые две команды говорят, пришла ли информация и что партнёр утверждает, что отправил; последние две — дошло ли что-нибудь до таблиц маршрутизации и пересылки. Префикс, присутствующий в первой команде и отсутствующий в третьей, — это проблема выбора или установки, а не связности.

Второй шлюз: выбор, затем установка

BGP выбирает лучший путь, и выбранный путь не устанавливается автоматически. Следующий хоп должен разрешиться, а другой источник маршрутов может уже владеть этим префиксом с лучшей административной дистанцией. Статический маршрут, оставшийся от миграции, легко победит действительный путь BGP и отправит трафик в другое место.

RFC 4271 держит три идеи раздельно: что прислал партнёр, что этот спикер выбрал лучшим и что он будет объявлять дальше. Это концептуальные роли, а не три физические базы данных, которые поставщик обязан показать, но именно это разделение делает «это есть в BGP» неполным ответом.

Проверьте также, какой контекст маршрутизации вы читаете. Маршрут, установленный в VRF, к которой не относится интерфейс пользователя, невидим для пакетов этого пользователя, а таблица всё это время выглядит правильной.

Третий шлюз: поиск, применимый к этому потоку

Теперь перестаньте спрашивать о маршруте и начните спрашивать о пакете. Запишите адрес источника пользователя, назначение, протокол, порт и входной интерфейс, потому что каждый из них может выбрать другую политику. Затем посмотрите на поиск, применимый к этой комбинации, а не на общую таблицу маршрутизации.

ip route get 10.60.20.25 from 10.60.10.40
ip rule show
sudo tcpdump -ni tun0 'host 10.60.20.25'

Более конкретный префикс — самая частая неожиданность здесь, а политический маршрут — вторая. Оба перекрывают агрегат, на который вы смотрели, и ни один не виден в сводке таблицы BGP.

Пинг с самого шлюза не является доказательством о сессии пользователя. Другой адрес источника, другой путь политики и часто другой результат. Проверяйте с тем же источником, который использует приложение, или примите, что тест отвечает на другой вопрос.

Четвёртый шлюз: дальняя половина пути

Если локальный поиск действительно выбрал туннель, пакет всё равно должен быть принят политикой защиты, разрешён правилом пересылки и получить ответ от чего-то на другой стороне. Крипто-ACL без пары адресов отбросит трафик, пока туннель сообщает о себе как о поднятом, что даёт тайм-аут, неотличимый от сбоя маршрутизации.

Обратный путь важен не меньше исходящего. Сторона облака должна знать, как достичь источника филиала — через маршрут или через трансляцию, которую вы настроили намеренно. Асимметричные обратные пути часты в проектах, проверенных только в одном направлении.

Сопоставьте свежее авторизованное соединение с тремя наблюдениями: локальная политика, которая совпала, счётчики туннеля, которые сдвинулись, и приём на дальней стороне там, где это видно. Если счётчики не двигаются, пакет вообще не входил в туннель, что бы ни говорила таблица маршрутов. Если двигаются, а ничего не приходит, дальняя сторона отбрасывает или неверно маршрутизирует его. Эти два исхода ведут к совершенно разным командам.

Назовите переход, который не сработал

Запишите результат как одно из пяти состояний: не получен, не принят политикой, не выбран, не установлен или не совпал с этим потоком. Добавьте шестое для случая, когда локальный путь правилен, а дальний конец не может ответить. Это предложение и есть результат, и оно гораздо полезнее снимка экрана установленного соседа.

Держите в плане приёмки и негативный тест: назначение, которое не должно проходить через туннель, проверенное после изменения. Контрольный список, доказывающий только удачный путь, не поймает широкое правило политики, которое кто-то добавит в следующее окно обслуживания.