Настройка BGP в FRRouting. Конфигурация, фильтрация маршрутов и резервирование каналов<

Представьте компанию с двумя интернет-провайдерами. Первый канал быстрый и дорогой, второй дешевле и нужен преимущественно для резерва. Администратор хочет отправлять основной трафик через первого провайдера, автоматически переходить на второго при аварии и по возможности управлять тем, через какой канал внешние пользователи подключаются к серверам компании.

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

Здесь пригодится Border Gateway Protocol (BGP). Протокол обменивается информацией о доступных сетях между автономными системами, выбирает подходящие маршруты и позволяет задавать собственные правила для разных направлений трафика.

Настроим BGP на четырёх виртуальных маршрутизаторах, проверим обмен маршрутами, сделаем один канал основным, а второй резервным, затем искусственно отключим соединение и посмотрим, как изменится маршрут. Для практики используем FRRouting (FRR), свободный программный маршрутизатор для Linux.

Все настройки ниже предназначены для изолированной лаборатории или сетей, которыми вы вправе управлять. Ошибочный BGP-анонс в действующей сети способен вызвать утечку маршрутов и нарушить доступность чужих ресурсов. Не переносите лабораторные ASN, IP-префиксы и правила экспорта в реальные BGP-сессии.

1. Собираем лабораторию из четырёх маршрутизаторов

В качестве основы возьмём Docker, Containerlab и FRRouting. Containerlab создаст контейнеры, соединит виртуальные интерфейсы и загрузит конфигурации маршрутизаторов. Не понадобятся ни физические маршрутизаторы, ни дорогостоящие лицензии, ни подключение к настоящим интернет-провайдерам.

Используем образ FRRouting 10.7.1 с поддержкой отдельного типа узлов frr в Containerlab. Для такой схемы требуется актуальная версия Containerlab с поддержкой данного типа. Описание образа, загрузки конфигураций и запуска демонов приведено в инструкции Containerlab.

Нужен Linux-хост с работающими Docker и Containerlab, правами администратора и достаточной памятью для четырёх контейнеров. Если работаете в Windows, удобнее использовать отдельную виртуальную машину Linux.

Схема сети

                  AS 65020
                  ISP-A (R2)
                  /        
                 /          
                /            
          R1 (клиент)       R4 (удалённая сеть)
           AS 65010           AS 65040
                            /
                           /
                          /
                  ISP-B (R3)
                   AS 65030

Маршрутизатор R1 представляет нашу компанию, R2 и R3 играют роли двух независимых провайдеров, R4 изображает удалённую сеть. Через R4 сможем проверить не только исходящий трафик компании, но и то, по какому пути возвращаются пакеты.

Соединение	Первый интерфейс	Второй интерфейс
R1 ↔ R2	R1 eth1, 10.0.12.1/30	R2 eth1, 10.0.12.2/30
R1 ↔ R3	R1 eth2, 10.0.13.1/30	R3 eth1, 10.0.13.2/30
R2 ↔ R4	R2 eth2, 10.0.24.1/30	R4 eth1, 10.0.24.2/30
R3 ↔ R4	R3 eth2, 10.0.34.1/30	R4 eth2, 10.0.34.2/30

У компании будет префикс 203.0.113.0/24, у удалённой сети 198.51.100.0/24. Оба диапазона зарезервированы стандартом RFC 5737 для документации. В настоящем интернете использовать их для собственных публичных сервисов нельзя.

Номера автономных систем из диапазона 64512–65534 предназначены для частного использования в двухбайтовом представлении ASN. Поэтому лабораторные AS 65010, 65020, 65030 и 65040 не требуют регистрации.

Создаём топологию

На Linux-хосте создаём рабочий каталог и четыре подкаталога для конфигураций FRR.

mkdir -p bgp-lab/{r1,r2,r3,r4}
 cd bgp-lab

В корневом каталоге создаём файл bgp.clab.yml.

name: bgp-demo
 
 topology:
   defaults:
     kind: frr
     image: quay.io/frrouting/frr:containerlab-10.7.1
 
   nodes:
     r1:
       startup-config: r1/frr.conf
       daemons:
         - bgpd
 
     r2:
       startup-config: r2/frr.conf
       daemons:
         - bgpd
 
     r3:
       startup-config: r3/frr.conf
       daemons:
         - bgpd
 
     r4:
       startup-config: r4/frr.conf
       daemons:
         - bgpd
 
   links:
     - endpoints: ["r1:eth1", "r2:eth1"]
     - endpoints: ["r1:eth2", "r3:eth1"]
     - endpoints: ["r2:eth2", "r4:eth1"]
     - endpoints: ["r3:eth2", "r4:eth2"]

Containerlab создаст соединения между указанными интерфейсами. Параметр startup-config указывает исходный файл конфигурации маршрутизатора. Демон bgpd отвечает за BGP, а zebra работает с интерфейсами и таблицей маршрутизации Linux. В выбранном типе узлов Containerlab запускает zebra автоматически.

