Метки MPLS и механизм propagation

Итак, что же такое MPLS и как он строит свои туннели? Мы с вами разобрались, что туннель, по сути, это на самом деле не что иное, как просто дополнительная инкапсуляция. ГРЕ делает инкапсуляцию на уровне третьем. То есть на третьем уровне он вставляет новый IP-заголовок. MPLS поступает несколько хитрее, и мы, собственно говоря, поговорим об этом. Итак, представим, что у нас... Давайте я еще раз нарисую наш топологию. Может быть, чуть-чуть количество амортизаторов, единственное, что я сокращу. Предположим, у нас есть пять амортизаторов, и на амортизаторе R5 прям явно терминируется некая подсеть A. То есть, когда я говорю, что подсеть терминируется на амортизаторе, это значит, что на амортизаторе создан IP-интерфейс. Ну, собственно говоря, создан интерфейс, и на этом интерфейсе прописан IP-адрес из некой подсетки.

То есть там некая сетка A. Сеть A, slash 24. Например, 192.168.1.0. Ну, почему бы и нет. Да, почему бы и нет. Тут это нам не принципиально. Действительно. Но у нас появляется некий дополнительный протокол. Этот протокол называется Label Distribution Protocol. Протокол LDP. Что это за протокол? Для чего он нужен? Суть в том, что… Давайте я сначала расскажу, как он работает. Я думаю, что вы сами поймете его назначение. Протокол LDP в большинстве случаев работает локально на линке. Он рассылает некие hello-сообщения по протоколу UDP на какой-то мультикассный адрес. На мультикассный адрес. Из диапазона 224.000.

Единственное, что я здесь хочу сказать, что все пакеты, вы должны это уже знать, все пакеты, которые рассылаются на адреса из этого диапазона, они обязаны помечаться в TTL равном единичке. То есть это приводит нас к тому, что такие пакеты являются не марштизированы. То есть они не могут пройти границу марштизатора. Я немножко тебя дополню. Не просто 224 какой-то адрес, 224.002 все роутеры. А, даже 002. Не могу сказать, что это прям уж сильно принципиально. Может быть, конечно, для сдачи экзамена это полезно запомнить, но по сути, на самом деле, мало когда вот так нужно. Единственное, что я помню, я не знаю, почему у меня запомнилось, передается все это Hello-сообщение на 646 порт. На 646 порт. Но внутри этого Hello-сообщения передается какая-то информация.

В частности, в частности, там передается раутер ID. Раутер ID, с точки зрения протокола LDP, это то же самое, что раутер ID для USPF, для BGP, для EGRP. То есть это просто некий идентификатор-маштизатор. А он обязан быть уникальный, как, например, в том же самом USPF, или может совпадать в соседнем устройстве? Вот этот вопрос, на самом деле, хороший. С дефолтной конфигурацией я могу тебя уверить, что он обязан быть уникальным. Если конфигурацию модифицировать, у меня есть подозрение, что он может пересекаться между двумя железками. Почему? Потому что здесь передается дополнительный параметр, который называется так называемый транспорт-адрес. Его назначение, ребят, я вам расскажу буквально через 1-2 минуты. Транспорт-адрес. И могут передаваться дополнительные параметры, например... Давайте о дополнительных параметрах мы попозже поговорим.

Соответственно, предположим, что мы включили рассылку LDP на двух интерфейсах. Что у нас происходит, например, с двумя амортизаторами, которые, скажем, работают по USPF, и которые обменялись с хлоусатчем? В общем, опуская детали глубинные, можем сказать, что, в принципе, амортизаторы становятся соседями. То есть они помещают друг друга в таблицу соседства. Для USPF эту табличку можно посмотреть в команде show.ip.uspf.net. Здесь происходит примерно то же самое. Примерно то же самое. Но амортизаторы... Эти амортизаторы можете увидеть в специальной табличке, которая называется LDP Discovery таблица. LDP Discovery таблица. После этого, то есть после того, как два амортизатора обменялись хеллоу-сообщениями,

