1. Главная страница » Компьютеры

Bgp сессия что это

Автор: | 16.12.2019

BGP (англ. Border Gateway Protocol , протокол граничного шлюза) — динамический протокол маршрутизации.

Относится к классу протоколов маршрутизации внешнего шлюза (англ. EGP — External Gateway Protocol).

BGP
Название Border Gateway Protocol
Семейство TCP/IP
Порт/ID 179/TCP
Назначение протокола Протокол динамической маршрутизации
Спецификация RFC 4271
Основные реализации (клиенты) Cisco IOS, Juniper JunOS, Bird, OpenBGPD, Quagga, Huawei VRP, Mikrotik RouterOS, frrouting

На текущий момент является основным протоколом динамической маршрутизации в сети Интернет.

Протокол BGP предназначен для обмена информацией о достижимости подсетей между автономными системами (АС, англ. AS — autonomous system), то есть группами маршрутизаторов под единым техническим и административным управлением, использующими протокол внутридоменной маршрутизации для определения маршрутов внутри себя и протокол междоменной маршрутизации для определения маршрутов доставки пакетов в другие АС. Передаваемая информация включает в себя список АС, к которым имеется доступ через данную систему. Выбор наилучших маршрутов осуществляется исходя из правил, принятых в сети.

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

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

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

Содержание

Формат сообщения [ править | править код ]

Сообщение BGP начинается с заголовка, после которого, в зависимости от типа сообщения, могут следовать данные. Максимальная длина сообщения — 4096 октетов, минимальная — 19 октетов. Заголовок сообщения содержит следующие поля:

  • Маркер (16 октетов) — используется для совместимости, должен быть заполнен единицами;
  • Длина (2 октета) — длина сообщения в октетах, включая заголовок;
  • Тип (1 октет):
  • 1 — Открытие;
  • 2 — Обновление информации;
  • 3 — Оповещение;
  • 4 — Сохранение соединения.

Открытие [ править | править код ]

Первое сообщение после установки соединения должно быть «Открытие». Если сообщение успешно обработано, в ответ будет послано «Сохранение соединения». В дополнение к заголовку BGP сообщение «Открытие» содержит следующие поля:

  • Версия (1 октет) — версия протокола, текущее значение 4;
  • Моя система (2 октета) — номер автономной системы;
  • Интервал времени (2 октета) — максимальный интервал времени в секундах между получением сообщений «Обновление информации» или «Сохранение соединения»;
  • Идентификатор отправителя (4 октета) — устанавливается равным IP-адресу;
  • Длина дополнительных параметров (1 октет);
  • Дополнительные параметры:
  • Тип параметра (1 октет);
  • Длина параметра (1 октет);
  • Значение параметра.

Обновление информации [ править | править код ]

Сообщение «Обновление информации» предназначено для передачи информации о маршрутах между АС. Сообщение может указывать новые маршруты и удалять неработающие. Структура сообщения:

Флаги атрибутов