FRRouting позволяет конфигурировать сетевые интерфейсы непосредственно через frr.conf, поэтому отдельные команды Linux для назначения IP-адресов в лаборатории не понадобятся.

2. Настраиваем FRRouting и устанавливаем BGP-соседство

Начнём с клиентского маршрутизатора R1. Именно здесь зададим два соседства, объявим собственную сеть и настроим правила маршрутизации.

Конфигурация R1

Содержимое файла r1/frr.conf.

frr defaults traditional
 !
 interface lo
  ip address 203.0.113.1/24
 !
 interface eth1
  ip address 10.0.12.1/30
 !
 interface eth2
  ip address 10.0.13.1/30
 !
 ip prefix-list OUR-NET seq 10 permit 203.0.113.0/24
 ip prefix-list REMOTE-NET seq 10 permit 198.51.100.0/24
 !
 route-map FROM-A permit 10
  match ip address prefix-list REMOTE-NET
  set local-preference 200
 !
 route-map FROM-B permit 10
  match ip address prefix-list REMOTE-NET
  set local-preference 100
 !
 route-map TO-A permit 10
  match ip address prefix-list OUR-NET
 !
 route-map TO-B permit 10
  match ip address prefix-list OUR-NET
  set as-path prepend 65010 65010 65010
 !
 router bgp 65010
  bgp router-id 1.1.1.1
  neighbor 10.0.12.2 remote-as 65020
  neighbor 10.0.13.2 remote-as 65030
  !
  address-family ipv4 unicast
   network 203.0.113.0/24
   neighbor 10.0.12.2 route-map FROM-A in
   neighbor 10.0.12.2 route-map TO-A out
   neighbor 10.0.13.2 route-map FROM-B in
   neighbor 10.0.13.2 route-map TO-B out
  exit-address-family
 !

Конфигурация решает сразу несколько задач. Команда router bgp 65010 запускает процесс BGP с номером нашей автономной системы. Команды neighbor указывают соседние маршрутизаторы и их ASN.

Команда network 203.0.113.0/24 разрешает BGP объявлять соответствующий префикс. В актуальных версиях FRR при включённой проверке network import-check маршрут к объявляемой сети должен присутствовать в локальной таблице маршрутизации. В лаборатории условие выполняется благодаря адресу 203.0.113.1/24 на интерфейсе lo.

Четыре правила route-map управляют маршрутами, поступающими от провайдеров и отправляемыми им. Атрибуты LOCAL_PREF и AS_PATH разберём подробнее после запуска лаборатории.

Обратите внимание на отсутствие команды no bgp ebgp-requires-policy. Мы намеренно оставляем проверку обязательных политик и прописываем входящие и исходящие фильтры. Такой подход соответствует безопасной модели из RFC 8212, при которой BGP не должен автоматически принимать и распространять маршруты без явно заданных правил.

Конфигурация основного провайдера R2

Файл r2/frr.conf.

frr defaults traditional
 !
 interface eth1
  ip address 10.0.12.2/30
 !
 interface eth2
  ip address 10.0.24.1/30
 !
 ip prefix-list CUSTOMER seq 10 permit 203.0.113.0/24
 ip prefix-list REMOTE seq 10 permit 198.51.100.0/24
 !
 route-map FROM-CUSTOMER permit 10
  match ip address prefix-list CUSTOMER
 !
 route-map TO-CUSTOMER permit 10
  match ip address prefix-list REMOTE
 !
 route-map FROM-REMOTE permit 10
  match ip address prefix-list REMOTE
 !
 route-map TO-REMOTE permit 10
  match ip address prefix-list CUSTOMER
 !
 router bgp 65020
  bgp router-id 2.2.2.2
  neighbor 10.0.12.1 remote-as 65010
  neighbor 10.0.24.2 remote-as 65040
  !
  address-family ipv4 unicast
   neighbor 10.0.12.1 route-map FROM-CUSTOMER in
   neighbor 10.0.12.1 route-map TO-CUSTOMER out
   neighbor 10.0.24.2 route-map FROM-REMOTE in
   neighbor 10.0.24.2 route-map TO-REMOTE out
  exit-address-family
 !

R2 принимает от клиента только сеть 203.0.113.0/24, а от удалённой стороны только 198.51.100.0/24. Затем передаёт разрешённые маршруты между соседями.

Провайдеру не требуется создавать собственные маршруты командой network. R2 выступает транзитной автономной системой.

Конфигурация резервного провайдера R3

Файл r3/frr.conf. Правила фильтрации аналогичны R2, но адреса интерфейсов и ASN отличаются.

