Условное анонсирование префиксов

Следующим вопросом, который я хотел бы рассмотреть на сегодняшнем занятии, является объявление префиксов BGP по требованию. Или, иными словами, генерация или объявление префиксов BGP при условии выполнения каких-то требований. Например, мы хотим сделать так, чтобы марштизатор R1 объявлял некий префикс в сторону марштизатора R4 и в сторону марштизатора R6, префикс, например, 200, 0, 0, 3, только при условии, если в таблице марштизации активен интерфейс между марштизаторами R1 и R3. Для чего такое нужно? Ведь представьте, если трафик, вернее, если линк здесь упадет, то, соответственно, этой сети не будет в реп-таблице,

то делать марштизатор R1 предпочтительной точкой входа не имеет смысл, потому что в любом случае марштизатор R1 перенаправит трафик в сторону марштизатора R2, а R2 уже отправит в сторону марштизатора R3. Чтобы не было такого субоптимального раутинга, мы можем сделать следующее. марштизатор R1, когда видит пропадание префикса в нашем случае 10, 2, 3, 0, 24, как только этот префикс пропадает из таблицы RIP, то марштизатор R1 перестает анонсировать его дальше. Высылается сообщение в виздро в сторону марштизатора R6 и в сторону марштизатора R4. Соответственно, таким образом, нам марштизатор R4 сразу перестроит таблицу марштизации, и предпочтительной точкой входа в автономную систему 123 становится линк между марштизаторами R2 и R5.

Давайте посмотрим, как сконфигурировать данную политику. Прежде всего, мне необходимо убедиться в том, что сейчас марштизатор R4 от нас принимает какой-то префикс. showIP. showIP. showIP. showIP. showIP. showIP. gp. как мы видим, что мы, например, принимаем от марштизатора R1. Так, специфики мы не анонсим. То есть у нас прилетает только 200 слайс 16. Давайте я для простоты, чтобы не разбирать предыдущую конфигурацию. Я нам... Хотя, сейчас, секунду. Я должен... Да, смотрите, я вижу, например, префикс 3333, который я получил в том числе от марштизатора R1.

Вот. Настроен марштизатор R1 так, чтобы префикс 3333 передавался в сторону марштизатора R4. Только в том случае, если линк между R1 и R3 находится в состоянии апптура. Прежде всего, нам нужно создать фильтр, который будет отлавливать префикс марштизации внутри нашей RIP-таблицы. Создадим его с помощью префикс-листа. IP-префикс-лист. Назовем его, скажем, R1, R3-линк. Это будет префикс 10.1.3.0.24. То есть это do show ip route connect. Надо собрать внимание, что я буду отлавливать вот эту подсеточку. Вот эту подсеточку. Вот эту подсеточку. Хорошо. Теперь.

Симулируем падение линка. Симулируем падение линка. Это фейс-гей 2.13. Сделаем. Shutdown. Shutdown. Окей. Сейчас, если мы посмотрим на таблицу маршрации. То мы увидим, что префикс эти 3.3.3.3.3, он нам и так до сих пор до сих пор до сих пор до сих пор до сих пор до сих пор до сих пор до сих пор. Так. Сделаем. Сделаем. Трэйс-раут. 3.3.3.3.3.3.source. В окно. К сожалению, я, видимо, забыл. Show IPBGP 4.4.4.4. Network. uffy. Здесь но extends draw withwyn.

Проверим Ping. IPBGP4444 нам доступен. Нам в рецепте R1 пришел IPBGP4444, он нам также известен. Хорошо. Хорошо. Пришел IPBGP3333. Как видите, мы до сих пор получаем префикс 3333 от муштизатора R1. И дальше выбираем маршрут лучше. Где у меня трассировка сейчас? Должна работать? Это мы явно видим. Муштизатор R1. Окей. Так, мы с вами создали префикс-лист. Теперь завяжем его на некую раутмапу.

