Для чего нужен bgp

ИТ База знаний

Полезно

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Основы протокола Border Gateway Protocol (BGP)

Основной протокол маршрутизации

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

Онлайн курс по Кибербезопасности

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

Все статьи из цикла про BGP:

Полное руководство по BGP в PDF

Ох как мы любим PDF 🙃 Для вашего удобства, весь цикл статей по BGP (Border Gateway Protocol) мы «упаковали» в документ формата PDF.

Обзор BGP

На рисунке 1 показан пример топологии BGP.

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

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

Как компонент прикладного уровня, BGP делает что-то блестящее. Он использует протокол управления передачей (TCP) для своих операций. Если мы рассмотрим EIGRP в качестве примера, то создателям пришлось приложить большие усилия, чтобы встроить надежность в сам протокол. Например, спикер EIGRP будет передавать многоадресные передачи, и, если это не сработает, он вернется к одноадресным передачам, чтобы попытаться обеспечить надежность.

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

Когда мы формируем пиринг между автономными системами, это называется протоколом внешнего пограничного шлюза (EBGP). (Примечание: в некоторых литературных источниках EBGP пишется как eBGP.) Помните, что причина, по которой BGP различает пиринг IBGP и пиринг EBGP, заключается в том, что эксплуатационные характеристики должны изменяться в зависимости от того, как выполняется пиринг. Например, мы заявили, что существует путь AS, который записывает автономные системы, которые передаются. Очевидно, что при пиринге EBGP, когда префикс передается от одного AS к другому AS, отправляющий AS должен поместить свою автономную систему в путь. Но с IBGP, префикс остается в AS, поэтому протокол BGP не обновляет значение AS. Вы можете вернуться к рисунку 1, чтобы увидеть эти различные типы пиринга в действии.

Таким образом, правила меняются, когда мы говорим о IBGP против EBGP, чтобы быть последовательным и безошибочными. И уникальные свойства BGP просто не заканчиваются на этом.

Типы сообщений BGP, форматы и соседние типы сообщений состояния соседства BGP

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

В этом части статьи мы рассмотрим типы сообщений BGP. На рисунке 2 показаны различные типы сообщений BGP.

Запомните первый шаг. Когда два спикера BGP хотят сформировать пиринг, они будут полагаться на протокол управления передачей (TCP). И, конечно, мы знаем, что будет three-way handshake (трехстороннее рукопожатие) с TCP, чтобы начать этот надежный сеанс связи.

Что же происходит дальше? Так это то, что эти устройства будут обмениваться открытыми сообщениями. Открытое сообщение содержит очень важную информацию, основным компонентом которой является номер автономной системы однорангового узла. Это будет определять, является ли это пиринг IBGP или пиринг EBGP.

Если в какой-то момент времени что-то пойдет не так, спикеры BGP могут использовать простое сообщение Notification. Данное сообщение прерывает пиринг в результате ошибки, которая может произойти с BGP.

Одним из очень интересных типов сообщений BGP является тип сообщения Route Refresh (обновления маршрута). Хотя этот тип сообщений не был включен в исходный стандарт BGP, большинство наших основных сетевых вендоров поддерживают Route Refresh. Route Refresh позволяют соседям обновлять, скажем, информацию о маршруте BGP или даже обновлять вещи после довольно серьезной реконфигурации политики, не разрушая пиринг и не влияя на пиринг каким- либо большим негативным образом.

Рисунок 3 показывает эти типы сообщений в действии благодаря захвату Wireshark’ом обмена сообщениями BGP в нашем примере топологии из рисунка 1.

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

В этом части статьи мы еще больше узнаем об эксплуатационных характеристиках Border Gateway Protocol, более подробно рассмотрев типы сообщений BGP.

Каждый тип сообщения имеет заголовок BGP. Этот заголовок показан на рисунке 4. Вы видите, что заголовок BGP имеет большое поле маркера. Можно подумать, что это чрезвычайно важно. Он имеет размер 16 октетов. Как оказалось, это поле будет заполнено у всех.

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

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

