Установление BGP-соседства: TCP, типы сообщений и параметры сессии

Добрый день, друзья! Приветствую вас на уроке номер 3. И сегодня мы с вами поговорим о видах BGP-сообщений и немножечко о процессе установления непосредственно BGP-соседства. Итак, прежде чем переходить к тому, какими сообщениями обмениваются BGP-мортизаторы, давайте поговорим о том, как они устанавливают отношения соседства. Если вы вспомните, как устанавливают отношения соседства-мортизаторы, скажем, по протоколу OSPF, то обычно дело выглядит примерно вот так. Для любого IGP-протокола есть два неких мортизатора. Далее, вы с помощью команды Network, либо с помощью команды, скажем, IPOSPF на интерфейсе, активируете Hello-рассылку, которые там рассылаются на некий мультикастный адрес, 224, скажем, 005. И таким образом, когда мультизаторы обменят данными холл-сообщений, они могут подружиться.

С BGP несколько иначе. Прежде всего, мне хотелось бы, чтобы вы запомнили одну вещь, что BGP, по сути, это TCP-приложение. Это TCP-приложение. Соответственно, поскольку это TCP-приложение, то для того, чтобы два мультизатора установили BGP-соседство, у нас нету требования, у нас нет, по сути, никакого требования на количество промежуточных хопов между ними. То есть, условно, если у нас есть мультизатор R1 и есть мультизатор R2, и между ними находится любое количество промежуточных устройств, то данные мультизаторы абсолютно без проблем всегда смогут установить отношение соседства. Здесь накладываются следующие требования.

Смотрите, если мы говорим о том, что мультизаторы R1 и R2 должны между собой установить TCP-сессию, например, сессия устанавливается с этого интерфейса на этот интерфейс, и между ними еще может быть какое-то промежуточное L3-облако. У нас появляется необходимость такая, что мультизатор R1, предположим, что у него IP-адрес здесь 1111, и мультизатор R2, у которого здесь IP-адрес 2222, то мультизатор R1 обязательно должен знать маршрут. То есть, если мы ведем команду showiperoot на 2222, то мы обязательно должны знать такой маршрут. То есть, что говоря, здесь должен быть сакцесс. То же самое в обратную сторону. Мультизатор R2 обязательно должен иметь в своей таблице маршрутизации маршрут на адрес маршрутизатора R1.

Ведь если маршрутной информации у нас не будет, то TCP-сессия не установится. А поскольку, как я вам сказал, BGP работает как TCP-аппликейшн, то и BGP-соседство двумтизатором установить не удастся. Как и любое TCP-приложение, BGP использует клиент серверную архитектуру. Соответственно, для BGP зарезервирован протокол номер, извините, порт 179. Соответственно, маршрутизатор всегда прослушивает этот порт. И когда два маршрутизатора общаются между собой, один из них будет клиентом, другой из них будет сервером. Соответственно, на сервере используется протокол номер 179.

На клиенте используется некий рандомный порт в диапазоне 1024. Кто из двух маршрутизаторов будет клиентом, а кто будет сервером, это процесс условно предопределенный. По сути, они оба, то есть когда вы настроите маршрутизаторы R1 и R2 так, чтобы они устанавливали друг с другом отношения соседства, то маршрутизаторы начнут обмениваться некими служебными сообщениями, и уже в процессе обмена они договорятся, кто из них будет клиентом, а кто из них будет сервером. Кто из них будет сервером. После того, как у нас установилась TCP-связанность, мы можем запускать BGP процесс. БГП для своей работы используют несколько основных сообщений,

их в частности пять. Первое сообщение – это сообщение Open. Что это такое? Оно отсылается сразу же после установления TCP-сессии. В частности, внутри этого сообщения содержится такая информация, как версия BGP. на текущий момент, я думаю, что у всех и всегда это будет версия 4. Далее. Содержится номер автономной системы ISN. То есть, то, что мы проходили с вами на прошлом занятии. Это может быть либо число от 1 до 65 тысяч, либо это может быть число от условного 1 до 65 тысяч. BGP router ID. Это некое имя мунизатора, его идентификатор.

