Готовимся к CCIE Enterprise -Advanced BGP

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

Использование BGP компанией не ограничивается подключением к Интернету. Если компания использует MPLS L3VPN от Интернет провайдера, вероятно, она использует BGP для обмена сетями LAN с провайдером. Маршруты обычно редистрибьютятся между BGP и другими протоколами маршрутизации. BGP используется на границе сети (Интернет или WAN) и имеет резервные подключения для обеспечения надежности сети. BGP обеспечивает advanced path selection. Эта глава посвящена поиску и устранению неисправностей в пограничных архитектурах BGP.</p>

BGP Multihoming

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

Resiliency (отказоустойчивость) in Service Providers

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

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

На рисунке ниже показаны четыре распространенных multihoming сценария:

• Scenario 1: R1 подключается к R3 с тем же Интернет провайдером. Этот дизайн отследит сбой линка; однако сбой на маршрутизаторе или в сети SP1 приводит к сбою сети.
• Scenario 2: R1 подключается к R3 и R4 с одним и тем же Интернет провайдером. Этот дизайн отследит сбой линка; однако сбой на маршрутизаторе R1 или в сети SP1 приводит к сбою сети.
• Scenario 3: R1 подключается к R3 и R4 с разными Интернет провайдерами. Эта конструкция отследит сбои линков и сбои в сети любого SP и сможет оптимизировать маршрутизацию трафика. Однако сбой на R1 приводит к сбою сети.
• Scenario 4: R1 и R2 образуют сессию iBGP друг с другом. R3 подключается к SP1, а R4 подключается к SP2. Эта конструкция отследит сбои каналов и сбои в сети любого SP и сможет оптимизировать маршрутизацию трафика.

Internet Transit Routing

Если предприятие использует BGP для подключения более чем к одному Интернет провайдеру, оно рискует превратить свою автономную систему (AS) в транзитную AS. На рисунке ниже AS 500 подключается к двум различным Интернет провайдерам (SP3 и SP4) для обеспечения отказоустойчивости.

Проблемы могут возникнуть, если R1 и R2 используют политику маршрутизации BGP по умолчанию. Пользователь, который подключается к SP3 (AS 300), направляется через корпоративную сеть (AS 500) к серверу, который подключен к SP4 (AS 400). SP3 получает префикс 100.64.1.0/24 от AS 100 и AS 500. SP3 выбирает путь через AS 500, потому что AS_Path намного короче, чем проход через сети SP1 и SP2.

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

Транзитной маршрутизации можно избежать, применив outbound BGP route policies, которые позволяют анонсировать только локальные BGP маршруты другим автономным системам. Это обсуждается далее в этой главе, в разделе «Фильтрация и управление маршрутами BGP».

Branch Transit Routing

Правильный дизайн сети должен учитывать шаблоны трафика, чтобы предотвратить неоптимальную маршрутизацию или петли маршрутизации. На рисунке ниже показан multihomed design с использованием нескольких транспортов для всех сайтов. Все маршрутизаторы настроены так, что они предпочитают транспорт MPLS SP2 над транспортом MPLS SP1 (активный / пассивный). Все маршрутизаторы связываются и объявляют все маршруты через eBGP маршрутизаторам SP. Маршрутизаторы не фильтруют ни один из префиксов, и все маршрутизаторы устанавливают local preference для MPLS SP2 на более высокое значение для маршрутизации трафика через него.

Когда сеть работает как положено, трафик между сайтами использует предпочтительную сеть SP (MPLS SP2) в обоих направлениях. Это упрощает устранение неполадок, когда поток трафика симметричен (один и тот же путь в обоих направлениях), в отличие от асимметричной пересылки (разные пути для каждого направления), поскольку полный путь должен быть обнаружен в обоих направлениях. Путь считается deterministic (детерминированным), если поток между сайтами предопределен и предсказуем.

Во время сбоя канала в сети SP существует вероятность подключения branch маршрутизатора к другому branch маршрутизатору через третий branch маршрутизатор. На рисунке ниже показан сценарий отказа, где R41, становится узлом, обеспечивающим транзитное соединение между сайтом 3 и сайтом 5.

Незапланированное транзитное соединение создает следующие проблемы:

• Сети транзитного маршрутизатора могут стать перенасыщенными, потому что они рассчитаны только на трафик этого сайта, а не на трафик, проходящий через них.
• Шаблоны маршрутизации могут стать непредсказуемыми и nondeterministic (недетерминированными). В этом сценарии трафик от R31 может проходить через R41, но обратный трафик может проходить и по другому пути.

Multihomed среды должны быть настроены таким образом, чтобы маршрутизаторы филиалов не могли действовать как транзитные маршрутизаторы. В большинстве схем транзитная маршрутизация трафика из другого branch нежелательна, так как его WAN пропускная способность может оказаться недостаточной. Маршрутизации транзита можно избежать, настроив outbound route filtering на каждом сайте филиала. По сути, сайты филиалов не анонсируют то, что они узнают из WAN, а рекламируют только сети, которые выходят с LAN. Если требуется режим транзита, то он ограничивается центрами обработки данных или другими определенными местами, со следующими характеристиками:

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

NOTE Маршрутизация транзита в ЦОД или других запланированных местах является нормой для корпоративных проектов, поскольку они учитывают пропускную способность. Обычно это делается, когда часть филиалов доступна только с одним SP, а другие филиалы соединяются с другим SP.

Conditional Matching (Условное сопоставление)

В этом разделе рассматриваются некоторые из распространенных методов, используемых для условного сопоставления маршрута - с использованием access control lists(ACL), prefix lists, регулярных выражений (regex) и AS path ACLs.

Access Control Lists

Первоначально access control lists (ACL) предназначались для фильтрации пакетов, поступающих на сетевой интерфейс или исходящих от него, аналогично функциям базового межсетевого экрана. Сегодня ACL обеспечивают packet classification для различных функций, таких как quality of service (QoS), или для идентификации сетей в протоколах маршрутизации.

ACL состоят из записей (access control entries (ACEs)), которые идентифицируют действие, которое необходимо предпринять (разрешить или запретить), и соответствующую классификацию пакетов. Классификация пакетов начинается с вершины (самая низкая последовательность) и продолжается вниз (более высокая последовательность) до тех пор, пока не будет идентифицирован соответствующий шаблон. Как только совпадение найдено, предпринимается соответствующее действие (разрешить или запрещать), и обработка останавливается. В конце каждого ACL находится неявный ACE deny, который отклоняет все пакеты, которые ранее не совпадали в ACL.

