Отклонение RPKI-Недопустимых (Invalid) Маршрутов BGP / Habr

Отклонить RPKI-недопустимые (invalid) маршруты BGP

Назначение

Полноценный фильтр для любой конфигурации BGP (Border Gateway Protocol) должен отклонить RPKI (Resource Public Key Infrastructure)-недопустимые (invalid) маршруты BGP.

При этом определяется, является ли маршрут RPKI недопустимым (invalid) или нет, в соответствии с RFC 6811 и RFC 8893.

Считается небезопасным манипулировать атрибутами пути (Path Attributes) BGP (например, LOCAL_PREF или COMMUNITY) на основе состояния проверки происхождения (Origin Validation state) RPKI. Сделать атрибуты пути BGP зависимыми от состояний проверки RPKI означает привнести излишнюю хрупкость в глобальную систему маршрутизации, как это объяснено здесь. Кроме того, использование RFC 8097 НАСТОЯТЕЛЬНО НЕ РЕКОМЕНДУЕТСЯ. RFC 8097 стал причиной проблем для операторов сетей с несколькими поставщиками.

В проекте документации RPKI перечислены различные программные пакеты Relaying Party.

Примеры конфигурации

Настройка протокола OpenBSD с пакетом OpenBGPD

Это пример того, как сделать Проверку Происхождения (Origin Validation) без протокола RPKI-To-Router. Убедитесь, что запись в корневом каталоге crontab (cron table) rpki-client включена и запускается каждый час.

Импортируйте сгенерированную конфигурацию rpki-client и укажите bgpd отклонить недействительные (invalid) RPKI маршруты.

НАСТОЯТЕЛЬНО НЕ рекомендуется устанавливать или изменять атрибуты пути BGP на основе состояния проверки происхождения (ключевое слово: ovs).

Junos

Настройка RTR

Укажите маршрутизатору, чтобы он отклонял недопустимые маршруты RPKI, а также отмечал не найденные (not-found) и действующие (valid) маршруты в нетранзитивном (non-transitive) состоянии. Примечание: Сообщества BGP или другие атрибуты пути BGP НЕ ДОЛЖНЫ быть изменены на основе проверки состояния!

Классическая Cisco IOS и IOS XE

Во всех релизах IOS и IOS-XE, Проверка происхождения маршрута (Route Origin Validation) будет вмешиваться в выбор наилучшего пути BGP, что приведет к зацикливанию маршрута. Вы должны использовать команду bgp bestpath prefix-validate disable, чтобы отключить интегрированную проверку происхождения маршрута и вместо неё выполнить это вручную в карте маршрута:

Соответствие и запрет на основе состояния валидации RPKI.

Альтернативным и настоятельно рекомендуемым способом избежать этих циклов маршрутизации является использование сигнализирования IBGP (send-community extended и announce rpki state соседских конфигураций). Это приведет к ненужной нагрузке на уровень управления и взаимозависимостям.

Входящие команды soft-refiguration inbound должны быть включены во время сеансов EBGP, чтобы избежать периодических обновлений маршрутизатора BGP Router (при обновлении VRP-таблиц).

Cisco IOS-XR

Примечание: ЗАПРЕЩАЕТСЯ конфигурировать bgp origin-as validation signal ibgp (см. выше примечание о RFC8097). Включение сигнала подтверждения вызывает ненужную "трескотню" протокола BGP в системе маршрутизации.

Настройте RTR и включите RPKI для каждого семейства адресов.

Соответствие и запрет на основе состояния валидации RPKI.

При необходимости используйте правила формируя их в виде цепочек.

Не забудьте включить функцию soft-reffiguration inbound always для каждого соседа EBGP для каждого семейства адресов! Плохо, что это не происходит по умолчанию.

BIRD

BIRD 2.0 поддерживает RTR. Однако текущая имплементация не производит автоматической перепроверки маршрутов при получении новых ROA (Route Origin Authorisation).

Протокол RPKI-RTR получает и поддерживает набор ROA с кэш-сервера (также называемого валидатором). Протокол RPKI-RTR получает и поддерживает набор ROA с кэш-сервера (также называемого валидатором). Вы можете проверять маршруты (RFC 6483) с помощью функции roa_check() в фильтре и устанавливать её в качестве фильтра импорта в протоколе BGP. BIRD должен повторно проверять все затронутые маршруты после обновления RPKI в RFC 6811, но мы это обновление пока что не поддерживаем! Для ручного вызова повторной проверки всех маршрутов можно использовать клиентскую команду BIRD reload in bgp_protocol_name. (https://bird.network.cz/?get_doc&v=20&f=bird-6.html#ss6.13)

Утилита rtrsub может быть использована для генерации статических ROA-таблиц для BIRD 1.6.

Настройте RTR следующим образом:

Определите функцию, которая при неверном RPKI-маршруте BGP возвратит false.

Замечание: НИКОГДА НЕ храните состояние валидации внутри переменных bgp_community или bgp_large_community или bgp_ext_community. Это может привести к перегрузке процессора и памяти, в результате чего могут возникнуть проблемы с эффективностью процесса конвергенции.

Nokia SR OS

Валидатор RPKI можно настроить через:

Базовый объект маршрутизации (пример ниже)
Объект управления маршрутизацией на Ethernet-порту OOB.

Настройте RTR в соответствии с RPKI валидатором(ами)

Классическая конфигурация CLI:

MD-CLI конфигурация:

Удалить неправильные префиксы

Удаление неправильных префиксов может быть сделано с помощью использования правил маршрутизации или в конфигурации BGP.

Классическая конфигурация правил маршрутизации CLI:

Настройка правил маршрутизации MD-CLI:

Классическая конфигурация CLI BGP (определенная для группы или соседа):

Конфигурация MD-CLI BGP (определенная для группы или соседа):

Проверка происхождения в объекте VPRN требует наличия SR OS 19.7.R1 или выше.

Классическая конфигурация CLI VPRN BGP (определенная для группы или соседа):

Конфигурация MD-CLI VPRN BGP (определенная для группы или соседа):

Huawei VRP

Настройте RTR и включите RPKI.

Процесс выбора наилучшего BGP теперь игнорирует маршруты с подтверждением результата Invalid (Недопустимый).

Arista EOS

Настройте RTR на кэш валидатора RPKI:

Сопоставьте правила входа в EBGP и отклоните RPKI-недопустимые маршруты BGP:

Современная IT инфраструктура все больше виртуализируется, уплывая в Облака. Модели «все как сервис» — SaaS, PaaS, IaaS используются повсеместно, но все эти решения по-прежнему используют сети передачи данных и машинные ресурсы для их обработки.
За последние 20 лет сети ЦОД претерпели множество изменений, с которыми попробуем познакомиться ближе на вебинаре «Эволюция сетевых технологий в ЦОД». Также на этом открытом уроке постараемся разобрать основные технологические этапы этой эволюции с присущими им технологиями и архитектурными решениями.
Присоединяйтесь!
Перевод материала был подготовлен в преддверии запуска курса «Дизайн сетей ЦОД».