MED: выбор точки входа в автономную систему
О чём этот урок
Атрибут MED и его роль в выборе точки входа в автономную систему.
Ключевые выводы
- MED — опциональный атрибут; чем меньше значение, тем предпочтительнее маршрут.
- По умолчанию MED сравнивается только для маршрутов, полученных из одной и той же AS.
- При использовании redistribute MED копируется из IGP-метрики исходного протокола; при network — равен 0.
- Команда bgp always-compare-med включает сравнение MED для маршрутов из разных AS.
- MED передаётся по eBGP, но обычно не транзитируется далее — действует только между непосредственными соседями.
Проверьте себя
Как интерпретируется значение MED при сравнении маршрутов?
В каком случае по умолчанию сравнивается MED?
Какое значение MED получает маршрут при использовании network?
Какая команда включает сравнение MED для маршрутов из разных AS?
Транзитируется ли MED далее после получения от eBGP-соседа?
Связанные уроки
Смотрите также
MED и Weight — атрибуты BGP Best Path Selection; Weight работает локально, MED передаётся соседям. Оба управляют выбором пути, но в разных сценариях
Local Preference и MED — зеркальные инструменты: LP управляет исходящим трафиком (выбор выходного пути), MED влияет на входящий трафик от конкретного соседа
Транскрипция
Если при сравнении двух префиксов оказывается, что веса одинаковые, local preference одинаковые, длина ASPT одинаковая, в следующем в дело для проверки вступает параметр, который называется multi-exit discriminator. По сути, это аналог метрики в HB протоколе, например, в том же OSPF. Обычно метод используется в тех случаях, когда вам необходимо сравнить два апдейта, которые приходят из одной и той же автономной системы. Предположим, что у нас есть вот такое connectivity. Скажем, маркетра R1 имеет точки подключения к маркетра R4 и R5.
И с точки зрения маркетра R1 нужно выбрать точку выхода, либо R4 или R5, но мы хотим использовать мет для этого. Прежде всего, нужно понимать, что метод может либо присутствовать в BGP апдейте, либо отсутствовать. То есть это на самом деле опциональный атрибут, который не обязан присутствовать в апдейте. То есть это исключительно прерогатива того маркетизатора, кто генерирует данный апдейт. Вкладывает туда метод или нет. В Cisco IOS по дефолту для сетей, которые вы оригинруете с помощью команды network, метод выставляется равным нулю. То есть если network, то метод равно нулю. Если мы используем регистрибьюцию, то берется метод, он копируется из метрики.
Копируется из метрики. Давайте посмотрим, как это работает. Что я сейчас делаю? Что я сейчас делаю? На амортизаторе R8 я создам либо создам, либо у нас уже должен быть интерфейс с адресом 172.16.8.0. Я просто проанонсирую этот префикс в OSPF. А на амортизаторе R5 я сделаю редистрибьюцию из OSPF в BGP. Я сделаю эту редистрибьюцию на амортизаторе R5 и сделаю ту же самую редистрибьюцию на R4. На амортизаторе R8. Проверяем show IP-интерфейс brief. Да, у нас уже есть интерфейс G2.8.
Он пока не анонсируется в OSPF. Давайте добавим вот туда. IP-OSPF 1, area 0. Area 0. На амортизаторах R4 и R5 проверим, что у нас появилась connectivity. Show IP-Route 172.16.8.0. Есть маршрут на амортизаторе R4. И то же самое, я думаю, должно быть на амортизаторе R5. Обратите внимание, что метрика на амортизаторе R5 равна 3. И на амортизаторе R4 также равна 3. Чтобы сделать пути немножко разными, немножко разными, чтобы понять, как метод действительно работает, я увеличу, например, стоимость вот этого линка, скажем, до значения 90. До значения 90. Для этого на амортизаторе R5 я скажу interface-gid 2.57, IP, OSPF, cost, cost 90.
После этого show IP-Route мне покажет, что метрика стала равна 92. 92. Хорошо. Теперь я сделаю редистрибьюцию OSPF сетей в BGP. В частности, для начала я создам префикс list, который будет отплавливать префикс мурсатора R8. Скажу permit 172.16.8.0.24. Создаем раутмапу, назову ее OSPF to BGP. Скажу match.ip. Адрес. Префикс. Имя вот этого префикс листа. Зайду в раутер BGP 4578 и скажу redistribute OSPF1 раутмапа.
Хорошо. Окей. Это сделано. То же самое сделаю на амортизаторе R4. Show run section. R4. Раутмап. Раутер BGP 4578. Окей. И IP префикс лист. Упс. IP префикс лист. Permit. 172.16.8.0.24. Сделано. Итак, проверяем. На амортизаторе R5. Show IP BGP для сети 172.16.8.0. В частности, у меня есть апдейт, который был сгенерирован амортизатором R5 самостоятельно.
Origin type is incomplete. То есть как раз он говорит нам о том, что данный префикс был внесен в BGP таблицу посредством амортизатора. Амортизатором дистрибьюции. И метрика равна 92. Метрика равна 92. На амортизаторе, давайте посмотрим то же самое, на амортизаторе R4. На амортизаторе R4. У нас также появился локальный префикс. Единственное, что пока вопрос, почему мы имеем еще отмортизатора R7. Вероятно, что амортизатор R8 анонсит эту сеть BGP. Да, давайте ее уберем из анонсов. Чтобы единой точкой появления этого префикса были наши граничные амортизаторы.
Это R4 и амортизаторы R5. Хорошо. Теперь мы должны убедиться в том, что данные префиксы передаются в сторону бордеров R1 и R2. Проверяем show ipvGP 172.16.8.0. Как вы видите, муршизатор R1 получил префикс от муршизатора только от муршизатора R4. Единственное, здесь еще есть localpref. Localpref, который выставлен на муршизатор R2. Он с прошлого примера. show run section BGP. Нужно убрать эту раутмапу, поскольку эта раутмапа выставляет localpreference в большое значение. Это все придет к тому, что у нас меды сравниваться не будут.
Проверяем show ipvGP 172.16.8.0. Так, метрика 3, localpreference 9.9.9. Сейчас, я думаю, мне потребуется некоторое время для обработки. Отлично. Localpreference 100. И то же самое мы должны проверить на муршизаторе R2. Хорошо. Хорошо. Как видите, в данном случае на муршизаторе R2 сравниваются два маршрута, полученные от муршизатора R5 и от муршизатора R1. Давайте посмотрим на ситуацию с точки зрения раутера R2. Что у нас происходит?
Муршизатор R5 передает апдейт в сторону муршизатора R2. Атрибута spas выставляется равным 45.78. Далее. Localpreference здесь нет. Мет выставляется равным 92. Далее. Также апдейт передает R4 в сторону муршизатора R1. Выставляет aspass равный 45.78. Мет выставляет равный 3. Далее. Муршизатор R3 передает апдейт в сторону муршизатора R2. Aspass остается 45.78. И мет равно 3. Муршизатор R2 происходит сравнение двух этих апдейтов. Сравниваются веса.
Первым шагом сравниваются веса. Они одинаковые. Вторым шагом сравниваются localpreference. Они тоже одинаковые. И они равны 100. Третьим шагом сравниваются длина aspass. Она одинаковая. Одинаковая. После этого сравнивается type of origin. То есть сравнивается origin type. origin type. В обоих случаях префикс был получен посредством редистрибуции. И там, и там. Это incomplete. То есть одинаковые. И после этого сравнивается уже мет. В частности сравниваются два числа. 3 и 92. Поскольку 3 меньше, чем 92. то маршрут, который был получен от маршрутизатора R1 для маршрутизатора R2 должен быть выбран наилучшим.
Так ли это? Да. Как мы видим, маршрут от маршрутизатора R1 выбран лучшим с метрикой 3. На вопрос, часто ли метр используется в жизни. Наверное, скорее нет, чем да. Бывают какие-то экзотические случаи, когда заказчик хочет использовать именно метр, а не local preference. Единственное, что метр иногда использовать хорошо внутри вашей автономной системы. Почему? В каких-то ситуациях? Когда у вас одинаковые все параметры, то по сути этот метр характеризует что? А почему у нас взялся? Откуда у нас делись метрика 3 и метрика 92?
Еще раз. По сути своей метрика 92 это IGP стоимость. showIP route 172.16.8.8. То есть это то, что у нас было. Та метрика, которая с точки зрения маршрутатора R5, метрика равна 92, чтобы достичь префикса 172.16.8.0. Когда этот префикс регистрибутируется из OSPF в BGP, то мет копируется из метрики. мет копируется из метрики. При желании вы можете мет сравнивать не только для префиксов, которые изначально пришли от одной и той же автономной системы. В принципе мет можно сравнивать абсолютно для всех апдейтов.
для всех апдейтов. Для этого в BGP присутствует команда router.bgp.1.3. BGP. BGP.always.com.p.net. wertapp. BGP. Появляется. Нужно ли ее использовать в реальной жизни? Я вам скажу честно, для меня вопрос открытый, и ответа у меня будет скорее нет, чем да.