Кратко

  • D-PATH — определённый RFC 10039 необязательный транзитивный атрибут BGP с кодом 36, который переносит последовательности DOMAIN-ID в настроенных сценариях стыка EVPN/IPVPN.
  • Собственный идентификатор в полученной последовательности выявляет доменную петлю, а после Local Preference более короткий D-PATH может получить преимущество; аутентификации доменов при этом нет.
  • Для эксплуатационного вывода нужны четыре независимые проверки: настройка идентичности, сохранение атрибутов, реализация в RIB/FIB и двусторонняя доставка в контексте арендатора.

Красивый маршрут и чёрная дыра

На границе домена C появляется VPN-маршрут с последовательностью A, B. Собственного DOMAIN-ID в ней нет, следовательно, доменная петля не обнаружена. Маршрут проходит политику и становится лучшим. Через несколько минут клиент сообщает, что сеть назначения недоступна.

Обе картины совместимы. D-PATH описывает декларацию управляющей плоскости. Пакету ещё предстоит пройти программирование FIB, разрешение next hop, инкапсуляцию и политики конкретного арендатора. Новый атрибут уменьшает неопределённость на одном участке цепи, но не получает власть над остальными.

Что именно считается доменом

Сегмент D-PATH содержит тип семейства сервиса и список DOMAIN-ID. При передаче маршрута в следующий домен шлюз добавляет идентификатор представляемого им домена. Все шлюзы одного домена должны использовать одинаковое значение, а разные домены шлюзов — разные значения.

Значение при этом непрозрачно и назначается административно. Протокол не выясняет принадлежность устройств и не координирует идентификаторы между организациями. Если при миграции половина шлюзов получит новый ID, один домен станет выглядеть как два. Если независимые домены выберут одинаковое значение, корректный маршрут может показаться петлёй.

Поэтому первичный источник истины — инвентаризация и фактически загруженная конфигурация. D-PATH показывает последствия этой конфигурации в обновлении, но не подтверждает, что исходное распределение было верным.

Атрибут может пройти транзитом, но это не подпись

Статус optional transitive позволяет перенести D-PATH через BGP-узел, который не понимает его семантику. Это полезно для совместимости, однако не защищает последовательность от удаления политикой, ошибочного кодирования или иной обработки реализацией.

Ожидание также зависит от модели стыка. При No Propagate атрибут не передаётся в соседний домен. При Uniform Model доменная история сохраняется и дополняется. Отсутствие D-PATH является неисправностью только там, где конфигурация требует его сохранения. Наличие же не гарантирует, что вместе с ним уцелели route targets, метки, VNI и другие данные сервиса.

Для некорректно сформированного атрибута применяется treat-as-withdraw. Такое поведение изолирует плохое обновление, но ошибка совместимости может вызвать массовое исчезновение маршрутов. Во время обновления ПО важно считать withdraw и сравнивать реальные обновления по обе стороны границы.

Короткий список не равен короткой сети

Длина D-PATH участвует в выборе после Local Preference. Если предшествующие условия равны, предпочтителен маршрут с меньшим числом DOMAIN-ID. Отсутствующий D-PATH считается нулевой длиной на этом этапе.

Это число не измеряет задержку, километры, загрузку или доверие. Политика с более высоким Local Preference может сознательно выбрать более длинную последовательность. Выигравший маршрут, в свою очередь, способен остаться только в RIB, не попасть в FIB, получить неразрешённый next hop или неверную метку.

Следовательно, журнал выбора объясняет решение BGP, а не качество услуги. Соединять их в один зелёный индикатор значит скрывать как раз тот разрыв, в котором возникают многие инциденты.

Четыре проверки вместо одной галочки

Первая проверка сопоставляет DOMAIN-ID всех шлюзов с реестром доменов и изменениями. Требуются одинаковые значения внутри домена и отсутствие коллизий между доменами.

Вторая сравнивает входящие и исходящие BGP-обновления на каждой границе. Вместе с D-PATH проверяются тип семейства и остальные VPN-атрибуты. Так можно указать точное место потери информации.

Третья прослеживает маршрут от приёма и выбора в RIB до записи в FIB. На пересылающем устройстве проверяются next hop, метка, VNI и состояние туннеля.

Четвёртая запускает двусторонний тест из VRF арендатора или равнозначного изолированного контекста. Проверка из управляющей сети не воспроизводит его политику и обратный путь. Только этот этап непосредственно подтверждает доставку.