Протоколы этого типа используются для определения маршрутов передачи данных между различными автономными системами. Такие протоколы обычно относят к классу Exterior Gateway Protocol. В настоящее время существуют два протокола данного типа:

• Border Gateway Protocol
• Exterior Gateway Protocol

Особенности внешней маршрутизации

Два маршрутизатора, которые обмениваются информацией о маршрутах, называются внутренними соседями в том случае, если они принадлежат к одной автономной системе и внешними – в том случае, если они принадлежат к различным автономным системам. На рисунке маршрутизаторы R2 R4 являются внутренними для автономных систем AS N и AS M соответственно. R1 и R3 совмещают функции внешнего и внутреннего маршрутизаторов. Маршрутизатор R1 представляет для автономной системы AS M маршруты к сетям, которые находятся в автономной системе AS N. Аналогичную функцию выполняет маршрутизатор R3 по отношению к маршрутам AS M.

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

Протокол маршрутизации EGP

Основные принципы построения протокола маршрутизации EGP определены в RFC 904 . Этот протокол маршрутизации имеет три основные черты:

• Использование механизма установления отношений между маршрутизаторами neighbor acquisition
• Маршрутизаторы EGP используют специальный механизм для определения статуса свих партнеров по протоколу
• Маршрутизаторы EGP периодически обмениваются информацией о достижимости сетей путем передачи сообщений об обновлениях маршрутов.

В процессе установления партнерских отношений, а также для выполнения обмена информацией о маршрутах, маршрутизаторы EGP обмениваются специальными сообщениями, которые передаются в режиме с подтверждением приема. В зависимости от ситуации, эти сообщения могут быть нескольких типов:

• Сообщения Neighbor Acquisition Messages
• Сообщения Neighbor Reach ability Messages
• Сообщения Poll Request Messages
• Сообщения Routing Update Messages

Сообщения об установлении отношений (Neighbor Acquisition)

Сообщения этого типа маршрутизатор передает в том случае, когда собирается установить с другим маршрутизатором отношения в соответствии с алгоритмами информационного обмена EGP.

Сообщения проверки состояния соседа Neighbor Reach ability

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

Когда маршрутизатор находится в активном состоянии (см. рисунок) он периодически посылает сообщения Hello вместе с обновлениями маршрутов и ожидает ответа от соседа. Если маршрутизатор находится в пассивном режиме, он может использовать содержимое поля STATUS для определения состояния соседа вместо того, чтобы периодически опрашивать его. Обычно оба маршрутизатора находятся в активном состоянии.

Сообщения проверки состояния маршрута Poll Request

Сообщения этого типа маршрутизатор передает в том случае, когда хочет установить, достижима или нет сеть SOURCE NETWORK.

Сообщения проверки состояния маршрута Routing Update

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

Как уже было выше отмечено, описание метрики маршрута в протоколе EGP указывается относительно общей сети, которая называется SOURCE NETWORK. Это является существенным отличием данного протокола от протоколов класса IGP. Рассмотрим представленный на рисунке пример:

В данном случае автономная система AS M использует маршрутизатор R1 для представления маршрутов к своим внутренним сетям для других автономных систем. В соответствии с принципом формирования информации о маршрутах, который принят в EGP, внутренние сети AS M будут представлены следующим образом:

Сообщение Error Response/Indication

Маршрутизатор EGP использует сообщения этого типа для того, чтобы предупредить соседний маршрутизатор о возникновении нештатной ситуации.

Недостатки протокола EGP

Протоколу EGP свойственен ряд существенных недостатков:

1. Маршрутизатор EGP представляет только один путь до каждой сети. Это делает невозможным использование процедур динамического перераспределения нагрузки между параллельными каналами
2. Маршрутизатор EGP не поддерживает внеклассовые сети.

Протокол маршрутизации BGP

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

Основные принципы построения BGP

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

• Inter-autonomous system routing маршруты которые соединяют данную автономную систему с одной или несколькими другими автономными системами
• Intra-autonomous system routing - протокол может быть использован для определения маршрута внутри автономной системы, в том случае, когда несколько маршрутизаторов участвуют в процессе определения маршрута BGP.
• Pass-through autonomous system - протокол может быть использован для определения маршрутов, которые проходят через автономную систему, которая не участвует в процессе BGP

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