NOTE Размещение ACE в ACL важно, и из-за того, что если ACE не сработает, то могут возникнуть непредвиденные последствия.

ACL подразделяются на две категории:

• Standard ACLs: Определение пакетов осуществляется исключительно на основе source network.
• Extended ACLs: Определение пакетов осуществляется на основе source, destination, protocol, port или комбинации других атрибутов пакета. Эта книга посвящена маршрутизации и ограничивается полями ACL source, destination и protocol.

Стандартные ACL используют номера 1–99, 1300–1999 или именованные ACL. Расширенные ACL используют номера 100–199, 2000–2699 или именованные ACL. Обычно имена ACL имеют отношение к функциям ACL, могут использоваться со стандартными или расширенными ACL и являются предпочтительными.

Standard ACLs.

Ниже приведен процесс создания стандартного ACL:

• Step 1. Создаете ACL с помощью команды ip access-list standard {acl-number | acl-name} . Это переведет CLI в режим конфигурации ACL.
• Step 2. Сконфигурируете конкретную запись ACE с помощью команды [sequence] {permit | deny } source source-wildcard. Вместо использования source source-wildcard, можно использовать ключевое слово any, оно заменяет 0.0.0.0 0.0.0.0, а использование ключевого слова host относится к IP-адресу/32, поэтому source-wildcard можно опустить.

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

Extended ACLs

Ниже приведен процесс создания расширенного ACL:

• Step 1. Создаете ACL с помощью команды ip access-list extended {acl-number | acl-name} . Это переведет CLI в режим конфигурации ACL.
• Step 2. Сконфигурируете конкретную запись ACE с помощью команды [sequence] {permit | deny } protocol source source-wildcard destination destination-wildcard. Правила выбора сетевого префикса в расширенном ACL зависит от того, является ли протокол IGP (EIGRP, OSPF или IS-IS) или BGP.

IGP Network Selection

Когда ACL используются для выбора сети IGP, поля source в ACL используются для идентификации сети, а поля destination определяют наименьшую длину префикса, разрешенную в сетевом диапазоне. В таблице ниже представлены образцы записей ACL из режима конфигурации ACL и указаны сети, которые будут соответствовать расширенному ACL. Обратите внимание, что минимальное отличие в destination wildcard для 172.16.0.0 влияет на диапазоны сети, которые разрешены во второй и третьей строках таблицы.

BGP Network Selection

Extended ACLs при сопоставлении маршрутов BGP реагируют иначе, чем при сопоставлении маршрутов IGP. Поля source соответствуют сетевой части маршрута, а поля destination совпадают с маской сети, как показано на рисунке ниже. До появления prefix lists расширенные ACL были единственным критерием соответствия, используемым в BGP.

Таблица ниже демонстрирует концепцию использования wildcard для сети и маски подсети.

Prefix Matching

Prefix lists предоставляет другой метод идентификации сетей в протоколах маршрутизации. Prefix list идентифицирует конкретный IP-адрес, сеть или диапазон сетей и позволяет выбирать несколько сетей с различной длиной префикса с помощью prefix match specification. Prefix match specification - это отбор с помощью префикс соответствий, а если еще проще , то целевая сеть (или набор сетей). Многие сетевые инженеры предпочитают этот метод отбора сети.

Prefix match specification состоит из двух частей: high-order bit pattern (старший бит шаблона) и high-order bit count (счетчик старших битов), который определяет high-order bits в bit pattern, которые должны быть сопоставлены. Обычно high-order bit pattern рассматривается как адрес или сеть, а high-order bit count - как длина или длина маски. (Рассматривайте картинку ниже - станет понятней)

На рисунке ниже prefix match specification имеет high-order bit pattern 192.168.0.0, а high-order bit count - 16. High-order bit pattern был преобразован в двоичный формат, чтобы продемонстрировать, где находится high-order bit count. Поскольку дополнительные параметры совпадения длины не используются, high-order bit count является точным совпадением.

На этом этапе логика prefix match specification выглядит идентично функциональности access list. Истинная мощность и гибкость проявляются в использовании параметров matching length для идентификации нескольких сетей с определенной длиной префикса с помощью одного оператора. Matching length параметры:

• le: Меньше или равно, <=
• ge: Больше или равно, >=

Рисунок ниже демонстрирует prefix match specification с high-order bit pattern 10.168.0.0 и high-order bit count 13; matching length префикса должна быть больше или равна 24.

Префикс 10.168.0.0/13 не соответствует параметру matching length поскольку длина префикса меньше минимального 24 бита, тогда как префикс 10.168.0.0/24 соответствует параметру matching length. Префикс 10.173.1.0/28 подходит, потому что первые 13 битов соответствуют high-order bit pattern, а длина префикса находится в пределах matching length параметра. Префикс 10.104.0.0/24 не подходит, потому что high-order bit pattern не соответствует high-order bit count.

Рисунок ниже демонстрирует prefix match specification с high-order bit pattern 10.0.0.0, high-order bit count 8, и matching length между 22 и 26.

Префикс 10.0.0.0/8 не соответствует, поскольку длина префикса слишком мала. Сеть 10.0.0.0/24 соответствует требованиям, поскольку bit pattern совпадает, а длина префикса попадает в диапазон от 22 до 26. Префикс 10.0.0.0/30 не соответствует, потому что bit pattern слишком длинный. Любой префикс, который начинается с 10 в первом октете и имеет prefix length от 22 до 26, будет соответствовать.

Prefix Lists

Prefix lists могут содержать несколько записей prefix matching specification, которые содержат permit or deny action. Prefix lists обрабатываются в последовательном порядке сверху вниз, и первый префикс сопоставляет процессы с соответствующим permit or deny action.

Prefix lists настраиваются с помощью команды глобальной конфигурации ip prefix-list prefix-list-name [seq] {permit | deny} high-order-bit-pattern/high-order-bit-count [ge ge-value] [le le-value]

Если порядковый номер не указан, то он автоматически увеличивается на 5 в зависимости от максимального порядкового номера. Первая запись - 5. Порядковый номер позволяет удалить конкретную запись. Поскольку prefix lists не могут быть переупорядочены, рекомендуется оставить достаточно места для вставки порядковых номеров позднее.

IOS and IOS XE требуют, чтобы ge-значение было больше, чем high-order bit count, и чтобы le-значение было больше или равно ge-значению:

high-order bit count < ge-value <= le-value

В примере ниже представлен пример prefix list с именем RFC1918 для всех сетей в диапазоне адресов RFC 1918.

Обратите внимание, что запись с порядковым номером 5 разрешает все префиксы /32 в bit pattern 192.168.0.0/13, а запись с порядковым номером 10 запрещает все префиксы /32 в любом bit pattern, а записи с порядковыми номерами 15, 20 и 25 разрешают маршруты в соответствующих диапазонах сети. Порядок следования важен для первых двух записей, чтобы гарантировать, что в сети 192.168.0.0 в prefix list существуют только префиксы /32.

IPv6 Prefix Lists

Логика сопоставления префиксов для IPv6 сетей работает точно так же, как и для сетей IPv4. Самое важное, что нужно помнить, - это то, что при определении диапазонов сети IPv6 записываются в шестнадцатеричном, а не в двоичном формате. Однако в конечном итоге все работает на двоичном уровне.

IPv6 prefix lists настраиваются с помощью команды глобальной конфигурации ipv6 prefix-list prefix-list-name [seq sequence-number] {permit | deny} high-order-bit-pattern/highorder-bit-count [ge ge-value] [le le-value].

В примере ниже приведен пример prefix list PRIVATE-IPV6 для всех сетей пространства IPv6, указанных в документации.

Regular Expressions (regex)

Бывают случаи, когда условное сопоставление сетевых префиксов может быть слишком сложным, и нужно идентифицировать все маршруты из конкретной организации. В таком случае path selection может быть выполнен с использованием BGP AS_Path.

Regular expressions (regex) используются для анализа большого количества доступных ASN (4 294 967 295). Regular expressions основаны на модификаторах запроса, используемых для выбора подходящего содержимого. Таблица BGP может быть проанализирована с помощью регулярного выражения с помощью команды show bgp afi safi regexp regex-pattern.

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

Изучение регулярных выражений может занять время, но наиболее часто используемые в BGP модификаторы: ^, $ и _. В таблице ниже показаны некоторые общие регулярные выражения BGP.

NOTE Практический опыт полезен при изучении таких технологий, как регулярное выражение. Существуют общедоступные сервера, называемые looking glasses , которые позволяют пользователям входить в систему и просматривать таблицы BGP. Большинство этих устройств являются маршрутизаторами Cisco, но есть и другие вендоры. Эти сервера позволяют сетевым инженерам видеть, объявляют ли они свои маршруты в Интернет, как они планировали, и предоставляют отличный способ опробовать регулярные выражения в таблице BGP в Интернете. Мы предлагаем использовать http://www.bgp4.as.

Route Maps

Route maps предоставляют множество различных функций для разных протоколов маршрутизации. На простейшем уровне route maps могут фильтровать сети так же, как ACL. Они также могут предоставляют дополнительные возможности за счет добавления или изменения сетевых атрибутов. Чтобы route map могла повлиять на протокол маршрутизации, протокол маршрутизации должен ссылаться на эту route map. Route maps критически важны для BGP, потому что они являются основным компонентом в подготовке уникальной политики маршрутизации для каждого соседа.

Route map состоит из четырех компонентов:

1. Sequence number(порядковый номер): Определяет порядок обработки route map.
2. Conditional matching criteria(Критерии условного соответствия): Определяет характеристики префикса (сеть, BGP path attribute, next hop и т. д.) с определенной последовательностью.
3. Processing action(Процесс обработки): разрешает или запрещает префикс.
4. Optional action(Необязательное действие): Позволяет выполнять манипуляции в зависимости от того, как route map ссылается на маршрутизатор. Действия могут включать изменение, добавление или удаление характеристик маршрута.

Route map использует синтаксис команды route-map route-map-name [permit | deny] [sequence-number]. К операторам route map применяются следующие правила:

• Если processing action не предусмотрено, то используется значение permit по умолчанию.
• Если порядковый номер не указан, порядковый номер автоматически увеличивается на 10.
• Если соответствующий оператор не включен, подразумевается, что все префиксы связаны с оператором.
• Обработка в route map останавливается после того, как все дополнительные действия будут выполнены (если настроены) после соответствия критерию условного соответствия.

В примере ниже представлен пример route map, демонстрирующий четыре компонента route map, описанных ранее. Критерий условного соответствия основан на диапазонах сети, указанных в ACL. К этому примеру были добавлены комментарии, чтобы объяснить поведение route map в каждой строке.

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

Conditional Matching(Условное соответствие)

Теперь, когда были объяснены компоненты и порядок обработки route map, в этом разделе подробно рассказывается, как можно сопоставить маршрут. Таблица ниже предоставляет синтаксис команд для наиболее распространенных методов conditionally matching префиксов и описывает их использование. Как видите, есть несколько вариантов.

Multiple Conditional Match Conditions (Условия множественного условного совпадения)

Если есть несколько переменных (ACLs, prefix lists, tags, и т. д.), настроенные для определенной последовательности в route map, и только одна переменная должна соответствовать, чтобы префикс был квалифицирован. Boolean логика использует для этой конфигурации оператор OR.

В примере ниже строка 10 требует, чтобы префикс соответствовал ACL-ONE или ACL-TWO. Обратите внимание, что строка 20 не имеет оператора соответствия, поэтому все префиксы, не переданные в строке 10, будут квалифицированы и отклонены.

NOTE В предыдущем примере строка 20 является избыточной из-за неявного отказа для любых префиксов, которые не совпадают в строке 10.

Если в строке route map настроено несколько параметров сопоставления, и они оба должны быть соблюдены, то в конфигурации используется Boolean оператор AND.

В примере ниже строка 10 требует чтобы префикс соответствовал ACL-ONE и чтобы metric имел значение от между 500 и 600. Если префикс не соответствует обоим параметрам соответствия, префикс не соответствует требованиям строки 10 и отклоняется, поскольку нет еще одной строки с разрешающим действием.

Complex Matching

Некоторые сетевые инженеры считают route maps слишком сложными, если в критериях условного соответствия используются ACL, AS path ACL, или prefix list содержащие оператор deny. В примере ниже показана конфигурация, в которой ACL использует оператор deny для сетевого диапазона 172.16.1.0/24.

При чтении таких конфигураций следует сначала следовать порядку следования, а затем критериям условного соответствия, и только после того, как произойдет совпадение, следует использовать действие обработки и дополнительное действие. Соответствие оператору deny в критериях условного соответствия исключает маршрут из использования в route map.