они вычленяют из хеллоу-сообщения соседа вот этот вот параметр. Транспортный адрес. Транспортный адрес. Ребята, по умолчанию, по умолчанию, транспортный адрес равен router 1. Рouter 1. И, наверное, в 99% случаев этот параметр будет IP-адрес интерфейса loopback 0. Loopback 0. То есть я вот их здесь покажу, наши loopback. А что делать, если мы используем оборудование, которое не поддерживает работу с loopback? Ну, например, тот же микротип. Он с MPLS работается, лдп работает, а loopbackов на нем нет. Ну, что делать? Использовать какой-то адрес физического интерфейса. Что я могу тут сказать? То есть это просто некий IP-адрес, не более того. Нужен им вот для чего. После того, как муристизаторы увидели друг друга в таблице Discovery, они, по сути, строят между собой TCP-сессию.

TCP-сессию. Соответственно, в качестве source IP-адреса выступает ваш router ID. Ну, более строго говоря, выступает на самом деле ваш транспортный адрес. И в качестве destination IP выступает router ID вашего соседа. Ну, собственно говоря, или его транспортный адрес. То есть эти транспортные адреса нужны для того, чтобы два раутера смогли построить ту самую TCP-сессию, которая уже не может использовать multi-cast, не может использовать easy. Правильно. Собственно говоря, обратите внимание, что мы строим TCP-сессию, как я сказал, что в 99% случаев это будут наши выбрать. К чему это нас приводит на самом деле? Если мы окунемся в самую базу BGP, то вы вспомните, что BGP представляет по сути собой тоже на самом деле

не что иное, как TCP-приложение. Соответственно, если вы строите BGP-сессию между вашими лоутбэками, это говорит о том, что у вас в вашей опорной сети, то есть между вашими маршрутизаторами, уже корректно работает маршрутизация. То есть хотя бы какая-то минимальная. То есть ваши лоутбэки должны быть друг другу достижимы. Соответственно, здесь, ребята, абсолютно то же самое. То есть работа LDP де-факто подразумевает работающий какой-то протокол маршрутизации между маршрутизаторами, в нашем случае R4 и R5. То есть вам нужен некий протокол, например, это может быть, например, OSPF, это может быть ASAS, это может быть EGRP. На самом деле это может быть все что угодно, это может быть статическая маршрутизация. Но лоутбэки маршрутизаторов должны быть друг для друга достижимы.

Соответственно, после этого вы спокойно можете построить некую LDP, некую LDP connectivity. Некоторые люди, наверное, которые особенно работают в банках или так или иначе связаны с безопасностью, могут спросить, а безопасно ли такое построение сессии? Обычно, конечно, надо там какой-то OSPF использовать там свою аутентификацию. В принципе, при желании вы можете и для LDP включить параметры аутентификации. Единственное, но LDP не использует какие-то свои собственные механизмы для обеспечения аутентификации. Проверка подлинности используется посредством протокола TCP, абсолютно точно так же, как в BGP. То есть просто используется некая дополнительная опция, номер ее, если я не путаю, номер 19. Это номер 19.

Отсюда есть один нюанс. Смотрите, иногда, иногда заказчиком, ну или, как сказать, интерпрайзом, особенно интерпрайзом, особенно где-то в СОДах, вы можете иногда столкнуться вот с такой ситуацией. У вас мужецизатор R4, например, соединен с неким фаерволом, пусть это будет ASA. Этот фаервол, например, работает в транспарент режиме, и здесь мужецизатор R5. Так вот, я когда еще был зеленым, я этого не знал, то есть у нас так же работал LDP, и в какой-то момент, в какой-то момент мы решили включить просто аутентификацию между мужецизаторами R4 и R5, ввели одинаковый пароль, и у нас LDP-сессия развалилась. И, в общем-то, больше не поднималась. Ну, я ответа на тот момент не знал, но все дело вот в чем, в том, что

фаерволы, я не могу сказать, да, там, про чекпоинт, про пауаль, там, но ASA, точно так же, как фаерпауэр, по умолчанию, не пропускает через себя пакеты, в которых есть какие-либо включенные TCP-опции. Соответственно, вам нужно просто будет модифицировать дополнительно правила фаервола, таким образом, чтобы пакеты с этой TCP-опции пропускались. Вот, но, конечно, это может быть ситуация не самая такая распространенная, но, тем не менее, она имеет место быть, поэтому я решил вам о ней рассказать. Окей. У вас может возникнуть, на самом деле, ребята, логичный вопрос. Ну, по крайней мере, я не знаю, у меня бы он точно бы возник. Ну, окей, мы построили вот эту TCP-сессию, а дальше что? У меня первый вопрос. Зачем нам отдельная TCP-сессия, если у нас уже есть EDP-взаимодействие? Соответственно, TCP нам нужно