frr defaults traditional
 !
 interface eth1
  ip address 10.0.13.2/30
 !
 interface eth2
  ip address 10.0.34.1/30
 !
 ip prefix-list CUSTOMER seq 10 permit 203.0.113.0/24
 ip prefix-list REMOTE seq 10 permit 198.51.100.0/24
 !
 route-map FROM-CUSTOMER permit 10
  match ip address prefix-list CUSTOMER
 !
 route-map TO-CUSTOMER permit 10
  match ip address prefix-list REMOTE
 !
 route-map FROM-REMOTE permit 10
  match ip address prefix-list REMOTE
 !
 route-map TO-REMOTE permit 10
  match ip address prefix-list CUSTOMER
 !
 router bgp 65030
  bgp router-id 3.3.3.3
  neighbor 10.0.13.1 remote-as 65010
  neighbor 10.0.34.2 remote-as 65040
  !
  address-family ipv4 unicast
   neighbor 10.0.13.1 route-map FROM-CUSTOMER in
   neighbor 10.0.13.1 route-map TO-CUSTOMER out
   neighbor 10.0.34.2 route-map FROM-REMOTE in
   neighbor 10.0.34.2 route-map TO-REMOTE out
  exit-address-family
 !

Конфигурация удалённой сети R4

R4 нужен для независимого наблюдения за тем, как внешняя автономная система выбирает маршрут к нашим адресам.

Файл r4/frr.conf.

frr defaults traditional
 !
 interface lo
  ip address 198.51.100.1/24
 !
 interface eth1
  ip address 10.0.24.2/30
 !
 interface eth2
  ip address 10.0.34.2/30
 !
 ip prefix-list CUSTOMER seq 10 permit 203.0.113.0/24
 ip prefix-list OUR-NET seq 10 permit 198.51.100.0/24
 !
 route-map FROM-ISP permit 10
  match ip address prefix-list CUSTOMER
 !
 route-map TO-ISP permit 10
  match ip address prefix-list OUR-NET
 !
 router bgp 65040
  bgp router-id 4.4.4.4
  neighbor 10.0.24.1 remote-as 65020
  neighbor 10.0.34.1 remote-as 65030
  !
  address-family ipv4 unicast
   network 198.51.100.0/24
   neighbor 10.0.24.1 route-map FROM-ISP in
   neighbor 10.0.24.1 route-map TO-ISP out
   neighbor 10.0.34.1 route-map FROM-ISP in
   neighbor 10.0.34.1 route-map TO-ISP out
  exit-address-family
 !

Теперь R4 знает двух провайдеров, принимает через них маршрут компании и объявляет собственную сеть.

Запускаем лабораторию

Проверьте, что Docker работает, и выполните команду из каталога bgp-lab.

sudo containerlab deploy -t bgp.clab.yml

После запуска Containerlab создаст четыре контейнера. Их имена будут начинаться с clab-bgp-demo-.

Проверяем состояние BGP на клиентском маршрутизаторе.

docker exec clab-bgp-demo-r1 
   vtysh -c "show bgp ipv4 unicast summary"

Ожидаем увидеть двух соседей с ASN 65020 и 65030. После установления соседства в столбце State/PfxRcd обычно отображается число принятых префиксов, а не название состояния. В нашей лаборатории каждый сосед должен передать один разрешённый маршрут к удалённой сети.

Посмотрим содержимое таблицы BGP.

docker exec clab-bgp-demo-r1 
   vtysh -c "show bgp ipv4 unicast"

Для сети 198.51.100.0/24 маршрутизатор R1 должен знать два пути. Один через R2, второй через R3. Однако использовать для обычной пересылки будет лучший путь, выбранный алгоритмом BGP.

Проверяем состояние маршрута подробнее.

docker exec clab-bgp-demo-r1 
   vtysh -c "show bgp ipv4 unicast 198.51.100.0/24"

В выводе должны присутствовать оба варианта с разными NEXT_HOP и LOCAL_PREF. Путь через R2 получит LOCAL_PREF 200, через R3 значение 100. В результате R1 предпочтёт провайдера A.

Заодно проверим маршрутизацию самого Linux. FRRouting хранит сведения о BGP-маршрутах, а zebra устанавливает выбранные маршруты в таблицу ядра.

docker exec clab-bgp-demo-r1 
   ip route get 198.51.100.1 from 203.0.113.1

Следующим узлом должен стать 10.0.12.2 через eth1.

Проверим прохождение пакетов между двумя автономными системами.

docker exec clab-bgp-demo-r1 
   ping -c 4 -I 203.0.113.1 198.51.100.1

Если BGP-соседства установились, фильтры пропускают префиксы, а Linux пересылает IP-пакеты, запросы должны достигать R4. Containerlab для FRR-узлов включает пересылку IPv4 и IPv6 внутри контейнеров, поэтому отдельно менять параметр net.ipv4.ip_forward в данном примере не требуется.

Что происходит при установлении BGP-соседства

Два маршрутизатора не начинают обмениваться маршрутами сразу после назначения IP-адресов. Сначала BGP устанавливает TCP-соединение на порт 179, согласовывает параметры сеанса и только затем передаёт маршрутную информацию.

