Теоретические основы и архитектура
Лабораторная работа: локализация аварий (Troubleshooting & Fault Isolation) в ядре MPLS L3VPN. Метод: проверка по слоям снизу вверх - физика и ошибки интерфейса, IGP и loopback, LDP и привязки, LFIB/CEF и MTU, MP-BGP и vpnv4, Route Target и импорт в VRF, таблица VRF и стык PE-CE; пока нижний слой не подтверждён доказательством (вывод команды, код ответа), верхний не диагностируют. На каждом слое различают control plane («знает ли узел маршрут и метку?») и data plane («пересылает ли он по ним?»: LFIB, ping mpls, traceroute mpls). Лаборатория разбирает три типовых отказа: 1. LDP отключён на одном интерфейсе: IGP и BGP живы, но loopback соседа в таблице меток помечен Untagged/No Label, и VPN-пакет пропадает на P. 2. Изменён import Route Target: LSP и сессии в порядке, но VRF не импортирует маршруты; решает сравнение RT в show vrf detail и в vpnv4-таблице. 3. Занижен MTU: каждая метка добавляет 4 байта, у пакета L3VPN их две, поэтому 1500-байтный IP-пакет требует 1508 байт в ядре; малые пинги проходят, а ping vrf ... size 1500 df-bit нет.
Метод: по слоям и от нижнего к верхнему
Отказ в MPLS-VPN проявляется одинаково ("пинг клиента не проходит"), а причин может быть десяток на разных уровнях. Метод изоляции делит путь на слои и проверяет каждый, начиная с нижнего, пока не найдёт первый неисправный: физический линк и ошибки интерфейса, соседство IGP и достижимость loopback, сессия LDP и привязки (LIB), запрограммированная таблица пересылки (LFIB/CEF) и MTU, сессия MP-BGP и VPNv4-маршруты, Route Target и импорт в VRF, таблица VRF и стык PE-CE, наконец клиентская сеть. Правило: пока нижний слой не подтверждён, верхний не диагностируют, потому что его симптомы могут быть следствием. На каждом слое нужно доказательство, а не предположение: вывод команды, число, код ответа.
Control plane и data plane: два вида вопроса
На каждом слое задают два разных вопроса. Control plane: "знает ли узел маршрут и привязку?" (show ip route, show mpls ldp bindings, show bgp vpnv4 unicast all). Data plane: "пересылает ли узел пакет по этому знанию?" (show mpls forwarding-table detail, show ip cef detail, ping mpls). Типичная ловушка - привязка есть в LIB, а в LFIB запись помечена No Label или Untagged, либо LFIB верна, но аппаратная таблица запрограммирована неправильно. Поэтому для диагностики сочетают оба вида проверок: LSP ping/traceroute и BFD из предыдущих уроков показывают состояние data plane, а таблицы - control plane.
Что показывают инструменты (карта слоёв)
Слой IGP: ping loopback-к-loopback с source, show ip ospf neighbor, состояние BFD. Слой LDP: show mpls ldp neighbor (сессия Operational, адрес транспорта - loopback), show mpls ldp discovery (hello приходят на нужные интерфейсы), show mpls ldp bindings 10.255.0.2 32 (привязка получена от next-hop). Слой LFIB: show mpls forwarding-table 10.255.0.2 32 detail (исходящая метка, интерфейс, next-hop), traceroute mpls (MRU и метки по hop-ам). Слой MP-BGP: show bgp vpnv4 unicast all summary (сессия Established, число префиксов). Слой VRF: show vrf detail A (RD, import/export RT), show ip route vrf A, show ip cef vrf A <prefix> detail (стек из двух меток: транспортная и VPN).
Три типовых отказа и признаки
Отключили LDP на одном интерфейсе. IGP-соседство и BGP-сессия до RR остаются Up, потому что идут как IP; в таблице меток префикс loopback соседа отображается как Untagged/No Label. VPN-пакет получает только VPN-метку и уходит на P, у которого нет привязки для транспортной метки, поэтому он отбрасывается. Ожидаемые признаки: show mpls ldp neighbor без соседа, ping mpls с кодом Q или N, ping vrf A теряется при том, что IGP-ping проходит. Решающее доказательство - show mpls forwarding-table <loopback PE2> detail.
Изменили import RT. Транспорт работает: LSP ping успешен, LDP и BGP в порядке. Но VRF не импортирует маршруты: на PE узел не сохраняет VPNv4-маршруты, RT которых не совпадает ни с одним импортом, поэтому искомого префикса нет в show ip route vrf A, а show bgp vpnv4 unicast all его не показывает. Диагностика: сравнить import RT в show vrf detail A на PE1 с RT, который экспортирует PE2 (виден на RR командой show bgp vpnv4 unicast rd <rd> <prefix> в поле Extended Community). Симптом "LSP исправен, а маршрута нет" однозначно указывает на слой политик VPN.
Уменьшили MTU. Малые пакеты проходят, крупные теряются: каждая метка добавляет 4 байта, у клиентского пакета в L3VPN их две (транспортная и VPN), то есть 1500-байтный IP-пакет требует в ядре 1508 байт. Если MTU линка равен 1500, пакет фрагментируется (при DF=0) или отбрасывается (при DF=1). Признаки: ping vrf A <dst> size 1500 df-bit не проходит, а size 1400 проходит; ping mpls с размером по умолчанию успешен, потому что эхо маленький; в traceroute mpls виден заниженный MRU на конкретном hop. Если ICMP "fragmentation needed" фильтруется, получаем MTU black hole: TCP-сессии "зависают" после рукопожатия. Исправление: увеличить MTU (или mpls mtu) на всех линках ядра минимум до 1508-1520, либо настроить tcp adjust-mss на PE как временную меру.
Хронология и события
Журнал и уведомления дают порядок событий, а порядок указывает на причину: если сначала упал BFD, затем OSPF, затем LDP и только потом BGP, причина лежит на нижнем уровне; если упала только сессия LDP без IGP, виновата конфигурация или MTU на LDP-уровне (hello идут, TCP-сессия 646 с крупными сообщениями не устанавливается). Типичный признак MTU-проблемы LDP/BGP: соседство поднимается, но на обмене большими обновлениями (Keepalive и Update) сессия падает. Всегда спрашивайте "что менялось": сравнивайте текущую конфигурацию с эталоном (baseline), сохранённым до инцидента.
Дисциплина проверки
Перед тестами фиксируют эталон здоровой сети: вывод show mpls forwarding-table, MRU в LSP traceroute, время RTT LSP ping, счётчики BFD. Затем вносят одно изменение, собирают минимальный набор команд, формулируют гипотезу слоя, подтверждают и возвращают состояние. Одновременное изменение нескольких параметров делает выводы недостоверными. Отсутствие ответа на OAM не доказывает разрыв: ответ может быть потерян на обратном пути или отфильтрован, поэтому требуется независимое подтверждение другим способом (таблица LFIB, счётчики интерфейса, traceroute mpls). И наоборот, успешный ping не доказывает исправность сервиса: он проверяет путь, но не RT и не MTU клиентского пакета.
Схема архитектуры и топология
+-----------+ Broken Core Link / Label Mismatch +-----------+
| PE-1 | =====================X========================> | PE-2 |
| Diagnostics: LSP Ping, Traceroute, LFIB Inspection | Egress |
| Isolates: MTU Black Hole, LDP Sync Mismatch, Broken Binding | Target |
+-----------+ +-----------+Схема прохождения трафика и стек меток
Systematic MPLS Troubleshooting Pipeline:
1. Verify Control Plane: Are IGP adjacencies UP? Is LDP session Operational? Is BGP VPNv4 established?
2. Verify Label Bindings: Does local LIB have a binding for the destination FEC?
3. Verify Data Plane (LFIB): Does incoming label map to correct outgoing label and interface?
4. Run LSP Ping / Traceroute: Is packet dropped due to MTU mismatch or unprogrammed penultimate hop?
5. Remediate: Fix LDP-IGP sync, MTU mismatch, or VRF Route Target policy.