Кратко

  • Роли BGP позволяют соседним сетям сопоставить ожидания «провайдер», «клиент», «пир» и «сервер маршрутов» до обмена объявлениями; подтверждённое несовпадение может не допустить сессию eBGP.
  • OTC переносит границу распространения вместе с маршрутом, но не удостоверяет коммерческий договор, не заменяет явные политики и не описывает сложные отношения, меняющиеся по префиксам.

Анализ

Утечка маршрута не обязательно означает ложный источник. RFC 7908 определяет её как распространение изученного объявления BGP за пределы задуманной области. Маршрут может вести к правильной цели, но перейти от одного провайдера к другому или от пира к провайдеру в направлении, которого отношения не разрешали. Ошибка находится в цепочке передач.

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

RFC 9234 добавляет проверку до обмена маршрутами. Сообщение BGP OPEN может нести Role Capability. Нормальные роли — Provider, Customer, Route Server, Route Server Client и Peer. Если роли объявляют обе стороны, пара должна быть допустимой: Provider с Customer, Route Server с Route Server Client, Peer с Peer. Иначе соединение отклоняется уведомлением Role Mismatch.

Это проверка согласованности протокола, а не коммерческий арбитр. Маршрутизатор не читает договор транзита, счёт или обязательства по трафику. Сети могут настроить совместимые, но неверные роли. Отношение может различаться по префиксу, услуге или региону. RFC называет его сложным и запрещает одну роль на такой сессии. Если связь нельзя разделить на нормальные сессии, по-прежнему нужна политика по префиксам.

Второй механизм работает с UPDATE. Only to Customer, или OTC, — необязательный транзитивный атрибут пути с кодом 35. Его четырёхоктетное значение содержит номер автономной системы. После передачи маршрута клиенту, пиру или клиенту сервера маршрутов OTC указывает, что далее маршрут должен идти только к клиентам.

Маршрут с OTC, полученный от клиента или клиента сервера маршрутов, считается утечкой и становится непригодным. Определённое RFC несоответствие при получении от пира даёт тот же результат. При экспорте маршрут с OTC нельзя отправлять провайдерам, пирам и серверам маршрутов. Так сигнал способен предотвратить локальную утечку и обнаружить её через несколько переходов.

Частичное внедрение тоже полезно. Если маршрут от провайдера, пира или сервера маршрутов пришёл без OTC, совместимый получатель может добавить атрибут. RFC называет это преимуществом для ранних пользователей. Но OTC не защищён криптографически: промежуточная AS может его удалить, а ошибочная метка — ограничить законную доступность.

Совместимость требует ещё одного решения. Если роль объявляет только один сосед, обычное поведение — продолжить с локально настроенной ролью. Строгий режим может отклонить молчащего соседа. RFC 9234 не рекомендует делать его стандартным: после обновления ПО eBGP-сессия может перестать устанавливаться.

Основой остаётся RFC 8212: без явной политики маршруты eBGP не следует импортировать или экспортировать. Роли и OTC не проверяют источник, не делают широкую политику безопасной и не заменяют фильтры префиксов и путей. Реестр IANA подтверждает только коды в протоколе — атрибут 35 и подкод 11, — но не внедрение в конкретной сети или версии продукта.

Источники