Состояние	Значение	Что проверить при проблеме
Idle	BGP ожидает начала процедуры соединения или повторной попытки	Конфигурацию соседа, интерфейс, сообщения об ошибках
Connect	Устанавливается TCP-соединение	IP-доступность и TCP/179
Active	BGP повторяет попытки установить соединение	Адрес соседа, маршруты, межсетевой экран
OpenSent	Отправлено сообщение OPEN	ASN, идентификаторы, согласование возможностей
OpenConfirm	Ожидается подтверждение согласованных параметров	KEEPALIVE, причины разрыва сеанса
Established	Соседство работает, возможен обмен маршрутами	Фильтры и полученные префиксы

Состояние Active не означает, что BGP работает активно и успешно. Обычно длительное пребывание в Active говорит о проблеме с установлением TCP-сессии.

Для детальной диагностики соседства используйте команду.

docker exec clab-bgp-demo-r1 
   vtysh -c "show bgp ipv4 unicast neighbors 10.0.12.2"

Вывод содержит состояние сессии, время работы, согласованные возможности, количество сообщений и статистику ошибок.

3. Управляем маршрутами с помощью BGP-атрибутов

После первого успешного соседства начинается самая интересная часть. BGP позволяет выбирать не просто кратчайший путь, а маршрут, который соответствует сетевой политике организации.

Например, компания может предпочитать более дорогой канал из-за меньших задержек или лучшего соглашения об уровне обслуживания. BGP не измеряет качество этих каналов автоматически, но позволяет администратору задать предпочтения.

LOCAL_PREF. Как выбрать исходящий канал

LOCAL_PREF определяет предпочтение маршрута внутри автономной системы. Чем выше значение, тем предпочтительнее путь при прочих применимых условиях.

В нашей конфигурации R1 получает два объявления для сети 198.51.100.0/24.

Маршрут	LOCAL_PREF	Результат
Через ISP-A	200	Основной
Через ISP-B	100	Резервный

Правила задаются через входящие route-map.

route-map FROM-A permit 10
  match ip address prefix-list REMOTE-NET
  set local-preference 200
 !
 route-map FROM-B permit 10
  match ip address prefix-list REMOTE-NET
  set local-preference 100

Параметр in означает, что правило применяется к маршрутам, полученным от соседа. Поэтому LOCAL_PREF влияет на выбор исходящего пути внутри нашей AS, но не заставляет другие автономные системы отправлять пакеты в нужном направлении.

Сам атрибут LOCAL_PREF не передаётся обычным внешним eBGP-соседям. Внутри одной AS он может распространяться через iBGP.

Приоритет действует для каждого префикса, к которому применяется политика. В реальной сети можно направлять трафик к одним сетям через провайдера A, а к другим через B. Для этого создают разные Prefix Lists и назначают соответствующие значения LOCAL_PREF.

Есть тонкость. LOCAL_PREF участвует в выборе лучшего BGP-пути, но итоговая пересылка пакетов также зависит от маршрутов других протоколов и правил Linux. Например, более предпочтительный статический маршрут может перекрыть маршрут BGP в основной таблице маршрутизации.

AS_PATH. Как повлиять на входящий трафик

Теперь посмотрим на противоположную задачу. Компания хочет, чтобы пользователи из внешней сети чаще приходили через основного провайдера A.

Прямого контроля над таблицами маршрутизации других автономных систем у компании нет. Однако можно попробовать изменить атрибут AS_PATH в собственных объявлениях.

AS_PATH содержит последовательность автономных систем, через которые проходит маршрут. При сопоставимых более приоритетных атрибутах BGP обычно предпочитает путь с меньшей длиной AS_PATH.

Поэтому на резервном канале R1 использует AS_PATH prepend.

route-map TO-B permit 10
  match ip address prefix-list OUR-NET
  set as-path prepend 65010 65010 65010

Команда добавляет дополнительные повторения ASN 65010 к объявлению, отправляемому провайдеру B. При стандартном экспорте eBGP собственный ASN также добавляется маршрутизатором.

На R4 разница между путями к нашей сети будет выглядеть примерно так.

Через ISP-A
 65020 65010
 
 Через ISP-B
 65030 65010 65010 65010 65010

При равных остальных значимых условиях R4 выберет путь через ISP-A.

Проверить можно непосредственно на удалённом маршрутизаторе.

docker exec clab-bgp-demo-r4 
   vtysh -c "show bgp ipv4 unicast 203.0.113.0/24"

Если убрать prepend на R1, оба варианта получат одинаковую длину AS_PATH. Тогда удалённый маршрутизатор будет выбирать путь по следующим критериям. Результат может измениться.

Однако AS_PATH prepend не гарантирует управление входящим трафиком в реальном интернете. Чужие маршрутизаторы могут предпочесть другое значение LOCAL_PREF, использовать собственные фильтры, выбрать маршрут по условиям операторского соглашения или вообще не получить альтернативное объявление.