Важными полями в заголовке, будут длина (Length) (то есть длина всего сообщения) и поля типа (Type). Поле Тип указывает, с каким типом сообщения BGP мы имеем дело.

Если, например, в этом поле 1, вы имеете дело с открытым (Open) сообщением BGP. Значение 2 указывает на сообщение об обновлении (Update). А 3 означает уведомление (Notification). Значение 4 будет иметь сообщение Keepalive. 5 указывает на необязательное Route Refresh.

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

Теперь я надеюсь вы понимаете, что, когда ваша система хочет сформировать BGP-пиринг с другим устройством, она собирается отправить открытое сообщение. На рисунке 5 показан формат этих сообщений.

Когда мы смотрим на формат открытого (Open) сообщения, мы замечаем, что там есть номер версии. Именно так BGP указывает на версию BGP, которую вы используете.

Ваша система также отправит свой номер AS в открытом сообщении. Это очень важно для такого поведения IBGP по сравнению с EBGP. Существует значение Hold Time. Что же такое Hold Time? Когда маршрутизатор, с которым вы хотите свериться, получает Open сообщение, он смотрит время удержания (Hold Time), смотрит на свое собственное настроенное Hold Time, а затем использует меньшее из двух значений. Hold Time должно быть либо нулевым, либо не менее трех секунд.

Есть поле BGP Identifier. Это Ваш BGP Router ID, и это уникальное значение, которое будет однозначно отличать вашу систему в пирингах BGP.

Наконец, у нас есть дополнительные параметры (Optional Parameter), которые можно задать с помощью открытого сообщения. Там есть необязательная длина параметра (Optional Parameter Length), а затем сами параметры, дающие дополнительную гибкость работы с протоколом.

Сообщение об обновлении BGP содержит индикатор длины отозванных маршрутов (Withdrawn Routes Length). Это гарантирует, что сообщение обновления является средством для маршрутов, которые будут удалены из таблицы BGP соседа. Примечание: затем в сообщение об обновлении вставляется список изъятых маршрутов.

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

Создатели BGP сделали гениальную вещь. Они создали протокол для передачи NLRI таким образом, чтобы он был гибким по мере изменения сетей и необходимости передачи новой информации. BGP создан для того, чтобы сразу же запускать для нас такие вещи, как IPv6. Он также может легко переносить префиксы VPN IPv4 внутри чего-то вроде MPLS VPN.

На рисунке 7 показаны поля сообщения уведомления (Notification).

Соседство BGP

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

Многие IGP спроектированы так, чтобы быть максимально быстро сходящимися. Это происходит потому, что в момент, когда происходит изменение внутри сети вашей организации, мы хотим sub-second сходимости других устройств, чтобы мы знали об этом изменении. BGP спроектирован по-другому. Таймеры имеют гораздо большую продолжительность, чем мы привыкли бы с нашим IGP, потому что мы хотим стабильности, жертвуя скоростью сходимости. В конце концов, BGP имеет дело с общедоступными таблицами маршрутизации интернета в развертываниях поставщиков услуг. Эти таблицы маршрутизации очень массивны. Нестабильность в этой среде приведет к катастрофе всего публичного Интернета.

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

Обратите внимание, что есть состояние простоя, когда устройство не инициирует ни одно из других состояний, и есть установленное состояние, когда оно полностью установлено со своим узлом. Что несколько удивительно, так это то, что есть все эти “промежуточные” состояния подключения, активного, открытого подтверждения (OpenConfirm) и активного.

Состояние — подключения-это состояние, в котором устройство BGP ожидает завершения TCP- соединения с соседним устройством.

Используя в Cisco CLI специальные команды, можно узнать все о состоянии BGP. Пример 1 показывает использование команды show ip bgp summary для проверки соседнего состояния.

