MPLS Inter-AS L3 VPN Option B: часть 2

Считаю, что мы с вами вчера говорили про интераэс 2 СПН третьего уровня. В частности, мы с вами рассматривали опцию А, мы с вами рассмотрели почти... Мы ее сконфигурировали, но она у нас немножко не завелась. Я там просто на самом деле забыл дать одну команду. Я вам вчера немножечко наврал. Немножко напутал. И сейчас я вам объясню, в чем я, скажем так, ошибся. Я немножечко ошибся. Так, сейчас, брат, я схему-какрою. Напоминаю, что у нас вот такая вот топология.

Мы строим VPN между муштизаторами R11 и R11. Родюзаторами. И вот есть у нас вот эта справа. Напоминаю, напоминаю нашу логическую топологию. Нашу логическую топологию. У нас поднята VPN V4-сессия BGP-шная между R1 и R8. Между R8 и R9. Соответственно, R8 выступает в качестве рут-рефлектора. То есть у нас вот эта сессия IBGP. В рамках адресного семейства VPN V4. Аналогичная ситуация у нас для нижнего сайта. Для нижнего сайта.

У нас, соответственно, BGP-сессия между R2 и R7. Между R7 и R10. Между R7 и R10. И у нас поднята BGP-сессия между муштизаторами. То есть у нас здесь поднята IBGP. IBGP VPN V4. И мы с вами обратили внимание, что нам потребуется некая специфичная дополнительная конфигурация на наших SBR. В частности, у нас автоматически на вот этих интерфейсах активировалась команда MPL-SBGP forwarding. То есть все в том, что у нас передаются BGP-шные метки. У нас передается некая VPN-овская метка по BGP VPN V4. Если у нас здесь нет никакого динамического протокомортизации, у нас здесь нет LDP-сессии. Поэтому у нас там не может быть LDP-шной транспортной метки. Мы используем VPN-овскую метку.

То есть используем BGP-шную VPN-овскую метку, чтобы передавать трафик между муштизаторами R9 и R10. По умолчанию просто IOS, то есть когда видит такое поведение, автоматом разрешает, в основном говоря, использовать BGP-шную метку. Это раз. И второе, если вы помните, мы на ASBR-ах сделали... Мы отменили route-target-фильтеринг. То есть мы сделали no route-target-фильтер на обоих ASBR-ах. Почему? Потому что у нас на этих ASBR-ах нет никаких VRF-ов. Соответственно, нам некуда импортировать эти префиксы. Некуда импортировать и пеновские префиксы, которые мы получаем от соседа. Соответственно, по умолчанию, если этот префикс импортировать некуда, мы их дропаем. Но поскольку нам их нужно потом передать IBGP-сессии на IBGP-сессию, то у нас происходит такая ситуация, что нам префикс нужно сохранить у себя в IBGP-тейбл.

Для этого мы меняем поведение фильтрации route-target, и по сути просто отменяем. И, соответственно, ребят, к вам очень важный нюанс. Ну, не то чтобы важный. Смотрите, у нас префикс, да, мартизатор R12, он передается от R2 к R7, потом на R10, потом на R9, и потом R9, R9 отдает этот префикс на мартизатор R8. Почему у нас вчера все это дело не заработало? Вопрос к вам. Смотрите, мы сюда передаем префикс там 12, 12, 12, 12, да, там с каким-то мы его там, route-distinguisher, первым, route-distinguisher, первым. Ребят, вопрос. Next hop в этом апдейте будет какой?

Сейчас, я найду, где-то. Коллеги, когда префикс передается от R9 к R8, идет с IBGP на IBGP сессию. Когда идет IBGP, у нас Next hop меняется, нет? В GP update. Нет, правильно. То есть, по сути, у нас Next hop стоит мартизатор R10. То есть, у нас в качестве Next hop стоит мартизатор R10. Ну, его транспортная сетка, то есть, VLAN 910. Вопрос. Мужчинатор R8, что-нибудь об этом Next hop знает? Он знает до него маршрут? Очевидно, нет, да, поскольку у нас этот интерфейс, это стыковочный, у нас там OSPF не активирован. Поэтому, что R8 сделает с таким апдейтом?

Правильно. На самом деле, единственное, что я вчера просто исправил, на самом деле, сразу по окончании нашего занятия, я на маршрутизаторе R9, на маршрутизаторе R9, show run section BGP, я дал командочку в сторону нашего root reflector и сделал команду Next hop self. То есть, я, по сути, просто изменил, изменил Next hop. И сейчас, сейчас нам отца R11, нам отца R11. Мы можем сделать ping 12, 12, 12, 12, source log back 0. То есть, у нас есть связанность. Теперь давайте обратим внимание на тассировку. Я вас там вчера немножко смутил. Я вам вчера рассказал, что LSP у нас строится end-to-end в option B. Нет, неверно. Дело в том, что, чтобы LSP был end-to-end,

у нас BGP на схог на всем пути. Должен быть неизменен. Вспоминаем логику. Мы смотрим префикс. Мы ищем маршрут в V-RF таблице. Видим, что он доступен через BGP Next hop в глобале. Правильно? Далее мы смотрим, как добраться до этого Next hop. Видим, что этот Next hop нам доступен, например, по SPF. Генерим пакет. В пакет вставляем транспортную метку, которая сигнализирует нам именно о чем? Добраться до нашего Next hop. Соответственно, ребята, к чему это приводит? Если у нас на сети где-то происходит подмена Next hop, то, очевидно, у нас обязательно будет меняться весь наш LSP путь. Если мы сделаем TraceRoute 12-12-12-12, SourceLowback 0, Umerick, обратите внимание,

