Диагностика и устранение проблем балансировки трафика в MPLS LDP с ECMP на Cisco IOS/IOS-XR

Принципы работы LDP и ECMP в сетях Service Provider

Почему трафик между двумя точками в MPLS-сети может идти по пяти разным путям, а на практике «залипать» только на одном? Ответ кроется в тонком взаимодействии протокола распределения меток LDP и механизма ECMP. Для инженера Service Provider это не теоретический вопрос — это ежедневная реальность, где некорректная балансировка ведёт к перегрузке отдельных линков, задержкам и жалобам клиентов. Разберёмся, как эти два механизма должны работать в тандеме.

ECMP (Equal-Cost Multi-Path) — это функция, позволяющая маршрутизатору иметь несколько следующих переходов (next-hop) для одного и того же префикса в таблице маршрутизации, если все они имеют одинаковую «стоимость» (метрику). Представьте себе шоссе с пятью параллельными полосами, ведущими к одному городу. ECMP позволяет распределять машины (пакеты) по этим полосам, увеличивая общую пропускную способность.

LDP (Label Distribution Protocol) — это протокол, который «наклеивает» на эти маршруты MPLS-метки. Он работает поверх IGP (например, OSPF или IS-IS) и распространяет информацию: «Чтобы попасть в сеть 10.1.1.0/24, используй метку 30012». LDP не выбирает путь — он лишь присваивает метку уже выбранному IGP-маршруту.

Ключевой момент взаимодействия: LDP должен быть полностью осведомлён обо всех ECMP-путях, которые предоставляет IGP. Если для префикса существует три равнозначных next-hop, LDP должен получить уникальную метку для каждого из этих next-hop от каждого соседа. Это называется per-next-hop label binding.

Рассмотрим на конкретном примере. Допустим, маршрутизатор PE1 видит сеть клиента 192.168.1.0/24 через маршрутизатор P2. IGP (OSPF) определил, что до P2 можно добраться двумя путями: через P-A и через P-B. Оба пути имеют одинаковую стоимость. Тогда:

Именно в этом месте часто возникает первая проблема. Если LDP-сессия с одним из соседей (например, P-B) не установлена, то PE1 получит привязку метки только от P-A. В этом случае, даже если IGP всё ещё видит два пути, для MPLS-трафика будет использоваться только один — тот, для которого есть метка. ECMP на уровне MPLS фактически отключается.

> Важный вывод: Балансировка MPLS-трафика в ECMP-среде возможна только тогда, когда для каждого равнозначного next-hop существует корректная и активная LDP-привязка метки. Наличие маршрута в IGP — необходимое, но недостаточное условие.

Как это выглядит в таблице FIB (Forwarding Information Base)? На Cisco IOS-XR команда show cef 192.168.1.0/24 detail покажет не один, а несколько элементов в списке распределения (loadinfo). Каждый элемент будет содержать: * Интерфейс следующего перехода (например, GigabitEthernet0/0/0/1). * Заголовок MPLS, который будет наложен (например, Label 30012). * MAC-адрес следующего перехода.

Алгоритм хеширования, который выбирает конкретный пакет для конкретного пути, обычно использует поля из заголовков IP (source/destination IP, source/destination port для TCP/UDP) или даже из заголовков MPLS. Это позволяет сессии (например, поток данных между двумя конкретными серверами) всегда идти по одному и тому же пути, избегая переупорядочивания пакетов, в то время как разные сессии распределяются по доступным путям.

Таким образом, диагностика проблем с балансировкой всегда начинается с проверки двух слоёв: IGP (есть ли несколько путей?) и LDP (есть ли метки для всех этих путей?). Только убедившись в корректности обоих слоёв, можно переходить к анализу хеширования и FIB, что мы детально разберём в следующей статье.

Анализ взаимодействия LDP и FIB на Cisco IOS-XR

Если предыдущая статья объясняла «почему» должно быть несколько путей, то здесь мы погружаемся в «как» маршрутизатор Cisco IOS-XR реализует эту логику на уровне данных. Именно в таблице FIB (Forwarding Information Base) — оптимизированной для быстрого поиска копии таблицы маршрутизации — решается судьба каждого пакета. Непонимание того, как LDP-метки интегрируются в FIB, является причиной 80% сложных инцидентов с балансировкой.

