Файл: Организационно-правовая форма.pdf

2.4.Контрольный пример реализации сети и его описание

Так вот для того, чтобы нам из своей AS передать информацию об этих публичных адресах в другую AS и используется BGP. Теперь главный вопрос, а зачем BGP, почему не взять пресловутый OSPF или вообще статику? Если говорить о OSPF/IS-IS, то это Link-State алгоритмы, которые подразумевают что каждый маршрутизатор знает топологию всей сети. Представляем себе миллионы маршрутизаторов в Интернете и отказываемся от идеи использовать Link State для этих целей вообще. Вообще OSPF при маршрутизации между area'ми является фактически distance vector протоколом. Гипотетически, можно было бы заменить «AS» на «Area» в плане глобальной маршрутизации, но OSPF просто не предназначен для переваривания таких объемов маршрутной информации, да и нельзя выделить в интернете Area 0.

– IGP – это нечто интимное и каждому встречному ISP показывать его не стоит. Даже без AS ситуация, когда клиент поднимает IGP с провайдером, крайне редкая (за исключением L3VPN). Дело в том, что IGP не имеют достаточно гибкой системы управления маршрутами – для LS-протоколов это вообще знать  (опять же можно фильтровать на границе зоны, но гибкости никакой).В итоге оказывается, что придётся открывать кому-то чужому потаённые части своей приватной сети или настраивать хитрые политики импорта между различными IGP-процессами.– В данный момент в интернете более 450 000 маршрутов. Если бы даже OSPF/ISIS могли хранить всю топологию Интернета, представьте, сколько времени заняла бы работа алгоритма SPF. Вот пример, чем может быть опасно использование IGP там, где напрашивается нечто глобальное. Поэтому нужен свой специальный протокол для взаимодействия между AS. Во-первых, он должен быть дистанционно-векторным – это однозначно. Маршрутизатор не должен делать расчёт маршрута до каждой сети в Интернете, он лишь должен выбрать один из нескольких предложенных. Во-вторых, он должен иметь очень гибкую систему фильтрации маршрутов. Мы должны легко определять, что светить соседям, а что не нужно выносить из избы.
В-третьих, он должен быть легко масштабируемым, иметь защиту от образования петель и систему управления приоритетами маршрутов.В-четвёртых, он должен обладать высокой стабильностью. Поскольку данные о маршрутах будут передаваться через среду, которая не всегда может обладать гарантированным качеством (за стык отвечают по крайней мере две организации), необходимо исключить возможные потери маршрутной информации. Ну и логичное, в-пятых, он должен понимать, что такое AS, отличать свою AS от чужих. BGP делится на IBGP и EBGP.IBGP необходим для передачи BGP-маршрутов внутри одной автономной системы. Да, BGP часто запускается и внутри AS. EBGP – это обычный BGP между автономными системами. На нём и остановимся.Установление BGP-сессии и процедура обмена маршрутами Возьмём типичную ситуацию, когда у нас подключение к шлюзу организовано напрямую.

Рисунок 7 Схема маршрутизации с помощью протокола BGP

Устройства, между которыми устанавливается BGP-сессия называются BGP-пирами или BGP-соседями.BGP не обнаруживает соседей автоматически – каждый сосед настраивается вручную. Процесс установления отношений соседства происходит следующим образом:I) Изначальное состояние BGP-соседства – IDLE. Ничего не происходит.

Рисунок 8 BGP находится в соcтоянии IDLE, если нет маршрута к BGP-соседу. 

II) Для обеспечения надёжности BGP использует TCP.Это означает, что теоретически BGP-пиры могут быть подключены не напрямую, а, например, так .Но в случае подключения к провайдеру, как правило, берётся всё же прямое подключение, таким образом маршрут до соседа всегда есть, как подключенный непосредственно.
BGP-маршрутизатор (их также называют BGP-спикерами/speaker или BGP-ораторами) слушает и посылает пакеты на 179-й TCP портКогда слушает – это состояние CONNECT. В таком состоянии BGP находится очень недолго.Когда отправил и ожидает ответа от соседа – это состояние ACTIVE.