в отличие от опции A, у нас на всем пути следования пакета есть метки. То есть в опции A, когда у нас передавался пакет между двумя ASBR маршрутизаторами, у нас передавался попрос IPv4 Traffic. Метка снималась. Здесь же, здесь же, вот видите, пятый hop, здесь меточка есть. Но, смотрите, на первом этапе у нас используется VPN метка 28. По сути, 28 метка это та метка, которая нам нужна, чтобы от PE маршрутизатора, который у нас вот здесь стоит, чтобы мы могли достигнуть нашего ASBR. То есть это VPN метка, которая была сгенерирована R9. Давайте посмотрим. Так, откуда берутся метки 39 и 28?

Еще раз. 12. 12. Опс, не здесь. Нам нужен уже маршрутизатор P1. шоу, бит-жи-пи, VPN v4, Unicast all для префикса 12.12.12.12. 12.12. К нам народ залазит. Сюда. Я видел, если кто-то пытается ходить. Смотрите, мы на маршрутизаторе PE получили префикс 150.8.8.8. О,

получили префикс 12. С root distingisher 102.1. Получили его от маршрутизатора R8. Получили его от маршрутизатора R8. У нас есть VPN метка номер 28, которая характеризует на то, что мы у нас мы вставим эту VPN метку, когда будем передавать трафик в сторону 159.99. Теперь смотрим. Show impuls forwarding 159.99. Видим, что чтобы добраться до этого префикса, мы с вами используем LDP-жи-пи, метку номер 39. Таким образом, у нас получается, что появляется стек меток из чисел 39 и 28. Собственно говоря, мы это и видим в нашей трассировке. Дальше все понятно. У нас просто меняется транспортная метка.

И в итоге такой пакет с меткой 28 уже, потому что у нас, как мы помним, одна верхняя меточка всегда снимается за один хоп до конца. Меточка доходит до муризатора R9. Там будет нечто интересное. Почему? Потому что, как вы видите, у нас дальше наша VPN метка пропадает, и вместо нее появляется какая-то метка номер 44. Давайте разбираться, что это. муризатор R9. муризатор R9. Муризатор R9. Смотрим. Шоу BGP. Ребят, по сессе муризатор R9 получил... Есть... Я просто напоминаю, что у нас вот здесь вот есть VPN-овская сессия. То есть, муризатор R9 должен в своей BGP-таблице иметь интересующий нас префикс конечного хоста. Смотрим. ShowBGP, VPN-V4, Unicast.

12, 12, 12. Что мы здесь видим? Что для этого хоста нам кто-то, в частности, кто? Очевидно, что муризатор R10. Прислал 44-ю метку. То есть, метка 44 это VPN-овская метка, которая была сгенерирована муризатором R10. То есть, муризатор R10 для этого префикса сгенерировал 44 и передал ее на R9. И муризатор R9 использует... То есть, по сути, он получил VPN-лейбл равный 44, да, но использует ее в качестве транспортной. Почему? Потому что у нас муризаторы находятся всего в одном... Поэтому

транспортные метки мы там не используем, потому что у нас должно быть две метки в стеке, мы одну метку снимаем, условно говоря, и остается одна более высокая VPN-овская. Соответственно, в нашей трассировке должна появиться вот эта метка 44-я на этапе прохождения пакета между R9 и R10. Давайте посмотрим. Да, вот она. Ну, вот она. Дальше, дальше. На муризаторе R10. На муризаторе изнано. На муризаторе R10. Смотрим. ShowBGP, VPN-V4, Unicast, All, 12-12, 12-12, 12. Инпут, да, то есть это 44 метка, то есть метка, который R10 сгенерировал и передал в сторону R9. И дальше у него есть выходная метка, то есть это метка номер 2,

которая была сгенерирована муризатором R2. Дальше мы смотрим, что у нас на схог муризатора R2. Смотрим, showMPLS forwarding table 150-222. Видим, что outgoing label, то есть LDP-шная метка у нас 28, и VPN-овская метка у нас тоже 28. Поэтому в трассировке мы должны увидеть стек из двух меток 28-28. Ну и дальше транспортная метка у нас меняется по обычным законам. То есть, что у нас получается? Смотрите, у нас получается, что у нас появляется 1, то есть у нас здесь появляется LSP-1. Далее, на пятом шаге у нас появляется LSP-2, то есть для трафика между двумя ASBR-ами. LSP-1 это трафик PE.

И на последнем этапе у нас появляется LSP-3, то есть 3-й независимый MPLS-ный путь, который нужен для того, чтобы от ASBR-а дойти до выходного PE-маршрутизатора. Вопросы? То есть идея Inter-AS опции B это некие улучшения по сравнению с опцией A. В каком плане? Мы заменяем все линки, то есть у нас в опции A между ASBR-ами должно было быть много-много линков. Конечно, это могли быть сабинтерфейсы. Суть в том, что много линков, много BGP-сессий. Здесь мы вот эти огромные одну,

но при этом мы их заменяем в рамках адресного семейства VPN-V4. Соответственно, если мы поднимаем адресное семейство VPN-V4, то на этих ASBR-ах мы обязаны инсталлировать все BGP VPN-маршруты. Ребят, здесь понятно? Можем двигаться дальше или что-то нужно разобрать? Дополнительно. Да. Что ж, ребят, тогда мы переходим с вами к опции С. Мне кажется, что опция

С. Что же такое опция С? Сереж, да, да, запись ведется. Ты на самом деле не сильно опоздал, потому что мы тоже прождали некоторое время, пока там программки у всех поставились. То есть мы просто успели верифицировать то, что у нас опция B работает, которая не заработала в самом начале. Я там буквально просто одну BGP-команду пропустил.