Что такое 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

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

Зачем?

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

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

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

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

На картинке инициировано создание туннеля, который направлен от 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.

MBB (Make-before-break)

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

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

Link Coloring

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

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

SRLG (Shared Risk Link Grouping)

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

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

Источник

ИТ База знаний

Полезно

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

MPLS (Multiprotocol label switching) является протоколом для ускорения и формирования потоков сетевого трафика, что, по сути, означает сортировку MPLS и расстановку приоритетов в ваших пакетах данных на основе их класс обслуживания (например, IP-телефон, видео или данные Skype). При использовании протоколов MPLS доступная используемая пропускная способность увеличивается, а критически важные приложения, такие как передача голоса и видео, гарантируют 100% бесперебойную работу.

Полный курс по Сетевым Технологиям

В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer

Как работает MPLS?

MPLS это метод маркировки пакетов, который устанавливает приоритетность данных. Большинство соединений сети должны анализировать каждый пакет данных на каждом маршрутизаторе, чтобы точно понимать его маршрут следования.

Виды маршрутизаторов

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

CE взаимодействует с маршрутизатором со стороны оператора (PE) и обменивается маршрутами внутри PE. Используемый протокол маршрутизации может быть статическим или динамическим (протокол внутреннего шлюза, такой как OSPF, или протокол внешнего шлюза, такой как BGP).

Некоторые маршрутизаторы PE также выполняют маркировку трафика.

Принципы работы MPLS

Входной маршрутизатор с MPLS (напомним, multiprotocol label switching, с английского) будет помечать пакеты данных при входе в сеть расставляя метки, поэтому, маршрутизаторы будут точно понимать, куда направляются данные, без необходимости снова и снова анализировать пакет с данными.

Чтобы понять принцип работы методики MPLS следует отметить, что в традиционной IP-сети каждому маршрутизатору приходится выполнять поиск IP, путем постоянного поиска его в таблицах с пакетами данных с последующей пересылкой на следующий уровень пока пакеты данных не достигнут нужного пункта назначения.

MPLS технология присваивает метку всем IP-пакетам, а тем временем уже сами маршрутизаторы принимают решение о передаче пакета далее на следующее устройство благодаря нужному значению метки. Метка добавляется в составе MPLS заголовка, который добавляется между заголовком кадра (второй уровень OSI) и заголовком пакета (третий уровень OSI) и, по сути, в дальнейшем идет их наложение друг на друга.

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

В чем преимущество переключения меток по методу MPLS?

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

Передача и управление трафиков происходит за счёт технологии Traffic Engineering, которая осуществляет передачу трафика по каналам по наиболее оптимальному маршруту, но с некоторыми ограничениями благодаря технологии CSPF (Constrained Shortest Path First), которая выбирает пути не только пользуясь критерием, основанном на его оптимальной длине маршрута, но еще и учитывает загрузку маршрутов. Используемые протоколы RSVP-TE позволяют резервировать полосы пропускания в сети.

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

Можно выделить следующие преимущества организации VPN на базе MPLS

В заключении следует отметить, что на практике MPLS в основном используется для пересылки единиц данных протокола IP (PDU, (Protocol Data Unit)) и трафика виртуальной частной локальной сети (VPLS) Ethernet. Основными приложениями MPLS являются инженерия телекоммуникационного трафика и MPLS VPN.

Полный курс по Сетевым Технологиям

В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer

Источник

Ответы на вопросы по MPLS для начинающих

Параметры загрузки

Об этом переводе

Этот документ был переведен Cisco с помощью машинного перевода, при ограниченном участии переводчика, чтобы сделать материалы и ресурсы поддержки доступными пользователям на их родном языке. Обратите внимание: даже лучший машинный перевод не может быть настолько точным и правильным, как перевод, выполненный профессиональным переводчиком. Компания Cisco Systems, Inc. не несет ответственности за точность этих переводов и рекомендует обращаться к английской версии документа (ссылка предоставлена) для уточнения.

Содержание

Введение

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

Что такое многопротокольная коммутация по меткам (MPLS)?

MPLS — это технология пересылки пакетов, в которой используются метки для принятия решений о пересылке данных. С помощью MPLS проводится однократный анализ заголовка третьего уровня (при поступлении пакета в домен MPLS). Анализ метки приводит к дальнейшей переадресации пакета. MPLS предлагает следующие удобные приложения:

Virtual Private Networking (VPN)

Traffic Engineering (TE)

Качество обслуживания (QOS)

Технология Any Transport over MPLS (AToM)

Кроме того, эта технология уменьшает время перенаправления пакета на основных маршрутизаторах. Технологии MPLS применимы к любым протоколам сетевого уровня.

Что такое метка? Какова структура метки?

Метка — это короткий 4-байтовый локально значимый идентификатор фиксированной длины, который используется для идентификации класса эквивалентности при пересылке (Forwarding Equivalence Class, FEC). Метка, присвоенная определенному пакету, содержит данные о FEC, которому назначен этот пакет.

Label — значение метки (неструктурированное), 20 битов

Exp —- Экспериментальное использование, 3 бита; в настоящее время используется в качестве поля класса обслуживания (Class of Service, CoS)

S — дно стека, 1 бит

TTL — аббревиатура Time to Live (время жизни информации), означает предельное количество переходов к маршрутизатору, 8 битов

В какой части пакета устанавливается метка?

Метка назначается между заголовком канального уровня (уровень 2) и заголовком сетевого уровня (уровень 3). Верхняя граница стека меток отображается первой в пакете, а нижняя — последней. Пакет сетевого уровня непосредственно следует последней метке из стека меток.

Что такое класс эквивалентной переадресации (FEC)?

Ответ. Класс эквивалентной переадресации FEC является группой IP-пакетов, которые переадресуются одинаковым образом по одному и тому же маршруту и с одной и той же обработкой переадресации. Класс FEC может соответствовать целевой IP-подсети, а также классу любого трафика, который будет определен Edge-LSR как значительный. Например, весь трафик с определенным значением IP-приоритета может служить основой для FEC.

Что такое восходящий маршрутизатор, коммутирующий по меткам (LSR)? Что такое нисходящий маршрутизатор коммутирующий по меткам?

Термины «восходящий» и «нисходящий» в контексте технологии MPLS являются относительными. Они всегда относятся к префиксу (если точнее, то к классу FEC). Это объясняется в следующем примере.

Для FEC 10.1.1.0/24, R1 является «нисходящим» маршрутизатором коммутирующим по меткам в R2.

Для FEC 10.1.1.0/24, R2 является «восходящим» маршрутизатором коммутирующим по меткам в R1.

Для FEC 10.1.1.0/24 маршрутизатор R1 является нисходящим LSR относительно R2, а R2 является нисходящим LSR по отношению к R3.

Для FEC 10.1.1.0/24, R1 является «нисходящим» маршрутизатором коммутирующим по меткам в R2. Для FEC 10.2.2.0/24, R2 является «нисходящим» маршрутизатором коммутирующим по меткам в R1.

Для достижения этой сети данные передаются от восходящего к нисходящему маршрутизатору.

Таблица маршрутизации R4 содержит R1, R2 и R3 в качестве следующего перехода для достижения 10.1.1.0/24.

Является ли R3 «нисходящим» маршрутизатором коммутирующим по меткам в R4 для 10.1.1.0/24?

Нет, данные передаются по направлению от восходящих к нисходящим устройствам.

Когда вы обращаетесь к меткам, что делает поступление сроков, выход, локальное, и удаленное среднее значение?

Рассмотрим маршрутизаторы R2 и R3 в данной топологии. R2 распределяет метку L для FEC F в R3. R3 использует метку L при пересылке данных на FEC-F (поскольку R2 является его нисходящим маршрутизатором LSR для FEC-F). В данном примере:

L является входящей меткой для F на R2

L является исходящей меткой для FEC-F на R3

L является локальным значением для FEC-F на R2

L является удаленной меткой для FEC-F на R3

Может ли маршрутизатор коммутирующий по меткам использоваться для отправки и (или) получения на MPLS-интерфейс собственного IP-пакета (не MPLS)?

Да, если протокол IP включен на этом интерфейсе. Собственные пакеты передаются и принимаются как обычно. IP — это всего лишь другой протокол. Пакеты MPLS имеют другую кодировку второго уровня. Принимающий маршрутизатор коммутирующий по меткам распознает пакет MPLS, основанный на кодировке второго уровня.

