Настройка MPLS L3 VPN: часть 2

Давайте попробуем на мартизаторе R11. На мартизаторе R11. Show IP, здесь brief. У меня адрес 10.1.11.1. 4. Pink. Почему? Почему? Да, на R4 надо, но... Извиняюсь, я не оттуда сделал пинг, вот отсюда. Pink нет. На мартизаторе R4... Да, я думаю, может быть, просто пропустил, но у нас интерфейс уже висит внутри VRAF. Обратите внимание, что пинга все равно нет между клиентскими мартизаторами. Почему?

Show IPR out. На статический маршрут не обращаем внимания. Вот таблица мартизации актуальная, по сути. Обратите внимание, у нас нет маршрута на удаленную сеть. То есть у нас есть два кастомера, но они не знают маршруту еще друг друга. То есть маршрута R14 на самом деле просто не знает, как пускать пакет, куда пускать пакет. Давайте решим эту проблему, ну, например, просто пока что прописав статический маршрут. На следующем занятии мы поговорим о том, как настраивать динамические партнерские партнерские партнеры в такой инфраструктуре. Команда, собственно говоря, IPR out. Нас интересует сеть, например, 10, 1, 11, 0. Булат, извини, конкретизируем мысли, я здесь немножко тебя не понял.

10, 4, 14, 4. И обратный маршрут на R11. IPR out 10, 4, 14, 0. Через 10, 1, 11, 0. Так, маршрутики я прописал. Маршрутики я прописал. Между дарик и дарик и дарик и сетей. Пинк. Вуаля. Вуаля. У нас пинк работает. Соответственно, если мы... Давайте теперь с вами запустим трассу. Трейсраут. Или давайте даже запустим, знаете, с вами не трассу, а посмотрим пакет Кэпчу. Пакет Кэпчу. В частности, давайте мы... То есть у нас пакет как идет? У нас пакет идет с маршрутизатора R14 до маршрутизатора R4.

У нас здесь идет чистый IPv4 пакет. Далее. С R4 пакет побежит в сторону маршрутизатора R1. Здесь это будет MPLS. И дальше пакет выплевывается, как обычный IPv4. Давайте с вашего позволения я возьму пакет Кэпчу, например, на маршрутизаторе R9. Да, может, и за R9. И я буду смотреть, что происходит, ну, например, вот на этом интерфейсе, G2.39. Так. Соответственно, меня интересует мой CSR. Так. Тысяча... Так. Меня интересует... Тысяча... Меня интересует интерфейс G2. Меня интересует интерфейс G2.

Так. Ставим галочку. Traffic capture. А на втором Сär behaviour. А на второй набор способит... Ег모wang talks of theubs. И на второй слове. Можем ли у меня видимо просто разлагинить. Тьсс. Меня интересует... Так. Так.

Так. EVM. Идем в Semulations. Теперь меня интересует Packet Capture. Для интерфейса Giga1. Так. Все правильно. Offline Capture to File. Я просто не уверен, что у меня Live Capture заведется на

Mac. Я просто честно говоря вам не... Okay. Successfully created. Давайте сделаем ping. Сделаем паближку. Ок. Так. Теперь давайте посмотрим, что у нас там в этом файле есть. Так. Так. Меня часто здесь будет интересоваться протоколы CMP. Обратите внимание, что у нас пакет шел с муртизатора R1 в сторону муртизатора R14. Вот. То есть что у нас было? Вот наш, собственно говоря, непосредственно ICMP payload. То есть это reply. А я откуда пинги запускал? А я запускал с 14-го. Давайте с этого интерфейса. То есть у нас пакет тип ICMP request. И вот пакет тип ICMP request. И вот мы видим, что у нас пакет шел с муртизатора R1 в сторону муртизатора R14. То есть что у нас было? Вот наш, собственно говоря, непосредственно ICMP payload. То есть это reply.

Это reply. А я откуда ping запускал? А, я запускал с 14-го. Давайте вот с этого интерфейса. Вот. То есть у нас пакет тип ICMP request. Сурс адрес на адрес нашего муртизатора R14. Дестинейшн адрес – адрес муртизатора R11. И далее обратите внимание, что у нас есть два MPLS-ных заголовка. То есть у нас есть две MPLS-ные метки. То есть у нас есть метка номер 37, и есть метка номер 29. Да? Очень интересно. То есть у нас… Мы с вами в прошлом примере говорили, у нас была всего одна MPLS-метка. Сейчас у нас есть две MPLS-метки. И чем они, помимо всего прочего, отличаются? Смотрите. Помимо прочего, видите, здесь есть S. То есть помните, я вам говорил, что есть так называемый флаг окончания стэка. То есть для метки 37 этот флаг выставлен в единичку.

