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

Вопросы. Понятно, как работает механизм предотвращения петель с таким вот OSPF мультихоумингом? Нет, Виктор, дополнительно включать ничего не нужно. То есть это все делается автоматом. То есть downbeat выставляется автоматом. Теги выставляются автоматом на основе номеров BGP автономных систем. Вот мы это только что видели. Ничего включать не нужно. Оно само. Это стандартно на самом деле заложено. Там есть прям отдельный RFC, который называется OSPF MPLS BGP VPN V4. Между...

При обрыве P2, P3. А у тебя маршрутизаторы PE между собой по OSPF никак не перятся. Они не передают друг другу OSPF маршрут как бы на прямую. Ну, не обязательно передают. То есть там OSPF маршрутов нет. Вообще. У тебя только BGP там бегает. Естественно, если один PE маршрутизатор так или иначе помирает, да, то CE маршрутизатор это детектирует. То есть у него отваливается OSPF соседства. И он перестраивает свою таблицу маршрутизации. Как быстро он это отдетектит, зависит от. То есть если они соединены прямым линком, да, по сути... По сути детектирование происходит почти моментально. Если на PE маршрутизатор происходит просто какие-то, например,

просто, например, OSPF отказал, да, и он, например, перестал... Ну, вообще просто OSPF закрешился. То CE маршрутизатор будет ждать пока у него есть отчет холл таймер, который по дефолту для Ethernet-сети составляет 40 секунд. Но вы должны понимать, что в жизни, в жизни на холл таймеры сейчас мало кто полагается. Обычно между маршрутизаторами запускается дополнительная BFD-сессия. То есть у вас ходят дополнительные управляющие пакеты. Они ходят, скажем, приблизительно 2-3-4 раза, 5 раз в секунду. Соответственно, условно говоря, там есть слем. Там в течение секунды нет ответа. У вас BFD-протокол говорит OSPF о том, что с нейбором что-то не так, и давай-ка мы положим отношения соседству. То есть с помощью BFD мы можем детектировать фейлеры в течение сабсиквенса. Если OSPF покрашился, а BFD жив, ну да, то в этом случае тебе, к сожалению, придется ждать, пока холл таймер не стечет.

Но я тебе честно скажу, я таких прецедентов в своей жизни особо не видел. Блад, давайте мы не будем путать фаст рерауты, поскольку это как бы мухи и котлеты. BFD – это просто отдельный контр-уфлайн протокол, который характеризуется тем, что OSPF-сообщения там очень легкие, они не несут никакой полезной нагрузки, и созданы только для того, чтобы детектировать, жив сосед или мертв. И BFD умеет сообщать о своем статусе другим протоколам, любым, там, OSPF, BGP, статическим маршрутам, неважно. Фаст рераут – это вообще из отдельной категории. Фаст рераут, по сути, нам позволяет в определенных ситуациях строить, например, бэкапный путь и переключаться на этот бэкапный путь, если с нашим основным путем что-то случилось.

То есть это, в принципе, все технологии, которые направлены на увеличение скорости сходимости сети, но они все работают по-разному и, по сути, между собой никак не связаны. Окей. Сейчас я хочу ввести дополнительный линк между нашими CE маршрутизаторами. Между нашими CE маршрутизаторами. То есть мне для этого потребуется прокинуть линк между маршрутизатором R11 и R14. То есть у меня появляется вот здесь дополнительный линк. Здесь дополнительный линк. Ребята, это сделать несложно. Мне на моих маршрутизаторах достаточно просто создать, на самом деле, сабинтерфейс и положить его просто в одну и ту же VLAN на двух железках.

То есть я говорю, интерфейс GIMP 2.11.14, encapsulation.1.q.11.14 и IP-адр здесь будет 10.11.14. И на маршрутизаторе R14. Pacebook 2.14. Пальшу. Пальшу. Пальшу. Пальшу. Пальшу. Пальшу. Пальшу. Пальшу. Пальшу. Пальшу. Пальшу. Вот. То есть у меня появляется новый линк между ними. Вот этот, который, скажем, прямой линк. Пинг. 10.11. 14.11. 11.14. 11.14.

11.14. Show IP, интерфейс GIMP. А, окей. Interf.com. GIMP 2. NoShot. In-office. In-office. In-office. GIMP 2. NoShot. Pink. 211.14. То есть проверяем базу connectivity. Change state to up. Change state to up. Change state to up. Show IP. Brief. Давайте проверим до начала. Мне кажется, да.

