Как я ловил «двойной вход» удалённого объекта и закольцованный маршрут в распределённой сети
На днях разбирал инцидент, который на первый взгляд выглядел как «магия»: на одном из удалённых объектов внезапно пропали из сети три дома. Провайдер уверяет, что транспорт работает. В ядре ЦОД всё чисто. На объекте тоже — никаких видимых аварий.
Но в реальности всё было куда интереснее. Под катом — подробная диагностика, тонкости взаимодействия L2VPN-каналов и OSPF, и главное: как я решил ситуацию.
Архитектура, чтобы понимать контекст
В ЦОД у меня работает ядро сети, на коммутаторах Cisco Nexus N3K-C3064PQ-10GX, в которые подключена физика от провайдеров, в которых передаются VLANы, которые связывают удаленные объекты с основной сетью. В одном из таких каналов приходят два транспортных VLAN-а, которые держат канал L2VPN:
VLAN 3680 — основной
VLAN 3790 — резервный
На обоих VLAN-ах настроены SVI из подсети 10.201.10.0/24 и они участвуют в маршрутизации.
OSPF area ядра — 0.
На объекте установлен Cisco C3750-48TS-S, который маршрутизирует локальные VLAN-ы (10, 20, 30, 40) в транспортную подсеть 10.201.10.0/24.
На объекте установлен:
Cisco C3750-48TS-S — L3 коммутатор ядра объекта
К нему подключены обычные L2-коммутаторы доступа (VLAN 10, 20, 30, 40 — локальные VLANы объекта)
Именно C3750 маршрутизирует локальные VLANы в транспортную подсеть 10.201.10.0/24, через которую объект выходит в ЦОД
В штатной схеме дом должен ходить через VLAN 3680 → ЦОД → ядро.
Где всё сломалось
На объекте проводились аварийно-восстановительные работы, и три коммутатора доступа были подключены напрямую в ЦОД, минуя локальный C3750.
Подключены они были в транспорт VLAN 3790, который в норме является резервным.
То есть получилась такая картина:
Дома → три L2-коммутатора → VLAN 3790 → ядро в ЦОД → OSPF решает что маршрут в 10.10.20.0/24 через 10.201.10.24 → отправляет трафик назад → по VLAN 3680 → обратно на объект → C3750 → снова в ядро.Это классический двойной вход одного и того же объекта с двух разных VLAN-ов.
Результат — кольцевой маршрут уровня L3:
Коммутаторы уходят в ЦОД через 3790
ЦОД видит маршрут на объект через 10.201.10.24 (который доступен только через 3680)
Возвращает трафик обратно на объект
Объект отправляет его снова в ЦОД
И так по кругу
В итоге дома — «в сети», но по факту недоступны: поток ESTABLISHED-сессий рвётся, ARP гуляет не туда, задержки скачут.
Почему это произошло?
Потому что:
Оба VLAN-а (3680 и 3790) настроены одинаково и оба включены в транспортную L3-схему.
В OSPF ядра есть маршрут в 10.10.20.0/24 через 10.201.10.24, а 10.201.10.24 живёт только по VLAN 3680.
Коммутаторы шли в ядро по другому VLAN-у — 3790, где нет “обратного” шлюза.
Получился L3 hairpinning с возвратом на тот же объект, но по другому пути.
Как я устранил проблему
Шаг 1 — исключил второй вход объекта
На ядре отключил маршрутизацию из VLAN 3790, оставив его чистым L2-транспортом. Конкретно:
SVI с VLAN 3790 удалил
Убрал его участие в OSPF
Оставил VLAN 3790 только как резервный канал на случай L2-аварии
После этого пакеты, входящие на ядро по VLAN 3790, перестали “участвовать” в маршрутизации и не могли вернуться на объект по альтернативному пути.
Шаг 2 — вернул нормальный путь трафика
После того как VLAN 3790 перестал работать как L3-вход, трафик трёх коммутаторов:
поднимался в ЦОД по 3790
не находил для себя маршрута в сторону 10.201.10.24
возвращался в объект уже по штатному пути, но через C3750
корректно маршрутизировался
и отправлялся обратно в ЦОД по VLAN 3680
Цикл прекратился.
Шаг 3 — восстановил схему объекта
Переключил три коммутатора:
снял временные подключения в обход
вернул их uplink-и за C3750
восстановил штатную топологию
После этого связи на всех трёх домах восстановились.
Итог
Причиной инцидента стало то, что пакеты из резервного VLAN-а 3790 возвращались в объект по основному VLAN 3680, проходили через C3750 и снова отправлялись в ЦОД.
PS:. пишу данный пост накануне своего дня рождения, буду сильно благодарен, если в качестве подарка подпишитесь на мой (надеюсь хотя бы сейчас) начинающийся канал в Telegram
