В предыдущем статья Я описал общую архитектуру Quagga и структуру таблицы маршрутизации, которая находится в демоне zebra. В этой статье я хочу рассказать о конструкции демона bgpd, отвечающего за реализацию протокола BGP. Я не буду описывать общую информацию о протоколе BGP. О нем написано огромное количество хороших статей и книг, а с логикой его работы можно ознакомиться, например, Здесь .
Я остановлюсь на механизме его реализации в демоне bgpd. Для удобства описание демона bgpd можно разделить на две части.
Назовем первую часть таблицей BGP (по аналогии с таблицей маршрутизации).
Он хранит все известные маршруты BGP с их атрибутами, сравнивает различные маршруты BGP и выбирает лучшие.
Назовем вторую часть обвязкой.
Привязка относится к многочисленным настройкам, которые влияют на то, какие маршруты попадают в таблицу BGP, какие маршруты объявляются соседям, как изменяются атрибуты маршрутов BGP и т. д. Те.
это различные списки распространения, списки префиксов, карты маршрутов, перераспределения и т. д. Таблица BGP Таблица BGP по конструкции очень похожа на таблицу маршрутизации Zebra. Аналогично, каждый префикс соответствует нескольким различным маршрутам, полученным из разных источников.
Только вместо административного расстояния и метрики используются различные атрибуты BGP, как показано на рисунке.
Здесь показаны только те атрибуты, которые влияют на выбор лучшего маршрута.
Например, атрибут сообщества напрямую не влияет на выбор лучшего маршрута и не показан на рисунке.
Каждый маршрут также хранит указатель на соседа BGP (BGP Peer), от которого был получен маршрут, что позволяет использовать соответствующие данные о соседе, а именно: тип соседа (IBGP или EBGP), его router-id и Айпи адрес.
При получении или удалении очередного маршрута запускается процедура, которая с помощью последовательного попарного сравнения маршрутов выбирает лучший для данного префикса.
Алгоритм сравнения двух маршрутов BGP
Из двух маршрутов лучшим считается тот (критерии указаны в порядке убывания приоритета): 1. Большее значение веса.2. Более высокое значение локального предпочтения.
3. Маршрут создается локально (с помощью команды network, redistribute илиагрегат-адреса).
4. Более короткий AS-PATH. 5. Меньшее значение Origin (IGP < EGP < INCOMPLETE) 6. Уменьшите значение MED. 7. Тип соседа, от которого получен маршрут (eBGP лучше, чем iBGP) 8. Понизьте метрику IGP до следующего перехода, указанного в маршруте.
9. Если оба маршрута являются eBGP, то предпочтительным является ранее выбранный как лучший (т. е.
более старый) маршрут. 10. Меньший Router-ID соседа.
11. Сокращенный список кластеров.
12. Меньший IP-адрес соседа.
В приведенном выше примере маршрут, отмеченный зеленым, является лучшим, поскольку он имеет наивысшее локальное предпочтение.
Если какие-либо маршруты имеют те же первые 8 точек, что и лучший маршрут, то они (при установке максимального пути больше 1) запоминаются и затем могут быть обработаны и переданы в zebra как многопутевой маршрут. Так же, как и в зебре, все префиксы, используемые в таблице BGP, организованы в виде дерева префиксов, и для быстрого поиска нужного префикса используется тот же алгоритм.
Обуздать Привязка вокруг таблицы BGP показана на рисунке.
Маршруты BGP могут исходить от соседей BGP или создаваться локально.
Прежде чем они попадут в таблицу BGP, они проходят ряд проверок, и их атрибуты можно фильтровать или изменять.
После выбора наилучшего маршрута этот маршрут рассылается соседям и попадает в таблицу маршрутизации зебры.
Получение маршрута BGP от соседа
Прежде чем маршруты попадут в таблицу BGP, они проходят несколько этапов, на которых их можно фильтровать или изменять.Путь маршрута от получения его от соседа до попадания в таблицу BGP показан на рисунке.
Команды, включающие соответствующие функции, выделены жирным шрифтом.
Прежде всего, при получении пакета происходит его парсинг, т.е.
содержимое пакета анализируется, проверяется на корректность и из данных, содержащихся в пакете, формируется внутренняя структура, представляющая маршрут BGP. Далее проверяется петля aspath, т.е.
проверка того, что AS-PATH не содержит номера автономной системы, к которой принадлежит маршрутизатор.
Эта проверка является ключом к предотвращению петель маршрутизации в BGP. Далее выполняются различные механизмы фильтрации маршрутов, если они настроены для соседа BGP, от которого был получен пакет. Список распределения фильтрует маршрут на основе IP-адреса префикса, фильтры списка префиксов основаны на IP-адресе префикса и его длине, фильтры списка фильтров основаны на содержимом AS-PATH маршрута BGP. Если маршрут успешно прошел все этапы фильтрации, то к нему применяется входящая карта маршрутов.
Здесь вы можете достаточно гибко изменять атрибуты полученного BGP-маршрута.
В зависимости от префикса и различных атрибутов маршрута BGP, таких как AS-PATH, сообщество, MED, следующий переход, происхождение, IP-адрес соседа BGP, вы можете изменить вес, AS-PATH, сообщество, следующий переход, местные предпочтения, MED, происхождение или также отфильтровать маршрут. Теперь наш маршрут почти готов к добавлению в таблицу BGP, и последний шаг — запросить у zebra достоверность следующего перехода и метрики перед ним.
Создание локального маршрута BGP
Маршрут BGP также можно создать локально с помощью команд network или redistribute. На рисунке показаны схемы добавления таких маршрутов.
Добавить маршрут с помощью команды network довольно просто.
В отличие от Cisco, Quagga не проверяет наличие заданного маршрута в таблице маршрутизации зебры.
Поэтому этот маршрут заполняется значениями по умолчанию, для изменения его атрибутов используется карта маршрутов, а маршрут добавляется в таблицу BGP. Когда вы вводите команду redistribute, демон bgpd просит демон zebra подписать (пометить) ее для добавления или удаления маршрутов определенного типа (например, OSPF) в таблице маршрутизации.
Когда в таблицу маршрутизации добавляется новый маршрут, zebra последовательно проверяет, какие демоны подписаны на маршруты этого типа, и отправляет этот маршрут подписанным демонам.
После получения нового маршрута от zebra демон bgpd меняет MED, применяет карту маршрутов и добавляет ее в таблицу BGP.
Отправка нового маршрута соседям BGP
После выбора нового лучшего маршрута BGP он отправляется соседям BGP. В этом случае последовательно просматриваются все соседи BGP и проверяется, нужно ли этому соседу отправлять маршрут. Эта процедура, выполняемая для каждого соседа BGP, показана на рисунке.
Первым делом нужно проверить, что получатель маршрута не является соседом, от которого был получен маршрут.
Далее проверяется общность маршрута.
Если в сообществе указано значение no-advertise, то маршрут не рекламируется.
Кроме того, маршрут не объявляется, если типом назначения является eBGP и сообщество содержит значение no-export. Затем происходит фильтрация с использованием исходящего списка распространения, списка префиксов и списка фильтров точно так же, как это было сделано для входящих маршрутов BGP. Он проверяет, что маршрут, полученный от соседа iBGP, не должен передаваться другому соседу iBGP (при условии, что отражатель маршрутов не используется).
Для маршрутов, у которых нет локальных предпочтений, локальные предпочтения устанавливаются по умолчанию.
Если у соседа установлена настройка next-hop-self 1.1.1.1 или соседом является eBGP, то next-hop заменяется собственным IP-адресом.
Используется исходящая карта маршрутов, которая позволяет на последнем этапе изменить атрибуты рекламируемого маршрута или отфильтровать его.
После успешного выполнения всех предыдущих шагов на основе маршрута BGP генерируется пакет обновления BGP, который отправляется соседу.
Отправка нового маршрута в zebra
Помимо отправки нового маршрута BGP своим соседям, маршрутизатор также отправляет этот маршрут в Zebra. Эта процедура показана на рисунке.
Перед отправкой маршрута в zebra для него задается Административное расстояние в зависимости от типа маршрута (iBGP или eBGP).
Из BGP-маршрута берутся все необходимые поля: тип маршрута (BGP), next-hop (или несколько next-hop, если используется многопутевой) и метрика, после чего маршрут отправляется в zebra и начинает конкурировать с маршрутами.
от других протоколов маршрутизации.
Заключение Конечно, в этой статье описаны не все возможности BGP в Quagga. Я не рассматривал функциональность маршрутного отражателя, конфедераций, IPv6 и т. д. Однако с учетом этой функциональности приведенная выше архитектура демона bgpd остается во многом такой же.
Ниже приведено краткое описание реализации некоторых дополнительных возможностей демона bgpd. Для использования IPv6 создается отдельная таблица BGP, в которой вместо префиксов IPv4 используются префиксы IPv6. Вся остальная логика таблицы BGP для IPv6 и ее привязка остается более или менее похожей на описанную выше логику работы для IPv4. При использовании Route-Reflector немного меняется логика проверки того, какие соседи должны отправлять BGP-маршруты, а при получении маршрута появляются дополнительные проверки для устранения петель (проверка атрибутов Originator ID и Cluster List).
Небольшие изменения в работе алгоритма выбора наилучшего маршрута в таблице BGP (так сказать, его тонкая настройка) можно внести с помощью следующих глобальных настроек BGP:
- bgp bestpath as-path ignore — пропускает шаг 4 (сравнение длин AS-PATH)
- bgp bestpath Compare-Routerid – пропускает шаг 9 (выбор более старого маршрута)
- bgp bestpath med Missing-as-worst — если у маршрута нет MED, то этот параметр считает, что на маршруте настроен максимально возможный MED. Без этой настройки отсутствующий MED считается равным 0.
- bgp Always-Compare-med — позволяет сравнивать MED маршрутов, полученных от разных AS. Без этой настройки шаг 6 для маршрутов, полученных от разных AS, пропускается.
- bgp deterministic-med – меняет порядок сравнения маршрутов.
Вместо последовательного сравнения маршрутов между собой сначала сравниваются маршруты, полученные от одной AS. Подробнее об этой настройке можно прочитать Здесь .
-
Должны Ли Айтишники Служить В Армии?
19 Oct, 24 -
Geinimi: Сложный Троян Для Android
19 Oct, 24 -
Главное – Хвост! Или Отказ В Регистрации 2
19 Oct, 24