Может ли маршрутизатор коммутирующий по меткам использоваться для отправки и (или) получения помеченных пакетов на интерфейс отличный от MPLS?

Нет. Пакеты никогда не будут передаваться на интерфейс, если на нем не включен данный протокол. MPLS обладает определенным типом кодировки Ether, связанным с многопротокольной коммутацией по меткам (точно так же, как IP, IPX и Appletalk обладают уникальными типами Ether). При получении маршрутизатором Cisco пакета с типом Ether, которые не может использоваться на интерфейсе, происходит отклонение такого пакета. Например, если маршрутизатор получает пакет Appletalk на интерфейсе, который не может обрабатывать пакеты Appletalk, то происходит отклонение пакета. Аналогично этому, если пакет MPLS получен на интерфейсе, который не может его обработать, то этот пакет отклоняется.

Какие платформы и операционные системы Cisco IOS поддерживают работу с многопротокольной коммутации по меткам (MPLS)?

Cisco серий 2691, 3640, 3660, 3725, 3745, 6400-NRP-1, 6400-NRP-2SV, 6400-NSP, Catalyst 5000 с модулем коммутации маршрутов (RSM), 7200, 7301, 7400, 7500, Catalyst 6500/Cisco 7600 с WS-SUP720-3B и WS-SUP720-3BXL, коммутирующий маршрутизатор Gigabit (GSR), модуль процессора маршрутов (RPM), универсальный широкополосный маршрутизатор (UBR) 7200, AS5350 и IGX8400-URM — все эти устройства поддерживают MPLS.

Эти платформы поддерживают Cisco TDP-протокол в качестве протокола распределения меток.

Сведения о LDP-протоколе, RSVP-протоколе и BGP-протоколе могут быть найдены с помощью служебной программы Software Advisor (только для зарегистрированных пользователей). Software Advisor предоставляет сведения о полном списке наборов функций, поддерживаемых в различных версиях Cisco IOS и на различных платформах.

GRE-туннель использует служебные данные размером 24 байта. Какой размер служебных данных соответствует туннелю MPLS LSP?

Туннель MPLS LSP имеет одну метку (4 байта) или две метки (например, при использовании быстрой перемаршрутизации для защиты линии связи) дополнительного трафика. В отличие от туннеля GRE, MPLS не изменяет IP-заголовок. Вместо этого, стек меток применяется к пакету проходящему по пути туннеля.

Как маршрутизатор коммутирующий по меткам определяет какая метка из стека меток считается верхней, нижней или средней?

Метка, которая расположена сразу после заголовка уровня 2, является верхней, а метка, для которой бит S имеет значение 1, называется нижней. Средние метки не считываются и не идентифицируются маршрутизатором коммутирующим по меткам. При этом метка будет средней меткой, если она не находится вверху стека и бит S = 0.

Каков диапазон значений метки? Какие значения метки могут быть получены? Что означают полученные значения?

Теоретически диапазон значений от 0 до (220-1). Значения меток 0-15 зарезервированы, а значения 4-15 зарезервированы для последующего использования. Значения 0-3 определяются следующим образом:

Значение 0 соответствует «IPv4 Explicit NULL Label». Эта метка указывает на то, что пакет должен быть извлечен из стека меток, а переадресация пакета должна быть основана на основе IP-заголовка версии 4. Это помогает сохранить бит Exp неизменным до выхода из маршрутизатора. Он используется в QoS на основе MPLS

Значение 1 соответствует «Router Alert Label». Если полученный пакет содержит это значение метки вверху стека меток, то пакет доставляется модулю локального программного обеспечения для обработки. Фактическая переадресация пакета определяется его меткой в стеке. Однако если пакет переадресуется далее, то метка Router Alert Label должна быть возвращена обратно в стек меток перед выполнением переадресации. Использование этой метки аналогично использованию метки «Router Alert Option» в IP-пакетах (например, проверка связи с параметром записи маршрутизатора)

Значение 2 соответствует «IPv6 Explicit NULL Label». Эта метка указывает на то, что пакет должен быть извлечен из стека меток, а переадресация пакета должна быть основана на основе IP-заголовка версии 6

Значение 3 соответствует «Implicit NULL Label». Это метка, которую маршрутизатор коммутирующий по меткам может назначать и распределять. Однако она никогда не отображается в инкапсуляции. Это указывает на то, что маршрутизатор коммутирующий по меткам выталкивает верхнюю метку из стека и направляет оставшуюся часть пакета (с меткой или без) через исходящий интерфейс (для каждой записи Lfib). Хотя это значение может никогда не отображаться в инкапсуляции, необходимо задать LDP-протокол так, чтобы зарезервировать значение

Какой протокол и номер порта позволяют использовать протоколы LDP и TDP для распределения меток в узлах LDP/TDP?

LDP использует TCP-порт 646, а TDP использует TCP-порт 711. Эти порты открыты на интерфейсе маршрутизатора, если для него настроен параметр «mpls ip». Использование TCP в качестве транспортного протокола приводит к надежной доставке данных LDP/TDP с помощью надежных механизмов управления потоком и обработки перегрузок.

Какие ограничения на использование MPLS существуют для маршрутизаторов Catalyst 6500 и 7600 Optical Services (OSR)?

Интерфейс, подключенный к домену MPLS, должен использовать один из модулей оптических сервисов (OSM) (например, любой модуль, который задействует комплекс параллельной ускоренной пересылки (PXF)) или интерфейс в модуле FlexWAN. Те же самые ограничения существуют и для многопротокольной коммутации по меткам третьего уровня VPN. Именно поэтому IP-кадр должен поступать на WAN-интерфейс, который может быть либо оптическим служебным модулем, либо интерфейсом в модуле FlexWAN. Эти ограничения не распространяются на Supervisor 720.

Где можно ознакомиться с примера MPLS-конфигурации?

Какие опции доступны для распределения нагрузки пакетов MPLS?

Балансировка нагрузки пакетов MPLS может осуществляться на основе информации меток MPLS и/или адресов источника и назначения в существенном IP-заголовке.

Мы можем настроить магистраль «802.1q» между двумя коммутаторами Cisco Catalyst на других узлах по соединению MPLS?

Наследует ли значение MPLS EXP значение DSCP из входящих пакетов IP по умолчанию или входящее значение DSCP будет доверенным без какой-либо дополнительной настройки MPLS? enabled interface?

Да, дополнительная настройка не требуется.

Функция ретрансляции DHCP работает в сети MPLS VPN?

Да, запрос DHCP пересылается внутри поля VRF через сеть VPN MPLS, а внешние устройства сети провайдера отправляют его с использованием того же поля VRF на сервер DHCP.

Источник

Сети для самых матёрых. Часть тринадцатая. MPLS Traffic Engineering

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

Однако сеть linkmeup выросла до размеров федерального оператора. Возможность управления трафиком и быстрого восстановления сервисов стали очень важным требованием в MPLS-сети.
Пора внедрять Traffic Engineering.

Зачем вообще может понадобиться инжиниринг трафика?

Приведу простой пример.
Конвергентная сеть мобильного оператора.

Подумайте, можем ли мы сделать это стандартными средствами? Разделить трафик разных сервисов разными VPN, безусловно, можем, но направить разными маршрутами — нет.

Без использования ТЕ весь трафик перенаправится в правое плечо, а там, кто бы мог предположить, не хватает пропускной способности — начнутся отбрасывания.

Кроме того, скорость сходимости OSPF или ISIS даже при использовании BFD исчисляется десятками мс, но после этого ещё и транспортные LSP должны перестроиться. В наши дни это уже не пройдёт незамеченным для абонентов.

Принципы работы MPLS Traffic Engineering

Какие же функции по управлению трафиком предоставляет MPLS Traffic Engineering?

Data Plane

С точки зрения передачи данных TE несколько отличается от LDP. Жирным выделены отличия:

Control Plane

А вот в плане управления отличия гораздо более значительные. C ними всю оставшуюся дорогу и будем разбираться.

Терминология