исключительно для гарантированной доставки неких данных, и отсюда можно предположить, что эти данные могут быть критичными для чего-то, что мы будем рассматривать чуть позже. Ну, на самом деле, действительно так. Данные, которые, амортизаторы, данные, которыми амортизаторы R4 и R5 будут обмениваться, дело в том, что если эта связанность нарушится, то ваши сервисы, например, L3 VPN либо L2 VPN, которые будут крутиться, которые мы сейчас пытаемся построить, они развалятся. Поэтому мы не можем допустить даже, скажем так, теоретической возможности того, чтобы данные, которые амортизаторы обмениваются, чтобы они терялись. Именно поэтому мы вынуждены построить некую TCP session. между ними. Есть же протоколы, которые не используют TCP и при этом используют гарантированную надежную доставку. Тот же OSPF, EJRP.

Ну, есть, есть. Ну, здесь решили сделать, здесь решили положиться на средства уже существующего протокола. Ну, тут дело, на самом деле, исключительно за автором, но, но, по секрету, ребят, по секрету, LDP на текущий момент его можно считать, на самом деле, как legacy протокол. В современных трендах так называемый сегмент раутинг, по сути, там информация, которую сейчас мы будем рассматривать, то есть информация, которая переносится посредством LDP, ту же самую информацию можно перенести посредством того же протокола OSPF либо ASIS, как вы знаете, там в OSPF есть огромное-огромное количество LSA, и в том числе есть LSA, который называется OPC. Так вот, в общем, эти дополнительные LSA могут использовать OSPF для переноса информации,

которая зашита в LDP. Единственное, я боюсь, что мы с вами, наверное, сегмент раутинг рассмотреть не успеем, поскольку, ну, эта тема совершенно отдельная. Но... А что же там за информация передается? Пока что было сказано про хвалу. Да. Ну, что же внутри этой TCP-сессии передается? Итак, когда... Какую информацию мужестватор R5 будет сообщать? Смотрите, мы когда включаем, по сути, своей поддержкой LDP на марштизаторе. На марштизаторе. На R5 можно, условно говоря, считать, что появляется, ну, появляется некая табличка. Появляется некая табличка. Эта табличка состоит из, упрощенно говоря, наверное, сейчас подумаем, сколько, наверное, из четырех столбцов. Из четырех столбцов. Первый столбец

это префикс. Обычный префикс из таблицы маршрутизации? Да, да, то есть это то, что вы видите, действительно, то, что вы видите в своей RIP-таблице, то есть то, что вы видите по выводу команды show-it-ger-out. Это поэтому ты сказал, что нужна работающая маршрутизация для того, чтобы работать в MPLS? Нет. Я сказал, что работающая маршрутизация нам нужна для построения LDP-сессии между маршрутизациями R4 и R5. Что это конкретно за префиксы? Сейчас поговорим. В нашем случае, для рассматривания нами примера, в качестве префикса будет выступать наша сеточка A. Сеточка A slash 24. Далее, собственно говоря, выходной интерфейс. Ну, пусть это будет некий интерфейс, я не знаю, пусть это будет некий интерфейс E01. Некий интерфейс

E01. Далее появляется столбец, который называется локальная метка, или вы ее увидите как некий local label. Рето, условно говоря, для начала вы можете считать, что это просто некое число. По сути, это просто на самом деле некий тег. Почему бы это мог быть и не просто числом? Ну, просто мы, когда будем смотреть, как пакет передается с точки зрения дата плейна, мы увидим, что там есть некие дополнительные поля, но, скажем так, с точки зрения построения таблицы, это действительно просто число. Оно будет не просто числом, когда пакет как бы улетит в провод. и есть некий столбец, который называется remote label. Remote label. Ребят, по сути, это некое число, которое вы получите от вашего

LDP соседа и которое также будет ассоциировано вот с этим вот префиксом A-24. Чтобы более подробно рассмотреть использование remote label, я, с вашего позволения, вот сюда еще добавлю один мыштезатор, R-6. И соединение вот таким вот образом. Вот таким вот образом. У меня есть такое подозрение, что тебе нужно будет либо в колоночку интерфейс добавить указания на какой сосед тебя интересует, либо добавить еще одну колонку. Ну, здесь neighbor, конечно, будет, да, но я решил просто не загромождать информацией, только, в принципе, там, смотря на интерфейс, мы понимаем, куда. и так, и так, собственно говоря, мыштезатор R-5 вот для этого префикса генерирует некое число, просто некое число. По сути, это рандомное число, единственное, но, единственное у него требование, оно должно быть там больше или равно 16,