Обратите внимание на пример 1. Этот пиринг BGP находится в состоянии ожидания (параметр State/PfxRcd в состоянии Idle). Как только произойдет соединение значение IDLE заменится на 1 (Если ATL использует только один префикс с TPA 1).

Онлайн курс по Кибербезопасности

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

Источник

Для чего нужен bgp

Если вы считаете, что её стоило бы доработать как можно быстрее, пожалуйста, скажите об этом.

BGP (Border Gateway Protocol) — это основной протокол динамической маршрутизации, который используется в Интернете.

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

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

Маршрутизация осуществляется пошагово от одной автономной системы к другой. Все политики BGP настраиваются, в основном, по отношению к внешним/соседним автономным системам. То есть, описываются правила взаимодействия с ними.

Так как BGP оперирует большими объемами данных (текущий размер таблицы для IPv4 более 450 тысяч маршрутов), то принципы его настройки и работы отличаются от внутренних протоколов динамической маршрутизации (IGP).

Содержание

[править] Терминология протокола

[править] Описание протокола

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

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

Как и другие протоколы динамической маршрутизации, BGP может передавать трафик только на основании IP-адреса получателя. Это значит, что с помощью BGP нет возможности настроить правила маршрутизации, в которых будет учитываться, например, то, из какой сети был отправлен пакет или данные какого приложения передаются. Если принимать решение о том как должен маршрутизироваться пакет, необходимо по каким-то дополнительным критериям, кроме адреса получателя, необходимо использовать механизм policy-based routing (PBR).

[править] Основные характеристики протокола

BGP это path-vector протокол с такими общими характеристиками:

[править] Автономная система

Автономная система (autonomous system, AS) — это система IP-сетей и маршрутизаторов, управляемых одним или несколькими операторами, имеющими единую, четко определенную политику маршрутизации с Интернетом (RFC 1930).

Диапазоны номеров автономных систем (autonomous system number, ASN):

[править] Описание работы протокола

По умолчанию BGP отправляет keepalive-сообщения каждые 60 секунд.

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

[править] Внутренний BGP (Internal BGP) и Внешний BGP (External BGP)

Если iBGP-маршрутизаторы работают в нетранзитной AS, то соединение между ними должно быть full mesh. Это следствие принципов работы протокола — если маршрутизатор, находящийся на границе AS, получил обновление, то он передает его всем соседям; соседи, которые находятся внутри автономной системы, больше это обновление не распространяют, так как считают, что все соседи внутри AS уже его получили.

[править] Таймеры протокола

[править] Типы сообщений BGP

У всех сообщений BGP такой формат заголовка:

Поля заголовка BGP-сообщений:

[править] Open

Open — используется для установки отношений соседства и обмена базовыми параметрами. Отправляется сразу после установки TCP-соединения.

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

Кроме стандартного заголовка пакета BGP, в сообщении Open такие поля:

[править] Update

Update — используется для обмена информацией маршрутизации.

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

[править] Notification

Notification — используется когда возникают ошибки BGP. После отправки сообщения сессия с соседом разрывается.

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

Кроме стандартного заголовка пакета BGP, в сообщении Notification такие поля:

[править] Keepalive

Keepalive — используется для поддерживания отношений соседства, для обнаружения неактивных соседей.

Сообщения Keepalive состоят только из заголовка пакета (длина 19 октетов).

Если периодичность отправки keepalive-сообщений выставлена в 0, то сообщения не отправляются.

[править] Отношения соседства

Для того чтобы установить отношения соседства, в BGP надо настроить вручную каждого соседа.

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

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

BGP выполняет такие проверки, когда формирует отношения соседства:

У первого пункта проверки есть некоторая особенность: только у одного из двух маршрутизаторов IP-адрес, указанный как адрес отправки обновлений, должен быть указан в команде neighbor другого маршрутизатора.

BGP выполняет проверку таймеров keepalive и hold, однако несовпадение этих параметров не влияет на установку отношений соседства. Если таймеры не совпадают, то каждый маршрутизатор будет использовать меньшее значение таймера hold.