Мне кажется, ребят, я, к сожалению, не знаю, в чем проблема. У меня интерфейс GIMP 2.0. Физически никуда не подключен. Я не смогу наживую подключить. Поэтому, поэтому, с вашего позволения. Я забыл прокинуть физический линк между устройствами. На живую, наверное, не подключится. Поэтому, поэтому мы сделаем следующее. Мы сделаем следующее. Мы добавим... Мы просто VRF еще поднимем на муштизатор R2. Поднимем вот здесь вот линк. Здесь вот линк. А. Сейчас. Давайте-ка... Можно я открою? Ну. Позвольте мне открыть мою физическую типологию.

Вполне возможно, что мне просто железку нужно будет стопнуть. Не предусмотрел. Ну, вернее, ошибся, когда нас построил. Так. Так. У меня есть линк между 11 и 12. 12 прямой. Это интерфейс G4. Между 11 и 12. А. Ну, да. То есть, коллеги. У меня вот здесь вот есть линк. Я, видимо, как раз его только закладывал для мультихоминга. Вот здесь.

Давайте-ка. Быстренько это сделаем. У нас не займет много времени, на самом деле. Интерфейс G4. NoShot. И адрес. 10.11.12.11. Ин на 12. Терминал. Интерфейс G4. NoShot. 10.11.12.12. Проверим. Пинк. 10.11.12.11. Есть. Отлично. Showrun. Интерфейс G3. Здесь все есть. Мне, по сути, что нужно. Давайте-ка на мультизаторе R1. Я сейчас настрою мультизатор R2. Мультизатор R2.

Showrun. Сверху. Сверху. При этом, как вы видите, у меня VPN-сессия уже настроена. Она уже настроена. Я здесь просто поднимаю раутер OSPF100. Но у меня развод вы示шала RA2. Сверху. помещаю интерфейс G3 внутри этой VRAF. Гравь forwarding. Создаю раутер успf100. Помещаю его внутри VRAF.

Говорю команду network. Говорю redistribute bgp100. Раутер bgp100. Адрес family IPv4. Redistribute uspf100. Раутер uspf100. Раутер uspf100. Например 1. Network 10 2 12 12 000. Ария 0. И network 12 12 12 000. Окей.

Окей. Окей, соответственно, теперь по идее show ip route uspf. У меня есть путь на марштизатор R1. При этом, как вы видите, он остался как external. Ну, потому что мы на PE марштизаторе, как вы помните, поменяли вот этот вот домен type. Давайте я его уберу. Давайте я его уберу. То есть верну его в дефолтное значение. Окей. Соответственно, марштизатор R12. Show ip route uspf. А здесь у меня есть подозрение, что нужно будет. Все. То есть маршрутик появился. Теперь мы поднимаем с вами, теперь мы поднимаем с вами успех вот на этом линке. То есть мы делаем мультихоуминг.

Поднимаем успех вот на этом линке. Для этого, для этого, на марштизаторе R12. Я говорю router uspf 100, network 10, 11, 12, 12, 0, 0, 0, 0, area 0. И то же самое я делаю на марштизаторе R11. Раутер uspf 100. Или какой здесь был? Show run include router. No router uspf 100. Раутер uspf 1. Здесь должно быть 11. Сейчас у меня поднимется отношение соседства между 11 и 12.

submit – и видно. И на 12. writing��. paid showrun. common router strictстarts 2k out ждем Да, он пока в состоянии wait.

Да, сейчас должно появиться. Там еще просто он уже успел его поднять, ждет, пока истечет. Ну вот, окей, loading to full. Ребята, у меня к вам такой ко всем вопрос. У нас между амортизаторами, то есть у нас какое отношение сосязности? То есть у нас OSPF настроено вот здесь, OSPF настроено вот здесь и OSPF настроено вот здесь. Как вы думаете, если я запущу трассу с лупбека R11 на лупбек R12, каким путем пойдет трафик? Как он пойдет? Пойдет ли он через MPLS вот так вот или же он пойдет напрямую? Кто как думает?

Кто как думает? Есть кто-нибудь живой? А почему через MPLS? Вот кто... Почему? Почему? Давайте сделаем трассу. Трасса 12.12.12.12. Сурс, лубак, 0. Ниндер. Обратите внимание, пакет идет напрямую.