ну, потому что числа от 0 до 15, они просто зарезервированы, могут использоваться при неких граничных случаях. Я, к сожалению, не знаю ни одного случая, за исключением, там, когда используется число номер 3. А вот, еще поговорим. Предположим, что мыштезатор R-5, давайте, чтобы просто для простоты он пускай сгенерировал некое число 500. Некое число 500. Соответственно, этот мыштезатор R-5 передает вот это число 500 на своего соседа, на своего соседа R-4, это он передает в рамках вот этой установившейся спис-с. Соответственно, на мыштезаторе R-4, на мыштезаторе R-4 получается следующее. М мыштезатор R-4 обязан знать, то есть, чтобы он принял эту информацию от мыштезатора R-5,

он по мыштезации, посредством того же успеха, он обязан знать об этом префиксе. То есть, префикс у него должен находиться так или иначе в его рибе. Ну, я не буду здесь заполнять, наверное, выходной интерфейс, просто оставлю вот local label и remote label. Соответственно, меточка 500, которую мы получаем от мыштезатора R-5, мы заносим его как remote label. Как remote label. То есть, отдельно нам нужно работающий SPF, который притащит эту сетку на роутер R-4, или отдельно LDP, который притащит эту же сетку. Да. А в чем разница? Дело в том, что когда пакетик разницу мы увидим с точки зрения data plane. Мы увидим, что когда пакетик на data plane придет на мыштезатор R-4, ему не нужно будет смотреть в свою таблицу мыштезации, ему достаточно будет посмотреть на ту меточку, которая к нему пришла. и это подведет нас к тому в итоге,

что на транзитных устройствах нам не обязательно будет знать всю таблицу мыштезации, мы сможем ограничиться только устройствами, которые находятся непосредственно в нашей сети. Все равно пока непонятно. Есть два протокола. Один таскает сетки, другой таскает сетки. Оба должны работать. Да, оба обязательно должны работать, но вам станет об этом чуть-чуть... Пока я, к сожалению, не могу пропустить эту часть, потому что, если я перейду сразу к построению VPN-ов, у нас не будет возможности разобраться о том, как все эти меточки передаются, откуда берутся основополагающие конструкции. Дело в том, что сетки мы сможем скрыть только тогда, когда мы поверх устройств спокойно, скажем так, между мыштезаторами R-1 и R-5 запустим BGP. В этом случае мы увидим, что действительно нам не нужны будут меточки

для хостов, которые относятся не к нам. Итак, у нас появляется меточка некая, соответственно, 500, мы получаем от нашего мыштезатора R-5, и для того же самого префикса мы сами генерируем число. Предположим, что это будет некое число 400. 400. Некое число 400. И дальше, дальше мы его передаем нашим соседям R-3 и R-6. Тут, ребят, важно сделать такое, ну не то чтобы важно, можно сделать некое одно отступление. Смотрите, меточка R-4 передает один и тот же апдейт на меточка R-3 и на меточка R-6. Так вот, он может передавать на самом деле как одну и ту же метку, так это могут быть на самом деле разные числа. Зависит это только от того, в каком режиме работает ваш MPS, то есть, ну скажем так, в каком режиме работает ваш LDP.

Если я не ошибаюсь, по умолчанию, по умолчанию, R-4 будет отсылать одну и ту же метку всем своим соседям. Всем своим соседям. А это абсолютно на самом деле не принципиально. Мне кажется, что для понимания проще, когда это одна и та же метка. да, да, собственно, это и есть режим по умолчанию. Соответственно, на мустизаторе R-3, да, у нас, соответственно, также должен быть этот префикс. На мустизаторе R-3 у нас в качестве remote label устанавливается меточка 400, да, и генерируется нами меточка некая 300. То же самое происходит на мустизаторе R-6 для префикса A. мы получаем метку 400, да, и здесь у нас получается меточка 600 локальная. Что же, далее, мы, оба этих мустизатора высылают апдейт на мустизатор R-2. На мустизатор R-2.

