Ограничения Route Reflector при выборе пути и их решение с помощью BGP Additional Paths.
Какое ограничение Route Reflector решает Add-Path?
На каких сторонах необходимо активировать Add-Path?
Что происходит с атрибутом NEXT_HOP при передаче маршрута по iBGP?
Какая команда решает проблему недоступности оригинального NEXT_HOP?
Что позволяет Add-Path анонсировать клиентам RR?
Оба урока о передаче нескольких путей: multipath — о балансировке трафика по нескольким маршрутам, add-paths — о передаче множества альтернативных путей соседям для лучшей конвергенции
Add-paths особенно полезен в топологиях с Route Reflectors, где RR по умолчанию отдаёт только один лучший путь; add-paths позволяет RR передавать клиентам несколько путей
К сожалению, рут-рефлектора не могут решить всех проблем. Да, конечно, они позволяют решить проблемы при масштабируемости сети. Однако, когда у вас появляются рут-рефлектора, появляются проблемы несколько иного рода, несколько иного характера. В частности, давайте с вами рассмотрим пример. У нас в сети есть некий рут-рефлектор. Предположим, что из автономной системы есть две точки выхода. Это муртизатор R1 и муртизатор R2. Они так или иначе подключены, например, к некому муртизатору RX. У этого муртизатора RX есть некая сеть. 1, 1, 1, 0, 24.
Дальше. Граница автономной системы проходит вот здесь. Предположим, что муртизатор R1 подключен к амуртизатору. Р3 подключен к рут-рефлектору. Муртизатор R4. Здесь есть муртизатор R5. Муртизатор R5 также подключен к рут-рефлектору. И вот здесь у нас есть некий муртизатор R6. Давайте посмотрим, что же произойдет в топологии такого рода. Муртизатор RX передает префикс осети 1, 1, 0 на оба бордера. На R1 и на бордер R2. Далее. Муртизатор R1 по IBGP-сессии передает префикс в сторону рут-рефлектор.
То же самое делает муртизатор R2. То же самое делает муртизатор R2. Муртизатор RR прилетают два маршрута от R1 и R2. И далее, прежде чем передавать данные маршруты, данные префиксы, всем своим оставшимся рут-рефлектор клиентам, рут-рефлектор прежде всего выбирает наилучший путь. На самом деле рут-рефлектор надает не все префиксы, а только лучшие. То есть, предположим, что рут-рефлектор наилучшим путем выбрал путь через муртизатор R1. То есть префикс, который был получен от R1, он выбран как best. В частности, я обращал внимание, что внутри каждого префикса присутствует обязательный атрибут,
который называется next-hop. То есть на рут-рефлекторе был выбран наилучший префикс с next-hop, равным муртизатору R1. И далее только этот наилучший маршрут будет отдаваться всем своим рут-рефлектор клиентам. И что получается? Рут-рефлектор отражает данный префикс в том числе в сторону муртизатора, например, R6, и в сторону муртизатора R4 тоже. Муртизатор R6 получает апдейт от рут-рефлектора клиента и инсталирует его к себе в BGP-таблицу. Каким образом? Получается, что у нас есть префикс 1.1.1.0.24, который нам доступен с next-hop, равным R1. То есть о чем это говорит? Это нам говорит лишь о том, что муртизатор R6, то есть трафик от муртизатора R6 пойдет каким образом?
Пойдет как-то от R5 и пойдет в сторону муртизатора R1. То есть, хоть у нас и есть вроде бы более, для нас более короткий выход из автономной системы, но трафик здесь бегать не будет, потому что в качественных схобах у нас выбран муртизатор R1. То есть, как вы видите, рут-рефлектора, они, по сути, скрывают некую часть топологии. И поэтому иногда у вас в сети может случиться субоптимальный раутинг. Субоптимальный раутинг. Давайте посмотрим, к чему это может привести. К чему это может привести. Итак, я сейчас вам хочу напомнить, что у нас есть топология. В частности, у нас уже настроены два рут-рефлектора.
В частности, это муртизатор R2, который имеет связанность с муртизатором R1, и муртизатор R5, который имеет связанность с R5. Я предлагаю сейчас в нашу топологию ввести дополнительный линк между муртизаторами R4 и R5, например. Хотя тут на самом деле не важно. Сейчас, секундочку дать мне буквально пару секунд. Что я хочу сделать? Я хочу взять вот эту сеть, которая находится между муртизаторами R1 и R3. Оба муртизатора R1 и R3 поместят ее в BGP-таблицу. Далее оба муртизатора отдадут их на один и тот же рут-рефлектор. То есть мне потребуется connectivity IBGP-сессия между R1 и R2.
Вот эта сессия будет мне нужна. Этот рут-рефлектор мы можем выводить из игры. И мы построим дополнительную IBGP-сессию между муртизатором R2 и R4. И вот здесь вы увидите, что муртизатор R4 выберет только один из маршрутов. То есть либо на X-HOP будет муртизатор R3, либо на X-HOP будет муртизатор R1. Ну что ж, давайте сделаем. Муртизатор R5 я могу вывести из игры. Он мне больше не нужен. Окей. Так.
Соответственно, теперь я поднимаю сессию между R1 и R2. С точки зрения R2 у меня есть уже связанность. У меня уже есть связанность. Единственное, я раут R1, R2, R2, R2. 1, 2, 3. Я уберу нейбора от этого пятого. И сделаю no shutdown. No neighbor shutdown. BGP-сессию. Хорошо. Далее. На маршруте R1. Show IP interface brief. Сеть между маршрутизатором. Напомню, нас интересует эта подсеть между маршрутизатором R1 и R3. Между R1 и R3 это сеть 10.1.3.
Раутер. 1, 2, 3. Говорю команду network. 10.1.3.0. mask. mask. mask. mask. mask. mask. mask. mask. mask. mask. mask. mask. mask. mask. mask. Это на маршрутизаторе R1. То же самое делаю. На маршрутизаторе R1. Теперь на раут рефляторе. Show IPBGP. Увидим то, что у меня есть... На маршрутизаторе R2 имеется префикс 10.1.3.0. Он доступен через два носхопа. Через носхоп маршрутизатора R3. И через маршрутизатор R1. Через маршрутизатор R1. При этом префикс через маршрутизатор R1 был выбран лучшим. Об этом свидетельствует у меня вот такой вот знак больше. Обращаясь на внимание, что больше это best.
То есть show IPBGP 10.1.3.0. Вот подтверждение, что префикс был выбран как the best, который был получен от маршрутизатора R1. Далее. Мне потребуется линк между R2 и R4. Interface G2.24. Interface G2.24. Adress 10.242. Включу его в OSPF. То же самое сделаю на четвертом. Раутер BGP 123.
Пропишу соседа. Neighbor 10.242. Remote IS 123. И то же самое сделаю на маршрутизаторе R2. Neighbor 10.242. Remote IS 123. Через какое-то время я ожидаю поднятия соседства. Ping 10.242. Проверим связность. Связность есть. Show IPBGP summary. Сессия пока не поднялась. Правильно я здесь настроился. Обратите внимание, я здесь неправильно указал соседа. Я здесь указал.
Can configure local system is a neighbor. Раутер 4. BGP neighbor is a neighbor. Проверяем. Show IPBGP. Обратите внимание, что на маршрутизатор R4 в качестве XHOP используется маршрутизатор R1. Если я сейчас запущу trace route 10. 10.1. Например, 3.3. Юмерик. То обратите внимание, как у меня бежит трафик. Как бежит трафик. Пакет от маршрутизатора R4.
Единственное, но здесь, наверное, не совсем хорошо получилось, потому что я использую URL на R4. Дело в том, что здесь шоу IP интерфейс BRI. У меня здесь есть интерфейс G.1. Мне его нужно сначала зашотдаунить. Зашотдаунить. Извиняюсь, я не могу делать трассу на 10.1.3. Объясню, почему. Дело в том, что если я посмотрю таблицу маршрутизации, show up и router SPF. Дело в том, что я здесь не вижу всех транзитных сетей. Почему? Потому что show run section router SPF. Здесь используется команда префикс oppression.
У меня остается только loopback в таблице маршрутизации. Поэтому я могу запустить trace на 33333. Source loopback 0. С пакетами всегда будет бежать. Бежит R2, потом в сторону R3. Он не заворачивается на маршрутизатр R1. Не заворачивается на маршрутизатр R1. К чему это я? Итак, возвращаемся к просмотру show ipvgp. И видим, что нам доступен только один XHOP. А при этом обратите внимание, что сеть не выбирается лучшей. Сеть не выбирается лучшей. То есть show ipvgp. route pgp. Нет.
Чуть-чуть, через секундочку буквально поговорим о том, почему так. Сейчас же посыл к чему. Использование root рефлекторов, с одной стороны, помогает нам строить сети более масштабируемые. А с другой стороны, они скрывают топологию. И у нас тогда может возникать субоптимальный раутинг. То есть это первая проблема. Вторая проблема – это увеличенное время конвергенции сети. То есть более медленная конвергенция. Почему так происходит? Здесь все очень просто. Если у клиента, например, попадает некая сеть, что он делает? Он высылает апдейт сначала на раут рефлектор. Далее раут рефлектор, этот апдейт он должен обработать. Вы выбираете, соответственно, новый наилучший маршрут. И только после этого рассылает информацию о пропавшем префиксе всем остальным своим клиентам. То есть если бы у нас все маршрутизаторы были связаны между собой
через полносвязную топологию напрямую, то конвергенция подходила бы несколько быстрее. Но платой за это мы получили бы то, что такой сеть очень тяжело управляет. Это что касается рут рефлекторов. Сейчас бы мне хотелось бы ваше внимание обратить на тот факт, что этот префикс 10.1.3.0, он нам не доступен в BGP-таблице. Почему так? Почему так? Если я скажу show ip bgp 10.1.3.0, то обратите внимание, что в качестве NextHop для BGP используется адрес 10.1.2.1, и он для нас inaccessible. По сути, это говорит мне о том, что данного NextHop нет у меня в таблице маршрутизации.
То есть если я скажу show ip route 10.1.2.1, я увижу, что subnet not in table. show ip cf 10.1.2.1. No route. Что получается? Когда маршрутизатор принимает некий BGP-анонс, прежде всего он проверяет, доступен ли NextHop. Понимаете, если NextHop недоступен, то обрабатывать префикс не будет особого смысла. Почему? Ну да, мы можем его как-то обработать, применить к нему какие-то политики, но инсталлировать его в таблице маршрутизации мы не сможем, потому что нам недоступен маршрутизатор, через который нам нужно маршрутизировать данный префикс. Поэтому обязательно, ну обязательно необходимо,
чтобы все ваши NextHop находились уже в таблице маршрутизации. Обычно за это отвечает протокол USPF. Ну то есть в реальной сети у вас USPF используется в качестве опорной сети. То есть вы в USPF передаете все ваши транзитные префиксы, например, ваши loopback и так далее. А уже поверх этих, например, транзитных сетей, либо loopback строите BGP-связанность. Конкретно в моем случае что получается? Вот этот префикс, он мне недоступен не из-за того, что мы его не анонсим в USPF. Мы можем посмотреть show.ip, например, в USPF database. show.ip database, например, router 10.1. router 1.1.1.1. И вы увидите, что у меня есть LSA,
который описывает данное подключение, который описывает данный наскоб. Но из-за того, что данное LSA не попадает в итоге после обработки в RIP-таблицу, данный префикс мне с точки зрения USPF недоступен. Поэтому я не могу... Мурсиатор R4 не может проинсталлировать к себе любые BGP-апдейты, которые приходят с neshop равным 10.1.2.1. Что можно сделать? Что можно сделать? На самом деле есть несколько различных сценариев, но наиболее распространенные из них следующие. Если мы с вами говорим про IBGP, давайте нарисуем такую сеть. R1, например, R2, R3 и R4.
Они между собой сидены, скажем. Скажем вот так. И мы строим связности между мурсиатором R1 и между мурсиатором R4. Теоретически мы можем построить BGP-сессию, которая строится, например, с этого физического интерфейса на этот физический интерфейс. Мы можем взять вот такую сессию. Либо мы можем, например, построить сессию с этого интерфейса на этот интерфейс. Однако, к сожалению, недостатком такого построения сессии является то, что при падении какого-либо линка физического сети у нас BGP-сессия также рвется. Хотя у нас существует альтернативный путь, как добраться до точки назначения. Поэтому внутри вашей автономной системы придерживается следующего правила. Создаются интерфейсы типа Loopback.
Обычно это некий интерфейс Loopback 0 здесь. И интерфейс Loopback 0 здесь. И вся сессия строится между вот этими интерфейсами. Между вот этими интерфейсами. Как этого достичь? Как этого достичь? И если посмотреть на нашу топологию, давайте построим connectivity от марштизатора R1 к марштизатору R2 с их Loopback адресами. Для этого что мне нужно сделать? Я должен убрать в сторону R2 сказать, у меня больше не будет соседа с адресом 10.1.2.2.2. Но у меня теперь будет сосед с адресом 2.2.2.2.2. Remote S 123. При этом, если я хочу строить сессию с Loopback,
то я говорю Neighbor 2.2.2.2.2. И здесь есть замечательная команда, которая называется Update Source. То есть с какого интерфейса мы будем строить и высылать наши BGP сообщения. Update Source. Loopback 0. То же самое делаем на втором. Добавляем No Neighbor. Neighbor 1.1.1.1.1. Remote S 123. И Neighbor 1.1.1.1.1.1.2. Update Source. Loopback 0. И не забываем сказать, что это наш root reflector клиент. то же самое давайте сделаем между r2 и r3 но либо теперь у нас получается 3 3 3 3
remote is 123 3333 update source вот back 0 здесь router gp123 но и батакон то и 2 2 2 2 2 remote is 120 теперь теперь на может 2 show ip gp summary видим что у меня по им поменялись адреса соседей и теперь если я посмотрю на маршизаторы r4 префикс 10 1 3 0 то увидите что в качестве
на скоб у меня стоит 4 единички то есть стоит маршизатор р1 и уже этот префикс он выбран наилучший он выбран наилучший show ip show ip route bgp видим что сеть 10 1 3 0 нам доступна через маршизатор через маршизатор характер я думаю что вы можете задаться вопросом если если раут рефлектор скрывает все топологии а можно ли сделать так чтобы лучше маршрут выбирал все таки конечный клиент а не сам раут рефлектор на самом деле сделать это можно появилось это я не уверен что очень давно в вывозах но тем не менее по сути это все дело одной команды
роутер gp 123 gp gp additional pass собственно говоря receive и send по сути можно мне кажется мы здесь можем обойтись только команды и gp additional pass send нам может за такер 4 шоу эти бюджет и и и и и и и и и здесь у нас есть префикс через третьего и через первого
вполне вероятно что нужно дать еще команду receive на маршизаторе r4 вероятно то есть на клиенте нужно еще дать команду additional pass receive 1 2 3 и и и и и и и и и сейчас вы видите немножко дергается беджи пи соседства потому что это новая капабильте между соседями и и и и и и и и и и и я ожидаю здесь увидеть вероятно нам потребуется помощь и дешевле пас стал тури
стал климате беджи пель и и и не так часто пользуюсь этой функции на самом деле поэтому с вашего позволения я запрошу небольшую помощь зала джи пи и дешевле дешевле пас можно использовать например сайт интерплессис как вариант либо непосредственно как либо непосредственно configuration guide для cisco ком так на муша 3 r1 так на муша 3 r1 так на муша 3 r1 где здесь
только сосед 2 2 2 2 2 а уже тарар 2 это route reflector да тарар 2 это route reflector здесь только сосед 2222 уже трер два и трат рефлектор так как очень похоже на то что я нашел ошибку я не сказал что я могу авертайзе что я должен диртать мурсатор р4 все эти все они что упасы поэтому раутер биджи 5123 наиба 10244 и у нас здесь появляется есть команда
адвир тайс то есть одежду пас теперь нам сатор р4 я ожидаю так наверное нужно сделать пирайки биджи петин просим а теперь на 4 доступен префикс здесь 130 доступен с флагом by б значит backup пас шоу и пиджи пи есть 130 у нас есть при есть два маршрута один который доступен через маршрута затор р1 2 доступен через маршрута 3 через маршрута 3 и есть еще один нюанс который касается обработки без обработки на схопов в
топологии в биджи пи топологиях давайте этот нюанс следующий следующий так поднимемся чё-то маршрута р5 я сейчас введу в основном систему 45 4578 подниму соседство с маршрута р2 10252 ремоута из 123 наиба 10252 ремонт а из 123 и на маршрута 3 r2 наиба 10252 ремонт а из 123 и на маршрута 3 r2 наиба 10255 ремонт а из ремонт а из 123 и на маршрута 3 r5 наиба 10255 ремонт а из ше 5 7 8 взял на маршрута 3 r5 на маршрута 3 r5 я добавлю одну подсеть в биджи пи
например я добавлю скажем вот эту сеть 10 5 7 network 10 5 7 0 маска 255 255 что получается шоу айпи биджи пи как мы появляется подсетка 10 1 5 7 0 это подсеть передается на маршрутизатор r2 на мусор 2 шоу айпи биджи пи вот здесь здесь есть сеть 10 5 7 0 кстати обратите внимание что префикс здесь один три ноль теперь народ рефлекции на раут рефлекторе помечен буковкой а что говорит что это одни шпас и так возвращаемся к префиксу 10 5 7 0 шоу айпи биджи пи
10 10 5 7 0 как поведен что здесь все хорошо этот маршрут нам доступен он выбран как best естественно должен был появиться таблицам афтизации по биджи пи протокол далее далее обращаем внимание что мы его анонсим на апдейт группы 22 23 27 шоу и ки биджи пи апдейт групп групп 22 23 и 27 как видите моего даем маршрутизатором r3 r1 и r4 раут биджи пи сеть также установлено и на маршрутизаторы р3 шоу айпи раут биджи пи сеть также установлено и на маршрутизаторы р3 шоу айпи так так так сейчас мне кажется я не нужно погасить интерфейс нужно лишний интерфейс погасить
интерфейс гидин шиндал шиндал дашу на всех что происходит шоу айпи раут бгп так про внимание что нам маршрутизаторы r1 равно как нам маршрутизаторы r3 равно как и нам маршрутизаторы с 4 отсутствует префикс 10 5 7 0 почему давайте посмотрим биджи пи таблицу шоу айпи биджи пи таблица да он присутствует но при тем они он мне помечен лучше он не помечен у нас отсутствует за знак больше шоу айпи биджи пи 10 5 7 0 почему потому что next hop is inaccessible
inaccessible обратите внимание что в качестве на схопа маршрутизатор r1 видит адрес маршрутизатора r5 10 2 5 5 итак маршрутизатор r5 анонсирует эту подсеть в новую внутрь бгп передает ее в сторону маршрутизатора r2 выставляя в качестве на схопа себя в качестве на схопа себя далее маршрутизатор r2 раздает этот апдейт в сторону маршрутизатором r3 и в сторону маршрутизаторов r1 при этом при этом на схоп сохраняется неизменно почему потому что это у нас айбиджи пи сессии соответственно у нас вытекает правило что при смене при передаче айбиджи пи апдейта next hop у нас не меняется у нас действует правило next hop unchanged
а как же быть а как же быть ведь нам просто необходимо чтобы может и затор r3 и мусорта r1 видели в качестве на схопа тот адрес до которого они знают маршрут есть несколько вариантов решения этой проблемы первый вариант мы можем добавить вот эту подсеть адвертайзить ее внутрь о спефа например как который крутится у нас в сети enterprise в этом случае этот линк станет доступным с точки зрения успех это первый вариант а второй вариант при передаче айбиджи пи мы можем поменять next hop как это делать 3 на мышца 3 r2 мы говорим следующее для нейбора 1111 для нейбора 1111 мы говорим next hop
next hop self disable next hop calculation for this neighbor на то есть описание может быть не совсем понятное но по сути она говорит следующее когда мы передаем апдейты сторону мусортизатора r1 для всех апдейтов мы выставляем в качестве мусорта р2 выставляет в качестве на схопа себя в частности поскольку у нас стоит стоит команда вы дана команда апдейт сурс лобак 0 то в качестве атрибута на схоп будет выставлен айпи адрес интерфейса лобак 0 лучше уран интерфейс лобак 0 будет выставлен адрес 2 2 2 2 2 2 и то же самое давайте сделаем для адрес интерфейс лобак 0 проверяем на мусортизаторе r1 и видите у нас изменилась запись у нас на схоп был 10 2 5 5 стал 2 2 2 2 2 2
поскольку этот скоп нам известен шоэпи раут 2 2 2 2 2 а он нам известен почему потому что у нас есть протокол маршрутизации успев который работает внутри нашей автономной системы то мы спокойно можем заинсталировать префикс 10 5 7 0 в внутрь свои джи пи таблички и поместить маршрут как валиды шоэпи раут бгп есть 5 7 0 то же самое будет на мусортизаторе р3 шоэпи раут бгп а вот на мусортизаторе р3 кстати этого не случилось шоэпи бгп у меня есть префикс в качестве на схопа стоит 10 2 5 5 то есть сторону р3 ничего не поменялось а я дал не ту команду я забыл дать команду next hope self
обратите внимание что это не происходит не сразу в принципе вы всегда можете сделать команду clear ip бгп указать адрес соседа например 3 3 3 3 и в направлении аут вы заново передадите все апдейты можете завтра р3 теперь префикс у нас доступен с 1 хопом 2222 шоэпи раут бгп разделив ой додай оно bull 7 объем пад м