Local Preference: управление исходящим трафиком

Следующим атрибутом, который нам необходимо рассмотреть, является атрибут local preference. Давайте кратко освежим, что мы настроили на текущий момент. На нашей типологии присутствует мультизатор R9, у которого есть подсеть 172.17. 172.17. 192.17.17. Этот префикс отвертается в сторону мультизатора R6, далее в сторону мультизатора R1. Также этот префикс отвертается в сторону мультизатора R8, далее на route reflector R7. Оттуда отражается на мультизатор R4, на мультизатор R5. После этого мартизатор R5 отдает префикс в сторону мартизатора R2, и мартизатор R4 отдает префикс в сторону мартизатора R1.

Давайте запустим трассировку с мартизаторов R1 и R2, чтобы посмотреть, как ходят пакеты. TraceRound 172, 1799, source lowback 0, виберек. Обратите внимание, что с мартизатора R1 пакеты бегут через мартизатор R6 и далее через мартизатор R9. То есть с точки зрения мартизатора R1 предпочтительным путь является путь через автономную систему номер 6. С точки зрения мартизатора R2 является путь через мартизатор R5, R7, R8, R9. мартизатор R2, пакет бежит вот таким вот путем.

Что происходит далее? Что происходит далее? Мартизатор R1 передает свой префикс, Преодет префикс получен от мартизатора R6 в сторону раут рефлектора R2. Далее мартизатор R2 сравнивает желтый апдейт и красный апдейт и высылает лучший апдейт в сторону мартизатора R3. Давайте посмотрим, что происходит на мартизаторе R3. Show IPBGP 172.17.9.0. Как вы видите, мы видим только один апдейт, который к нам пришел от мартизатора R2. Если мы запустим Trace 172.17. Единственное, что чтобы запустить Trace loopback,

мне необходимо будет добавить еще свой loopback в BGP-таблицу. Раутер BGP 123, Network 3333. Давай 5255, давай 5255. И теперь мы можем запускать трассу. 82.17.99. Source loopback 0. Как вы видите, пакет попадает на мартизатор R2. На мартизатор R2. А дальше следует по пути, который уже был у нас ранее. То есть мартизатор R2, мартизатор R5, R7, R8 и R9. То есть, по сути, у нас на самом деле отсутствует некая согласованная политика мартизации, например, на префикс 172.17.9 внутри нашей автономной системы. Почему? Потому что каждый мартизатор решает, куда ему мартизировать трафик самостоятельно. Так вот, чтобы как-то согласовать BGP мартизацию в рамках одной автономной системы,

был придуман атрибут Local Preference. Был придуман атрибут Local Preference. Local Preference, он очень хорош, когда у вас есть мультихоминг-подключение, как вот на нашей картинке, когда автономная система 123 подключается несколькими маршрутизаторами к внешним автономным системам. Так вот, что Local Preference нам позволяет сделать? Что нам Local Preference позволяет сделать? Предположим, что прилетает некий префикс X от маршрутизатора R4 и от маршрутизатора R5. И мы хотим, чтобы все маршрутизаторы в нашей сети использовали в качестве точки выхода канал между маршрутизаторами R1 и R4. То есть, например, чтобы маршрутизатор R3 как-то передавал трафик вот сюда,

чтобы трафик от маршрутизатора R2 двигался также через вот этот канал. Как это сделать? Как это сделать? Обратите внимание, если я сейчас на маршрутизаторе R3 выдам команду show.ipbgp 172.17.9.0, то вы увидите, что у атрибута Local Preference стоит значение по умолчанию равное 100. Так вот, если мы вернемся мысленно к алгоритму BGP Best Path Selection, то мы увидим, что Local Preference – это атрибут, который проверяется сразу после веса. То есть, чем Local Preference выше, тем маршрут считается более предпочтительным. Что нам это дает? Что нам это дает? Более того, в отличие от веса, атрибут Local Preference является, так называемым,

транзитивным. То есть, он передается между маршрутизаторами. Однако, он передается только внутри одной автономной системы. То есть, это атрибут, который проверяется только по IBGP-сессиям. По IBGP-сессиям Local Preference не передается. Соответственно, если маршрутизатор должен передать апдейт, то есть, переложить апдейт с IBGP на IBGP, то при передаче на IBGP апдейт из апдейта атрибут Local Preference удаляется. Как же решить нашу задачу? Как же решить нашу задачу? Мы можем сделать вот что. Например, когда маршрутизатор R1 будет отдавать префикс, который он получил от маршрутизатора R4, когда он его будет передавать в сторону R2, он может его передать со значением Local Preference, равным, например, 200. Соответственно, на маршрутизатор R2, по сути, прилетают два префикса от R1 и от R5.

Но от R5 мы выставляем на приеме значение Local Preference, равное 100, и получаем от R1 апдейт, в котором атрибут Local Preference равный 200. То есть, но выигрывает в этом случае маршрут, полученный от маршрутизатора R1, то есть он будет заинсталлирован в IBGP табличку как BEST, и дальше будет передан в сторону маршрутизатора R3. Также мы здесь увидим маршрут с Local Preference равным 200. Равным 200. Итак, как мы это можем сделать? Давайте вернемся к конфигурации маршрутизатора R1, show run section BGP.

