BGP Additional Path (ADD-PATH)

Функция ADD-PATH описана в RFC7911 – Advertisement of Multiple Paths in BGP, который определяет новое расширение BGP, позволяющее маршрутизатору (чаще всего Route Reflector) объявлять несколько путей (маршрутов) для одного и того же префикса. Это расширение даёт возможность идентифицировать путь, используя Path Identifier, в дополнение к префиксу.

Зачем нужен Add Path?

Согласно RFC4271  A Border Gateway Protocol 4: «BGP спикер объявляет своим партнерам только те маршруты, которые он использует сам». Это означает, что маршрутизатор, который получает более одного пути для одного и того же пункта назначения, выполняет локально BGP Path Selection, выбирает лучший путь и анонсирует только этот лучший путь своим соседям. В определенных ситуациях это может привести к нежелательным результатам.

В качестве примера рассмотрим следующий сценарий. В AS 400 нет full mesh соседств между iBGP спикерами. То есть маршрутизаторы R4, R5 и R6 не имеют соседства друг с другом, а запирины только с RR.

 

BGP Additional Path (ADD-PATH)
BGP Additional Path (ADD-PATH)

1) AS 100 анонсирует маршрут для 203.0.113.0/24 на R2 и R3 через AS200 и AS300

2) Маршрут анонсируется к AS400 и принимается на R4 и R6.

3) R4 и R6 анонсируют маршрут к их Route Reflector

4) RR в свою очередь проходит процесс принятия решения BGP и выбирает маршрут через R4 как лучший маршрут. В этом примере мы предполагаем, что не меняем никаких атрибутов для маршрутов (естественно, кроме Next Hop на eBGP), до того, как R4 и R6 анонсируют маршрут к RR. Таким образом, RR выбирает маршрут через R4 на основе идентификаторов маршрутизаторов R4 и R6 (самый низкий RID).

5) Затем RR анонсирует маршрут, который он выбрал для себя в качестве лучшего, на R5.

6) В результате R5 имеет только один маршрут для отправки трафика на 203.0.113.0/24, используя R4 в качестве next hop.

7) R5 отправляет трафик в направлении 203.0.113.0/24 через R4.

Это не кажется проблемой, пока вы не поймете, что канал между R5 и R4 — 1 Гбит/с, а канал между R5 и R6 — 10 Гбит/с, и канал 1 Гбит/с в сторону R4 испытывает перегрузку, задержки возрастают, а пользователи испытывают трудности с доступом к интересующим их ресурсам.
Гипотетически вы можете переделать дизайн таким образом, что этот 1G интерфейс станет 10G. Но что если это невозможно сделать, или вы не можете сделать это достаточно быстро, или вы просто не хотите ничего переделывать?
Рассмотрим возможность использования атрибута Local Preference для решения этой проблемы как показано ниже:

BGP Additional Path (ADD-PATH)

Теперь R6 анонсирует маршрут с Local Preference 200. В результате, когда RR сравнивает два маршрута, выбирается маршрут от R6 (наибольший Local Preference). Этот маршрут затем отправляется на R5, который теперь отправляет трафик, предназначенный для 203.0.113.0/24 через R6 (вместо R4). Это не может не радовать. Но что если мы добавим еще один маршрутизатор к этой топологии?

BGP Additional Path (ADD-PATH)

Новый маршрутизатор R7 физически расположен рядом с R4, и вы можете видеть, что метрика IGP до R4 намного ниже, чем метрика до R6. Однако поскольку RR теперь выбирает R6 в качестве лучшего маршрута, R7 будет принимать только этот маршрут и будет отправлять трафик, предназначенный для 203.0.113.0/24, через R6. Получается, эта ситуация выглядит великолепно с точки зрения R5, но ужасно с точки зрения R7.

Какие на этот счёт могут быть соображения? Что если RR будет отправлять два маршрута, которые он получает от R4 и R6, и на R5, и на R7, и позволит им самостоятельно решить, какой маршрут лучше, независимо от того, какое решение он принимает для себя.

BGP Additional Path (ADD-PATH)

R5 теперь имеет два маршрута и, сравнивая их, решает, что лучший путь для достижения 203.0.113.0/24 – через R6. Он сам принимает это решение и не полагается на RR, который решил вернуться к использованию R4, поскольку R6 больше не отправляет маршрут с local preference 200. R7 выбирает R4 на основе своих собственных метрик для R4 и R6.
Теперь возникает следующий вопрос: как заставить RR отправлять два маршрута? Да! Нужно настроить Additional Path.

