PE-CE OSPF в L3 VPN: часть 2

Да, все правильно. Все правильно. То есть что у нас происходит? У нас мурсиатор R4 получает апдейт по OSPF. Далее мы регистрибутируем этот маршрут из OSPF в БГП. Передаем его по БГП в сторону мурсиатора R1. И помещаем из BGP в OSPF. То есть из БГП в OSPF. То есть на самом деле по сути что происходит? Вот мурсиатор PE. Про PE какую роль он выполняет? Слышали? В OSPF такое понятие как ASBR.

То есть это тот маршрут изатор, который помещает какие-то внешние префиксы внутрь OSPF домена. Соответственно, но мурсиатор ASBR, то есть когда делается редистрибуция БГП в OSPF, у нас генерируется LSA пятого типа. ЛSA пятого типа. Давайте в этом убедимся. show.ip.spf database. И вот действительно у нас есть Type 5 External Link, то есть LSA, который описывает внешний маршрут, который как бы не принадлежит нашему домену. Соответственно, у нас есть LSA, которая в частности описывает вот эту сеть. То есть сеть 14141414. Аналогичный процесс происходит на мурсиаторе, на другой паре по ECE. То есть теперь мы можем спокойно запустить ping между нашими лобэками. Ping 14141414. Source loopback 0.

И сделать трассировку. 14141414. Source loopback 0. Нumeric. Обратите внимание, что в нашем случае VPN метка равна 16, что видно из трассировки. Почему она равна 16 и откуда она получилась? То есть на showBGP. То есть мы смотрим на PEM маршрутизаторе. ShowBGP, VPN v4, unicast all. Для префикса 14141414. Вот она. То есть видите, mpls label в направлении out. То есть по сути мы будем использовать эту метку на выход. Это значит, что мы эту метку получили от маршрутизатора R4. Вот она 16 метка. Откуда она берется? Василий. Я вот не знаю. Знаешь, Василий, я бы на твой вопрос ответил, потому что.

А вот. Как-то вот так. Нюа, смотрите, ребят, вопрос. Ведь по сути, по сути, что у нас происходит? Ведь наши маршрутизаторы, наши маршрутизаторы, то есть я имею в виду CE маршрутизаторы, в частности R11 и R14. Ведь этому чаще всего будут маршрутизаторы родной компании. То есть, условно говоря, это может быть два офиса, Москва и Питер. Как вы думаете, логично ли, что, скажем, московский офис, в частности маршрутизатор R11, видит префиксы питерского офиса как external? Или, ну, хотелось бы видеть, наверное, в некоторых случаях, хотелось бы видеть как internal. На самом деле, ну, мне кажется, да, что более логично, чтобы эти префиксы прилетали как внутренние.

Поскольку мы у провайдера просто заказываем некий сервис, просто чтобы он передал префиксы из одной точки в другую. Нам бы не хотелось бы, чтобы он менял их тип. То есть мы вот ему отдаем как внутренний префикс. Будь добр, пожалуйста, отдавай нам внутренний. Я сейчас сделаю на маршрутизаторе R4 сделаю небольшие изменения конфигурации. В частности, в частности, showrun, section, успех. Ребят, я уберу router успех 4. No router успех 4. заменю его на router успех 4. Redistribute bgp100 subnets

и router bgp100 address family ipv4 vref red redistribute успех 4. То есть я просто поменял номер успех процесса. номер успех процесса, не более того. Окей. Проверяем connectivity. King есть. Show ip route спе. Видите изменения? Обратите внимание, маршруты стали видны как? Как внутренний, при этом как внутренний межзонный. Хотя мы просто поменяли номер успех процесса на одном из муфтизаторов PE. Давайте вспоминать. Давайте вспоминать.

Василий, в целом твоя мысль верна единственное, что смотри, мы когда просматривали BGP префикс я ваше внимание акцентировал на одной детали которая вот еще в 16-ричной форме которая в 16-ричной форме записана то есть на муштизаторе например, на муштизаторе да, да, да, то есть смотрите show BGP VPN V4 unicast да, тот же самый SPF домен ID unicast all для удаленного префикса 14-14-14-14 то есть смотрите мы по BGP принимаем маршрут атрибуты которого