LSP — Label Switched Path — вообще говоря, любой путь через сеть MPLS, но порой подразумевают LDP LSP. Однако мы не будем столь категоричны — при необходимости я буду указывать, что имею в виду именно LDP LSP.
RSVP LSP — соответственно LSP, построенный с помощью RSVP TE с учётом наложенных ограничений. Может также иногда называться CR-LSP — ConstRaint-based LSP.
Туннелем мы будем называть один или несколько MPLS LSP, соединяющих два LSR-маршрутизатора. Метка MPLS — это по сути туннельная инкапсуляция.
В случае LDP — каждый LSP — это отдельный туннель.
В случае RSVP туннель может состоять из одного или нескольких LSP: основной, резервный, best-effort, временный.
Говоря TE-туннель, мы будем подразумевать уже конкретно MPLS Traffic Engineering туннель, построенный RSVP-TE.
TEDB — Traffic Engineering Data Base — тот же LSDB протоколов IS-IS/OSPF, но с учётом ресурсов сети, которые интересны модулю TE.
CSPF — Constrained Shortest Path First — расширение алгоритма SPF, которое ищет кратчайший путь с учётом наложенных ограничений.

Итак, MPLS TE хочет строить LSP с учётом требуемых ресурсов и пожеланий оператора, поэтому столь простой LDP с его лучшим маршрутом тут не у дел.

И его место занимает RSVP-TE — наследник отвергнутого стеком TCP/IP протокола RSVP.
TE работает в тесном симбиозе с IGP. Хотя правильнее это называть паразитизмом. Он вынуждает их (OSPF или IS-IS) служить себе: переносить нужную ему информацию и тем самым наполнять TEDB.

Процесс выглядит следующим образом:

Далее мы будем ходить вокруг да около вот этой схемы:

У нас есть L3VPN-клиент, офисы которого подключены к Linkmeup_R1 и Linkmeup_R4.

Способы направления трафика в TE-туннель

В отличие от LDP LSP, по которым трафик бежит по умолчанию и так, в TE-туннели трафик нам нужно направить.

И есть для этого следующие способы:

Статический маршрут

Самый простой в понимании и самый сложный в обслуживании способ.

По сути тот же статический маршрут.

IGP Shortcut

Этот способ наиболее распространённый и поддерживается почти всеми производителями.
Маршрутизатор рассматривает туннель, как виртуальный интерфейс. И через этот интерфейс удалённые маршрутизаторы словно бы непосредственно подключены к локальному, а не находятся в десятках хопов. Этакая телекоммуникационная червоточина. Она и называется — shortcut — сокращённый путь.

Червоточина Фламма

Но протоколы IGP по умолчанию не хотят этого видеть и используют для отправки трафика физический интерфейс.

С помощью IGP Shortcut (в цисконародье AutoRoute Announce) мы вынуждаем протокол маршрутизации на Ingress LSR рассматривать туннель как обычную линию — Egress LSR будто бы подключен непосредственно. А соответственно и все сети, находящиеся за Egress LSR, будут доступны через туннель.

Таким образом всё, чьей точкой назначения является этот маршрутизатор, или узлы за ним, будет отправлено в туннель. В том числе и VPN-пакеты.

Таким образом туннель становится обычным интерфейсом, и, как у любого другого интерфейса у него должна быть метрика.

Метрика туннеля

Во-первых, есть два типа метрик:

Метрика IGP — хорошо известная нам из курса базовой маршрутизации метрика интерфейсов.
Метрика TE — та метрика, которая будет использована при расчёте метрики TE-туннеля.

Если есть IP-пути, которые не имеют общих сегментов с туннельным LSP, и при этом их метрики равны, будет иметь место балансировка.

Во-вторых, у нас есть следующие способы управления метрикой туннеля:

Вот человек очень доступно объясняет, как работают метрики.

Ну и вообще рекомендую ресурс: labminutes.com/video/sp

Forwarding adjacencies

Forwarding adjacencies — штука сходной c IGP Shortcut природы с той лишь (существенной) разницей, что туннель теперь будет анонсироваться Ingress LSR IGP-соседям, как обычный линк. Соответственно, все окружающие маршрутизаторы будут учитывать его в своих расчётах SPF.

IGP Shortcut же влияет только на таблицу маршрутизации на Ingress LSR, и окружающие соседи про этот туннель не знают.

Tunnel-policy*

*Этот способ зависит от производителя — у кого-то есть, у кого-то нет.
Tunnel-policy применяется для перенаправления исключительно трафика VPN в туннели.
То есть в режиме настройки VPN (не важно, L2 или L3) указывается какой туннель должен быть использован.

Существует две возможности:

Особенности Juniper

У джуна зачастую свой подход (ещё сегодня в этом убедитесь). Так у него существует несколько таблиц маршрутизации:

Это в некотором смысле похоже на микс Tunnel-Policy и IGP Shortcut, только автоматически.

Практика

Всё та же сеть, но с ограничениями по пропускной способности.

Нам нужно обеспечить L3VPN клиенту.
У клиента есть требования: 8 Мб/с. Вынь да положь.
Направляем трафик в туннель через Auto-Route.

В лаборатории ограничение интерфейса — 10000 кб/с. Поэтому при задании требований туннеля и доступных полос, отталкиваемся исключительно от этой цифры.

Итак, начнём с того, что никакого LDP — только RSVP-TE. То есть LSP нет, пока мы не настроим туннель.

Хоть мы всё это уже и делали в прошлый раз, но начнём настройку сначала.

И заодно на всех интерфейсах сразу настроим ограничение по полосе пропускания

При указании требования по полосе для туннеля данная команда является обязательной — полосу нужно задать явно, иначе IGP эту информацию не анонсирует, а CSPF соответственно не будет учитывать эту линию и не вычислит путь под требования туннеля.

На схеме выше я обозначил, какие из интерфейсов имеют ограничение в 5Мб/с. Если не подписано, то ограничения нет — ставим 10.

Следует всегда помнить, что это только референсное значение для расчёта пути TE, и фактически команда никак не ограничивает реальную скорость TE-трафика, через интерфейс.

Обратите внимание, что команда ip rsvp bandwidth указывает полосу только в одном направлении. То есть если мы настроили её на интерфейсе E0/0 в сторону Linkmeup_R2, то это означает, что в 5Мб/с ограничена полоса только для исходящего трафика.
Чтобы ограничить в другую сторону, нужно настроить интерфейс E0/1 со стороны Linkmeup_R2.

Команда metric-style wide — обязательна, напоминаю. Дело в том, что TE использует новые TLV с расширенными метками, а по умолчанию ISIS генерирует только короткие.

Поскольку конфигурация полностью одинаковая, для других узлов не привожу.

Здесь мы указали, что туннель строим до узла 4.4.4.4, требуется 8 Мб/с, а LSP строится динамически (без Explicit-Path)

Сразу после этого видим, что туннель поднялся.

То есть CSPF рассчитал маршрут с учётом нашего ограничения, RSVP PATH успешно сигнализировал путь, а RSVP RESV зарезервировал ресурсы на всём пути.

Трассировка показывает, что путь проложен ровно так, как мы этого хотели.

А в сообщении RSVP PATH можно увидеть, что он несёт информацию о требуемой полосе.

В дампе вы можете видеть начало объекта ERO с перечислением всех узлов по пути будущего RSVP LSP и запрос резервирования полосы пропускания.
Здесь стоит 1000000 Байтов в секунду или ровно 8 Мегабит в секунду (если мы не путаем Мега с Меби). Величина эта дискретная и меняется с некоторым шагом. В случае данной лабы — это 250 кб/с.

Можете поиграться с параметрами и увидеть, как туннель реагирует на изменения в сети.

То же самое на обратной стороне:

При необходимости можно также настроить метрику туннельного интерфейса:

На этом шаге сначала CSPF вычисляет список узлов, через которые нужно проложить LSP. Выхлоп этого процесса помещается в объект ERO. потом RSVP-TE с помощью сообщений PATH и RESV резервирует ресурсы и строит LSP.

Но этого ещё недостаточно для практического использования туннеля.

Теперь LoopBack удалённого PE стал доступен через туннель, а маршруты добавились в таблицу маршрутизации VRF.