То есть говорит о том, что это bottom of the stack. И метка 29. Давайте посмотрим, что это такое. Мы трафик снимали на марштизаторе R9. Мы трафик снимали на марштизаторе R9. как This one. Это겠� Rayfin?" cualee… She по моему еще со вчерашнего поплохело я боюсь что мне нужно будет ребутнуть я думаю что это будет быстро

чтобы не снимать еще один дам трафика пока пока найдет его загрузка давайте вернемся вот к нашему амортизатору R1 show bgp vpnv4 unicast all для префикса 10.1.1.1.0.1.2.4 обратите внимание что у нас есть некая mpls метка в направлении in и она равна числу 37 и при этом при этом мы эту же меточку видим в нашем capture

а что будет сейчас ничего не будет поскольку амортизатор грузится то есть что у нас получается на самом деле с точки зрения control plane с точки зрения control plane вот есть мой амортизатор p1 и мой амортизатор p2 между ними между ними выстроена vpnv4 ss p1 отправляет сюда префикс 10.1.1.0.24 и помимо прочего помимо прочего добавляет дополнительный атрибут в частности он говорит использую метку in pls label с номером 37 с номером 37 соответственно эта информация используется муртизатором p2 то есть если к муртизатору p2 прилетает пакет то есть внутри вот этой вот vrf и пакет отправляется на префикс 10.1.1.0.24

то муртизатор p2 понимает что он должен сделать примерно следующую конструкцию то есть он говорит то есть он инкапсулирует данные внутрь ip далее далее здесь будет л2 заголовок ставит верхнюю метку равную метки 37 вот эту которую получил от своего p-e соседа после этого после этого смотрит через кого ему доступен префикс 10.1.1.0 он видит что этот префикс ему доступен через кого через муртизатор p1 через муртизатор p1 он смотрит далее он ищет свою ldp метку для p1 и выставляет ее вот и выставляете вот сюда вот ldp label

и выплевывает такой пакет наружу то есть соответственно когда следующий транзитный амортизатор будут обрабатывать этот пакет то они будут смотреть только вот эту меточку внешнюю метку такая метка называется транспортная метка и вот эта метка она будет меняться как бы хобби хобби при этом випеновская метка остается неизменным то есть муртизаторы транзитные ее не анализируют для них это просто как некий payload соответственно в итоге в итоге пакет прилетает на муртизатор p1 муртизатор p1 уже обрабатывает вот эту внутреннюю метку которая называется vpn label

называется vpn метка и именно благодаря этой метке на уровне дата плейна муртизатор понимает что пакет должен быть отправлен именно например в зеленую вероятность почему потому что обратите внимание что мы сгенерировали меточку 37 для vrf red для префиксы 10 1 11 0 то есть если я дам команду show mpls forwarding table то если я получаю метку 37 если я получаю метку 37 то я этот пакет по сути маркетизирую на этот префикс а этот префикс находится внутри vrf red что-то направляет что она называется forwarding table что вот у нас в forwarding table что у нас в forwarding table labels labels

37 detail то есть она отправится в сторону vrf red то есть пакет будет от транслирован внутрь vrf red и дальше произойдет обычная муртизация в рамках данной вероятности Похоже, что марштизатор R9 поднялся. У меня здесь нет команды no-service-config. Видимо, 9-ый раутер еще не очухался. Надо ввести команду no-service-config. Сейчас, поскольку марштизатор R9 – это единственный марштизатор, который может передавать пакеты с точки зрения dataplan, очевидно, что пакеты у меня не добегут.

Show your split neighbor. Пинг есть. Теперь запускаем trace route. 10, 1, 11, 11. Numeric. Обратите внимание, что вот она, меточка номер 37. Вот она, меточка номер 37, которая никогда не меняется, пока пакет проходит через ампиловое соблако. И вот она, меточка 29. В частности, вот она. То есть, это уже просто транспортная метка, которая используется на марштизаторе R9. Вот она, транспортная метка 40. То есть, если… То есть, смотри, какая логика. То есть, марштизатор R4, он получает пакет, который прилетает в vref red.

То есть, он говорит show ip route vref red. Далее, он видит, что этот префикс 10, 1, 11, доступен через nexthop 150.1, 1, 1. 10, 1, 11, 1. Окей. Теперь мы ищем маршрут на префикс 150.1, 1, 1. Show ip route 150.1, 1. Этот nexthop доступен через интерфейс 2.410. И при этом mpls flag mpls required. То есть, говорит нам о том, что на этом интерфейсе включен mpls. Дальше. Мурсетер R4 говорит show mpls forwarding table. Для какого префикса? Для bgp nexthop 150.1, 1, 1, 32. Упс. И видит, что outgoing label для этого префикса у него равно 40.

