Правила назначения номеров приватных автономных систем. Пояснить принцип работы протокола BGP. Основные пакеты и их форматы. Сообщения проверки состояния маршрута Poll Request

До сих пор мы варились в собственном соку – VLAN’ы, статические маршруты, OSPF. Плавно росли над собой из зелёных студентов в крепких инженеров.
Теперь отставим в сторону эти игрушки, пришло время BGP.

Сегодня мы

• Разбираемся с протоколом BGP: виды, атрибуты, принципы работы, настройка


• Подключаемся к провайдеру по BGP


• Организуем резервирование и распределение нагрузки между несколькими линками


• Рассмотрим вариант резервирования без использования BGP – IP SLA

Друзья, статья 90 000 символов не помещается в ЖЖ, поэтому прошу проследовать на сайт linkmeup.ru , где она в полном варианте.

Сначала освежим в памяти основы протоколов динамической маршрутизации.
Бывает два вида протоколов: IGP (внутренние по отношению к вашей автономной системе) и EGP (внешние).
И те и другие опираются на один из двух алгоритмов: DV (Distance Vector) и LS (Link State).
Внутренние мы уже рассматривали . К ним относятся ISIS/OSPF/RIP/EIGRP. Нужны они для того, чтобы обеспечить распространение маршрутной информации внутри вашей сети.

EGP представляет только один протокол – BGP – Border Gateway Protocol. Он призван обеспечивать передачу маршрутов между различными сетями (автономными системами).
Грубо говоря, стык между Балаган-Телекомом и его аплинковым провайдером будет точно организован через BGP.
То есть схема применения примерно такая:

Автономномые системы – AS

Чтобы было немного понятнее, можно, например, представить, что город – это автономная система. И как два города связаны между собой магистралями, так и две АС связываются между собой BGP. При этом внутри каждого города есть своя дорожная система – IGP.

Вот как это выглядит с небольшого отдаления:

В BGP AS – это не просто какая-то абстрактная вещь для удобства. Эта штука весьма формализована, есть специальные окошки в собесе, где можно в будние дни с 9 до 6 получить номер автономной системы. Выдачей этих номеров занимаются RIR (Regional Internet Reistry) или LIR (Local Internet Registry).

Вообще глобально этим занимается IANA . Но чтобы не разорваться, она делегирует свои задачи RIR – это региональные организации, каждая из которых отвечает за определённую часть планеты (Для Европы и России – это RIPE NCC)

BGP

Теперь главный вопрос, который интересует всегда новичков: а зачем BGP, почему не взять пресловутый OSPF или вообще статику?

Наверное, большие дяди могут очень подробно и обстоятельно объяснить это, мы же постараемся дать поверхностное понимание.

– Если говорить о OSPF/IS-IS, то это Link-State алгоритмы, которые подразумевают (внимание!), что каждый маршрутизатор знает топологию всей сети. Представляем себе миллионы маршрутизаторов в Интернете и отказываемся от идеи использовать Link State для этих целей вообще.

Вообще OSPF при маршрутизации между area"ми является фактически distance vector протоколом. Гипотетически, можно было бы заменить «AS» на «Area» в плане глобальной маршрутизации, но OSPF просто не предназначен для переваривания таких объемов маршрутной информации, да и нельзя выделить в интернете Area 0.

RIP, EIGRP... Кхе-кхе. Ну, тут всё понятно.

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

Поэтому нужен свой специальный протокол для взаимодействия между AS.
Во-первых, он должен быть дистанционно-векторным – это однозначно. Маршрутизатор не должен делать расчёт маршрута до каждой сети в Интернете, он лишь должен выбрать один из нескольких предложенных.
Во-вторых, он должен иметь очень гибкую систему фильтрации маршрутов . Мы должны легко определять, что светить соседям, а что не нужно выносить из избы.
В-третьих, он должен быть легко масштабируемым , иметь защиту от образования петель и систему управления приоритетами маршрутов .
В-четвёртых, он должен обладать высокой стабильностью . Поскольку данные о маршрутах будут передаваться через среду, которая не всегда может обладать гарантированным качеством (за стык отвечают по крайней мере две организации), необходимо исключить возможные потери маршрутной информации.
Ну и логичное, в-пятых, он должен понимать, что такое AS, отличать свою AS от чужих.

Встречайте: BGP .

Вообще описание работы этого поистине грандиозного протокола мы разобьём на две части. И сегодня рассмотрим принципиальные моменты.

BGP делится на IBGP и EBGP.

IBGP необходим для передачи BGP-маршрутов внутри одной автономной системы. Да, BGP часто запускается и внутри AS, но об этом мы плотненько поговорим в другой раз.
EBGP – это обычный BGP между автономными системами. На нём и остановимся.

Установление BGP-сессии и процедура обмена маршрутами

Устройства, между которыми устанавливается BGP-сессия называются BGP-пирами или BGP-соседями.

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

I) Изначальное состояние BGP-соседства – IDLE . Ничего не происходит.

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

II) Для обеспечения надёжности BGP использует TCP.
Это означает, что теоретически BGP-пиры могут быть подключены не напрямую, а, например, так .

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

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

На 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.

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

Информация о сетях появилась теперь в таблице BGP:

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

UPDATE передаются при каждом изменении в сети до тех пор пока длится BGP-сессия. Заметьте, никаких синхронизаций таблиц маршрутизации нет, в отличии от какого-нибудь OSPF. Это было бы технически глупо – полная таблица маршрутов BGP весит несколько десятков мегабайтов на каждом соседе.