ЧТО ПРОИСХОДИТ, КОГДА ВЫ ВКЛЮЧАЕТЕ ADD PATH
Когда вы включаете ADD PATH, в поведении BGP происходят 3 основных изменения:
1. Согласуется поддержка ADD PATH
2. Изменяется NLRI в BGP UPDATE
3. Анонсируется несколько маршрутов

Поддержка ADD PATH

RFC3392 – Capabilities Advertisement with BGP-4 определяет, как маршрутизаторы BGP обмениваются необязательными параметрами, называемыми capabilities, которые, как следует из названия, описывают, способны ли соседи выполнять определенные функции, такие как graceful restart, 4-байтовые номера автономной системы или Multiprotocol.
Когда вы включите Add Path, ваши BGP-маршрутизаторы будут согласовывать возможность поддержки функционала ADD PATH (Capability Code 69), описанную в Разделе 4 RFC7911, чтобы указать, что они способны отправлять / принимать несколько путей для одного и того же префикса.

BGP Additional Path (ADD-PATH)

Например, в address family/subsequent address family может быть unicast IPv4, а поле «Send/Receive» может иметь значение:
(1) в состоянии получить несколько путей от своего соседа
(2) в состоянии отправить несколько путей к своему соседу
(3) в состоянии получать и отправлять несколько путей от / к своему соседу

Необходимо активировать Add Path как для отправителей, так и для получателей BGP префиксов, используя нижеприведённые команды. Приводится вывод команд, относящихся только к функционалу ADD PATH. Подразумевается, что вы знаете как настроить связанность BGP и функционал Route Reflector. Роутеры R4, R5, R6, R7 настроены как клиенты отражателя маршрутов RR.

Сначала включим возможность принимать несколько BGP маршрутов на клиентах RR. В примере приводится только маршрутизатор R5, но те же самые команды нужно выполнить и на R4, R6 и R7.

Первая команда включает способность принимать дополнительные маршруты, ведущие к одному и тому же префиксу. Вторая команда позволяет установить дополнительные префиксы в RIB. Префиксы устанавливаются как backup.

Теперь произведём настройки на Route Reflector

Первая команда видоизменилась. Теперь она позволяет маршрутизатору как принимать, так и отдавать дополнительные BGP маршруты. Вторая команда указывает на то, что все пути с уникальными next hop могут быть выбраны в процессе route selection. Ну и оставшиеся, говорят о том, что нужно анонсировать все дополнительные маршруты на соответствующих соседей.

После того как вы включите Additional Path на всех маршрутизаторах, вы можете убедиться, что маршрутизаторы действительно согласовали поддержку ADD PATH.

