> For the complete documentation index, see [llms.txt](https://linkmeup.gitbook.io/sdsm/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://linkmeup.gitbook.io/sdsm/8.-bgp-i-ip-sla/2.-bgp/1.-ystanovlenie-bgp-sessii-procedura-obmena-marshrutami.md).
# Установление BGP-сессии и процедура обмена маршрутами
Возьмём типичную ситуацию, когда у нас подключение к провайдерскому шлюзу организовано напрямую.
Устройства, между которыми устанавливается BGP-сессия называются BGP-пирами или BGP-соседями.
BGP не обнаруживает соседей автоматически – каждый сосед настраивается вручную.\
Процесс установления отношений соседства происходит следующим образом:
**I)** Изначальное состояние BGP-соседства – **IDLE**. Ничего не происходит.
BGP находится в соcтоянии IDLE, если нет маршрута к BGP-соседу.
**II)** Для обеспечения надёжности BGP использует TCP.\
Это означает, что теоретически BGP-пиры могут быть подключены не напрямую, а, например, [так](http://img-fotki.yandex.ru/get/6701/83739833.28/0_b9013_38a76d17_XXL.png).
Но в случае подключения к провайдеру, как правило, берётся всё же прямое подключение, таким образом маршрут до соседа всегда есть, как подключенный непосредственно.
BGP-маршрутизатор (их также называют BGP-спикерами/speaker или BGP-ораторами) слушает и посылает пакеты на 179-й TCP порт.\
Когда слушает – это состояние **CONNECT**. В таком состоянии BGP находится очень недолго.
Когда отправил и ожидает ответа от соседа – это состояние **ACTIVE**.
R1 отправляет TCP SYN на порт 179 соседа, инициируя TCP-сессию.
R2 возвращает TCP ACK, мол, всё получил, согласен и свой TCP SYN.
R1 тоже отчитывается, что получил SYN от R2.
После этого TCP-сессия установлена.
В состоянии ACTIVE BGP может подвиснуть, если
* нет IP-связности с R2
* BGP не запущен на R2
* порт 179 закрыт ACL
Вот пример неуспешного установления TCP-сессии. BGP будет в состоянии ACTIVE, иногда переключаясь на IDLE и снова обратно.\
TCP SYN отправлен с R1 на R2.
На R2 не запущен BGP, и R2 возвращает ACK, что получен SYN от R1 и RST, означающий, что нужно сбросить подключение.
Периодически R1 будет пытаться снова установить TCP-сессию.
> В свою бытность зелёным юнцом, я, впервые настраивая BGP-пиринг с провайдером, потратил полдня на поиск проблемы. Я реально не знал, как настраивается BGP и искал ошибку в конфигурации, думал, что есть какие-то тонкости для моей ситуации, уже начал читать про community. Но наконец в голову пришла светлая мысль – проверить ACL на входе в сеть. Да, TCP-запросы провайдера попадали в deny и сессия не устанавливалась.\
> Будьте аккуратны. Рядовая практика для провайдера вешать на все свои внешние интерфейсы, торчащие в «мир» ACL.
**III)** После того, как TCP-сессия установлена, BGP-ораторы начинают обмен сообщениями ***OPEN***.
> OPEN – первый тип сообщений BGP. Они отсылаются только в самом начале BGP-сессии для согласования параметров.
В нём передаются версия протокола, номер AS, Hold Timer и Router ID. Чтобы BGP-сессия поднялась, должны соблюдаться следующие условия:
* Версии протокола должна быть одинаковой. Маловероятно, что это будет иначе
* Номера AS в сообщении OPEN должны совпадать с настройками на удалённой стороне
* Router ID должны различаться
Также внизу вы можете увидеть поддерживает ли маршрутизатор дополнительные возможности протокола.
Получив OPEN от R1, R2 отправляет свой OPEN, а также KEEPALIVE, говорящий о том, что OPEN от R1 получен – это сигнал для R1 переходить к следующему состоянию – Established.
Вот примеры неконсистентности параметров:
**а) некорректная AS** (На R2 настроена AS 300, тогда, как на R1 считается, что данный сосед находится в AS 200):
R2 отправляет обычный OPEN
R1 замечает, что AS в сообщении не совпадает с настроенным, и сбрасывает сессиию, отправляя сообщение ***NOTIFICATION***. Они отправляются в случае каких-либо проблем, чтобы разорвать сессию.
При этом в консоли R1 появляются следующие сообщения:
**б) одинаковый Router ID**\
R2 отправляет в OPEN Router ID, который совпадает с ID R1:
R1 возвращает NOTIFICATION, мол, опух?!
При этом в консоли будут следующего плана сообщения:
После таких ошибок BGP переходит сначала в IDLE, а потом в ACTIVE, пытаясь заново установить TCP-сессию и затем снова обменяться сообщениями OPEN, вдруг, что-то изменилось?\
Когда сообщение Open отправлено – это состояние **OPEN SENT**.\
Когда оно получено – это сотояние **OPEN CONFIRM**.
> Если Hold Timer различается, то выбран будет наименьший. Поскольку Keepalive Timer не передаётся в сообщении OPEN, он будет рассчитан автоматически (Hold Timer/3). То есть Keepalive может различаться на соседях\
> Вот пример: на R2 настроены таймеры так: Keepalive 30, Hold 170.
>
> 
>
> R2 отправляет эти параметры в сообщении OPEN. R1 получает его и сравнивает: полученное значение – 170, своё 180. Выбираем меньшее – 170 и вычисляем Keepalive таймер:
>
> 
>
> Это означает, что R2 свои Keepalive’ы будет рассылать каждые 30 секунд, а R1 – 56. Но главное, что Hold Timer у них одинаковый, и никто из них раньше времени не разорвёт сессию.
Увидеть состояние OPENSENT или OPENCONFIRM практически невозможно – BGP на них не задерживается.
**IV)** После всех этих шагов они переходят в стабильное состояние **ESTABLISHED**.\
Это означает, что запущена правильная версия BGP и все настройки консистентны.
Для каждого соседа можно посмотреть Uptime – как долго он находится в состоянии ESTABLISHED.
**V)** В первые мгновения после установки BGP-сессии в таблице BGP только информация о локальных маршрутах.
Можно переходить к обмену маршрутной информацией.\
Для этого используются сообщения ***UPDATE***
> Каждое сообщение UPDATE может нести информацию об **одном** новом маршруте или о удалении группы старых. Причём одновременно.
Разберём их поподробнее.\
R1 передаёт маршрутную информацию на R2.\
Первый плюсик в сообщении UPDATE – это атрибуты пути. Мы их подробно рассмотрим позже, но вам уже должны быть поняты два из них. *AS\_PATH* означает, что маршрут пришёл из AS с номером 100.\
NEXT\_HOP – что логично, информация для R2, что указывать в качестве шлюза для данного маршрута. Теоретически здесь может быть не обязательно адрес R1.
Атрибут *ORIGIN* сообщает о происхождении маршрута:
* **IGP** – задан вручную командой network или получен по BGP
* **EGP** – этот код вы никогда не встретите, означает, что маршрут получен из устаревшего протокола, который так и назывался – “EGP”, и был полностью повсеместно заменен BGP
* **Incomplete** – чаще всего означает, что маршрут получен через редистрибьюцию
Второй плюсик – это собственно информация о маршрутах – NLRI – Network Layer Reachability Information. Собственно, наша сеть 100.0.0.0/23 тут и указана.
Ну и UPDATE от R2 к R1.\
Нижеидущие KEEPALIVE – это своеобразные подтверждения, что информация получена.
Информация о сетях появилась теперь в таблице BGP:
И в таблице маршрутизации:
UPDATE передаются при каждом изменении в сети до тех пор, пока длится BGP-сессия. Заметьте, никаких синхронизаций таблиц маршрутизации нет, в отличии от какого-нибудь OSPF. Это было бы технически глупо – полная таблица маршрутов BGP весит несколько десятков мегабайтов на каждом соседе.
**VI)** Теперь, когда всё хорошо, каждый BGP-маршрутизатор регулярно будет рассылать сообщения **KEEPALIVE**. Как и в любом другом протоколе это означает: «Я всё ещё жив». Это происходит с истечением таймера Keepalive – по умолчанию 60 секунд.
> Если BGP-сессия устанавливается нормально, но потом рвётся и это повторяется с некой периодичностью – верный знак, что не проходят keepalive. Скорее всего, период цикла – 3 минуты (таймер HOLD по умолчанию). Искать проблему надо на L2. Например, это может быть плохое качество связи, перегрузки на интерфейсе или ошибки CRC.
Ещё один тип сообщений BGP – [**ROUTE REFRESH**](http://jaluther.blogspot.ru/2012/04/bgp-route-refresh-capability.html) – позволяет запросить у своих соседей все маршруты заново без рестарта BGP процесса.
[Подробнее](http://www.freesoft.org/CIE/RFC/1771/9.htm) обо всех типах сообщений BGP.
Полная [FSM](https://en.wikipedia.org/wiki/Finite-state_machine) ([конечный автомат](https://ru.wikipedia.org/wiki/Конечный_автомат)) для BGP выглядит так:
*Нашёл в сети подробное* [*описание*](http://ts71.org.ua/wp-content/uploads/2010/11/Лекция-21.-Расширенное-конфигурирование-протокола-BGP.doc) *каждого шага.*
**Вопрос на засыпку:** Предположим, что Uptime BGP-сессии 24 часа. Какие сообщения гарантировано не передавались между соседями последние 12 часов?
Теперь расширим наш кругозор до вот такой сети:\
Картинки без подсетей\
И посмотрим, что из себя представляет таблица маршрутов BGP на маршрутизаторе R1:
Как видите, маршрут представляет из себя вовсе не только NextHop или просто список устройств до нужной подсети. Это список AS. Иначе он называется AS-Path.\
То есть, чтобы попасть в сеть 123.0.0.0/24 мы должны отправить пакет наружу, преодолеть AS 200 и AS 300.
AS-path формируется следующим образом:\
а) пока маршрут гуляет внутри AS, список пустой. Все маршрутизаторы понимают, что полученный маршрут из этой же AS\
б) Как только маршрутизатор анонсирует маршрут своему внешнему соседу, он добавляет в список AS-path номер своей AS.\
в) внутри соседской AS, список не меняется и содержит только номер изначальной AS\
г) когда из соседской AS маршрут передаётся дальше в начало списка добавляется номер текущей AS.
И так далее. При передаче маршрута внешнему соседу номер AS всегда добавляется в начало списка AS-path. То есть фактически это стек.
AS-path нужен не просто для того, чтобы маршрутизатор R1 знал путь до конечной сети – ведь по сути Next Hop достаточно – каждый маршрутизатор решение по-прежнему принимает на основе таблицы маршрутизации. На самом деле тут преследуются две более важные цели:\
1\) Предотвращение петель маршрутизации. В AS-Path не должно быть повторяющихся номеров
> На самом деле ASN может повторяться в AS-Path в двух случаях\
> а) Когда вы используете AS-Path Prepend, о котором ниже.\
> б) Когда вы хотите соединить два куска одной AS, не имеющих прямой связи друг сдругом.
2\) Выбор наилучшего маршрута. Чем короче AS-Path, тем предпочтительнее маршрут, но об этом позже.