То есть когда IP-пакет приходит от клиента,
а) он получает метку VPN (16).
б) из FIB VRF TARS ему известно, что для данного префикса пакет должен быть отправлен на адрес 4.4.4.4
в) До 4.4.4.4 есть TE-туннель (Tunnel 4) и известна его пара выходной интерфейс/метка — Ethernet0/1, 18 — она будет транспортной.

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

Сейчас путь от R1 до R4 выглядит так: R1->R5->R2->R6->R3->R4 — всё из-за этих чёртовых ограничений.

Теперь начинаем баловаться.
Попробуем разорвать наш рабочий линк R3->R4, пока длится непрерывный пинг.

LSP перестроился на R1->R5->R2->R6->R3->R7->R4 с потерей одного пакета. Это время может значительно увеличиться, если физического падения линии не будет на маршрутизаторах.

Если у нас не останется путей, удовлетворяющих заданным условиям — беда — LSP не будет.

Например, выключим линию R2-R5 и наблюдаем падения TE-туннеля на R1 без его дальнейшего восстановления.

Переоптимизация туннелей

Если линк R3->R4 восстановится, туннель перестроится обратно?
Да. Но не скоро. Пролетит много пакетов, прежде чем Ingress PE шевельнёт своим RSVP. (На самом деле зависит от производителя)
Это называется переоптимизацией туннелей (Tunnel reoptimization). С некоторой периодичностью Ingress PE заставляет CSPF проверить, а не появилось ли более оптимальных маршрутов.

Способы управления туннелями

Итак, у нас достаточно способов, как повлиять на путь трафика с помощью TE:

Метрика пути MPLS TE

Для чего может понадобиться настраивать TE-метрику отличной от IGP?
Например, есть линия с высоким значением задержки. Ей задаём бОльшее значение TE-метрики.
Тогда:
При построении туннелей для голосового трафика будем использовать TE-метрику,
В туннелях для прочих данных — IGP.

Используется для этого команда

Чтобы указать туннелю, какую учитывать метрику:
Значение по умолчанию:

Ограничение по полосе пропускания

На практике мы познакомились с базовой функцией TE — возможностью строить MPLS туннели с резервированием ресурсов на всём протяжении LSP.

Но не беспокоит ли вас вот эта идея с Bandwidth? Не возвращаемся ли мы в каменный век, когда не было переподписки. Да и как вообще определять величину этого ограничения? А что делать с тем, что она плавает в течение суток на порядки?

Offline Bandwidth

Метод, когда мы настраиваем статическое значение требуемой полосы, называется Offline Bandwidth.
Идея в том, что есть некая программа стоимостью в трёшку на Патриарших прудах, которая по каким-то алгоритмам вычисляет для вашего трафика одну цифру, которую вам и нужно настроить на туннеле.

Полосу можно настроить для всего туннеля, как мы делали это выше на практике:

А можно для конкретного RSVP LSP:

Это значение может отличаться от того, что указано для туннеля и имеет более высокий приоритет.

При этом для другого LSP (path-option 2, например), значение может отличаться — мол, если уж не получается зарезервировать 8 Мб/с, давай хотя бы 5 попробуем?

У Offline Bandwidth есть два существенных минуса:
— Ручная работа, которой хороший инженер старается избегать.
— Неоптимальное использование ресурсов. Ну, назначим мы полосу в 300 Мб/с клиенту, зарезервируем на каждой линии, а на деле ему надо-то от силы 30. И только в пике, когда у него бэкапятся БД, нужно 300. Неаккуратненько.

Этот вариант практиковался на заре появления TE. Существует он и сейчас.
Однако, следуя в ногу со временем, нужно быть более гибким и податливым.

Auto-Bandwidth

А Autobandwidth молодец.
Этот механизм отслеживает загрузку туннеля в течение определённого периода и потом адаптирует резервирование.

Терминология

Adjust Interval — время, в течение которого маршрутизатор наблюдает за трафиком и отслеживает пики.
Adjust Threshold — порог, после которого RSVP перезапрашивает резервирование.

Например, Adjust Interval у нас 2 часа. Текущее значение зарезервированной полосы пропускания — 90 Мб/с.
Adjust Threshold — 20 Мб/с.

В первом интервале всплеск 119 Мб/с (до 119 Мб/с) — больше порога. Значит RSVP-TE пытается построить новый туннель с новыми значениями для полосы пропускания.

Во втором — 23Мб/с (до 142) — опять больше порога. Обновляем резервирование по возможности.

В третьем максимальное значение падает до 137 Мб/с — разница только 5. Ничего не происходит.

В четвёртом всплеск падает до 116 (разница 21) — RSVP сигнализирует новый LSP с пониженными требованиями по полосе.

Так, каждые два часа будет происходить проверка и, возможно, перестроение туннелей.
Чем короче Adjust Interval, тем, соответственно, чаще будет обновляться резервирование и более рационально использоваться доступная полоса пропускания.

Примерно так при двухчасовом интервале будет выглядеть 24-часовое поведение auto-bandwidth.

Уже заметили проблему?
Возьмём типичный профиль утреннего трафика:

И такая дребедень целый день.

Вот измерили мы в 8 утра всплеск — 200 Мб/с. И два часа держится это значение для туннеля. А за это время на работу уже пришёл народ и запустил ютуб — средняя скорость уже 240, а всплески до 300. До 10 утра будет происходить тихая деградация. Тихая, потому что ни туннель, ни Auto-Bandwidth о ней не знают. А вот пользователи знают и их ИТшник тоже знает, уж поверьте.

Если же сильно уменьшать интервал юстировки, то на сети будут постоянно пересигналзироваться новые LSP.

Для решения этой и других проблем существуют механизмы Overflow и Underflow. Первый — для слежения за ростом трафика, второй — за снижением.
Если разница между текущим резервированием и всплесками трафика превосходит порог Overflow несколько раз подряд, RSVP TE будет пробовать построить новый LSP, не дожидаясь истечения Adjust Interval.

То же и для Underflow — RSVP-TE будет пересегнализировать LSP с более низкими требованиями, если заметил тенденцию к уменьшению объёма трафика.

И остаётся только одна, но серьёзная проблема.
Так уж устроен наш мир, что когда растёт трафик у одного абонента, обычно растёт и у другого. И может так статься, что когда придёт время снова увеличить резервирование, увеличить его будет уже некуда — всё занято. И тогда, если нет других путей, удовлетворяющих новым условиям, будет использоваться старый. И никому не будет дела до того, что его уже не хватает, что пакеты начали теряться, что клиент ищет номер директора, чтобы найти инженера, которому можно оторвать что-нибудь лишнее.

Мы с этим будем бороться с помощью приоритезации туннелей, о которой ниже.

Для включения функции AutoBandwidth глобально и одновременно настройки Adjust Interval:

Далее для каждого туннеля отдельно нужно активировать AutoBandwidth. При этом можно задать другое значение для Adjust Interval, а также установить минимально и максимально возможные значения для резервируемой полосы.

Для настройки Overflow:

Подробнее о Auto-Bandwidth можно почитать в очень честном документе.

Приоритеты туннелей

Это механизм, который приоритезирует туннели: какой из них важнее. Он применим, как для случая Auto-Bandwidth в частности, так и для любого построения RSVP LSP вообще.

Всё предельно логично:
Setup Priority — приоритет установки RSVP LSP.
Hold Priority — приоритет удержания RSVP LSP.

Если полосы пропускания не хватает на узле, и у нового туннеля приоритет установки выше, чем приоритет удержания у старого, новый будет построен — старый сломан.

Оба имеют 8 значений: от 0 до 7. Для обоих 0 — это наивысший, 7 — наинизший.

Например, у нас есть туннель LSP1, у которого Hold priority 4.
Тут приходит запрос от RSVP-TE на LSP2 с Setup Priority 6 и Hold Priority тоже 6. Если полосы пропускания достаточно, то он просто построится. Если нет — то маршрутизатор не даст этого сделать — потому что уже существующий туннель приоритетнее нового (4>6).
Допустим, полосы достаточно и оба туннеля поднялись нормально.
И тут приходит новый запрос на LSP3 с Setup/Hold Priority 5. Это выше, чем у LSP2, но ниже, чем у LSP1. И ему полосы уже не хватает. LSP1 точно не будет тронут, потому что его Hold приоритет до сих пор самый высокий. И тогда есть два варианта:

Существует два режима замещения туннелей:
Hard preemption — LSP с более высоким приоритетом просто замещает LSP с низким. Даже если потом LSP с низким приоритетом найдёт новый путь, часть трафика будет потеряна.
Soft preemption — применяется механизм Make-Before-Break. Маршрутизатор через RSVP-TE сообщает Ingress LSR низкоприоритетного LSP, что нужно искать новый путь. LSP с высоким приоритетом ожидает, пока трафик низкоприоритетного LSP переключится на новый LSP.
При этом, если путь найти не удалось в течение некоторого времени, низкоприоритетный LSP всё равно ломается и строится высокоприоритетный.

Данные о приоритетах замещения передаются в RSVP-TE PATH и учитываются при резервировании ресурсов на промежуточных узлах.

Практика

Если вы обратили внимание, то после настройки tunnel mpls traffic-eng badnwidth на туннельном интерфейсе, в конфигурации автоматически появляется строка tunnel mpls traffic-eng priority 7 7.

Дело в том, что без требований по полосе приоритеты не имеют никакого значения — через один узел можно проложить сколько угодно туннелей — ведь полоса не резервируется — и команды нет.

Но, как только появилось требование, по полосе, приоритеты начинают играть роль.
7 — это значение по умолчанию — наименьшее.

Давайте на Linkmeup_R1 настроим новый туннель до 4.4.4.4 с более высоким приоритетом?

Необходимая полоса всего 4Мб/с. Поэтому туннель должен пройти по пути R1->R2->R3->R4.

Так и есть, вот его трассировка:

С Tunnel4 у них только один общий линк R3->R4, но его полоса пропускания только 10. А двум туннелям нужно 8+4=12.
Tunnel42 с приоритетом установки 4 выдавливает Tunnel4 с приоритетом удержания 7.
И тому приходится искать новый путь.

Сначала удаляется старый RSVP LSP Tunnel4 и сигнализируется новый по доступному пути

Потом RSVP-TE сигнализирует LSP для Tunnel42.

В этот момент вернёмся к Autobandwidth. Именно связка Tunnel priority + Autobandwidth даёт элегантное решение.

Одним ранним утром было трафика мало, autobandwidth подсчитал сколько именно его в каждом туннеле, и TE везде хватило пропускной способности.

Потом ближе к обеду трафик подрос, autobandwidth адаптировался, перерезервировал новые полосы — всё ещё хватает.

К вечеру один за другим туннели начинают вылетать, потому что TE не может зарезервировать новую полосу.

И тут важно, чтобы туннели жирных клиентов, IP-телефонии и канал для МВД никогда не падали. Тогда задаём для этих туннелей Hold priority выше, чем Setup priority других.

— При попытке низкоприоритетных зарезервировать новую полосу на интерфейсе, где её уже не хватает, он обломится.
— Высокоприоритетный наоборот вытеснит низкоприоритетный и займёт освободившуюся полосу.

Explicit-Path

Идея Explicit-Path более чем полно была раскрыта в 10-м выпуске СДСМ.

Как вы помните, CSPF вычисляет кратчайший путь с учётом ограничений. Далее этот путь трансформируется в объект ERO (Explicit Route Object) сообщения RSVP-TE PATH, который явно сообщает, по какому пути этот PATH нужно передать.

Так вот если, вы хотите, чтобы какие-то узлы обязательно присутствовали или наоборот отсутствовали в этом пути, можно это явно указать в Explicit-Path, который станет одним из входных ограничений для CSPF.

Итак, мы вручную задаём, через какие узлы должен пролечь LSP, а через какие не должен.
RSVP-TE просит CSPF рассчитать маршрут с учётом Explicit-Path и других ограничений туннеля.
Если одно входит в противоречие с другим — беда, не будет LSP.

Explicit-Path — это строго локальное ограничение — только Ingress LSR о нём знает и не передаёт ни в анонсах IGP, ни в сообщениях RSVP-TE.

Настройка Explicit-path выполняется в два этапа:
1) Создание самого explicit-path с ограничениями:

2) Примение его к path-option на туннеле:

SRLG — Shared Risk Link Group. Ещё один способ повлиять на LSP и отличная идея против плоских колец.

Задача этой функции предотвратить построение основного и резервного LSP через линии, которые могут повредиться одновременно.

Например, два волокна, которые физически проходят в одном кабеле, наверняка порвутся одним и тем же ковшом экскаватора.

SRLG-группа — группа интерфейсов, которые «разделяют риск». О! Группа риска.

Вручную (конечно, а как иначе маршрутизатор узнает, что это физически идентичные линии) настраиваются интерфейсы, которые являются членами одной SRLG-группы.
Информация о SRLG распространяется по сети вместе с анонсами IGP, как и доступная полоса или значение Attribute-Flag, и помещается потом в TEDB.
Далее CSPF должен учитывать эту информацию при расчёте кратчайших маршрутов.

Имеется два режима:
Force Mode заставляет CSPF учитывать данные SRLG обязательно — если иного пути нет, то резервный LSP не будет построен вообще.
Preffered Mode допускает построение запасных туннелей через SRLG-линии, если нет иных возможностей.
Режим задаётся на Ingress LSR.

Для добавления интерфейсов в одну группу риска на любых узлах вводится команда:

А на Ingress PE включить проверку SRLG:

Что это за команда, поговорим в разделе FRR.

Administrative Groups или Affinity

Вот сейчас должно стать страшно. Мне страшно.

Итак, к данному моменту мы узнали про четыре инструмента управления трафиком:

Пока вы не согнулись под тяжестью знаний, расскажу вам такую историю.

Огромнейшая сеть linkmeup. Своя оптика, свои РРЛ пролёты, куски лапши, доставшиеся от купленных домонетов, куча арендованных каналов у разных операторов. И через всё это хозяйство MPLS, хуже того — TE-туннели.

И для разных сервисов важно, чтобы они шли определённым путём.
Например, трафик 2G ни в коем случае не должен идти через РРЛ-пролёты — проблемы с синхронизацией нас съедят.
Трафик ШПД нельзя пускать через линии Балаган Телеком, потому что эти паразиты из 90-х берут деньги за объём пропущенного трафика.
Разрешать строить туннели через сети доступа вообще запрещено категорически.

И с этим нужно что-то делать.

Каждый раз, настраивая туннель, учитывать в Explicit Path все эти детали — с ума можно сойти.
Но, новая связка — удивительное спасение, которое решит все наши проблемы, просто нажмите кнопку «сделать хорошо».

Идея в том, что каждый интерфейс мы помечаем определёнными цветами.
А потом говорим, что вот этот туннель может идти по красным и фиолетовым линиям, но не может по зелёным, жёлтым и коричневым.
Marketing Bullshit! Непонятно? Мне тоже.

Итак.
Administrative Group (у Juniper: admin-group, у Cisco: Attribute-Flag) — это атрибут физического интерфейса, который может описать 32 его дискретных характеристики.
Какой бит из 32 за что отвечает решает оператор самостоятельно.
Раз уж примеры у нас в консоли Cisco, то далее буду использовать термин Attribute-Flag наравне с Administrative group, что не совсем правильно.

Например,
считаем с наименее значимых битов (с конца):
первый бит в 1 означает, что это оптика
второй бит в 1 означает, что это РРЛ
третий бит в 0 означает, что это линия в сторону сети доступа, а 1 — магистральный интерфейс.
четвёртый бит в 1 означает, что это аренда
пятый бит в 1 означает, что это Балаган-Телеком
шестой бит в 1 означает, что это Филькин-Сертификат
седьмой бит в 1 означает, что это канал через интернет без гарантий.
…
десятый бит в 1 означает, что полоса пропускания меньше 500 Мб/с
итд. я так могу все 32 утилизировать.

Affinity и маска — это требования туннеля к своему пути.
Какие отношения могут сложиться в этом треугольнике ?

Если это равенство выполняется, туннель можно строить через этот интерфейс.

Рассмотрим на примере.
У нас есть 32 бита и политика — за что отвечает каждый из них (возьмём пример выше).

В Mask мы указываем, какие характеристики канала нас интересуют. Например, для туннеля с трафиком 2G важно

Mask: 0100 0110
Взяли только первые 8 бит для простоты.
Заметьте, что это Wildcard Mask.

В Affinity мы указываем, что именно нам нужно.

