Weight: первый атрибут в алгоритме Best Path Selection

Добрый день! Сегодня мы с вами поговорим о выборе наилучшего пути в BGP под управлением Cisco Avias. Когда мы с вами смотрели выводы show.ip.bgp, мы замечали, что у префикса есть некий набор атрибутов. В частности, до этого момента мы работали с атрибутом isPass. Однако, если внимательно присмотреться, то вы увидите, что таких атрибутов там довольно-таки много. В частности, атрибут NextHop, атрибут Origin, атрибут ClusterList, атрибут LocalPreference, атрибут Internal или External, атрибут Wait и так далее.

Соответственно, для BGP выбор наилучшего пути основывается на сравнении определенных атрибутов между собой. То есть здесь присутствует огромная разница между BGP и такими протоколами, как OSPF и EGRP. Если OSPF используют для сравнения, для выбранной лучшего пути, некую метрику, в частности, cost, который настроен на линк, то BGP сравнивает между собой именно атрибуты, которые получены от разных соседей. При этом все атрибуты будут сравниваться в строгой последовательности. Но прежде чем переходить к сравниванию атрибутов между собой, BGP проводит некоторые проверки.

Прежде всего, NextHop обязательно должен быть доступен. Если NextHop недоступен, то есть его нет в RIB, то такой маршрут не будет обрабатываться BGP процессом. Помните, у нас было уже пару случаев на более ранних уроках, и в этом случае префикс никогда не помечался как валидный. Далее. ASPath не должен содержать номер собственной AS. То есть это классический механизм BGP Loop Prelection. Этот момент у меня помечен звездочкой. Почему? Потому что иногда требуется нарушить это правило. В частности, у нас может быть вот такая ситуация. Все те, кто слушали у меня курс по MPLS, вы уже знаете об этой ситуации.

Тем, кто не был на курсе, хочу рассказать. Предположим, что амортизатор R1 находится в автономной системе условной номер 10. Амортизатор R2 находится внутри автономной системы номер 10. И они связаны между собой через облако, скажем, сервис провайдера. У вас вот здесь работает, скажем, IBGP. И вот здесь у вас также работает IBGP. И ваша задача передать префиксы с амортизатора R1 на амортизатор R2. В таком случае очевидно, что если амортизатор R1 передаст апдейт сначала в сторону сервис провайдера, а потом сервис провайдер передаст его в сторону амортизатора R2, то такой апдейт будет дроб. Но специально для таких случаев есть некоторые команды, которые позволяют частично игнорировать AS-пас.

И у амортизатора R2 все равно будет возможность принять такой префикс. Об этом мы поговорим чуть-чуть позже. Детально эта ситуация рассмотрена в MPLS курсе. Следующее. Следующее. Если оба этих условия выполнены, то начинается сравнение атрибутов. Прежде всего сравниваются, предпочтаются маршруты, у которых наибольший вес. Я не случайно пометил этот пункт двумя звездочками. Дело в том, что этот атрибут является так называемым Cisco proprietor. То есть он не реализован у других вендоров. Наверное, у других вендоров, у Huawei, у Juniper есть некая альтернатива.

Но именно вес присутствует только у Cisco. Следующий шаг. Сравниваются маршруты, сравниваются атрибуты, которые называются Local Preference. Если атрибут Local Preference одинаковый у двух маршрутов, то мы переходим к шагу номер 4 и сравниваем длину атрибута IS-Path. То есть, по сути, мы сравниваем, сколько транзитных автономных систем есть через первый путь и есть через второй. Но чем меньше длина IS-пути, тем лучше. Если длина IS-пути одинаковая, то сравнивается атрибут, который называется Origin. Напоминаю, что Origin указывает нам на то, каким образом данный префикс попал в BGP-систему. В частности, этот атрибут может принимать одно из двух возможных значений.

Либо значение IGP, либо значение incomplete. Значение IGP используется в том случае, если префикс был анонсирован с помощью команды Network. Значение incomplete используется в том случае, если префикс попал через redistribute. Если и этот шаг не дает ответа на вопрос, какой же из двух маршрутов лучше, то сравниваются маршруты, сравниваются атрибуты так называемой multi-exit discriminator. По сути своей, это некая метрика. То есть, это аналог метрики в SPF, аналог метрики в EGRP. Единственное, метрика мет не всегда присутствует в BGP-апдейте. То есть, это на самом деле необязательная атрибука. И что делать, например, если мет не передается к нам от соседа?