говорят нам о том, что первоначально первоначально этот маршрут был порожден в SPF домене да, то есть об этом нам говорят SPF атрибуты, которые к нему добавлены и в частности он был порожден в домене в домене вот в таком-то да, то есть условно говоря в домене номер там ну 64-16-ричный да, или в домене номер 100 далее мы сравниваем вот этот мы сравниваем полученный домен ID с доменом ID нашим собственным для этой вероэфа смотрим, что этот домен домен равен 100 да, то есть он он берется из номера SPF процесса и мы решаем, что если если если эти домены различны то по факту мы считаем, что два CE-машкизатора принадлежат различным заказчикам да и поэтому мы генерируем LSA пятого типа

то есть да просто мы говорим что как будто это совсем-совсем внешняя сеть если же эти домены совпадают если же эти домены совпадают то show ip ospf не здесь на CE show ip ospf database то обратите внимание у нас уже нет LSA пятого типа вместо этого наш PE-машкизатор начинает генерировать LSA третьего типа начинаем генерировать LSA третьего типа и давайте посмотрим show ip ospf database summary 14 14 смотрите представьте

себе такую ситуацию представьте себе такую ситуацию. Так, сейчас нужно открыть point x. Представляете, вот такую ситуацию, что у вас есть MPLS-ное облако. У вас есть PE-машкизаторы. У вас есть PE-1, PE-2. У этих машкизаторов, например, вот здесь сконтигурировано VRF, здесь сконтигурировано VRF. Здесь у вас есть CE-машкизатор CE-1, здесь есть машкизатор CE-2. При этом у них, предположим, есть еще, например, дополнительный лент. У нас есть машкизатор некий, например, PE-3. PE-3. Здесь у нас тоже есть кастомер. Что получается? Префикс от CE-3 передается на PE-3 по USPF.

По USPF. Далее, соответственно, префикс помещается в BGP, то есть у нас здесь происходит редистрибьюция USPF-BGP. Далее префикс по BGP отдается на обоих соседей. И редистрибутируется здесь из BGP в USPF. Далее что происходит? Префикс отдается от PE-1 в сторону CE-1. Причем, обратите внимание, здесь улетает уже LSA-type-3. То есть, по сути, наши машкизаторы PE, они с точки зрения USPF-3 становятся кем? Они становятся ABR-ами. То есть, именно ABR генерирует Type-3. Но префикс, вот эта LSA-ка summary идет вот таким вот образом. То есть, так в одну сторону и так в другую сторону.

Ребят, как вы думаете, существует ли вероятность того, что, например, вот этот вот машкизатор PE-1 рассчитает USPF таким образом, что заинсталирует вот эту оранжевую LSA-ку как лучшую? То есть, выберет этот маршрут как лучшую? Ребят, ну на самом деле, конечно же, есть. По сути, мы сравниваем между собой BGP маршрут и USPF маршрут. Да? То есть, естественно, амортизатор PE-1 инсталирует маршрут оранжевый как лучший. Далее, что он с ним делает? У нас редистрибуция настроена, правильно? Что у нас помещается? У нас помещается этот префикс в BGP. То есть, у нас происходит редистрибуция USPF-BGP.

И отправляется вот так вот. То же самое происходит на PE-2, на самом деле. В общем, у нас при определенных ситуациях начинает штормить control plane просто постоянно. Префикс как-то начинает флапаться. Это проблема. Это проблема. То есть, проблема из-за чего? Потому что USPF – это не совсем link-state протокол. То есть, он link-state, но только внутри зоны. Между зонами у нас работает классический distance-вектор. То есть, когда мы скрываем LSA первого-второго типа, мы их скрываем за LSA третьего типа. То есть, мы берем только некую суммарную информацию, по сути, превращаем USPF в distance-вектор. Смотрите, обратите внимание, что я когда просматриваю LSA, в частности на CE-мужтизаторе.