Некоторые провайдеры предлагают управление входящими маршрутами через BGP Communities. Клиент передаёт специальную метку, а провайдер на её основе меняет LOCAL_PREF или выполняет prepend в выбранных направлениях. Набор поддерживаемых Communities и их смысл зависят от конкретного оператора.

Если провайдер поддерживает такие политики, согласованные Communities обычно дают более гибкие возможности, чем многократное добавление своего ASN вслепую.

MED. Когда полезно указать предпочтительную точку входа

Multi-Exit Discriminator (MED) позволяет одной автономной системе сообщить соседней, через какое из нескольких соединений предпочтительнее принимать трафик.

MED работает по противоположному принципу относительно LOCAL_PREF. При сравнении MED меньшему значению отдаётся предпочтение.

Допустим, компания подключена к одному провайдеру двумя независимыми BGP-сессиями. Можно настроить следующие исходящие политики.

ip prefix-list OUR-NET seq 10 permit 203.0.113.0/24
 !
 route-map MED-PRIMARY permit 10
  match ip address prefix-list OUR-NET
  set metric 50
 !
 route-map MED-BACKUP permit 10
  match ip address prefix-list OUR-NET
  set metric 200

Первую route-map назначают на экспорт в основную сессию, вторую на резервную. Если провайдер учитывает MED и остальные значимые критерии выбора не мешают, маршрут с MED 50 будет предпочтительнее.

В нашей основной лаборатории два провайдера принадлежат разным автономным системам. Поэтому рассчитывать на MED для выбора между ISP-A и ISP-B неправильно. По умолчанию BGP обычно сравнивает MED для конкурирующих маршрутов, полученных из одной соседней AS, а не между произвольными автономными системами.

FRRouting поддерживает настройку bgp always-compare-med, но включать её без оценки сетевой политики не стоит. Принудительное сравнение MED между разными AS может дать неожиданные результаты и усложнить работу маршрутизации.

NEXT_HOP. Почему маршрут есть, а пакеты не проходят

Атрибут NEXT_HOP указывает IP-адрес следующего маршрутизатора, через который следует передавать пакеты.

В нашей лаборатории R1 получает маршрут от ISP-A с NEXT_HOP 10.0.12.2. Адрес находится в непосредственно подключённой сети, поэтому R1 способен передавать через него пакеты.

Проверить доступность следующего узла можно командами.

docker exec clab-bgp-demo-r1 
   ip route get 10.0.12.2
 
 docker exec clab-bgp-demo-r1 
   vtysh -c "show bgp ipv4 unicast 198.51.100.0/24"

При обычной передаче маршрута между eBGP-соседями маршрутизатор, как правило, меняет NEXT_HOP на собственный адрес соединения. Однако существуют исключения, включая некоторые сценарии с общей сетью и специальными настройками.

Особенно внимательно NEXT_HOP приходится проверять в iBGP. Внутренний сосед может получить внешний маршрут с адресом следующего узла, до которого у него нет маршрута.

Для типового пограничного маршрутизатора, передающего внешние маршруты внутреннему iBGP-соседу, часто применяют команду.

router bgp 65010
  address-family ipv4 unicast
   neighbor 10.255.0.2 next-hop-self
  exit-address-family

Здесь 10.255.0.2 лишь пример внутреннего BGP-соседа, отсутствующего в нашей четырёхузловой схеме. Такое соседство нужно создать отдельно, а адрес пограничного маршрутизатора должен быть достижим через внутреннюю маршрутизацию.

Команда next-hop-self задаёт собственный адрес в качестве NEXT_HOP для соответствующих объявлений. При этом исправление NEXT_HOP не заменяет настройку IGP, статических маршрутов или другой связности между внутренними маршрутизаторами.

Как BGP выбирает лучший маршрут

Распространённое упрощение звучит так. BGP выбирает маршрут с самым коротким AS_PATH. На практике AS_PATH лишь один из критериев, причём далеко не первый.

В FRRouting при стандартных условиях сначала учитываются доступность следующего узла, локальные предпочтения, локальное происхождение маршрута и другие признаки, а уже затем длина AS_PATH и последующие атрибуты.

Ниже упрощённый порядок наиболее характерных критериев. Конкретное поведение может меняться из-за настроек FRR и особенностей маршрута.

Критерий	Предпочтение
Weight	Большее значение, локальный механизм FRR
LOCAL_PREF	Большее значение
Локальное происхождение	При определённых условиях локально созданный маршрут
AS_PATH	Обычно более короткий путь
ORIGIN	IGP, затем EGP, затем incomplete
MED	Меньшее значение при применимости сравнения
Тип соседства	eBGP обычно предпочтительнее iBGP
IGP metric до NEXT_HOP	Меньшая внутренняя стоимость

При дальнейшем равенстве могут учитываться возраст маршрута, идентификаторы маршрутизаторов и адреса соседей. Полную последовательность следует проверять для конкретной версии и конфигурации FRRouting.

Значения атрибутов можно увидеть командой show bgp ipv4 unicast, а причину выбора удобнее анализировать по подробному выводу конкретного префикса.