Выполняем операцию и получаем: 0000 0100.

Теперь возьмём для примера три интерфейса.

То есть при построении LSP на каждом линке будет учитываться значение Attribute-Flag.
По умолчанию значение Attribute-Flag на интерфейсе — 0x0. И в некотором смысле — это прискорбно — ведь результат операции «И» с маской будет отличаться от результата с Affinity, а значит мы должны настроить Attribute-Flag на всех интерфейсах.

Соответственно, в пределах компании можно выработать политики, как помечать интерфейсы и как управлять трафиком. Можно возложить эту задачу даже на систему управления, чтобы работа инженера сводилась к расстановке галочек в графическом интерфейсе, а конфигурация затем применялась бы автоматически.

Но в любом случае это не умаляет человеческого фактора с одной стороны и просто непостижимой сложности отладки и обслуживания с другой.

Однако случаи комплексного внедрения Administrative Group даже на сетях российиских операторов имеются.

Другим примеров использования могли бы быть коды регионов или стран. Тогда можно было бы задавать через какую географию пропускать трафик.

В этом свете 32 бита оказывается очень мало, поэтому RFC 7308 определяет расширенные административные группы, количество бит в которых ограничено естественым пределом LSA или вообще MTU.

Парень на пальцах разжёвывает Affinity и в рот стопочкой складывает.

Практика

Очень очень короткая. Просто посмотрим, что работает. Короткая, потому что применение Affinity требует настройки Attribute-Flag на всех узлах и всех интерфейсах. А это то, чего меньше всего хочется, если честно.

Продолжаем с последней конфигурации, где у нас два туннеля.
Файл конфигурации.
Tunnel42 идёт по пути R1-R2-R3-R4. С ним и поиграем.

Значение Attribute-Flag по умолчанию 0x0. Поэтому его и возьмём в качестве Affinity — то есть все интерфейсы у нас подпадают под условие. Кроме R3-R4, на котором мы настроим Attribute-Flag 0x1. Поскольку равенство не выполнится — CSPF не сможет строить кратчайший путь через этот линк.

И наблюдаем, как туннель пошёл в обход этого линка.

Однако при этом благополучно развалился Tunnel4. Значение Affinity по-умолчанию тоже 0x0, но маска 0xFFFF. Поэтому он тоже не вписался в перенастроенный линк R3-R4.

Но, мы могли бы настроить на нём маску 0x0 — не учитывать никакие биты Affinity и Attribute-Flag:

И тогда туннель поднимется, не учитывая эти ограничения.

Надёжность и сходимость

На практике мы уже видели, что перестроение туннеля в случае поломки занимает несколько секунд. Что ж, не так уж и плохо было во времена моего деда.

Вся история развития компьютерных сетей — это история борьбы с авариями, борьбы за скорость сходимости, за уменьшение времени перерыва.
Что у нас есть на вооружении?

Если бы эволюция строила людей по этому принципу, мы бы умирали преимущественно от старости (вторая причина по числу смертей была бы «погиб под собственным весом»).

Защита на физическом уровне обычно предоставляет время сходимости в ±50 мс.
IP хорош, но сходится за секунды, а то и минуты.

MPLS TE предлагает две опции для повышения стабильности и уменьшения времени прерывания сервисов.

Первая реализует защиту на уровне всего LSP, вторая — на уровне линка или узла — и она называется FRR — Fast ReRoute.

Path Protection

При настройке туннеля мы можем указать, сколько и каких LSP мы хотим построить.

В этом ключе понятное дело, что non-standby совсем не дело. Опираясь на IGP, RSVP-TE сначала ждёт обновления маршрутной информации, потом сам должен отработать — счёт на секунды. Сигналом является уведомление от RSVP-TE или BFD, что LSP больше не живой, либо информация от IGP об изменении топологии.

Для случая Standby строится одновременно основной RSVP LSP и резервный. Соответственно, как только Ingress LSR фиксирует разрыв шаблона основного LSP, трафик сразу переключается на запасной — нам грозит потеря только тех пакетов, которые были посланы ровно до момента, как авария была зафиксирована.

Local Protection (FRR)

А вот FRR — Fast Reroute — позволяет спасти даже те машинки, которые прямо сейчас уже стремятся к назначению, не подозревая ещё, что там мост обвалился. То есть FRR — это как объезд на участке трассы, где ведутся ремонтные работы, а Backup LSP — это другая трасса.

FRR использует обходные пути и описан в RFC4090 Среднее время переключения после детектирования аварии — 50мс.

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

Как это обычно и бывает, вещи которые просто настраиваются, скрывают под пальто нечто интересное.

Итак, у FRR есть две функции:

Когда случается страшное, он просто уводит пакеты в обходной туннель.

На иллюстрации а) показана защита линии. На б) — защита узлов.
Берём LSP от R1 до R4. Каждый узел по пути, кроме R4, будет пытаться строить свои обходные пути.
Так R1 для защиты линии R1-R2 выберет путь R1->R5->R2. А для защиты от падения узла R2: R1->R5->R6->R3.
R2 должен защитить линию R2-R3 и узел R3.
ИТД.

Терминология

PLR — Point of Local Repair — точка расхода. Это узел, который инициирует защиту линии или узла. Может быть Ingress PE или любой транзитный P, но не Egress PE
MP — Merge Point — точка схода, куда приземляется защитный туннель. Любой транзитный P или Egress PE, но не Ingress PE.
Primary LSP или Protected LSP — исходный LSP, который требует защиты.
Bypass LSP — защитный LSP.
NHOP — Next Hop — следующий после PLR узел в Primary LSP.
NNHOP — Next Next Hop — соответственно следующий узел после Next Hop.

Давайте сначала с Link Protection разберёмся?

FRR Link Protection

Задача FRR — спасти те пакетики, которые летят прямо в пропасть рухнувшего линка, уведя их на этот самый Bypass LSP.

Когда PLR замечает, что линия, через которую лежит транзитный LSP, упала, он мгновенно перенаправляет трафик. Заметьте, что не Ingress PE этим занимается, а именно тот узел, на котором произошёл обрыв. Падение линка фиксируется по падению интерфейса или BFD-сессии.

Можно сравнить FRR со стрелкой на железнодорожных путях.
Чтобы так быстро перенаправить пакеты, Bypass LSP должен быть построен заранее. Так и происходит.

Каждый узел по ходу Primary LSP ищет, как обойти падение следующего линка и падение следующего хопа.

То есть он запускает полный механизм построения LSP:

Поэтому давно существует механизм AutoTunnel, который инструктирует каждый узел на пути Primary LSP самостоятельно и автоматически рассчитывать Bypass-туннели.
Включается он на Ingress LSR командой глобального режима:

Идея auto-tunnel значительно глубже, чем только автоматические FRR-туннели. Читать об этом тут.

Теперь нужно решить две задачи —
— как в этот Bypass LSP поместить пакеты из Primary LSP.
— Как на MP понять, что с полученным счастьем делать.

Всё очень просто — FRR LSP — это обычный туннель. То есть нам достаточно туннелировать наш предыдущий туннель на участке от PLR до MP, а это значит, добавить ещё одну MPLS-метку в каждый пакет. Итого их будет 3: VPN, Tunnel, FRR.

Итак, когда пакет приходит на PLR во время аварии, тот сначала делает обычный SWAP внешней метки, словно бы он должен был выйти через старый (в данный момент сломанный интерфейс) и ещё он знает, что надо передать его в FRR туннель — добавляет ещё одну метку.

Далее пакет коммутируется по Bypass LSP по стандартным правилам — меняется внешняя (FRR) метка, а две внутренние остаются неизменными.

На предпоследнем узле внешняя метка снимается — PHP и до MP пакет идёт с изначальными двумя.
MP получает пакет, смотрит на транспортную метку и далее коммутирует пакет, словно бы ничего и не происходило.

Важно, что всё это работает, только если используется глобальный пул меток, а не специфичный по интерфейсам. Так MP не учитывает, с какого интерфейса пришёл пакет с данной меткой.

FRR Node Protection

Всё абсолютно то же самое за исключением транспортной метки — PLR должен знать какую метку ждёт NNHOP.

Туннель теперь строится не до следующего узла, а через один — NNHOP. В этом помогает атрибут сообщения RSVP — LRO (Label Request Object). Будучи в RSVP PATH он просит узлы по пути выделять метки.