В Cisco IOS-XR FIB хранится в процессе ipv4_rib и отображается командами семейства show cef. Ключевое отличие от IOS классического — более детализированная структура записи. Рассмотрим вывод команды show cef 10.2.2.0/24 на маршрутизаторе, где ECMP активен:

Обратите внимание на две ключевые секции via. Каждая из них — это отдельный ECMP-путь. Критически важные поля: * next hop: IP-адрес следующего маршрутизатора. * local label: Метка, которую данный next-hop (сосед) дал нам для этого префикса. Именно эта метка будет вставлена в заголовок пакета при выборе этого пути. * Интерфейс: через какой физический интерфейс идёт пакет.

Если в выводе вы видите только одну секцию via, значит, ECMP не работает. Причины могут быть:

Для глубокого анализа используйте команду show cef 10.2.2.0/24 detail. Она покажет структуру loadinfo — это и есть таблица хеширования. Вы увидите что-то вроде:

Это означает, что хеш-функция распределяет входящие потоки между индексами 0 и 1, которые указывают на два разных next-hop. Буква Y в поле Hash означает, что путь активен и пригоден для использования.

Типичная ловушка: Иногда после изменения топологии IGP (например, восстановления линка) FIB может обновиться не сразу или некорректно. Старые записи могут содержать «мёртвые» пути. Для принудительной перестройции FIB используется команда clear cef table. Однако на production-сети это следует делать с осторожностью и в окне обслуживания.

Другой сценарий — асимметричная конфигурация MTU. Если на одном из ECMP-путей MTU меньше, и пакет с наложенной меткой (добавляющей 4 или более байт) превышает этот MTU, он будет фрагментирован или отброшен. Это не отразится в выводе show cef, но приведёт к потере пакетов на одном из путей. Для диагностики используйте ping с большим размером пакета и флагом df-bit (Don't Fragment) через каждый конкретный next-hop.

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

Методология поиска неисправностей при нарушении балансировки

Когда мониторинг показывает, что один из линков загружен на 95%, а параллельный — на 5%, формальный ответ «балансировка нарушена» проблемы не решает. Нужен чёткий, воспроизводимый алгоритм, который позволит быстро локализовать причину: проблема в IGP, в LDP, в FIB или в самом механизме хеширования. Представляем четырёхэтапную методологию, проверенную на инцидентах в крупных сетях.

Этап 1: Верификация топологии IGP. Прежде чем подозревать MPLS, убедитесь, что IP-маршрутизация работает корректно. * show route <префикс> | include known — проверьте, сколько путей к префиксу знает IGP. * show ospf database router / show isis database verbose — убедитесь, что нет скрытых проблем в базе данных IGP, которые могли бы сделать один из путей предпочтительным. * Практический тест: Сделайте traceroute в режиме IP (без MPLS) к целевому префиксу. Если он всегда идёт только через один next-hop, значит, проблема на уровне IGP, и дальнейший анализ MPLS не требуется.

Этап 2: Проверка состояния LDP-сессий и привязок меток. Если IGP предоставляет несколько путей, проверяем, «покрыты» ли они метками. * show mpls ldp neighbor — убедитесь, что LDP-сессии установлены со всеми next-hop, которые предоставляет IGP. Статус должна быть «Operational». * show mpls ldp bindings <префикс> — эта команда показывает, от каких соседей мы получили метки для данного префикса. Количество полученных привязок должно совпадать с количеством next-hop из IGP. * Критическая проверка: Сравните вывод show mpls forwarding-table <префикс>. Он показывает, какие метки используются для пересылки. Если в ldp bindings метка от соседа B есть, а в mpls forwarding-table её нет — значит, процесс установки FIB (ipv4_rib) по какой-то причине её не принял.

Этап 3: Анализ FIB (CEF) и таблицы хеширования. Это детальный осмотр «двигателя» балансировки. * show cef <префикс> detail — как разбирали ранее, ищите несколько секций via и активные записи в loadinfo. * Поиск несоответствий: Убедитесь, что каждый next-hop в FIB имеет корректный local label и указывает на правильный исходящий интерфейс. Иногда после изменений в конфигурации интерфейсов FIB может содержать устаревшие ссылки. * show cef exact-route <source-ip> <dest-ip> — мощнейшая команда. Она показывает, по какому именно пути (интерфейс, next-hop, метка) будет отправлен пакет с заданными source и destination IP. Проведите серию тестов с разными парами IP-адресов, чтобы эмпирически проверить распределение.

Этап 4: Исследование хеширования и асимметрии. Если предыдущие шаги проблем не выявили, значит, сам алгоритм хеширования работает не так, как ожидается. * Проверка конфигурации хеширования: На IOS-XR используется команда show cef load-balancing. Убедитесь, что включены нужные поля для хеширования (например, include-ports). Если хеш считается только по IP-адресам, а трафик — это множество потоков между двумя IP (например, бэкап между двумя серверами), он не будет балансироваться. * Асимметричный трафик: Проблема может быть не в балансировке «туда», а в балансировке «обратно». Проверьте балансировку на обратном пути от точки B к точке A. Используйте show cef exact-route на промежуточных маршрутизаторах. * Влияние MPLS-заголовка: В некоторых случаях хеш может вычисляться по полям MPLS-заголовка, а не по IP. Это может привести к непредсказуемому распределению. Настройка cef load-balancing-fields позволяет это контролировать.

> Алгоритм действий при инциденте: 1) Зафиксировать асимметрию в мониторинге. 2) Определить проблемный префикс. 3) Пройти этапы 1-3 на обоих концах пути (на ingress и egress PE). 4) Сравнить результаты. Часто проблема оказывается в том, что на одном из маршрутизаторов не хватает LDP-привязки.

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