А они только на R-2 высылают? То есть получается такая, как волна, как диффузия в UGRP, или они во все стороны рассылают? Они на самом деле рассылают их во все стороны, то есть они рассылают их всем своим LDP-соседям. LDP-соседям. Я просто не показываю обратное распространение этого префикса, потому что вся логика будет понятна, когда мы разберем примерчик, что происходит на мустизаторе R-2. Смотрите, на мустизаторе R-2 на мустизаторе R-2 у нас есть префикс, да, там A-24. По сути, по сути, мы получаем две remote label. То есть мы получаем метку 300 и мы получаем метку 600. То есть мы метку 300 получаем от мустизатора R-3 и метку 600 мы получаем от мустизатора R-6. От мустизатора R-6. Соответственно, на мустизаторе R-2 на мустизаторе R-2 встает вопрос,

какую из этих двух меточек принять. какую из этих двух меточек принять. Почему бы не принять обе? Это возможно, но далеко не на всех железках. То есть, теоретически, мы можем использовать MPLS EcoCost Multipassing, но я не уверен, что оно работает на, скажем так, на low-end устройствах. Я тут, к сожалению, не дам гарантии. Нужно смотреть просто Configuration Guide для каждой конкретной версии софта, для каждой версии устройств. В целом, мы можем заинсталлировать две метки и использовать два NextHop. Но, если нам нужно выбрать один, нужно выбрать один. Как мы поступаем? На самом деле, все очень просто. Мужцизатор R2 выдает команду,

условно говоря, showIperOut на некий префикс. На вот этот префикс. В выводе этой команды вы увидите NextHop и вы увидите выходной интерфейс. Вы увидите выходной интерфейс. Соответственно, вот, например, это 0.1, это 0.2. Соответственно, предположим, что в качестве выходного интерфейса на мужцизаторе R2 был выбран интерфейс 0.2. В этом случае метка от мужцизатора R6 не будет инсталлирована в вашу базу данных LDP-шную, а будет использоваться метка от мужцизатора R3. Соответственно, дальше на мужцизаторе R2 мы генерируем свою локальную метку 200 и передаем ее в сторону мужцизатора R1. То есть, на мужцизаторе R1 у нас remote label 200,

некая локальная метка 100. А у меня важный вопрос. Да. Одновременно ли происходят процессы рассылки всех этих меток, или они происходят вот так, как ты нарисовал сначала один, потом второй, потом третий, дождался анонса от второго, переслал дальше, ну, примерно, как в RIP. То есть, в RIP, это когда к нам приходит анонс, мы его пересылаем дальше, следующий не может разослать этот анонс своему соседу до тех пор, пока его не получил. Я тебя понял. С настройками по умолчанию, по сути, рассылка меток у вас стартует, как только у вас поднялась LDP-сессия между устройствами. И иногда, иногда это может приводить к не очень, скажем так, к печальным последствиям. В частности, в частности, да, в частности. Предположим, предположим, да, ну, конечно, немножко забежал вперед, я там собирался об этом на следующих занятиях рассказать, но пока в верхней...

То есть, может быть такое, что R2 отправит анонс по LDP и просетку Routro R1 до того, как и опять расскажет по R2. Да, такая ситуация теоретически возможно. Иллюстрируется вот таким примером. Представьте, что у нас сеть стабильна, да, у нас все сконвергировалось, все работает, все хорошо. Теперь, предположим, что у нас падает линк между маршрутизаторами R2 и R3. И, падает ли. Упал, например, соседство там, OSPF-ное, упала, LDP-сессия упала, на трафик стал ходить через маршрутизатор R6. Теперь, предположим, что линк у нас обратно поднимается. Что у нас произойдет? Что у нас произойдет? Смотрите, у нас сойдется прежде всего OSPF. маршрутизатор R2 перенастроит свою таблицу маршрутизации таким образом, что выходной интерфейс настанет интерфейс 0.2 и начнет

высылать пакеты в сторону маршрутизатора R3. Но, но, как я вам сказал, LDP – это TCP-шная сессия. И эта TCP-шная сессия, она может быть построена уже только после того, как сошлась ваша маршрутизация. То есть, потребуется некоторое время. То есть, у нас между маршрутизаторами R2 и R3 поднялся OSPF Neighborships. После этого, там, в течение, не знаю, секунды, может быть, двух, это может быть, доли секунды, какое-то время потребуется для того, чтобы TCP-сессия поднялась. Потребуется какое-то время обменяться метками, чтобы сеть сконвергировала. И вот, пока вот эта TCP-сессия устанавливается, пока происходит обмен меточками, что будет происходить с нашими пакетами? С нашими пакетами. Они, по сути, будут отсылаться