Такая ситуация возможна. По умолчанию, по умолчанию, в Cisco считают, что если мет не передается, то мет равен нулю. Это поведение настраиваемое. То есть, мы можем либо использовать мет, то есть, мы можем мет настроить по умолчанию, либо равным нулю, либо максимальному значению. Я, честно говоря, не помню, какое оно довольно-таки большое. По-моему, порядка 32 битч. При этом мет сравнивается не всегда, а только если мы сравниваем маршруты, которые мы получили от двух BGP-соседей, которые находятся в одной и той же автономной системе. Единственное, конечно, это параметр, вот эта вещь также настраиваемая. И мы можем сказать, что нам необходимо метрику сравнивать всегда и при любых обстоятельствах. Да, это не так часто используется, но, тем не менее, это возможно.

Если и сравнение мультиэкзидискриминатора не позволяет нам ответить на вопрос о наилучшем пути, по сути, мы сравниваем дальше между собой административную дистанцию BGP-протоколов. Если мы апдейт получили от IBGP-соседа, то для IBGP у нас административная дистанция равна 200, для IBGP административная дистанция равна 20. В этом случае выигрывает маршрут, который был получен по IBGP. Если же маршруты были получены от IBGP-соседей одинакового типа, то дальше мы сравниваем уже IGP-метрику, то есть, например, OSPF-метрику, либо EGRP-метрику до NextHop. Если метрика одинаковая, то дальше включается уже, на самом деле, такой, скажем, полурандом.

Начинают в качестве арбитров выступать либо раутер-айди, либо IP-адрес. Лично мое, скажем так, к вам пожелание, никогда не доводить выборный лучшего пути дальше, чем длина ISPASS. То есть вот здесь, вот здесь, выборный лучшего пути должен заканчивать. Потому что дальше сравниваются атрибуты, которые не всегда передаются, они могут, ну, не так часто, на самом деле, в жизни они используются. А сейчас я предлагаю разобраться, собственно говоря, с первым атрибутом, который называется вес. И в каких ситуациях его хорошо использовать. Итак, прежде всего, вес – это пропретарный атрибут, то есть это неизвестный атрибут.

И этот атрибут – так называемый locally significant. То есть он никуда с муристизатора не передается, а живет только на нем. И используется для сравнения апдейтов, которые приходят на этот муристизатор. То есть, самое типовое сценарий, когда вес может быть полезен, это следующее. Есть муристизатор R1. Он имеет, например, 2 или 3 BGP-связности с внешними BGP-соседями. И мы, например, хотим сделать так, чтобы исходящий трафик пришел через муристизатор R2. А в случае, если муристизатор R2 будет недоступен, то трафик переключался на муристизатор R3. То есть, условно говоря, вес очень часто используется для обеспечения, так называемого, active standby-подключения к сервис-провайдерам со стороны организации.

Давайте посмотрим, как это работает. В нашей топологии я могу использовать муристизатор R1 как тестовую точку. Я подниму и BGP-соседство с муристизатором R6 и с муристизатором R4. И я хочу, чтобы муристизатор R1 предпочитал муристизатор R6 как исходящую точку для всего трафика. Давайте сделаем. Итак, на муристизаторе R1. У меня уже поднят BGP процесс, поэтому я говорю router BGP 123. Говорю сосед neighbor 10.1.6.6.6.

Remote AS6. Вот, а сейчас ушел IP BGP summary. Так, у меня есть пилинг со вторым. Я думаю, что вот этого neighbor нам нужно убрать. No show IP interface brief. То есть, также остатки у нас есть. Между первым и пятым. Да, между первым и пятым у нас не должно быть прямого линка. Сделаем. И поднимаю соседство между первым и четвертым. Говорю команду neighbor 10.1.4.4. Remote AS6.4.5.7.8. Поднимаю соседство на муристизатор R4.

