BGP источника
Понимание проверки источника для BGP
Проверка источника помогает предотвратить непреднамеренное объявление маршрутов. Иногда сетевые администраторы по ошибке объявляют неуправленные сети маршруты. Эту проблему безопасности можно решить, настроив проверку источника (также известная как защищенная интердоменовая маршрутизация). Проверка источника – это механизм, с помощью которого объявления маршрутов могут аутентификации, исходя из ожидаемой автономной системы (AS). Проверка источника использует один или несколько серверов кэша открытых ресурсов (RPKI) для аутентификации определенных префиксов BGP ресурсов. Для аутентификации префикса маршрутизатор (адресант BGP) запрашивает базу данных проверенных сопоставлений префикса с AS, загружаемых с сервера кэша, и проверяет, что префикс исходит из ожидаемой AS.
При включив аутентификацию RPKI, Junos OS автоматически открывает TCP-порт 2222 без уведомления. Можно применить фильтр для блоки и защиты этого порта.
Junos OS поддерживает проверку источника для префиксов IPv4 и IPv6.
Рис. 1 показывает примерную топологию.
- Поддерживаемые стандарты
- Как работает проверка источника
- BGP взаимодействия с базой данных проверки маршрута
- Атрибут сообщества для того, чтобы объявить состояние проверки RPKI соседям IBGP
- Проверка безостановочной активной маршрутизации и источника
- Маркировка диапазона префиксов как никогда разрешенного
Поддерживаемые стандарты
В Junos OS проверки источника поддерживаются следующие документы РНК и проект:
RFC 6810, ресурсная инфраструктура открытых ключей (RPKI) протокола маршрутизатора
Проверка источника префикса в RFC 6811 BGP,
Интернет-проект проект-ietf-sidr-origin-validation-signaling-00, BGP Префикс Origin Validation State Extended (частичная поддержка)
Расширенное сообщество (состояние проверки источника) поддерживается Junos OS маршрутизации. Указанное изменение в процедуре выбора маршрута не поддерживается.
Как работает проверка источника
RPKI и проверка источника используют сертификаты X.509 с расширениями, указанными в RFC 3779, X.509 Extensions дляIP-адресов и идентификаторов AS.
RPKI состоит из распределенного сбора информации. Каждый орган сертификации опубликовывал сертификаты о конечном объекте (EE), списки отзыва сертификатов (CRLs) и подписанные объекты в определенном местоположении. Все эти хранилища формируют полный набор сведений, доступный каждому серверу кэша RPKI.
Каждый сервер кэша RPKI поддерживает локальный кэш всего распределенного хранилища, регулярно синхронизая каждый элемент локального кэша с исходной точкой публикации репозитория.
На маршрутизаторе записи базы данных отформатированы как записи проверки маршрута (RV) Запись RV является (префикс, максимальная длина, источник AS) тройной. Он соответствует любому маршруту, префикс которого соответствует префиксу RV, длина префикса которого не превышает максимальную длину, заданную в записи RV, и чей источник AS равен as источнику, заданной в записи RV.
Запись RV – упрощенная версия авторизации источника маршрута (ROA). ROA — это объект, подписанный в цифровой формате, который представляет собой средство проверки того, что держатель БЛОКА IP-адресов получил разрешение AS на начало маршрутов к одному или более префиксам в адресном блоке. RoAs не используются напрямую при проверке маршрута. Сервер кэша экспортирует упрощенную версию ROA на маршрутизатор в качестве записи RV.
Максимальное значение длины должно быть больше или равна длине авторизованного префикса и меньше или равна длине (в битах) IP-адреса в семейке адресов (32 для IPv4 и 128 для IPv6). Максимальная длина определяет префикс IP-адреса, который AS имеет право объявлять.
Например, если префикс IP-адреса - 200.4.66/24, а максимальная длина – 26, AS имеет право объявлять 200.4.66.0/24, 200.4.66.0/25, 200.4.66.128/25, 200.4.66.0/26, 200.4.66.64/26, 200.4.66.128/26 и 200.4.66.192/26. При отображении максимальной длины AS имеет право только объявлять префикс, указанный в RV.
В качестве другого примера RV может содержать префикс 200.4.66/24 с максимальной длиной 26, а также префикс 200.4.66.0/28 с максимальной длиной 28. Этот RV разрешает AS объявлять любой префикс, начиная с 200.4.66 с длиной не менее 24 и не более 26, а также конкретный префикс 200.4.66.0/28.
Источник маршрута представлен самым правым номером AS в AS_PATH атрибуте. Проверка источника выполняется путем сравнения исходных AS в обновлении маршрутизации с авторизованным источником AS, опубликованным в записях RV.
Безопасность, предоставленная проверкой источника, как известно, слаба в отношении определенного злоумышленника, поскольку нет защиты против такого атакующего, подменившего исходный AS. Тем не менее, проверка источника обеспечивает полезную защиту от случайных объявлений.
Хотя проверка источника может быть реализована путем непосредственного участия каждого маршрутизатора в RPKI, это будет рассматриваться как слишком интенсивный ресурс (поскольку для проверки данных RPKI требуется множество открытых криптографических операций), а также с интенсивным рабочим процессом для настройки и поддержания конфигурации RPKI на каждом маршрутизаторе. Поэтому отдельный сервер кэша RPKI выполняет проверку открытых ключей и создает проверенную базу данных сопоставлений префикса к AS. Проверенная база данных загружается на клиентский маршрутизатор через защищенное TCP-соединение. Таким образом, маршрутизатору требуется небольшая информация об инфраструктуре RPKI и нет требований криптографии открытого ключа, кроме зашифрованного пароля для транспорта. Затем маршрутизатор использует загруженные данные для проверки полученных обновлений маршрутов.
При настройке серверных сеансов можно сгруппировать сессии вместе и настроить параметры сеанса для каждого сеанса в группе. Маршрутизатор периодически пытается настроить настраиваемое максимальное количество соединений с серверами кэша. В случае неудачной установки соединения периодически попытки подключения.
Тем временем, после того, как политика импорта проверки применяется к сеансу BGP, проверка маршрута выполняется независимо от состояния сеанса кэша (вверх или вниз) и базы данных RV (пустые или не пустые). Если база данных RV пуста или все сеансы сервера кэша не установлены, состояние проверки для каждого маршрута устанавливается неизвестно, поскольку для оценки полученного префикса BGP существует запись RV.
Можно настраивать период повторной попытки. После успешного подключения к кэш-серверу маршрутизатор запрашивает серийный номер последней базы данных и запрашивает, чтобы кэш RPKI транслировал все записи RV, принадлежащие этой версии базы данных.
Каждое входящий сообщение сбрасывает время жизни для сервера кэша RPKI. После того, как все обновления будут обучаемы, маршрутизатор будет выполнять периодические проверки качества работы на основе настраиваемого интервала. Это можно сделать, отправив блок данных протокола последовательного запроса (PDU) с тем же серийным номером, который сервер кэша отчитал в своем последнем уведомлении PDU. Сервер кэша отвечает нулями или более обновлениями и конечными (EOD) PDU данными, которые также обновляют текущее состояние сервера кэша и сбрасывают регистр-срок действия.
При получении префикса от внешнего BGP (EBGP) он рассматривается политикой импорта и маркируется как Valid, Invalid, Unknown или Unverified:
Valid (Действительно) — указывает на то, что префикс и пара AS находятся в базе данных.
Invalid (Недействительный) — указывает на то, что префикс найден, но соответствующая AS, полученная от равноправного узла EBGP, не является AS, отображенной в базе данных, или длина префикса в сообщении обновления BGP больше, чем максимальная длина, разрешенная в базе данных.
Unknown — указывает, что префикс не входит в число префиксов или диапазонов префиксов в базе данных.
Unverified — указывает, что источник префикса не проверен по базе данных. Это вызвано тем, что база данных заполнена и проверка не вызвана в политике BGP импорта, хотя проверка источника включена, или проверка источника не включена для BGP равноправных BGP равноправных пользователей.
Если в базе данных проверки есть потенциальные совпадения для маршрута, маршрут должен соответствовать одному из них, чтобы он был действительным. В противном случае он будет недействительным. Любое совпадение является достаточным для того, чтобы маршрут был действительным. Это не должно быть лучшим совпадением. Маршрут считается неизвестным только в отсутствие потенциальных совпадений. Дополнительные сведения о логике сопоставления префикса с AS базы данных см. в разделе 2 Интернет-проект проект-ietf-sidr-pfx-validate-01, BGPПодтверждение источника префикса.
Проверка RPKI доступна только в основном экземпляре. Если для экземпляра маршрутизации настроена проверка RPKI, то проверка RPKI не удаться со следующим сообщением об RV instance is not running ошибке.
BGP взаимодействия с базой данных проверки маршрута
База данных проверки маршрута (RV) содержит набор записей RV, загружаемых маршрутизатором с сервера кэша RPKI. После заполнения базы данных RV записями RV база данных RV сканирует таблицу маршрутов RIB-Local, чтобы определить, есть ли префиксы в RIB-Local, которые могут быть затронуты записями RV в базе данных. (RIB-Local содержит маршруты IPv4 и IPv6, показанные в выходных данных show route protocol bgp команды.)
Этот процесс запускает BGP политик импорта BGP (а не экспорта политик).
Рис. 2 отображает процесс.
Политики импорта применяются к RIB-in. Другой способ понять, что политики импорта применяются к маршрутам, показанным в выходных данных команды, в то время как политики экспорта применяются к маршрутам, показанным show route receive-protocol bgpshow route advertising-protocol bgp командой.
Как показано в таблице, для контроля того, какие маршруты BGP в таблице маршрутов, и экспорт политик маршрутов используется для управления маршрутами, которые BGP из таблицы маршрутов соседним Рис. 3 маршрутизаторам.
При настройке политики импорта для проверки маршрута конфигурация политики использует validation-database условие совпадения. Это условие совпадения инициирует запрос в базе данных RV о состоянии проверки префикса в данном экземпляре маршрутизации. По умолчанию запрашивается база данных проверки, совпадающая с экземпляром маршрутизации. Если экземпляр проверки маршрута не найден, запрашивается основной экземпляр.
В следующей BGP импорта условие вызывает просмотр в базе данных from validation-database RV маршрутизатора. Если состояние проверки действительно, то происходит действие. Действие – принять маршрут и установить в таблице validation-state маршрутов действительное.
[edit protocols bgp] import validation;
[edit policy-options]
policy-statement validation-1 {
term valid {
from {
protocol bgp;
validation-database valid; # Triggers a lookup in the RV database
}
then {
validation-state valid; # Sets the validation state in the routing table
accept;
}
}
}
Атрибут сообщества для того, чтобы объявить состояние проверки RPKI соседям IBGP
Проверка префикса проводится только для внешних BGP обновлений (EBGP). В as вам, вероятно, не нужно иметь сеанс RPKI, работающий на каждом внутреннем BGP (IBGP) маршрутизаторе. Вместо этого необходим способ переноса состояния проверки по всей сетке IBGP, чтобы все динамики IBGP могли иметь согласованную информацию. Это осуществляется с помощью данной проверки в не транзитивном расширенном сообществе. Атрибут сообщества объявляет и получает состояние проверки префикса между соседями IBGP.
Junos OS для проверки маршрутов поддерживает следующие хорошо известные расширенные сообщества:
источник-проверка-state-valid
origin-validation-state-invalid
origin-validation-state-unknown
Следующий пример BGP политики импорта настраивается на маршрутизаторе, сеансе с сервером RPKI.
Маршрутизатор с сеансом RPKI
policy-statement validation-1 {
term valid {
from {
protocol bgp;
validation-database valid;
}
then {
validation-state valid;
community add origin-validation-state-valid;
accept;
}
}
}
Следующий пример BGP политики импорта настраивается на одноранговом маршрутизаторе IBGP, который не имеет сеанса с сервером RPKI.
Одноранговой маршрутизатор IBGP без сеанса RPKI
policy-statement validation-2 {
term valid {
from community origin-validation-state-valid;
then validation-state valid;
}
}
Проверка безостановочной активной маршрутизации и источника
При настройке проверки источника на маршрутизаторе с двумя маршрутизаторами маршрутизации и безостановочной маршрутизации активирована, и первичный, и standby Routing Engine имеют копию базы данных RV. Эти две базы данных RV остаются синхронизированными друг с другом.
Маршрутизатор не поддерживает два одинаковых сеанса с сервером RPKI. Протокол RPKI-RTR запускается только на модуль маршрутизации. В режиме ожидания модуль маршрутизации сеанс сервера кэша RPKI всегда не может быть.
База данных RV активно поддерживается основным сервером модуль маршрутизации через сеанс с сервером RPKI. Эта база данных реплицируется на модуль маршрутизации. Хотя сеанс не работает на модуль маршрутизации, реплицированная база данных RV содержит записи RV. Когда standby модуль маршрутизации снова и становится основным модуль маршрутизации, он уже имеет полностью заполненную базу данных RV.
Чтобы просмотреть содержимое двух баз данных, используйте show validation database команды show validation replication database и команды.
Маркировка диапазона префиксов как никогда разрешенного
Модель проверки маршрута имеет один существенный недостаток: Она содержит только положительные обновления. Он может объявить, какая AS является легитимным владельцем префикса. Однако он не может явно передать отрицательное обновление, как в: Этот префикс никогда не исходит от данной AS. Эта функциональность может быть в некоторой степени обеспечена с помощью обходного решения AS 0.
Реализация Junos OS не пытается ограничить входные данные из кэша. Например, установлена и согласована запись RV с AS 0 источника. Это позволяет обходной путь для маркировки диапазона префиксов, который никогда не может быть объявлен, так как AS 0 не является допустимой AS. As в записи RV никогда не соответствует AS, полученной от одноранговых узла EBGP. Таким образом, любой совпадающий префикс помечен как недопустимый.
См. также
Пример использования и преимущества проверки источника для BGP
Если администратор автономной системы (AS) начинает объявления всей или части назначенной сети другой компании, то BGP не имеет встроенного метода распознавания ошибки и реагирования таким образом, чтобы избежать перебоев в обслуживании.
Предположим, например, что администратор в сети клиента по ошибке объявляет маршрут (скажем, 10.65.153.0/24), перенаправив трафик поставщику услуг клиента AS 1. Этот маршрут /24 является более конкретным маршрутом, чем маршрут, используемый фактическим поставщиком контента (10.65.152.0/22), который направляет трафик в AS 2. Благодаря тому, как работают маршрутизаторы, большинство маршрутизаторов выбирают более конкретный маршрут и отправляют трафик в AS 1 вместо AS 2.
Захваченный префикс широко распространен в Интернете, поскольку транзитные маршрутизаторы распространяют обновленные данные о пути. Недопустимые маршруты могут быть широко распределены через Интернет, так как маршрутизаторы в свободной зоне (DFZ) по умолчанию имеют захваченный маршрут. Через определенное время правильный путь AS восстанавливается BGP равноправных узлах, но тем временем следует ожидать прерывания обслуживания.
Поскольку BGP зависит от транзитной модели доверия, важное значение имеет проверка между клиентом и поставщиком. В примере выше поставщик услуг AS 1 не проверил неисправное объявление для 10.65.153.0/24. Принимая это объявление и перенаправив его равноправным узлам и поставщикам, AS 1 распространяла неверный маршрут. Маршрутизаторы, которые получили этот маршрут от AS 1, выбрали его, так как это был более конкретный маршрут. Фактический поставщик контента перед ошибкой рекламил 10.65.152.0/22. /24 было меньшее (и более конкретное) объявление. В соответствии с обычным BGP выбора маршрута, затем был выбран /24, фактически завершив перехват.
Даже при быстром обнаружении и выявлении поставщиков контента и сотрудничества с другими поставщиками обслуживание их префиксов может прерываться на многие минуты, до нескольких часов. Точная продолжительность простоя зависит от конкретной точки доступа в Интернет. В таких событиях вновь проявляется интерес к решениям для этой уязвимости. BGP имеет важное значение для отношений с провайдерами и не будет уходить в ближайшее время. В этом примере демонстрируется решение, использующее проверку источника. Данное решение основывается на криптографических расширениях BGP модели распределенного клиент-сервера, которая позволяет избежать чрезмерного перенастройки ЦП маршрутизатора.
Проверка источника помогает преодолеть уязвимость транзитного доверия, позволяя поставщику ограничивать объявления, которые он принимает от клиента. Эти механизмы включают передачу политик маршрутов на основе расширенного BGP сообщества.
См. также
Примере: Настройка проверки источника для BGP
В этом примере показано, как настроить проверку источника между BGP равноправными узлами, обеспечивая передачу полученных объявлений маршрутов (исходя из ожидаемой автономной системы (AS). Если проверена as источника, политика может указать, что префиксы, в свою очередь, объявлены.
Требования
В данном примере требования к оборудованию и программному обеспечению следующие:
Ресурсная инфраструктура открытых ключей (RPKI) кэш-сервера с использованием сторонного программного обеспечения для аутентификации BGP префиксов.
Junos OS версии 12.2 или более поздней версии, которая работает на устройстве маршрутки, которое взаимодействует с сервером кэша по TCP-соединению.
Обзор
Иногда маршруты объявляются непреднамеренно из-за ошибки оператора. Чтобы избежать этой проблемы с безопасностью, можно настроить BGP на проверку и настроив на нее исходную AS и отклонить эти недопустимые объявления. Эта функция использует сервер кэша для аутентификации префиксов или диапазонов префиксов.
Следующие утверждения конфигурации обеспечивают проверку источника AS:
[edit routing-options] validation { group group-name { max-sessions number; session address { hold-time seconds; local-address local-ip-address; port port-number; preference number; record-lifetime seconds; refresh-time seconds; traceoptions { file filename <files number> <size size> <(world-readable | no-world-readable)>; flag flag { disable; flag-modifier; } } } static { record destination { maximum-length prefix-length { origin-autonomous-system as-number { validation-state (invalid | valid); } } } } traceoptions { file filename <files number> <size size> <world-readable | no-world-readable>; flag flag { disable; flag-modifier; } } }
В данном примере для параметров проверки используются настройки по умолчанию.
Большинство доступных троек являются необязательными. Необходимые настройки:
validation { group group-name { session address { } } }
Уровень иерархии позволяет настраивать статические записи на устройстве маршрутов, переописывая записи, полученные с сервера кэша [edit routing-options validation static] RPKI.
Например:
[edit routing-options validation] user@R0# set static record 10.0.0.0/16 maximum-length 24 origin-autonomous-system 200 validation-state valid
Можно настроить политику маршрутизации, действуя на основе состояния проверки префикса маршрута. Атрибут сообщества можно использовать для того, чтобы объявить и получить состояние проверки префикса между внешними BGP (EBGP) и внутренними равноправными узлами BGP (IBGP). Использование политики маршрутов на некоторых маршрутизаторах может быть удобнее, чем настройка сеанса с сервером RPKI. В этом примере демонстрируется использование атрибута "validation-state community" между равноправными узлами IBGP.
Рис. 4 показывает примерную топологию.
В данном примере устройство R0 имеет IBGP-соединение с устройством R1 и EBGP соединение с устройством R2. Устройство R0 получает записи проверки маршрута (RV) с сервера кэша с помощью протокола, определенного в проекте проекта Интернет-проекта-ietf-sidr-rpki-rtr-19, протокол RPKI/маршрутизатора для отправки записей RV. Протокол RPKI-маршрутизатора работает через TCP. Записи RV используются устройством R0 для создания локальной базы данных RV. На устройстве R1 состояние проверки устанавливается на основании BGP "проверка-state", полученного вместе с маршрутом.
Конфигурации
- интерфейс командной строки быстрой конфигурации
- Настройка устройства R0
- Настройка устройства R1
- Настройка устройства R2
интерфейс командной строки быстрой конфигурации
Чтобы быстро настроить этот пример, скопировать следующие команды, ввести их в текстовый файл, удалить все разрывы строки, изменить все данные, необходимые для настройки сети, а затем скопировать и вкопировать команды в интерфейс командной строки на [edit] иерархии.
Устройство R0
set interfaces ge-1/2/0 unit 2 description to-R1 set interfaces ge-1/2/0 unit 2 family inet address 10.0.0.2/30 set interfaces ge-1/2/1 unit 5 description to-R2 set interfaces ge-1/2/1 unit 5 family inet address 10.0.0.5/30 set interfaces ge-1/2/2 unit 9 description to-cache set interfaces ge-1/2/2 unit 9 family inet address 10.0.0.9/30 set interfaces lo0 unit 1 family inet address 1.0.1.1/32 set protocols bgp group int type internal set protocols bgp group int local-address 1.0.1.1 set protocols bgp group int export send-direct set protocols bgp group int neighbor 1.1.1.1 set protocols bgp group ext type external set protocols bgp group ext import validation set protocols bgp group ext export send-direct set protocols bgp group ext peer-as 200 set protocols bgp group ext neighbor 10.0.0.6 set protocols ospf area 0.0.0.0 interface ge-1/2/0.2 set protocols ospf area 0.0.0.0 interface lo0.1 passive set policy-options policy-statement send-direct from protocol direct set policy-options policy-statement send-direct then accept set policy-options policy-statement validation term valid from protocol bgp set policy-options policy-statement validation term valid from validation-database valid set policy-options policy-statement validation term valid then validation-state valid set policy-options policy-statement validation term valid then community add origin-validation-state-valid set policy-options policy-statement validation term valid then accept set policy-options policy-statement validation term invalid from protocol bgp set policy-options policy-statement validation term invalid from validation-database invalid set policy-options policy-statement validation term invalid then validation-state invalid set policy-options policy-statement validation term invalid then community add origin-validation-state-invalid set policy-options policy-statement validation term invalid then reject set policy-options policy-statement validation term unknown from protocol bgp set policy-options policy-statement validation term unknown then validation-state unknown set policy-options policy-statement validation term unknown then community add origin-validation-state-unknown set policy-options policy-statement validation term unknown then accept set policy-options community origin-validation-state-invalid members 0x4300:0.0.0.0:2 set policy-options community origin-validation-state-unknown members 0x4300:0.0.0.0:1 set policy-options community origin-validation-state-valid members 0x4300:0.0.0.0:0 set routing-options autonomous-system 100 set routing-options validation group test session 10.0.0.10
Устройство R1
set interfaces ge-1/2/0 unit 1 family inet address 10.0.0.1/30 set interfaces lo0 unit 2 family inet address 1.1.1.1/32 set protocols bgp group int type internal set protocols bgp group int local-address 1.1.1.1 set protocols bgp group int import validation-ibgp set protocols bgp group int neighbor 1.0.1.1 set protocols ospf area 0.0.0.0 interface ge-1/2/0.1 set protocols ospf area 0.0.0.0 interface lo0.2 passive set policy-options policy-statement validation-ibgp term valid from community origin-validation-state-valid set policy-options policy-statement validation-ibgp term valid then validation-state valid set policy-options policy-statement validation-ibgp term invalid from community origin-validation-state-invalid set policy-options policy-statement validation-ibgp term invalid then validation-state invalid set policy-options policy-statement validation-ibgp term unknown from community origin-validation-state-unknown set policy-options policy-statement validation-ibgp term unknown then validation-state unknown set policy-options community origin-validation-state-invalid members 0x4300:0.0.0.0:2 set policy-options community origin-validation-state-unknown members 0x4300:0.0.0.0:1 set policy-options community origin-validation-state-valid members 0x4300:0.0.0.0:0 set routing-options autonomous-system 100
Устройство R2
set interfaces ge-1/2/0 unit 6 family inet address 10.0.0.6/30 set interfaces lo0 unit 5 family inet address 172.16.1.1/32 set interfaces lo0 unit 5 family inet address 192.168.2.3/32 set interfaces lo0 unit 5 family inet address 2.2.0.2/32 set protocols bgp group ext export send-direct set protocols bgp group ext peer-as 100 set protocols bgp group ext neighbor 10.0.0.5 set policy-options policy-statement send-direct from protocol direct set policy-options policy-statement send-direct from protocol local set policy-options policy-statement send-direct then accept set routing-options autonomous-system 200
Настройка устройства R0
Пошаговая процедура
В следующем примере необходимо провести различные уровни в иерархии конфигурации. Для получения информации о навигации по интерфейс командной строки см. использование редактора интерфейс командной строки в режиме конфигурации в руководстве Junos OS интерфейс командной строки пользователя.
Для настройки устройства R0:
Настройте интерфейсы.
[edit interfaces] user@R0# set ge-1/2/0 unit 2 description to-R1 user@R0# set ge-1/2/0 unit 2 family inet address 10.0.0.2/30 user@R0# set ge-1/2/1 unit 5 description to-R2 user@R0# set ge-1/2/1 unit 5 family inet address 10.0.0.5/30 user@R0# set ge-1/2/2 unit 9 description to-cache user@R0# set ge-1/2/2 unit 9 family inet address 10.0.0.9/30 user@R0# set lo0 unit 1 family inet address 1.0.1.1/32
Настройте BGP.
Примените экспортную политику таким образом, чтобы прямые маршруты экспортировали из
send-directтаблицы маршрутов в BGP.Примените политику импорта для того, чтобы установить атрибуты validation-state и BGP сообщества для всех маршрутов, импортируемых (или полученных) с одноранговых устройств
validationEBGP устройства R0.Настройте сеанс IBGP с устройством R1. Настройте сеанс EBGP с устройством R2.
[edit protocols bgp] user@R0# set group int type internal user@R0# set group int local-address 1.0.1.1 user@R0# set group int export send-direct user@R0# set group int neighbor 1.1.1.1 user@R0# set group ext type external user@R0# set group ext import validation user@R0# set group ext export send-direct user@R0# set group ext peer-as 200 user@R0# set group ext neighbor 10.0.0.6
Настройте OSPF (или другой протокол внутреннего шлюза [IGP]) на интерфейсе, который сталкивается с одноранговой IBGP и на интерфейсе обратной связи.
Прим.:Если в сообщении IBGP используется адрес интерфейса обратной связи, необходимо включить интерфейс IGP
neighborинтерфейса обратной связи. В противном случае сеанс IBGP не будет установлен.[edit protocols ospf area 0.0.0.0] user@R0# set interface ge-1/2/0.2 user@R0# set interface lo0.1 passive
Настройте политику маршрутов, которая экспортирует прямые маршруты из таблицы маршрутов в BGP.
[edit policy-options policy-statement send-direct] user@R0# set from protocol direct user@R0# set then accept
Настройте политику маршрутизации, которая определяет атрибуты, которые должны быть изменены на основании состояния проверки каждого BGP маршрута.
[edit policy-options policy-statement validation] user@R0# set term valid from protocol bgp user@R0# set term valid from validation-database valid user@R0# set term valid then validation-state valid user@R0# set term valid then community add origin-validation-state-valid user@R0# set term valid then accept user@R0# set term invalid from protocol bgp user@R0# set term invalid from validation-database invalid user@R0# set term invalid then validation-state invalid user@R0# set term invalid then community add origin-validation-state-invalid user@R0# set term invalid then reject user@R0# set term unknown from protocol bgp user@R0# set term unknown then validation-state unknown user@R0# set term unknown then community add origin-validation-state-unknown user@R0# set term unknown then accept [edit policy-options] user@R0# set community origin-validation-state-invalid members 0x4300:0.0.0.0:2 user@R0# set community origin-validation-state-unknown members 0x4300:0.0.0.0:1 user@R0# set community origin-validation-state-valid members 0x4300:0.0.0.0:0
Настройте сеанс с сервером кэша RPKI.
[edit routing-options validation] user@R0# set group test session 10.0.0.10
Настройте номер автономной системы (AS).
[edit routing-options] user@R0# set autonomous-system 100
Результаты
В режиме конфигурации подтвердите конфигурацию путем ввода show interfaces команд show protocols и show policy-optionsshow routing-options команд. Если в выходных данных не отображается указанная конфигурация, повторите инструкции, показанные в данном примере, чтобы исправить конфигурацию.
user@R0# show interfaces
ge-1/2/0 {
unit 2 {
description to-R1;
family inet {
address 10.0.0.2/30;
}
}
}
ge-1/2/1 {
unit 5 {
description to-R2;
family inet {
address 10.0.0.5/30;
}
}
}
ge-1/2/2 {
unit 9 {
description to-cache;
family inet {
address 10.0.0.9/30;
}
}
}
lo0 {
unit 1 {
family inet {
address 1.0.1.1/32;
}
}
}
user@R0# show protocols
bgp {
group int {
type internal;
local-address 1.0.1.1;
export send-direct;
neighbor 1.1.1.1;
}
group ext {
type external;
import validation;
export send-direct;
peer-as 200;
neighbor 10.0.0.6;
}
}
ospf {
area 0.0.0.0 {
interface ge-1/2/0.2;
interface lo0.1 {
passive;
}
}
}
user@R0# show policy-options
policy-statement send-direct {
from protocol direct;
then accept;
}
policy-statement validation {
term valid {
from {
protocol bgp;
validation-database valid;
}
then {
validation-state valid;
community add origin-validation-state-valid;
accept;
}
}
term invalid {
from {
protocol bgp;
validation-database invalid;
}
then {
validation-state invalid;
community add origin-validation-state-invalid;
reject;
}
}
term unknown {
from protocol bgp;
then {
validation-state unknown;
community add origin-validation-state-unknown;
accept;
}
}
}
community origin-validation-state-invalid members 0x4300:0.0.0.0:2;
community origin-validation-state-unknown members 0x4300:0.0.0.0:1;
community origin-validation-state-valid members 0x4300:0.0.0.0:0;
}
user@R0# show routing-options
autonomous-system 100;
validation {
group test {
session 10.0.0.10;
}
}
После настройки устройства войдите в commit режим конфигурации.
Настройка устройства R1
Пошаговая процедура
В следующем примере необходимо провести различные уровни в иерархии конфигурации. Для получения информации о навигации по интерфейс командной строки см. использование редактора интерфейс командной строки в режиме конфигурации в руководстве Junos OS интерфейс командной строки пользователя.
Настройка устройства R1:
Настройте интерфейсы.
[edit interfaces] user@R1# set ge-1/2/0 unit 1 family inet address 10.0.0.1/30 user@R1# set lo0 unit 2 family inet address 1.1.1.1/32
Настройте BGP.
Примените политику импорта для того, чтобы установить параметр validation-state и BGP сообщества для всех маршрутов, полученных от одноранговых устройств
validation-ibgpIBGP устройства R1.Настройте сеанс IBGP с устройством R0.
[edit protocols bgp group int] user@R1# set type internal user@R1# set local-address 1.1.1.1 user@R1# set import validation-ibgp user@R1# set neighbor 1.0.1.1
Настройте OSPF.
[edit protocols ospf area 0.0.0.0] user@R1# set interface ge-1/2/0.1 user@R1# set interface lo0.2 passive
Настройте политику маршрутизации, которая определяет атрибуты, которые должны быть изменены на основании атрибута сообщества validation-state BGP атрибута BGP маршрутов, полученных от устройства R0.
[edit policy-options policy-statement validation-ibgp] user@R1# set term valid from community origin-validation-state-valid user@R1# set term valid then validation-state valid user@R1# set term invalid from community origin-validation-state-invalid user@R1# set term invalid then validation-state invalid user@R1# set term unknown from community origin-validation-state-unknown user@R1# set term unknown then validation-state unknown [edit policy-options] user@R1# set community origin-validation-state-invalid members 0x4300:0.0.0.0:2 user@R1# set community origin-validation-state-unknown members 0x4300:0.0.0.0:1 user@R1# set community origin-validation-state-valid members 0x4300:0.0.0.0:0
Настройте номер автономной системы (AS).
[edit routing-options] user@R1# set autonomous-system 100
Результаты
В режиме конфигурации подтвердите конфигурацию путем ввода show interfaces команд show protocols и show policy-optionsshow routing-options команд. Если в выходных данных не отображается указанная конфигурация, повторите инструкции, показанные в данном примере, чтобы исправить конфигурацию.
user@R1# show interfaces
ge-1/2/0 {
unit 1 {
family inet {
address 10.0.0.1/30;
}
}
}
lo0 {
unit 2 {
family inet {
address 1.1.1.1/32;
}
}
}
user@R1# show protocols
bgp {
group int {
type internal;
local-address 1.1.1.1;
import validation-ibgp;
neighbor 1.0.1.1;
}
}
ospf {
area 0.0.0.0 {
interface ge-1/2/0.1;
interface lo0.2 {
passive;
}
}
}
user@R1# show policy-options
policy-statement validation-ibgp {
term valid {
from community origin-validation-state-valid;
then validation-state valid;
}
term invalid {
from community origin-validation-state-invalid;
then validation-state invalid;
}
term unknown {
from community origin-validation-state-unknown;
then validation-state unknown;
}
}
community origin-validation-state-invalid members 0x4300:0.0.0.0:2;
community origin-validation-state-unknown members 0x4300:0.0.0.0:1;
community origin-validation-state-valid members 0x4300:0.0.0.0:0;
}
user@R1# show routing-options autonomous-system 100;
После настройки устройства войдите в commit режим конфигурации.
Настройка устройства R2
Пошаговая процедура
В следующем примере необходимо провести различные уровни в иерархии конфигурации. Для получения информации о навигации по интерфейс командной строки см. использование редактора интерфейс командной строки в режиме конфигурации в руководстве Junos OS интерфейс командной строки пользователя.
Настройка устройства R2:
Настройте интерфейсы.
Для демонстрационных целей на интерфейсе обратной связи настроено несколько адресов.
[edit interfaces] user@R2# set ge-1/2/0 unit 6 family inet address 10.0.0.6/30 user@R2# set lo0 unit 5 family inet address 172.16.1.1/32 user@R2# set lo0 unit 5 family inet address 192.168.2.3/32 user@R2# set lo0 unit 5 family inet address 2.2.0.2/32
Настройте BGP.
[edit protocols bgp] user@R2# set group ext export send-direct user@R2# set group ext peer-as 100 user@R2# set group ext neighbor 10.0.0.5
Настройте политику маршрутов.
[edit policy-options policy-statement send-direct] user@R2# set from protocol direct user@R2# set from protocol local user@R2# set then accept
Настройте номер автономной системы (AS).
[edit routing-options] user@R2# set autonomous-system 200
Результаты
В режиме конфигурации подтвердите конфигурацию путем ввода show interfaces команд show protocols и show policy-optionsshow routing-options команд. Если в выходных данных не отображается указанная конфигурация, повторите инструкции, показанные в данном примере, чтобы исправить конфигурацию.
user@R2# show interfaces
ge-1/2/0 {
unit 6 {
family inet {
address 10.0.0.6/30;
}
}
}
lo0 {
unit 5 {
family inet {
address 172.16.1.1/32;
address 192.168.2.3/32;
address 2.2.0.2/32;
}
}
}
user@R2# show protocols
bgp {
group ext {
export send-direct;
peer-as 100;
neighbor 10.0.0.5;
}
}
user@R2# show policy-options
policy-statement send-direct {
from protocol [ direct local ];
then accept;
}
user@R2# show routing-options autonomous-system 200;
После настройки устройства войдите в commit режим конфигурации.
Проверки
Подтвердим, что конфигурация работает правильно.
- Проверка отображения измененных атрибутов в таблицах маршрутов
- Использование операций трассировки
- Отображение сведений о проверке
Проверка отображения измененных атрибутов в таблицах маршрутов
Цель
Убедитесь BGP на маршрутизаторах Device R0 и Device R1 имеются ожидаемые состояния проверки и ожидаемые локальные предпочтения.
Действий
В рабочем режиме введите show route команду.
user@R0> show route
inet.0: 12 destinations, 13 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.0.1.1/32 *[Direct/0] 04:53:39
> via lo0.1
1.1.1.1/32 *[OSPF/10] 04:50:53, metric 1
> to 10.0.0.1 via lt-1/2/0.2
2.2.0.2/32 *[BGP/170] 01:30:37, localpref 100
AS path: 200 I, validation-state: valid
> to 10.0.0.6 via lt-1/2/0.5
10.0.0.0/30 *[Direct/0] 04:51:44
> via lt-1/2/0.2
10.0.0.2/32 *[Local/0] 04:51:45
Local via lt-1/2/0.2
10.0.0.4/30 *[Direct/0] 04:51:44
> via lt-1/2/0.5
[BGP/170] 02:24:57, localpref 100
AS path: 200 I, validation-state: valid
> to 10.0.0.6 via lt-1/2/0.5
10.0.0.5/32 *[Local/0] 04:51:45
Local via lt-1/2/0.5
10.0.0.8/30 *[Direct/0] 03:01:28
> via lt-1/2/0.9
10.0.0.9/32 *[Local/0] 04:51:45
Local via lt-1/2/0.9
172.16.1.1/32 *[BGP/170] 02:24:57, localpref 100
AS path: 200 I, validation-state: invalid
> to 10.0.0.6 via lt-1/2/0.5
192.168.2.3/32 *[BGP/170] 02:24:57, localpref 100
AS path: 200 I, validation-state: validation-state: unknown
> to 10.0.0.6 via lt-1/2/0.5
224.0.0.5/32 *[OSPF/10] 04:53:46, metric 1
MultiRecvuser@R1> show route
inet.0: 10 destinations, 12 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
2.2.0.2/32 *[BGP/170] 01:06:58, localpref 100, from 1.0.1.1
AS path: 200 I, validation-state: valid
> to 10.0.0.2 via lt-1/2/0.1
172.16.1.1/32 *[BGP/170] 00:40:52, localpref 100, from 1.0.1.1
AS path: 200 I, validation-state: invalid
> to 10.0.0.2 via lt-1/2/0.1
192.168.2.3/32 *[BGP/170] 01:06:58, localpref 100, from 1.0.1.1
AS path: 200 I, validation-state: unknown
> to 10.0.0.2 via lt-1/2/0.1
224.0.0.5/32 *[OSPF/10] 04:57:09, metric 1
MultiRecvСмысл
Маршруты имеют ожидаемые состояния проверки и значения локального предпочтения на основе информации, полученной от сервера кэша RPKI.
Использование операций трассировки
Цель
Настройте операции трассировки для проверки источника и отслеживайте результаты вновь объявленного маршрута.
Действий
На устройстве R0 настройте трассировку.
[edit routing-options validation traceoptions] user@R0# set file rv-tracing user@R0# set flag all user@R0# commit
На устройстве R2 добавьте маршрут, добавив еще один адрес на интерфейсе обратной связи.
[edit interfaces lo0 unit 5 family inet] user@R2# set address 10.4.4.4/32 user@R2# commit
На устройстве R0 проверьте файл трассировки.
user@R0> file show /var/log/rv-tracing Jan 27 11:27:43.804803 rv_get_policy_state: rt 10.4.4.4/32 origin-as 200, validation result valid Jan 27 11:27:43.944037 task_job_create_background: create prio 7 job Route-validation GC for task Route Validation Jan 27 11:27:43.986580 background dispatch running job Route-validation GC for task Route Validation Jan 27 11:27:43.987374 task_job_delete: delete background job Route-validation GC for task Route Validation Jan 27 11:27:43.987463 background dispatch completed job Route-validation GC for task Route Validation
Смысл
Проверка маршрута работает, как ожидалось.
Отображение сведений о проверке
Цель
Запустите различные команды проверки.
Действий
user@R0> show validation statistics Total RV records: 3 Total Replication RV records: 3 Prefix entries: 3 Origin-AS entries: 3 Memory utilization: 9789 bytes Policy origin-validation requests: 114 Valid: 32 Invalid: 54 Unknown: 28 BGP import policy reevaluation notifications: 156 inet.0, 156 inet6.0, 0
user@R0> show validation database RV database for instance master Prefix Origin-AS Session State Mismatch 2.0.0.0/8-32 200 10.0.0.10 valid 10.0.0.0/8-32 200 10.0.0.10 valid 172.0.0.0/8-12 200 10.0.0.10 invalid IPv4 records: 3 IPv6 records: 0
user@R0> show validation replication database RRV replication database for instance master Prefix Origin-AS Session State 2.0.0.0/8-32 200 10.0.0.10 valid 10.0.0.0/8-32 200 10.0.0.10 valid 172.0.0.0/8-12 200 10.0.0.10 invalid IPv4 records: 3 IPv6 records: 0
user@R0> show validation group
master
Group: test, Maximum sessions: 2
Session 10.0.0.10, State: Connect, Preference: 100user@R0> show validation session Session State Flaps Uptime #IPv4/IPv6 records 10.0.0.10 Up 0 00:02:28 1/0
user@R0> request validation policy Enqueued 3 IPv4 records Enqueued 0 IPv6 records