Border Gateway Protocol — настройка и принципы работы
Количество интеллектуальных устройств, подключенных к интернету, достигает беспрецедентного уровня. По оценке Cisco Umbrella, в 2020 году к сети было подключено около 75 миллиардов устройств. Вся сетевая структура, на которой держится интернет, является довольно хрупкой, и в значительной степени построена на основных протоколах интернета — DNS (службы доменных имен) и BGP (протокол пограничного шлюза) — о которых и пойдет речь в сегодняшней статье.
Содержание:
1. Что такое BGP?
1.1. Терминология протокола, краткая сетевая теория
2. Основные характеристики BGP
3. Принцип работы BGP-протокола
4. Настройка BGP
4.1. Как контролировать входящий трафик при BGP-маршрутизации?
5. Настройка BGP Community Strings
5.1. Конфигурация BGP community на маршрутизаторе R1
5.2. Конфигурация BGP community на R2
6. Проверка таблиц BGP-маршрутизаторов провайдера
6.1. Настройка local preference на PE-1
6.2. Настройка local preference на PE-2
6.3. Ограничения BGP протокола, применение в мире
Заключение
1. Что такое BGP?
Единственный протокол пограничного шлюза (BGP) — это стандартизированный протокол внешнего шлюза (EGP), в отличие от RIP, OSPF и EIGRP (IGP), призванный «разруливать», к примеру, контроль входящего трафика за счет балансировки нагрузок на маршрутизаторы от внешних автономных систем.
1.1. Терминология протокола, краткая сетевая теория
BGP — дистанционно-векторный протокол маршрутизации, созданный для маршрутизации между AS (автономная система). Поддерживает отдельную таблицу маршрутизации на основе кратчайшего пути к AS назначения (в отличие от показателей протокола IGP, таких, как distance или cost).
Автономным системам BGP присваивается номер автономной системы — ASN, представляющий собой 16-битное число в диапазоне от 1 до 65 535. Протокол использует TCP для надежной передачи своих пакетов через порт 179.
Вопреки распространенному ошибочному мнению, BGP не является обязательным, когда требуется несколько подключений к интернету. Отказоустойчивость или избыточность исходящего трафика легко обеспечивается IGP, например OSPF или EIGRP. В интернете насчитывается сотни тысяч маршрутов, и внутренние маршрутизаторы не должны быть излишне обременены.
Истинное преимущество BGP заключается в контроле того, как именно трафик входит в локальную AS.
2. Основные характеристики BGP
Пиры BGP (соседи)
Для устойчивого функционирования BGP-маршрутизаторы (называемые пирами) должны формировать отношения соседства (называемые одноранговыми пирами).
Существует два типа соседских отношений BGP:
- iBGP-пиры — соседи BGP в пределах одной автономной системы.
- eBGP-пиры — соседи BGP, соединяющие отдельные автономные системы.
Как только одноранговые узлы BGP формируют отношения соседства, они совместно используют полную таблицу маршрутизации. После этого одноранговым узлам передаются только изменения в таблице маршрутизации посредством сообщений Update.
По умолчанию BGP предполагает, что одноранговые узлы eBGP находятся на расстоянии не более одного перехода (хопа).
Это ограничение можно обойти, используя опцию ebgp-multihop с командой Neighbor.
Одноранговые узлы iBGP не имеют ограничений на переходы и зависят от базового протокола IGP AS для соединения одноранговых узлов друг с другом.
BGP формирует одноранговые отношения с помощью серий сообщений. Вначале любой сессии одноранговые узлы отправляют сообщение OPEN, чтобы инициировать сеанс. Сообщение OPEN содержит несколько параметров:
- Версия BGP — должна быть одинаковой для узлов BGP, на деле она практически всегда одинаковая.
- ASN — номер автономной системы.
- Router ID — идентификатор маршрутизатора BGP.
3. Принцип работы BGP-протокола
По мере формирования однорангового сеанса BGP он проходит через несколько состояний. Этот процесс известен как FSM (Finite State Machine) — модель конечного состояния BGP. FSM — это описание того, какие действия и когда должны выполняться механизмом маршрутизации BGP. В модели есть шесть состояний, и есть определенные условия, при которых каждое состояние BGP перейдет к следующему.
- Idle — начальное состояние BGP.
- Connect — BGP ожидает установления TCP-соединения с удаленным узлом. В случае успеха отправляется сообщение OPEN. В случае неудачи сеанс переводится в состояние Active.
- Active — BGP пытается инициировать TCP-соединение с удаленным узлом. В случае успеха отправляется сообщение OPEN. В случае неудачи BGP будет ждать, пока истечет время таймера ConnectRetry, и вернет сеанс в состояние Connect.
- OpenSent — BGP установил TCP-соединение и отправил сообщение OPEN, после чего ожидает ответа на сообщение OPEN. Получив ответное сообщение OPEN, узел BGP отправит сообщение KEEPALIVE.
- OpenConfirm — BGP прослушивает ответное сообщение KEEPALIVE.
- Established – одноранговый сеанс BGP полностью установлен. Теперь будут отправляться сообщения UPDATE, содержащие информацию о маршрутизации.
Если сеанс застрял в состоянии Active, потенциальные проблемы могут быть из-за:
- отсутствия IP-подключения (нет маршрута к хосту);
- неверного оператор соседа;
- списка доступа, фильтрующего TCP-порт 179.
Сообщения узлов BGP:
KEEPALIVE — отправляются каждые 60 секунд по умолчанию, чтобы убедиться, что удаленный одноранговый узел по-прежнему доступен. Если маршрутизатор не получает KEEPALIVE в течение периода HOLD-TIME (по умолчанию 180 секунд), маршрутизатор объявляет этот одноранговый узел мертвым.
UPDATE — используются для обмена маршрутами между узлами и сообщают об имеющихся изменениях в маршруте (динамическая перестройка маршрутов).
NOTIFICATION — отправляются при возникновении фатальной ошибки состояния. Если отправлено сообщение NOTIFICATION, одноранговый сеанс BGP прерывается и сбрасывается.
4. Настройка BGP
Конфигурация в задаче выполняется на Router A, и ее необходимо повторить с соответствующими изменениями IP-адресов на Router B, чтобы полностью реализовать процесс BGP между устройствами (схема работы показана на картинке ниже).
Задаем номер автономной системы:
Device(config)# router bgp 40000
Для внешних протоколов команда network определяет, какие сети объявляются. Внутренние протоколы используют эту команду, чтобы определить, куда отправлять сообщения update:
Device(config-router)# network 10.1.1.0 mask 255.255.255.0
Задаем ip-адрес в качестве аргумента router-id:
Device(config-router)# bgp router-id 10.1.1.99
Теперь задаем keepalive 70 — время, через которое ПО отправляет сообщения проверки активности своему узлу BGP. По умолчанию таймер проверки активности установлен на 60 секунд. holdtime 120 – время, по истечении которого ПО, не получив сообщения проверки активности, объявляет одноранговый узел BGP недействующим. По умолчанию таймер удержания установлен на 180 секунд:
Device(config-router)# timers bgp 70 120
Некоторые функции, такие как bgp log-neighbor-changes (логирование перезапуска соседей) и bgp fast-external-fallover (немедленный сброс однорангового узла при выходе из строя его канала), включены по умолчанию (здесь представлены в явной форме для лучшего понимания того, как работает BGP).
По умолчанию сеансы внешних соседних одноранговых узлов BGP сбрасываются, если канал, используемый для их связи, выходит из строя:
Device(config-router)# bgp fast-external-fallover
Это включает регистрацию изменений состояния BGPneighborstatus (up или shutdown) и сбросов соседей.
Неожиданные сбросы соседей свидетельствуют о высокой частоте ошибок или потерях пакетов в сети и должны быть исследованы. Используем эту команду для устранения проблем с сетевым подключением и измерения стабильности сети:
Device(config-router)# bgp log-neighbor-changes
После того как задача решена, в таблице BGProuting маршрутизатора A мы можем увидеть запись для сети 10.1.1.0, которая является локальной для этой AS.
4.1. Как контролировать входящий трафик при BGP-маршрутизации?
Когда пакеты приходят в клиентскую сеть несколькими способами, сетевые операторы должны контролировать это поведение по ряду причин. Например, клиент в AS6400 может иметь uplink со своим провайдером в AS6500.
Из соображений избыточности AS6400 может захотеть иметь еще один uplink, который будет использоваться только в качестве резервного канала. Контроль за входящим трафиком здесь приобретает первостепенное значение, так как любой трафик, генерируемый по этому звену при нормальной работе, стоит денег клиента.
Если у нас нет специального соглашения с провайдерами, с которыми мы взаимодействуем, изменить поток входящего трафика гораздо сложнее, чем повлиять на исходящий трафик. Для исходящего трафика клиенты могут локально влиять на алгоритм выбора наилучшего пути, поскольку у них есть граничные маршрутизаторы.
Чтобы влиять на путь входящего трафика, клиенты могут использовать определенные атрибуты в обновлениях, отправляемых их провайдерам (например, MED, AS-PATH, Community Strings, и т.д.). В этой статье мы рассмотрим только метод на основе атрибута Community Strings.
BGP communities — это транзитивный атрибут, который может передаваться от одной AS к другой AS. Этот метод требует дополнительной настройки на стороне провайдера local preference для маршрутов, на основе сопоставления с community strings.
5. Настройка BGP Community Strings
BGP предпочитает маршрут с более высоким local preference маршруту с более низким local preference. Провайдер (AS6500) настраивает local preference 200 на маршрутизаторе PE-1 для префикса клиента 190.0.0.0/16, полученного от однорангового узла eBGP R1 и помеченного community 200.
Аналогично, интернет-провайдер устанавливает local preference 300 на PE-2 для того же префикса 190.0.0.0/16, полученного от его равноправного узла eBGP R2 и помеченного community 300. Маршрутизатор PE-1 выберет лучший путь к префиксу 190.0.0.0/16 через соседнего iBGP PE- 2.
Важно понимать, что local preference является локальным и распространяется только внутри нашей AS. Таким образом, когда маршрутизатор ISP PE-1 в AS6500 узнает префикс 190.0.0.0/16 от соседа R1 в AS6400, Update не будет содержать атрибут LOCAL_PREF. Но когда маршрутизатор PE-2 распространяет префикс 190.0.0.0/16 к соседнему iBGP PE-1 в локальной сети AS6500, Update содержит атрибут LOCAL_PREF со значением 300.
При этом важно знать, что значение по умолчанию для local preference равно 100.
5.1. Конфигурация BGP community на маршрутизаторе R1
Давайте настроим маршрутизатор клиента R1 (AS6400) для отправки префикса 190.0.0.0/16 на маршрутизатор ISP PE-1 с подключенным community 6400:200.
- Используем набор префиксов CUST-PS, который соответствует 190.0.0.0/16
- Задаем community ISP-CS со значением 6400:200. Первые 16 бит представляют AS происхождения community (AS6400), а вторые 16 бит представляют шаблон, определенный AS6400:
- Политика маршрутизации COMM-RPL соответствует префиксу клиента CUST-PS и устанавливает ISP-CS community. Политика маршрута пропускает несоответствующие префиксы без изменения их атрибутов:
- Применяем политику маршрутизации COMM-RPL к соседу eBGP 11.0.0.2 (PE-1) для исходящего маршрута. В отличие от Cisco IOS, в IOS-XR как стандартные, так и расширенные community отправляются по умолчанию в сеансах iBGP, но не в сеансах eBGP. Следовательно, нам необходимо задать send-community-ebgp и для узла eBGP PE-1:
5.2. Конфигурация BGP community на R2
Конфигурация BGP community на клиентском маршрутизаторе R2 аналогична конфигурации на R1 (смотрите выше 1, 3, 4 пункты). Нам нужно создать список префиксов, набор BGP community и route-map, соответствующие списку префиксов и настроить набор community.
После этого мы можем настроить политику маршрутизации для PE-1 и применить ее к исходящим маршрутам. Также необходимо разрешить community отправлять сообщения на узел eBGP PE-1.
Разница со 2 пунктом на R1:
Разница с 4 пунктом R1:
6. Проверка таблиц BGP-маршрутизаторов провайдера
оскольку оба маршрута имеют одинаковое значение LOCAL_PREF, равное 100, PE1 предпочитает маршрут eBGP, полученный от R1, маршруту iBGP, полученному от PE-2 (рисунок ниже).
аршрут 190.0.0.0/16 через next-hop 11.0.0.1 (R1) установлен в таблице маршрутизации PE-1.
Маршрутизатор PE-2 установил полученный маршрут 190.0.0.0/16 от узла eBGP R2 в свою таблицу BGP. Маршрут помечен community 6400:300 и имеет значение LOCAL_PREF, равное 100. В таблице BGP PE-2 установлен еще один маршрут, полученный от однорангового узла iBGP PE-1. Этот маршрут помечен community 6400:200 и имеет значение LOCAL_PREF по умолчанию, равное 100.
Процесс BGP, запущенный на маршрутизаторе PE-2, выбирает путь к префиксу 190.0.0.0/16 через одноранговый узел eBGP R2 как лучший путь, поскольку маршруты eBGP предпочтительнее маршрутов iBGP.
6.1. Настройка local preference на PE-1
Настроим PE-1 для изменения local preference на 200 для маршрута 190.0.0.0/16, когда этот маршрут получен от однорангового узла eBGP R1, помеченного community 6400:200.
Во-первых, настроим PE-1 для отображения BGP community в новом формате AA:NN:
Во-вторых, создадим префиксный список CUST-PL, соответствующий префиксу 190.0.0.0/16:
Нам также необходимо создать два стандартных community-list:
Карта маршрутов CUST-PREF-RM соответствует префиксу CUST-PL и community-list. Значения local preference устанавливаются на основе совпадающего списка префиксов и community-list. Если эти атрибуты не совпадают, route-map 30 разрешает маршруты без изменения их атрибутов.
Последний шаг состоит в применении карты маршрутов CUST-PREF-RM для входящего трафика к узлу eBGP R1 и узлу iBGP PE-2.
6.2. Настройка local preference на PE-2
На данном маршрутизаторе произведем идентичные настройки, как и на PE-1, за исключением крайнего шага. Применяем карту маршрутов CUST-PREF-RM к одноранговому узлу eBGP R2 и к входящему узлу iBGP PE-1.
И напоследок, проверяем таблицу BGP PE-1:
6.3. Ограничения BGP протокола, применение в мире
За последние пару десятилетий произошел ряд событий, которые прекрасно иллюстрируют, что происходит, когда BGP дает сбой. Независимо от того, вызвано ли это злонамеренными злоумышленниками или случайно из-за маршрутизации утечек, эффект, по сути, один и тот же.
BGP как протокол содержит в себе критическую особенность, заключающуюся в его способности воздействовать почти на все основные интернет-службы. Но самое удивительное в протоколе, отвечающем за маршрутизацию почти всего интернет-трафика, заключается в том, что он работает на основе системы полного доверия между провайдерами.
Каждая AS сообщает остальной части интернета через своих соседей, от каких IP-сетей она готова получать трафик.
Анонс — это способ разместить рекламный баннер на супермагистрали в интернете, чтобы сказать: «Эй, я Vodafone! И я здесь!». Затем маршрутизаторы используют эту информацию для поиска наилучшего маршрута к этой компании.
Этот процесс важен, потому что в качестве ограничений есть объявления, которые должны оставаться только между двумя AS. Когда одна из этих AS неправильно распространяет объявление о префиксах в мире, это называется «утечкой». Утечки случаются довольно регулярно и обычно связаны с ошибкой конфигурации.
Похожая проблема — взлом BGP. При утечке BGP AS вставляет себя в середину пути, но при перехвате AS просто заявляет, что владеет префиксами и должна получать весь трафик для него.
19 Апреля 2021 года из-за утечки маршрутов BGP тысячи крупных сайтов и сетей по всему миру оказались недоступными. Инцидент произошел с автономной системой Vodafone (AS55410) в Индии, но затронул крупные компании в США, включая Google.
Инцидент длился 10 минут, но и этого времени было достаточно, чтобы заставить пользователей по всему миру испытать трудности с подключением к интернет-ресурсам.
Заключение
BGP является единственным протоколом внешней маршрутизации, у которого достаточно обширная зона ответственности, так как на сегодняшний день записей маршрутизации BGP насчитывается около 900 тысяч. Безусловно, как и у любого механизма у данного протокола есть уязвимые места.
Конкретно в нашем примере с Community Strings мы разобрались и погрузились в логику разгрузки маршрутизаторов от избыточности, а также показали эффективное использование резервных точек подключения с провайдерами. Для дополнительной пользы от данной статьи рекомендуем посмотреть следующее тематическое видео на YouTube:
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: