Маршрутизатор обычно закрепляется за несколькими сетями. Когда он получает пакет, он должен решить две задачи:

к какой сети он должен его передать;
по какому пути.

Последнее решение основано на выборе оптимального пути. Какой доступный путь является оптимальным путем? Это обычно определяется метрикой. Метрика – это условная стоимость передачи по сети. Полное измерение конкретного маршрута равно сумме метрик сетей, которые включают в себя маршрут . Маршрутизатор выбирает маршрут с наименьшей метрикой. Метрика назначается для интерфейса сети в зависимости от типа протокола. Некоторые простые протоколы, подобно протоколу маршрутной информации ( RIP – Routing Information Protocol ), рассматривают все сети как одинаковые. Тогда стоимость прохождения через каждую сеть - одна и та же, и для определения метрики подсчитываются участки. Так, если пакет, чтобы достигнуть конечного пункта, проходит через 10 сетей, полная стоимость составляет 10 участков.

Другие протоколы, такие как "первоочередное открытие наикратчайших путей" ( OSPF - Open Shortest Path First ), позволяют администратору назначить стоимость для передачи через сеть , основанную на типе требуемого обслуживания. Маршрут через сеть может иметь различную стоимость (метрику). Например, если для типа сервиса желательна максимальная производительность , спутниковый канал имеет меньшую метрику, чем оптическая линия. С другой стороны, если типу сервера желательна минимальная задержка, оптическая линия имеет меньшую метрику, чем спутниковый канал. OSPF позволяет каждому маршрутизатору иметь таблицу последовательностей маршрутов, основанную на требуемом типе сервиса.

Другие протоколы определяют метрику различно. В протоколе пограничной маршрутизации ( BGP - Border Gateway Protocol ) критерий - это политика, которую может устанавливать администратор . Политика - это принцип, по которому определяется путь .

В любой метрике маршрутизатор должен иметь таблицы маршрутизации, чтобы консультироваться при дальнейшей передаче пакета. Таблица маршрутизации задает оптимальный путь для пакета. Таблица может быть либо статическая, либо динамическая . Статическая таблица - одна из тех, которые часто не меняются. Динамическая таблица - одна из тех, которая обновляется автоматически, когда имеются изменения где-либо в Интернете. Сегодня Интернет нуждается в динамических таблицах. Таблицы нужно обновлять по мере появления изменений в Интернете. Например, их нужно обновить, когда маршрут вышел из строя, или они должны быть обновлены всякий раз, когда создается лучший маршрут .

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

В этой лекции мы поговорим об однонаправленных протоколах маршрутизации. Многонаправленные протоколы маршрутизации мы обсудим в следующей лекции.

Внутренняя и внешняя маршрутизация

Сегодня Интернет - громадная сеть , так что один протокол маршрутизации не может обрабатывать задачу обновления таблиц всех маршрутизаторов. По этой причине Интернет разделяется на автономные системы. Автономная система (Autonomous System – AS) - группа сетей и маршрутизаторов под управлением одного администратора. Маршрутизация внутри автономной системы отнесена к внутренней маршрутизации . Маршрутизация между автономными системами отнесена к внешней маршрутизации . Каждая автономная система может выбрать протокол внутренней маршрутизации для того, чтобы обрабатывать маршрутизацию внутри автономной системы. Однако для обработки маршрутизации между автономными системами выбирается только один протокол маршрутизации .

Разработано несколько внутренних и внешних протоколов. В этой лекции мы коснемся только наиболее популярных из них - внутренних протоколов RIP и OSPF и одного внешнего протокола BGP . RIP и OSPF используются для обновления таблиц маршрутизации внутри автономной системы. Протокол BGP применяется в обновлении таблиц маршрутизации для маршрутизаторов, которые объединяют вместе автономные системы.

Протокол маршрутной информации (RIP)

Протокол маршрутной информации ( RIP – Routing Information Protocol ) - внутренний протокол маршрутизации , используется внутри автономной системы. Это очень простой протокол, основанный на применении дистанционного вектора маршрутизации. В этом разделе сначала рассмотрим принцип дистанционного вектора маршрутизации, так как он применяется в RIP , а затем обсудим сам протокол RIP .

Вектор расстояния маршрутизации

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

Распределение информации о входе в автономную систему . Каждый маршрутизатор распределяет информацию о входе соседним автономным системам. Вначале эта информация может быть не подробной. Однако объем и качество информации не играют роли. Маршрутизатор посылает, во всяком случае, все что имеет.
Распределение только соседям . Каждый маршрутизатор посылает свою информацию только к соседям. Он посылает информацию, которую получает через все интерфейсы.
Распределение через регулярные интервалы . Каждый маршрутизатор посылает свою информацию соседней автономной системе через фиксированные интервалы, например, каждые 30 с.

До сих пор мы варились в собственном соку – 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 неразрывно связан с понятием Автономной Системы (AS – Autonomous System), которое уже не раз встречалось в нашем цикле.
Согласно определению вики, АС - это система IP-сетей и маршрутизаторов, управляемых одним или несколькими операторами, имеющими единую политику маршрутизации с Интернетом.

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

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

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

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

BGP

