Внезапно я осознал, что вся эта серия как-то затягивается. Пришло время поднапрячься и закончить лабу. Сегодня ковыряюсь с BGP.
Лукавить не буду, топология хоть и типовая, но была слизана с аналогичной в статье на Linkmeup.ru. Однако сами "кейсы" я оттуда брать не буду, придумаю что-нибудь сам основываясь на официальном гайде по CCNP Route.
Напомню, что базовый конфиг уже был настроен в этом посте. Единственное, что я добавил с тех пор - анонс default маршрута. Теперь от B2 и B3 к B4 и B5 соответственно приходит маршрут 0.0.0.0/0. Который последние редистрибуцируют в EIGRP. Естественно применен policy-map, который пропускает только дефолтный маршрут.
Сегодня рассмотрим следующее.
Сегодня рассмотрим следующее.
6. Advanced BGP routing (IPv4)
- AS Path prepend
- Weight
- Local Preference
- MED
- Peer Groups
- Filtering
Но сначала пробежимся по топологии и посмотрим как там оно сошлось.
В этом мне поможет следующая импровизированная табличка.
Для экономии времени не будем бегать по всем девайсам, а глянем только на "наши". Например, на B4.
Волнуют нас выделенные три строчки. Классический вопрос - почему 101 доступен только по одному пути, а 102 по двум?
Тут надо помнить два правила:
Вот пункт номер два и является ответом на вопрос.
От B5 не приходит анонс про 101.0.0.0, потому что у этого B5 лучший маршрут смотрит на B4.
Если взглянуть на, скажем, B2 то можно заметить интересный маршрут, который я отметил ниже.
Маршрут этот неактивный (нет >), что хорошо. Но, если он станет активным, то трафик в 102.0.0.0/20 пойдет через нашу AS64500.
Почему так? Просто потому что B4 анонсирует 101ый префикс и никак его не отфильтровывает.
Трафика этого может быть много, классические "грабли". Вот и предпосылки для фильтрации.
Фильтровать в BGP можно по разному, ниже я попытался наглядно это изобразить.
Ну и начнем прям по порядку.
neighbor 101.10.10.6 soft-reconfiguration inbound
Это позволит нам посмотреть те анонсы, которые приходят от соседа 101.10.10.6 до применения всех фильтров.
Далее создаем ACL и крепим его к определенному соседу с помощью distribute-list.
router bgp 64500
neighbor 101.10.10.5 distribute-list OUR_PREFIXES out
!
ip access-list extended OUR_PREFIXES
permit ip 100.0.0.0 0.0.4.255 any
Деликатно сбрасываем процесс
clear ip bgp 64501 out
Проверяем на удаленной стороне. Вот вам было/стало.
Теперь мы анонсируем только нужные префиксы.
Здесь воспользуемся префикс листом. Порядок действий в целом незамысловат.
router bgp 64500
neighbor 102.10.10.5 prefix-list OUR_PREFIXES out
!
ip prefix-list OUR_PREFIXES seq 5 permit 100.0.0.0/22
clear ip bgp 64502 soft
Данный инструмент позволяет фильтровать анонсы основываясь на том какие AS фигурируют в AS-PATH. Причем мы можем использовать что-то вроде регулярных выражений.
Для примера отфильтруем все анонсы, которые пришли из AS64502 и там же были зарождены. Фильтровать будем на B5.
Сейчас мы получаем следующие анонсы
У нас несколько префиксов, которые в AS-PATH содержат 64502. Два их них были созданы в 64502 и оттуда же и пришли. Это дефотлный маршрут и 102.0.0.0/20.
Создадим as-path ACL ^64502$. Это означает что AS64502 первая в списке и последняя.
router bgp 64500
neighbor 102.10.10.5 filter-list 300 in
!
ip as-path access-list 300 deny ^64502$
Добавляем, само собой, во входящем направлении. Проверяем, нужные (или ненужные...) маршруты исчезли.
Предыдущий фильтр я удалил.
На B4 отфильтруем 0.0.0.0/0 маршрут приходящий от B2. Кстати, можно переиспользовать префикс-лист, который я использую для редистрибуции из BGP в EIGRP.
ip prefix-list DEFAULT seq 5 permit 0.0.0.0/0
!
route-map TEST deny 10
match ip address prefix-list DEFAULT
!
router bgp 64500
neighbor 101.10.10.5 prefix-list TEST in
Рестартуем BGP и видим, что дефолтный маршрут от B2 больше не присутствует в таблице BGP. Однако так же можно увидеть, что анонс приходит, мы просто фильтруем его на выходе.
Официальный гайд предлагает использовать следующие атрибут:
Исходящий трафик
Входящий
router bgp 64500
neighbor 10.0.30.2 weight 65535
Смысла не много, но механизм иллюстрирует.
Более гибкий способ - назначать веса средствами роут-мапов. Реализуем тот же функционал, поднимем вес префикса, который приходит от iBGP соседа.
У нас уже есть ACL, который определяет "наши" префиксы, будем его переиспользовать.
ip access-list extended OUR_PREFIXES
permit ip 100.0.0.0 0.0.4.255 any
!
route-map LOCAL_VIA_IBGP permit 10
match ip address OUR_PREFIXES
set weight 65000
!
route-map LOCAL_VIA_IBGP permit 20
!
router bgp 64500
neighbor 10.0.30.2 route-map LOCAL_VIA_IBGP in
Довольно неожиданно я наступил на "классические" грабли и забыл добавить строку "route-map LOCAL_VIA_IBGP permit 20". Результат - сработал незримый deny all, таки образом я отрубил все префиксы пришедшие от iBGP соседа кроме 100.0.0.0/22.
Немного сэкономлю трафик, результат аналогичный предыдущей картинки.
В таблице маршрутизации уже есть маршрут до 100.0.0.0/22 и он directly connected, а значит AD у него 0. BGP явно проигрывает с AD равным 200 для internal маршрутов. Так что не так-то просто "выстрелить себе в ногу".
Итак, два наших роутера имеют анонсы для 103.0.0.0/21.
Оба маршрутизатора получают по паре анонсов. Один локальный - c local_pref равным 100. Второй от eBGP соседа. По-умолчанию, iBGP сосед передает префиксы с local_pref равным 100 и тут мы видим это поведение.
А вот дальше может возникнуть некая путаница. Почему роутеры выбрали путь через eBGP пиров? Ответ в целом простой, но не совсем. Давайте прям по пунктам.
1. Маршрут до адресов есть.
2. Вес одинаковый
3. Local_pref...он же разный... 100 для iBGP против 0 для eBGP... больше лучше и должен был быть выбран маршрут через iBGP. На самом деле нет. Если идти дальше, то
4. Локального маршрута нет
5. AS-Path одинаковый
6. Origin одинаковый
7. eBGP лучше чем iBGP. Вот тут и принимается решение использовать внешний маршрут.
Так что там с local_pref? В выводе выше видно, что для префикса пришедшего от eBGP local_pref пуст. На самом деле нет...
В официальном гайде ничего явно про этот факт нет, но Cisco говорит про это следующее:
"A path without LOCAL_PREF is considered to have had the value set with the bgp default local-preferencecommand, or to have a value of 100 by default." То есть, если local_pref от пира не пришел, он считается равным значению по умолчанию. А значение ""по умолчанию по умолчанию равно 100. Так что на шаге 3 у нас решения не происходит, потому что local_pref одинаковый и равный 100. Хоть команда явно это и не показывает. Ну что поделать.
Займемся делом. Скажем, я хочу чтобы вся родная ASка знала, что добираться до 103.0.0.0/21 стоит через B4. Это можно сделать отправив всем iBGP пирам префикс 103.0.0.0/21 с local_pref большим чем 100. Например, 150. Делается это обычно сразу же, на входе префикса в AS. То есть, принимаем анонсы от B2 и определенному префиксу поднимаем local_pref.
Все уже привычно.
ip prefix-list 103 seq 5 permit 103.0.0.0/21
!
route-map INCREASE_LP_FOR_103 permit 10
match ip address prefix-list 103
set local-preference 150
!
route-map INCREASE_LP_FOR_103 permit 20
!
router bgp 64500
neighbor 101.10.10.5 route-map INCREASE_LP_FOR_103 in
B4 на все префиксы пришедшие от соседа 101.10.10.5 применит роут-мап, в котором все префиксы пройдут без изменений кроме 103.0.0.0/21, local_pref которого поднимется до значения 150. Теперь все соседи по AS должны получить такой анонс от B4 и уже учитывать значение local_pref. Например, B5.
Модифицируем созданный в прошлом пункте роут-мап таким образом, что B4 добавит к пути ещё одну ASку с помощью set as-path prepend 64500.
route-map INCREASE_LP_FOR_103 permit 10
match ip address prefix-list 103
set local-preference 150
set as-path prepend 64500
!
route-map INCREASE_LP_FOR_103 permit 20
Такой вот модифицированный анонс разойдется по AS, B5 его получит, но все равно предпочтет использовать полученный (но более длинный маршрут) с local_pref 150, нежели короткий, но с local_pref равным 0 (или 100).
На этом управление исходящим трафиком в рамках CCNP Route можно считать законченным.
Для этого ухудшим анонсируемый префикс от B5 к B3. Сейчас трафик ходит напрямую, конечно же.
Роут-мап практически аналогичный предыдущему примеру, только применен в другую сторону - out. Ну и свою AS придется добавить два раза, чтобы маршрут стал хуже, чем альтернативный.
router bgp 64500
neighbor 102.10.10.5 route-map AS_PREPEND out
!
ip prefix-list OUR_PREFIXES seq 5 permit 100.0.0.0/22
!
route-map AS_PREPEND permit 10
match ip address prefix-list OUR_PREFIXES
set as-path prepend 64500 64500
!
route-map AS_PREPEND permit 20
Мы ожидаем, что маршрут через 102.10.10.6 получит as_path 64500, 64500, 64500. Он станет короче чем маршрут через 101.0.0.1 (64501, 64500).
Почти так и получится.
Только теперь пришел ещё анонс аж через три ASки. Это самый длинный путь. Почему так? Дело в том, что такие вот манипуляции затрагивают все ноды в глобальной сети.
Если текстом, то:
1. У B2 лучший маршрут смотрит на B4. Самый короткий as_path = 64500
2. B4 анонсирует префикс в сторону B3 c as_path = 64501 64500.
3. B4 анонсирует такой же префикс с такоим же as_path в сторону B1. Этот маршрут становится лучшим на B1.
4. B1 анонсирует свой лучший маршрут в сторону B3 с as_path = 64503 64501 64500
Но механизм понятен. Уберем препенд перед следующим шагом.
Например, сделаем так, чтобы приоритетным считался путь к B5. Последний будет анонсировать MED = 20, а вот B4 будет передавать значение меньше MED =10.
Конфиги на B4 и B5 будут немного разные, потому как для первого устройства переиспользуем ACL,а для второго prefix-list.
router bgp 64500
neighbor 101.10.10.5 route-map MED10 out
!
route-map MED10 permit 10
match ip address OUR_PREFIXES
set metric 10
!
route-map MED10 permit 20
router bgp 64500
neighbor 102.10.10.5 route-map MED20 out
!
route-map MED20 permit 10
match ip address prefix-list OUR_PREFIXES
set metric 20
!
route-map MED20 permit 20
Однако если посмотреть на "ребят сверху", то никаких изменений мы не увидим. Потому что по умолчанию атрибут MED не участвует в выборе маршрутов. Нужно включить этот функционал отдельно командой "bgp always-compare-med". Однако и в таком случае особо ничего интересного не произойдет. Потому как нет того устройства, куда приходят два одинаковых префикса с разными значениями MED. Дела в том, что MED атрибут довольно слабый и сейчас решение происходит задолго до него.
Сделаем B4 dual-homed маршрутизатором, подключим его в B3 отдельным линком, после чего настроим соседство. Все это мы уже проходили.
На B4:
interface Ethernet0/3
ip address 102.10.10.9 255.255.255.252
!
router bgp 64502
neighbor 102.10.10.10 remote-as 64500
neighbor 102.10.10.10 default-originate
На B3
interface Ethernet0/3
ip address 102.10.10.10 255.255.255.252
!
router bgp 64500
neighbor 102.10.10.9 remote-as 64502
neighbor 102.10.10.9 distribute-list OUR_PREFIXES out
Теперь можно посмотреть на B3. Вот теперь все по-честному. К B3 пришло два анонса с разным MED и выбрал он наименьший.
6. Advanced BGP routing (IPv4)
- AS Path prepend
- Weight
- Local Preference
- MED
- Peer Groups
- Filtering
Stay tuned.
Тут надо помнить два правила:
- BGP рассказывает соседям только про лучший маршрут.
- iBGP роутер не передает iBGP маршруты своим iBGP соседям.
Вот пункт номер два и является ответом на вопрос.
От B5 не приходит анонс про 101.0.0.0, потому что у этого B5 лучший маршрут смотрит на B4.
Если взглянуть на, скажем, B2 то можно заметить интересный маршрут, который я отметил ниже.
Маршрут этот неактивный (нет >), что хорошо. Но, если он станет активным, то трафик в 102.0.0.0/20 пойдет через нашу AS64500.
Почему так? Просто потому что B4 анонсирует 101ый префикс и никак его не отфильтровывает.
Трафика этого может быть много, классические "грабли". Вот и предпосылки для фильтрации.
Фильтровать в BGP можно по разному, ниже я попытался наглядно это изобразить.
Ну и начнем прям по порядку.
Фильрация
distribute-list
Для начала включим возможность просматривания входящих анонсов на B2.neighbor 101.10.10.6 soft-reconfiguration inbound
Это позволит нам посмотреть те анонсы, которые приходят от соседа 101.10.10.6 до применения всех фильтров.
Далее создаем ACL и крепим его к определенному соседу с помощью distribute-list.
router bgp 64500
neighbor 101.10.10.5 distribute-list OUR_PREFIXES out
!
ip access-list extended OUR_PREFIXES
permit ip 100.0.0.0 0.0.4.255 any
Деликатно сбрасываем процесс
clear ip bgp 64501 out
Проверяем на удаленной стороне. Вот вам было/стало.
Теперь мы анонсируем только нужные префиксы.
prefix-list
Выходов их AS у нас два, так что B3 все ещё получает "транзитный маршрут".Здесь воспользуемся префикс листом. Порядок действий в целом незамысловат.
router bgp 64500
neighbor 102.10.10.5 prefix-list OUR_PREFIXES out
!
ip prefix-list OUR_PREFIXES seq 5 permit 100.0.0.0/22
clear ip bgp 64502 soft
as-path access-list
Штука крутая, но почему-то заслужившая только мимолетного упоминания в официальном гайде.Данный инструмент позволяет фильтровать анонсы основываясь на том какие AS фигурируют в AS-PATH. Причем мы можем использовать что-то вроде регулярных выражений.
Для примера отфильтруем все анонсы, которые пришли из AS64502 и там же были зарождены. Фильтровать будем на B5.
Сейчас мы получаем следующие анонсы
У нас несколько префиксов, которые в AS-PATH содержат 64502. Два их них были созданы в 64502 и оттуда же и пришли. Это дефотлный маршрут и 102.0.0.0/20.
Создадим as-path ACL ^64502$. Это означает что AS64502 первая в списке и последняя.
router bgp 64500
neighbor 102.10.10.5 filter-list 300 in
!
ip as-path access-list 300 deny ^64502$
Добавляем, само собой, во входящем направлении. Проверяем, нужные (или ненужные...) маршруты исчезли.
route-map
Самый продвинутый инструмент, который можно использовать не столько для фильтрования, сколько для управления маршрутами вообще. Для фильтрации мы будем использовать только match и не будем использовать set. Хотя это конечно же не правило, безусловно можно как-то модифицировать анонс.Предыдущий фильтр я удалил.
На B4 отфильтруем 0.0.0.0/0 маршрут приходящий от B2. Кстати, можно переиспользовать префикс-лист, который я использую для редистрибуции из BGP в EIGRP.
ip prefix-list DEFAULT seq 5 permit 0.0.0.0/0
!
route-map TEST deny 10
match ip address prefix-list DEFAULT
!
router bgp 64500
neighbor 101.10.10.5 prefix-list TEST in
Рестартуем BGP и видим, что дефолтный маршрут от B2 больше не присутствует в таблице BGP. Однако так же можно увидеть, что анонс приходит, мы просто фильтруем его на выходе.
Управление трафиком
По сути фильтрование маршрутов уже можно назвать управлением трафика, но мы коснемся более гибких инструментов. Разделить всю тему можно на два больших раздела - управление исходящим трафиком (относительно легко) и управление входящим трафиком (уже интереснее).Официальный гайд предлагает использовать следующие атрибут:
Исходящий трафик
- Weight
- Local_Pref
- AS_Path
Входящий
- MED
- AS_Path
Outbound
weight
Проприетарный цисковский механизм, у других вендоров встречаются аналоги. Удобен для управления входящим трафиком в пределах одного роутера. Значение по умолчанию - 0, для локальных маршрутов - 32768. Таким образом роутер всегда будет предпочитать локальный маршрут. Управлять можно через роут-мап или указав напрямую на соседе.
Давайте немного пошалим и заставим B4 слать трафик не на свой локальный маршрут, а соседу.
router bgp 64500
neighbor 10.0.30.2 weight 65535
Смысла не много, но механизм иллюстрирует.
Более гибкий способ - назначать веса средствами роут-мапов. Реализуем тот же функционал, поднимем вес префикса, который приходит от iBGP соседа.
У нас уже есть ACL, который определяет "наши" префиксы, будем его переиспользовать.
ip access-list extended OUR_PREFIXES
permit ip 100.0.0.0 0.0.4.255 any
!
route-map LOCAL_VIA_IBGP permit 10
match ip address OUR_PREFIXES
set weight 65000
!
route-map LOCAL_VIA_IBGP permit 20
!
router bgp 64500
neighbor 10.0.30.2 route-map LOCAL_VIA_IBGP in
Довольно неожиданно я наступил на "классические" грабли и забыл добавить строку "route-map LOCAL_VIA_IBGP permit 20". Результат - сработал незримый deny all, таки образом я отрубил все префиксы пришедшие от iBGP соседа кроме 100.0.0.0/22.
Немного сэкономлю трафик, результат аналогичный предыдущей картинки.
RIB-failure
Возможно вы заметили, что на картинках вместо звездочек (*) стоит литера r. Это значит, что маршрут не валиден и произошел так называемый RIB-Failure. Это означает, что маршрут не был добавлен в таблицу маршрутизации. Почему? Можно спросить у роутера. |
| Да-да... шрифт стал меньше... |
В таблице маршрутизации уже есть маршрут до 100.0.0.0/22 и он directly connected, а значит AD у него 0. BGP явно проигрывает с AD равным 200 для internal маршрутов. Так что не так-то просто "выстрелить себе в ногу".
local_pref
Тут немного интереснее. Во-первых, это уже стандартный атрибут, а, во-вторых, он передается внутри одной автономной системы.Итак, два наших роутера имеют анонсы для 103.0.0.0/21.
Оба маршрутизатора получают по паре анонсов. Один локальный - c local_pref равным 100. Второй от eBGP соседа. По-умолчанию, iBGP сосед передает префиксы с local_pref равным 100 и тут мы видим это поведение.
А вот дальше может возникнуть некая путаница. Почему роутеры выбрали путь через eBGP пиров? Ответ в целом простой, но не совсем. Давайте прям по пунктам.
1. Маршрут до адресов есть.
2. Вес одинаковый
3. Local_pref...он же разный... 100 для iBGP против 0 для eBGP... больше лучше и должен был быть выбран маршрут через iBGP. На самом деле нет. Если идти дальше, то
4. Локального маршрута нет
5. AS-Path одинаковый
6. Origin одинаковый
7. eBGP лучше чем iBGP. Вот тут и принимается решение использовать внешний маршрут.
Так что там с local_pref? В выводе выше видно, что для префикса пришедшего от eBGP local_pref пуст. На самом деле нет...
В официальном гайде ничего явно про этот факт нет, но Cisco говорит про это следующее:
"A path without LOCAL_PREF is considered to have had the value set with the bgp default local-preferencecommand, or to have a value of 100 by default." То есть, если local_pref от пира не пришел, он считается равным значению по умолчанию. А значение ""по умолчанию по умолчанию равно 100. Так что на шаге 3 у нас решения не происходит, потому что local_pref одинаковый и равный 100. Хоть команда явно это и не показывает. Ну что поделать.
Займемся делом. Скажем, я хочу чтобы вся родная ASка знала, что добираться до 103.0.0.0/21 стоит через B4. Это можно сделать отправив всем iBGP пирам префикс 103.0.0.0/21 с local_pref большим чем 100. Например, 150. Делается это обычно сразу же, на входе префикса в AS. То есть, принимаем анонсы от B2 и определенному префиксу поднимаем local_pref.
Все уже привычно.
ip prefix-list 103 seq 5 permit 103.0.0.0/21
!
route-map INCREASE_LP_FOR_103 permit 10
match ip address prefix-list 103
set local-preference 150
!
route-map INCREASE_LP_FOR_103 permit 20
!
router bgp 64500
neighbor 101.10.10.5 route-map INCREASE_LP_FOR_103 in
B4 на все префиксы пришедшие от соседа 101.10.10.5 применит роут-мап, в котором все префиксы пройдут без изменений кроме 103.0.0.0/21, local_pref которого поднимется до значения 150. Теперь все соседи по AS должны получить такой анонс от B4 и уже учитывать значение local_pref. Например, B5.
as-path
Довольно распространенный способ "ухудшения" префикса. Рассмотрим способ на том же примеры, заодно продемонстрируем, что атрибут as_path имеет далеко не самый высший приоритет и local_pref его "победит".Модифицируем созданный в прошлом пункте роут-мап таким образом, что B4 добавит к пути ещё одну ASку с помощью set as-path prepend 64500.
route-map INCREASE_LP_FOR_103 permit 10
match ip address prefix-list 103
set local-preference 150
set as-path prepend 64500
!
route-map INCREASE_LP_FOR_103 permit 20
Такой вот модифицированный анонс разойдется по AS, B5 его получит, но все равно предпочтет использовать полученный (но более длинный маршрут) с local_pref 150, нежели короткий, но с local_pref равным 0 (или 100).
На этом управление исходящим трафиком в рамках CCNP Route можно считать законченным.
Inbound
as-path
Теперь можно применить ухудшение as_path только в другом направлении. Допустим, нам интересно, чтобы больше трафика на наш префикс 100.0.0.0/22 приходило в B4. Трафик этого префикса покидает нашу AS через этот роутер, так пусть и приходит на него. Довольно логично.Для этого ухудшим анонсируемый префикс от B5 к B3. Сейчас трафик ходит напрямую, конечно же.
Роут-мап практически аналогичный предыдущему примеру, только применен в другую сторону - out. Ну и свою AS придется добавить два раза, чтобы маршрут стал хуже, чем альтернативный.
router bgp 64500
neighbor 102.10.10.5 route-map AS_PREPEND out
!
ip prefix-list OUR_PREFIXES seq 5 permit 100.0.0.0/22
!
route-map AS_PREPEND permit 10
match ip address prefix-list OUR_PREFIXES
set as-path prepend 64500 64500
!
route-map AS_PREPEND permit 20
Мы ожидаем, что маршрут через 102.10.10.6 получит as_path 64500, 64500, 64500. Он станет короче чем маршрут через 101.0.0.1 (64501, 64500).
Почти так и получится.
Только теперь пришел ещё анонс аж через три ASки. Это самый длинный путь. Почему так? Дело в том, что такие вот манипуляции затрагивают все ноды в глобальной сети.
Если текстом, то:
1. У B2 лучший маршрут смотрит на B4. Самый короткий as_path = 64500
2. B4 анонсирует префикс в сторону B3 c as_path = 64501 64500.
3. B4 анонсирует такой же префикс с такоим же as_path в сторону B1. Этот маршрут становится лучшим на B1.
4. B1 анонсирует свой лучший маршрут в сторону B3 с as_path = 64503 64501 64500
Но механизм понятен. Уберем препенд перед следующим шагом.
MED
Этот атрибут позволяет "промаркировать" входы в ASку. Вышестоящие ASки смогут на основе MED определить куда приоритетное передавать трафик. Нужно помнить, что в случае MED - чем меньше тем лучше. По умолчанию равен 0.Например, сделаем так, чтобы приоритетным считался путь к B5. Последний будет анонсировать MED = 20, а вот B4 будет передавать значение меньше MED =10.
Конфиги на B4 и B5 будут немного разные, потому как для первого устройства переиспользуем ACL,а для второго prefix-list.
router bgp 64500
neighbor 101.10.10.5 route-map MED10 out
!
route-map MED10 permit 10
match ip address OUR_PREFIXES
set metric 10
!
route-map MED10 permit 20
router bgp 64500
neighbor 102.10.10.5 route-map MED20 out
!
route-map MED20 permit 10
match ip address prefix-list OUR_PREFIXES
set metric 20
!
route-map MED20 permit 20
Однако если посмотреть на "ребят сверху", то никаких изменений мы не увидим. Потому что по умолчанию атрибут MED не участвует в выборе маршрутов. Нужно включить этот функционал отдельно командой "bgp always-compare-med". Однако и в таком случае особо ничего интересного не произойдет. Потому как нет того устройства, куда приходят два одинаковых префикса с разными значениями MED. Дела в том, что MED атрибут довольно слабый и сейчас решение происходит задолго до него.
Сделаем B4 dual-homed маршрутизатором, подключим его в B3 отдельным линком, после чего настроим соседство. Все это мы уже проходили.
На B4:
interface Ethernet0/3
ip address 102.10.10.9 255.255.255.252
!
router bgp 64502
neighbor 102.10.10.10 remote-as 64500
neighbor 102.10.10.10 default-originate
На B3
interface Ethernet0/3
ip address 102.10.10.10 255.255.255.252
!
router bgp 64500
neighbor 102.10.10.9 remote-as 64502
neighbor 102.10.10.9 distribute-list OUR_PREFIXES out
Теперь можно посмотреть на B3. Вот теперь все по-честному. К B3 пришло два анонса с разным MED и выбрал он наименьший.
- AS Path prepend
- Weight
- Local Preference
- MED
- Peer Groups
- Filtering
P.S.
Возможно кто-то заметил, что скриншоты консоли выглядят несколько иначе. А все потому, что я начал использовать очень крутую штуку, которая называется Guacamole. Это по сути некий веб клиент, который поддеривает все нужные протоколы, такие как telnet, ssh, rdp и vnc. Очень удобно. Ещё пару лет назад, коллега с работы мне её показывал (привет, коллега, если читаешь), но всю мощь я заценил только сейчас.
P.P.S.
В планах сдать Route до нового года. Довольно амбициозно, учитывая домашние дела и новую работу. Боюсь что все забуду, если отложить на следующий год. Потом планирую осветить ряд тем с новой работы, такие как load balancing и security. Ну и вообще тему ЦОДов, раз уж я в неё влип. )Stay tuned.
Комментариев нет:
Отправить комментарий