А в RSVP RESV Label Object содержит эти самые выделенные метки.

Bandwidth Protection

При сигнализации Bypass LSP возникает вопрос: а резервировать ли ресурсы.
Если да, то это уже называется Bandwidth Protection.

При этом обычно нет смысла два раза резервировать ресурсы для одного и того же туннеля. Ну действительно — от того, что мы увели трафик из Primary в Bypass ведь не следует, что ресурсы будут использоваться дважды на PLR и MP? Тем более, что свободной полосы вообще может не хватить. Поэтому вводится понятие SE (Shared Explicit). Если в изначальном RSVP PATH будет установлен этот атрибут, ресурсы не будут резервироваться дважды — промежуточные узлы буду знать, что это не совсем независимый LSP — это старый задумал что-то.

Итак, процедура следующая:

Тут есть два варианта:

Этот метод очень похож на Facility, но есть одно существенное отличие. В режиме Facility существующие LSP туннелировались в Bypass LSP, получая третью метку в стек. В режиме One-to-One при обходе препятствия в стеке останется две метки, то есть это будет выглядеть и работать, как самый обычный LSP.

PLR при обнаружении аварии, полученные пакеты старых LSP будет отправлять по новому пути, просто выполнив обычный Swap транспортной метки. Но метка и выходной интерфейс будут новыми — от Detour LSP.

DMP также выполняет обычный Swap транспортной метки. Вместо метки Detour LSP он подставляет старую от Primary LSP и отправляет дальше.

Я разобрал подробно режим Facility, потому что он наиболее часто используемый.

Теперь, когда более менее разобрались с концепцией FRR, добро пожаловать в болото деталей.

Как это водится, когда мы погружаемся слишком глубоко, в игру вступают квантовые законы, а технологии теряют свою вендоронезависимость.

Например, в терминологии Juniper, One-to-One режим называется Fast Reroute — да вот так странно и называется. Разработчиков как-то не напрягает пересечение с FRR в более высокой ступени иерархии. Ну хоть link и link-node protection вторым названием имеют Facility mode.

Потом, Cisco не поддерживает режим One-to-One, поэтому для реализации FRR важно, чтобы MPLS-маршрутизаторы использовали глобальный пул меток, а не по интерфейсам. Да и ладно — не очень-то и хотелось.

Зато Cisco обладает гибким механизмом, какие LSP туннелировать и для каких нужно резервировать полосу. Подробнее.

Если говорить про Huawei, то по умолчанию режим Facility предполагает ручную настройку туннелей на PLR. Но есть режим Auto-FRR — тогда всё будет работать автоматически.

Как говорится, чем дальше в сельву, тем злее гаучо.

Вот и всё, что нужно знать об FRR.

Практика

Продолжаем всё с той же сетью и с того момента, на котором мы остановились (если не считать affinity).
Файл конфигурации.

Path-Protection

Добавим Standby LSP с более низкими требованиями полосы пропускания: 3 Мб/с.

Обратите внимание, что Preference (1) должен быть таким же, как и у Primary LSP.

Путь защитного туннеля лёг следующим образом:

Во-первых, на линии R1-R2 4 Мб/с из 5 уже занял Tunnel42. Поэтому для запасного LSP Tunnel4 не осталось полосы.

Во-вторых, основной и резервный LSP используют обычно метод резервирования полосы Shared Explicit (SE), что означает, что для одного и того же туннеля не будет полоса резервироваться дважды. Поэтому через 10 Мб/с линк R1-R5 удалось проложить и основной LSP (8 Мб/с) и резервный (3 Мб/с).

В-третьих, вы можете видеть, что резервный LSP на участке R6-R4 он выбрал тот же путь, что и основной. Поэтому использование Explicit-path иногда вполне может быть оправдано.

Для удовольствия и удовлетворения можете дёрнуть линк R2-R5 и убедится, что трафик абонентов почти не прерывался.

Если в текущей конфигурации у вас пинг прекратился и не восстанавливается, попробуйте понять почему.

Local-Protection (FRR)

Если вы всё ещё дёргаете линк R2-R5, пожалуйста, перестаньте и верните его в состояние Up.
Кроме того, для наглядности работы FRR, придётся убрать Path-Protection.
Файл конфигурации

Итак, мы хотим настроить FRR для этого Tunnel4.

1) Включаем FRR на туннеле

Логично сделать это и на другом конце

Сразу после этого RSVP сигнализировал новый атрибут вдоль LSP

Он сообщил, что для этого LSP нужна защита линка.

Но туннелей пока не появляется.

2) Теперь нужно включить возможность построения туннелей автоматически:

Что делает эта команда? Проверяет, какие интерфейсы используются под туннели, требующие Local-protection, и пытается защитить линк и следующий узел, поэтому на каждом узле (где может) строит необходимые туннели.

Например, на Linkmeup_R2 будет 4:

Обратите внимание на то, что защитные туннели строятся без какого-либо учёта полосы пропускания, пока об этом отдельно не будет сказано.

Так, теперь я хочу разорвать линию R2->R6.
По идее для защиты этой линии у нас есть Tunnel65436 (R2->R5->R6). Но тогда полный путь будет выглядеть немного странно: R1->R5->R2->R5->R6-R3->R4 — то есть по линии R5-R2 трафик пройдёт дважды — туда и обратно. Поэтому R2 ненадолго включает интеллект и выбирает Tunnel65437, который напрямую ведёт к R3.

Тогда на участке R2-R3 мы должны увидеть две метки в стеке — VPN и туннельную. Метка bypass не будет вставляться, потому что PHP.

Если хочется, увидев все три метки, убедиться, что FRR работает, введите на R2 команду

Она заставит R2 использовать тот самый странный путь.

Здесь нужно быть аккуратным. Я на это попался.

Дело в том, что у нас нет реального бешеного трафика, на котором можно было бы заметить переключение с Bypass-туннеля FRR на заново построенный Primary.

Я хочу сказать, что Primary LSP успевает восстановиться в промежутке между двумя ICMP-запросами. И тогда в дампе вы увидите не Bypass LSP, а перестроенный Primary LSP, а соответственно, не три метки, а две.

И в этой нелёгкой учебной ситуации нам помогает полоса пропускания — Primary LSP не сможет перестроиться через линию R2->R3 из-за недостатка свободной полосы, а Bypass LSP, не учитывающий этого, сможет.

Таким образом переключения с Bypass на Primary не произойдёт, и мы можем наслаждаться долгоживущим Bypass.

Смотрим на VPN и транспортную метки R1:

PUSH VPN — 16
PUSH Tunnel — 26

Смотрим таблицу меток на R5:

SWAP Tunnel 16->27 (метка, которую ждёт NHOP)
PUSH Bypass Implicit Null — то есть реально метку не вставляем.

PHP: POP Tunnel 27 (дождался).

Смотрим дамп на участке — 2 метки (implicit null не был реально добавлен):

Ну и напоследок пара лёгких тем без практики.

MPLS QoS

Теме QoS будет посвящён отдельный выпуск. Готовьтесь. Но не поговорить немного об этом сейчас было бы непростительно.

MPLS TE IntServ

Итак, MPLS TE использует парадигму IntServ QoS — предварительное резервирование ресурсов по всему пути.

То есть мы изначально уверены, что необходимая полоса (и другие требования) будет предоставлена сервису. При этом пакеты внутри туннеля (LSP) все равнозначны.

Однако, такое случается, что трафик у клиента растёт. Может, в какой-то момент его объём превосходит статически настроенный порог, а свободной полосы больше нет, или Autobandwidth ещё не успел отработать повышение скорости.

Так или иначе — пакеты начинают отбрасываться, причём безо всякого разбора — важные они или нет.

То есть идея IntServ в реализации MPLS TE сама по себе ещё не гарантирует, что на каждом отдельном узле проблем не возникнет.

MPLS TE DiffServ

А кто у нас там отвечает за Per-Hop Behavior? Напомните? DiffServ? А не объединить ли нам эти две прекрасные парадигмы?
Ведь в заголовке MPLS имеется поле EXP, которое планировалось Expериментальным, но уже давно официально используется для задания приоритета пакетов и называется Traffic class. Вот только по старой привычке его и сейчас продолжат называть EXP,
Это называется MPLS DiffServ-aware Traffic Engineering — MPLS DS-TE.