на те интерфейсы, на которых, которые еще ничего о метках не знают. Чем это нам может грозить? скажу вам сразу, что ваши L2, L3, VPN, в общем, любые сервисы, которые будут требовать наличия меточек при транспорте, они все будут рушиться на это время. Есть, естественно, методы, как с этим бороться, но об этом не сегодня. Об этом не сегодня. то есть, резюмируя, у нас отдельно происходит процесс передачи маршрутов. Для этого нужен, например, SPF или BGP или что-то другое. И этот процесс волнообразный, то есть у нас зародилась сети сетка А, и дальше все маршрутизаторы потихоньку начинают про эту сеть узнавать. И потом совершенно отдельно от этого, никак не связано с этим, отдельный процесс рассылает указания, какие метки на какие маршруты следуют назначаться. Да, абсолютно верно.

То есть, по умолчанию эти два процесса никак не связаны между собой. Это, ты знаешь, как, я когда тоже сеть только изучал, у меня часто возникали вопросы, как, например, вот у тебя есть, например, сети ХСРП, и есть, например, ОСПФ, да, и у меня возникал вопрос, а как ОСПФ будет пересылать пакет на виртуальный ХСРП адрес на IP. Ответ, собственно говоря, никак. Это два разных куска кода, которые находятся в операционной системе, то есть, это два разных процесса между собой никак не связаны. Здесь примерно так же, то есть, ОСПФ живет отдельно, ЛДП живет отдельно. Единственное, что, если мы вот ХСРП и ОСПФ мы связать в принципе никак не можем, у нас нет такой возможности, ну, оно там и не надо, конечно, то здесь у нас есть некие средства, которые позволят эти два протокола засинхронизировать друг с другом. То есть, мы можем сделать так, чтобы вот мурциатор R2 в нашем примере

не слал пакеты в сторону мурциатора R3 до тех пор, пока там ЛДП не сойдется полностью. Как это работает? Вам нужно будет просто немножко запасить терпение. Окей, окей, смотрите, меточками мы обменялись, то есть, вот мы обменялись метками. Что же у нас теперь, как у нас теперь будут передаваться, как у нас теперь будут передаваться IP пакеты? Ну, предположим, что у нас пакет бежит из некой сети B в некую сеть A. Смотрите, я вот здесь нарисую, вот это у нас будет первый шаг, второй шаг, третий шаг, четвертый шаг, пятый шаг и шестой шаг. Давайте вместе думать. На первом, смотрите, это может быть просто компьютер некий подключен. Здесь у нас, вот здесь никакой LDP не работает,

никакой LDP здесь не работает. Соответственно, на первом шаге компьютер высылает обычный ARP-запрос, мусоратор R1 обрабатывает этот ARP-запрос, соответственно, отвечает ARP-reply, и дальше компьютер B генерирует обычный IPv4 пакет. То есть, у нас, соответственно, есть некое поле данных, которое так или иначе потом инкапсулируется в IPv4, в IPv4, и он инкапсулируется дальше в L2. Соответственно, в качестве сурс MAC-адреса у нас выступает MAC-адрес станции B в качестве destination MAC-а выступает R1, выступает R1. Здесь все просто, здесь все стандартно. Некие изменения, как вы могли догадаться, могут начаться на шаге 2. Смотрите, муницизатор R2

первым делом говорит, я хочу, я смотрю show IPRout, show IPRout, R1, куда мы идем? Мы идем на сеть A. То есть, но... Извини, а почему R2, когда у нас пока только R1? Второй шаг, второй шаг, мы смотрим на муницизаторы R1. Если оговорился, извиняюсь. Муницизаторы R1 смотрят show IPRout, сеть A, видят, что выходной интерфейс 0.1, и он увидит, что на этом интерфейсе, на этом интерфейсе включена, включим протокол LDP, то есть, включена передача посредством меток. В выводе вы это увидите посредством команды MPLS enable. То есть, конечно, выводы могут там немножко отличаться, но все в том, что там будет написано на интерфейсе включен MPLS. А, соответственно, муницизатор думает, ага, соответственно, но я через этот интерфейс

