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

Понятие FEC (Forwarding Equivalence Class) — основа пересылки в MPLS. FEC объединяет группу IP-пакетов, которые пересылаются одинаковым образом, по одинаковому пути и с одинаковым обращением. В базовом MPLS каждый IP-префикс ядра (например, Loopback PE2 10.255.0.2/32) представляет собой отдельный FEC. Каждый маршрутизатор независимо генерирует для этого FEC локальную метку (Local Label) из своего пула и анонсирует её всем LDP-соседям в виде Label Binding. Получив метку от соседа, маршрутизатор сохраняет её в базе LIB как Remote Label. Затем, сопоставив следующий переход (Next-Hop) по таблице маршрутизации IGP, маршрутизатор выбирает соответствующую Remote Label в качестве исходящей метки (Outgoing Label) и инсталлирует запись в аппаратную таблицу LFIB. Таким образом через всю сеть строится непрерывный путь коммутации меток — LSP (Label Switched Path). Если хотя бы на одном транзитном P-маршрутизаторе разорвётся связка LDP для данного FEC, LSP разрушится, и трафик начнёт отбрасываться.

FEC: что именно привязывается к метке

FEC (Forwarding Equivalence Class) - класс пакетов, которые все LSR пересылают одинаково. В транспортном MPLS на LDP FEC почти всегда равен IP-префиксу из IGP: Prefix FEC в сообщении Label Mapping содержит address family, длину и сам префикс. Кроме него в LDP есть Wildcard FEC (все FEC, используется в Label Withdraw/Release), Typed Wildcard (RFC 5918) и pseudowire-элементы PWid FEC 128 и Generalized PWid FEC 129 для L2VPN. Для транспортного LSP достаточно префиксов /32 loopback: именно они являются next-hop для BGP VPN, поэтому метки на линковые /30 в ядре обычно не нужны.

Label Mapping: что передаётся

Сообщение Label Mapping (0x0400) содержит FEC TLV и Label TLV (Generic Label, 20 бит) плюс необязательные TLV (Hop Count, Path Vector). Локальную метку LSR выбирает из своего пула: на IOS-XE диапазон по умолчанию начинается с 16, на Huawei динамические метки начинаются с 1024 (16-1023 резервируются под static LSP), на Junos динамические метки LDP начинаются приблизительно с 299776. Значения 0-15 зарезервированы: 0 - IPv4 explicit null, 1 - router alert, 2 - IPv6 explicit null, 3 - implicit null, 7 - ELI, 13 - GAL, 14 - OAM alert. Implicit null в пакете не появляется: egress лишь сообщает метку 3, а предпоследний LSR выполняет pop (PHP), так что на egress приходит уже пакет с вложенным содержимым.

LIB, RIB и LFIB: три таблицы

  • LIB (Label Information Base) хранит все локальные привязки и все привязки, полученные от каждого соседа (по умолчанию liberal retention).
  • RIB - таблица IGP; для каждого префикса даёт next-hop (адрес линка) и интерфейс.
  • LFIB - таблица пересылки: входная метка -> операция (swap/pop) -> выходная метка, интерфейс, next-hop.

Алгоритм: для FEC берём IGP next-hop, находим LDP-соседа, которому принадлежит этот адрес (по сообщению Address), и из LIB берём привязку этого соседа. Если привязки нет, LFIB остаётся с Pop/No Label. Отсюда типовые сбои: сосед есть, привязка есть, но LFIB пуст, потому что next-hop принадлежит другому адресу соседа, не опубликованному в Address, или потому, что IGP next-hop не является LDP-соседом (линк без mpls ip).

Непрерывный LSP и точное совпадение FEC

LSP непрерывен, если у каждого LSR на пути есть привязка от IGP next-hop. Достаточно одного разрыва, чтобы LSP сломался. По RFC 5036 LSR ищет FEC по точному совпадению с записью RIB. Поэтому суммирование loopback-ов на ABR/ASBR ломает LSP: egress рекламирует метку для 10.255.0.2/32, а у транзитных узлов в RIB есть лишь 10.255.0.0/24, точного соответствия нет, метка не используется. Лекарство - не суммировать loopback-адреса PE либо, где поддерживается, включить longest-match (на Junos longest-match в protocols ldp).

Что значит No Label и Pop Label

Для egress-FEC в Cisco show mpls forwarding-table показывает Outgoing Label Pop Label у предпоследнего узла: это PHP, у него в LIB от egress пришла метка imp-null. Значение No Label означает, что для префикса нет метки от IGP next-hop: пакет уходит в IP без метки. Для обычного IP-трафика это незаметно, а L3VPN-трафик с VPN-меткой снаружи теряется на первом узле без метки, так как P-маршрутизатор не знает клиентских префиксов.

Пример непрерывного LSP на лабораторной топологии

FEC 10.255.0.2/32. PE2 для собственного loopback выдаёт implicit null (3). P1 выбирает локальную метку (например, 18), в LFIB: in 18 -> pop -> PE2. PE1 получает от P1 метку 18 и выбирает локальную 21; в LFIB PE1: ingress, push 18 на интерфейс к P1. Для пакета PE1 -> PE2 в ядре идёт единственная метка 18, в PE2 пакет приходит без транспортной метки. Конкретные номера зависят от порядка выделения и версии ПО, а структура всегда такая: egress - implicit null, транзит - swap или pop, ingress - push.

Контроль набора FEC

По умолчанию IOS-XE выделяет метки для всех IGP-префиксов, Junos - только для loopback и тех префиксов, что разрешены egress-policy, Huawei - для host-маршрутов (lsp-trigger по умолчанию host). Ограничение по prefix-list (Cisco: mpls ldp label allocate global prefix-list; Huawei: lsp-trigger ip-prefix; Junos: egress-policy) уменьшает LFIB и атаку на меткообмен. Но каждый BGP next-hop и RR-адрес, для которого нужна метка, должен остаться в списке: иначе ingress не построит LSP и L3VPN-трафик пропадёт.