MPLS overview. Просто о сложном.

Последние пару-тройку недель в свободное время вожусь с MPLS. Наткнулся на отличный гайд по L2VPN от Alcatel-Lucent (Designing and Implementing IP/MPLS-Based Ethernet Layer 2 VPN Services: An Advanced Guide for VPLS and VLL). Отличная книга! Материал действительно сложный, поэтому я буду делать много заметок. Ну а раз так, почему бы не запостить все это.

Вообще, планирую написать довольно много постов по MPLS сигнализации и по MPLS вообще, простыми словами не углубляясь в потроха. Просто, как и что работает.

Итак, попробуем структурировать все что я собираюсь описать:

MPLS TE features
     - Overview
     - Secondary LSP
     - MBB (Make-before-break)
     - CSPF (Constrained Shortest Path First)
         - Link Coloring
         - SRLG (Shared Risk Link Grouping)

RSVP-TE
     - Overview
     - Signaling procedure
     - Fast Reroute
          - One-to-One backup
          - Facility Backup
          - Manual Bypass

LDP
     - Overview
     - Signaling procedure
     - T-LDP

LDPoRSVP

Service oriented approach and PWE3

MTU
     - Port MTU
     - LSP-Path MTU
     - SDP MTU
     - Service MTU
     - VC MTU

Собираем лабу!

Сегодня пункт номер 0. Погнали!

Все посты про MPLS VPN можно посмотреть по тегу MPLS или в обобщающем посте.

Зачем?

Прежде чем что-то писать, наверное, стоит спросить себя зачем... Я хотел бы простыми словами описать общие принципы MPLS TE. В частности, как используется MPLS в больших сетях провайдеров, какие механизмы управления трафиком он использует и как достигается такая высокая отказоустойчивость. Надеюсь, пост будет полезен коллегам, которые работают с сетями, но пока не особо встречались с MPLS. Инженерам, которые хотят узнать о нем, но очень не хотят читать RFC и вникать в подробности. Так же, что-то полезное в этом посте могут найти и те, кто по долгу службы сталкивается с сетями, но работают в других IT сферах. Попытаюсь написать статейки, которых мне не хватало тогда, когда я подошел к знакомству с MPLS. 

Что вообще такое MPLS?

Как, наверное, многим известно, MPLS (Multiprotocol Label Switching) был придуман в стародавние времена, когда роутинг ещё не выполнялся на аппаратном уровне. В то время роутинг был довольно тяжелой процедурой. Чтобы прочувствовать ситуацию, можете попробовать отключить CEF на какой-нибудь Циске. Результат будет очень плачевный, поэтому не стоит делать это в рабочей сети. В попытках ускорить этот медленный процесс команда инженеров из большого числа вендоров придумали роутить не анализируя информацию в IP-пакете, а лишь заглядывая в некие метки. Идея интересная. Таким образом был написан первый RFC в далеком 2001 году тружениками Cisco, Juniper и Force10.

Посудите сами. В классическом понимании, когда на некий маршрутизатор приходит Ethernet кадр, ему необходимо посчитать CRC, отбросить L2 заголовок, посмотреть в L3 заголовок, глянуть в таблицу маршрутизации, найти куда пакет отправить, обратно все обернуть L2 и отправить в исходящий интерфейс. Это явно не полный список дел, можно еще добавить ARP, например. Но сейчас не об этом. В MPLS все просто. Пришел кадр, посмотрел в метку, посмотрел на что её поменять и куда отправить, поменял и отправил. Дело сделано.

MPLS работает поверх IP-сети, не заменяя её, а дополняя и улучшая. Для того чтобы включить MPLS в сети, вам для начала нужно организовать IP связность. Ясно, что руками ничего прописывать смысла нет, поэтому используем какой-нибудь протокол маршрутизации. На деле же, использовать какой-нибудь EIGRP нет абсолютно никакого резона. Об этом ниже. После включения MPLS на IP полносвязной сети, трафик будет ходить по меткам, но маршруты движения этого трафика будут такими как построил их какой-нибудь протокол маршрутизации. После моей первой встречи с MPLS я задал себе вопрос - "А нафига оно нужно?". Конечно же, не все так просто. Вся сила и сложность MPLS кроется в аббревиатуре TE. О ней чуть ниже.