R7#debug ip bgp 172.16.71.1
R7#clear ip bgp 172.16.71.1
R7#
*Mar 17 10:14:20.281: %BGP-3-NOTIFICATION: sent to neighbor 172.16.71.1 6/4 (Administrative Reset) 0 bytes
*Mar 17 10:14:20.281: BGP: ses global 172.16.71.1 (0xD7814310:1) Send NOTIFICATION 6/4 (Administrative Reset) 0 bytes
*Mar 17 10:14:20.286: BGP: nbr_topo global 172.16.71.1 IPv4 Unicast:base (0xD7814310:1) NSF delete stale NSF not active
*Mar 17 10:14:20.286: BGP: nbr_topo global 172.16.71.1 IPv4 Unicast:base (0xD7814310:1) NSF no stale paths state is NSF not active
*Mar 17 10:14:20.286: BGP: nbr_topo global 172.16.71.1 IPv4 Unicast:base (0xD7814310:1) Resetting ALL counters.
*Mar 17 10:14:20.286: BGP: 172.16.71.1 closing
*Mar 17 10:14:20.286: BGP: ses global 172.16.71.1 (0xD7814310:1) Session close and reset neighbor 172.16.71.1 topostate
*Mar 17 10:14:20.287: BGP: nbr_topo global 172.16.71.1 IPv4 Unicast:base (0xD7814310:1) Resetting ALL counters.
*Mar 17 10:14:20.287: BGP: 172.16.71.1 went from Established to Idle
*Mar 17 10:14:20.287: %BGP-5-ADJCHANGE: neighbor 172.16.71.1 Down User reset
*Mar 17 10:14:20.287: %BGP_SESSION-5-ADJCHANGE: neighbor 172.16.71.1 IPv4 Unicast topology base removed from session User reset
*Mar 17 10:14:20.287: BGP: ses global 172.16.71.1 (0xD7814310:1) Removed topology IPv4 Unicast:base
*Mar 17 10:14:20.287: BGP: ses global 172.16.71.1 (0xD7814310:1) Removed last topology
*Mar 17 10:14:20.287: BGP: nbr global 172.16.71.1 Open active delayed 1024ms (0ms max, 60% jitter)
*Mar 17 10:14:20.287: BGP: nbr global 172.16.71.1 Active open failed — open timer running
*Mar 17 10:14:21.254: BGP: 172.16.71.1 active went from Idle to Active
*Mar 17 10:14:21.254: BGP: 172.16.71.1 open active, local address 172.16.71.7
*Mar 17 10:14:21.259: BGP: ses global 172.16.71.1 (0xD6CEDDA8:0) act Adding topology IPv4 Unicast:base
*Mar 17 10:14:21.259: BGP: ses global 172.16.71.1 (0xD6CEDDA8:0) act Send OPEN
*Mar 17 10:14:21.259: BGP: ses global 172.16.71.1 (0xD6CEDDA8:0) act Building Enhanced Refresh capability
*Mar 17 10:14:21.259: BGP: 172.16.71.1 active went from Active to OpenSent
*Mar 17 10:14:21.259: BGP: 172.16.71.1 active sending OPEN, version 4, my as: 400, holdtime 180 seconds, ID AC104707
*Mar 17 10:14:21.264: BGP: 172.16.71.1 active rcv message type 1, length (excl. header) 46
*Mar 17 10:14:21.264: BGP: ses global 172.16.71.1 (0xD6CEDDA8:0) act Receive OPEN
*Mar 17 10:14:21.264: BGP: 172.16.71.1 active rcv OPEN, version 4, holdtime 180 seconds
*Mar 17 10:14:21.264: BGP: 172.16.71.1 active rcv OPEN w/ OPTION parameter len: 36
*Mar 17 10:14:21.264: BGP: 172.16.71.1 active rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Mar 17 10:14:21.264: BGP: 172.16.71.1 active OPEN has CAPABILITY code: 1, length 4
*Mar 17 10:14:21.264: BGP: 172.16.71.1 active OPEN has MP_EXT CAP for afi/safi: 1/1
*Mar 17 10:14:21.264: BGP: 172.16.71.1 active rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar 17 10:14:21.264: BGP: 172.16.71.1 active OPEN has CAPABILITY code: 128, length 0
*Mar 17 10:14:21.264: BGP: 172.16.71.1 active OPEN has ROUTE-REFRESH capability(old) for all address-families
*Mar 17 10:14:21.264: BGP: 172.16.71.1 active rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar 17 10:14:21.264: BGP: 172.16.71.1 active OPEN has CAPABILITY code: 2, length 0
*Mar 17 10:14:21.264: BGP: 172.16.71.1 active OPEN has ROUTE-REFRESH capability(new) for all address-families
*Mar 17 10:14:21.264: BGP: 172.16.71.1 active rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar 17 10:14:21.264: BGP: 172.16.71.1 active OPEN has CAPABILITY code: 70, length 0
*Mar 17 10:14:21.264: BGP: ses global 172.16.71.1 (0xD6CEDDA8:0) act Enhanced Refresh cap received in open message
*Mar 17 10:14:21.264: BGP: 172.16.71.1 active rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Mar 17 10:14:21.264: BGP: 172.16.71.1 active OPEN has CAPABILITY code: 69, length 4
*Mar 17 10:14:21.264: BGP: ses global 172.16.71.1 (0xD6CEDDA8:0) act Additional Paths cap val 2 logged for afi/safi: 1/1
*Mar 17 10:14:21.264: BGP: ses global 172.16.71.1 (0xD6CEDDA8:0) act Additional Paths cap received as SEND for afi/safi: 1/1.
*Mar 17 10:14:21.264: BGP: 172.16.71.1 active rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Mar 17 10:14:21.264: BGP: 172.16.71.1 active OPEN has CAPABILITY code: 65, length 4
*Mar 17 10:14:21.264: BGP: 172.16.71.1 active OPEN has 4-byte ASN CAP for: 400
*Mar 17 10:14:21.264: BGP: 172.16.71.1 active rcvd OPEN w/ remote AS 400, 4-byte remote AS 400
*Mar 17 10:14:21.264: BGP: 172.16.71.1 active went from OpenSent to OpenConfirm
*Mar 17 10:14:21.264: BGP: 172.16.71.1 active went from OpenConfirm to Established
*Mar 17 10:14:21.264: BGP: ses global 172.16.71.1 (0xD6CEDDA8:1) act Assigned ID
*Mar 17 10:14:21.264: BGP: ses global 172.16.71.1 (0xD6CEDDA8:1) Up
*Mar 17 10:14:21.264: %BGP-5-ADJCHANGE: neighbor 172.16.71.1 Up
*Mar 17 10:14:21.267: BGP: 172.16.71.1 rcv message type 5, length (excl. header) 4
*Mar 17 10:14:21.267: BGP: 172.16.71.1 rcvd REFRESH_REQ for afi/safi: 1/1, refresh code is 1
*Mar 17 10:14:21.267: BGP: 172.16.71.1 rcv message type 5, length (excl. header) 4
*Mar 17 10:14:21.267: BGP: 172.16.71.1 rcvd REFRESH_REQ for afi/safi: 1/1, refresh code is 2
*Mar 17 10:14:21.272: BGP_Router: unhandled major event code 128, minor 0