Так вот для того, чтобы нам из своей AS передать информацию об этих публичных адресах в другую AS (читай в Интернет) и используется BGP. И если вы думаете, что яндекс или майкрософт использует какие-то небесные технологии для подключения своих ЦОДов к Интернету, то вы ошибаетесь – всё тот же BGP.

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

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

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

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

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

Поэтому нужен свой специальный протокол для взаимодействия между 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

Вот пример неуспешного установления 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.

Нижеидущие 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 и другие инструменты

Одним из очень мощных инструментов работы с BGP – Looking Glass. Это сервера, расположенные в Интернете, которые позволяют взглянуть на сеть извне: проверить доступность, просмотреть через какие AS лежит путь в вашу автономную систему, запустить трассировку до своих внутренних адресов.

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

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

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

Control Plane и Data Plane

Перед тем, как окунуться в глубокий омут управления маршрутами, сделаем последнее лирическое отступление. Надо разобраться с понятиями в заголовке главы.
В своё время, читая MPLS Enabled Application , я сломал свой мозг на них. Просто никак не мог сообразить, о чём авторы ведут речь.
Итак, дабы не было конфузов у вас.
Это не уровни модели, не уровни среды или моменты передачи данных – это весьма абстрактное деление.
Управляющий уровень (Control Plane ) – работа служебных протоколов, обеспечивающих условия для передачи данных.
Например, когда запускается BGP, он пробегает все свои состояния, обменивается маршрутной информацией итд.
Или в MPLS-сети LDP распределяет метки на префиксы.
Или STP, обмениваясь BPDU, строит L2-топологию.

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

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

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

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

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

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

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

Этот протокол маршрутизации предназначен для сравнительно небольших и относительно однородных сетей. Маршрут характеризуется вектором расстояния до места назначения. Предполагается, что каждый маршрутизатор является отправной точкой нескольких маршрутов до сетей, с которыми он связан. Описания этих маршрутов хранится в специальной таблице, называемой маршрутной. Таблица маршрутизации RIP содержит по записи на каждую обслуживаемую машину (на каждый маршрут). Запись должна включать в себя:

IP -адрес места назначения.
Метрика маршрута (от 1 до 15; число шагов до места назначения).
IP -адрес ближайшего маршрутизатора по пути к месту назначения.
Таймеры маршрута.

Периодически (раз в 30 сек) каждый маршрутизатор посылает широковещательно копию своей маршрутной таблицы всем соседям-маршрутизаторам, с которыми связан непосредственно. Маршрутизатор-получатель просматривает таблицу. Если в таблице присутствует новый путь или сообщение о более коротком маршруте, или произошли изменения длин пути, эти изменения фиксируются получателем в своей маршрутной таблице. Протокол RIP должен быть способен обрабатывать три типа ошибок:

Циклические маршруты.
Для подавления нестабильностей RIP должен использовать малое значение максимально возможного числа шагов (не более 16).
Медленное распространение маршрутной информации по сети создает проблемы при динамичном изменении маршрутной ситуации (система не поспевает за изменениями). Малое предельное значение метрики улучшает сходимость, но не устраняет проблему.

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

Недостатки RIP

RIP не работает с адресами субсетей. Если нормальный 16-бит идентификатор ЭВМ класса B не равен 0, RIP не может определить является ли не нулевая часть c убсетевым ID , или полным IP -адресом.
RIP требует много времени для восстановления связи после сбоя в маршрутизаторе (минуты). В процессе установления режима возможны циклы.
Число шагов важный, но не единственный параметр маршрута, да и 15 шагов не предел для современных сетей.

OSPF (Open Shortest Path First ) - протокол динамической маршрутизации, основанный на технологии отслеживания состояния канала (link-state technology) и использующий для нахождения кратчайшего пути Алгоритм Дейкстры (Dijkstra’s algorithm).

OSPF имеет следующие преимущества:

Высокая скорость сходимости по сравнению с дистанционно-векторными протоколами маршрутизации;
Поддержка сетевых масок переменной длины (VLSM);
Оптимальное использование пропускной способности (т. к. строится минимальный остовный граф по алгоритму Дейкстры);

Описание работы протокола

Маршрутизаторы обмениваются hello-пакетами через все интерфейсы, на которых активирован OSPF. Маршрутизаторы, разделяющие общий канал передачи данных, становятся соседями, когда они приходят к договоренности об определённых параметрах, указанных в их hello-пакетах.
На следующем этапе работы протокола маршрутизаторы будут пытаться перейти в состояние смежности со своими соседями. Переход в состояние смежности определяется типом маршрутизаторов, обменивающихся hello-пакетами, и типом сети, по которой передаются hello-пакеты. OSPF определяет несколько типов сетей и несколько типов маршрутизаторов. Пара маршрутизаторов, находящихся в состоянии смежности, синхронизирует между собой базу данных состояния каналов.
Каждый маршрутизатор посылает объявления о состоянии канала маршрутизаторам, с которыми он находится в состоянии смежности.
Каждый маршрутизатор, получивший объявление от смежного маршрутизатора, записывает передаваемую в нём информацию в базу данных состояния каналов маршрутизатора и рассылает копию объявления всем другим смежным с ним маршрутизаторам.
Рассылая объявления внутри одной OSPF-зоны, все маршрутизаторы строят идентичную базу данных состояния каналов маршрутизатора.
Когда база данных построена, каждый маршрутизатор использует алгоритм «кратчайший путь первым» для вычисления графа без петель, который будет описывать кратчайший путь к каждому известному пункту назначения с собой в качестве корня. Этот граф - дерево кратчайших путей.
Каждый маршрутизатор строит таблицу маршрутизации из своего дерева кратчайших путей.

Протоколы внешней маршрутизации BGP и EGP

EGP (Exterior Gateway Protocol - протокол внешнего шлюза) был первым протоколом семейства TCP/IP, применяемым для организации взаимодействия автономных систем. Он до сих пор иногда используется. В EGP пограничный маршрутизатор АС не ищет соседей самостоятельно. Ему нужно заранее сообщить IP-адреса или полные доменные имена других пограничных маршрутизаторов, с которыми он будет обмениваться информацией.

Для реализации своих функций протокол использует систему следующих сообщений: Приобретение соседа (Neighbor Acquisition ). Прежде чем начать получать информацию от внешних маршрутизаторов, необходимо установить, какой маршрутизатор является соседним. Эта операция состоит из обмена сообщениями типа "приобретение соседа" (соответственно запрос/ ответ/ отказ и др.) через стандартный механизм трехходового квитирования. Ясно, что маршрутизатор предполагаемого соседа также должен поддерживать механизм сообщений типа "приобретение соседа". Сообщение "приобретение соседа" включает в себя поле интервала приветствия (hello interval ) и поле интервала опроса (poll interval ). Поле интервала приветствия определяет период интервала проверки работоспособности соседей. Поле интервала опроса определяет частоту корректировки маршрутизации.
Досягаемость соседа (Neighbor reachability ). Для маршрутизаторов, выполняющих функции связи различных доменов сетей, важно располагать самой последней информацией о работе своих соседей. Если маршрутизатор обнаруживает, что какой-либо шлюз не функционирует, ему необходимо немедленно приостановить поток данных к этому шлюзу. Для этих целей и используется данный тип сообщений.

EGP -протокол поддерживает два вида сообщений этого типа - сообщение приветствия (hello ) и ответа на приветствие (i heard you ). Выделение типа сообщений оценки досягаемости из общего потока корректирующих сообщений позволяет уменьшать сетевой график, так как изменения о досягаемости сетей обычно появляются чаще, чем изменения параметров маршрутизации. Любой узел EGP заявляет об отказе одного из своих соседей только после того, как от него не был получен определенный процент сообщений о досягаемости.

Опроса (Poll ). Чтобы обеспечить правильную маршрутизацию между AS , EGP должен знать об относительном местоположении отдаленных хостов. Сообщения опроса позволяют роутерам EGP получать информацию о досягаемости сетей, в которых находятся эти машины. Такие сообщения имеют помимо обычного заголовка только одно поле - поле сети источника IP (source network ). Это поле определяет сеть, которая должна использоваться в качестве контрольной точки запроса.
Корректировки маршрутизации (Routing update ). Сообщения о корректировке маршрутизации дают роутерам EGP возможность указывать местоположение различных сетей в пределах своих AS .

BGP ( Border Gateway Protocol ) это протокол внешних маршрутизаторов , предназначенный для связи между маршрутизаторами в различных автономных системах. BGP заменяет собой старый EGP.

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

IP датаграмма в АС может принадлежать как к локальному траффику, так и к транзитному траффику. Локальный - это траффик у которого источник и пункт назначения находятся в одной AS . При этом IP адреса источника и назначения указывает на хосты, принадлежащие одной автономной системе. Весь остальной траффик называется транзитным. Основное преимущество использования BGP в Internet заключается в уменьшении транзитного траффика.

Автономная система может принадлежать к следующим категориям:

Ограниченная (stub ) AS автономная система имеет единственное подключение к одной внешней автономной системе. В такой автономной системе присутствует только локальный траффик.
Многоинтерфейсная (multihomed ) AS имеет подсоединение к нескольким удаленным автономным системам, однако по ней запрещено прохождение транзитного траффика.
Транзитная (transit ) AS имеет подключение к нескольким автономным системам и в соответствии с ограничениями может пропускать через себя как локальный, так и транзитный траффик.

Общая топология Internet состоит из транзитных, многоинтерфейсных и ограниченных автономных систем. Ограниченные и многоинтерфейсные автономные системы не нуждаются в использовании BGP - они могут использовать EGP , чтобы обмениваться информацией о доступности с транзитными автономными системами.

BGP позволяет использовать маршрутизацию, основанную на политических решениях, где в се правила определяются администратором автономной системы и указываются в конфигурационных файлах BGP . Решения принимаются в соответствии с вопросами безопасности или экономической целесообразности.

BGP отличается от RIP или OSPF тем, что BGP использует TCP в качестве транспортного протокола. Две системы, использующие BGP , устанавливают TCP соединения между собой и затем обмениваются полными таблицами маршрутизации BGP . Обновления представляются в виде изменений таблицы маршрутизации (таблица не передается целиком).

BGP это протокол вектора расстояний, однако, в отличие от RIP (который объявляет пересылки к пункту назначения), BGP перечисляет маршруты к каждому пункту назначения (последовательность номеров автономных систем к пункту назначения). При этом исчезают некоторые проблемы, связанные с использованием протоколов вектора расстояний. Каждая автономная система идентифицируется 16-битным номером.

BGP определяет выход из строя канала или хоста на другом конце TCP соединения путем регулярной отправки сообщения "оставайся в живых" (keepalive ) своим соседям. Рекомендуемое время между этими сообщениями составляет 30 секунд. Сообщение "оставайся в живых", которое используется на уровне приложений, независимо от TCP опций "оставайся в живых"

BGP – это протокол маршрутизации внешнего шлюза, использующийся для проведения маршрутизации между маршрутными доменами (или автономными системами). BGP используются всеми поставщиками услуг Интернет, а также в ядрах очень крупных сетей.

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

Принцип работы дистанционно–векторного протокола маршрутизации:

Протокол BGP является протоколом вектора маршрута т.е. применяет информацию о векторе (направлении) и о пути к пункту назначения.

Пример работы дистанционно–векторного протокола маршрутизации

Предположим, что маршрутизатор А сгенерировал маршрут к сети 10.1.10/2А и объявил его маршрутизатору В. В информации о том, как достичь сети назначения 10.1.10/2А, маршрутизатор А указывает, что он является первым маршрутизатором в пути. Маршрутизатор В, получив этот маршрут, добавляет себя в путь и отправляет его маршрутизатору С, который, в свою очередь, добавляет себя в путь к сети 10.1.10/2А и отправляет маршрут маршрутизатору D. Когда маршрутизатор D получает маршрут к пункту назначения 10.1.10/2А, он обнаруживает, что путь к нему, проходит через маршрутизаторы С, В и А. Маршрутизатор D добавляет себя в путь и отсылает полученный маршрут обратно маршрутизатору А. Получив объявление маршрута, маршрутизатор А отвергает его, т. к. находит в соответствующем пути себя.

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

Протокол BGP не предъявляет никаких требований к топологии сети.

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

Выбор пути .Протокол BGP не использует метрики для определения петель в пути, они нужны ему для управления сетевыми правилами.

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

· Административный вес;

· Локальное предпочтение;

· Локально созданные маршруты;

· Кратчайший AS-путь;

· Наиболее низкий источник;

· Метрика МЕD (Мultiple Ехit Discriminator);

· Предпочтительные внешние пути;

· Путь через ближайшего соседа, если включена синхронизация;

· Путь через соседа с наименьшим идентификатором маршрутизатора;

Маршрут с кратчайшим AS – путем выбирается тогда, когда совпадают все более значимые факторы.

Сегодня мы

Разбираемся с протоколом BGP: виды, атрибуты, принципы работы, настройка
Подключаемся к провайдеру по BGP
Организуем резервирование и распределение нагрузки между несколькими линками
Рассмотрим вариант резервирования без использования BGP – IP SLA

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

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

BGP

Вообще 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.

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

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

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

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

BGP находится в соcтоянии IDLE, если нет маршрута к 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 в сообщении OPEN должны совпадать с настройками на удалённой стороне
Router ID должны различаться

Также внизу вы можете увидеть поддерживает ли маршрутизатор дополнительные возможности протокола.

Получив OPEN от R1, R2 отправляет свой OPEN, а также KEEPALIVE, говорящий о том, что OPEN от R1 получен – это сигнал для R1 переходить к следующему состоянию – Established.

Вот примеры неконсистентности параметров:

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

R2 отправляет обычный OPEN

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

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

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

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

Если 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 на них не задерживается.

Для каждого соседа можно посмотреть Uptime – как долго он находится в состоянии ESTABLISHED.

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

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

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

Атрибут ORIGIN сообщает о происхождении маршрута:

IGP – задан вручную командой network или получен по BGP
EGP – этот код вы никогда не встретите, означает, что маршрут получен из устаревшего протокола, который так и назывался – “EGP”, и был полностью повсеместно заменен BGP
Incomplete – чаще всего означает, что маршрут получен через редистрибьюцию

Ну и UPDATE от R2 к R1.

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

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

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

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

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

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

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

Control Plane и Data Plane

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

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

Выбор маршрута

Ситуация с маршрутами у нас такая.
Есть BGP-таблица, в которой хранятся абсолютно все маршруты, полученные от соседей.

То есть если есть у нас несколько маршрутов, до сети 100.0.0.0/23, то все они будут в BGP-таблице, независимо от “плохости” оных:

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

Итак, критерии выбора лучших:

Максимальное значение Weight (локально для маршрутизатора, только для Cisco)
Максимальное значение Local Preference (для всей AS)
Предпочесть локальный маршрут маршрутизатора (next hop = 0.0.0.0)
Кратчайший путь через автономные системы. (самый короткий AS_PATH)
Минимальное значение Origin Code (IGP < EGP < incomplete)
Минимальное значение MED (распространяется между автономными системами)
Путь eBGP лучше чем путь iBGP
Выбрать путь через ближайшего IGP-соседа
Если это условие выполнено, то происходит балансировка нагрузки между несколькими равнозначными линками
Следующие условия могут различаться от вендора к вендору.
Выбрать самый старый маршрут для eBGP-пути
Выбрать путь через соседа с наименьшим BGP router ID
Выбрать путь через соседа с наименьшим IP-адресом