Сам MPLS как протокол я описывать не буду, хотя бы потому, что его уже отлично описали ребята из linkmeup.ru. Этих ребят я готов пиарить как только смогу, о них вы ещё услышите. В любом случае, лучше сначала ознакомиться с базой MPLS по ссылке, чем читать пост далее.

TE?

Меня же сейчас больше интересует MPLS не как технология сама по себе. Мне интересна сфера его применения в провайдерских сетях как база для организации L2 и L3 VPN. Однако как выяснилось, тема намного сложней, чем я рассчитывал. Таким образом, сам протокол отходит немного на второй план, а на первый план выходит все, что связано с Traffic Engineering. У меня по какой-то причине, долгое время были проблемы с осознанием этого термина. Упомянутый алкателевский талмуд помог мне понять что же вкладывается в этот термин играя на контрасте. Приведу оригинальные определения, потому как с переводом теряется некая игра слов.

По мнению авторов книги, 

Traffic management (TM) places the bandwidth where the traffic is.

Traffic engineering (TE) places the traffic where the bandwidth is.

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

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

Распространение меток

Стоит немного рассказать о распространении меток, чтобы переходить к дальнейшему повествованию. После того, как к MPLS-маршрутизатору приходит кадр, он должен посмотреть на входящую метку и найти у себя соответствие метка/исходящий порт. Подчеркиваю, для того чтобы понять куда и с какой меткой отправлять кадр, маршрутизатору нужна только входящая метка и ничего более. Соответственно, перед тем как начать гонять реальный абонентский трафик, нужно чтобы у каждого маршрутизатора были знания о метках. В этом посте я не буду затрагивать эту тему, но пока что знайте, что метки в MPLS распространяются двумя протоколами (почти что...) LDP и RSVP TE. Эту тему мы оставим на будущее, но кратко обозначим основные моменты.

LDP. Довольно простой, с первого взгляда, протокол. Наиболее часто он применяется в случае, когда нужно всем маршрутизаторам знать обо всех метках в сети. Именно это и произойдет, если вы включите на маршрутизаторе Cisco MPLS на нужных интерфейсах. Каждый маршрутизатор проанонсирует все соответствия метка/префикс всем своим соседям. После чего эти соседи будут обладать необходимыми знаниями о том с какой меткой отправлять трафик для того или иного префикса. Там тоже не все так просто, метки эти могут распространяться по запросу, а не по мере узнавания о них. Но это все детали. Это как раз тот случай, когда трафик будет ходить по маршрутам, которые предоставил протокол маршрутизации.

На картинке ниже я пытался изобразить, как R1 узнав, что у него появился новый префикс рассказывает своим соседям, что им нужно отправлять трафик для этого префикса с меткой 30. Соседи получают это сообщение и вешают метку 30 в исходящие пакеты. Таким же образом R2 и R3 отправляют своим соседям метки для своих префиксов. В итоге, все узлы знают обо всех метках в сети. Такое поведение можно изменить, изменяя режимы работы LDP. Но сейчас про базовый принцип работы.

RSVP-TE. Тут все чуть сложней. Распространение меток в RSPV-TE носит абсолютно другой характер. Маршрутизатор, который хочет отправить трафик в MPLS сеть (Head End), отправляет в сеть запрос (сообщение Path), который доходит до конечного маршрутизатора (Tail). Тот в свою очередь выделяет метку и отправляет определенный ответ (сообщение Reserv) назад в сторону Head End маршрутизатора. Когда по сети идет запрос (HE->Tail) каждый маршрутизатор оценивает свои возможности, может ли он зарезервировать определенные ресурсы для этого трафика. Когда идет ответ (Tail->NE), каждый маршрутизатор по пути выделяет метку, сообщает о ней предыдущему маршрутизатору и одновременно с этим выделяет ресурсы. Таким образом, после того как инициировано создание туннеля, отправлен запрос и получен ответ, у каждого маршрутизатора в сети есть зарезервированные ресурсы для прохождения трафика и метки чтобы этот трафик гонять. 