Обычно в качестве BGP router ID используются лупбеки. Желательно, чтобы эти router ID, очевидно, между разными мунизаторами были разные. И, помимо прочего, могут высылаться дополнительные параметры для согласования. Как пример, может высылаться некий набор адрес family. В самом-самом первом уроке по BGP мы говорили о том, что BGP умеет масштабироваться не только по количеству префиксов, но и по их типам. Так вот, например, вы можете передавать, скажем, IPv4 префиксы и вы можете передавать IPv6 префиксы. Но два мунизатора, перед тем, как этими префиксами обмениваются, они должны друг с другом договориться, чем они будут обмениваться. Вот, собственно говоря, здесь это может и передаваться. Передаваться.

Следующее сообщение, которое используется, это сообщение KipaLife. KipaLife играет абсолютно такую же роль, как KipaLife, скажем, в горе-туннеле. То есть это просто некие такие легкие-легкие пинги, которые проверяют доступность соседа. По умолчанию KipaLife будут отсылаться раз в 60 секунд. При этом вы можете сконфигурировать значение KipaLife равное 0. Это будет значить, что KipaLife не используется. То есть никакой проверки связанности с удаленным соседом у вас не будет. Кстати, на основе KipaLife высчитывается значение HoldTimer. Значение HoldTimer высчитывается как 3 умножить на KipaLife. При этом есть один такой важный нюанс.

Представьте, что, поскольку я говорил, что BGP используется в том числе для маршрутизации между разными автономными системами, то есть у вас, скажем, может быть маршрутизатор R1 и может быть, например, маршрутизатор R2, который находится в разных автономных системах. И, скажем, маршрутизатор R1 может использовать HoldTimer, пусть будет 120 секунд, а у маршрутизатора R1 пусть будет 180 секунд. В этом случае будет всегда, всегда будет выбран минимальный. То есть происходит согласование этого параметра и выбирается минимальный. Следующее сообщение – это сообщение Update. Из его названия, я думаю, все понятно.

Похожие сообщения есть и в SPF, есть и в EGRP. То есть предположим, что у вас есть некая стабильная сеть и у вас появился новый подсиск, появился новый интерфейс с IP-адресом. Вы добавляете эту сеть в BGP и дальше эта информация распространяется по всем вашим соседям. Так вот, для того, чтобы сообщить, что у нас появился некий префикс, используется сообщение Update. Точно так же это сообщение используется, если мы какую-то сеть потеряли. То есть, например, у вас упал какой-то линк. Если эта сеть больше не доступна, мы об этом сообщаем всем нашим соседям. Следующее сообщение – это сообщение Route Refresh. По сути, конечно, мы будем об этом говорить еще в нашем курсе,

но суть усвоится примерно к следующему. Скажем, у нас есть соседство между амортизаторами R1 и R2. Мурсуатор R2 выслал нам какое-то n-ное количество префиксов. Предположим, что Мурсуатор R2 выслал нам 100 тысяч префиксов. Мы их получили, каким-то образом обработали. При этом мы их обрабатываем согласно политикам, которые мы настраиваем на амортизатор R1. Теперь предположим, что мы изменили наши политики. У нас теперь новые политики для обработки трафика. И теперь мы можем попросить амортизатор R2 выслать нам вот эти 100-100 тысяч сообщений еще раз.

Для чего? Можете спросить вы. А для того, чтобы у нас в BGP табличке появились апдейты, которые прошли уже через измененные правила. Например, через измененные правила фильтрации. Почему нет? Это сообщение Round Refresh. И последний тип сообщения – это сообщение Notification. Обычно это сообщение высылается, когда мы по тем или иным причинам разрываем отношения с нашим соседом. Например, мы вручную рестартанули BGP-сессию. То есть дали команду clearipbgp. Либо же мы, например, у нас что-то случилось с каналом связи между двумя амортизаторами, и у нас просто истек hold timer. Либо же у нас появились новые типы префиксов.