4. Фильтрация маршрутов, резервирование и устранение ошибок

BGP редко ломается из-за одной сложной команды. Гораздо чаще проблема возникает из-за неверного ASN, отсутствующего фильтра, недоступного NEXT_HOP или случайного объявления чужих сетей.

Хорошая практика состоит в том, чтобы сначала определить, какие маршруты сосед вправе присылать и получать, затем проверить обмен и только после этого настраивать атрибуты предпочтения.

Prefix Lists и Route Maps

Prefix List задаёт условия сопоставления IP-префиксов. Например, можно разрешить только одну сеть.

ip prefix-list OUR-NET seq 10 permit 203.0.113.0/24

Запись разрешает именно префикс 203.0.113.0/24. Она не означает автоматического разрешения всех более специфичных маршрутов внутри данной сети.

Чтобы разрешить диапазон длин маски, используют параметры ge и le.

ip prefix-list EXAMPLE seq 10 permit 203.0.113.0/24 le 28

Такой фильтр совпадёт с исходным /24 и входящими в него префиксами с масками до /28 включительно.

Но для объявления собственного публичного адресного пространства подобное правило нельзя бездумно копировать. Более специфичные префиксы IPv4 длиннее /24 многие сети не принимают в глобальную таблицу маршрутизации. Для реального многопровайдерного подключения требуется согласовать разрешённые объявления и политику фильтрации с операторами.

Route Map объединяет условия отбора с действиями над маршрутами.

route-map EXPORT permit 10
  match ip address prefix-list OUR-NET
  set metric 100

Здесь route-map пропускает разрешённый префикс и присваивает объявлению MED 100.

Если route-map содержит несколько записей, FRR обрабатывает их по порядку согласно правилам сопоставления. Маршруты, не разрешённые ни одной подходящей записью, не проходят через такую политику.

Поэтому опасно добавлять универсальный permit в конце экспортной политики без понимания последствий. Можно случайно разрешить передачу маршрутов, которые сосед вообще не должен получать.

Проверяем фильтры на R1.

docker exec clab-bgp-demo-r1 
   vtysh -c "show ip prefix-list"
 
 docker exec clab-bgp-demo-r1 
   vtysh -c "show route-map"

Затем смотрим, какие маршруты реально отправляются провайдеру.

docker exec clab-bgp-demo-r1 
   vtysh -c "show bgp ipv4 unicast neighbors 10.0.12.2 advertised-routes"

В нашей лаборатории в объявлениях R1 должен присутствовать 203.0.113.0/24, но не сеть удалённой AS 198.51.100.0/24.

Для проверки принятых маршрутов используем.

docker exec clab-bgp-demo-r1 
   vtysh -c "show bgp ipv4 unicast neighbors 10.0.12.2 routes"

Команда показывает маршруты от соседа, которые прошли входящую политику. Для просмотра всех изначально полученных объявлений, включая отклонённые, в зависимости от версии FRR и возможностей соседа могут потребоваться дополнительные настройки хранения входящих маршрутов.

Проверяем резервирование каналов

Теперь искусственно отключим основной канал между R1 и ISP-A.

Сначала убедитесь, что BGP использует маршрут через 10.0.12.2. Затем на R1 отключите интерфейс eth1.

docker exec clab-bgp-demo-r1 
   ip link set eth1 down

После обнаружения потери соединения BGP-соседство с R2 прекратится. Маршрут через основного провайдера перестанет быть доступным, а R1 сможет использовать путь через R3.

Проверяем результат.

docker exec clab-bgp-demo-r1 
   vtysh -c "show bgp ipv4 unicast summary"
 
 docker exec clab-bgp-demo-r1 
   vtysh -c "show bgp ipv4 unicast 198.51.100.0/24"
 
 docker exec clab-bgp-demo-r1 
   ip route get 198.51.100.1 from 203.0.113.1

Ожидаемый следующий узел после переключения на резервный маршрут будет 10.0.13.2 через eth2.

Проверим связь с удалённым адресом.

docker exec clab-bgp-demo-r1 
   ping -c 4 -I 203.0.113.1 198.51.100.1

После распространения изменений по сети связь должна восстановиться через ISP-B.

На маршрутизаторе R4 тоже изменится путь к клиентской сети. Поскольку R2 потеряет маршрут R1 и отзовёт соответствующее объявление, оставшийся путь через R3 станет доступным вариантом.

Проверяем с удалённой стороны.

docker exec clab-bgp-demo-r4 
   vtysh -c "show bgp ipv4 unicast 203.0.113.0/24"

Восстановим основной канал.

docker exec clab-bgp-demo-r1 
   ip link set eth1 up

Когда соседство восстановится и маршрутизаторы снова обменяются объявлениями, R1 должен предпочесть ISP-A благодаря большему LOCAL_PREF. R4 при сопоставимых остальных критериях снова выберет путь через ISP-A благодаря более короткому AS_PATH.

