Кратко

  • Редакция 13 предлагает проверять next-hop reachability в forwarding database выбранной data plane и разрешает OAM-проверку доступности пути в той же плоскости.
  • Успешный probe подтверждает результат конкретного механизма в определённый момент; он не гарантирует все ECMP-члены, FEC, VPN lookup, конечный prefix, обратный путь или приложение.
  • Нужна раздельная цепочка доказательств: локальная резолвимость, eligibility BGP, установка FIB, распространение update, прохождение traffic и подтверждённый service outcome.

Панель показывала зелёный статус: MPLS path available. LSP Ping получил ответ от удалённого PE, next hop оставался кандидатом, а BGP выбрал ожидаемый путь. Клиентский сервис всё равно не работал. В удалённой VRF отсутствовал нужный маршрут, поэтому пакеты доходили до PE и терялись после следующего lookup.

Проверка была успешной. Вывод «VPN работает» — нет.

Такой сценарий показывает границу, важную для draft-ietf-idr-bgp-bestpath-selection-criteria-13. Документ от 14 сентября 2026 года является активным Internet-Draft рабочей группы IDR, предназначенным для Proposed Standard. В случае одобрения он обновит RFC 4271, но сейчас это не RFC. Datatracker указывает на необходимость устранить замечания экспертов и подготовить новую редакцию. Четыре ранних review признают реальную проблему, одновременно считая текст недостаточно готовым.

RFC 4271 требует, чтобы путь был resolvable до участия в Phase 2 decision function. Однако в MPLS-сети наличие IP-route до BGP next hop не означает наличие работающего LSP. Label entry может отсутствовать, binding — быть повреждён, а forwarding на промежуточном узле — не работать. PE продолжает рекламировать reachability и привлекает traffic в blackhole.

Редакция 13 предлагает две поправки. Next hop следует разрешать в forwarding database той data plane, которую выбрала policy. Дополнительно можно выполнить path-availability check через OAM-механизм, связанный с той же plane. Цель — не позволить абстрактной IP-достижимости представлять неисправный MPLS transport.

Это полезное усиление локальной eligibility. Оно не превращает проверку next hop в end-to-end proof.

Что именно увидел положительный probe

Любой OAM-механизм имеет объект и семантику. Он может проверять конкретный LSP, FEC, endpoint, направление или return mode. Ответ означает, что сообщение и reply прошли согласно правилам этого механизма. Он не перечисляет автоматически все пути, которыми могут идти production packets.

При ECMP probe способен выбрать один member, пока другой повреждён. Одна FEC отвечает, другая нет. Control packet получает приоритет или маршрут, отличный от data. Удалённый PE жив, но нужная VRF, label, customer prefix или egress interface отсутствуют. Обратный путь может быть сломан. Приложение может отклонить запрос после успешной доставки сети.

Routing review прямо упоминает false positives: OAM проходит, хотя часть ECMP members или FECs сломана. Operations review подчёркивает, что проверка создаёт новую зависимость, которая сама может ошибаться. Security review добавляет возможность spoofed positive, сохраняющего неисправный путь.

Поэтому интерфейс обязан назвать scope: выбранная data plane, таблица, FEC или endpoint, метод, режим, направление, время, authentication state и срок действия. Без scope слово available заставляет читателя предположить гораздо больше, чем было измерено.

Eligibility — локальное решение, а не свойство мира

Даже первый критерий не даёт глобальной истины. Draft говорит о forwarding database определённой data plane, но не уточняет точную таблицу или VRF. Destination и tunnel endpoint могут разрешаться в разных tables. Policy per-neighbor или per-SAFI способна выбрать разные контексты для одного next hop.

После lookup локальная policy объединяет forwarding state и optional OAM result и решает, допустить ли путь к best-path selection. Нормативный текст не описывает точно, что происходит при failed check, хотя conclusion говорит о продолжении advertisement или withdrawal. Reviews требуют связать последствия с RFC 4271 явно.

Следовательно, eligible означает: «эта реализация при этой версии policy и этих входных данных допустила путь». Это не утверждение, что весь transport исправен. ineligible также не доказывает физическую неисправность: причиной может быть false negative, устаревший результат, неверная таблица или неинициализированная сессия.

Полезна трёхзначная модель. Positive evidence поддерживает eligibility в указанном scope. Negative evidence показывает определённый failed check. Indeterminate фиксирует отсутствие, истечение срока, конфликт или невозможность сопоставить результат с текущей forwarding generation. Локальная policy выбирает действие, но не должна переименовывать неопределённость в факт.

BGP update не доставляет пакет

После изменения eligibility BGP повторно выбирает путь. Router может изменить FIB и отправить update. Neighbor должен его принять и выполнить собственное решение. Только затем traffic может перейти. Каждый переход имеет отдельное время и отдельный отказ.

Withdrawal подтверждает намерение control plane убрать reachability, а не отсутствие traffic. Alternate best path подтверждает выбор, а не installation. Счётчик FIB подтверждает локальные packets, а не удалённую обработку. Application success подтверждает один outcome, но не объясняет автоматически, какой routing event его вызвал.

Доказательная цепочка выглядит так:

  1. BGP получил path и next hop;
  2. policy выбрала plane и конкретную таблицу;
  3. forwarding state был прочитан в известной generation;
  4. OAM дал ограниченный по времени и scope результат;
  5. policy классифицировала eligibility;
  6. decision process выбрал путь;
  7. FIB была установлена;
  8. updates дошли до peers;
  9. независимый traffic test проверил доставку;
  10. приложение подтвердило требуемый результат.

Объединять эти строки в один health flag удобно, но опасно. При сбое оператор не знает, какой переход расследовать. При успехе руководство получает доказательство меньшего объёма, чем предполагает.

Механизм измерения тоже является объектом угрозы

Revision 13 не выбирает BFD или LSP Ping, но reviews используют их как примеры. RFC 5880 описывает ложные состояния up/down и рекомендации по authentication. RFC 8029 рассматривает spoofing, replay и tampering. Даже authenticated exchange можно заблокировать on path; можно также пропустить probes и отбросить data.

Если результат влияет на множество routes одного next hop, атака или сбой измерения масштабируется через BGP. Negative вызывает исключение и, возможно, withdrawals. Spoofed positive удерживает blackhole. Flapping производит route churn. Положительный статус поэтому должен сопровождаться состоянием самого механизма, а не выглядеть неоспоримым фактом.

Service proof начинается после route proof

Безопасный rollout сначала работает в shadow mode. Система вычисляет eligibility, но не меняет best path. Операторы сравнивают результат с forwarding counters, независимыми probes нескольких FEC и реальными application transactions. Они ищут как false negatives, так и false positives.

После ограниченного включения проверяется radius: сколько routes зависят от session, какие VRF и customers затронуты, какой backup существует. Тесты отдельно ломают MPLS forwarding при живом IP route, ломают только OAM, повреждают один ECMP member и удаляют remote-VRF route при рабочем LSP. Каждый сценарий должен давать различимый evidence pattern.

Rollback возвращает известную policy, очищает производные состояния, запускает reevaluation и проверяет FIB, advertisement и application. Отключить probe недостаточно, если последний positive или negative продолжает влиять на eligibility.

Редакция 13 справедливо требует смотреть на data plane, которая действительно понесёт traffic. Её нельзя читать как разрешение считать один data-plane signal доказательством всего сервиса. Хороший контроль расширяет видимость, сохраняя границы каждого наблюдения. Плохой контроль делает локальную квитанцию универсальным обещанием — и обнаруживает ошибку только тогда, когда зелёный экран уже противоречит пользователю.

Источники