1, 2, 3. Раутер BGP 4.5.7.8. Neighbor 10.1.4.1. Remote AS6.4.5.7.8. 1, 2, 3. И со стороны муристизатора R6. Раутер BGP 6. Neighbor 10.1.6.1. Remote AS6.4.5.7.8. 1, 2, 3. Remote AS6.4.5.7.8. И сразу же хочу поднять связность между 6 и 9. Neighbor 10.6.9.9. Remote AS9. И со стороны 9. Раутер BGP 9. Neighbor 10.6.9.6.

Remote AS6. И вот. Итак. Со стороны муристизатора R1. У меня поднялись SHOW IP и BGP Summary. У меня поднялись два соседа. Четвертый и шестой. Четвертый и шестой. Хорошо. Теперь я с муристизатора R9 буду анонсировать некий префикс. Этот префикс пойдет двумя путями. Он пойдет через автономную систему 4578. Придет вот так вот апдейт. И второй апдейт. И второй апдейт пойдет напрямую через AS6. Напрямую через AS6. Так.

На муристизатор R9 я создаю интерфейс G2. 9. Inkslation. Dot. 9. IP адрес. 10. О, здесь у нас будет 172.16. 9. 9. И помещаю эту сеть. Raul 3. GP9. Network. 172.16. 9. 0. Mas. 2550. Проверяю. Show IP. BGP. Сеть 182.16. 9. Появилась. Она должна была появиться на муристизаторе R6. Show IP. BGP. Да. Появилась. И должна была появиться на муристизаторе R1. 172.16. 9.0. Единственное, как видите, я пока ее получаю только от муристизатора R6. И совершенно не получаю от муристизатора R4 почему-то.

Давайте посмотрим здесь. Show IP. BGP. Потому что муристизатор R4 получает его от муристизатора R1. Муристизатора R1. Что мне на самом деле сейчас не очень нравится. Давайте посмотрим, получает ли этот префис муристизатор R8. Show IP. BGP. Муристизатор R8 не получает. А почему? Show IP. BGP. Summary. А потому что на муристизатор R8 нету связанности с 9. Раутер BGP. 4578. Neighbor. 10. 8. 9. 9. Remote. S9. Дождемся поднятия соседа.

Все поднялось. Теперь на муристизатор R4. Так. Так. На R8. Neighbor поднялся. Show IP. BGP. И. И. Префикс есть. Префикс есть. Этот префикс мы передаем на муристизатор R7. На муристизатор R7. Show IP. BGP. Обратите внимание, что на муристизатор R7. 172.16.9.0, который мы получили, он не помечен как валидный. Он не помечен как валидный. А все потому, что на R8 нам необходимо дать командочку nextHopSelf. Чтобы у нас не возникала проблема с nextHop. Здесь мы говорим Neighbor. 77.77.77.77.7.7.7.7.7.7.7.

NextHopSelf. И сделаем Clear IP. BGP. На out. Сейчас на муристизатор R7. Да. Префикс, который муристизатор R7 получил от муристизатора R8. Помечен лучше. И на муристизатор R4. Что же у нас на муристизатор R1? Как мы видим, на муристизатор R1 у нас действительно присутствует два префикса. Один префикс, который получен от двух соседей. Show IP. BGP. 172.16.9.0. Первый префикс получен от муристизатора R4. Второй получен от муристизатора R6. И при этом префикс, который получен от муристизатора R6, по каким-то причинам был выбран наилучшим. То есть, очевидно, если вернуться к нашему слайдюцу

по выбору наилучшего пути, то сыграл, на самом деле, скорее всего, сыграл пункт номер 7. То есть, там, где предпочитаются маршруты, полученные по имиджу, вероятно, сыграл либо пункт номер 8, либо пункт номер 9. Какой-то из этих. То есть, здесь сразу не очень понятно, почему. Итак. Я хочу, например, чтобы муристизатор R1 в качестве исходящей точки выбирал муристизатор R4. Как я это могу сделать? Сделать я могу это очень просто. Сказать. Раутер BGP 1, 2, 3. И поскольку первым сравнивается вес, заметьте, по умолчанию вес для префиксов, полученных от соседей, равен нулю. Поэтому, если я установлю вес для маршрутизатора R4 большим, чем ноль, то маршрутизатор R4 с точки зрения