Рисунок 9 R1 отправляет TCP SYN на порт 179 соседа, инициируя TCP-сессию. Рисунок 10 R2 возвращает TCP ACK, мол, всё получил, согласен и свой TCP SYN. Рисунок 11 R1 тоже отчитывается, что получил SYN от R2. Рисунок 12 TCP-сессия установлена.

В состоянии ACTIVE BGP может подвиснуть, если

нет IP-связности с R2

BGP не запущен на R2

порт 179 закрыт ACLВот пример неуспешного установления TCP-сессии. BGP будет в состоянии ACTIVE, иногда переключаясь на IDLE и снова обратно.TCP SYN отправлен с R1 на R2. Рисунок 13 На R2 не запущен BGP, и R2 возвращает ACK, что получен SYN от R1 и RST, означающий, что нужно сбросить подключение. Рисунок 14 R1 будет пытаться снова установить TCP-сессию.

Рядовая практика для провайдера вешать на все свои внешние интерфейсы, торчащие в «мир» ACL.III) После того, как TCP-сессия установлена, BGP-ораторы начинают обмен сообщениями OPEN.OPEN – первый тип сообщений BGP. Они отсылаются только в самом начале BGP-сессии для согласования параметров.

Рисунок 15 номер AS, Hold Timer и Router ID

В нём передаются версия протокола, номер AS, Hold Timer и Router ID. Чтобы BGP-сессия поднялась, должны соблюдаться следующие условия:
Версии протокола должна быть одинаковой. Маловероятно, что это будет иначе

• Номера AS в сообщении OPEN должны совпадать с настройками на удалённой стороне
• Router ID должны различаться
  Также внизу вы можете увидеть поддерживает ли маршрутизатор дополнительные возможности протокола.
  Получив OPEN от R1, R2 отправляет свой OPEN, а также KEEPALIVE, говорящий о том, что OPEN от R1 получен – это сигнал для R1 переходить к следующему состоянию – Established.

Рисунок 16 примеры неконсистентности параметров

Вот примеры неконсистентности параметров: а) некорректная AS (На R2 настроена AS 300, тогда, как на R1 считается, что данный сосед находится в AS 200):R2 отправляет обычный OPEN

Рисунок 16 отправка сообщения NOTIFICATION.

R1 замечает, что AS в сообщении не совпадает с настроенным, и сбрасывает сессиию, отправляя сообщение NOTIFICATION. Они отправляются в случае каких-либо проблем, чтобы разорвать сессию.

Рисунок 17 пример настройки BGP

При этом в консоли R1 появляются следующие сообщения: Рисунок 18 пример настройки BGP

б) одинаковый Router IDR2 отправляет в OPEN Router ID, который совпадает с ID R1:

Рисунок 19 пример настройки BGP

R1 возвращает NOTIFICATION, мол, опух?!

Рисунок 20 пример настройки BGP

При этом в консоли будут следующего плана сообщения:

Рисунок 21 пример настройки BGP

После таких ошибок BGP переходит сначала в IDLE, а потом в ACTIVE, пытаясь заново установить TCP-сессию и затем снова обменяться сообщениями OPEN, вдруг, что-то изменилось? 
Когда сообщение Open отправлено – это состояние OPEN SENT.
Когда оно получено – это сотояние OPEN CONFIRM.

Если Hold Timer различается, то выбран будет наименьший. Поскольку Keepalive Timer не передаётся в сообщении OPEN, он будет рассчитан автоматически (Hold Timer/3). То есть Keepalive может различаться на соседях
Вот пример: на R2 настроены таймеры так: Keepalive 30, Hold 170.

Рисунок 22 пример настройки BGP

R2 отправляет эти параметры в сообщении OPEN. R1 получает его и сравнивает: полученное значение – 170, своё 180. Выбираем меньшее – 170 и вычисляем Keepalive таймер:

Рисунок 23 пример настройки BGP

Это означает, что R2 свои Keepalive’ы будет рассылать каждые 30 секунд, а R1 – 56. Но главное, что Hold Timer у них одинаковый, и никто из них раньше времени не разорвёт сессию.

