Количество интеллектуальных устройств, подключенных к интернету, достигает беспрецедентного уровня. По оценке 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 протокола, применение в мире
Заключение
Единственный протокол пограничного шлюза (BGP) — это стандартизированный протокол внешнего шлюза (EGP), в отличие от RIP, OSPF и EIGRP (IGP), призванный «разруливать», к примеру, контроль входящего трафика за счет балансировки нагрузок на маршрутизаторы от внешних автономных систем.
BGP — дистанционно-векторный протокол маршрутизации, созданный для маршрутизации между AS (автономная система). Поддерживает отдельную таблицу маршрутизации на основе кратчайшего пути к AS назначения (в отличие от показателей протокола IGP, таких, как distance или cost).
Автономным системам BGP присваивается номер автономной системы — ASN, представляющий собой 16-битное число в диапазоне от 1 до 65 535. Протокол использует TCP для надежной передачи своих пакетов через порт 179.
Вопреки распространенному ошибочному мнению, BGP не является обязательным, когда требуется несколько подключений к интернету. Отказоустойчивость или избыточность исходящего трафика легко обеспечивается IGP, например OSPF или EIGRP. В интернете насчитывается сотни тысяч маршрутов, и внутренние маршрутизаторы не должны быть излишне обременены.
Истинное преимущество BGP заключается в контроле того, как именно трафик входит в локальную AS.
Для устойчивого функционирования BGP-маршрутизаторы (называемые пирами) должны формировать отношения соседства (называемые одноранговыми пирами).
Существует два типа соседских отношений BGP:
Как только одноранговые узлы BGP формируют отношения соседства, они совместно используют полную таблицу маршрутизации. После этого одноранговым узлам передаются только изменения в таблице маршрутизации посредством сообщений Update.
По умолчанию BGP предполагает, что одноранговые узлы eBGP находятся на расстоянии не более одного перехода (хопа).
Это ограничение можно обойти, используя опцию ebgp-multihop с командой Neighbor.
Одноранговые узлы iBGP не имеют ограничений на переходы и зависят от базового протокола IGP AS для соединения одноранговых узлов друг с другом.
BGP формирует одноранговые отношения с помощью серий сообщений. Вначале любой сессии одноранговые узлы отправляют сообщение OPEN, чтобы инициировать сеанс. Сообщение OPEN содержит несколько параметров:
По мере формирования однорангового сеанса BGP он проходит через несколько состояний. Этот процесс известен как FSM (Finite State Machine) — модель конечного состояния BGP. FSM — это описание того, какие действия и когда должны выполняться механизмом маршрутизации BGP. В модели есть шесть состояний, и есть определенные условия, при которых каждое состояние BGP перейдет к следующему.
Если сеанс застрял в состоянии Active, потенциальные проблемы могут быть из-за:
Сообщения узлов BGP:
KEEPALIVE — отправляются каждые 60 секунд по умолчанию, чтобы убедиться, что удаленный одноранговый узел по-прежнему доступен. Если маршрутизатор не получает KEEPALIVE в течение периода HOLD-TIME (по умолчанию 180 секунд), маршрутизатор объявляет этот одноранговый узел мертвым.
UPDATE — используются для обмена маршрутами между узлами и сообщают об имеющихся изменениях в маршруте (динамическая перестройка маршрутов).
NOTIFICATION — отправляются при возникновении фатальной ошибки состояния. Если отправлено сообщение NOTIFICATION, одноранговый сеанс 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.
Когда пакеты приходят в клиентскую сеть несколькими способами, сетевые операторы должны контролировать это поведение по ряду причин. Например, клиент в AS6400 может иметь uplink со своим провайдером в AS6500.
Из соображений избыточности AS6400 может захотеть иметь еще один uplink, который будет использоваться только в качестве резервного канала. Контроль за входящим трафиком здесь приобретает первостепенное значение, так как любой трафик, генерируемый по этому звену при нормальной работе, стоит денег клиента.
Если у нас нет специального соглашения с провайдерами, с которыми мы взаимодействуем, изменить поток входящего трафика гораздо сложнее, чем повлиять на исходящий трафик. Для исходящего трафика клиенты могут локально влиять на алгоритм выбора наилучшего пути, поскольку у них есть граничные маршрутизаторы.
Чтобы влиять на путь входящего трафика, клиенты могут использовать определенные атрибуты в обновлениях, отправляемых их провайдерам (например, MED, AS-PATH, Community Strings, и т.д.). В этой статье мы рассмотрим только метод на основе атрибута Community Strings.
BGP communities — это транзитивный атрибут, который может передаваться от одной AS к другой AS. Этот метод требует дополнительной настройки на стороне провайдера local preference для маршрутов, на основе сопоставления с 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.
Давайте настроим маршрутизатор клиента R1 (AS6400) для отправки префикса 190.0.0.0/16 на маршрутизатор ISP PE-1 с подключенным community 6400:200.
Конфигурация BGP community на клиентском маршрутизаторе R2 аналогична конфигурации на R1 (смотрите выше 1, 3, 4 пункты). Нам нужно создать список префиксов, набор BGP community и route-map, соответствующие списку префиксов и настроить набор community.
После этого мы можем настроить политику маршрутизации для PE-1 и применить ее к исходящим маршрутам. Также необходимо разрешить community отправлять сообщения на узел eBGP PE-1.
Разница со 2 пунктом на R1:
Разница с 4 пунктом R1:
оскольку оба маршрута имеют одинаковое значение 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.
Настроим 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.
На данном маршрутизаторе произведем идентичные настройки, как и на PE-1, за исключением крайнего шага. Применяем карту маршрутов CUST-PREF-RM к одноранговому узлу eBGP R2 и к входящему узлу iBGP PE-1.
И напоследок, проверяем таблицу BGP PE-1:
За последние пару десятилетий произошел ряд событий, которые прекрасно иллюстрируют, что происходит, когда BGP дает сбой. Независимо от того, вызвано ли это злонамеренными злоумышленниками или случайно из-за маршрутизации утечек, эффект, по сути, один и тот же.
BGP как протокол содержит в себе критическую особенность, заключающуюся в его способности воздействовать почти на все основные интернет-службы. Но самое удивительное в протоколе, отвечающем за маршрутизацию почти всего интернет-трафика, заключается в том, что он работает на основе системы полного доверия между провайдерами.
Каждая AS сообщает остальной части интернета через своих соседей, от каких IP-сетей она готова получать трафик.
Анонс — это способ разместить рекламный баннер на супермагистрали в интернете, чтобы сказать: «Эй, я Vodafone! И я здесь!». Затем маршрутизаторы используют эту информацию для поиска наилучшего маршрута к этой компании.
Этот процесс важен, потому что в качестве ограничений есть объявления, которые должны оставаться только между двумя AS. Когда одна из этих AS неправильно распространяет объявление о префиксах в мире, это называется «утечкой». Утечки случаются довольно регулярно и обычно связаны с ошибкой конфигурации.
Похожая проблема — взлом BGP. При утечке BGP AS вставляет себя в середину пути, но при перехвате AS просто заявляет, что владеет префиксами и должна получать весь трафик для него.
19 Апреля 2021 года из-за утечки маршрутов BGP тысячи крупных сайтов и сетей по всему миру оказались недоступными. Инцидент произошел с автономной системой Vodafone (AS55410) в Индии, но затронул крупные компании в США, включая Google.
Инцидент длился 10 минут, но и этого времени было достаточно, чтобы заставить пользователей по всему миру испытать трудности с подключением к интернет-ресурсам.
BGP является единственным протоколом внешней маршрутизации, у которого достаточно обширная зона ответственности, так как на сегодняшний день записей маршрутизации BGP насчитывается около 900 тысяч. Безусловно, как и у любого механизма у данного протокола есть уязвимые места.
Конкретно в нашем примере с Community Strings мы разобрались и погрузились в логику разгрузки маршрутизаторов от избыточности, а также показали эффективное использование резервных точек подключения с провайдерами. Для дополнительной пользы от данной статьи рекомендуем посмотреть следующее тематическое видео на YouTube:
Сегодня мы поговорим о том, как выбрать лучшие курсы Power BI в Украине, особенно для…
В 2023 году во всех крупнейших регионах конкуренция за вакансию выросла на 5–12%. Не исключением…
Unicorn Hunter/Talent Manager Лина Калиш создала бесплатный трекер поиска работы в Notion, систематизирующий все этапы…
Edtech-стартап Mate academy принял решение отправить своих работников в десятидневный отпуск – с 25 декабря…
Служба безопасности Украины задержала в Киеве 46-летнего программиста, который за деньги устанавливал шпионские программы и…
IT-специалист Джордан Катлер создал и выложил на Github подборку разнообразных ресурсов, которые помогут достичь уровня…
