Конфигурация LDP в MPLS

Пока что очень много цифр, очень много меток. Хочется как-то посмотреть это на практике. Да, естественно, мы до этого дойдем. Что касается практики. На самом деле, я думаю, что с точки зрения теории, я как раз хотел ограничиться сегодня тем, как эти метки распространяются, и как потом будет выглядеть пакет на дата плей. Ребят, с точки зрения лаба. У меня, если вам там, я вам потом спокойно расшарю вирус. У меня лабораторная работа построена на верле. Соответственно, физическая топология. Давайте я вот здесь. Физическая топология представляет собой 14 муртизаторов. Это муртизаторы из SR1000B. Почти все соединены между собой через неуправляемый свитч.

Плюс есть прямые соединения между муртизаторами R2, R12, R1, R11. Там, здесь у меня, я когда переделал, будет... Так, сейчас, секундочку. Просто... Ну, тут, на самом деле, не сильно важно. Короче, ну что запутать хочу? За хорошее зрение 100 рублей премия. Да. Вот примерно так вот выглядит топология. Вот эти выделенные линки нам потребуются, когда мы будем с вами рассматривать VPLS. Да, просто дело в том, что VPLS будет работать у нас на SR1000B только в том случае, если клиентские устройства будут подключены через физический интерфейс. Через саб-интерфейс это не заведется. Далее, далее. С точки зрения L3, с точки зрения L3 у нас вот эта физическая топология, она преобразуется вот в такую топологию.

То есть, да, то есть ее, условно говоря, можно разделить на две части. Смотрите, марштизаторы от R11, R12, R13 и R14, они будут выступать в качестве клиентских устройств. Да, то есть это будет эмуляция клиентского подключения. Все остальное это марштизаторы-провайдеры. Марштизаторы-провайдеры. С точки зрения IP-адресации у каждого марштизатора будет свой лукбэк. Этот лукбэк находится в диапазоне 150XXX-32. То есть, соответственно, для марштизатора R1 это будет IP-адрес 150.1.1.1. Для марштизатора R2 там будет IP-адрес 150.2.2.2.2. И point-to-point линки – это некие сети 10 что-то. Для примера, вот если у нас есть некая сеть между марштизаторами, скажем, R2 и R6, то это будет сеть 10.2.6.0.24.

У нас, соответственно, на марштизаторе R2 будет IP-адрес 10.2.6.2. На марштизаторе R6 будет IP-адрес 10.2.6.6. 10.2.6.6. Ну, то есть я думаю, что здесь ничего сложного нет. Так. А ты можешь поделиться с нами вот этими всеми картинками, чтобы мы потом… Картинками поделюсь. Я их специально залил, как видишь, на Google Drive. Ипотека это не то. На Google Drive. Вот. И после занятия я просто расшарю на самом деле ссылку. Вот. И оттуда можно будет все скачать. То есть я их в PDF сохранил, поскольку я видел, не рисуем. Так. Так, так, так. Соответственно, у меня есть преднастроенные мустизаторы. У меня есть преднастроенные мустизаторы. Упс. Я вам покажу, что у меня преднастроено. На самом деле преднастроено не так уж и много.

Я покажу на примере мустизатора R1. С видите, конфликт совсем небольшой. Преднастроен интерфейс Lubbac. И преднастроены вот эти все транзитные интерфейсы. То есть у меня, видите, настроен интерфейс G2.15, G2.18 интерфейс G3. И включен OSPF. Включен OSPF. Вручную задан router ID. Рouter ID совпадает с адресом Lubbac 0, чтобы нам никогда не путаться. Далее, ребят, здесь включен PASIF интерфейс G1. На это можно не обращать внимания. В тех конфликтах я расшарил. Это исключительно, скажем так, специфика верла, поскольку интерфейс G1 используется для... Подразумевает, что он используется для управления этим устройством. Что это а-ля интерфейс менеджмент. Но поскольку у меня находится он немножко в работающей сети,

на этом интерфейсе поднимаются IP-адреса. Если я просто включу OSPF на этом интерфейсе, то у меня все маршрутизаторы, абсолютно все маршрутизаторы, они поднимут OSPF в соседство друг с другом. И будут передавать данные напрямую, а не через вот эту логическую платформу. И здесь, собственно говоря, у меня включена команда Network. Вот такая конструкция. Я думаю, она должна быть вам знакома. Скажите, пожалуйста, в чате есть ли те, кто не понимает, то есть у кого могут возникнуть вопросы, что делает вот эта команда? Как будто бы все понимают. Хорошо. Ну, собственно говоря, чтобы подтвердить или опровергнуть наши ожидания, я дам просто команду showip ospf interface brief и дам команду showip interface brief.

И вы увидите, что у меня вот эти списки абсолютно совпадают. То есть у меня есть раз, два, три, четыре, пять. Раз, пять интерфейсов, на которых есть IP-адреса. И, собственно говоря, раз, два, три, четыре, пять интерфейсов, на которых включен OSP. То есть, по сути, эта команда просто помещает, на самом деле, все мои интерфейсы в OSPF area. Ну, собственно говоря, ребят, не забываем, что интерфейс G1 просто в процессе нашей работы мы спокойно игнорируем. Мы спокойно игнорируем. Собственно говоря, давайте проверим, что у меня есть действительно connectivity, showip route OSPF. Собственно, видите, у меня есть большое-большое количество маршрутов. Большое-большое количество маршрутов. Давайте include 150, исключительно лопбеки посмотрим. То есть, у меня первый мустизатор знает о втором, о третьем, о четвертом, о пятом, о шестом, о седьмом, о восьмом, о девятом, о десятом.

То есть, мустизаторы R11, R14. Да, мустизаторы R11, R14. На них OSPF не сконфигурирован. То есть, на них просто заданы IP-адреса. Не более того. Они нам пока не нужны. И, соответственно, если посмотреть на топологию, то самый длинный путь у нас будет между мустизаторами R1 и мустизатором R2. Единственное, я вот так вот сделаю. Открою в этом в PDF. В PDF. Надо, насколько в нем можно. Ну, удобнее просто в нем рисовать. Comment. Ну, то есть, соответственно, у меня пакет должен идти, ну, каким-то вот таким вот образом. То есть, это будет самый длинный исследованный пакет. Соответственно, если... Давайте проверим. Пинк 150222, SOSLBK0.

Все есть. Traceroute. 52222, SOSLBK0. Мемерик. Вот. Собственно, как вы видите, да, с IP connectivity у нас здесь все в порядке. Давайте попробуем установить LDP-соседство. LDP-соседство между мустизатором, например, между мустизатором R1 и R5. Итак, ребят, прежде всего, прежде всего для работы, скажем так, для возможности передачи пакетов, у которых вот есть вот этот заголовочек MPLS, нам обязательно потребуется, чтобы у вас, у нас работал CERF. Что, IP-CERF? Я думаю, что он на всех устройствах у вас будет включен по умолчанию. Да. Извини, я тебя перебью, не все могут знать, что такое CERF. Может быть, ты расскажешь? Далее. Глобально-глобально включаем поддержку вот этих меток.

Это глобальная команда MPLS IP. Единственное, в большинстве средств современных платформ она включена по умолчанию, и, собственно говоря, также на самом деле особой необходимости нет. Но это не менее. Далее. Далее. Помните, я вам говорил, что наша LDP-сессия, она строится между транспортными адресами. И по умолчанию транспортный адрес – это есть наш раутер ID. По-хорошему, по-хорошему, этот раутер ID желательно задать. Делается эта команда MPLS LDP. И здесь есть командочка раутер ID. Далее. Далее. Указываем, какой интерфейс, то есть IP-адрес какого интерфейса мы будем использовать в качестве раутера ID. Лоббат. Далее. Обратите внимание, что здесь есть ключевая команда force. Для чего она нужна? Дело в том, что если вы поменяете раутер ID, уже для работающих сессий LDP, он поменен не будет.

Команда force позволяет изменить это поведение. То есть, условно говоря, если вы говорите force, это значит, что ваши все LDP-сессии, они будут, скажем так, они рестартанутся. Я обычно, то есть, при конфигурации с нуля, обычно все равно, на самом деле, включаю эту команду. MPLS LDP router ID force. Соответственно, ребят, по сути, нам нужно включить, как вы понимаете, эту команду на всех мультизаторах. Единственное, за исключением вот этих вот. Так. Я, с вашего позволения, просто сразу во все сессии отправлю. MPLS LDP router ID. Так. Окей. Следующее, следующее. Если мы вернемся к началу нашего занятия, то вспомним, что LDP работает на линке.

Да. То есть, но. Мы должны включить протокольчик LDP на конкретном интерфейсе. То есть, но. Нам уже следует, говорим. Интерфейс G2.15. И нам здесь достаточно, ребят, дать команду просто MPLS IP. То есть, MPLS IP делает две вещи. Первая. Включает возможность передачи пакетов. Передачи пакетов через этот интерфейс с меткой. Ну, соответственно, и позволяет принимать пакеты с меткой. Это раз. И второе. Включает LDP рассылку. Включает LDP рассылку. Единственное, что здесь, давайте я на интерфейсе R5, я пока погашу наш лупбэк, чтобы вам просто кое-что продемонстрировать. И на амортизаторе R5 на интерфейсе G2.15 говорим MPLS IP.

Итак, проверяем. Show MPLS интерфейс. Вот видите, у меня включен MPLS включен на интерфейсе 2.15. Видите, yes. То есть, говорит о том, что передача меток на этом интерфейсе активирована. Включен протокол LDP. Status operational, yes. Далее. Здесь есть еще дополнительные поля. В частности, static, tunnel и BGP. Дело в том, что метки можно передавать не только посредством протокола LDP. Их, как отсюда вы видите, можно конфигурировать статически. Но это не очень удобно. Эти метки можно передавать посредством протокола BGP. Tunnel. Tunnel – это из области traffic engineering. Это мы рассмотрим ближе к концу нашего курса. Соответственно, ребята, статическую настройку мы с вами рассматривать не будем. А вот с передачей меток посредством BGP мы разберемся.

Итак, смотрите, я включил рассылку. Соответственно, они, по идее, должны друг друга увидеть. ShowMPLS LDP Discovery. Видим, что у меня есть интерфейс E2.15. И, соответственно, через него XMID мы передаем. На мартизаторе R5. На мартизаторе R5. ShowMPLS LDP. И ставим. Через интерфейс, как мы говорим, мы также передаем. ShowMPLS LDP. И ставим. Neighbors. Алексей, извини, пожалуйста. Вопрос был, что такое XMID.

Обратите внимание, что Neighbors-то у нас и нет. А все почему? Посмотрите. Если я на интерфейсе, если я сделаю NoShot. NoShot. Видите? Lookback поднялся. Lookback поднялся. 150222. Так, и через какое-то время у нас должна подняться TCP-сессия. ShowIPRoute 150555. Сейчас. То есть у нас есть... Ой. Сейчас. Нет, никто мне не сказал, что я вот это все настраиваю на мартизаторе R2.

Видите? Здесь вообще не должно быть такого интерфейса. NoInterface B2.15. NoInterface B2.15. Мне нужен интерфейс 1. О, router 1. B2.15. B2.15. Итак. Neighbors-ад. То есть смотрите. ShowMPLS LDP Discovery. Обратите внимание, что... Это как раз показывает то, что мы видим посредством UDP. То есть это инициальный поиск, первоначальный поиск возможных соседей. То есть говорит нам о том, что мы на интерфейсе G2.15 отправляем и получаем какие-то UDP Hello. В частности, мы получаем UDP Hello от мартизатора 150555. Далее, далее.

Мы пытаемся с ним построить TCP-сессию. ShowMPLS LDP Neighbors. В частности, видите, что у нас построилась TCP-сессия. Она построилась между адресами 150.1.1.1. То есть это наш адрес. И 150.5.5.5. Это адрес удаленного соседа. Вот это число 646. Это, собственно говоря, LDP-шный порт. Здесь видно, что мартизатор R1 выступает в качестве сервера, а мартизатор R5 выступает в качестве клиента. Рандомный порт. В качестве source IP для построения TCP-сессии мы используем адрес 10.1.5.5. По сути, нам нужно вот эту процедуру. То есть showrun interface G2.15. Повторить на самом деле просто на всех интерфейсах. Говорим interface G2.18.

Говорим на POS API. Говорим на POS API. А представьте, что у меня вот видите, есть мартизатор, например, R3. У него там 1, 2, 3, 4 интерфейса. А может быть там какой-нибудь мартизатор, например, у меня 100 интерфейсов будет, саб-интерфейсов. И что же, неужели нужно вот так вот на каждом интерфейсе включать поддержку LDP? Можно, можно. Но есть обходной вариант. Есть обходной вариант. В частности, в частности, можно зайти в режим контигурации протокола амортизации. В моем случае это router SPF1. И здесь, если посмотреть доступные нам команды, есть что-то касаемо MPLS. MPLS, LDP, автоконфиг.

Что делает эта команда, ребята? Смотрите. Show IP SPF интерфейс break. Эта команда находит все интерфейсы, которые, на которых включен SPF. и на всех этих интерфейсах включает рассылку LDP. При желании, при желании, вы можете включить LDP рассылку на интерфейсах, которые относятся к конкретной зоне. Show MPLS interfaces. Видите, у меня вот они все включены. Все очень просто. То есть, в принципе, достаточно дать одну команду. То есть, достаточно дать одну команду. Так. Постяну. Так. R1 я уже настроил. Это будет exit. И дальше я просто говорю. Router SPF1. MPLS LDP.

Автоконфиг. У меня начинают подниматься соседи. У меня начинают подниматься соседи. Алексей, извини, пожалуйста. Вопрос был в чате. Не знаю, видел это или нет. Итак, и так. Естественно, теперь, если я теперь сделаю Traceroute на 152.22 SourceLobb0 Numeric. Обратите внимание, обратите внимание, что у нас Traceroute несколько видов изменился. Несколько видов изменился. И видите, если мы его сравним, я не знаю, у нас сохранился вывод Traceroute. Да, то есть, видите, трассировка была вот такой, да? Трассировка была вот такой. Да, Иннокентий, я вижу, отвечу, сейчас мысль закончу, да, и постараюсь ответить на вопрос.

Трассировочка стала вот такой. То есть, видите, появились какие-то MPLS-ные методы. Что это за метки? Смотрите. Эти метки можно посмотреть командой showMPLS-for-рогтейбл. Обратите внимание, здесь есть примерно все то же самое, да, только чуть больше, вот как я вам рисовал. То есть, у нас есть наш префикс. Да, префикс. Вот префикс, например, 150.222. 150.222. Далее. Далее. Outgoing интерфейс. Вот он. Local label и outgoing label. Да, то есть, это то, что я называл local label и remote label. В частности, посмотрите, мы сгенерировали для префиксов 150.222, локальную метку 28, и метку 30 мы получили от наших соседей, от пятого и от восьмого.

вот. Вот. 10.1.5.5. Мы от них получили метку 30. Соответственно, когда мы запускаем трассу, мы видим, что эта метка равна 30. Вот она. Меточек 30. Далее. Пакет попадает, например, на маршрутизатор R5. Show impuls forwarding table. Давайте для конкретного префикса посмотрим. 105.222. Слышь 32. Вот. Нам маршрутизатор R5, вот она, видите, локальная метка 30. Локальная метка 30. Это как раз та метка, которую мы используем в качестве outgoing метки. тесты. Тесты. Но. Маршрутизатор R5 получает пакет с меткой 30, с меткой 30 и переменяет ее на метку 28.

И высылает этот пакет на интерфейс D2.35 в сторону маршрутизатора R5. Уже с меткой 28. собственно говоря, мы вот это в трассировке и видим. Вот она, пошла. Ну и дальше, вы видите, здесь у нас просто в примере так метки сошлись, что используются только 28.30, но в целом, в целом, эти метки генерируются каждым маршрутизатором независимым друг от друга. Вот таким вот образом происходит передача пакетов в сети с метками. Какие это бенефиты нам дает? Об этом мы поговорим уже с вами на следующем занятии. А сейчас у нас в чате есть два вопроса. Вопрос от Алексея и вопрос от Сергея. Вопрос Алексея, что такое CEF? Алексей, если ответить

совсем кратко, это Cisco Express Forward. Скажем так, по сути, по сути, это метод, я не знаю, метод, не метод, это некий алгоритм того, как префиксы, префиксы, которые выучены вами на уровне Control Plane, программируются в ваши асики, в вашей линейной плате. по CEF у CISC есть прям отдельная прям отдельная книжка или как минимум статья. understanding CISC CEF. И вот, собственно говоря, по сути, прям первая статья ведет вас на Cisco.com. Она, конечно, довольно старая, но принципы там изложены довольно-таки

неплохо, да, то есть она для 12 тысяч маршрутизаторов, но все в том, что она как раз описывает, как работает CEF, то есть как работает конкретный алгоритм на цифровых маршрутизаторах. вопрос от Сергея. Можно уточнить про назначение в секции OSPF строки по маршруту? Сергей, это не маршрут. Итак, showrun section OSPF. это просто включение OSPF на всех интерфейсах, на которых есть IP-адрес, и все эти интерфейсы мы кладем в OSPF зону 0. Так, вопрос от Евгения. Ребята, давайте сюда. Вопрос от Евгения. Что-то нужно будет ставить для лап?