То есть show ip route.sp. Обратите внимание, что префикс 12.12.12. Мне известен через прямой линк. Кто-нибудь понимает? Скажите, напишите. Вот поставьте, пожалуйста, честно, тот, кто не понял, почему произошло. Почему мы выбрали путь через прямой линк, а не через MPLS? Будем вместе разбираться. Смотрите. Давайте так. Давайте. Вот что. Мортизатор. Да, то есть почему он выгоднее? Почему этот линк лучше? Смотрите. Смотрите. Так.

Мы смотрим в сторону. То есть мортизатор R12. И скена. Что значит административная дистанция успех меньше, чем MPLS? У нас MPLS это не протокол мортизации. У нас мортизатор R12 дает префикс в сторону R2 по USPF. То есть дает свою USPF на USA. Далее. Далее. Этот маршрут идет из USPF в BGP. Попадает на R1. И идет обратно как BGP из BGP в USPF. BGP в USPF. Это первый пункт. То есть это первый пункт. То есть R1 получает на линке GIG3. И второй апдейт. И второй апдейт он получает через линк четвертый. То есть это второй.

Так почему же вот этот синенький линк выгоднее? Это оба апдейта одного и того же протокола мортизации. Даже одного процесса. Поэтому очевидно, что административная дистанция у них разная. Здесь нужно обратить внимание вот на что. У нас связность, связность. Вот этот лупбек, который мы адвертайзерим. Мы его поместили в зону 0. В зону 0. И вот этот линк у нас также между мортизаторами. Мортизаторами. Находится в зоне 0. Поэтому второй путь. Вот скажем так. ЛСА-ка вторая. Вот синенькая. Это будет какой тип успеха? Обратите внимание. Это О. Что значит внутризонный маршрут. То есть это О.

Внутризонный. Соответственно. А первое. Первое. Вспомним, что это у нас было. Это у нас было либо intra-area. То есть intra-area. То есть между зонной. Либо это E2. В зависимости от домена. Да. А теперь, ребята, вспоминаем с вами OSPF Best Path Selection. То есть если OSPF получает один и тот же префикс в рамках одного и того же процесса, но разными путями. У нас действует правило. Самый лучший маршрут – это внутризонный. Потом идет межзонный. Потом идет маршрут E1. Потом идет маршрут E2. И потом идет NSSA маршрута N1 и N2. То есть от лучшего к худшему. Поэтому, по сути, у нас сейчас сравнивается между...

OSPF сравнивает между внутризонным маршрутом и междузонным маршрутом. И всегда будет выбирать внутризонный маршрут. Вопрос на закрепление. Скажите, пожалуйста, если я вот на этом линке, на прямом линке, задеру OSPF метрику, скажем, я ее поставлю там, я не знаю, 9999. Маршрут пойдет в MPL особо или будет также использовать прямой линк? Да. То есть, смотрите, метрика может сравниваться только если маршрут одинакового типа. То есть, например, оба внутризонные, либо оба междузонные, оба внешние и так далее. Поэтому, если у вас есть вот такая ситуация, например, у вас есть два скоростных апплинка через MPLS.

Скорость обычно составляет единицы или десятки гигабит внутри MPLS. У вас есть бэкапный канал. Например, я не знаю, какой-нибудь медленный L2 VPN, либо какой-нибудь старый, я не знаю, не дай бог, фрейм релей, либо еще что-нибудь такое. Либо там оптику протянули каким-то чудом. В общем, если вы решаете использовать вот этот вот L2 канал прямое соединение как резервное, то вы по дефолту удивитесь в том, что это не работает. Но это не работает. А проблема вся какая? Как раз то, что факт, что у нас внутри, то есть по этому прямому линку уходит LSA первого-второго типа. А через наш MPLS, из-за того, что у нас есть редистрибуция, у нас эти LSA первого-второго типа, по сути, они теряются на PE-мушкизат.

Как вы думаете, есть ли у этой задачи какое-либо решение? Василий, понимаешь, использовать как эреями. Можно, конечно, на R12, например, поместить лупбэк, скажем, не в нулевую зону, скажем, в зону 10, условно говоря. И тогда действительно к тебе на R11 этот маршрут придет как интер-эрея. И у тебя что через MPLS, в который префикс пришел, что через прямой линк, у тебя будут сравниваться уже два интер-эрея маршрута, то есть одинаковые. С точки зрения успеха я имею в виду кода их. И там уже можно играться, например, метрикой. Но это на самом деле не всегда так можно сделать. Представь, что у тебя там есть больше офисов, как вариант.

