Функция 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.
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 для решения этой проблемы как показано ниже:
Теперь R6 анонсирует маршрут с Local Preference 200. В результате, когда RR сравнивает два маршрута, выбирается маршрут от R6 (наибольший Local Preference). Этот маршрут затем отправляется на R5, который теперь отправляет трафик, предназначенный для 203.0.113.0/24 через R6 (вместо R4). Это не может не радовать. Но что если мы добавим еще один маршрутизатор к этой топологии?
Новый маршрутизатор R7 физически расположен рядом с R4, и вы можете видеть, что метрика IGP до R4 намного ниже, чем метрика до R6. Однако поскольку RR теперь выбирает R6 в качестве лучшего маршрута, R7 будет принимать только этот маршрут и будет отправлять трафик, предназначенный для 203.0.113.0/24, через R6. Получается, эта ситуация выглядит великолепно с точки зрения R5, но ужасно с точки зрения R7.
Какие на этот счёт могут быть соображения? Что если RR будет отправлять два маршрута, которые он получает от R4 и R6, и на R5, и на R7, и позволит им самостоятельно решить, какой маршрут лучше, независимо от того, какое решение он принимает для себя.
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, чтобы указать, что они способны отправлять / принимать несколько путей для одного и того же префикса.
Например, в 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.
R5(config)# router bgp 400
R5(config-router)# bgp additional-paths receive
R5(config-router)# bgp additional-paths install
Первая команда включает способность принимать дополнительные маршруты, ведущие к одному и тому же префиксу. Вторая команда позволяет установить дополнительные префиксы в RIB. Префиксы устанавливаются как backup.
Теперь произведём настройки на Route Reflector
RR(config)# router bgp 400
RR(config-router)# bgp additional-paths send receive
RR(config-router)# bgp additional-paths select all
RR(config-router)# neighbor 172.16.41.4 advertise additional-paths all
RR(config-router)# neighbor 172.16.51.5 advertise additional-paths all
RR(config-router)# neighbor 172.16.61.6 advertise additional-paths all
RR(config-router)# neighbor 172.16.71.7 advertise additional-paths all
Первая команда видоизменилась. Теперь она позволяет маршрутизатору как принимать, так и отдавать дополнительные 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 поддерживается для данной сессии:
R5#show ip bgp neighbors 172.16.51.1 BGP neighbor is 172.16.51.1, remote AS 400, internal link BGP version 4, remote router ID 172.16.71.1 BGP state = Established, up for 02:43:30 <...вывод обрезан...> For address family: IPv4 Unicast Additional Paths send capability: received Additional Paths receive capability: advertised BGP diverse-paths computation is enabled Session: 172.16.51.1 <...вывод обрезан...>
Изменения в NETWORK LAYER REACHABILITY INFORMATION (NLRI)
NLRI – это поле переменной длины, которое содержит список префиксов в сообщении UPDATE.
Без Additional Path поле NRLI выглядит в соответствии с RFC4271 (Section 4.3) следующим образом:
При использовании Additional Path NLRI включает в себя новое поле (идентификатор пути) и в соответствии с RFC7911 (Section 3) выглядит так:
Идентификатор пути позволяет отправлять несколько маршрутов для одного и того же префикса, причем принимающая сторона не предполагает, что второй анонс заменяет первый.
Что это означает?
Давайте снова посмотрим на наш лабораторный сценарий.
Если 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 будет предполагать, что второй маршрут является заменой первого маршрута (что может быть правильным предположением на данный момент).
Давайте проверим маршрут 203.0.113.0/24 на RR, который RR отправит на R5, и что R5 имеет в своей таблице BGP относительно 203.0.113.0/24 (без настроенного ADD PATH). На RR видим:
RR# show ip bgp 203.0.113.0
BGP routing table entry for 203.0.113.0/24, version 16
Paths: (2 available, best #2, table default)
Advertised to update-groups:
6
Refresh Epoch 1
300 100, (Received from a RR-client)
198.51.100.5 (metric 1010) from 172.16.61.6 (198.51.100.6)
Origin IGP, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
200 100, (Received from a RR-client)
198.51.100.1 (metric 1010) from 172.16.41.4 (198.51.100.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
RR выбрал маршрут через R4 и отправил только этот маршрут на R5:
RR# show ip bgp neighbor 172.16.51.5 advertised-routes
BGP table version is 16, local router ID is 172.16.71.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*>i 203.0.113.0 198.51.100.1 0 100 0 200 100 i
Total number of prefixes 1
Таким образом, R5 имеет маршрут только через R4:
R5# show ip bgp 203.0.113.0
BGP routing table entry for 203.0.113.0/24, version 21
Paths: (1 available, best #1, table default)
Additional-path-install
Not advertised to any peer
Refresh Epoch 1
200 100
198.51.100.1 (metric 20) from 172.16.51.1 (172.16.71.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 198.51.100.2, Cluster list: 172.16.71.1
rx pathid: 0, tx pathid: 0x
Давайте изменим Local Preference маршрута, объявленного R6, чтобы RR изменил свой выбор для 203.0.113.0/24:
R6(config)# route-map LP permit 10
R6(config-route-map)# set local-preference 200
!
R6(config)#router bgp 400 R6(config-router)#neighbor 198.51.100.5 route-map LP in
После этого мы снова проверяем, что анонсировал RR, и что R5 теперь имеет в своей BGP таблице:
RR# show ip bgp neighbor 172.16.51.5 advertised-routes
BGP table version is 18, local router ID is 172.16.71.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*>i 203.0.113.0 198.51.100.5 0 200 0 300 100 i
Total number of prefixes 1
R5# show ip bgp 203.0.113.0
BGP routing table entry for 203.0.113.0/24, version 23
Paths: (1 available, best #1, table default)
Additional-path-install
Not advertised to any peer
Refresh Epoch 1
300 100
198.51.100.1 (metric 20) from 172.16.51.1 (172.16.71.1)
Origin IGP, metric 0, localpref 200, valid, internal, best
Originator: 198.51.100.6, Cluster list: 172.16.71.1
rx pathid: 0, tx pathid: 0x
Маршрут был заменён.
Вы также можете включить отладку и убедиться, что R5 рассматривает это обновление для 203.0.113.0/24 как «ИЗМЕНЕНИЕ».
*Mar 17 14:58:52.450: BGP(0): 172.16.51.1 rcvd UPDATE w/ attr: nexthop 198.51.100.5, origin i, localpref 200, metric 0, originator 198.51.100.6, clusterlist 172.16.71.1, merged path 300 100, AS_PATH
*Mar 17 14:58:52.450: BGP(0): 172.16.51.1 rcvd 203.0.113.0/24
*Mar 17 14:58:52.450: BGP(0): Revise route installing 1 of 1 routes for 203.0.113.0/24 -> 198.51.100.5(global) to main IP table
Это ожидаемое поведение. R5 предполагает, что второе сообщение UPDATE является фактическим обновлением предыдущего, что является правильным. Мы изменили local preference маршрута, объявленного R6, и RR изменил своё мнение.
А что если RR вместо того, чтобы выбрать один лучший маршрут и отправить только его, отправит оба маршрута. Как R5 узнает разницу?
Это именно та задача, которую решает идентификатор пути. Добавляя это значение к маршрутам, получатель может обрабатывать их как отдельные маршруты, а не заменять один другим.