Жень, смотри, я вам как бы как таковых заданий давать не буду. Тут исключительно все на ваше усмотрение. Вы можете использовать EVNG, вы можете использовать реальные обороны, вы можете использовать GNS, да? Максимум, что я могу дать, это просто готовую вот эту Viral-топологию, и именно под эту топологию я буду выкладывать в итоге те или иные файлы конфигурации. То есть, если у вас есть Viral, вам будет немножко проще. Если нет, используйте, например, EVNG. Еваня. Василий, а что ты подразумеваешь под недефолтным режимом генерации номеров меток? Ты имеешь в виду, зачем мы можем изменить, скажем, диапазон? А, ну, особо, на самом деле, это не, ну, особо ничем. то есть, ну,

особо не для чего. То есть, я ни разу не видел ситуации, когда бы MPLS label range приходилось бы модифицировать. Может быть, может быть, если у вас, скажем так, есть сеть, которая образована слиянием нескольких независимых IGP-доменов, вам, вы можете для каждого IGP-домена задать свой диапазон, и вы просто в трассировке будете прям понимать, по какому диапазону, в какой, ну, где у вас идет пакет. То есть, ну, прям просто по номерам метков, просто по номерам метков вы можете понимать, там, что это за устройство. Вот, по правде говоря, например, EOS и EOS XR используют дефолтные разные диапазоны, и вот EOS и EOS XR очень хорошо видны в трассировке. Вопрос, я извиняюсь, я не знаю, как зовут вот человека, вот, B, Fatiho, MPLS IP Auto Configuration принятая практика для лучшего настраивания в частности

для понимания что-то запад. Смотри, в принципе, в использовании MPLS Auto Config ничего страшного нет. Почему? Потому что в любом случае у тебя интерфейсы, которые смотрят в сторону заказчика, да, в сторону заказчика, они будут так или иначе помещены в VRF, да, и по умолчанию там работают, ну, как бы, метки там работать не будут. Единственное, что, есть advanced сценарии, в частности, для carrier support carrier, то есть, это когда у вас один провайдер дает услуги другому провайдеру. Иногда, иногда вот у Juniper, например, очень удобно можно включить MPLS на интерфейсе, но сделать его пассивным. То есть, нам нужно включить передачу по меткам, но нам не нужно строить LDP соседства. И вот в этом случае, в этом случае, то есть, нам бы не хотелось в CISC, то есть, в Juniper мы просто делаем как LDP passive интерфейс, да, а в CISC мы

вынуждены MPLS там просто не включать, да, а MPLS IP автоконфигурация там включим. То есть, я бы сказал так, использовать MPLS автоконфиг можно всегда, за исключением случаев, если ты понимаешь, что прямо тебе на некоторых интерфейсах этого делать не надо. Вопрос на счет генерации меток меняется при разрыве с CISC между PM. Слушай, смотри, вообще, вообще, как бы метка генерируется каждый раз, когда у тебя появляется новый, так называемый, ну, forwarding relation class. Ну, по сути, то есть, если у тебя префикс пропал, потом появился, для него будет сгенерирована новая метка, да, ну, на самом деле, довольно большая вероятность, что она численно будет абсолютно такая же, как была раньше, да, но она сейчас, как бы, ну, она может быть абсолютно любой, на самом деле. Ин, смотри, давай сейчас

зайдем метки на роутер, я не думаю, что это на самом деле нужно, мы потом, мы в любом случае, там, на следующем занятии будем смотреть, как нам не генерировать метки на транзитные префиксы, поскольку нам чаще всего нужны только на лубэке, я предлагаю просто на следующие занятия оставить, так, в целом, нам главное просто, в общем, при верификации, когда вы запускаете стресс-раут, просто главное видеть, что у вас есть какие-то метки, какие они, в принципе, это уже вопрос десятый, главное, чтобы они были. Искрен, это вопрос риторический, мне на самом деле все, честно говоря, все равно, кто-то его называет как лейер 2,5, поскольку заголовок вклинивается между классическим заголовком второго уровня и классическим заголовком третьего уровня. Не суть важна,

считай, что это заголовки 2,5. Вон, да, тебе, Макенчий, гораздо лучше по таким темам проконсультировать, нежели я. Окей, ссылка будет там. Ну, ребят, в общем-то, на сегодня все, продолжим завтра. Субтитры сделал DimaTorzok Продолжение следует...