Например, мы захотели вместо или в добавление к IPv4 анонсировать еще и наши IPv6. В этом случае амортизатор вышлет сообщение Notification. Ну что ж, давайте с вами закрепим это на небольшой практике. Итак, установим базовое отношение соседства между амортизатором R1 и амортизатором R2. Все здесь. Для этого у меня есть прямой линк между ними. Это интерфейс G2.12. Для начала мне потребуется узнать IP-адреса амортизаторов R1 и R2. Show IP. Интерфейс Brief. Обращаю внимание. Здесь нам уж истер R1 и IP-адреса 10.1.2.1.

Нам уж истер R2. IP-адреса 10.1.2.2. Проверим связанность. Пинк 10.1.2.1. Связанность есть. Хорошо. Так, у меня мы здесь с вами в прошлое радио настраивали какой-то BGP. Давайте мы с вами его уберем. Ну, раутер BGP. Согласно моей лабораторной схеме, номер автономии системы используется 123. Соответственно, создаем BGP процесс номер роутера BGP 123. Итак. Пока пусто. Мы создали процесс. Соответственно, мы можем его посмотреть командой show IP process.

Show IP protocols, извиняюсь. protocols. И запущен протокол BGP 123. При этом у меня нет никаких фильтров. Отключена автоматическая суммаризация маршрутов. Это то есть когда-то в BGP была команда автосаммари. То есть ее смысл абсолютно такой же, как и в EGRP. Обратите внимание, что для BGP сразу пишется его административная дистанция. При этом пишется некий external and internal. То есть видите, две разные административные дистанции. 20 и 200. Что такое external? Что такое external и что такое internal BGP? Мы с вами поговорим чуть-чуть позже. Сейчас, сейчас. Я сейчас на амортизаторе хочу включить. Хочу включить несколько дебагов. Первый это debug IP TCP transactions.

Debug TCP transactions. Show TCP brief. Пока что у меня нет активных сессий, поскольку у меня амортизаторы не пытаются снять отношения соседств друг с другом. Итак. Раутер BGP 1.2.3. Сразу, прежде всего, хотелось бы задать наш раутер ID. Он задается командой BGP router ID. BGP router ID. В частности, я буду использовать интерфейс LOOBAC0. Для амортизатора R1 это будет ADES 4D. И для амортизатора R2. 2.2.2.2. Далее. В отличие от IGP протоколов, как я сказал, BGP это по сути point-to-point сессии.

Поэтому, точно так же, как в любой TCP сессии, вы должны явно указать IP адрес вашего соседа, с кем вы хотите узнать отношения соседств. Сделаем. Для этого используется команда Neighbor. Указываем адрес. Адрес нашего соседа. На амортизаторе R2 это адрес 10.1.2. Дальше у нас есть много-много ключевых команд, которые мы можем с вами добавить. Но нас сейчас... У нас сейчас будет интересовать только одна из них. В частности, это команда, которая звучит. Remote.is. То есть, здесь я должен указать номер автономной системы на...

То есть, по сути, номер BGP процесса, который запущен на амортизаторе R2. В моем случае это будет Remote.is.123. 1.2.3. Обратите внимание. У меня теперь шел TCP-бриф. У меня нет пока что удаленной сессии, но... Обратите внимание. Сендинг син. То есть, я пытаюсь построить TCP-сессию с амортизатором 10.1.2.2. Я отправляю син пакет. То есть, обычно трехстороннее TCP-рукопожать. Но в итоге... В итоге... В итоге... State изменяется с SynthSend на Closed. Да? Ну, потому что мы... То есть, мы ему отправили. Да?

