Кратко

  • Route Target Constraints превращает импортный интерес PE в состояние раскрытия для конкретного соседа: membership NLRI идёт к источникам, а совпавшая VPN-достижимость возвращается в обратном направлении.
  • Приёмка join, leave или миграции требует подтверждения AFI 1/SAFI 132, точной membership, ограниченной синхронизации, различий Adj-RIB-Out, независимой политики безопасности, а также VRF, меток, FIB и пакетов.

Окно включения подходит к концу. На принимающем PE создан VRF, его import RT совпадает с ожидаемым атрибутом маршрута. Исходный PE уже анонсирует VPN-префикс. На RR нет перегрузки, все соседства зелёные. Но в VPN RIB получателя префикса нет.

Причина может находиться не по ходу маршрута, а навстречу ему. Принимающий PE ещё не создал нужную RT Membership NLRI, либо RR не сохранил необходимое направление спроса. Тогда фильтр для этого соседа не разрешает включить маршрут в VPN Adj-RIB-Out. Источник исправен, но граф не знает, кому раскрывать достижимость.

Так устроен RTC, или RT-Constrain, определённый в RFC 4684. При плотной схеме RR рассылает широкий набор VPN-маршрутов, а PE отбрасывают то, что не импортирует ни один локальный VRF. RTC позволяет получателю объявить интерес, после чего RR строит фильтр по соседу и возвращает только совпавшие NLRI.

При разреженной membership сокращаются память, обработка и объём обновлений. Одновременно появляется отдельная плоскость доказательств: наличие маршрута у источника не означает, что конкретный получатель должен был видеть его в текущей конфигурации раскрытия.

Route Target даёт право на рассмотрение, а не результат

RFC 4364 разделяет Route Distinguisher и Route Target. RD делает потенциально пересекающиеся VPN-префиксы уникальными для BGP. RT — extended community, которая связывает экспорт маршрутов и импорт в VRF.

Совпадение хотя бы одного RT маршрута с import RT VRF делает маршрут подходящим для импорта. Это не установка. Ещё действуют выбор BGP, локальная политика, процессы PE/CE, рекурсия next hop и метки, запись в RIB и программирование FIB.

RTC не меняет эту границу. Membership описывает интерес к распространению, а не личность клиента. Она не создаёт VRF, не удостоверяет право использовать RT, не проверяет VPN-маршрут и не доказывает доставку пакетов.

Поэтому отсутствие маршрута имеет разные источники: его не создал источник; не получил RR; отсутствует RTC membership; reflection потерял один из путей спроса; производный фильтр устарел; маршрут не попал в Adj-RIB-Out; PE отклонил импорт или выбор; не разрешились next hop и метка; FIB или данные не сработали. Надо найти первую границу без ожидаемого состояния.

Спрос и достижимость идут в противоположные стороны

Главный объект RFC 4684 — обратный граф распространения. Получатель анонсирует интерес системам, которые держат или распространяют VPN-маршруты. Совпавшие маршруты затем идут к получателю. Membership — не удалённая команда, а BGP-объект, на который влияют выбор, политика и route reflection.

Она передаётся в MP_REACH_NLRI либо MP_UNREACH_NLRI из RFC 4760 с AFI 1 и SAFI 132. Кроме default membership, ключ содержит четырёхоктетный origin AS и восьмиоктетный Route Target в префиксе длиной от 32 до 96 бит. Более короткий префикс выражает широкий интерес, но расширяет состояние и периметр раскрытия.

Префикс нулевой длины — default RT membership. Он означает готовность получать все релевантные VPN-анонсы в отношениях с этим соседом. Это не IP default route, не default VRF, не универсальный клиент и не команда установить все маршруты.

RR по своей роли может нуждаться в плотном наборе, а смешанное внедрение — в совместимости с соседями без RTC. Но default membership остаётся явным исключением: она уменьшает селективность, увеличивает стоимость сходимости и расширяет видимость информации.

Capability подтверждает канал, но не содержание

Обе стороны должны согласовать AFI 1/SAFI 132 в BGP OPEN. Это доказывает возможность обмена семейством. Оно не доказывает появление, получение или выбор конкретной membership NLRI и не подтверждает производный VPN-фильтр.

Наличие rtfilter или family route-target в конфигурации также показывает намерение, а не результат. Минимальный набор включает capability с обеих сторон, точный UPDATE, полученную RTC RIB, все важные пути membership, результат политики и фактический фильтр для каждого VPN Adj-RIB-Out.