Как видите, очень много критериев выбора. Причём они довольно сложные и с ходу их все понять непросто. Втягивайтесь потихоньку.
О некоторых упомянутых атрибутах мы поговорим ниже, а конкретно на выборе маршрутов остановимся в отдельной статье.

Схема: Общая схема сети
Условие: Full View на всех маршрутизаторах

Если вы сейчас посмотрите таблицу BGP на маршрутизаторе провайдера Балаган Телеком, то увидите 3 маршрута в сеть 102.0.0.0/21 – сеть Филькина Сертификата. И один из маршрутов ведёт через нашу сети ЛинкМиАп.

Это говорит о том, что наш бордер анонсирует чужие маршруты дальше, иными словами наша AS является транзитной.

Задание:
Настроить фильтрацию таким образом, чтобы наша AS64500 перестала быть транзитной.

Prefix-list

Тут всё просто и логично. Ну почти.

Префикс-листы – это просто привычные нам сеть/маска, и мы указываем разрешить такие маршруты или нет.

Синтаксис команды:
ip prefix-list {list-name} {deny|permit}
{network/length}

list-name – название списка. Ваш КО. Обычно указывается, как name_in или name_out . Это подсказывает нам на входящие или исходящие маршруты будет действовать (но, конечно, на данном этапе никак не определяет).
seq – порядковый номер правила (как в ACL), чтобы проще было оперировать с ними.
deny/permit – определяем разрешать такой маршрут или нет
network/length – привычная для нас запись, вроде, 192.168.14.0/24.
А вот дальше, внимание, сложнее – возможны ещё два параметра: ge и le . Как и при настройке NAT (или в ЯП Фортран), это означает "g reater or e qual" и "l ess or e qual".
То есть вы можете задать не только один конкретный префикс, но и их диапазон.

Например, такая запись
ip prefix-list NetDay permit 10.0.0.0/8 ge 10 le 16

будет означать, что будут выбраны следующие маршруты.

10.0.0.0/10, 10.0.0.0/11, 10.0.0.0/12, 10.0.0.0/13, 10.0.0.0/14, 10.0.0.0/15, 10.0.0.0/16

Пример

Сейчас мы запретим принимать анонс сети 120.0.0.0/24 через провайдер Филькин Сертификат, а все остальные разрешим. Запись 0.0.0.0/0 le 32 означает любые подсети с любой длиной маски (меньшей или равной 32 (0-32)).

Ip prefix-list TEST_PL_IN seq 5 deny 120.0.0.0/24
ip prefix-list TEST_PL_IN seq 10 permit 0.0.0.0/0 le 32

Router bgp 64500
neighbor 102.0.0.1 prefix-list TEST_PL_IN in

Сделаем на всякий случай оговорку: последний пример не означает, что соседний провайдер не будет вам их передавать – конечно, будет, ведь он-то ничего не знает о ваших политиках – а вот ваш маршрутизатор, получив такой анонс, не добавит маршрут в свою BGP-таблицу.

Конфигурация устройств .

Route Map

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

Синтаксис команды следующий:
route-map {map_name} {permit|deny} {seq}

map_name – имя карты
permit/deny – разрешаем или нет прохождение данных, подпадающих под условия route-map
seq – номер правила в route-map
match – условие подпадания трафика под данное правило.

expression :

Пример применения

Укажем, что в подсеть 120.0.0.0/24 предпочтительно ходить через Балаган Телеком, а в 103.0.0.0/22 через Филькин Сертификат. Для этого воспользуемся атрибутом Local Preference. Чем выше значение этого параметра, тем выше приоритет маршрута.

Ip prefix-list TEST1_IN seq 5 permit 120.0.0.0/24

Ip prefix-list TEST2_IN seq 5 permit 103.0.0.0/22

Route-map BGP1_IN permit 10
match ip address prefix-list TEST1_IN
set local-preference 50

Route-map BGP1_IN permit 20
set local-preference 100

Route-map BGP2_IN permit 10
match ip address prefix-list TEST2_IN
set local-preference 50
route-map BGP2_IN permit 20
set local-preference 100
router bgp 64500
neighbor 101.0.0.1 route-map BGP2_IN in
neighbor 102.0.0.1 route-map BGP1_IN in

Сначала мы создали обычным образом prefix-list , которым выделили подсеть 120.0.0.0/24. Permit означает, что на этот префикс в будущем будут действовать правила route-map. Как и в обычных ACL далее идёт неявное правило deny для всего остального. В данном случае оно означает, что под действие route-map подпадёт только 120.0.0.0/24 и ничего другого.

В созданной карте маршрутов BGP1_IN мы разрешили прохождение маршрутной информации (permit ), подпадающей под созданный prefix-list (match ip address prefix-list TEST1_IN ).
Для этих анонсов установим local preference в 50 – ниже, чем стандартные 100 (set local-preferеnce 50 ). То есть они будут менее «интересными».

