Кратко

  • В примере из индивидуального проекта IETF от 27 октября PE1 получает четыре маршрута с одним префиксом P1. Он выбирает маршрут из RD22 для VPN11. В запись BMP попадает RD11, то есть принимающий экземпляр, а RD22 как источник выбранного маршрута исчезает.
  • Редакция 02 предлагает передавать удалённую идентичность VRF и для маршрутов EVPN Type-5. Отправитель может пропустить новое поле, коллектор может его не читать. Оператору придётся самому решить, можно ли контролировать межэкземплярный импорт без имени источника.

Четыре претендента на один P1

Авторы проекта строят сеть, в которой PE2 предлагает префикс P1 из трёх VPN-экземпляров — RD21, RD22 и RD23. PE3 предлагает ещё один вариант из RD31. У всех есть route target, позволяющий VPN11 на PE1 рассматривать импорт. PE1 выбирает RD22. Сервер BMP получает затем отчёт о выбранном маршруте в локальной таблице VPN11: P1, следующий узел, RD11. Отчёт указывает ящик, куда положили маршрут, и не называет ящик, из которого его взяли.

В проекте нет сообщения о реальной утечке. Есть точная демонстрация того, как полнота интерфейса обманывает взгляд. Мониторинг честно показывает P1 в VPN11. Но из той же записи нельзя узнать, выбрал PE1 источник RD21 или RD22. Оба находятся за PE2, поэтому следующий узел не помогает. Момент решения присутствовал на маршрутизаторе; его происхождение не доехало до наблюдателя.

Реестр IETF называет документ активным индивидуальным Internet-Draft. Это предложение по формату, а не утверждённый RFC и не статистика внедрений. Управленческий вопрос оно ставит вполне зрелый: кто разрешает назвать наблюдение за пересечением VRF достаточным, если наблюдатель знает только место прибытия?

Локальная таблица показывает победителя, но не его родословную

RFC 9069 дал BMP возможность передавать Loc-RIB — маршруты, выбранные локальным процессом BGP. Коллектору удобно получать готовый выбор вместо пересчёта всех входящих объявлений. Однако заголовок для VPN-маршрута описывает локальный экземпляр: адрес пира заполнен нулями, а peer distinguisher соответствует таблице, о которой идёт отчёт. В примере это RD11. Он обозначает VPN11 и ничего не сообщает о RD22.

PE1 получил кандидатов и сделал выбор. Потеря сведений происходит в экспортируемом наблюдении, а не обязательно в памяти устройства. Поэтому вопрос к оператору следует формулировать точно. Если надо проверить, что импорт между VRF шёл из разрешённого источника, карточка «P1 есть в VPN11» недостаточна. Требуется назвать удалённый экземпляр выбранного маршрута.

Проект предлагает Remote VRF Information TLV: семейство адресов, удалённый идентификатор BGP и удалённый route distinguisher. Одна запись сможет содержать RD11 как место приёма и RD22 как источник. Отдельные необязательные поля могут переносить MPLS-метку или SRv6 SID удалённого VPN-маршрута. Это полезные сведения о его обработке, но они не заменяют идентичность исходного экземпляра.

Разрешающий route target и политика импорта задают границу, через которую проходят объявления. Для контроля границы недостаточно увидеть результат в целевой таблице. Источник может смениться с RD22 на RD21 при неизменных P1 и VPN11. Экран продолжит показывать ровную зелёную строку. Строка не ложная; из неё просто выбросили различие, ради которого контроль и существовал.

В EVPN счёт есть, а адресата расследования нет

Предыдущая редакция 01 описывала случай VPN. Редакция 02 добавила EVPN Type-5: P1 из EVI21 на PE2 импортируется через IRB в EVI11 на PE1. Обычная запись BMP показывает P1 в EVI11 и PE2 как следующий узел, но не EVI21. Предложенное поле способно нести AFI 25, SAFI 70, удалённый BGP ID и RD21.

Авторы сопоставляют идею с другим проектом о статистике BMP для EVPN. Счётчик по EVI поможет заметить объём межэкземплярного переноса. Из счётчика невозможно извлечь ответ, какой именно EVI дал конкретный P1. Число подсказывает, куда смотреть; идентификатор источника помогает восстановить цепочку одного решения.

И эта цепочка пока относится к выбору BGP. Loc-RIB не подтверждает установку маршрута в таблице пересылки, прохождение пакета или изменение работы сервиса. Новое поле улучшает атрибуцию выбранного маршрута. Реальный эффект требует иных наблюдений. Приписать этому полю доказательство доставки было бы ещё одной подменой вопроса.

Два законных способа выбросить нужное поле

Устройство BMP, поддерживающее расширение, может приложить TLV с удалённой VRF. Коллектор может его проигнорировать, оставаясь совместимым с RFC 9069. Номера типов в разделе IANA пока не назначены. От публикации проекта RD22 не появляется автоматически ни в потоке, ни в хранилище, ни в сигнализации.

Раздел безопасности требует устанавливать сеансы только с авторизованными и доверенными устройствами мониторинга. Он определяет, кому можно передать данные. Он не решает за оператора, хранить ли имя удалённого экземпляра, как показывать его отсутствие и кто вправе принять такой пробел. Зелёный индикатор живого сеанса не является доказательством сохранённой родословной маршрута.

Sources