Время переключения не фиксировано. Оно зависит от способа обнаружения отказа, таймеров BGP, обработки обновлений и установки маршрутов в таблицы пересылки.

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

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

Рассмотрим более неприятный сценарий. Канал между компанией и ISP-A работает, BGP-сессия Established, но за маршрутизатором провайдера возникает авария.

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

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

Для повышения отказоустойчивости применяют дополнительные механизмы.

BFD позволяет быстрее обнаруживать недоступность соседнего маршрутизатора или пути между BFD-узлами при корректной настройке.
Мониторинг внешних контрольных адресов помогает заметить проблемы за пределами ближайшего BGP-соседа.
Активные проверки TCP и HTTP позволяют обнаруживать недоступность конкретных сервисов, которую обычный BGP не обязан замечать.
Согласованные политики провайдеров помогают управлять экспортом, приоритетами и реакцией на отказы.

Нельзя путать мониторинг сервиса с автоматическим переключением. Система проверок должна быть связана с механизмом изменения маршрута, а её логика обязана учитывать ложные срабатывания и временные сетевые проблемы.

Ещё один практический нюанс касается NAT. При переключении провайдеров может измениться публичный исходящий IP-адрес, а существующие TCP-соединения разорвутся. Собственный маршрутизируемый префикс и согласованное многопровайдерное BGP-подключение позволяют избежать части таких проблем, но не устраняют все кратковременные потери трафика.

Диагностика типичных ошибок BGP

Симптом	Вероятная причина	Что делать
Сосед постоянно в Active	Нет IP-связности, закрыт TCP/179, ошибочный адрес соседа	Проверить интерфейсы, маршруты и межсетевой экран
Соседство сбрасывается после OPEN	Неверный ASN или несовместимые параметры	Изучить сообщения BGP и конфигурацию обеих сторон
Established, но маршрутов нет	Нет разрешающих политик, маршрут не объявляется или фильтруется	Проверить Prefix Lists, Route Maps и advertised-routes
Маршрут есть в BGP, но не используется	NEXT_HOP недоступен, другой маршрут предпочтительнее	Проверить подробный BGP-вывод и таблицу Linux
Исходящий трафик идёт не туда	Неверный LOCAL_PREF или другая более приоритетная политика	Проверить атрибуты и выбранный маршрут
Входящий трафик игнорирует prepend	Удалённая AS использует собственные предпочтения	Проверить маршрут с удалённой стороны и политику провайдера
После изменения фильтра ничего не изменилось	Не выполнена повторная обработка маршрутов	Применить мягкое обновление соответствующей BGP-сессии

Если после настройки соседства FRRouting показывает пометку (Policy) вместо количества маршрутов, проверьте наличие входящих и исходящих политик. В режиме frr defaults traditional действует требование явных правил для eBGP.

Для применения изменённых входящих правил без принудительного разрыва всего BGP-соседства можно использовать Route Refresh, если сосед поддерживает такую возможность.

docker exec clab-bgp-demo-r1 
   vtysh -c "clear bgp ipv4 unicast 10.0.12.2 in"

Аналогично для повторной отправки объявлений с учётом изменённой исходящей политики.

docker exec clab-bgp-demo-r1 
   vtysh -c "clear bgp ipv4 unicast 10.0.12.2 out"

Эти операции отличаются от жёсткого сброса BGP-сессии. Команда clear bgp * без соответствующих уточнений может вызвать разрыв соседств и кратковременную потерю маршрутов.

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

docker exec clab-bgp-demo-r1 
   vtysh -c "show running-config"
 
 docker exec clab-bgp-demo-r1 
   ip -br address
 
 docker exec clab-bgp-demo-r1 
   ip route
 
 docker exec clab-bgp-demo-r1 
   vtysh -c "show ip route"

Команды решают разные задачи. show bgp показывает информацию протокола BGP, show ip route отображает таблицу маршрутов FRRouting, а Linux ip route помогает понять, какие маршруты фактически доступны сетевому стеку.

Не каждый маршрут, присутствующий в BGP-таблице, обязательно будет установлен в таблицу ядра. Между получением объявления и реальной пересылкой пакетов существует несколько этапов выбора и установки маршрута.

Безопасная BGP-конфигурация для реального подключения

Рабочая лаборатория не равнозначна готовой конфигурации пограничного маршрутизатора компании. В настоящей сети придётся учитывать адресное пространство, ASN, условия договора с операторами, число ожидаемых маршрутов, скорость переключения и требования безопасности.

Минимальный набор проверок перед подключением к провайдеру выглядит следующим образом.