И в конечном итоге привяжем карту к конкретному BGP-соседу (neighbor 102.0.0.1 route-map BGP1_IN in ).

Что же получается в результате?

Другие примеры рассмотрим в следующем разделе.

Схема: Общая схема сети

Тема: Поиск неисправностей.
От провайдеров: полная таблица маршрутов BGP

На маршрутизаторе msk-arbat-gw1 настроено распределение исходящего трафика между провайдерами Балаган Телеком и Филькин Сертификат. Трафик идущий в сети провайдера Филькин Сертификат, должен идти через него, если он доступен. Остальной исходящий трафик, должен передаваться через провайдера Балаган Телеком, когда он доступен.
При проверке исходящего трафика, оказалось, что при отключении Балаган Телеком, исходящий трафик к ЦОД (103.0.0.1) не идет через Филькин Сертификат.

Задание:
Исправить настройки так, чтобы исходящий трафик в сети провайдера ISP2, к его клиенту и в сеть удаленного офиса компании, шел через провайдера ISP2.

=====================

Балансировка и распределение нагрузки

“А какие вы знаете способы балансировки трафика в BGP?”
Это вопрос, который любят задавать на собеседованиях.

Начиная готовиться к этой статьей, я имел разговор с нашей Наташей, из которого стало понятно, что в BGP балансировка и распределение – это две большие разницы.

Балансировка нагрузки

Под балансировкой обычно понимается распределение между несколькими линками трафика, направленного в одну сеть.

Включается она просто
router bgp 100
maximum-paths 2

При этом должны выполняться следующие условия:

Не менее двух маршрутов в таблице BGP для этой сети.
Оба маршрута идут через одного провайдера
Параметры Weight, Local Preference, AS-Path, Origin, MED, метрика IGP совпадают.
Параметр Next Hop должен быть разным для двух маршрутов.

Последнее условие обходится скрытой командой
router bgp 64500
bgp bestpath as-path multipath-relax

В этом случае умаляется также условие полного совпадения AS-path, но длина должна быть по-прежнему одинаковой.

Как мы можем проверить это на нашей сети? Нам ведь нужно убедиться, что балансировка работает.

Балансировка обычно осуществляется на базе потоков (IP-адрес/порт отправителя и IP-адрес/порт получателя), чтобы пакеты приходили в правильном порядке. Поэтому нам нужно создать два потока.
Нет ничего проще:
1) ping непосредственно с msk-arbat-gw1 на 103.0.0.1
2) подключаемся телнетом на msk-arbat-gw1 (не забыв настроить параметры) с любого другого маршрутизатора и запускаем пинг с указанием источника (чтобы потоки чем-то отличались друг от друга)

После этого один пинг пойдёт через один линк, а второй через другой. Проверено

По умолчанию никак не учитывается пропускная способность внешних каналов. Такая возможность однако реализована и запускается командами

Router bgp 64500
bgp dmzlink-bw
neighbor 101.0.0.1 dmzlink-bw
neighbor 102.0.0.1 dmzlink-bw

Схема: Общая схема сети
Условие: ЛинкМиАп получает от обоих провайдеров маршрут по умолчанию.

Задание:
Настроить балансировку исходящего трафика между маршрутами по умолчанию от провайдеров Балаган Телеком и Филькин Сертификат в пропорции 3 к 1.

Схема: Общая схема сети
Условие: ЛинкМиАп получает Full View от обоих провайдеров.

Задание:
Не используя атрибуты weight, local preference или фильтрацию, настроить маршрутизатор msk-arbat-gw1 так, чтобы для исходящего трафика Балаган Телеком был основным, а Филькин Сертификат резервным.

2) MED

Multiexit Discriminator. В cisco он называется метрикой (Inter-AS метрика). MED является слабым атрибутом. Слабым, потому что он проверяется лишь на шестом шаге при выборе маршрута и оказывает по сути слабое влияние.
Если Local Preference влияет на выбор пути выхода трафика из Автономной системы, то MED передаётся в соседние AS и таким образом влияет на пути входа трафика.
Вообще MED и Local Preference часто путают новички, поэтому опишем в табличке разницу

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

3) Анонс разных префиксов через разных ISP

Ещё один способ распределить нагрузку – раздавать разные сети разным провайдерам.

Сейчас в сети ЦОДа наши анонсы выглядят так:

То есть наша сеть 100.0.0.0/23 известна через два пути, но в таблицу маршрутизации добавится только один. Соответственно и весь трафик назад пойдёт одним – лучшим путём.

Но!
Мы можем разделить её на две подсети /24 и одну отдавать в Балаган Телеком, а другую в Филькин Сертификат.
Соответственно ЦОД будет знать про эти подсети через разные пути:

Настраивается это так.

Во-первых, мы прописываем все свои подсети – все 3: одну большую /23 и две маленькие /24:
router bgp 64500
network 100.0.0.0 mask 255.255.254.0
network 100.0.0.0 mask 255.255.255.0
network 100.0.1.0 mask 255.255.255.0

Для того, чтобы они могли быть анонсированы, нужно создать маршруты до этих подсетей.
ip route 100.0.0.0 255.255.254.0 Null0
ip route 100.0.0.0 255.255.255.0 Null0
ip route 100.0.1.0 255.255.255.0 Null0