Префикс 172.16.1.0/24 запрещен ACL-ONE, что означает, что в строках 10 и 20 он не попадет под совпадение; следовательно, действие обработки (разрешить или запретить) не требуется. Строка 30 не содержит предложения соответствия, поэтому любые оставшиеся маршруты разрешены. Префикс 172.16.1.0/24 в строке 30 получит метрику 20.

NOTE Route maps обрабатываются с использованием определенного порядка: sequence, conditional match criteria, processing action, и optional action. Любые операторы deny в компоненте match изолированы от sequence action в route map.

Optional Actions

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

The continue Keyword

Порядок действия route map по умолчанию - обрабатывает sequences по порядку и при первом совпадении выполняет действие обработки, выполняет любое дополнительное действие (если возможно) и останавливает обработку. Это предотвращает обработку нескольких sequences в route map.

Добавление ключевого слова continue к route map позволяет route map продолжать обработку других sequences. В примере ниже представлена простейшая конфигурация. Сетевой префикс 192.168.1.1 соответствует строкам 10, 20 и 30. Поскольку ключевое слово continue было добавлено к строке 10, последовательность 20 обрабатывает, а последовательность 30 - нет, поскольку в строке 20 отсутствует команда continue. Префикс 192.168.1.1 permitted и он модифицирован так, что metric равен 20 с next-hop адресом 10.12.1.1.

NOTE Команда continue обычно не используется, поскольку она усложняет устранение неполадок с route maps.

BGP Route Filtering and Manipulation

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

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

IOS XE предоставляет четыре метода фильтрации входящих и исходящих маршрутов для определенного BGP пира. Эти методы можно использовать по отдельности или одновременно с другими методами:

1. Distribute list: Distribute list включает фильтрацию сетевых префиксов на основе стандартного или расширенного ACL. Неявный отказ связан с любым недопустимым префиксом.
2. Prefix list: Список prefix-matching specifications разрешает или запрещает использование сетевых префиксов в нисходящем порядке, аналогично ACL. Неявный отказ связан с любым недопустимым префиксом.
3. AS path ACL/filtering: Список команд регулярных выражений позволяет разрешить или запретить сетевой префикс на основе текущих значений AS path. Неявный отказ связан с любым недопустимым префиксом.
4. Route maps: Route maps предоставляют метод условного сопоставления различных атрибутов префикса и выполнения различных действий. Действия могут быть простым разрешением или отказом; или может включать изменение атрибутов пути BGP. Неявный отказ связан с любым недопустимым префиксом.

NOTE BGP neighbor не может использовать distribute list и prefix list одновременно для получения или объявления маршрутов.

В следующих разделах более подробно объясняется каждый из этих методов фильтрации. Представьте себе простой сценарий с R1 (AS 65100), который имеет один eBGP пиринг с R2 (AS 65200), который затем может иметь пиринги с другими автономными системами (например, AS 65300). На следующей картинке рассмотрим таблицу BGP R1.

Distribute List Filtering

Distribute lists позволяют фильтровать префиксы сети для каждого соседа, используя стандартные или расширенные списки ACL. Для настройки distribute list необходимо использовать команду настройки BGP address-family neighbor ip-address distribute-list {acl-number | acl-name} {in|out}. Помните, что extended ACL для BGP используют source поля для сопоставления сетевой части и destination поля для сопоставления с сетевой маской.

В примере ниже представлена конфигурация BGP маршрутизатора R1, демонстрирующая фильтрацию с помощью distribute lists. Конфигурация использует расширенный ACL с именем ACL-ALLOW, который содержит две записи. Первая запись разрешает любую сеть, которая начинается в диапазоне от 192.168.0.0 до 192.168.255.255, с любой длиной сети. Во вторая записи разрешены сети, содержащие шаблон 100.64.x.0 с длиной префикса /25. Затем distribute list привязывается к BGP сессии с R2.

В примере ниже показана таблица маршрутизации R1. Два локальных маршрута вводятся в таблицу BGP R1 (10.12.1.0/24 и 192.168.1.1/32). Две loopback сети из R2 (AS 65200) и R3 (AS 65300) разрешены, потому что они находятся в пределах первой записи ACL-ALLOW и принимаются две сети в шаблоне 100.64.x.0 (100.64.2.0/25 и 100.64 .3.0 / 25). Сеть 100.64.2.192/26 отклоняется, поскольку длина префикса не соответствует второй записи ACL-ALLOW. Сравниваем с пример 12-8. Там показаны маршруты до применения distribute list BGP.

Prefix List Filtering

Prefix lists позволяют фильтровать префиксы сети для каждого BGP соседа, используя prefix list. Настройка prefix list включает использование команды BGP address family конфигурации neighbor ip-address prefix-list prefix-list-name {in|out}.

Чтобы продемонстрировать использование prefix list, мы можем использовать исходную таблицу BGP из примера 12-8 и отфильтровать ее, разрешив только маршруты в пространстве RFC 1918. Тот же список префиксов из примера 12-1 используется и будет применяться к пирингу R1 с R2 (AS 65200). В следующем примере показана конфигурация prefix list и использование его в пиринге с R2.

Теперь, когда prefix list применен, рассмотрим таблицу BGP на R1 в примере ниже. Обратите внимание, что сети 100.64.2.0/25, 100.64.2.192/26 и 100.64.3.0/25 были отфильтрованы, поскольку они не подпадали под критерии соответствия prefix list. Сравниваем с примером 12-8, где показаны маршруты до применения фильтров.

AS Path ACL Filtering

Отбор маршрутов от BGP соседа с использованием AS path требует сконфигурированного AS path access control list (AS path ACL). Регулярные выражения, представленные ранее в этой главе, являются компонентом фильтрации AS_Path.

В примере ниже показаны маршруты, которые R2 (AS 65200) анонсирует к R1 (AS 65100).

R2 анонсирует маршруты к R1, полученные от R3 (AS 65300). По сути, R2 обеспечивает транзитное соединение между автономными системами. Если бы это было подключение к Интернету, а R2 был бы предприятием, он не захотел бы анонсировать маршруты, полученные от других AS. Рекомендуется использовать AS path access list для ограничения анонсирования только маршрутов AS 65200.

