Теоретические основы и архитектура

Протокол LDP поддерживает несколько архитектурных режимов работы: 1. Распространение меток: Downstream Unsolicited (DU) — маршрутизатор рассылает свои метки всем соседям автоматически без запроса (стандарт в сетях операторов); Downstream on Demand (DoD) — метка выдаётся только в ответ на явный запрос от upstream соседа (исторически для ATM-коммутаторов; в IP/MPLS-ядрах встречается редко). 2. Хранение меток: Liberal Label Retention — маршрутизатор сохраняет в базе LIB метки от ВСЕХ соседей, даже если они не являются текущим Next-Hop по IGP (при падении основного линка новая метка уже готова в памяти, что ускоряет сходимость); Conservative Label Retention — сохраняются только метки от текущего IGP Next-Hop (экономит память, но замедляет переключение). 3. Контроль распределения: Ordered Control — маршрутизатор анонсирует метку для FEC только после того, как сам получил метку от downstream-соседа или является egress-узлом (метка выдаётся только при наличии рабочего хвоста LSP; по умолчанию Junos работает в ordered, Cisco IOS - в independent); Independent Control — маршрутизатор генерирует и анонсирует метку немедленно, не дожидаясь ответа от нижестоящего узла.

Три независимые оси поведения LDP

RFC 5036 описывает три ортогональных выбора, и их нельзя путать: как метки раздаются (Downstream Unsolicited или Downstream on Demand), что делать с полученными метками (liberal или conservative retention) и когда можно выдавать собственную метку (independent или ordered control). Реализация каждого вендора выбирает комбинацию; на Ethernet-ядре оператора это почти всегда DU + liberal, а control mode отличается между платформами.

Downstream Unsolicited и Downstream on Demand

В DU downstream-узел (тот, кто выдаёт метку для пересылки к нему) рассылает Label Mapping всем соседям без запроса, как только у него есть привязка для FEC. Upstream просто принимает. В DoD upstream сначала шлёт Label Request (0x0401) для конкретного FEC, а downstream отвечает Label Mapping; метка выдаётся только по запросу, а при изменении next-hop запрос повторяется. DoD нужен там, где метки дороги (ATM, Frame Relay, label-controlled интерфейсы) или метки хочется выдавать только когда они нужны. Режим согласуется в Initialization (флаг A): если один узел предлагает DU, а другой DoD, сессия использует DoD. Для Ethernet DU естественен и экономит один round trip на каждый FEC, поэтому DoD в IP/MPLS-ядрах встречается редко (Huawei позволяет явно выбрать режим на интерфейсе командой mpls ldp advertisement).

Label retention: liberal и conservative

Liberal retention хранит в LIB привязки от всех соседей, даже если сосед сейчас не next-hop для FEC. Выигрыш - мгновенный перенос на запасной путь: после падения основного линка LDP берёт уже имеющуюся в LIB метку нового next-hop, не ожидая Label Mapping, и LFIB пересчитывается за миллисекунды. Цена - память: N соседей умножают размер LIB; при 5000 FEC и 4 соседях это 20 000 записей, что для современных платформ несущественно. Conservative retention хранит только привязку от текущего next-hop и отбрасывает остальные (при DoD снова запрашивает метку нового next-hop через Label Request). Он экономит память, но после смены next-hop сходимость идёт через обмен сообщениями, и на это время трафик теряется.

Label distribution control: independent и ordered

При independent control LSR выдаёт локальную метку для FEC сразу, как только префикс появился в его RIB, и рассылает её, не дожидаясь привязки от next-hop. Плюс - быстрый старт и независимость от порядка, минус - возможны промежуточные чёрные дыры: апстрим уже получил метку, а downstream-ветка LSP ещё не построена, и пакет с меткой уходит в тупик. При ordered control узел выдаёт метку, только когда он egress для FEC (например, это его loopback) либо уже получил привязку от next-hop. LSP строится строго от egress к ingress, поэтому каждая выданная метка гарантирует рабочий хвост. Цена - время построения: метка проходит последовательно через каждый узел, и разрыв на середине пути гасит всё, что выше по цепочке. По документации Cisco IOS в frame-mode использует independent control, Junos - ordered; платформа, где поведение критично, проверяется вручную (см. review).

Implicit null, explicit null и PHP

Egress для FEC может выдать три варианта: implicit null (метка 3, PHP: предпоследний LSR снимает метку, egress получает чистый пакет), explicit null (метка 0 для IPv4, 2 для IPv6: метка остаётся до egress, и сохраняется поле TC/EXP) или non-null (обычная метка, LSP заканчивается обычным lookup). Implicit null экономит один lookup на egress, а explicit null нужен для сквозной QoS-классификации по TC на последнем хопе. У Cisco mpls ldp explicit-null может действовать для списка FEC и списка соседей, у Junos - protocols mpls explicit-null, у Huawei - label advertise explicit-null в MPLS-view, у MikroTik - use-explicit-null=yes.

Кто и что получает метки: управление распространением

Метки можно ограничить отдельно для передачи (Cisco mpls ldp advertise-labels for <FEC-ACL> to <PEER-ACL>, Junos export policy) и для приёма (accept/import: Cisco inbound label filtering, Junos import, MikroTik accept-filter). Это превращается в точную модель пересылки: при liberal retention принятый, но не подходящий по next-hop label остаётся в LIB «про запас». При отсутствии нужной привязки у ordered-узла он не выдаёт метку вверх по цепочке, и LSP не строится, а у independent-узла метка есть, но хвост LSP пустой и пакеты теряются. Если ограничение распространения применено по ошибке к FEC, нужному BGP-next-hop, L3VPN ломается.