• Начало сеанса (Open)
• Для периодической проверки состояния соседа (Keep Alive)
• При изменении содержания таблицы маршрутов автономной системы(update)
• При возникновении аварийной ситуации(Notification)

Формат сообщения BGP

Каждое сообщение BGP состоит из заголовка и последующих специфических полей:

В поле LENGTH помещается размер сообщения (вместе с заголовком), выраженный в байтах. В поле TYPE помещается код сообщения в соответствии со следующей таблицей:

В поле маркера может быть помещена информация, которая необходима для выполнения операции аутентификации абонента. Если установление подлинности абонента не требуется, маркер формируется значениями – все «1».

Сообщение OPEN

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

Поле VERSION

В данном поле размещается информация о номере версии протокола BGP. В настоящий момент используется версия 4 этого протокола.

Поле AS Number

В этом поле размещается номер автономной системы, в которой находится источник данного сообщения.

Поле Hold Time

Значение этого поля определяет величину интервала времени, в течение которого отправитель будет ожидать получения ответного сообщения в подтверждение установления сессии BGP.

Поле BGP Identifier

В этом поле размещается идентификатор отправителя сообщения – в качестве этого идентификатора может быть использован IP адрес одного из интерфейсов маршрутизатора.

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

Сообщение UPDATE

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

Поля Unfeasible Routes Length и Withdrawn Routes определяют уничтожаемые маршруты. В поле Withdrawn Routes размещаются описания отзываемых маршрутов. Если данное сообщение UPDATE не содержит уничтожаемых маршрутов, поле Unfeasible Routes Length должно иметь значение 0.

В поле Total Path Attribute Length – содержится выраженная в байтах длина поля Path Attributes. Атрибут каждого маршрута представляет собой совокупность трех значений: . Содержимое этих полей используется для гибкого определения таких атрибутов маршрута, как – путь, по которому был получен данный маршрут, Next hop gateway, и т.д.

В поле Network Layer Reach ability Information определяется собственно представляемая сеть. Для представления используются пара значений .

Причем значение length представляет собой выраженную в битах длину префикса сети, а в поле prefix помещается собственно префикс.

Протокол 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);
• Оптимальное использование пропускной способности (т. к. строится минимальный остовный граф по алгоритму Дейкстры);

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

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

Сегодня мы

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

Сначала освежим в памяти основы протоколов динамической маршрутизации.
Бывает два вида протоколов: 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.

– 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.

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 у них одинаковый, и никто из них раньше времени не разорвёт сессию.

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.

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

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

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

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

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

Control Plane и Data Plane

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

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

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

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

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

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

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

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

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

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

1. Максимальное значение Weight (локально для маршрутизатора, только для Cisco)
2. Максимальное значение Local Preference (для всей AS)
3. Предпочесть локальный маршрут маршрутизатора (next hop = 0.0.0.0)
4. Кратчайший путь через автономные системы. (самый короткий AS_PATH)
5. Минимальное значение Origin Code (IGP < EGP < incomplete)
6. Минимальное значение MED (распространяется между автономными системами)
7. Путь eBGP лучше чем путь iBGP
8. Выбрать путь через ближайшего IGP-соседа

   Если это условие выполнено, то происходит балансировка нагрузки между несколькими равнозначными линками

   Следующие условия могут различаться от вендора к вендору.

9. Выбрать самый старый маршрут для eBGP-пути
10. Выбрать путь через соседа с наименьшим BGP router ID
11. Выбрать путь через соседа с наименьшим 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

Пример

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 :

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

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 балансировка и распределение – это две большие разницы.

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

Включается она просто
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

Не будем на нём останавливаться, потому что используют его редко, да и наша сеть для этого не подходит – должно быть несколько соединений между двумя 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

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

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

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

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

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

PBR

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

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

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

• Выделение нужного трафика. Осуществляется либо с помощью 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#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 можно изменять очень много в подопытном пакете: начиная от меток 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 должен идти через Балаган Телеком.
Указанный трафик передается правильно, но не маршрутизируется остальной трафик из локальной сети, который должен передаваться через провайдера Балаган Телеком., .

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