Увидеть состояние OPENSENT или OPENCONFIRM практически невозможно – BGP на них не задерживается.
IV) После всех этих шагов они переходят в стабильное состояние ESTABLISHED.
Это означает, что запущена правильная версия BGP и все настройки консистентны.
Для каждого соседа можно посмотреть Uptime – как долго он находится в состоянии ESTABLISHED.

Рисунок 24 пример настройки BGP

V)В первые мгновения после установки BGP-сессии в таблице BGP только информация о локальных маршрутах.

Рисунок 25 пример настройки BGP

Можно переходить к обмену маршрутной информацией.Для это используются сообщения UPDATE

Каждое сообщение UPDATE может нести информацию об одном новом маршруте или о удалении группы старых. Причём одновременно.

Рисунок 26 пример настройки BGP

Разберём их поподробнее.
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.

Рисунок 27 пример настройки BGP

Нижеидущие KEEPALIVIE – это своеобразные подтверждения, что информация получена.
Информация о сетях появилась теперь в таблице BGP:

Рисунок 28 пример настройки BGP

И в таблице маршрутизации:

Рисунок 29 пример настройки BGP

UPDATE передаются при каждом изменении в сети до тех пор пока длится BGP-сессия. Заметьте, никаких синхронизаций таблиц маршрутизации нет, в отличии от какого-нибудь OSPF. Это было бы технически глупо – полная таблица маршрутов BGP весит несколько десятков мегабайтов на каждом соседе. VI) Теперь, когда всё хорошо, каждый BGP-маршрутизатор регулярно будет рассылать сообщения KEEPALIVE. Как и в любом другом протоколе это означает: «Я всё ещё жив». Это происходит с истечением таймера Keepalive – по умолчанию 60 секунд.
Если BGP-сессия устанавливается нормально, но потом рвётся и это повторяется с некой периодичностью – верный знак, что не проходят keepalive. Скорее всего, период цикла – 3 минуты (таймер HOLD по умолчанию). Искать проблему надо на L2. Например, это может быть плохое качество связи, перегрузки на интерфейсе или ошибки CRC.

Ещё один тип сообщений BGP – ROUTE REFRESH – позволяет запросить у своих соседей все маршруты заново без рестарта BGP процесса. Подробнее обо всех типах сообщений BGP. Полная FSM (конечный автомат) для BGP выглядит так:

Рисунок 30 пример настройки BGP

Вопрос на засыпку: Предположим, что Uptime BGP-сессии 24 часа. Какие сообщения гарантировано не передавались между соседями последние 12 часов?

И посмотрим, что из себя представляет таблица маршрутов BGP на маршрутизаторе R1:

Рисунок 31 пример настройки BGP

Как видите, маршрут представляет из себя вовсе не только NextHop или просто список устройств до нужной подсети. Это список AS. Иначе он называется AS-Path.То есть, чтобы попасть в сеть 123.0.0.0/24 мы должны отправить пакет наружу, преодолеть AS 200 и AS 300. AS-path формируется

следующим образом:а) пока маршрут гуляет внутри AS, список пустой. Все маршрутизаторы понимают, что полученный маршрут из этой же ASб) Как только маршрутизатор анонсирует маршрут своему внешнему соседу, он добавляет в список AS-path номер своей AS. в) внутри соседской AS, список не меняется и содержит только номер изначальной ASг) когда из соседской AS маршрут передаётся дальше в начало списка добавляется номер текущей AS. 

Рисунок 32 пример настройки BGP

И так далее. При передаче маршрута внешнему соседу номер AS всегда добавляется в начало списка AS-path. То есть фактически это стек.
AS-path нужен не просто для того, чтобы маршрутизатор R1 знал путь до конечной сети – ведь по сути Next Hop достаточно – каждый маршрутизатор решение по-прежнему принимает на основе таблицы маршрутизации. На самом деле тут преследуются две более важные цели:
1) Предотвращение петель маршрутизации. В AS-Path не должно быть повторяющихся номеров На самом деле ASN может повторяться в AS-Path в двух случаяха) Когда вы используете AS-Path Prepend, о котором ниже.б) Когда вы хотите соединить два куска одной AS, не имеющих прямой связи друг сдругом.