На картинке инициировано создание туннеля, который направлен от PE1 к PE2. PE1 отправляет сообщение Path, которое адресовано PE2. В этом сообщении передается довольно много информации, в числе прочего передается просьба о резервировании ресурсов. P1 получив этот пакет, оценивает свои возможности и отправляет сообщение P3. P3 проделывает аналогичные процедуры и отправляет сообщение на PE2. Тот выделяет метку для этого туннеля и отправляет ответное сообщение Reserv, в котором её и передает. P3 получив сообщение записывает метку, выделяет ресурсы, генерирует свою и отправляет её P1. P1 проделывает аналогичные процедуры. В итоге сообщение Reserv доходит до PE1. Тот выделяет ресурсы, записывает метку себе и считает туннель поднятым. Теперь можно начать передавать трафик от PE1 к PE2. Чтобы передавать трафик обратно, нужно сигнализировать ещё один обратный туннель. Конечно, я опустил все подробнисти, какие только мог опустить. С подробностями разберемся в будущих постах. В общем, когда PE1 хочет отправить чистый клиентский трафик в тунель, он вешает метку 102 и отправляет трафик P1. Тот смотрит на метку, убирает её и вставляет 101, после чего отправляет трафик к P3. Тот тоже смотрит на метку, снимает её и вещает 100 и отправляет в сторону PE2. PE2 получая трафик аналогично смотрит в метку, убирает её и отправляет чистый трафик клиенту.

Secondary LSP.

Каждый канал прохождения трафика в MPLS называется LSP (Label Switched Path). Это канал от пункта А до пункта Б. Внизу предыдущей картинки я попыталя это изобразить. Стоит подчеркнуть, что он однонаправлен. Чтобы трафик передавался в обратном направлении, нужно строить второй LSP (из пункта Б в А), и вообще не факт что они пойдут по одному маршруту в сети. В каждом таком канале (LSP) есть путь (LSP-Path). LSP-Path - путь по которому проходит трафик в канале. Это, грубо говоря, список узлов в сети, ассоциированные с путем метки и интерфейсы. Все мы знаем, Two is one and one is nothing. В общем и целом, глупо, если вы прописали только один путь для туннеля, если можете прописать два... или восемь... Концепция Secondary LSP проста. Вы можете указать второй, третий, четвертый и т.д. путь для вашего туннеля. Каждый из таких путей может быть hot-stanby (уже предсигналеный туннель) и cold-stanby (сигнализации еще не было). Соответственно, когда первичный путь по каким-то причинам ляжет, маршрутизатор немедленно перебросит трафик в secondary путь (если он hot-stanby), или сначала просигнализирует туннель с помощью RSVP-TE а потом уже бросит в него трафик (если путь cold-stanby). Понятно, что hot-stanby дает большую отказоустойчивость, но и резервирует больше ресурсов для дополнительных туннелей.

MBB (Make-before-break)

Как и во всем MPLSе, тут все предельно просто... Когда вы хотите пустить трафик по другому пути или с другими параметрами, не очень красиво было бы класть канал, строить новый путь и пускать в него трафик вновь. Абонент будет нервничать. MBB позволяет сначала полностью простроить новый канал, пустить в него трафик, а уже потом отключить старый. Абонент обычно даже ничего не почувствует. Все рады.

Алгоритм CSPF (Constrained Shortest Path First)

Используя сигнализацию меток с RSVP-TE появляется возможность пускать трафик не так как проложил маршрут протокол маршрутизации, а так как оптимальнее с точки зрения MPLS (ну или просто как хочется). Для того чтобы просчитать путь прохождения трафика для MPLS туннеля используется алгоритм CSPF, у которого под капотом всеми любимый алгоритм Дейкстры. Математик из меня так себе, поэтому эту тему я технично пропущу. Говоря простыми словами, это протокол, который может просчитать кратчайший маршрут между двумя вершинами графа по заданным критериям. Такими как, оставшийся bandwith на линках, условие избегать или наоборот выбирать те или иные линки и прочее. Очевидно, для того чтобы учитывать все дополнительные параметры о них нужно сначала узнать. Вот тут и всплывает первая кооперация в MPLS. Все эти дополнительные данные переносят доработанные протоколы маршрутизации (OSPF TE и IS-IS TE). Они помогают алгоритму CSPF, доставляя для него всякие разные полезные данные со всей сети. 

Кстати, никто не обязывает использовать CSPF для просчета пути. Всегда можно положиться на результат работы внутреннего протокола маршрутизации. Более того, есть пара моментов, когда это поможет обойти ряд проблем. Об этом будет в статье по LDPoRSVP.