На некую раутмапу. Создадим раутмап. Мап. Назовем его existing prefixes. То есть внутри этой раутмапы у нас может быть несколько фильтров, которые будут отлавливать разные подсети. Название раутмап мне говорит о том, что здесь будет существующий префикс. Аферми 10. Говорим. Match. IP. Адрес. Префикс. Сделаем. Хорошо. Следующим шагом мне необходимо создать фильтр, который будет отлавливать префикс муштизатора R3. То есть мне нужно отлавить те префиксы, которые должны объявляться только при выполнении какого-то условия. Создадим IP префикс-лист.

Префикс-лист, например, 3 в back. Так. В данном случае будет пермит 3333. Создад 32. Его также придется завязать на раутмапу. И назовем ее... Эту мапу назовем как conditional advertisements. То есть те префиксы, которые мы будем анонсировать при выполнении требований, которые указаны вот в этой раутмапе. Здесь. Префикс. Префикс-лист. Это требуемый окно. Хорошо. Теперь нам необходимо применить данные настройки для конкретных соседей. Приходим в настройку router.pgp. И говорим, что в сторону соседа 10.1.

Давайте я сразу запущу debug. Do debug IP PGP. И говорю, neighbor 10.1.4.4. То есть это связано с анонсизатором R4. Я ему говорю, все маршруты, которые будут... Все апдейты, которые будут подаваться в сторону вот этого соседа, они будут отфильтровываться с помощью advertise map. В нашем случае это route map conditional advertisement. Conditional advertisement. Conditional advertisement будет завязан на exist map. То есть те префиксы, которые указаны внутри advertise карты,

они будут валидны только в том случае, если выполнено условие exist map. В частности, exist map – это exist prefixes. Хорошо. Обратите внимание, сразу славится send. То есть у нас полетели новые апдейты. И сейчас, если мы на мурсуаторах 4 посмотрим show IP PGP для префикса 3.3.3.3, то... Так, он пока что здесь все равно. Давайте сделаем clear IP PGP 10.1.4.1.in. Так, обратите внимание, я сейчас нигде не вижу, я в апдейтах не вижу то, что высылается в префикс R3, но, обратите внимание, send enrichable для 3.3.3.3.

То есть, по сути, мы изымаем 3.3.3.3 из BGP таблицы, которая отправляется в сторону мурсуатора R4. Как вы видите, апдейт в сторону мурсуатора, апдейт, полученный от мурсуатора R1 пропал. И теперь, естественно, если мы запустим trace, то трасса пошла по другому пути, но в нашем случае пошел через мурсуатор R7, R5, R2. Соответственно, трафик побежал. Вот теперь он от R7 в сторону R5, в сторону R2 и в сторону R3. Теперь достаточно мне включить линк между R1 и R3. Единственное, из-за особенностей виртуализации,

мне сначала нужно будет включить линк на мурсуаторе R3. После этого я его включаю на мурсуаторе R1. интерфейс G2.13 no shot. Брюс, у меня появляется маршрут в таблице маршрутизации, и должно сработать правило advertise-карты. Advertise-карты. И вот, видите, сообщение send update. Теперь нам уже сатра R4. Нам уже сатра R4. в шопе или GP333. Так, почему-то до сих пор пока у меня его нет.

Смотрите. Send update for 3333.3 в сторону маршрутизатора R1. 10.1.6.1. Где же в сторону R1.10.1.4? Окей. Окей, окей, окей. Ускорим процесс конвергенции. Route installing. Так. Ну, вроде бы сейчас все хорошо. Так. Но у меня пока что отсутствует префикс через маршрутизатор R1. Давайте посмотрим на дабагол, что произошло на маршрутизаторе R1. Итак, show ip-prefix-list. Префикс-list отлавливает сеть 10.1.3.0.