Обработка выполняется в последовательном порядке сверху вниз, и первое подходящее соответствие обрабатывает сконфигурированное действие permit или deny. Неявный отказ существует в конце AS path ACL. IOS поддерживает до 500 AS path ACLs и использует команду ip as-path access-list acl-number {deny | permit} regex-query для создания AS path ACL. Затем ACL применяется командой neighbor ip-address filter-list acl-number {in|out} .

В примере ниже показана конфигурация на R2 с использованием AS path ACL для ограничения трафика. Разрешен только locally originated трафик. Использовался шаблона регулярного выражения ^ $ (см. Таблицу 12-5). Для обеспечения полноты AS path ACL применяется ко всем соседствам eBGP.

Теперь, когда AS path ACL был применен, анонсированные маршруты можно проверить. В примере ниже показаны маршруты, анонсированные маршрутизатору R1 от R2. Обратите внимание, что все маршруты не имеют AS path, подтверждая, что анонсируются только локально исходящие маршруты. Пример 12-13 может использоваться для сравнения, там показаны маршруты до применения BGP AS path ACL.

Route Maps

Как объяснялось ранее, route maps предоставляют дополнительные функции по сравнению с просто фильтрацией. Route maps также предоставляют метод управления BGP path attributes. Route maps применяются к BGP neighbor маршрутам которые анонсируются или принимаются. Для каждого направления можно использовать разные route map. Route map связана с соседом BGP с помощью команды neighbor ip-address route-map route-map-name {in|out} под конкретным address family.

В примере ниже показана таблица маршрутизации BGP маршрутизатора R1, которая используется здесь для демонстрации возможностей route map.

Route maps также допускают несколько этапов обработки. Чтобы продемонстрировать эту концепцию, наша route map будет состоять из четырех шагов:

1. Запретите любые маршруты, которые находятся в сети 192.168.0.0/16, используя prefix list.
2. Сопоставьте все маршруты, исходящие от AS 65200, которые находятся в диапазоне сети 100.64.0.0/10, и установите BGP local preference в 222.
3. Сопоставьте все маршруты, исходящие от AS 65200, которые не соответствуют шагу 2, и установите BGP weight в 65200.
4. Разрешите обработку всех остальных маршрутов.

В примере ниже демонстрируется конфигурация маршрутизатора R1, в котором имеется ссылка на несколько prefix lists вместе с AS path ACL.

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

• Маршруты 192.168.2.2/32 и 192.168.3.3/32 были отброшены. Маршрут 192.168.1.1/32 - это локально созданный маршрут.
• В сетях 100.64.2.0/25 и 100.64.2.192/26 значение local preference изменено на 222, поскольку сети исходят из AS 65200 и находятся в пределах диапазона сети 100.64.0.0/10.
• Маршрутам 10.12.1.0/24 и 10.23.1.0/24 от R2 был назначен BGP attribute weight 65200.
• Все остальные маршруты получены и не изменены.

NOTE Рекомендуется использовать разные route policy для входящих и исходящих префиксов для каждого соседа BGP.

Clearing BGP Connections

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

Маршрутизаторы инициируют hard reset с помощью команды clear ip bgp ip-address [soft]. Для soft reset используйте необязательное ключевое слова soft. Все сессии BGP маршрутизатора могут быть очищены с помощью звездочки * вместо IP-адреса пира.

Когда политика BGP изменяется, таблица BGP должна быть обработана снова, чтобы соседи могли быть уведомлены соответствующим образом. Маршруты, полученные пирами BGP, необходимо обработать снова. Если сессия BGP поддерживает возможность обновления маршрута, BGP пир повторно анонсирует (обновляет) префиксы запрашивающему маршрутизатору, давая возможность inbound policy обработать с использованием измененной политики. Возможность обновления маршрута оговаривается для каждого address family при установлении сессии.

Выполнение soft reset сессий, которые поддерживают возможность route refresh (обновления маршрута), инициирует route refresh. Soft resets может быть выполнен для определенного address family с помощью команды clear bgp afi safi {ip-address|*} soft [in | out]. Изменения outbound routing policies используют необязательное ключевое слово out, а изменения inbound routing policies - необязательное ключевое слово in. Вы можете использовать * вместо указания IP-адреса пира, чтобы выполнить это действие для всех BGP пиров.

BGP Communities

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

BGP communities - это необязательный транзитивный атрибут BGP, который может передаваться от AS к AS. BGP community - это 32-битное число, которое может быть включено в маршрут. BGP community может отображаться как полное 16-битное число (0-4 294 967 295) или как два 16-битных числа (0–65535):( 0–65535), обычно называемые новым форматом.

Private BGP communities следуют определенному соглашению, в котором первые 16 бит представляют AS источника community, а вторые 16 бит представляют шаблон, определенный исходной AS. Шаблон private BGP community может варьироваться от организации к организации, не требует регистрации и может обозначать географические местоположения для одной AS или указывая метод анонсирования маршрута в другой AS. Некоторые организации публикуют свои private BGP community шаблоны на таких веб-сайтах, как http://www.onesc.net/communities/.

В 2006 году RFC 4360 расширил возможности BGP communities, предоставив расширенный формат. Extended BGP communities обеспечивают структуру для различных классов информации и обычно используются для VPN сервисов. RFC 8092 обеспечивает поддержку для communities размером более 32 бит (но это выходит за рамки этой книги).

Well-Known Communities

RFC 1997 определен набор global communities (известных как well-known communities), которые используют community range от 4 294 901 760 (0xFFFF0000) до 4 294 967 295 (0xFFFFFFFF). Все маршрутизаторы, которые могут отправлять/получать BGP communities, должны реализовывать well-known communities. Ниже приведены три общих well-known communities:

1. Internet: Это стандартизированное community для определения маршрутов, которые следует анонсировать в Интернете. В крупных сетях, которые развертывают BGP в ядре, маршрутам, анонсируемым в Интернет должно быть назначено это community. Это позволяет граничным BGP маршрутизаторам разрешать анонсирование маршрутов BGP в Интернет только с Internet community. Фильтрация не выполняется автоматически, но может выполняться с помощью outbound route map.
2. No_Advertise: Маршруты с этим community не следует анонсировать ни одному BGP пиру (iBGP или eBGP).
3. No_Export: Когда получен маршрут с этим community, он не анонсируется ни одному eBGP пиру. Маршруты с этим community можно анонсировать iBGP пирам.

Enabling BGP Community Support

Маршрутизаторы IOS и IOS XE по умолчанию не анонсируют BGP communities пирам. Communities включаются для каждого соседа с помощью BGP команды neighbor ip-address send-community [standard | extended | both] в конфигурации address family соседа. Если ключевое слово не указано, по умолчанию отправляются standard communities.