Резюмируем, для того чтобы пустить трафик в MPLS туннеле туда куда нужно, мы должны:

- использовать расширенные протоколы маршрутизации (OSPF TE или IS-IS TE), которые передадут всю нужную дополнительную информацию о сети,

- использовать RSVP-TE, который передаст метки по всему пути и зарезервирует ресурсы на каждом маршрутизаторе,

- использовать алгоритм CSPF, который посчитает кратчайший маршрут учитывая всю дополнительную информацию, о которой поговорим далее.

 

Link Coloring

Один их тех параметров, которые может учитывать CSPF (и который перенося OSPF TE и IS-IS TE). Концепция внешне проста как две копейки. Мы говорим нашей MPLS сети обращаясь к Head End маршрутизатору: "А прокинь-ка, пожалуйста, туннель до такого-то маршрутизатора. Зарезервируй по пути мегабит, скажем, двадцать. Только знаешь, избегай, пожалуйста, линков, которые я до этого обозначил как красные. Спасибо, дружище". Жена всегда ругается на меня, когда я с техникой разговариваю... После такой просьбы, маршрутизатор пытается прокинуть MPLS туннель используя RSVP TE по кратчайшему пути и с заданными параметрами. Если у него не получается, то он обязательно отрапортует об этом.

На картинке, при попытке построить туннель от PE1 до PE2 с условием избегать крассные линки, CSPF тщательно обойдет его и построить туннель окольными путями.

SRLG (Shared Risk Link Grouping)

Концепция так же проста и логична. Мы, как персонаж знающий сеть полностью, можем выделить на маршрутизаторе "группы риска". Скажем, у нас два линка идут в одном волокне. Если один из них упал, возможно это порыв оптики, может быть и с другими линками в этом кабеле не все чисто. Не кажется ли вам, что лучше избегать линков в этом кабеле? Логично. Так и запишем в конфиге маршрутизатора. Мол, вот эти два линка находятся в одной SRLG группе. Если уж что-то случилось с одним из них, постарайся проложить маршрут избегая второй. Вся эта инфа о "группах риска" так же распространяется по всей MPLS-сети с помощью TE протоколов маршрутизации. Поэтому, при отказе линка P1-P3 на картинке, CSPF просчитает такой маршрут, который не будет использовать линк P1-P4, при условии, что на P1 создана SRLG-группа объединяющая соответсвтующие линки.

Стоит отметить, что "прокидывание" этих самый MPLS-туннелей может быть полностью отдано под контроль системы, вы, как администратор, лишь инициируете процесс. Возможно, скажем, просто инициировать туннель от одного маршрутизатора до другого не обозначая никакие параметры. Кстати говоря, это не значит, что туннель не будет защищен от аварий... Но об этом в будущих статьях. В то же время, можно, к примеру, попросить зарезервировать парочку мегабит, конкретно обозначить путь, который будет включать определенные узлы в сети, дополнительно обозначить каких линков стоит избегать, попросить прокинуть ещё один путь в hot-stanby режиме и парочку путей на всякий случай в режиме cold-stanby и т.д. Путь, вообще, тоже никто не обязывает прописывать полностью hop-by-hop. Вы можете вообще не специализировать путь, а полностью отдать это на усмотрение системы, после чего CSPF просчитает для вас конкретный путь. Вы так же можете указать через какие узлы должен пройти путь, остальные узлы прочситает CSPF. Ну и третий вариант указать hop-by-hop каждый узел, полностью контролируя процесс.

Важная особенность про резервирование bandwith. Я как-то раньше не задумывался об этом, но никто не мешает клиенту фугануть мегабайт 200 в туннель, для которого зарезервировано 50. Резервирование - это понятие в control plane, которое не позволит прокинуть 10x100Мбит/с туннелей  в гигабитный линк и все. Как вы правильно поняли, для того чтобы клиент не сильно наглел, нужно делать QoS, но это совсем другая история...

В качестве заключения.  

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

В следующий раз в планах разобраться с RSVP-TE или LDP, с механизмами позволяющими достичь довольно большой отказоустойчивости. Если у вас есть какие-либо вопросы, не стесняйтесь оставлять комментарии.