должен был получить какие-то метки. И он начинает смотреть вот эту свою табличку, которую мы с вами сформировали на прошлом шаге. Он видит, что через интерфейс 0.1 была получена метка 200. Была получена метка 200. Поэтому, поэтому, что он делает? Он берет вот эти данные, берет вот эти данные, инкапсулирует их в IP. Я немножко дополню, она получена не просто через интерфейс, а она получена именно от NextHop, который в таблице маршрутизации помечен NextHop. Да. Соответственно, вот здесь вот у нас будет, будут заголовки MAC-адресов, да, и между ними, между ними вклинивается новый заголовок, который называется MPLS-заголовок. В частности, в частности, да, сюда, вот как раз сюда и будет вставляться наша меточка 200.

будет вставляться наша меточка 200. Там, на самом деле, там вставляется не только сама метка, там есть некие дополнительные поля. С частью этих полей мы еще столкнемся в течение этого курса, да, с частью полей нет. Одним из важных, наверное, одним из важных полей, которые здесь есть, есть также поле TTL. Ну, на самом деле, назначение этого поля абсолютно такое же, как назначение поля TTL в IP4 пакете, да, это разрыв петли на дата-плейне при каких-то неполадках на контрол-плейне. Ну, то есть, например, у вас там муртизация, ну, например, да, вы два статических маршрута на муртизаторах там прописали друг на друга, например, два дефолта, которые смотрят друг на друга. То есть, вы получаете infinite loop, и эта петля разрывается только на дата-плейне, когда у вас TTL падает в ноль.

Вот, здесь то же самое, то есть, это поле нужно абсолютно для того же. Естественно, этот пакетик, этот пакетик вот таким вот образом передается на муртизатор R2. То есть, суть в том, что мы здесь ставим метку 200, которую от этого муртизатора мы и получили. Далее, далее, пакет прилетает на муртизатор R2, на муртизатор R2. Соответственно, муртизатор R2 получает этот пакет, видит, видит, что получил метку 200. Получил метку 200. Он думает, ага, а что это такая за метка? Он лезет, он начинает проверять свою табличку, свою табличку, и находит, что метка 200, это действительно метка, которая находится, я, к сожалению, здесь тер, вот этот столбец у нас называется local label. Local label. Я помню, когда я учил этот процесс с самого начала, я испытывал сложности с пониманием того, что такое local label и что такое remote label. У тебя есть какие-нибудь

советы, как легко и быстро запомнить, что из этого для чего нужно? Исключительно от названия. Local label – это то, что сгенерировали мы и передали соседям. Remote label – это то, что мы от соседей установили. Соответственно, когда мы пакет принимаем, мы всегда, то есть мы, когда пакет принимаем, мы должны решить, что с ним делать. Соответственно, нам нужно этот пакет как-то идентифицировать. Для идентификации пакета используется вот этот столбец local label. То есть метку 200. То есть, по сути, когда мы придумали какую-то метку, мы ее назвали local label, записали в таблицу local label к себе, дальше мы ее отправили своим соседям, тем самым указываем, ребята, когда вы хотите послать трафик до этой сети к нам, используйте метку 200, мы метку 200 назначили на эту сеть. Да, а мы уже там разберемся, что с этим пакетом делать дальше. Соответственно, мы видим, что этой метке 200 у нас есть соответствие метка 300,

на которой мы получили от маршрутизатора R3. Поэтому, поэтому, на самом деле, здесь происходит операция, которая называется swap. в литературе вы ее можете увидеть. По сути, у нас просто метка 200, она заменяется на метку 300, и такой, и пакет выплевывается в сторону маршрутизатора R3. Но, ребята, дальше тут нетрудно догадаться, что происходит. На следующем шаге у нас метка 300 меняется на метку 400, на метку 500, ну и, соответственно, на шестом шаге, то есть, у нас эта метка 500, она просто, условно говоря, снимается и передается нативный IPv4 пакет уже в сторону конечного хоста A. В сторону конечного хоста A.

Вот таким вот образом обратите внимание, что, да, конечно, на контрплейне, да, на контрплейне мы вот пока что, пока что вынуждены обмениваться сетями A и B, да, но на уровне датаплейна, когда пакетик бежит, заметьте, у нас все транзитные маршрутизаторы в IP-заголовок уже не смотрят, да, они смотрят только на метку, они смотрят только на метку. Окей.