R1 станет предпочтительной точкой выхода. Сделать это можно вот так. Neighbor 10, 1, 4, 4. И есть такая командочка, как вес. Я могу задать любое число в диапазоне от 0 до 65 тысяч. Например, вес 100. Проверяю, что IPBGP. Обратите внимание, что пока ничего не обновилось. Ничего не обновилось. Чтобы мои изменения по фильтрации или по модификации каких-то атрибутов вступили в силу, мне необходимо запросить апдейт во входящее направление от своих соседей.

Сделал я думаю. Теперь обратите внимание. В качестве наилучшего маршрута выбран маршрут через маршрутизатор R4. Почему? Потому что у него стоит вес равным 100. То есть showIPRouteBGP в качестве исходящей точки используется маршрутизатор R4. Если вдруг что-то случится, упадет отношение соседства, то в качестве резервного пути будет использоваться путь через маршрутизатор R4. Через маршрутизатор R4. То есть вот таким вот образом, если на один маршрутизатор приходят каналы связи от двух провайдеров, сделать это довольно-таки просто. То есть сделать один канал primary, а другой канал secondary. Однако, однако, вес не обязательно выставлять на все префиксы, получаемые от соседа.

Предположим, что мы хотим ходить на определенный префикс через маршрутизатор R2. Ну или в нашем главном случае будет маршрутизатор R4 и маршрутизатор R6. То есть что делать, если мы хотим только ходить на определенные префиксы через R4, а на другие префиксы мы хотим ходить через R6? Что для этого можно сделать? Что для этого можно сделать? Для частоты эксперимента я на R9 подниму сейчас еще один интерфейс. Еще один интерфейс. Интерфейс GII 2.99. С IP адресом 172.17.99. И объявлю эту сеть также BGP. Network.

Готово. Проверяем на амурциатор R1. Show IP или GP. Обращаю ваше внимание, что оба префиксы 172.16.9.0 и 172.17.9.0. Для обоих этих префиксов выставлен вес равный 100. Например, если я хочу ходить на префикс 172.17.9.0 через R6, что я должен сделать? Очевидно, что я должен этому префиксу выдать вес больше, чем 100. Но только этому префиксу. Я не хочу трогать 172.16. Я хочу изменить только для 172.17. Что мы можем сделать? Можно, например, создать префикс list. Префикс list для from R6.

Даже, наверное, лучше назвать его не from R6, а to R6. Потому что пакеты будут ходить в сторону мурциатора R6. Пермит указываем нужный нам префикс. Далее создаем, например, раутмапу, который мы говорим. R6 inbound. Она будет применяться для апдейтов, которые приходят от мурцизатора R6. Говорим, что мы говорим в матч. Мне необходимо назвать матч префикс лист, матч IP. Адрес. Префикс лист. Название префикс листа.

и выставить ему большой вес set вес например 3 девятки далее мне необходимо не забыть теперь я применяю данную раутмапу router bgp 123 для соседа neighbor 10.1.6.6 route map и делаю clear ipgp проверяем show ipgp нет

show run section bgp remote 6 route map rm r6 inbound show ip prefix list 1 entry 172 179 0 show так мы отлавливаем префикс лист номер 6 set clauses вис этом да от матч на 0 пакетов на 0 пакетов мальчик на 0 пакетов

мне нужно некоторое время чтобы проверить возможные ограничения которые присутствуют для матча на префикс листах так прошло некоторое время которое видимо потребовалось бджп бджп протокол для конвергенции я здесь ничего абсолютно не менял как вы видите для префиксы 172 1790 установился вес 3 девятки 3 девять если мы сейчас посмотрим шоу ipb gp 172 1790 то мы увидим что лучшим был был выбор маршрут через и мы встречаем маршрут мультизатор р6 через маршрут мультизатор р6 соответственно если мы теперь сделаем

trace 10 172 172 1699 source lubac 0 не брик да к сожалению меня здесь не будет здесь не будет не будет видны хопы потому что нету нету нигде в таблице маршизации транзитных префиксов на то есть только пинге будет работать даже пинге будет работать почему потому что видимо на удаленной стороне никто ничего не знает конечно о нашем лубики да потому что ура интерфейс лобок 0 я его нигде в

успех не анонсирует но скорее не было не было не было целью нашей задачи шоу опирал бджп как мы видим префикс 17 2 16 9 0 в качестве выходной точки будет использовать мажоризатор 4 172 17 9 0 будет использовать мажоризатор 6