[править] Состояния связи с соседями

Если не совпали IP-адреса с соседом, то этот сосед будет в состоянии active.

[править] Атрибуты пути (path attributes)

Атрибуты пути разделены на 4 категории:

Примеры атрибутов BGP:

[править] Autonomous system path

Атрибут Autonomous system path (AS Path):

Каждый сегмент атрибута AS path представлен в виде поля TLV (path segment type, path segment length, path segment value):

[править] Next-hop

Third party next hop:

[править] Origin

Атрибут Origin — указывает на то, каким образом был получен маршрут в обновлении.

Возможные значения атрибута:

[править] Local preference

Атрибут Local preference:

[править] Atomic aggregate

Метка, указывающая, что NLRI является summary.

[править] Aggregator

Список RID и ASN маршрутизаторов, создавших summary NLRI.

[править] Communities

Значения от 0x00000000 до 0x0000FFFF и от 0xFFFF0000 до 0xFFFFFFFF зарезервированы.

Как правило community отображаются в формате ASN:VALUE. В таком формате, доступны для использования community от 1:0 до 65534:65535. В первой части указывается номер автономной системы, а во второй значение community, которое определяет политику маршрутизации трафика.

Некоторые значения communities предопределены. RFC1997 определяет три значения таких community. Эти значения должны одинаково распознаваться и обрабатываться всеми реализациями BGP, которые распознают атрибут community.

Если маршрутизатор получает маршрут в котором указано предопределенное значение communities, то он выполняет специфическое, предопределенное действие основанное на значении атрибута.

Предопределенные значения communities (Well-known Communities):

Маршрутизаторы которые не поддерживают атрибут community, будут передавать его далее, так как это transitive атрибут.

[править] Multi exit discriminator (MED)

[править] Weight (проприетарный атрибут Cisco)

[править] Выбор пути

Характеристики процедуры выбора пути протоколом BGP:

[править] Cisco

На маршрутизаторе Cisco, если не настроены никакие политики выбора пути, выбор пути происходит таким образом (на каждый следующий шаг маршрутизатор переходит только при совпадении значений на предыдущем):

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

Только лучший путь помещается в таблицу маршрутизации и анонсируется BGP-соседям.

[править] BGP в маршрутизаторах Cisco

[править] BGP в маршрутизаторах Juniper

[править] BGP в Quagga

[править] Конфигурационные файлы qua2, qua4, qua6

Конфигурационные файлы на странице BGP/config.

[править] Дополнительная информация

Источник

Bgp протокол для чайников

Как работает интернет?

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

Всем своим соседям (не по дому, разумеется, а тем, с кем есть прямые соединения), владелец AS сообщает: «Чуваки! У меня есть AS номер XXX!» Это называется BGP-Анонсом.

Соседи принимают это во внимание и передают дальше. Вот владелец AS YYY всех оповещает: «чуваки! Через меня доступна ASXXX! Путь до нее: XXX YYY». Постепенно, у каждого участника этой вакханалии складывается маршрутная таблица, в которой всегда видно, что от своей ASZZZ до ASXXX можно дойти по маршруту «ZZZ YYY YYY1 XXX».

Всё это развлекательное мероприятие и называется «протокол BGP».

Радость от него была бы неполной, не будь в BGP возможности выбрать маршрут. От двух свои провайдеров можно получить разные маршруты до ZZZ. Если XXX подключен не только к YYY1, но и напрямую к YYY, то у него будет более выгодный маршрут всего из трех хопов, вместо четырех.

Надеюсь, вы еще не запутались в трех латинских буквах и можно перейти к IP адресам.

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

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

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

Как? А элементарно. Надо соседу, который сидит по ту сторону резервного канала, отдавать не просто свой номер AS, а целый маршрут до нее. Вот так: «XXX XXX XXX XXX XXX». Да-да, просто несколько раз указать свою же AS. Это называется «добавить препенды».