А теперь создаём префикс-листы, которые разрешают каждый только одну подсеть /24 и общую /23.
ip prefix-list LIST_OUT1 seq 5 permit 100.0.0.0/24
ip prefix-list LIST_OUT1 seq 10 permit 100.0.0.0/23
!
ip prefix-list LIST_OUT2 seq 5 permit 100.0.1.0/24
ip prefix-list LIST_OUT2 seq 10 permit 100.0.0.0/23

Осталось привязать префикс-листы к соседям.
router bgp 64500
neighbor 101.0.0.1 remote-as 64501
neighbor 101.0.0.1 prefix-list LIST_OUT1 out
neighbor 102.0.0.1 remote-as 64502
neighbor 102.0.0.1 prefix-list LIST_OUT2 out

Привязываем мы их на OUT – на исходящий, потому что речь о маршрутах, которые мы отправляем вовне.

Итак, соседу 101.0.0.1 (Балаган Телеком) мы будем анонсировать сети 100.0.0.0/24 и 100.0.0.0/23.
А соседу 102.0.0.1 (Филькин Сертификат) – сети 100.0.1.0/24 и 100.0.0.0/23.

Результат будет таким:

Вроде бы, неправильно, потому что у нас по два маршрута в каждую сеть /24 – через Балаган Телеком и через Филькин Сертификат.
Но если приглядеться, то вы увидите, что согласно AS-Path у нас такие маршруты:

То есть, по сути всё правильно. Да и в таблицу маршрутизации всё помещается правильно:

Теперь осталось ответить на вопрос какого лешего мы тащили за собой большую подсеть /23? Ведь согласно правилу Longest prefix match более точные маршруты предпочтительней, то есть /23, как бы и не нужен, когда есть /24.

Но вообразим себе ситуацию, когда падает сеть Балаган Телеком. Что при этом произойдёт

Существуют также специальные организации, которые отслеживают анонсы BGP в Интернете и, если вдруг происходит что-то неожиданное, может уведомить владельца сети. Подсеть 100.0.0.0/24 перестанет быть известной в интернете – ведь только Балаган Телеком что-то знал о ней благодаря нашей настройке. Соответственно, ляжет и часть нашей сети. Но! Нас спасает более общий маршрут 100.0.0.0/23. Филькин Сертификат знает о нём и анонсирует его в Интернет. Соответственно, хоть ЦОД и не знает про сеть 100.0.0.0/24, он знает про 100.0.0.0/23 и пустит трафик в сторону Филькина Сертификата.

То есть, слава Лейбницу, мы застрахованы от такой ситуации.

Надо иметь ввиду, что помимо настройки маршрутизатора вам придётся завести все три сети в базе данных RIPE. Там должны быть и обе сети /24 и сеть /23.

Конфигурация устройств

4) BGP Community

C помощью BGP Community можно давать провайдеру указания, что делать с префиксом, кому передавать, кому нет, какой local preference у себя ставить и т.д. Рассматривать этот вариант сейчас не будем, потому что тему коммьюнити мы перенесём в следующий выпуск.

Схема: Общая схема сети

Условие: На маршрутизаторе msk-arbat-gw1 настроено управление входящим и исходящим трафиком. Основной провайдер Балаган Телеком, резервый – Филькин Сертификат. При проверке настроек оказалось, что исходящий трафик передается правильно. При проверке входящего трафика, оказалось, что входящий трафик идет и через провайдера Балаган Телеком, но когда отключается Балаган Телеком, входящий трафик не идет через Филькин Сертификат.

Задание: Исправить настройки.

Подробности задачи и конфигурация
=====================

Вы можете её качать и использовать, как пожелаете с указанием авторства.

PBR

Все технологии маршрутизации, которые мы применяли до этого момента в наших статьях, будь то статическая маршрутизация, динамическая маршрутизация (IGP или EGP), в своей работе принимали во внимание только один признак пакета: адрес назначения. Все они, упрощенно, действовали по одному принципу: смотрели, куда идет пакет, находили в таблице маршрутизации наиболее специфичный маршрут до пункта назначения (longest match), и переправляли пакет в тот интерфейс, который был записан в таблице напротив этого самого маршрута. В этом, в общем-то, и состоит суть маршрутизации. А что, если такой порядок вещей нас не устраивает? Что, если мы хотим маршрутизировать пакет, отталкиваясь от адреса источника? Или нам нужно мальчики HTTP направо, девочки SNMP налево?

В такой ситуации нам приходит на помощь маршрутизация на базе политик ака PBR (Policy based routing). Эта технология позволяет нам управлять трафиком, базируясь на следующих признаках пакета:

Адрес источника (или комбинация адрес источника-адрес получателя)
Информация 7 уровня (приложений) OSI
Интерфейс, в который пришел пакет
QoS-метки
Вообще говоря, любая информация, используемая в extended-ACL (порт источника\получателя, протокол и прочее, в любых комбинациях). Т.е. если мы можем выделить интересующий нас трафик с помощью расширенного ACL, мы сможем его смаршрутизировать, как нам будет угодно.