То есть, для summary LSA, обратите внимание, здесь стоит одно ключевое слово, которое называется downward. По сути, это выставление дополнительного сигнального бита внутри LSA третьего типа. То есть, бит называется downbeat. логика его какая? Смотрите, когда мужтизатор делает эту дистрибуцию из BGP в USPF для какой-то VRF. Помимо, собственно, генерации третьего типа LSA, он в эту LSA ставит downbeat. Для чего он нужен, этот downbeat? Любой маршрутизатор, который принимает LSA, в котором есть downbeat,

он проверяет, не находится ли его интерфейс, через который он принял эту LSA внутри VRF. Если интерфейс находится внутри VRF, то такая LSA не обрабатывается, она просто дропается. Просто дропается. Таким образом, возвращаясь к нашему прошлому примеру, маршрутизатор PE1 получит оранжевую LSA третьего типа от маршрутизатора PE2, увидит, что в этой LSA есть downbeat, то есть условия раз выполнены. Второе. Наш интерфейс, через который мы эту LSA получили, находится в VRF. Поэтому что мы делаем? Мы ее не обрабатываем, мы ее дропаем. То есть, это дополнительное средство loop prevention для USPF, которое работает именно с таких топологий. Это раз. Это раз.

Второе. Если мы вернемся с вами... Это именно для LSA третьего типа. Для LSA третьего. Ребята, а как вы думаете, а что будет, если на CE маршрутизаторе вот этот интерфейс помещен в VRF? То есть, например, у вас провайдер настроил себя VRF, и кастомер у себя также может настроить VRF? Как вы думаете, в этом случае CE маршрутизатор, что он сделает? С апдейтом, который получит от PE1. Правильно отбросит, да? И не будет иметь возможности связаться с другим сайтом. Действительно, на самом деле, такое встречается. У нас, кстати, даже есть тут слушатель, Ваня Артемьев. Вот у вас на сети именно так и работает.

То есть, у вас на сети на CE настроена VRF. А нам, например, нужно префикс там куда-то дальше передать. То есть, у нас для этого, для этого. То есть, специально для таких сценариев. Специально для таких сценариев. На CE маршрутизаторе. На CE маршрутизаторе. Ну, давайте я... Раутер по SPF 100. И здесь есть командочка, командочка, которая называется, по-моему, Capability. Capability. Capability... Нет. Или Capability.

Нет, это... Возможно, мне придется, да, там где-то и командочку подсмотреть. Но все в том, что есть команда, которая называется, что-то, compatibility-vref-light. Я был уверен, что она называется compatibility, на самом деле. Ну, в общем, ребята, то есть, команда звучит примерно как compatibility-vref-light. Я ее, может быть, чуть-чуть попозже поищу. Хотя, что попозже? Давайте. SPF compatibility-vref-light. Попозже по-моему, я ее, возможно, нет у меня в OSPF процессе, да,

потому что с точки зрения CE-муштизатора это не vref-light. То есть, это не vref-light. То есть, если я создам некий, там, router SPF 99, там, vref-light, условно, test, окей, создам эту vref-light, vref-light, definition, test, задание, например, true distinguishable, произвольный. Router SPF 99, vref-light, vref-light, test. unknown vref-specified. vref-definition-test. Нужно активировать его для адресного семейства. vref-light. Окей. И наверняка, наверняка здесь должна появиться эта команда

capability. Вот. Видите, то есть появилось дополнительное слово, да, capability. То есть, видите, don't perform p-specific checks. То есть, по сути, мы говорим в summary LSA, в summary LSA, не проверять вот этот вот downbeat. То есть, если этот downbeat присутствует, мы все равно его себе заинсталируем. То есть, эту команду не нужно вводить на p-амортизаторах, которые смотрят обратно в mpls. То есть, это только в том случае для CE-раутеров, если у вас там vref-ы есть. Виктор, ты все правильно понял. Это, на самом деле, не обязательно должен быть физический линк между ними. Это просто может быть некий бэкапный путь. То есть, например, у тебя есть основной путь, скажем, через mpls, скажем, какой-то высокоскоростной канал. И у тебя есть

