# Установление 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, тем предпочтительнее маршрут, но об этом позже.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://linkmeup.gitbook.io/sdsm/8.-bgp-i-ip-sla/2.-bgp/1.-ystanovlenie-bgp-sessii-procedura-obmena-marshrutami.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.