Принимать только согласованные маршруты или необходимую часть таблицы интернета. Для сценария с резервным выходом иногда достаточно получать от обоих провайдеров маршрут по умолчанию.
Разрешать экспорт исключительно своих подтверждённых префиксов. Не допускать случайного транзита между провайдерами.
Настроить ограничения числа префиксов с учётом ожидаемой маршрутной таблицы и последствий превышения лимита.
Внедрить фильтрацию некорректных и специальных диапазонов там, где такие маршруты не должны присутствовать.
Использовать RPKI Origin Validation для проверки соответствия анонсирующей AS и разрешённого происхождения префикса, учитывая, что проверка происхождения не подтверждает корректность всей цепочки AS_PATH.
Защитить управление маршрутизаторами, ограничить доступ к BGP-соседствам и применять согласованные с оператором механизмы защиты сессии.
Контролировать число маршрутов, изменения соседств, отклонённые объявления и фактическую доступность сервисов.

Дополнительную защиту от непреднамеренных утечек обеспечивают BGP Role и механизмы предотвращения утечек маршрутов, описанные в RFC 9234. Однако их применение зависит от поддержки на обеих сторонах соединения.

Если организация использует два подключения только ради резервного выхода в интернет, собственная автономная система и полноценная таблица BGP могут оказаться избыточными. Иногда достаточно двух маршрутов по умолчанию с проверкой работоспособности каналов.

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

Завершаем работу лаборатории

После экспериментов можно сохранить изменённые конфигурации средствами Containerlab, если настройки менялись интерактивно. Перед повторным развёртыванием учитывайте, что сохранённая работающая конфигурация может отличаться от исходных файлов startup-config.

Для полного удаления лабораторных контейнеров выполните.

sudo containerlab destroy -t bgp.clab.yml --cleanup

Исходные файлы топологии и конфигураций в рабочем каталоге останутся доступными для последующих экспериментов.

Частые вопросы о настройке BGP

Можно ли настроить BGP без собственного публичного ASN?

Да. Для лабораторий подходят частные ASN. Некоторые провайдеры также предлагают варианты BGP-подключения с частным ASN клиента, но правила анонсирования, обработки AS_PATH и доступность многопровайдерной схемы необходимо согласовать с оператором. Для независимого присутствия в глобальной маршрутизации обычно требуется собственный публичный ASN и соответствующая адресная политика.

Нужно ли получать полную таблицу маршрутов интернета от провайдеров?

Нет. Если требуется главным образом резервирование интернет-доступа, можно получать только маршрут 0.0.0.0/0 от каждого провайдера и задавать приоритеты. Полная таблица полезна для детального управления исходящей маршрутизацией, но увеличивает требования к памяти, процессору и операционной поддержке маршрутизатора.

Сколько времени BGP переключает трафик на резервный канал?

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

Почему команда network не объявляет IP-префикс?

При включённом network import-check FRRouting требует наличия соответствующего маршрута в локальной таблице маршрутизации. Также нужно проверить активность нужного адресного семейства, исходящие фильтры и состояние BGP-соседа. Само присутствие команды network ещё не гарантирует, что другой маршрутизатор получит объявление.

Можно ли распределить трафик между двумя провайдерами поровну?

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

В чём разница между LOCAL_PREF и административной дистанцией?

LOCAL_PREF помогает выбирать предпочтительный маршрут внутри BGP. Административная дистанция участвует в выборе между маршрутами, полученными из разных источников, например BGP, OSPF и статической конфигурации. Больший LOCAL_PREF не означает, что маршрут обязательно победит более предпочтительный статический маршрут.

Почему AS_PATH prepend не меняет входящий трафик?

Удалённые автономные системы самостоятельно выбирают лучшие маршруты. LOCAL_PREF, операторские политики и доступность альтернативных путей могут иметь большее значение, чем длина AS_PATH. Поэтому prepend является способом повлиять на выбор, но не гарантирует результат. Проверять эффект нужно по маршрутам из внешних сетей и по реальному распределению входящего трафика.

Может ли BGP работать без OSPF или другого внутреннего протокола?

Да. В небольшой сети с непосредственно подключёнными соседями или статическими маршрутами отдельный IGP может не понадобиться. Но в крупной автономной системе внутренний протокол маршрутизации обычно нужен для доступности адресов маршрутизаторов, NEXT_HOP и устойчивой работы iBGP.

Подходит ли FRRouting для промышленной эксплуатации?

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

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

Следующий шаг состоит в настройке LOCAL_PREF для исходящего трафика и AS_PATH prepend для попытки повлиять на входящий. Затем стоит отключить основной канал и посмотреть, как меняются маршруты с обеих сторон соединения. Такой эксперимент быстро показывает границы возможностей BGP.

Для реальной компании с двумя провайдерами разумно сначала определить требования к резервированию, собственному адресному пространству и управлению входящими соединениями. Если достаточно автоматического переключения обычного интернет-доступа, полноценный BGP может оказаться лишней сложностью. Если требуется независимая маршрутизация собственного префикса через нескольких операторов, FRRouting даёт необходимые механизмы, но качество результата будет зависеть от фильтрации, согласованных политик и проверки отказов в реальной сети.

Сначала найти, потом защитить: с чего начинается работа с данными. Узнайте на вебинаре PT Data Security 10 ноября.