Возвращаясь к нашей картинке, AS XXX подключена к двум провайдерам: YYY1 — кривой, но с безнлимитным трафиком. YYY — устойчивый, но трафик за большое бабло. Владелец XXX предпочитает, чтобы пока работает YYY1, весь трафик гонялся через него. Поэтому специально для YYY сообщаем, что через нас видно «XXX XXX XXX». Поскольку маршрут от XXX до ZZZ напрямую через YYY теперь получается длиннее, то связь будет через YYY.

Главное, чтобы ни из одной точки интернета этот маршрут никогда не стал кратчайшим. Сколько препендов добавить обычно выбирается на глазок — ну 5-10. Более длинные маршруты в интернете встречаются редко.

Относится к классу протоколов маршрутизации внешнего шлюза (англ. EGP — External Gateway Protocol).

На текущий момент является основным протоколом динамической маршрутизации в сети Интернет.

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

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

BGP, наряду с DNS, является одним из главных механизмов, обеспечивающих функционирование Интернета.

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

Содержание

Формат сообщения [ править | править код ]

Сообщение BGP начинается с заголовка, после которого, в зависимости от типа сообщения, могут следовать данные. Максимальная длина сообщения — 4096 октетов, минимальная — 19 октетов. Заголовок сообщения содержит следующие поля:

Открытие [ править | править код ]

Первое сообщение после установки соединения должно быть «Открытие». Если сообщение успешно обработано, в ответ будет послано «Сохранение соединения». В дополнение к заголовку BGP сообщение «Открытие» содержит следующие поля:

Обновление информации [ править | править код ]

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

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

Сохранение соединения [ править | править код ]

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

Оповещение [ править | править код ]

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

Процесс выбора [ править | править код ]

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

Ну-с, приступим? Для начала простое — настройка интерфейсов.

Назначим и Loopback-интерфейсу какой-нибудь адрес, чтобы далее проверить связность:

А теперь самое вкусное — настройка BGP. Будем разбирать каждую строчку.

Сначала поднимаем процесс BGP и назначаем AS Number, именно тот, что выдал нам LIR!
Далее настраиваем пиринг, задаем информацию о соседе:

Командой neighbor мы указываем того, с кем будем поднимать сессию. На указанный адрес 101.0.0.1 наш маршрутизатор последовательно отправит сначала TCP-SYN, а затем OPEN-сообщение. Здесь же указываем номер автономки, с которой у нас намечается пиринг — AS64501.
Абсолютно симметричная конфигурация на противоположной стороне:

В CLI появится сообщение:

Ура? Ура, но проверим состояние процесса.

Одно состояние сменяет другое и вот достигнут Established. Маршрутизатор за это время отправил одно OPEN-сообщение и аналогичное получил, а также получил и принял по два KEEPALIVE.
Проверим о каких сетях знает BGP.
sh ip bgp

Ни-че-го. Смотрим на R2.

И тут тоже самое.
А всё тут просто. До прописанной командой network сети должен быть точный маршрут, в противном случае она не окажется в таблице BGP. А муршрута нет:

А его и вписывать некуда, кроме разве что Loopback-интерфейса. Ну нет нигде этой сети. Исхитримся так:

Маршрут говорит нам, что пакеты идущие в эту сеть будут дропнуты. Но это по плану, так надо. Просто напросто при наличии более конкретных маршрутов (маска больше /23, т.е. /24. /30. /32), то следуя правилу Longest Prefix Match будут выбираться именно они.
Радуемся. В BGP-таблице отобразился локальный маршрут:

Теперь если мы настроим процесс BGP и нужные маршруты на всех устройствах нашей схемы, то таблички BGP и маршрутизации на бордере (border — пограничный маршрутизатор сети) станет такой:



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