Можно действительно... Искен единственный не с меньшей дистанции, а с большей дистанцией. Потому что если ты настроишь с меньшей административной дистанции, он у тебя всегда будет выигрывать. Ну, я понял, что ты перепутал. Ребят, а почему никто не предложил, ну, может быть, Евгении только? Ну, так неуверенно. Смотрите, если у нас LSA первого, второго типа прилетают по прямому линку и теряются в MPLS, что мы можем попробовать сделать? Мы можем попробовать каким-то образом передавать вот эти LSA первого, второго типа через MPLS облако. То есть, по сути, между P-амортизаторами нам потребуется некий туннель. И действительно, Евгений, этот туннель называется Шамлинк. Единственное, я боюсь, что мне уже времени, на самом деле, просто не хватит сейчас рассказать про...

Сконфигурировать Шамлинк. Я предлагаю просто это оставить на самое начало следующего занятия. А сейчас просто говорю вам о том, что между... Давайте я вот эту картинку все сотру. Что у нас получается? Нам нужно, нам потребуется некий туннель между амортизаторами R1 и R2. R1 и R2. То есть, он называется действительно Шамлинк. Мы помещаем, мы помещаем вот этот вот интерфейс в нулевую зону. В нулевую зону. И таким образом, то есть, если у нас вот здесь вот нулевая зона и вот здесь вот нулевая зона, через этот Шамлинк мортизаторы построят ОСПФ соседством. То есть, по сути, мы что делаем? Мы на PE-мортизаторах поднимаем дополнительные лупбеки.

Эти лупбеки относим к VRF-у заказчика. С этих лупбеков мы строим вот этот туннель. И в этот туннель начинают туннелироваться LSA первого и второго типа. И таким образом, таким образом, мортизатор R11 от своего PE-соседа получит LSA первого и второго типа здесь. И также он получит LSA первого и второго типа здесь. И на самом деле дальше уже начинается игра метрика. То есть, вам достаточно будет вот на этом вот лимке на прямом задрать метрику какую-нибудь большую поставить, и у вас трафик всегда будет ходить честно. Идея понятна? То есть, что нужно сделать? Как уже конкретно реализовать вот этот туннель на PE-мортизаторе?

То есть, как их туннелировать? То есть, какие строчки в конфиг нужно ввести? Ну, мы это рассмотрим на следующем занятии. Так что, в целом, на сегодня у меня все. То есть, я считаю, что мы с вами довольно-таки плотненько поговорили по USPF. из кем не догоняешь чего. Давайте разберемся. В общем, шамлинк – это просто некий виртуальный интерфейс, специально разработанный вот для таких ситуаций. И в этот туннель, в этот вот линг будут как бы мортизаторы построят соседство. И для них это будет как будто у тебя есть линг прямой между маршрутизаторами, при этом который относится к этой же кастомерской VRF. Может быть, я попробую тоже немножко сказать про шамлинк. Во-первых, если вы знаете концепцию построения виртуаллинка, то это то же самое, что и виртуаллинк, по сути.

То есть, это способ связать между собой два маршрутизатора в USPF, которые напрямую в нулевом регионе, в нулевой арии не связаны. Здесь та же самая история. Вы берете два USPF маршрутизатора, которые между самой прямой проводом не связаны, и делаете так, что они друг друга видят, Unicast не связан общим проводом, но как будто бы они связаны общим проводом. А учитывая, что дальше у вас LDP строят туннели между двумя PE-шками, соответственно, трафик, который эти два маршрутизатора друг другу будут отправлять, будут сворачиваться в IPMS с помощью этих самых LDP-шных меток NextHop, которые у вас там есть. В общем, это просто как бы провод между ними. Алексей, спасибо тебе большое. Было действительно очень интересно. Нет, насколько мне известно, нет. Шамлинг – это не проприетарная технология. Опять же, на это все есть RFC, если интересно.

В любом случае, Алексей на следующем занятии покажет, как это работает. Может быть, даже если повезет, покажет, как это работает на другом оборудовании. То есть, наверное, можно подключить в эту лобу что-нибудь еще. Но, соответственно, спасибо за внимание. Встретимся на следующем занятии. Да, в следующем понедельник. На этом всего хорошего. Всем пока. Счастливо. Сaki 해야�isés. С trze assistant.