Вы также можете проверить сведения о соседе BGP и снова убедиться, что ADD PATH поддерживается для данной сессии:

Изменения в NETWORK LAYER REACHABILITY INFORMATION (NLRI)

NLRI – это поле переменной длины, которое содержит список префиксов в сообщении UPDATE.
Без Additional Path поле NRLI выглядит в соответствии с RFC4271 (Section 4.3) следующим образом:

BGP Additional Path (ADD-PATH)

При использовании Additional Path NLRI включает в себя новое поле (идентификатор пути) и в соответствии с RFC7911 (Section 3) выглядит так:

BGP Additional Path (ADD-PATH)

Идентификатор пути позволяет отправлять несколько маршрутов для одного и того же префикса, причем принимающая сторона не предполагает, что второй анонс заменяет первый.
Что это означает?
Давайте снова посмотрим на наш лабораторный сценарий.
Если RR отправляет обновление для 203.0.113.0/24 к R5 без идентификатора пути, с next-hop = R4 и AS PATH = 200 100 I, и сразу после этого он отправляет обновление для того же префикса 203.0.113.0/24 с next-hop = R4 и AS PATH = 300 100 I, то R5 будет предполагать, что второй маршрут является заменой первого маршрута (что может быть правильным предположением на данный момент).

BGP Additional Path (ADD-PATH)

Давайте проверим маршрут 203.0.113.0/24 на RR, который RR отправит на R5, и что R5 имеет в своей таблице BGP относительно 203.0.113.0/24 (без настроенного ADD PATH). На RR видим:

RR выбрал маршрут через R4 и отправил только этот маршрут на R5:

Таким образом, R5 имеет маршрут только через R4:

Давайте изменим Local Preference маршрута, объявленного R6, чтобы RR изменил свой выбор для 203.0.113.0/24:

R6(config-route-map)# set local-preference 200
!

После этого мы снова проверяем, что анонсировал RR, и что R5 теперь имеет в своей BGP таблице:

Маршрут был заменён.

Вы также можете включить отладку и убедиться, что R5 рассматривает это обновление для 203.0.113.0/24 как «ИЗМЕНЕНИЕ».

Это ожидаемое поведение. R5 предполагает, что второе сообщение UPDATE является фактическим обновлением предыдущего, что является правильным. Мы изменили local preference маршрута, объявленного R6, и RR изменил своё мнение.
А что если RR вместо того, чтобы выбрать один лучший маршрут и отправить только его, отправит оба маршрута. Как R5 узнает разницу?
Это именно та задача, которую решает идентификатор пути. Добавляя это значение к маршрутам, получатель может обрабатывать их как отдельные маршруты, а не заменять один другим.

BGP Additional Path (ADD-PATH)

Давайте теперь настроим Additional Path (листенинг команд приводился ранее) и посмотрим, что изменилось.

Теперь RR анонсирует R5 два маршрута к 203.0.113.0/24

Вот так стала выглядеть маршрутная информация в BGP таблице на R5

Мы видим, что у нас теперь имеется два маршрута. Красным цветом выделен тот самый идентификатор пути.

Таким образом, маршрутизатор, на котором настроен ADD PATH, может отправлять все маршруты, известные для каждого конкретного пункта назначения, вплоть до максимального количества, которое является частью конфигурации. Кстати, для IOS и IOS XE максимальное значение равно 3. Это позволяет маршрутизаторам на принимающей стороне самостоятельно сравнивать маршруты и решать, какой маршрут лучше. В нашем тестовом сценарии Additional Path дает возможность R5 или R7 самостоятельно выбирать между R4 и R6 на основе своих собственных метрик.

Также если бы интерфейсы от R5 до R4 и R6 имели одинаковую скорость, мы могли бы включить балансировку нагрузки на R5.

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

источник