Соответственно, оттуда к нам прилетел Reset. Поскольку амортизатор R2 сейчас никаких, собственно говоря, соединений от мортизатора R1 не ожидает. Вот. Ну, собственно говоря, здесь, я думаю, мы это тоже можем увидеть. Видите? Вот, видите? Send Reset. Да? Ой. Ой. Сейчас, коллеги, я случайно... Так. Как вы видите, мы отправляем Reset. То есть, мортизатор R2 отправляет Reset, потому что на нем, на мортизаторе R2 еще не сконфигурирован. То есть, мы не ожидаем никаких TCP-пакетов. Давайте исправим это дело.

Neighbor 10.1.2.1. Remote AS 1.2.3. Итак. Neighbor is up. При этом TCP-сессия находится в состоянии established. Ну, то есть, трехстороннее рукопожатие завершилось успешно. Show TCP-brief. Как видите, теперь на мортизаторе R2 есть открытая сессия. Соответственно, на мортизаторе R2 используется порт номер 179. Порт номер 179, который нам говорит, по сути, о том, что мортизатор R2 в данном случае является сервером. Она является сервером. А на мортизаторе R1 используется порт 39187, который нам говорит о том, что мортизатор R1 является клиентом.

На самом деле, тут несложно догадаться, что в качестве арбитра, для выбора того, кто из мортизаторов будет являться сервером, а кто клиентом, используется их R2. Используется их R2. Итак. Сделали. Но это мы с вами посмотрели debug TCP. Debug TCP. Сейчас мы можем с вами включить несколько иной дебаг. Например, debug IP BGP. Adjacency. Нет. Наврал. Debug IP BGP.

Events. Debug IP BGP. Можно сказать, debug IP BGP. All на самом деле. BGP. All. И сейчас сделаем Clear. Идет BGP со звездочкой. То есть я полностью перезагружу всю свою BGP. TSP-шную сессию. TSP-шную сессию. Debug. Go. Я боюсь, тут будет слишком много информации. Но. Но. Так. Угу.

Так. Вот. На что бы мне хотелось бы обратить ваше внимание. Видите. Высылается сообщение Open. То есть, Receive Open. Вот он. То есть мы получили от соседа сообщение Open. В котором содержится у нас о том, что в версии номер 4 Hold Timer составляет 180 секунд. Плюс мы получили некие Capability. То есть мы получили информацию о том, какими маршрутами мы будем обмениваться. Будем обмениваться. И при этом мы получили информацию о том, что на удаленном пире запущен BGP процесс номер 123. Номер 123. Номер 123. И при этом этот пир поддерживает 4-байтную автономную систему. То есть, условно говоря, на нем может быть сконфигурировано AS номером 4 миллиарда.

4 миллиарда. Посмотреть, в каком состоянии и вообще какие у вас есть соседи, вы можете командой showipbgpsummary. В частности, вы увидите, что у нас есть один сосед. Это муж театр R2. На нем запущено... Он находится в автономной системе номер 123. Работает по протоколу версии 4. Далее. Это просто счетчики сообщений. Это просто счетчики сообщений, отправленных и полученных. Далее. Table version. То есть, это номер версии BGP таблицы. Он будет увеличиваться при каждом изменении BGP топологии.

То есть, например, когда у вас префикс добавился, префикс удалился. Соответственно, timer up-down. То есть, как давно было установлено ваше отношение к соседству. И вот этот последний столбец. Видите, он написан либо state, либо префикс received. Так вот, если BGP соседство установлено удачно, то есть, произошли все необходимые обмены всеми необходимыми сообщениями, то здесь будет красоваться некое число, которое будет указывать на то, сколько префиксов вы получили от конкретного соседа. Если же здесь будет указано некое состояние, например, active, либо idle, это нам говорит о том, что отношение, так сказать, к тому, что BGP сессия не установлена, по каким-либо причинам, и вам необходимо заняться устранением неисправности. О том, через какие состояния проходят BGP соседи,

BGP-муртизаторы при установлении соседства, мы поговорим с вами в следующем уроке. БГП-муртизаторы при установлении соседства,