Узлы IOS XE могут отображать communities в новом, более удобном для чтения формате, с помощью команды глобальной конфигурации ip bgp-community new-format. В примере ниже сначала отображается BGP community в десятичном формате, а затем - в новом формате.

Conditionally Matching BGP Communities

Условное сопоставление BGP communities позволяет выбирать маршруты на основе BGP communities в атрибутах, чтобы в route maps могла происходить выборочная обработка. В примере ниже показана BGP таблица BGP для R1, который получил несколько маршрутов от R2 (AS 65200).

В этом примере предположим, что вы хотите сделать условный отбор по определенному community. Вся таблица BGP может быть отображена с помощью команды show bgp afi safi detail, а затем вы можете вручную выбрать маршрут с определенным community. Однако, если известно BGP community, все маршруты могут быть отображены с помощью команды show bgp afi safi community community, как показано в примере ниже.

В примере ниже показана запись явного пути для сети 10.23.1.0/24 и все BGP path attributes. Обратите внимание, что к пути добавлены два BGP communities (333: 333 и 65300: 333).

Условное сопоставление требует создания community list, который имеет структуру аналогичную ACL, может быть стандартным или расширенным, и на него можно ссылаться по номеру или имени. Стандартные community lists пронумерованы от 1 до 99 и соответствуют либо well-known communities, либо private community (as number: 16-bit-number). Расширенные community lists пронумерованы от 100 до 500 и используют шаблоны регулярных выражений.

Синтаксис конфигурации для community list: ip community-list {1-500 | standard list-name | expanded list-name} {permit | deny} community-pattern. После составления community list, на него ссылаются в route map с помощью команды match community 1-500.

Пример ниже демонстрирует создание BGP community list, соответствующего community 333: 333. BGP community list затем используется в первой строке route-map COMMUNITY-CHECK, которая запрещает любые маршруты с этим community. Вторая строка route map позволяет использовать все остальные маршруты BGP и устанавливает BGP weight равным 111. Затем route map применяется к маршрутам, анонсированным от R2 к R1.

В следующем примере показана таблица BGP после применения route- map к соседу. Сетевой префикс 10.23.1.0/24 был отброшен, а для всех других маршрутов, полученных от AS 65200, был установлен BGP weight 111.

Setting Private BGP Communities

Private BGP community устанавливается route map-ом с помощью набора команд set community bgp-community [additive]. По умолчанию при настройке community все существующие communities перезаписываются, но могут быть сохранены с помощью необязательного ключевого слова [additive].

В примере ниже показаны записи таблицы BGP для сети 10.23.1.0/24, в которой есть BGP communities 333: 333 и 65300: 333.

В примере ниже показана конфигурация, в которой BGP community настроено на сеть 10.23.1.0/24. Ключевое слово additive не используется, поэтому предыдущие значения community 333: 333 и 65300: 333 заменяются community 10:23. В сети 10.3.3.0/24 к существующим communities 3: 0, 3: 3 добавлены communities 10:10. Затем route map ассоциируется с R2 (AS 65200).

Теперь, когда route map применена и маршруты обновлены, можно исследовать path attributes, как показано в примере ниже. Как и ожидалось, предыдущие BGP communities были удалены для сети 10.23.1.0/24, но остались для сети 10.3.3.0/24.

Understanding BGP Path Selection

BGP best-path selection algorithm влияет на то, как трафик входит или покидает AS. Некоторые конфигурации маршрутизатора изменяют BGP attributes чтобы влиять на входящий трафик, исходящий трафик или входящий и исходящий трафик, в зависимости от требований дизайна сети. Многие сетевые инженеры не понимают BGP best-path selection, что часто может приводить к неоптимальной маршрутизации. В этом разделе объясняется логика, используемая маршрутизатором, который использует BGP при пересылке пакетов.

Routing Path Selection Using Longest Match (Routing Path Selection с использованием наибольшего совпадения)

Маршрутизаторы всегда выбирают путь, по которому должен идти пакет, проверяя длину сети записи. Path selected для пакета, выбирается на основе длины префикса, и предпочтительнее максимальная длина префикса. Например, /28 предпочтительнее чем /26, а /26 предпочтительнее чем /24.

Эта логика может использоваться для влияния на path selection в BGP. Предположим, что организация владеет сетевым диапазоном 100.64.0.0/16, но ей нужно анонсировать только две подсети (100.64.1.0/24 и 100.64.2.0/24). Она может анонсировать оба префикса (100.64.1.0/24 и 100.64.2.0/24) со всех своих маршрутизаторов, но как она сможет распределять нагрузку для каждой подсети, если весь трафик поступает на один маршрутизатор (например, R1)?

Организация может изменять различные BGP path attributes (PAs), которые приходят от других AS. Но SP может иметь BGP routing policy, которая игнорирует эти path attributes, что приводит к случайному получению сетевого трафика.

Более элегантный способ, гарантирующий детерминированный выбор путей за пределами организации, - анонсировать суммарный префикс (100.64.0.0/16) на обоих маршрутизаторах. Затем организация может анонсировать более длинный совпадающий префикс на маршрутизаторе, который должен получать сетевой трафик для этого префикса. На рисунке ниже показана концепция: R1 анонсирует префикс 100.64.1.0/24, R2 анонсирует префикс 100.64.2.0/24, а оба маршрутизатора анонсируют суммарный сетевой префикс 100.64.0.0/16.

Независимо от политики маршрутизации SP, более специфические префиксы анонсирует наружу только один маршрутизатор. Резервирование обеспечивается анонсированием суммарного адреса. Если R1 выходит из строя, используется анонсирование R2 100.64.0.0/16 для достижения сети 100.64.1.0/24.

NOTE Убедитесь, что суммарные сети, анонсируемые вашей организацией, находятся только в пределах вашей сети. Кроме того, провайдеры обычно не принимают маршруты IPv4 длиннее /24 (например, /25 или /26) или маршруты IPv6 длиннее /48.

BGP Best Path Overview

В BGP анонсирование маршрута содержит (NLRI) и атрибуты пути (PA). NLRI состоит из префикса сети и длины префикса, а BGP attributes, такие как AS_Path, origin и т. д. хранятся в PA. Маршрут BGP может содержать несколько путей к одной и той же сети назначения. Каждый из path’s attributes влияют на желательность маршрута, когда маршрутизатор выбирает best path. BGP маршрутизатор анонсирует соседним маршрутизаторам только best path.