Бит Значение
0 1 – дополнительный, 0 – стандартный
1 1 – транзитивный (для стандартных всегда 1)
2 1 – информация частичная, 0 – полная
3 1 – поле длины атрибута два октета, 0 – один октет
4 не используются, должны быть 0
5
6
7
  • Длина удаляемых маршрутов (2 октета);
  • Удаляемые маршруты:
  • Длина (1 октет) — длина в битах префикса IP-адреса;
  • Префикс IP-адреса, дополненный минимальным количеством бит до полного октета;
  • Длина атрибутов пути (2 октета);
  • Атрибуты пути:
    • Тип атрибута:
      • Флаг атрибута;
      • Код атрибута;
      • Длина атрибута (1 или 2 октета, в зависимости от флага);
      • Данные атрибута;
      • Информация о достижимости — список префиксов IP-адресов:
        • Длина (1 октет) — длина в битах префикса IP-адреса (нулевая длина — соответствие всем IP-адресам);
        • Префикс IP-адреса, дополненный минимальным количеством бит до полного октета.
        • Все атрибуты пути соответствуют всем записям в поле «Информация о достижимости».

          Сохранение соединения [ править | править код ]

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

          Оповещение [ править | править код ]

          Оповещение посылается в случае обнаружения ошибки, при этом соединение закрывается. Сообщение содержит следующие поля:

          • Код ошибки (1 октет);
          • Субкод (1 октет);
          • Данные.

          Процесс выбора [ править | править код ]

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

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

          Ну-с, приступим? Для начала простое — настройка интерфейсов.



          Назначим и Loopback-интерфейсу какой-нибудь адрес, чтобы далее проверить связность:

          А теперь самое вкусное — настройка BGP. Будем разбирать каждую строчку.

          Сначала поднимаем процесс BGP и назначаем AS Number, именно тот, что выдал нам LIR!
          Далее настраиваем пиринг, задаем информацию о соседе:

          Командой neighbor мы указываем того, с кем будем поднимать сессию. На указанный адрес 101.0.0.1 наш маршрутизатор последовательно отправит сначала TCP-SYN, а затем OPEN-сообщение. Здесь же указываем номер автономки, с которой у нас намечается пиринг — AS64501.
          Абсолютно симметричная конфигурация на противоположной стороне:

          В CLI появится сообщение:

          Ура? Ура, но проверим состояние процесса.

          Одно состояние сменяет другое и вот достигнут Established. Маршрутизатор за это время отправил одно OPEN-сообщение и аналогичное получил, а также получил и принял по два KEEPALIVE.
          Проверим о каких сетях знает BGP.
          sh ip bgp

          Ни-че-го. Смотрим на R2.

          И тут тоже самое.
          А всё тут просто. До прописанной командой network сети должен быть точный маршрут, в противном случае она не окажется в таблице BGP. А муршрута нет:

          А его и вписывать некуда, кроме разве что Loopback-интерфейса. Ну нет нигде этой сети. Исхитримся так:

          Маршрут говорит нам, что пакеты идущие в эту сеть будут дропнуты. Но это по плану, так надо. Просто напросто при наличии более конкретных маршрутов (маска больше /23, т.е. /24. /30. /32), то следуя правилу Longest Prefix Match будут выбираться именно они.
          Радуемся. В BGP-таблице отобразился локальный маршрут:

          Теперь если мы настроим процесс BGP и нужные маршруты на всех устройствах нашей схемы, то таблички BGP и маршрутизации на бордере (border — пограничный маршрутизатор сети) станет такой:



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

          Мимо данной темы в контексте BGP и подключения к прову попросту невозможно пройти. Вот наша уютная компания уже имеет AS Number и вооружилась ворохом PI-адресов. При организации стыка с провайдером Балаган-Телеком нас строго спросят — "будем фулл вью или ограничимся дефолтом?"
          Всё, что было у нас выше — это Full View. Маршрутизатор будет изучать все без исключения маршруты Интернета. Наш теоретический случай предусматривает штук пять-шесть маршрутов, но в действительности их более 400000. В итоге нам и один провайдер анонсирует 400 тысяч маршрутов и другой столько же. А вдруг будет еще резервный пров? Получите распишитесь, в итоге больше миллиона маршрутов.
          Ну, и чего теперь, отваливать сотни нефти за мощную циску?

          Вот так выглядит саммари маршрутной таблицы route-server.ip.att.net, одного публичного сервера. Можно стучаться телнетом.
          По факту не всем автономкам нужно курить Full View, даже более-менее крупным компаниям достаточно Default Route и погнали. Идея простая. Вместо вороха точных маршрутов нам приходит по одному маршруту по-умолчанию от каждого из провайдеров. Впрочем, это может происходить не только вместо, но и вместе.
          Разберемся в плюсах и минусах обоих случаев.
          При работе с Full View вся структура интернета у вас перед глазами. Вы можете посмотреть трассу от себя до любого адреса глобальной сети:

          И вы знаете, какие AS ведут к сети назначения, а RIPE позволяет узнать, какие провайдеры обеспечивают передачу. И мы можем без проблем следить за всеми изменениями сети. Даже если где-то далеко на крайних хопах у кого-то что-то отвалится (т.е. не обязательно у вас или одного из ваших провайдеров), BGP обнаружит это и перестроит таблицу маршрутизации в соответствии с изменением топологии, например, пустит трафик через второго провайдера.
          И мы вольны гибко рулить маршрутами, тонко настраивая алгоритм выбора наилучшего пути. Допустим, трафик до яндекса мы будем пускать через "Балаган Телеком", а вот уже до гугла — через "Филькин Сертификат". Это будет load balancing — распределение нагрузки.
          Сделать это можно, например, путем настройки приоритета маршрутов для определенных префиксов.
          Ваш выбор без вариантов Full View, если ваша AS транзитная, т.е. к вам по BGP будут подключены еще клиенты.
          Плюсов много, но расплатой здесь будет производительность. Готовьтесь к высокой утилизации оперативки и долгому изучению маршрутной информации после подъема BGP-сессии. Например, даже при кратковременном падении линка до вышестоящего провайдера на полное восстановление уйдет несколько минут.
          А теперь Default Route. В первую очередь — это огромная экономия ресурсов нашего оборудования. Обслуживать тоже проще, больше нет задачи гонять тысячи и тысячи маршрутов внутри нашей AS. С другой стороны вы понятия не имеете о состоянии интернетов и доступности конечных узлов — вы тупо шлете трафик на дефолт, прилетевший от провайдера, апстрима (upstream). И если проблема где-то дальше, вы о ней не будете иметь понятия, а как следствие падение части предоставляемых сервисов. В этом месте мы отдаем всё на откуп вышестоящему провайдеру, надеясь, что там BGP быстренько перестроится и снова всё взлетит.
          Балансировка и распределение входящего трафика не пострадает, мы этим сможем рулить, а вот управление исходящим накроется.

          Давайте резюмировать. Если у вас нет цели гонять через себя транзитный трафик (подключать через себя другие AS) и не требуется гибкое распределение исходящего трафика, то вам дорога к Default Route.
          Но вот точно не имеет смысла принимать от одного провайдера анонсы Full View, а от другого Default Route, т.к. один линк всегда будет простаивать и не станет гонять через себя исходящий трафик, ведь выбираться будет более специфический маршрут, который точно найдется среди анонсированного вам Full View.
          Но ничего не мешает брать от всех провов Default Route и в нагрузку определенные префиксы (конкретно этого провайдера, например). Тогда до нужных ресурсов у вас будут специфические маршруты, но при этом без Full View.
          Взглянем на пример настройки Default Route для линка в нижестоящему маршрутизатору:

          Тогда на нашем бордере таблица маршрутов будет такой:

          Теперь кроме обычных входящих в Full View маршрутов будет присутствовать и маршрут по-умолчанию.

          И еще маленькое отступление перед погружением в пучины маршрутизации. Есть на эту тему годное мозговыносящее чтиво MPLS Enabled Application. Так что там с понятиями в заголовке? Это никакие не уровни сетевой модели, среды или некие моменты передачи данных, а лишь абстрактное деление.
          Control Plane — уровень управления, где работают служебные протоколы, которые обеспечивают условия для передачи данных. Вот запускается BGP, следует по всем своим агрегатным состояниям и обменивается маршрутной информацией. Или же когда в MPLS-сетях LDP распределяет метки на префиксы. Таким же макаром обсуждавшийся уже STP обменивается BPDU и строит L2-топологию.
          Все эти процессы живут в рамках Control Plane.
          А вот Data Plane, передающий уровень — это уже передача полезных данных клиента.
          Часто случается, что данные с этих двух уровней ходят в разных направлениях как бы "навстречу друг другу". Таким вот образом маршруты передаются из AS100 в AS200, чтобы в свою очередь AS200 могла передать данные в AS100.

          И на разных уровнях могу быть совершенно отличные принципы работы. В том же MPLS на Data Plane создается само соединение, а непосредственно данные передаются посредством заранее определенного пути LSP. Сам же путь определяется по обычному TCP/IP стандарту, т.е. от одного хоста к другому.
          Тут нужно понять назначение этих уровней и разницу в них.
          Это крайне важный вопрос для BGP. Анонсируя свои маршруты вы одновременно создаете путь для входящего трафика — маршруты исходят от вас, а вот трафик течет к вам.

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

          • AS-Path ACL
          • Prefix-list
          • Weight
          • Local Preference
          • MED

          Много? Но только два первых могут фильтровать анонсируемые и передаваемые маршруты. Остальное — выставление приоритетов.

          Механизм этот очень мощный, но не пользуется особой популярностью. При помощи AS-Path ACL вы можете наглухо запретить прием анонсов от AS200, к примеру. Ну, вот не нужны нам от этой автономки анонсы, пускай будем получать их от другой.
          Самое сложное — это запомнить все использующиеся при этом подходе выражения:

          Давайте накидаем примеров, чтобы проще было понять.
          _200_ Маршруты проходящие через AS 200
          До и после номера AS идут знаки “_”, означающие, что в AS-path номер 200 может стоять в начале, середине или конце, главное, чтобы он был.
          ^200$ Маршруты из соседней AS 200
          “^” означает начало списка, а “$” – конец. То есть в AS-path всего лишь один номер AS – это означает, что маршрут был зарождён в AS 200 и оттуда сразу был передан нам.
          _200$ Маршруты отправленные из AS 200
          “$” означает конец списка, то есть это самая первая AS, из неё маршрут и зародился, знак “_” говорит о том, что неважно, что находится дальше, хоть ничего, хоть 7 других AS.
          ^200_ Сети находящиеся за AS 200
          Знак “^” означает, что ASN 200 была добавлена последней, то есть маршрут к нам пришёл из AS 200, но это не значит, что родился он в ней же – знак “_” говорит о том, что это может быть конец списка, а может пробел перед следующей AS.
          ^$ Маршруты локальной AS
          Список AS-path пуст, значит маршрут локальный, сгенерированный внутри нашей AS.
          Пример
          Отфильтруем в нашей сети маршруты, появившиеся в AS64501. То есть мы будем получать от этой автономки все "глобальные интернетовские" маршруты, но ни одного её локального.

          ShareIT — поделись знаниями!

          Полезно

          Узнать IP — адрес компьютера в интернете

          Онлайн генератор устойчивых паролей

          Онлайн калькулятор подсетей

          Калькулятор инсталляции IP — АТС Asterisk

          Руководство администратора FreePBX на русском языке

          Руководство администратора Cisco UCM/CME на русском языке

          Навигация

          Серверные решения

          Телефония

          FreePBX и Asterisk

          Настройка программных телефонов

          Корпоративные сети

          Популярное и похожее

          Зачем вам 802.1X и что он решает?

          Модель OSI – это просто!

          Wi-Fi для бизнеса

          Таблицы маршрутизации EIGRP

          Протокол BGP

          Связь между автономными системами

          4 минуты чтения

          Сегодняшняя статья будет посвящена основному протоколу динамической маршрутизации – BGP (Border Gateway Protocol). Почему основному? – Потому что с именно с помощью BGP организована топология всего Интернета.

          Итак, в данной статье разберем следующие моменты:

          1. Основные термины протокола BGP
          2. Принципы работы протокола BGP
          3. Типы сообщений протокола BGP

          Терминология

          Когда речь идёт BGP, первое на чем необходимо остановиться — это понятие автономной системы AS(Autonomus System). Автономная система — это совокупность точек маршрутизации и связей между ними, объединенная общей политикой взаимодействия, которая позволяет этой системе обмениваться данными с узлами, находящимися за ее пределами.

          AS характеризуется (с недавних пор 32 битным) номером ASN (Autonomus System Number) и пулом IP-адресов. Выдачей и того и другого занимается организация IANA (Internet Assigned Numbers Authority), делегируя контроль за распределением ASN и других интернет ресурсов, региональным регистраторам.

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

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

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

          Как известно, протоколы динамической маршрутизации классифицируются по двум основным признакам:

          1. Тип работы протокола относительно AS
            • IGP (Interior Gateway Protocol) – работают внутри автономной системы. Сюда относятся: RIP, OSPF, EIGRP, IS-IS
            • EGP (Exterior Gateway Protocol) – работают вне автономных систем и обеспечивают их связность. Сюда относится BGP
            • Алгоритм работы протокола
              • Distance-Vector — знает маршруты только до своих ближайших соседей и обменивается с ними таблицей маршрутизации. (RIP, EIGRP)
              • Link State – знает всю топологию сети и обменивается таблицей топологии со своими соседями (OSPF, IS-IS)

              Очевидно BGP не может быть Link State протоколом. Только представьте себе сколько автономных систем в Интернете, любой маршрутизатор просто выйдет из строя если получит такое количество информации.

              Итак, BGP – это протокол внешней маршрутизации, использующийся для соединения двух AS. Схема выглядит примерно так:

              Так как на BGP возложена великая задача – соединение автономных систем во всем Интернете, то он должен быть очень надежным. Для этих целей, в самом начале работы, BGP-маршрутизатор инициирует установление TCP сессии на 179 порт к своему соседу, происходит стандартных обмен SYN и ACK.

              Соединения по протоколу BGP должно быть абсолютно согласовано администраторами автономных систем, желающих организовать стык. Если, скажем, администратор AS402 запустил процесс BGP на маршрутизаторе BR2 (Border Router), указав в качестве соседа BR1 и его ASN, а администратор AS401 никаких действий не произвел, то TCP-сессия не поднимется и системы так и останутся несвязными. Кроме того, должны соблюдаться следующие условия:

              1. 179 порт не блокируется ACL (Access Control List)
              2. Маршрутизаторы пингуют друг друга
              3. При запуске BGP процесса ASN удаленной стороны был указан верно
              4. RouterID не совпадают

              Если TCP-сессия установлена успешно, то BGP-маршрутизаторы начинают обмен

              сообщениями OPEN, в котором сообщают свои ASN, RouterID и Hold timer. Hold timer это время, в течение которого будет поддерживаться TCP-сессия. Если условия, перечисленные ранее, не соблюдаются, например не совпадает информация о номере AS, то сообщением NOTIFICATION маршрутизатор, получивший неверный ASN уведомит об этом своего соседа и сбросит TCP-сессию.

              Если же все условия соблюдаются, то маршрутизаторы, с определенным интервалом, начинают высылать друг другу сообщения KEEPALIVE, означающие подтверждение параметров, принятых в OPEN и уведомление “я ещё жив”.

              Наконец, маршрутизаторы могут приступать к обмену маршрутной информацией по средствам сообщения UPDATE. Структура данного сообщения делится на две части:

              1. Path Attributes (Атрибуты пути). Здесь указывается из какой AS поступил маршрут, его происхождение и Next Hop для данного пути.
              2. NRLI (Network Layer Reachability Information). Здесь указывает информация непосредственно о сетях, подлежащих добавлению в таблицу маршрутизации, т.е IP-адрес сети и ее маска.

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

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

              Пожалуйста, расскажите почему?

              Нам жаль, что статья не была полезна для вас 🙁 Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

              Подпишитесь на нашу еженедельную рассылку, и мы будем присылать самые интересные публикации 🙂 Просто оставьте свои данные в форме ниже.

              Добавить комментарий

              Ваш адрес email не будет опубликован. Обязательные поля помечены *