Материал Cisco о Route Target Constraint показывает, как конкретное семейство продуктов превращает import RT из VRF в rtfilter и производные фильтры RR. Справочник Juniper по family route-target описывает то же направление: PE сообщает интерес, RR отдаёт совпавшие маршруты.

Команды и defaults непереносимы между продуктами. bgp default route-target filter Cisco и Juniper Route Target Filtering документируют локальные средства. Их конфигурация сама по себе не доказывает обмен RFC 4684.

Один обычный best path не представляет всех подписчиков

Несколько PE в одной AS способны создать одинаковый {origin AS, Route Target}. Если RR использует только обычный лучший iBGP-путь, направления спроса от других клиентов могут исчезнуть, хотя каждому нужны совпавшие VPN-маршруты.

Поэтому RFC 4684 требует учитывать все доступные iBGP-пути данного RT-префикса при построении выходного фильтра и отдельно регулирует анонс локально созданной membership. Это опирается на корректную топологию reflection из RFC 4456, но не сводится к обычному best-path.

Это и не ADD-PATH для VPN-достижимости. Задача — сохранить все направления спроса, а не передать получателю несколько альтернатив маршрута. Фраза «RT есть в таблице» ничего не говорит о PE-источниках интереса, сохранённых путях, peer-фильтрах и итоговом VPN Adj-RIB-Out.

Join и leave изменяют живой граф

После анонса или withdrawal membership отправитель должен пересчитать VPN RIB-OUT и минимальным набором сообщений перейти из старого состояния в новое. Commit VRF не завершает join, а удаление RT из конфигурации не завершает leave.

Для join последовательно подтверждают одобренный import, создание membership, её приём и reflection, расширение peer-фильтра, появление в Adj-RIB-Out, приём на PE, импорт в VRF, next hop, метку, FIB и пакеты.

Для leave сначала доказывают, что RT больше не нужен ни одному локальному VRF. Маршрут, совпадающий с другим активным RT, должен остаться. Один маршрут может нести несколько RT, один VRF — импортировать несколько значений, поэтому общий счётчик способен скрыть одновременно пропажу и утечку. Сравнивать нужно точные идентификаторы и атрибуты.

EoR ограничивает начальное ожидание

RFC 4684 рекомендует End-of-RIB для RTC даже без Graceful Restart. RR может дождаться начального membership-набора, прежде чем выпускать VPN-анонсы, чтобы не принять неполный спрос за окончательный.

Ожидание обязано иметь предел; заданный default равен 60 секундам. Это не универсальный SLO, а защита от бессрочной остановки из-за оптимизации. В доказательство входят реальный таймер, время EoR и поведение после истечения.

RTC UPDATE и Route Refresh различаются. Первый меняет текущий интерес, второй просит заново объявить экспортное состояние. RFC 5291 описывает ORF как типизированные записи в ROUTE-REFRESH. RFC 7543 показывает, как Covering Prefix ORF может инициировать RTC membership ради недостающих VPN-маршрутов; обычный RTC от этого механизма не зависит.

Селективное раскрытие не является границей безопасности

RFC 4684 прямо говорит, что выходные фильтры из RT membership не предназначены для безопасности. Между административными доменами нужны независимые входные и выходные фильтры NLRI, а также ограничения на саму membership.

Membership — BGP-утверждение соседа. Она не аутентифицирует клиента, не подтверждает договор, не разрешает любой RT, не валидирует VPN-маршрут и сама не ограничивает data plane. Если сосед расширит интерес, а отправитель примет его за разрешение, расширится и раскрытие.

Независимые меры включают утверждённые пространства RT, роли peers, преобразование на границах, входную политику membership, выходную политику VPN NLRI, лимиты состояния, журналирование и rollback. RTC делает распределение внутри этих правил эффективнее, но не заменяет их.

Доказательство проходит оба направления

Модель Adj-RIB-In, Loc-RIB и Adj-RIB-Out из RFC 4271 не позволяет одной таблице изображать весь процесс. Для RTC её применяют к семействам membership и VPN.

Начинают на получателе: одобренные VRF и import RT, capability, membership UPDATE, политика и все нужные iBGP-пути. На RR сохраняют RTC RIB и peer-фильтр. Затем идут в направлении VPN-маршрута: источник, RR Loc-RIB, целевой Adj-RIB-Out, VPN RIB получателя.

Завершают импортом, выбором, меткой, next hop, FIB и положительными и отрицательными packet-canary. Ту же цепочку повторяют при withdrawal, миграции RR и upgrade, подтверждая исчезновение старого графа.

Источники