Посмотрим наличие этой сети в таблице маршрутизации. Show ip-route. Да, такая сеть является connected. Теперь show ip-bgp. 3333. 3333 отдается в сторону Advertise группы номер 30. Show ip-bgp. Update. Group 30. В частности, только в сторону маршрутизатора R6. Он не отдается маршрутизатору R4. Так, а почему так? Нам сейчас, видимо, потребуется некий troubleshooting. Никий troubleshooting. Итак, маршрутизатор R1 знает префиксы от маршрутизатора R3 и от маршрутизатора R2.

В сторону маршрутизатора R4 мы говорим conditional advertisement при условии префиксов. Давайте проверим, правильно ли я настраиваю эти route map. Show ip-prefix list. Окей, то есть он отлавливает loopback 3333. При наличии exist map. Show route map. Да, обратите внимание, у меня неправильно настроен параметр match. Show run section route map. Видите, у меня нет такого префикс-листа.

Я ошибся в имени. Хотя нет, стоп. IP-адрес, префикс-лист, exist, префикс-лист. Да. Префикс-лист, он должен называться show run include. Include префикс. Префикс-лист. Префикс называется... Вот, префикс-лист L1R3-link. То есть мне вот эту строчку нужно убрать. Хорошо. И сказать match IP-адрес. Префикс-лист. И в качестве префикс-листа указ PL. PL. R1, R3-link.

Здесь, на ненужаторе R4. Сейчас включим debug IP BGP updates. Хорошо. Теперь вроде бы все в порядке. Show IPBGP для 3333. Нам нужно запросить clear IPBGP 10.1.4.1. Где-то здесь мы должны будем получить update. Да, видите? Receipt 3333. Receipt 3333. Теперь show IPBGP 3333. И вот.

Теперь, если с саб-интерфейса мы обратно погасим. Взял. Взял. Здесь, например, зелу shutdown. То на ненужаторе R4, по идее, должно прийти сообщение withdraw. Отерrar. И… Прошел update. Дебаг. Так, но все равно мы пока его отдаем. По идее сеть 10.1.3.0 у нас пропала.

Давайте еще раз. Мы отлавливаем эту сеть. Никаких абэс, не прилетал. Пока что не прилетал. В чем, может быть, вызвана проблема? Например, давайте посмотрим show ipbgp 3.3.3. Далее посмотрим show ipbgp update group 31. Действительно, мы видим, что статус сейчас стоит Advertise. То есть нам говорят, на самом деле, о том, что у нас выполняются условия, которые описаны в existing prefixes.

Говорит нам о том, что у нас эта сеть в любом случае есть таблица маршрутизации. show iprout 10.1.3.0. И, как вы видите, она сейчас нам доступна по OSPF через маршрутизатор R2. Что сейчас произошло? Я выключил интерфейс. Вот этот вот. Но, поскольку, во-первых, это эмуляция, а во-вторых, поскольку вот этот интерфейс, да, то есть интерфейс на R3, вот этот sub-интерфейс, он остается в состоянии up. Здесь включен протокол SPF. По протоколу SPF эта сетка долетает до маршрутизатора R1 и все равно остается в RIB. Поэтому для полного воспроизведения падения линка мне необходимо погасить еще интерфейс на маршрутизаторе R3. Давайте на R4 включу debug ipbgpupdate.

На маршрутизаторе R1. На маршрутизаторе R3 скажу P2.13. Shutdown. Shutdown. Соответственно, сейчас стоит пока что Advertise. Как вы видите, прилетели какие-то апдейты на маршрутизатор R4. На маршрутизаторе R1. Сейчас пока стоит Advertise. Show ip. RAUD.13.0. Все, эта сеть больше в Notting Table. Давайте замклировать IPBGP. Отключим debug. Но сейчас все равно пока не разберем в таком количестве.

Слишком уж много апдейтов. Show ipbgp33333. И как вы видите, апдейт от маршрутизатора R1 пропал. Р1 пропал. Субтитры сделал DimaTorzok. Редактор субтитров А.Семкин. Корректор А.Кулакова Редактор субтитров А.Кулакова Редактор субтитров А.Кулакова