дополнительный путь между амортизаторами. Это может быть, например, L2 VPN, скажем. более дорогой, например, менее скоростной, который ты бы хотел использовать в качестве бэкапа, если, не дай бог, у первого провайдера будут какие-то проблемы. Я не могу сказать, что прямо уж очень-очень распространенная, но, да, то есть, если это может быть, например, даже один офис, может быть, один офис, и у тебя есть просто два оплинка наверх. Ну, а ты решил использовать OSPF, и вот внутри у тебя тоже есть коннективность. Окей, с этим разбрались, да, как с петлями бороться. Но, но, давайте теперь посмотрим, давайте теперь вручную изменим OSPF-домен ID. То есть, очевидно, что если параметр некий берется из номера OSPF-процесса, ну, наверняка мы его можем сконфигурировать,

ну, потому что это было бы нелогично просто его брать откуда-то жестко. Давайте на ПЕ-маштизаторе, на ПЕ-маштизаторе, show run, include routers, здесь это должен быть router OSPF-100. Окей. И у нас здесь появляется командочка, которая называется domain ID. domain ID. Соответственно, задаем домен ID type, нам нужен вот этот type 0,0,0,0,5, и, соответственно, нам нужно некое value, которое мы укажем в значении hex. ну, то есть, я его просто скопирую с, ну, скажем так, showBGP, VPNV4, unicast, all для префицита 14, 14, 14, 14, 14,

14, 14, то есть, получается вот это вот значение, value, и, например, я просто 64 поменяю на 65. 0,65. вот так. Вот так. Не нужно указывать вот этот вот hex. префикс. Соответственно, теперь, если я вернусь на CE-машизатор R11, посмотрю showIP route OSPF, надо обратить внимание, что у меня появляется экстерном маршруте.

А теперь давайте вернемся к нашей топологии. Ребята, смотрите, у нас downbeat, как я сказал, был введен для того, чтобы защитить OSPF от петель, которые вызваны редистрибуцией из OSPF в BGP и из BGP в OSPF в нескольких местах. Но downbeat, он существует только в Type 3 в эссеях. Теперь же, теперь же, как мы выяснили, у нас уже не Type 3, у нас теперь Type 5. А в Type 5, в Type 5, к сожалению, downbeat у нас нет. Давайте посмотрим, что... Но защита от петель нам нужна, от этого никуда не деться, потому что мы же ее теряем. Давайте посмотрим OSPF базу данных. OSPF базу данных на этом можете затворить. showIP OSPF database

и нас будет интересовать external для сети 14, 14, 14, 14. Обратите внимание, это LSA, она 5-го типа, то есть, описывает внешние маршруты. в частности, она описывает сеть 14, 14, 14, 14, с сетевой маской, с сетевой маской слэш 32, metric type 2, то есть, это маршрут Е2. И обратите внимание, у нас есть external route tag. External route tag. по сути своей, по сути своей, это route tag, который был взят определенными манипуляциями из номера нашей автономной системы BGP. То есть, у нас запущен BGP номер 100.

BGP номер 100. То есть, число 100 и вот это число, они напрямую связаны. То есть, они там получаются прямым неким взаимодействием. Что получается? Да, собственно. Что у нас получилось? Когда маршрут, когда маршрут редистрибутируется из BGP в SPF, да, то есть, если он редисцируется как пятый тип, то дополнительно к LSA выставляется некий tag. Соответственно, LSA пятого типа передается от CE к CE и дальше уходит к PE2. И PE2 видит, что он принимает эту LSA через... Во-первых, он принимает через интерфейс внутри VRF. Первое. Второе. Он видит, что на нем настроена

редистрибуция из OSPF в BGP. Два. Второе. О, третье. Он видит, что к нему пришла LSA пятого типа. Он начинает эту LSA пятого типа анализировать, вытаскивает оттуда tag. И, по сути, сравнивает, равен ли tag номеру автономной системы BGP, который настроен на нем локально. если номера условно совпадают, то марштизатор понимает, то марштизатор PE2 понимает, что этот префикс на самом деле уже в MPLS побывал. То есть, он уже передавался. Поэтому редистрибутировать его обратно и создавать возможные петли нет никакой необходимости. Поэтому такая LSA не обрабатывается и drop. ПОДПИСМЕНТЫ