Кейс: диагностика асимметричного трафика в MPLS-сети

Разбор реального инцидента — лучший способ закрепить теорию. Представьте сеть Service Provider с топологией: CE1 — PE1 — P1 — P2 — PE2 — CE2. Между P1 и P2 существуют два параллельных линка (через агрегаторы A1 и A2), что даёт ECMP. IGP (IS-IS) видит оба пути. Жалоба от клиента: передача данных между его офисами (CE1 и CE2) идёт с низкой скоростью, хотя мониторинг показывает, что один линк между P1 и P2 загружен на 90%, а второй — на 10%.

Шаг 1: Верификация IGP. На P1 выполняем:

Видим, что P2 достижим через два next-hop: 10.1.12.2 (через A1) и 10.1.13.3 (через A2). Метрика одинаковая. show route 10.2.2.1 (адрес PE2) действительно показывает два пути. IGP в порядке.

Шаг 2: Проверка LDP.

Сессии с A1 и A2 установлены. Проверяем привязки меток для префикса PE2:

Вывод показывает две привязки: от A1 (метка 30112) и от A2 (метка 30113). Казалось бы, всё хорошо. Но затем проверяем, что реально используется:

А здесь видна только одна запись, указывающая на next-hop 10.1.12.2 (A1) с меткой 30112. Вот первый красный флаг: FIB использует только один путь, хотя LDP-привязки для обоих получены.

Шаг 3: Глубокий анализ FIB. Переходим к детальному просмотру:

В выводе видим только одну секцию via для 10.1.12.2. Второго пути нет. Почему? Смотрим логи и обнаруживаем, что на P1 некоторое время назад была перезагрузка интерфейса, ведущего к A2. После этого в таблице маршрутизации (RIB) путь через A2 появился, но процесс ipv4_rib по какой-то причине не внёс его в FIB. Это известный race-condition в некоторых версиях IOS-XR.

Решение: Принудительная перестройка FIB для этого префикса.

После этой команды проверяем show cef 10.2.2.1 detail снова. Теперь видим оба пути в loadinfo. Мониторинг трафика через 5 минут показывает, что загрузка линков выровнялась до 50% на каждом.

Но история на этом не заканчивается. Через неделю жалоба повторяется. Теперь оба пути в FIB присутствуют, но трафик всё равно идёт по одному. Возвращаемся к методологии.

Шаг 4: Анализ хеширования. Используем команду эмуляции:

Она показывает путь через A1. Пробуем другие пары IP-адресов из потока клиента — все идут через A1. Пробуем пары с другими source/destination port — распределение появляется. Проблема идентифицирована: трафик клиента — это один крупный поток данных (например, синхронизация базы) между двумя фиксированными IP и портами. Алгоритм хеширования, учитывающий 5-tuple (src/dst IP, src/dst port, protocol), для этого потока всегда даёт одинаковый результат.

Решение: Настроить на P1 и P2 балансировку с учётом только IP-адресов, игнорируя порты. Это приведёт к тому, что весь трафик между этими двумя IP будет идти по одному пути, но зато трафик от других клиентов будет распределяться более равномерно, что решит проблему общей перегрузки линка. Команда на IOS-XR:

Этот кейс показывает, что проблема может быть двухуровневой: сначала технический сбой в FIB, затем — неподходящая для трафика логика хеширования. Эффективная диагностика требует системного подхода и понимания, как каждый компмент влияет на итоговое решение о пересылке пакета.

Инструменты верификации и мониторинга путей в ECMP

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

Встроенные команды верификации (On-Box Diagnostics). Это первый эшелон диагностики, который даёт мгновенный снимок состояния. * show cef exact-route <src-ip> <dst-ip> — как уже упоминалось, ключевая команда для проверки конкретного потока. Её расширенная форма show cef exact-route <src-ip> <dst-ip> detail покажет не только путь, но и используемую метку и индекс в таблице хеширования. * show mpls forwarding-table <prefix> detail — показывает не только исходящую метку, но и счётчики пакетов/байт (packets, bytes), прошедших через каждый конкретный путь. Мониторинг этих счётчиков в динамике — самый простой способ визуально оценить балансировку. * show cef load-balancing — отображает глобальную конфигурацию хеширования и текущие активные поля. Незаменима для проверки, не изменился ли кто-то из инженеров настройки.

Инструменты активного зондирования (Active Probing). Пассивный мониторинг показывает, что есть. Активное зондирование позволяет проверить, что должно быть. * IP SLA с MPLS-опциями: Настроив IP SLA операцию на ingress-маршрутизаторе, можно эмулировать трафик с заданными параметрами (например, UDP-пакеты с определённым портом) и отслеживать, по какому пути он пойдёт. Это позволяет тестировать хеширование без реального трафика. Затем на промежуточных маршрутизаторах можно отследить этот тестовый поток. * EEM (Embedded Event Manager) для автоматической реакции: EEM-скрипт может мониторить вывод команды show mpls forwarding-table и, при обнаружении, что для ECMP-префикса активен только один next-hop, автоматически отправлять alert в систему мониторинга или даже выполнять корректирующее действие (например, clear cef table).

Интеграция с внешними системами мониторинга. Для масштабного мониторинга необходима централизация данных. * SNMP: Опрос MIB mplsLdpEntityTable для отслеживания статуса LDP-сессий и mplsFTNTable для получения информации о FTN (FEC-to-NHLFE) записях, которые и определяют пересылку. Резкое изменение в количестве записей или их состоянии — повод для тревоги. NetFlow / IPFIX: Настройте экспорт NetFlow на промежуточных маршрутизаторах с включением поля MPLS Top Label. Анализ потоков в коллекторе (например, в Kentik или Plixer*) позволит визуализировать распределение трафика по разным меткам (а значит, и по разным путям) в реальном времени. Если вы видите, что 95% трафика к префиксу идёт с одной меткой — это явная проблема балансировки. Streaming Telemetry (на IOS-XR): Самый современный подход. Настройте стриминг данных о состоянии FIB и LDP в модель YANG в формате GPB или JSON. Система вроде Telegraf + InfluxDB + Grafana* может строить в реальном времени графики количества активных путей для каждого префикса и распределения трафика между ними. Падение количества путей с двух до одного — немедленный алерт.

Практический чек-лист построения системы мониторинга:

Использование этого набора инструментов превращает поддержку MPLS ECMP из реактивного тушения пожаров в проактивное управление производительностью сети. Вы будете знать о проблеме балансировки за минуты после её возникновения, а в идеале — предупредите её появление.