Идея, вообще говоря, заключается в том, чтобы MPLS-пакетам предоставить то качество сервиса, которое ожидали оригинальные пакеты. То есть в идеале нужно сделать соответствие 1 к 1. Но EXP — это всего лишь 3 бита, то есть 8 значений приоритета, тогда как DSCP — 6 бит (64 значения) — как ни крути, но детализация при такой архивации теряется.
Таким образом, существует два подхода:
E-LSP — EXP-Inferred LSP. Забить и радоваться тому, что имеем.
L-LSP — Label-Inferred LSP. Кодировать приоритет связкой EXP+метка.

Для случая, когда изначально имеем дело с полем DSCP — мы переносим в MPLS EXP только три наиболее значимых (левых) бита DSCP.
И да, мы смиряемся с потерей деталей.

Когда PDU приходит на Ingress LSR, мы помещаем его в туннель и задаём приоритет в поле EXP.
Ну например, в одном туннеле у нас пойдут данные ШПД и фиксированной телефонии. Естественно, телефонии мы дадим приоритет 5, а всему остальному 0.
Тогда даже если внутри одного туннеля случится затор, первыми будут умирать слабые.

В этом случае данные QoS кодируются в связку Метка+EXP. Предполагается, что метка задаёт механизм обработки в очередях, а метка — приоритет отбрасывания пакета.
Информация о PHB должна быть сигнализирована в процессе установки LSP.
Каждый L-LSP несёт только один тип сервиса.

На сегодняшний день операторы в большинстве своём определяют четыре класса трафика: BE, AF, EF и CS. E-LSP более чем достаточно для этого, поэтому L-LSP не только практически не используется, но и более того, не у всех вендоров реализован. Поэтому останавливаться далее на сравнении методов я даже не буду.

Режимы QoS

А вот что интересно, так это какому всё-таки полю CoS доверять на каждом узле: IP DSCP, Tunnel EXP или VPN EXP?

Uniform Mode

Это плоская модель End-to-End.

На Ingress PE мы доверяем IP DSCP и копируем (строго говоря, отображаем, но для простоты будем говорить «копируем») его значение в MPLS EXP (как туннельный, так и VPN заголовки). На выходе с Ingress PE пакет уже обрабатывается в соответствии со значением поля EXP верхнего заголовка MPLS.

Каждый транзитный P тоже обрабатывает пакеты на основе верхнего EXP. Но при этом он может его поменять, если того хочет оператор.

Предпоследний узел снимает транспортную метку (PHP) и копирует значение EXP в VPN-заголовок. Не важно, что там стояло — в режиме Uniform, происходит копирование.

Egress PE снимая метку VPN, тоже копирует значение EXP в IP DSCP, даже если там записано другое.

То есть если где-то в середине значение метки EXP в туннельном заголовке изменилось, то это изменение будет унаследовано IP-пакетом.

Pipe Mode

Если же на Ingress PE мы решили не доверять значению DSCP, то в заголовки MPLS вставляется то значение EXP, которое пожелает оператор.

Но допустимо и копировать те, что были в DSCP. Например, можно переопределять значения — копировать всё, вплоть до EF, а CS6 и CS7 маппировать в EF.

Каждый транзитный P смотрит только на EXP верхнего MPLS-заголовка.

Предпоследний узел снимает транспортную метку (PHP) и копирует значение EXP в заголовок VPN.

Egress PE сначала производит обработку пакета, опираясь на поле EXP в заголовке MPLS, и только потом его снимает, при этом не копирует значение в DSCP.

То есть независимо от того, что происходило с полем EXP в заголовках MPLS, IP DSCP остаётся неизменным.

Такой сценарий можно применять, когда у оператора свой домен Diff-Serv, и он не хочет, чтобы клиентский трафик как-то мог на него влиять.

Short-Pipe Mode

Этот режим вы можете рассматривать вариацией Pipe-mode. Разница лишь в том, что на выходе из MPLS-сети пакет обрабатывается в соответствие с его полем IP DSCP, а не MPLS EXP.

Это означает, что приоритет пакета на выходе определяется клиентом, а не оператором.
Ingress PE не доверяет IP DSCP входящих пакетов. Транзитные P смотрят в поле EXP верхнего заголовка. Предпоследний P снимает транспортную метку и копирует значение в VPN-метку.
Egress PE сначала снимает метку MPLS, потом обрабатывает пакет в очередях.

Упрощение настройки туннелей

В типичной операторской сети для масштабирования и снижения нагрузки сейчас разворачиваются L3/L2VPN на основе BGP с функцией Auto-Discovery и выделенными BGP Route Reflector.

Если в качестве транспорта используются LDP LSP, то туннели MPLS у нас автоматически образуют полносвязную топологию.

В таких условиях добавление нового PE требует настройки только этого нового PE и RR.

Однако ситуация совсем иная, если на транспорте RSVP-TE. Если узлов PE много, то может стать головной болью настроить туннели между всеми нужными парами маршрутизаторов.

Есть два подхода, которые позволяют избежать этого конфиграционного безумия.

LDP over TE

Этот подход не требует нового функционала. Вводят иерархию — в неком неизменном ядре сети поднимается полносвязная система TE-туннелей между P-маршрутизаторами.
Делается это один раз и никогда уже не меняется.
А обычные PE маршрутизаторы друг к другу строят LDP LSP.

В стеке пакета MPLS, движущегося в ядре сети, получится три метки — VPN, LDP, RSVP-TE.
То есть LDP LSP, как бы туннелируются в RSVP LSP.

Иллюстрация с сайта www.nexthop.me

На, назовём это, сегменте доступа у нас удобный и уютный LDP, а в ядре сети (это может быть междугородней магистралью) при этом есть возможность управлять трафиком.

RSVP Auto-Mesh/Auto-Tunnel

Это маленькая, но крайне полезная импрувизация, позволяющая автоматизировать настройку туннелей.

Как только в TEDB появляется новое PE-устройство, с ним моментально строятся прямые и обратные туннели.

Какая конфигурация применяется? Заранее создаётся шаблон настройки туннельного интерфейса.
Как узнать, что новый узел — это PE? В шаблоне указывается ACL, который определяет с кем можно строить.

Например, мы берём за правило, что у PE узлов интерфейс Loopback 127 будет 10.127.127.0/24, и анонсируем его в IGP.

Простейшая конфигурация будет выглядеть так:

Заключение

Хотелось бы подвести краткий итог одной фразой: всё, что было описано в данной статье, в самом деле встречается на белом свете и вовсе не замки на песке.
Поэтому кратко повторим:

MPLS TE использует RSVP-TE, как протокол распределения меток и резервирования ресурсов. А тот в свою очередь опирается на LS IGP:

Это широко используемая концепция в MPLS TE — сперва добейся! Прежде, чем сломать что-то, что уже работает, построй новый LSP.

Тесно связанные с MBB понятия.

Shared Explicit (SE) — два разных резервирования (LSP) для одного туннеля рассматриваются связанными и полоса полоскания не будет резервироваться дважды.

Fixed Filter (FF) — различные LSP от одного и того же отправителя всегда рассматриваются независимыми и полоса для них резервируются отдельно.

Режим SE очень удобен в механизме MBB, и зачастую в режиме FF отключаются вообще возможности FRR и переоптимизации.

Каждый туннель имеет два значения:

Механизмы упрощения настройки:

Полезные ссылки

Кто-то скажет: СДСМ становится всё более и более странным. Вы отрываетесь от реальности.
И будет неправ: в следующий раз всё-таки вернёмся к животрепещущим темам — QoS. Долгожданный, многообещанный, и насколько сложный, настолько же и бесполезный.
Будет так же треш и угар на 140к знаков, но про то, с чем вы каждый день работаете.

Также напоминаю, что список лучших книг по сетям сейчас тут.
Все аббревиатуры, использованные в статье, вы можете найти в глоссарии linkmeup.

Благодарности
Андрею Глазкову, Александру Клипперу и Александру Фатину за вычитку материала и комментарии.
Артёму Чернобаю за иллюстрацию.
Моей жене и детям, что терпели лишения, но позволили закрыть тему MPLS.

Источник