Внутри BGP Loc-RIB таблицы все маршруты и их path attributes поддерживаются с рассчитанным best path. Затем best path устанавливается в RIB маршрутизатора. Если best path больше не доступен, маршрутизатор может использовать существующие пути, чтобы быстро определить новый best path. BGP пересчитывает best path для префикса по четырем возможным событиям:

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

BGP автоматически устанавливает первый полученный путь как best path. Когда для той же длины префикса сети получены дополнительные пути, новые пути сравниваются с текущим best path. Обработка продолжается до тех пор, пока не будет определен победитель best path.

BGP best-path algorithm использует следующие атрибуты в указанном порядке для best-path selection:

• Weight
• Local preference
• Local originated (network statement, redistribution, or aggregation) (происхождение маршрута (анонсирование командой network, редистрибьюция или агрегирование).
• AIGP
• Shortest AS_Path
• Origin type
• Lowest MED
• eBGP over iBGP
• Lowest IGP next hop
• If both paths are external (eBGP), prefer the first (oldest) (если оба пути внешние (eBGP), предпочтительнее первый (самый старый))
• Prefer the route that comes from the BGP peer with the lower RID (Предпочтительнее маршрут, который исходит от BGP пира с более низким RID)
• Prefer the route with the minimum cluster list length (Предпочтительнее маршрут с минимальной длиной списка кластеров)
• Prefer the path that comes from the lowest neighbor address (Предпочтительнее путь, который исходит от соседа с наименьшего адресом)

BGP routing policy может варьироваться от организации к организации в зависимости от манипуляций с PA BGP. Поскольку некоторые PA транзитивны и переносятся от одной AS к другой AS, эти изменения могут повлиять на нисходящую маршрутизацию и для других SP. Другие PA нетранзитивны и влияют только на политику маршрутизации внутри организации. Сетевые префиксы условно сопоставляются по множеству факторов, таких как длина AS_Path, определенный ASN, BGP communities или другие атрибуты.

Best-path algorithm объясняется в следующих разделах.

Weight

BGP weight - это Cisco-определяемый атрибут и первый шаг для выбора BGP best path. Weight - это 16-битное значение (от 0 до 65 535), назначаемое локально на маршрутизаторе; он не анонсируется другим маршрутизаторам. Путь с большим weight является предпочтительным. Weight может быть установлен для определенных маршрутов с помощью inbound route map или для всех маршрутов, полученных от конкретного соседа. Weight не анонсируется пирам и влияет только на исходящий трафик от маршрутизатора или AS. Поскольку это первый шаг в best-path algorithm, его следует использовать, когда другие атрибуты не смогут повлиять на best path для конкретной сети.

В примере ниже показана таблица BGP для префикса сети 172.16.1.0/24 на R2. В третьей строке выходных данных маршрутизатор указывает, что существуют два пути, и первый путь является наилучшим. Изучая выходные данные каждого пути, видим что путь, полученный через AS 65300, имеет weight 123. Путь через AS 65100 не имеет weight, его значению равно 0; следовательно, лучший путь - через AS 65300.

Local Preference

Local preference (LOCAL_PREF) - это well-known discretionary path attribute, который включен в анонсирование пути по все AS. Local preference attribute представляет собой 32-битное значение (от 0 до 4 294 967 295), которое указывает предпочтение для выхода из AS в сеть назначения. Local preference не анонсируется между eBGP peers и обычно используются для влияния на next-hop address для исходящего трафика (то есть для выхода из автономной системы). Local preference могут быть установлены для определенных маршрутов с помощью route map или для всех маршрутов, полученных от определенного соседа.

Более высокое значение предпочтительнее более низкого значения. Если граничный BGP маршрутизатор не назначает local preference при получении префикса, то ему присваивается значение local preference по умолчанию равное 100. Оно используется при вычислении best-path и включается в анонсирование для других iBGP пиров. Изменение local preference может повлиять на path selection на других iBGP пирах, не влияя на eBGP пиры, поскольку local preference не анонсируется за пределы AS.

В примере ниже показана таблица BGP для префикса сети 172.16.1.0/24 на R2. В третьей строке выходных данных маршрутизатор указывает, что существуют два пути, и первый путь является наилучшим. BGP weight не существует, поэтому используется local preference. Путь, полученный через AS 65300, является best path, поскольку он имеет local preference of 333, тогда как путь через AS 65200 имеет local preference 111.

Locally Originated via Network or Aggregate Advertisement

Третий пункт принятия решения в best-path algorithm требует определить, создавался ли маршрут локально. Предпочтение отдается в следующем порядке:

• Маршруты, которые анонсированы локально
• Сети, которые были агрегированы локально
• Маршруты, полученные BGP пирами.

Accumulated Interior Gateway Protocol

Accumulated Interior Gateway Protocol (AIGP) - это необязательный нетранзитивный атрибут, который включается в анонсы по всей AS. IGP обычно использует lowest-path metric для определения кратчайшего пути к месту назначения, но не могут поддерживать масштабируемость BGP. BGP использует AS для идентификации единого домена управления политикой маршрутизации. BGP не использует path metric из-за проблем с масштабируемостью в сочетании с тем, что каждая AS может использовать различную политику маршрутизации для вычисления метрик.

AIGP предоставляет BGP возможность поддерживать и вычислять концептуальную path metric в каждой AS в среде с множеством AS и уникальными доменами маршрутизации IGP. Возможность для BGP принимать решения о маршрутизации на основе path metric является жизнеспособным вариантом, поскольку все AS находятся под контролем одного домена с согласованными политиками маршрутизации для BGP и IGP.

На рисунке ниже AS 100, AS 200 и AS 300 находятся под управлением одного и того же Интернет провайдера. AIGP был включен в BGP сессиях между всеми маршрутизаторами, и произведена редистрибьюция IGP в BGP. AIGP metric анонсирована между AS 100, AS 200 и AS 300, что позволяет BGP использовать метрику AIGP для вычислений best-path между автономными системами.

К AIGP metrics применяются следующие правила:

• Путь с метрикой AIGP предпочтительнее пути без метрики AIGP.
• Чтобы узнать расстояние до next-hop address, если next-hop address требует рекурсивный поиск, AIGP path требует подсчета производной метрики. Это гарантирует, что cost до BGP edge роутера включен. Формула подсчета: Derived AIGP metric = (Original AIGP metric + Next-hop AIGRP metric). Если существует несколько путей AIGP и один next-hop address содержит метрику AIGP, а другой - нет, то non-AIGP path не используется. Next-hop AIGP metric добавляется рекурсивно, если выполняется несколько поисков.
• AIGP paths сравниваются на основе производной AIGP metric (с рекурсивным next hops) или фактической AIGP metric (нерекурсивный next hop). Путь с более низкой AIGP metric является предпочтительным.

Shortest AS Path

Следующим решающим фактором для BGP best-path algorithm является длина AS path. Длина пути обычно коррелирует с количеством переходов AS. Более короткий AS path предпочтительнее более длинного AS path.

Добавление ASN к AS path увеличивает его длину, тем самым делая этот путь менее желательным по сравнению с другими путями. Обычно к AS path добавляется ASN владельца сети.

В примере ниже показана таблица BGP для сетевого префикса 172.16.1.0/24 на R2. Второй маршрут, полученный через AS 65100, является наилучшим. Ни для одного из путей не установлен weight, local preference идентичны. Второй путь имеет длину AS path равную 1, а у первого пути длина AS path равна 2 (65300 и 65300).

NOTE ASN повторяются в первой записи, что указывает на то, что AS 65300 дважды добавила свое объявление BGP для управления сетевым трафиком.

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

Origin Type

Следующим фактором выбора BGP best-path является well-known mandatory BGP attribute называемый origin. По умолчанию сети, которые анонсируются с помощью команды network, устанавливаются со значением origin - IGP or i, а сети которые редистрибьютили назначается значения Incomplete для origin attribute. Порядок предпочтения origin:

1. IGP origin (most)
2. EGP origin
3. Incomplete origin (least)

В примере ниже показана таблица BGP для сетевого префикса 172.16.1.0/24 на маршрутизаторе R2. Второй путь, полученный через AS 65100, является лучшим путем, потому что он имеет origin IGP, тогда как первый путь имеет origin incomplete, что является наименее предпочтительным.

Multi-Exit Discriminator (MED)

Следующим фактором выбора BGP best-path является нетранзитивный атрибут BGP, называемый multiple-exit discriminator (MED). MED использует 32-битное значение (от 0 до 4 294 967 295), называемое метрикой. BGP автоматически устанавливает MED равным метрике пути IGP во время анонсирования сети или редистрибьюции. Если MED получен из сессии eBGP, он может быть анонсирован другим iBGP пирам, но его не следует отправлять за пределы AS, которая его получила. Цель MED - влиять на потоки трафика, входящие из другой AS. Более низкий MED предпочтительнее более высокого MED.

NOTE Чтобы MED был эффективным фактором принятия решения, выбираемые пути должны исходить из одного и того же ASN.

В рекомендациях RFC 4451 указано, что префиксу без значения MED следует отдавать приоритет и, по сути, его следует сравнивать со значением 0. Некоторые организации требуют, чтобы MED был установлен на определенное значение для всех префиксов, и объявляют, что пути без MED должны рассматриваться как наименее предпочтительные. По умолчанию, если MED отсутствует в префиксе, полученном от eBGP пира, устройства используют MED, равный 0, для вычисления best-path. Маршрутизаторы IOS анонсируют MED равным 0 iBGP пирам.

В примере ниже показана таблица BGP для сетевого префикса 172.16.1.0/24 на R2. Обратите внимание, что R2 поддерживает пиринг только с AS 65300 для MED, чтобы иметь право на процесс best-path selection. MED для первого пути равен 0, а для второго пути - 33. Первый путь предпочтительнее, так как MED ниже.

eBGP over iBGP

Следующим фактором выбора BGP best-path является то, исходит ли маршрут от iBGP, eBGP пиров или AS (суб-AS) члена конфедерации. Порядок выбора best-path:

1. eBGP peers (most desirable)
2. Confederation member AS peers
3. iBGP peers (least desirable)

NOTE Конфедерации BGP выходят за рамки экзамена CCNP и CCIE Enterprise Core ENCOR 350-401 и не обсуждаются в этой книге.

Lowest IGP Metric

Следующий шаг решения - использовать наименьшую стоимость IGP для BGP next-hop address. На рисунке ниже показана топология, в которой R2, R3, R4 и R5 находятся в AS 400. AS 400 имеет full mesh пиринги и устанавливает сессии BGP, используя интерфейсы Loopback 0. R1 анонсирует префикс сети 172.16.0.0/24 для R2 и R4.

R3 предпочитает путь от R2 по сравнению с путем iBGP от R4, потому что метрика для достижения next-hop address ниже. R5 предпочитает путь от R4 по сравнению с путем iBGP от R2, потому что метрика для достижения next-hop address ниже.

Prefer the Oldest eBGP Path

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

Недостатком этого метода является то, что он не приводит к детерминированному методу определения BGP best path с точки зрения проектирования.

Router ID

Следующим шагом для BGP best-path algorithm является выбор best path с использованием наименьшего router ID среди eBGP роутеров, которые отправляют анонсы. Если маршрут был получен route reflector-ом, то идентификатор отправителя (originator ID) заменяется router ID.

Minimum Cluster List Length

Следующим шагом в BGP best-path algorithm является выбор best path с использованием наименьшей длины cluster list. Сluster list - это нетранзитивный атрибут BGP, который добавляется (не перезаписывается) route reflector-ом с его cluster ID. Route reflectors используют cluster ID attribute как механизм предотвращения петель. Сluster ID не анонсируется между AS и является локально значимым. Проще говоря, на этом шаге определяется путь, по которому прошло наименьшее количество анонсированных переходов iBGP.

NOTE BGP route reflectors выходят за рамки экзамена CCNP и CCIE Enterprise Core ENCOR 350-401 и не обсуждаются в этой книге.

Lowest Neighbor Address

Последним шагом BGP best-path algorithm является выбор пути, который исходит от самого низкого BGP neighbor address. Этот шаг ограничен iBGP пирингом, поскольку eBGP пиры использовали oldest received path в качестве средства разрешения конфликтов.

Рисунок ниже демонстрирует концепцию выбора маршрутизатора с наименьшим neighbor address. R1 объявляет префикс сети 172.16.0.0/24 маршрутизатору R2. R1 и R2 установили две сессии BGP с использованием сетей 10.12.1.0/24 и 10.12.2.0/24. R2 выбирает объявленный путь из 10.12.1.1, поскольку это меньший IP-адрес.