Плюсы использования PBR очевидны: невероятная гибкость маршрутизации. Но и минусы тоже присутствуют:

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

Политика, на основе которой осуществляется PBR, создается командой route map POLICY_NAME , и содержит два раздела:

Выделение нужного трафика. Осуществляется либо с помощью ACL, либо в зависимости от интерфейса, в который трафик пришел. За это отвечает команда match в режиме конфигурации route map
Применение действия к этому трафику. За это отвечает команда set

Немного практики для закрепления

Имеем вот такую топологию:

В данный момент трафик R1-R5 и обратно идет по маршруту R1-R2-R4-R5, для удобства, адреса присвоены так, чтобы последняя цифра адреса была номером маршрутизатора:

R1#traceroute 192.168.100.5
1 192.168.0.2 20 msec 36 msec 20 msec
2 192.168.2.4 40 msec 44 msec 16 msec
3 192.168.100.5 56 msec * 84 msec

R5#traceroute 192.168.0.1
1 192.168.100.4 56 msec 40 msec 8 msec
2 192.168.2.2 20 msec 24 msec 16 msec
3 192.168.0.1 64 msec * 84 msec

Для примера, предположим, что нам нужно, чтобы обратно трафик от R5 (с его адресом в источнике) шел по маршруту R5-R4-R3 -R1. По схеме очевидно, что решение об этом должен принимать R4. На нем сначала создаем ACL, который отбирает нужные нам пакеты:
R4(config)#access-list 100 permit ip host 192.168.100.5 any

Затем создаем политику маршрутизации с именем “BACK”:
R4(config)#route-map BACK

Внутри нее говорим, какой трафик нас интересует:
R4(config-route-map)#match ip address 100

И что с ним делать:
R4(config-route-map)#set ip next-hop 192.168.3.3

После чего заходим на интерфейс, который смотрит в сторону R5 (PBR работает с входящим трафиком!) и применяем на нем полученную политику:
R4(config)#int fa1/0
R4(config-if)#ip policy route-map BACK

Проверяем:

R5#traceroute 192.168.0.1
1 192.168.100.4 40 msec 40 msec 16 msec
2 192.168.3.3 52 msec 52 msec 44 msec
3 192.168.1.1 56 msec * 68 msec

Работает! А теперь посмотрим внимательно на схему и подумаем: все ли хорошо?

А вот и нет!
Следуя данному ACL, у нас заворачивается на R3 весь трафик с источником R5. А это значит, что если, например, R5 захочет попасть на R2, он, вместо короткого и очевидного маршрута R5-R4-R2, будет послан по маршруту R5-R4-R3-R1-R2. Поэтому, нужно очень аккуратно и вдумчиво составлять ACL для PBR, делая его максимально специфичным.

В этом примере мы в качестве действия, применяемого к трафику, выбрали переопределение некстхопа (узла сети, куда дальше отправится пакет). А что еще можно сделать с помощью PBR? Имеются в наличие команды:

set ip next-hop
set interface
set ip default next-hop
set default interface

С первыми двумя все относительно понятно – они переопределяют некстхоп и интерфейс, из которого пакет будет выходить (чаще всего set interface применяется для point-to-point линков). А в случае, если мы применяем команды set ip default next-hop или set default interface, роутер сначала смотрит таблицу маршрутизации, и, если там имеется маршрут для проверяемого пакет, отправляет его соответственно таблице. Если маршрута нет, пакет отправляется, как сказано в политике. К примеру, если бы мы в нашей топологии вместо set ip next-hop 192.168.3.3 скомандовали set ip default next-hop 192.168.3.3, ничего бы не поменялось, так как у R4 есть маршрут к R1 (через R2). Но если бы он отсутствовал, трафик направлялся бы к R3.

Вообще говоря, с помощью команды set можно изменять очень много в подопытном пакете: начиная от меток QoS или MPLS и заканчивая атрибутами BGP

=====================

Схема и конфигурация . Маршрутизаторы провайдеров также не используют BGP.

Задание: Настроить переключение между провайдерами.
Маршрут по умолчанию к Балаган Телеком должен использоваться до тех пор, пока приходят icmp-ответы на пинг google (103.0.0.10) ИЛИ yandex (103.0.0.20). Запросы должны отправляться через Балаган Телеком. Если ни один из указанных ресурсов не отвечает, маршрут по умолчанию должен переключиться на провайдера Филькин Сертификат. Для того чтобы переключение не происходило из-за временной потери отдельных icmp-ответов, необходимо установить задержку переключения, как минимум, 5 секунд.

Схема: как и для других задач по PBR. Конфигурация ниже.

Условие: ЛинкМиАп использует статические маршруты к провайдерам (не BGP).

На маршрутизаторе msk-arbat-gw1 настроена PBR: HTTP-трафик должен идти через провайдера Филькин Сертификат, а трафик из сети 10.0.2.0 должен идти через Балаган Телеком.
Указанный трафик передается правильно, но не маршрутизируется остальной трафик из локальной сети, который должен передаваться через провайдера Балаган Телеком., .

У цикла “Сети для самых маленьких” есть свой сайт: , где вы сможете найти все выпуски аккуратно сложенными и готовыми к вдумчивому чтению.