Хорошо. Я хочу сейчас удалить, наверное, конфигурацию с весами и конфигурацию с route map. Делаем clear IPBGP. Local Preference точно так же, как вес, если не ошибаюсь, его можно настроить для конкретного нейбора. Для начала давайте посмотрим нашу табличку show IPBGP. В частности, для префикса 172.16.9.0. Как вы видите, мы получаем префикс 172.16.9.0 от трех соседей. От трех соседей. От трех соседей. Получаем его от маршрутизатора R2.

Получаем его от маршрутизатора R4. И мы его получаем от маршрутизатора R6. Например, мы хотим, чтобы предпочтительный путь был через маршрутизатор R4. Что мы можем сделать? Говорим router BGP 1.2.3, neighbor 10.1.4.4. Можно ли назначить Local Preference на соседа? Как вы видите, команды Local Preference здесь нет. То есть на соседа он не назначается. Поэтому что мы можем сделать? Мы можем сконфигурировать, например, route map. Применить его к соседу. И после этого route map. Применить его к соседу в направлении. Давайте сделаем. Для начала мы создадим IP префикс-лист, в котором мы будем отлавливать все префиксы.

Будет 00.LE32. Забыл. Permit IP. Permit. Просто permit. Далее создаем route map. Permit. Забыл. Забыл. Морциатор R4. In. 1.10. Match. IP. Адрес. Префикс-лист. Название нашего префикс-листа. И выставляем set. Local Preference. BGP Local Preference Past Attribute. Set Local Preference. То есть это просто число в диапазоне от миллиард до вот такого большого значения. Давайте выставим пример set Local Preference 999.

После этого нам необходимо будет применить нашу маршрутную карту для соседа Neighbor 10.1.4.4. Route Map In. После этого сделаем апдейт. Получим заново BGP апдейты от всех своих соседей. Так что получается. Show IP BGP. В частности, меня будет интересовать префикс 172.16.9.0. Show IP BGP 172.16.9.0. Обратите внимание, что маршрут выбран BGP. Но Local Preference стоит пока 100.

Обновилось. Show IP BGP. Show IP BGP. Итак, 172.16.9.0. Как видите, мы получаем его теперь только от маршрутизатора R4 и от маршрутизатора R6. Мы его больше не получаем от маршрутизатора R2. Потому что маршрутизатор R2 сейчас будет использовать нас в качестве выходной точки. Что у нас получается? Для префикса, который получен от маршрутизатора R4, у нас выставлен Local Preference 9.9.9. Для апдейта, который мы получили от маршрутизатора R6, выставлен Local Preference значением по умолчанию. То есть это значение 100. Если посмотрим, show IP BGP 172.16.9.0. То есть это явно указано. От маршрутизатора R4, Local Preference 3.9.

От маршрутизатора R6, Local Preference 100. Соответственно, маршрут с наибольшим Local Preference выбран как лучший. То есть у нас получается такой нюанс, что мы выбираем маршрут от маршрута R4. И выставляем ему Set Local Preference 3.9. Далее мы передаем этот маршрут всем нашим IBGP соседям. В качестве IBGP соседей у нас выступает только маршрута R2. Поскольку он является рут рефлектором. Мы переходим на маршрута R2. Смотрим show IPBGP 172.16.9.0. И видим, что от рут рефлектора клиента, то есть от маршрута R1, мы получили маршрут с Local Preference равным 3.9.

И выбрали этот маршрут лучшим. То есть этот маршрут теперь выигрывает у маршрута по сравнению с маршрутизатором R5. И дальше мы передаем этот маршрут на наши IBGP пиры. В частности, маршрута R2 передаст этот апдейт в сторону маршрутизатора R3. Давайте посмотрим на маршрута R3. Show IPBGP 172.16.9.0. Как видите, маршрута R3 знает маршрут, который был получен от маршрута R2. Вот маршрута R2. Оригинатором выступает маршрутизатор R1. И Local Preference 3.9.

Соответственно, если мы сейчас с вами сделаем trace, обратите внимание, как у нас поменялся trace. Если в первом случае мы ходили через маршрутизатор R2, R5, R7, R8, R9, то теперь наша трасса с маршрутизатора R3 пролегает через путь R1, R4, R7, R8 и R9. Таким образом, Local Preference де-факто является таким атрибутом, с помощью которого вы можете легко выбирать исходящую точку из вашей автономной системы. То есть это, опять же, атрибут, который предназначен для того, чтобы определять, каким путем будет выходить трафик из вашей автономной системы.

Поскольку атрибут является хорошо известным и транзитивным, то он поддерживается абсолютно всеми вендорами. То есть неважно, у вас пиринг Cisco Cisco или Cisco Juniper, Cisco Huawei. Это абсолютно неважно. Главное не забывать, что Local Preference живет только внутри одной автономной системы. Давайте, кстати, в этом и убедимся, что он живет только внутри одной автономной системы. Как мы можем этого достичь? Смотрите, поскольку на маршрутизаторе маршрутизатор R1 выбирает лучшим префикс от маршрутизатора R4, то он его будет отдавать в сторону маршрутизатора R6. Давайте посмотрим на R6 в бюджетной таблице. BGP 172.16.9.0. Обратите внимание, действительно, на маршрутизаторе R6 есть префикс, который получен от маршрутизатора R1,

то есть, в частности, от IP ADS 10.1.6.1. Но значение Local Preference уже не 999, а только 100. Почему? Потому что, когда маршрутизатор R1 передает апдейт в сторону IBGP соседа, в сторону IBGP соседа, то он удаляет Local Preference из этого апдейта. То есть, No Local Preference. Продолжение следует...