Соответственно, таким образом генерируется стэк mpls меток, который состоит из метки 40 и из метки 37, которая была получена от конкретного bgp-сосерба. Таким образом, пакет с двумя меточками выплевывается. Далее, внутри mpls облака у нас происходит коммутация на основе внешней транспортной метки 40. VPN с коммутацией остается неизменной. Вопросы? Искент, под VPN v4 здесь подразумевается, да, именно туннель, конечно. То есть, VPN v4 маршрут в нашем случае это просто root distinguisher плюс префикс. А посмотреть транспорт-лейбл можно в LFIP?

Можете показать, как ее посмотреть? PPE. Ну вот, смотри, вот она. То есть, вот она транспортная метка на моштизаторе PE. Вот она. В принципе, можно воспользоваться такой командой showipcf vrf red. И куда у нас пакет летит? На 10, 1, 11, 1. И мы видим, что если мы отправляем пакет из красной vrf на такой-то префикс, то мы отправляем такой пакет на интерфейс 2.410 и нацепляем на него две метки. 40 и 37. То есть, по сути, вот это showipcf — это и есть просмотр твоего LFIP. Но как этот LFIP формируется? Он формируется вот из вывода команд showimplast forwarding table и из команды showtypout vrf. Виктор, смотри.

Да, дополнительная пилосметка, чтобы моштизатор мог понять, в каком мы бире в предназначен пакет. Но здесь нужно просто разделять понятие control plane и data plane. Смотри, routeTarget, то есть routeDistingisher нам нужен только для того, чтобы сделать префиксы уникальными в пределах одного моштизатора. routeTarget нам позволяет сообщить, какие префиксы. Например, мы приняли префикс по BGP, мы должны понять, в какую VRAF этот префикс отдать с точки зрения control plane и сообщить дальше своим клиентам. Но когда у нас пакет летит на data plane, то есть когда пакет летит реально по проводу, у нас там нет никаких routeTarget. Мы там можем оперировать только меточками. Поэтому нам нужен некий идентификатор на уровне data plane. То есть когда моштизатор принимает пакет, он его анализирует и он должен понять, в какую VRAF этот пакет нужно отмоштизировать. Искен.

На самом деле, если говорить про классические сети, которые основаны на LDP протоколах, максимум, что я видел, по-моему, это 3 или 4. Если мы будем говорить о современных топологиях, о сегмент раутинге, теоретически их может быть очень много. И это не очень много. Но вообще ограничен исключительно размером МТУ, который готов муортизатор пропустить на конкретном моменте. Ну, Василий, я, к сожалению, не смогу дать рекомендуемое МТУ, но по сути размер метки это 4 байта. Поэтому необходимо рассчитывать, чтобы у Вас внутри транспорта сети МТУ был как МТУ внутреннего интерфейса, плюс количество метку, умноженное на 4 байта. В 99% случаев Вам хватит либо двух меток, либо трех.

Иннокентий, ты здесь? Чаще всего третья метка будет возникать при трафик-инженеринге. То есть эта метка будет сигнализировать некий бэкапный туннель, на который нам нужно при необходимости переключиться. Например, если какие-то неполадки сети произошли. Либо третий уровень иногда используется, когда мы будем строить L3 VPN третьего уровня между разными автономными системами. В некоторых случаях нам необходимо три метки поставить, чтобы корректно пакет ходил.

Что касаемо VSI-лэйбла, да, это уже метка, ну, она просто метка, да, которая характеризует какой-то твой L2 circuit, и это VPN-лэйбл. То есть транспорт-лэйбл у тебя чаще всего будет LDP, чаще всего, да. А VSI-лэйбл – это уже замена вот этой VPN-овской метки BGP. Ну, вот VSI-лэйбл также может у тебя распространяться либо по BGP, либо по LDP, там уже в зависимости от того, как ты сам настроишь. Но это абсолютно разнозначное понятие, что VPN-овская метка, что VSI. Ну что ж, видимо, Иннокентия у нас нет. На самом деле я тут. А, ну все, отлично. Ну что ж, да, я на самом деле тогда на Сим с вами прощаюсь.

До завтра. Спасибо большое за интересную лекцию. Я, правда, пропустил самый-самый конец, но я прошу за это прощение. Давайте встретимся завтра, и завтра будет...