Теоретические основы и архитектура
Лабораторная работа: устранение проблемы Blackholing через LDP-IGP Synchronization и фильтрация меток. При восстановлении упавшего физического линка OSPF или IS-IS поднимает соседство и быстро начинает направлять транзитный трафик через этот линк. Однако сессия LDP требует времени на обнаружение, TCP-соединение и обмен Label Mapping (обычно секунды). В этот промежуток времени маршрутизатор пересылает трафик в линк, где меток ещё нет, и помеченный трафик на этом направлении теряется (Blackholing). Механизм LDP-IGP Sync решает эту проблему: пока LDP-сессия на линке не перейдёт в состояние Operational, IGP держит метрику этого интерфейса на максимальном значении (у Cisco в OSPF это 65535, в IS-IS и на других платформах значение иное). Трафик продолжает безопасно идти по резервному пути. Как только LDP полностью готов, IGP снижает метрику до нормальной. Также в лабораторной настраивается фильтрация анонса меток (Label Filtering), чтобы маршрутизаторы не генерировали метки для транзитных /30 подсетей.
Проблема: IGP быстрее LDP
После восстановления линка OSPF или IS-IS поднимает adjacency и пересчитывает SPF за десятки миллисекунд, а LDP должен заново пройти discovery, открыть TCP-сессию (три сегмента handshake, затем Initialization и KeepAlive) и обменяться Label Mapping для всех FEC: на практике от долей секунды до десятков секунд. Всё это время IGP уже считает линк лучшим и направляет по нему трафик. Меток для FEC на этом линке ещё нет, поэтому на транзитном узле пакеты с VPN-меткой теряются: LDP black hole. Параллельный IP-трафик может проходить (LFIB отдаёт No Label, пакет уходит как IP), но L3VPN, pseudowire и всё, что зависит от транспортного LSP, пропадает до момента, пока метки не будут установлены.
Решение: LDP-IGP synchronization (RFC 5443)
Пока на интерфейсе нет «готового» LDP, IGP объявляет линк с максимальной метрикой. Трафик остаётся на запасном пути, а сам линк остаётся «последней надеждой»: если запасного пути нет, IGP всё равно будет им пользоваться. Когда LDP на этом линке готов (сессия Operational и обмен привязками начался), метрика возвращается к штатной, и SPF плавно переносит трафик. Cisco в OSPF объявляет максимальную метрику 65535; точное значение зависит от платформы и протокола.
Состояния на Cisco (show mpls ldp igp sync): LDP не настроен или IGP sync выключен на интерфейсе; LDP настроен и ожидает сессию; sync achieved (метрика нормальная); sync not achieved (метрика максимальная). Два таймера управляют поведением: holddown - предельное время ожидания, пока сессия не поднялась, после которого IGP всё же возвращает нормальную метрику (по умолчанию на Cisco ограничение выключено: ждать бесконечно) и delay - небольшая пауза уже после поднятия сессии, чтобы привязки успели попасть в LFIB (IOS-XE: mpls ldp igp sync delay). Конфигурация делается в процессе IGP (mpls ldp sync в router ospf), а исключения - на интерфейсе (no mpls ldp igp sync).
Одностороннее включение не работает
Метрика линка - свойство направления. Если sync включён на PE1 и выключен на P1, PE1 после восстановления объявит максимальную метрику, а P1 сразу рекламирует нормальную: трафик от P1 к PE1 пойдёт по восстановленному линку, где PE1 ещё не выдал меток. Sync нужно включать на обоих концах каждого линка, и проверять оба конца в show mpls ldp igp sync.
Когда sync вредит: LDP никогда не поднимется
Если LDP по какой-то причине не поднимается на данном линке (MD5, ACL на TCP 646, MTU), линк навсегда останется с максимальной метрикой, и трафик уйдёт на запасной маршрут: это хороший отказ (трафик не теряется), но обязательно нужен мониторинг sync-статуса, иначе деградация остаётся незамеченной. Holddown ограничивает такое состояние, но возвращает потери, поэтому выбирать его нужно осознанно. На Junos аналог - ldp-synchronization на интерфейсе в блоке IGP с параметром hold-time; на Huawei - ldp-sync в OSPF и таймеры hold-down на интерфейсе.
LDP session protection
При падении единственной прямой связи пропадает adjacency и сессия, а с ней все привязки соседа: после возврата линка нужно заново получить все метки. Session protection держит параллельную targeted-adjacency до соседа по любому доступному пути: сессия переживает потерю прямого линка, привязки остаются в LIB, а когда линк возвращается, метки уже на месте и sync срабатывает почти мгновенно. На Cisco: mpls ldp session protection [for ACL] [duration секунды], на Junos - session-protection с необязательным timeout. Цена - дополнительная targeted-adjacency и состояние на каждого защищаемого соседа.
Фильтрация меток в ядре
Метки нужны только для адресов, которые используются как BGP next-hop (loopback PE и RR при необходимости); метки на линковые /30 и тем более на клиентские префиксы бесполезны и увеличивают LFIB и поверхность атаки. Практика: ограничить выделение (Cisco allocate global host-routes или prefix-list) либо рассылку (Junos export с route-filter .../16 prefix-length-range /32-/32, MikroTik advertise-filter). Правило работы: каждый адрес, на который указывает next-hop VPN-маршрута, обязан остаться в списке. Контрольный тест: убрать PE2 из списка и убедиться, что LSP до PE2 пропал, затем вернуть.
Порядок выполнения лабораторной
- Базовая связность: IGP, LDP, метки на всех FEC; зафиксировать ping 10.255.0.2 с loopback PE1. 2) Включить sync на обоих концах основного и резервного линков. 3) Включить session protection. 4) Запустить непрерывный ping 10.255.0.2 source Loopback0 с частотой 5/с, выключить основной линк, дождаться, когда трафик идёт по резерву. 5) Включить линк и наблюдать: IGP-adjacency up, sync not achieved, LDP Oper, sync achieved, метрика вернулась; сравнить число потерянных пакетов с прогоном без sync. 6) Отдельным изменением включить фильтрацию меток и проверить, что все PE-FEC остались.
Что проверять в первую очередь
show mpls ldp igp sync на обоих концах линка, show ip ospf mpls ldp interface (состояние sync на OSPF-интерфейсе), show mpls ldp neighbor (какие adjacency и targeted), show mpls forwarding-table 10.255.0.2 до и после, show ip route 10.255.0.2 (cost 20 по основному, 60 по резервному линку).
Схема архитектуры и топология
+-----------+ [Primary Link: Restored / Metric 65535] +-----------+
| PE-1 | ====================================================> | P-1 |
| | ---------------- [Backup Link: Metric 50] ----------> | |
+-----------+ +-----------+Схема прохождения трафика и стек меток
LDP-IGP Synchronization Sequence (RFC 5443):
1. Primary physical link restores; the IGP adjacency comes up.
2. The IGP advertises the link with maximum metric (Cisco OSPF: 65535; IS-IS and other platforms use their own maximum).
3. Transit traffic stays on the backup path (metric 50) while LDP is not Operational on that link.
4. LDP discovers the neighbor, opens the TCP session and exchanges label bindings.
5. The IGP restores the configured metric (10) and SPF moves traffic back to the primary link.
A hold-down timer, if configured, bounds the wait when LDP never comes up.