Мимо данной темы в контексте BGP и подключения к прову попросту невозможно пройти. Вот наша уютная компания уже имеет AS Number и вооружилась ворохом PI-адресов. При организации стыка с провайдером Балаган-Телеком нас строго спросят — «будем фулл вью или ограничимся дефолтом?»
Всё, что было у нас выше — это Full View. Маршрутизатор будет изучать все без исключения маршруты Интернета. Наш теоретический случай предусматривает штук пять-шесть маршрутов, но в действительности их более 400000. В итоге нам и один провайдер анонсирует 400 тысяч маршрутов и другой столько же. А вдруг будет еще резервный пров? Получите распишитесь, в итоге больше миллиона маршрутов.
Ну, и чего теперь, отваливать сотни нефти за мощную циску?

Вот так выглядит саммари маршрутной таблицы route-server.ip.att.net, одного публичного сервера. Можно стучаться телнетом.
По факту не всем автономкам нужно курить Full View, даже более-менее крупным компаниям достаточно Default Route и погнали. Идея простая. Вместо вороха точных маршрутов нам приходит по одному маршруту по-умолчанию от каждого из провайдеров. Впрочем, это может происходить не только вместо, но и вместе.
Разберемся в плюсах и минусах обоих случаев.
При работе с Full View вся структура интернета у вас перед глазами. Вы можете посмотреть трассу от себя до любого адреса глобальной сети:

И вы знаете, какие AS ведут к сети назначения, а RIPE позволяет узнать, какие провайдеры обеспечивают передачу. И мы можем без проблем следить за всеми изменениями сети. Даже если где-то далеко на крайних хопах у кого-то что-то отвалится (т.е. не обязательно у вас или одного из ваших провайдеров), BGP обнаружит это и перестроит таблицу маршрутизации в соответствии с изменением топологии, например, пустит трафик через второго провайдера.
И мы вольны гибко рулить маршрутами, тонко настраивая алгоритм выбора наилучшего пути. Допустим, трафик до яндекса мы будем пускать через «Балаган Телеком», а вот уже до гугла — через «Филькин Сертификат». Это будет load balancing — распределение нагрузки.
Сделать это можно, например, путем настройки приоритета маршрутов для определенных префиксов.
Ваш выбор без вариантов Full View, если ваша AS транзитная, т.е. к вам по BGP будут подключены еще клиенты.
Плюсов много, но расплатой здесь будет производительность. Готовьтесь к высокой утилизации оперативки и долгому изучению маршрутной информации после подъема BGP-сессии. Например, даже при кратковременном падении линка до вышестоящего провайдера на полное восстановление уйдет несколько минут.
А теперь Default Route. В первую очередь — это огромная экономия ресурсов нашего оборудования. Обслуживать тоже проще, больше нет задачи гонять тысячи и тысячи маршрутов внутри нашей AS. С другой стороны вы понятия не имеете о состоянии интернетов и доступности конечных узлов — вы тупо шлете трафик на дефолт, прилетевший от провайдера, апстрима (upstream). И если проблема где-то дальше, вы о ней не будете иметь понятия, а как следствие падение части предоставляемых сервисов. В этом месте мы отдаем всё на откуп вышестоящему провайдеру, надеясь, что там BGP быстренько перестроится и снова всё взлетит.
Балансировка и распределение входящего трафика не пострадает, мы этим сможем рулить, а вот управление исходящим накроется.

Давайте резюмировать. Если у вас нет цели гонять через себя транзитный трафик (подключать через себя другие AS) и не требуется гибкое распределение исходящего трафика, то вам дорога к Default Route.
Но вот точно не имеет смысла принимать от одного провайдера анонсы Full View, а от другого Default Route, т.к. один линк всегда будет простаивать и не станет гонять через себя исходящий трафик, ведь выбираться будет более специфический маршрут, который точно найдется среди анонсированного вам Full View.
Но ничего не мешает брать от всех провов Default Route и в нагрузку определенные префиксы (конкретно этого провайдера, например). Тогда до нужных ресурсов у вас будут специфические маршруты, но при этом без Full View.
Взглянем на пример настройки Default Route для линка в нижестоящему маршрутизатору:

Тогда на нашем бордере таблица маршрутов будет такой:

Теперь кроме обычных входящих в Full View маршрутов будет присутствовать и маршрут по-умолчанию.

И еще маленькое отступление перед погружением в пучины маршрутизации. Есть на эту тему годное мозговыносящее чтиво MPLS Enabled Application. Так что там с понятиями в заголовке? Это никакие не уровни сетевой модели, среды или некие моменты передачи данных, а лишь абстрактное деление.
Control Plane — уровень управления, где работают служебные протоколы, которые обеспечивают условия для передачи данных. Вот запускается BGP, следует по всем своим агрегатным состояниям и обменивается маршрутной информацией. Или же когда в MPLS-сетях LDP распределяет метки на префиксы. Таким же макаром обсуждавшийся уже STP обменивается BPDU и строит L2-топологию.
Все эти процессы живут в рамках Control Plane.
А вот Data Plane, передающий уровень — это уже передача полезных данных клиента.
Часто случается, что данные с этих двух уровней ходят в разных направлениях как бы «навстречу друг другу». Таким вот образом маршруты передаются из AS100 в AS200, чтобы в свою очередь AS200 могла передать данные в AS100.

И на разных уровнях могу быть совершенно отличные принципы работы. В том же MPLS на Data Plane создается само соединение, а непосредственно данные передаются посредством заранее определенного пути LSP. Сам же путь определяется по обычному TCP/IP стандарту, т.е. от одного хоста к другому.
Тут нужно понять назначение этих уровней и разницу в них.
Это крайне важный вопрос для BGP. Анонсируя свои маршруты вы одновременно создаете путь для входящего трафика — маршруты исходят от вас, а вот трафик течет к вам.

Нас ждет обширная тема — распределение нагрузки при помощи инструментов BGP. Но чтобы это постичь, нам для начала нужно разобраться каким вообще образом мы можем управлять маршрутами в данном протоколе. А возможностей уйма, именно поэтому протокол является таким гибким, прекрасно подходящим для маршрутизации между несколькими провайдерами, в отличие от любого из представителей IGP.
Можно выделить следующие инструменты:

Много? Но только два первых могут фильтровать анонсируемые и передаваемые маршруты. Остальное — выставление приоритетов.

Механизм этот очень мощный, но не пользуется особой популярностью. При помощи AS-Path ACL вы можете наглухо запретить прием анонсов от AS200, к примеру. Ну, вот не нужны нам от этой автономки анонсы, пускай будем получать их от другой.
Самое сложное — это запомнить все использующиеся при этом подходе выражения:

Давайте накидаем примеров, чтобы проще было понять.
_200_ Маршруты проходящие через AS 200
До и после номера AS идут знаки “_”, означающие, что в AS-path номер 200 может стоять в начале, середине или конце, главное, чтобы он был.
^200$ Маршруты из соседней AS 200
“^” означает начало списка, а “$” – конец. То есть в AS-path всего лишь один номер AS – это означает, что маршрут был зарождён в AS 200 и оттуда сразу был передан нам.
_200$ Маршруты отправленные из AS 200
“$” означает конец списка, то есть это самая первая AS, из неё маршрут и зародился, знак “_” говорит о том, что неважно, что находится дальше, хоть ничего, хоть 7 других AS.
^200_ Сети находящиеся за AS 200
Знак “^” означает, что ASN 200 была добавлена последней, то есть маршрут к нам пришёл из AS 200, но это не значит, что родился он в ней же – знак “_” говорит о том, что это может быть конец списка, а может пробел перед следующей AS.
^$ Маршруты локальной AS
Список AS-path пуст, значит маршрут локальный, сгенерированный внутри нашей AS.
Пример
Отфильтруем в нашей сети маршруты, появившиеся в AS64501. То есть мы будем получать от этой автономки все «глобальные интернетовские» маршруты, но ни одного её локального.

Источник