VI) Теперь, когда всё хорошо, каждый BGP-маршрутизатор регулярно будет рассылать сообщения KEEPALIVE . Как и в любом другом протоколе это означает: "Я всё ещё жив". Это происходит с истечением таймера Keepalive – по умолчанию 60 секунд.

Если BGP-сессия устанавливается нормально, но потом рвётся и это повторяется с некой периодичностью – верный знак, что не проходят keepalive. Скорее всего, период цикла – 3 минуты (таймер HOLD по умолчанию). Искать проблему надо на L2. Например, это может быть плохое качество связи, перегрузки на интерфейсе или ошибки CRC.

Ещё один тип сообщений BGP – ROUTE REFRESH – позволяет запросить у своих соседей все маршруты заново без рестарта BGP процесса.

Условие:
Настройки маршрутизаторов несущественны. Никаких фильтров маршрутов не настроено. Почему на одном из соседей отсутствует альтернативный маршрут в сеть 195.12.0.0/16 через AS400?

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

Looking Glass и другие инструменты

Это как если бы вы попросили кого-то: “слушай, а посмотри, как там мои анонсы видятся?”, только просить никого не нужно.

Не стоит недооценивать силу внешних инструментов. Однажды у меня была проблема с очень низкой скоростью отдачи вовне. Она едва переваливала за несколько мегабит. После довольно продолжительного траблшутинга, решил взглянуть в Looking Glass. Какого же было моё удивление, когда я обнаружил, что трафик идёт ко мне, через VPN канал до филиала в другом городе, с которым установлен IBGP. Естественно, ширина канала была небольшой и утилизировалась практически полностью.

Существуют также специальные организации, которые отслеживают анонсы BGP в Интернете и, если вдруг происходит что-то неожиданное, может уведомить владельца сети – BGPMon , Renesys , RouterViews .
Благодаря им было предотвращено несколько глобальных аварий.

Control Plane и Data Plane

Всё это примеры процессов Control Plane. То есть это подготовка сети к передаче – организация коммутации, наполнение таблицы маршрутизации.

Передающий уровень (Data Plane ) – собственно передача полезных данных клиентов.

Часто случается так, что данные двух уровней ходят в разных направлениях, “навстречу друг другу”. Так в BGP маршруты передаются из AS100 в AS200 для того, чтобы AS200 могла передать данные в AS100.

Более того, на разных уровнях могут быть разные парадигмы работы. Например, в MPLS Data Plane ориентирован на создание соединения, то есть данные там передаются по заранее определённому пути – LSP.
А вот сам этот путь подготавливается по стандартным законам IP – от хоста к хосту.

Важно понять назначение уровней и в чём разница.

Для BGP это принципиальный вопрос. Когда вы анонсируете свои маршруты, фактически вы создаёте путь для входящего трафика . То есть маршруты исходят от вас, а трафик к вам.

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

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

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 октет);
  • Значение параметра.

Обновление информации

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

• Длина удаляемых маршрутов (2 октета);
• Удаляемые маршруты:
  • Длина (1 октет) - длина в битах префикса IP-адреса;
  • Префикс IP-адреса, дополненный минимальным количеством бит до полного октета;
• Длина атрибутов пути (2 октета);
• Атрибуты пути:
  • Тип атрибута:
    • Флаг атрибута;
    • Код атрибута;
  • Длина атрибута (1 или 2 октета, в зависимости от флага);
  • Данные атрибута;
• Информация о достижимости - список префиксов IP-адресов:
  • Длина (1 октет) - длина в битах префикса IP-адреса (нулевая длина - соответствие всем IP-адресам);
  • Префикс IP-адреса, дополненный минимальным количеством бит до полного октета.

Все атрибуты пути соответствуют всем записям в поле «Информация о достижимости».

Сохранение соединения

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

Оповещение

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

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

Процесс выбора

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

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

См. также

Ссылки

• RFC 1105 (англ.) , A Border Gateway Protocol version 1
• RFC 1163 (англ.) , A Border Gateway Protocol version 2
• RFC 1164 (англ.) , Application of the Border Gateway Protocol in the Internet
• RFC 1265 (англ.) , BGP Protocol Analysis
• RFC 1266 (англ.) , Experience with the BGP Protocol
• RFC 1403 (англ.) , BGP OSPF Interaction
• RFC 4271 (англ.) , A Border Gateway Protocol 4 (BGP-4)
• RFC 1772 (англ.) , Application of the Border Gateway Protocol version 4 in the Internet
• RFC 1773 (англ.) , Experience with the BGP-4 Protocol
• RFC 4274 (англ.) , BGP-4 Protocol Analysis
• RFC 1863 (англ.) , A BGP4/IDRP Route Server alternative to a full mesh routing
• RFC 1997 (англ.) , BGP Communities Attribute
• RFC 1998 (англ.) , An Application of the BGP Community Attribute in Multi-home Routing
• BGP протокол (рус.) , Использование BGP для междоменного роутинга (примеры настройки Cisco маршрутизаторов)

Литература

• Установка и настройка BGP , используя ПО маршрутизации Quagga в Gentoo Linux
• Настройка BGP на Linux (Quagga Zebra) с автоматической балансировкой нагрузки по трем каналам и резервированием
• Уильям Р. Паркхерст Справочник по командам и настройке протокола BGP-4 маршрутизаторов Cisco = Cisco BGP-4 Command and Configuration. - М .: «Вильямс», 2002. - С. 384. - ISBN 1-58705-017-X
• BGP протокол (перевод на русский) = CISCO UNIVER CD.