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

Вот почему к современным сетям предъявляются довольно высокие требования: контроль качества (QoS), высокая управляемость, масштабируемость, мультисервисность (передача разных видов трафика) и т.п. С этой целью все больше операторов сегодня используют в своих сетях оборудование с поддержкой MPLS (Multiprotocol label switching – многопротокольная коммутация по меткам) и предоставляют услуги на базе этой технологии.

Для создания опорной IP/MPLS-сети компания D-Link представляет следующие модели коммутаторов:

• DGS-3620-28SC – управляемый стекируемый коммутатор 3 уровня с 20 портами 100/1000Base-X SFP, 4 комбопортами 100/1000Base-T/SFP и 4 портами 10GBase-X SFP+
• DXS-3600-16S – управляемый стекируемый коммутатор с 8 портами 10GBase-X SFP+, 1 слотом расширения, источником питания AC и 3 вентиляторами
• DXS-3600-32S – управляемый стекируемый коммутатор с 24 портами 10GBase-X SFP+, 1 слотом расширения, источником питания AC и 3 вентиляторами

В данных коммутаторах используется следующая функциональность MPLS: поддержка протокола LDP, LER/LSR, EoMPLS (VPWS), VPLS, H-VPLS, VRF, L3 VPN MPLS, технология MPLS TE (будет доступна в следующих версиях ПО). Данное решение позволяет телекоммуникационным операторам создать мультисервисную сеть, отвечающую всем современным требованиям.

Что такое MPLS и какие преимущества предоставляет эта технология?

MPLS – это масштабируемый и независимый от любых протоколов (PPTP, L2TP, PPPoE и т.д.) механизм передачи данных. В сети на базе MPLS пакетам данных присваиваются метки. Решение о последующей передаче пакета другому узлу сети осуществляется только исходя из значения присвоенной метки без изучения пакета данных как такового. За счет этого возможно создание сквозного виртуального канала с любым протоколом передачи данных. Такой канал будет полностью независим от среды передачи.

Рассмотрим пример: требуется объединить два или более удаленных офиса через сеть оператора связи. Раньше для этого требовалось выделять отдельный VLAN, а при использовании в объединяемых офисах собственных виртуальных сетей на основе стандарта 802.1q – отдельный Q-in-Q SP-VLAN, который нужно было «прокинуть» через всю сеть от одной точки входа до
другой по цепочке коммутаторов. При такой реализации оператору приходится решать следующие проблемы:

• число VLAN ID ограничено диапазоном от 1 до 4094
• долгое время ввода услуги
• сложность организации отказоустойчивости

В IP/MPLS-сети все гораздо проще. использует виртуальные частные локальные сети VPLS (Virtual Private LAN Services) либо VPN уровня 2, что позволяет объединить распределенные локальные сети в единую сеть. Выделяется VCI из диапазона от 1 до 4294967295, настраивается точка входа. В основе концепции VPLS лежит передача пакетов Ethernet из сети заказчика (в том числе информация о внутренних VLAN) по операторской сети «прозрачным» способом без всяких изменений. Другими словами, сеть оператора связи абсолютно невидима для сети заказчика, так что ее можно строить так, будто операторской сети не существует вообще. С этой целью пакеты инкапсулируются по технологии MPLS, которая позволяет создавать тоннели в сети оператора связи, независимые от трафика пользователей. Как следствие, заказчик получает полный контроль над своей сетью и ее работой.

Теперь рассмотрим услугу предоставления доступа в Интернет. При использовании стандартных способов маршрутизации клиентского трафика, то есть с применением статической либо динамической (RIP или OSPF) маршрутизации, коммутаторы уровня 3 всегда «смотрят» на адрес назначения и маршрутизируют по самому короткому пути. Однако со временем и количество абонентов, и скорость предоставляемых тарифов повышается. В результате этого оператор связи сталкивается с проблемой «узкого» места, поскольку коммутатор направляет весь трафик по одному пути.

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

Таким образом, при грамотном планировании маршрутов и правил технология MPLS TE (Traffic Engineering) дает операторам связи гораздо более гибкий механизм контроля трафика по сравнению с существующими IP-сетями. Это обеспечивает повышенную гибкость, позволяющую лучше адаптироваться к растущим потребностям пользователей, а также более эффективную работу сетей и более предсказуемое качество услуг. Количество критериев, которые могут применяться в системах MPLS для классификации пакетов, невероятно широко. Скорее всего, в первых реализациях MPLS будет использоваться только часть этих критериев, а остальные будут подключаться к работе по мере необходимости.

Сети с коммутацией каналов, сети с коммутацией пакетов

Среди множества возможных подходов к решению задачи коммутации абонентов в сетях выделяют два основополагающих:

• коммутация каналов (circuit switching);

• коммутация пакетов (packet switching).

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

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

Рисунок 1 Инкапсуляция пакетных сервисов в SDH.

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

Особенности сети с коммутацией пакетов

При таких диаметральных подходах к способу обмена информацией, оба метода обладают рядом достоинств, и естественно рядом недостатков. Оба метода борются со своими недостатками, каждый своими, присущими ему методами. Рассмотрим для начала особенности пакетной коммутации на примере IP -сети.

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

Задачи, которые стояли перед пакетной (нашем случае - IP ) сетью были со временем успешно решены, но «за все приходится платить».

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

IP -сеть оперирует «пульсирующим» трафиком. Ее основное достоинство в том, что она умеет перераспределять ресурсы между различными сеансами связи. Но, у всего есть физический предел, и без потери пакетов в IP -сети не обходится. Потери пакетов происходят либо из-за переполнения буферов ожидания при больших всплесках трафика, при значениях нагрузки выше пиковой, либо при авариях на сети. Кроме того, IP -сеть не гарантирует того, что пакеты достигнут адресата назначения в том же порядке, в котором они вышли от источника.

Поиски решения проблем сетей передачи данных

В поисках решений, призванных минимизировать или исключить минусы пакетных сетей появились технологии X .25, а затем Frame Relay . Была разработана и долгое время применялась технология ATM . Они были призваны повысить надежность и скорость доставки пакетов в пакетных сетях. Совершенствовались механизмы QoS . Эти усовершенствования решили много проблем. С применением этих технологий качество передачи данных по пакетным сетям стало приемлимым для использования в телефонной связи, при передаче факсов и телекса, банковском секторе, электронной торговле и на транспорте.

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

Скорость реакции на событии, 100% гарантия доставки информационного сигнала - основные критерии для управляющих сигналов технологических процессов. В этих секторах традиционно используют сеть с коммутацией каналов на основе сети SDH .

Проблемы сетей с коммутацией каналов

Сеть SDH /SONET является классическим примером сети с коммутацией каналов. И все ее проблемы на сегодняшний день - это типовые проблемы, общие для всех сетей такого типа.

Список основных проблем для сетей такого типа состоит из трех пунктов.

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

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

Третье - низкая эффективность использования полосы пропускания физической линии связи. Ресурс полосы пропускания выделяется каналу передачи данных на все время его существования. То есть даже в те моменты, когда нет данных для передачи, ресурс сети «занят», закреплен за назначенным ему каналом.

Традиционные потребители SDH внесли некоторые организационные изменения, для минимизации влияния проблем сети. На этапе проектирования узлы и соединительные линии сети рассчитывались с избыточной мощностью, в перспективе хотя бы 3-5 лет. Таким образом избегали проблемы отказа в обслуживании. Как только с ростом нагрузки такой риск появлялся - сеть модернизировали. Все соединения, которые можно было установить заблаговременно, проключались, и оставались включенными в постоянном режиме, вне зависимости от того есть потребность в передаче данных или нет.

Сервис пакетных сетей инкапсулировали в потоки сети SDH , выделяя под пакетную передачу диапазоны от 64 кбит/с до нескольких потоков Е1.

Естественно, эффективность использования ресурса пропускной способности сети падала еще больше. Но, это была «плата за качество связи».

Развитие сервисов

С течением времени новые потребности в области передачи данных формировались в основном в технологиях с пакетной коммутацией. Голосовые и видео сервисы активно освоили пакетные сети, и добились высокого качества при достаточно скромных требованиях в полосе пропускания. Кодеки научились эффективно бороться с задержкой пакетов и джиттером. Бизнес-приложения, получившие широкое применение во всех отраслях промышленности, тоже ориентированы на использование сетей IP . IP - приложения быстро развиваются, и требуют все больше и больше ресурсов транспортной сети. Вслед за потребностями сервисов, пакетные сети перешли к применению высокопроизводительных магистральных линий связи, со скоростями nx 1G , 10G и 40G .Скорости SDH сетей остались на прежнем уровне.

Для предприятий потребителей сети SDH определилась проблема. В количественном отношении, объем информации передаваемый по IP -сетям намного превысил объем информации SDH . Магистральные каналы SDH -сетей стали уступать по производительности абонентским портам IP -сети. Стало физически невозможно пропустить весь пакетный трафик внутри SDH . Немаловажно, что цифровые каналы SDH -сети, при заказе у операторов связи, стоят заметно дороже IP -каналов, и поддерживать связность региональных SDH -сетей с производительными магистральными каналами становится все дороже.

Рисунок 2 Схема сети предприятия с раздельным обслуживанием сервисов.

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

Идея MPLS , наращиваем возможности

Предпосылками для создания такой сети явилась разработка компанией Cisco технологии CEF (Cisco Express Forwarding ) и, основанной на этой технологии, сети MPLS (Multi Protocol Label Switching ).

Сеть MPLS разрабатывалась для передачи различного вида трафика, включая IP -пакеты, ячейки ATM , фреймы SDH и кадры Ethernet . Сама технология MPLS преследует цель ускорить передачу пакетов через устройства маршрутизации. Для этого в рамках одного MPLS- домена, на основании информации протоколов маршрутизации, и таблиц FIB созданных CEF , MPLS формирует таблицу меток (LIB /LFIB ). Эта таблица заполняется для всех интерфейсов, на которых включен MPLS . Таблица LFIB содержит информацию о том, куда направить входящий трафик с каждого из подключенных интерфейсов, и какую операцию выполнить с заголовком меток. С этого момента все операции с пакетами производятся в соответствии с этими таблицами, на уровне коммутации. В прикладном смысле это в разы, а иногда и на порядки ускоряет прием, обработку и отправку пакетов. Теперь для обработки пакета не надо разбирать пакет, получать из него адреса назначения, искать информацию о маршрутах в таблицах маршрутизации. Все манипуляции с трафиком сводятся к тому, чтобы приняв пакет с одного интерфейса сразу отправить его в выходной интерфейс и изменить у него метку MPLS . Со всеми пакетами вошедшими в определенный интерфейс производится одно и то же действие. Эта модель очень напоминает проключение каналов в SDH .

Выделение MPLS -TP

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

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

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

В 2006 году компания Nortel предложила технологию PBB -TE , затем была предложена концепция T -MPLS . Эти технологии развивались разными институтами, T -MPLS поддерживалась ITU -T , а PBB -TE основывалась на стандартах IEEE . В 2009 году эти ветки объединились в одну концепцию MPLS -TP , за развитие архитектуры MPLS отвечает объединенная рабочая группа инженеров ITU -T и IETF В настоящее время MPLS -TP хорошо документирован, вышли документы RFC 5654 (Requrements of MPLS -TP ), 5921 (A Framework for MPLS in Transport Profile ), 5659 (Architecture for Multu -Segment Pseudowire Emulation Edge -2-Edge ), 5960 (MPLS -TP Data Plane Architecture ). Па рынке появился список вендоров, предлагающих законченные решения, основанные на технологии MPLS -TP . Линейки оборудования есть у Cisco , Olencom , xTran , Nateks и других производителей. На сегодняшний день технология полностью сформировалась, прошла проверку на большом количестве инсталлированных сетей в режиме реального производства.

Что добавил MPLS -TP

Основное отличие MPLS -TP от MPLS -сети является ее близость к SDH идеологии. Из маршрутной информации было исключено влияние динамических протоколов маршрутизации, автоматическое изменение таблиц маршрутизации в момент изменения структуры или состава сети.

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

MPLS -TP состоит из 3-х уровней логических соединений для организации пользовательского канала. Предполагается, что до начала программирования сервисов все приборы сети объединены между собой в некую топологию через высокоскоростные каналы Ethernet .

Первый логический уровень организации сервиса сети MPLS -TP - создание LSP (Label Switched Path ) маршрута коммутируемых меток. Это логическое соединение между двумя узлами сети MPLS -TP . LSP определяет метки и входные/выходные магистральные интерфейсы для доставки трафика от одного узла сети к другому.

Следующий уровень - уровень PW (pseudowire ). PW представляет собой логический канал передачи данных поддерживающий определенный тип абонентского сервиса. В зависимости от типа сервиса, PW содержит информацию о приоритетах трафика, требуемой пропускной способности канала. Через эти характеристики PW поддерживает требуемое качество сервиса, задает порядок и приоритет пропуска трафика через LSP и магистральные интерфейсы. Для получения маршрутной информации PW привязывается к LSP . На этом же уровне описывается метод резервирования пользовательского канала передачи данных.

И, наконец, уровень сервиса. На этом уровне определяется тип трафика и назначаются пользовательские интерфейсы. В соответствии с заявленными приоритетами выбирается PW ля транспортировки данных сервиса.

Для обеспечения управления, миллисекундной реакции на аварийные события все уровни организационной иерархии MPLS -TP контролируются протоколами BFD и OAM .

Рисунок 3. Логика организации сервисов в MPLS-TP.

В части управления и мониторинга системы управления MPLS -TP поддерживают аварийные события стандарта SDH в части организации канала, синхронизации и мониторинга состояний линков. Для управления пакетными каналами передачи поддерживаются события стандартов E 802.3ag , Y .1731. Достоинством NMS -систем сетей MPLS -TP является то, что они легко читаются и обслуживаются специалистами, подготовленными для сетей SDH .

Что можно поручить сети MPLS -TP

В итоге, с сетью MPLS -TP мы получили рабочую и проверенную технологию, которая может объединить сервисы пакетной и SDH сетей в одной инфраструктуре. Наработки, которые были реализованы в технологии MPLS -TP , предоставляют пользователям получить на пакетной сети каналы передачи данных по качеству не уступающие каналам SDH . При этом MPLS -TP сеть легко справляется с пиковыми нагрузками, оптимальным образом распределяет физические ресурсы сети между различными сервисами на основании назначенных приоритетов QoS . Умеет обслуживать большое количество сессий нерегулярного трафика, такого как видео, голос или прикладные сервисы (почта, ftp , торренты, задачи бэкапирования).

Основные характеристики сети MPLS-TP :

• Организация двунаправленных каналов по заданным пользователем маршрутам.
• Контроль за состоянием канала передачи данных на всех логических и физических уровнях с помощью протоколов BFD и OAM .
• Отсутствие неопределенностей, связанных с динамической маршрутизацией.
• Управление приоритетами трафика, минимизация очередей.
• Выделение полосы пропускания при организации канала, гарантированный ресурс полосы для всех сервисов.
• Резервирование маршрутов, сервисов и портов.
• Скорости восстановления трафика до 50 ms (требования SDH ).
• Высокоскоростные магистральные интерфейсы (Nx 1G , 10G , 40G ).
• Интерфейсы STM , совместимость с существующими сетями SDH .

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

Поскольку пакетная сеть может поддерживать любые топологии, а не только «кольцо», возможно проектировать сети с связанной и частично связанной топологией, что приводит к дополнительным ресурсам резервирования каналов передачи данных. Идеология управления сетью MPLS -TP легко понятна специалистам, подготовленным для работы с сетями SDH , это исключает необходимость в длительной переподготовке обслуживающего сеть персонала. Сеть MPLS -TP на уровне физических интерфейсов совместима с сетями IP /MPLS , а значит для присоединения сегментов сети предприятия, можно заказывать у операторов связи не дорогостоящие каналы цифровой иерархии, но обычные IP -подключения уровня L 2.

Основные выгоды от внедрения MPLS -TP

В результате внедрения на предприятии магистральной сети технологии MPLS -TP достигаются следующие цели:

• Вместо 2-х различных сетей для IP и SDH сервисов все потребности предприятия обслуживает 1 сеть.
• Повышается управляемость и надежность сети за счет применения новой топологии, расширенных механизмов управления и мониторинга.
• Снижение стоимости владения за счет оптимизации работы обслуживающего персонала сети.
• Снижение платежей за аренду выделенных каналов за счет использования каналов MPLS вместо TDM на магистральных участках сети.

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

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

Label - метка - значение от 0 до 1 048 575. На основе неё LSR принимает решение, что с пакетом делать: какую новую метку повешать, куда его передать.
Является частью заголовка MPLS.

Label Stack - стек меток. Каждый пакет может нести одну, две, три, да хоть 10 меток - одну над другой. Решение о том, что делать с пакетом принимается на основе верхней метки. Каждый слой играет какую-то свою роль.
Например, при передаче пакета используется транспортная метка, то есть метка, организующая транзит от первого до последнего маршрутизатора MPLS.
Другие могут нести информацию о том, что данный пакет принадлежит определённому VPN.
В этом выпуске метка всегда будет только одна - больше пока не нужно.

Push Label - операция добавления метки к пакету данных - совершается в самом начале - на первом маршрутизаторе в сети MPLS (в нашем примере - R1).

Swap Label - операция замены метки - происходит на промежуточных маршрутизаторах в сети MPLS - узел получает пакет с одной меткой, меняет её и отправляет с другой (R2, R5).

Pop Label - операция удаления метки - выполняется последним маршрутизатором - узел получает пакет MPLS и убирает верхнюю метку перед передачей его дальше (R6).

На самом деле метка может добавляться и удаляться где угодно внутри сети MPLS.
Всё зависит от конкретных сервисов. Правильнее будет сказать, что метка добавляется первым маршрутизатором пути (LSP), а удаляется последним.
Но в этой статье для простоты мы будем говорить о границах сети MPLS.
Кроме того, удаление верхней метки ещё не означает, что остался чистый IP-пакет, если речь идёт о стеке меток. То есть если над пакетом с тремя метками совершили операцию Pop Label, то меток осталось две и дальше он по-прежнему обрабатывается, как MPLS. А в нашем примере была одна, а после не останется ни одной - и это уже дело IP.

LSR - Label Switch Router - это любой маршрутизатор в сети MPLS. Называется он так, потому что выполняет какие-то операции с метками. В нашем примере это все узлы: R1, R2, R3, R4, R5, R6.
LSR делится на 3 типа:
Intermediate LSR - промежуточный маршрутизатор MPLS - он выполняет операцию Swap Label (R2, R5).
Ingress LSR - «входной», первый маршрутизатор MPLS - он выполняет операцию Push Label (R1).
Egress LSR - «выходной», последний маршрутизатор MPLS - он выполняет операцию Pop Label (R6).
LER - Label Edge Router - это маршрутизатор на границе сети MPLS.
В частности Ingress LSR и Egress LSR являются граничными, а значит они тоже LER.

LSP - Label Switched Path - путь переключения меток. Это однонаправленный канал от Ingress LSR до Egress LSR, то есть путь, по которому фактически пройдёт пакет через MPLS-сеть. Иными словами - это последовательность LSR.
Важно понимать, что LSP на самом деле однонаправленный. Это означает, что, во-первых, трафик по нему передаётся только в одном направлении, во-вторых, если существует «туда», не обязательно существует «обратно», в-третьих, «обратно» не обязательно идёт по тому же пути, что «туда». Ну, это как туннельные интерфейсы в GRE.

Как выглядит LSP?

Да, вот так непрезентабельно.
Это компилированный вывод с четырёх LSR - R1, R2, R5, R6. То есть на LSR вы не увидите законченной последовательности узлов от входа до выхода, по типу атрибута AS-PATH в BGP. Здесь каждый узел знает только входную и выходную метки. Но LSP при этом существует.

Это похоже немного на IP-маршрутизацию. Несмотря на то, что существует путь от точки А до точки Б, таблица маршрутизации знает только следующий узел, куда надо отправлять трафик. Но разница в том, что LSR не принимает решение о каждом пакете на основе адреса назначения - путь определён заранее.

И одно из самых важный понятий, с которым необходимо разобраться - FEC - Forwarding Equivalence Class . Мне оно почему-то давалось очень тяжело, хотя по сути - всё просто. FEC - это классы трафика. В простейшем случае идентификатором класса является адресный префикс назначения (грубо говоря, IP-адрес или подсеть назначения).
Например, есть потоки трафика от разных клиентов и разных приложений, которые идут все на один адрес - все эти потоки принадлежат одному классу - одному FEC - используют один LSP.
Если мы возьмём другие потоки от других клиентов и приложений на другой адрес назначения - это будет соответственно другой класс и другой LSP.

В теории помимо адреса назначения FEC может учитывать, например, метки QoS, адрес источника, идентификатор VPN или тип приложений. Важно понимать тут, что пакеты одного FEC не обязаны следовать на один и тот же адрес назначения. И в то же время, если даже и два пакета следуют в одно место, не обязательно они будут принадлежать одному FEC.

Я поясню для чего всё это нужно. Дело в том, что для каждого FEC выбирается свой LSP - свой путь через сеть MPLS. И тогда, например, для WEB-сёрфинга вы устанавливаете приоритет QoS - это будет один FEC - а для VoIP - - другой FEC. И далее можно указать, что для FEC BE LSP должен идти широким, но долгим и негарантированным путём, а для FEC EF - можно узким, но быстрым.

К сожалению или к счастью, но сейчас в качестве FEC может выступать только IP-префикс. Такие вещи, как маркировка QoS не рассматриваются.

Если вы обратите внимание на таблицу меток, FEC там присутствует, поскольку параметры замены меток определяются как раз таки на основе FEC, но делается это только в первый момент времени - когда эти метки распределяются. Когда же по LSP бежит реальный трафик, никто, кроме Ingress LSR, уже не смотрит на него - только метки и интерфейсы. Всю работу по определению FEC и в какой LSP отправить трафик берёт на себя Ingress LSR - получив чистый пакет, он его анализирует, проверяет какому классу тот принадлежит и навешивает соответствующую метку. Пакеты разных FEC получат разные метки и будут отправлены в соответствующие интерфейсы.
Пакеты одного FEC получают одинаковые метки.

То есть промежуточные LSR - это молотилки, которые для всего транзитного трафика только и делают, что переключают метки. А всю интеллектуальную работу выполняют Ingress LSR.

LIB - Label Information Base - таблица меток. Аналог таблицы маршрутизации (RIB) в IP. В ней указано для каждой входной метки, что делать с пакетом - поменять метку или снять её и в какой интерфейс отправить.
LFIB - Label Forwarding Information Base - по аналогии с FIB - это база меток, к которой обращается сетевой процессор. При получении нового пакета нет нужды обращаться к CPU и делать lookup в таблицу меток - всё уже под рукой.

Одна из первоначальных идей MPLS - максимально разнести Control Plane и Data Plane - ушла в небытие.
Разработчикам хотелось, чтобы при передаче пакета через маршрутизатор не было никакого анализа - просто прочитал метку, поменял на другую, передал в нужный интерфейс.
Чтобы добиться этого, как раз и было два разнесённых процесса - относительно долгое построение пути (Control Plane) и быстрая передача по этому пути трафика (Data Plane)

Но с появлением дешёвых чипов (ASIC, FPGA) и механизма FIB обычная IP-передача тоже стала быстрой и простой.
Для маршрутизатора без разницы, куда смотреть при передаче пакета - в FIB или в LFIB.
А вот что, несомненно, важно и полезно - так это, что безразличие MPLS к тому, что передаётся под его заголовком - IP, Ethernet, ATM. Не нужно городить GRE или какие-то другие до боли в суставах неудобные VPN. Но об этом ещё поговорим.

Заголовок MPLS

Весь заголовок MPLS - это 32 бита. Формат полей и их длина фиксированы. Часто весь заголовок называют меткой, хотя это не совсем и верно.

Label - собственно сама метка. Длина - 20 бит.
TC - Traffic Class. Несёт в себе приоритет пакета, как поле DSCP в IP.
Длина 3 бита. То есть может кодировать 8 различных значений.
Например, при передаче IP-пакета через сеть MPLS значению в поле DSCP определённым образом ставится в соответствие значение TC. Таким образом пакет может почти одинаково обрабатываться в очередях на всём протяжении своего пути, как на участке чистого IP, так и в MPLS.
Но, естественно, это преобразование с потерями - шести битам DSCP тесно в 3 битах TC: 64 против 8. Поэтому существует специальная таблица соответствий, где целый диапазон - это всего лишь одно значение.

Первоначально поле носило название EXP (экспериментальное), а его содержимое не было регламентировано. Предполагалось, что оно может быть использовано для исследований, внедрения нового функционала. Но это в прошлом.
Если кто-то с вами спорит, что это поле экспериментальное и не утверждено формально за функцией QoS - он не шарит порядочно отстал от жизни .

В сети настроена простая политика QoS, в которой IP-пакеты, которые идут с хоста 10.0.17.7 на адрес 6.6.6.6, маркируются и передаются по сети MPLS. Для маркировки пакетов используется поле EXP, значение поля 3.

Схема

На маршрутизаторе R6 настроена политика QoS, которая классифицирует пакеты по полю EXP.
Но, при проверке оказалось, что политика на R6 не отрабатывает. То есть, нет пакетов, приходящих со значением EXP 3 и все пакеты попадают в class default.

Задание: Исправить конфигурацию так, чтобы политика на R6 срабатывала.

Маршрутизатор R7 используется в качестве клиента. Соответственно MPLS между R7 и R1 не включен.

Подробности задачи и конфигурации .
=====================

S - Bottom of Stack - индикатор дна стека меток длиной в 1 бит. Заголовков MPLS на пакете может быть несколько, например, внешняя для коммутации в сети MPLS, а внутренняя указывает на определённый VPN. Чтобы LSR понимал с чем он имеет дело. В бит S записывается «1», если это последняя метка (достигнуто дно стека) и «0», если стек содержит больше одной метки (ещё не дно). То есть LSR не знает, сколько всего меток в стеке, но знает, одна она или больше - да этого и достаточно на самом-то деле. Ведь любые решения принимаются на основе только самой верхней метки, независимо от того, что там под ней. Зато, снимая метку, он уже знает, что дальше сделать с пакетом: продолжить работу с процессом MPLS или отдать его какому-то другому (IP, Ethernet, ATM, FR итд).

Вот к этой фразе: “Зато, снимая метку, он уже знает, что дальше сделать с пакетом” - надо дать пояснение. В заголовке MPLS, как вы заметили, нет информации о содержимом (как Ethertype в Ethernet’е или Protocol в IP).
Это с одной стороны хорошо - внутри может быть что угодно - выше гибкость, а с другой стороны, как без анализа содержимого теперь определить, какому процессу передавать всё это хозяйство?
А тут небольшая хитрость - маршрутизатор, как вы увидите дальше, всегда сам выделяет метку и передаёт её своим соседям, поэтому он знает, для чего её выделял - для IP или для Ethernet или ещё для чего-то. Поэтому он просто добавляет эту информацию в свою таблицу меток. И в следующий раз, когда делает операцию Pop Label, он уже из таблицы (а не из пакета) знает, что дальше делать.

В общем, стек тут в классическом понимании - последним положили, первым взяли (LIFO - Last Input - First Output).

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

TTL - Time To Live - полный аналог IP TTL . Даже той же самой длиной обладает - 8 бит. Единственная задача - не допустить бесконечного блуждания пакета по сети в случае петли. При передаче IP-пакета через сеть MPLS значение IP TTL может быть скопировано в MPLS TTL, а потом обратно. Либо отсчёт начнётся опять с 255, а при выходе в чистую сеть IP значение IP TTL будет таким же, как до входа.

Как видите, заголовок MPLS втискивается между канальным уровнем и теми данными, которые он несёт - в случае IP - сетевым. Поэтому метафорически MPLS называется технологией 2,5 уровня, а заголовок - Shim-header - заголовок-клин.
К слову, метка не обязательно должна быть в заголовке MPLS. Согласно решению IETF, она может встраиваться в заголовки ATM, AAL5, Frame Relay.

Вот как оно выглядит в жизни:

Пространство меток

Как уже было сказано выше, может существовать 2^20 меток.

Из них несколько зарезервировано:

0 : IPv4 Explicit NULL Label . «Явная пустая метка». Она используется на самом последнем пролёте MPLS - перед Egress LSR - для того, чтобы уведомить его, что эту метку 0 можно снять, не просматривая таблицу меток (точнее LFIB).
Для тех FEC, что зарождаются локально (directly connected) Egress LSR выделяет метку 0 и передаёт своим соседям - предпоследним LSR (Penultimate LSR).
При передаче пакета данных предпоследний LSR меняет текущую метку на 0.
Когда Egress LSR получает пакет, он точно знает, что верхнюю метку нужно просто удалить.

Так было не всегда. Изначально предлагалось, что метка 0 может быть только на дне стека меток и при получении пакета с такой меткой, LSR должен вообще очистить упоминания об MPLS и начать обрабатывать данные.
В какой-то момент теоретики под давлением практиков согласились, что это нерационально и реального применения им придумать не удалось, поэтому отказались от обоих условий.
Так что теперь метка 0 не обязательно последняя (нижняя) и при операции Pop Label удаляется только она, а нижние остаются и пакет дальше обрабатывается в соответствии с новой верхней меткой.

1 : Метка Router Alert Label - аналог опции Router Alert в IP - может быть где угодно, кроме дна стека. Когда пакет приходит с такой меткой, он должен быть передан локальному модулю, а дальше он коммутируется в соответствии с меткой, которая была ниже - реальной транспортной, при этом наверх стека снова должна быть добавлена метка 1.

2 : IPv6 Explicit NULL Label - то же, что и 0, только с поправкой на версию протокола IP.

3 : Implicit Null . Фиктивная метка, которая используется для оптимизации процесса передачи пакета MPLS на Egress LSR. Эта метка может анонсироваться, но никогда не используется в заголовке MPLS реально. Рассмотрим её попозже.

4-15 : Зарезервированы.

В зависимости от вендора, могут быть зафиксированы и другие значения меток, например, на оборудовании Huawei метки 16-1023 используются для статических LSP, а всё, что выше - в динамических. В Cisco доступные метки начинаются уже с 16-й.

На следующей схеме все маршрутизаторы, кроме R5, это маршрутизаторы Huawei. R5 - Cisco.

Схема

Для приведенной ниже конфигурации маршрутизатора R5, необходимо настроить его таким образом, чтобы распределение значений меток соответствовало Huawei. Речь о том, что в Huawei динамические метки начинаются с 1024, а в Cisco с 16.

Конфигурация R5

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

Второй режим - DoD - Downstream-on-Demand . LSR знает FEC, у него есть соседи, но пока они не спросят, какая для данного FEC метка, LSR сохраняет молчание.

Этот способ удобен, когда к LSP предъявляются какие-то требования, например, по ширине полосы. Зачем слать метку просто так, если она тут же будет отброшена? Лучше вышестоящий LSR запросит у нижестоящего: мне нужна от тебя метка для данного FEC - а тот: «ок, на».

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

Ordered Control против Independent Control

Во-вторых , LSR может дожидаться, когда со стороны Egress LER придёт метка данного FEC, прежде чем рассказывать вышестоящим соседям. А может разослать метки для FEC, как только узнал о нём.

Первый режим называется Ordered Control

Гарантирует, что к моменту передачи данных весь путь вплоть до выходного LER будет построен.

Второй режим - Independent Control .

То есть метки передаются неупорядоченно. Удобен тем, что трафик можно начинать передавать ещё до того, как весь путь построен. Этим же и опасен.

Liberal Label Retention Mode против Conservative Label Retention Mode

В-третьих , важно, как LSR обращается с переданными ему метками.
Например, в такой ситуации, должен ли R1 хранить хранить информацию о метке 20, полученной от соседа R3, который не является лучшим способом добраться до R6?

А это определяется режимом удержания меток.
Liberal Label Retention Mode - метки сохраняются. В случае, когда R3 станет следующим шагом (например, проблемы с основным путём), трафик будет перенаправлен скорее, потому что метка уже есть. То есть скорость реакции выше, но велико и количество использованных меток.
Conservative Label Retention Mode - лишняя метка отбрасывается сразу, как она получена. Это позволяет сократить количество используемых меток, но и MPLS среагирует медленнее в случае аварии.

PHP

Нет, это не тот PHP, о котором вы подумали. Речь о Penultimate Hop Popping . Все инженеры немного оптимизаторы, вот и тут ребята подумали: а зачем нам два раза обрабатывать заголовки MPLS - сначала на предпоследнем маршрутизаторе, потом ещё на выходном.
И решили они, что метку нужно снимать на предпоследнем LSR и назвали сие действо - PHP.
Для PHP существует специальная метка - 3.
Возвращаясь к нашему примеру, для FEC 6.6.6.6 и 172.16.0.2 R6 выделяет метку 3 и сообщает её R5.
При передаче пакета на R6 R5 должен назначить ему фиктивную метку - 3, но фактически она не применяется и в интерфейс отправляется голый IP-пакет (стоит заметить, что PHP работает только в сетях IP) - то есть процедура Pop Label была выполнена ещё на R5.

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

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

Протоколы распространения меток

Их не так много - три: LDP, RSVP-TE, MBGP.
Есть две глобальные цели - распространение траспортных меток и распространение меток сервисных.
Поясним: транспортные метки используются для передачи трафика по сети MPLS. Это как раз те, о которых мы говорим весь выпуск. Для них используются LDP и RSVP-TE.

Сервисные метки служат для разделения различных сервисов. Тут на арену выходят MBGP и отросток LDP - tLDP .
В частности MBGP позволяет, например, пометить, что вот такой-то маршрут принадлежит такому-то VPN. Потом он этот маршрут передаёт, как vpn-ipv4 family своему соседу с меткой, чтобы тот смог потом отделить мух от котлет.
Так вот, чтобы он мог отделить, ему и нужно сообщить о соответствии метка-FEC.
Но это действие другой пьесы, которую мы сыграем ещё через полгода-год.

Обязательным условием работы всех протоколов динамического распределения меток является базовая настройка IP-связности. То есть на сети должны быть запущены IGP.

Ну, вот теперь, когда я вас окончательно запутал, можно начинать распутывать.
Итак, как проще всего распределить метки? Ответ - включить LDP.

LDP

Протокол с очень прозрачным названием - Labed Distribution Protocol - имеет соответствующий принцип работы.
Рассмотрим его на сети linkmeup, которую мы мурыжим весь выпуск:

1. После включения LDP LSR делает мультикастовую рассылку UDP-дейтаграмм во все интерфейсы на адрес 224.0.0.2 и порт 646, где активирован LDP - так происходит поиск соседей.
TTL таких пакетов равен 1, поскольку LDP-соседство устанавливается между непосредственно подключенными узлами.

Вообще говоря, это не всегда так - LDP сессия может устанавливаться для определённых целей и с удалённым узлом, тогда это называется tLDP - Targeted LDP . О нём мы поговорим в других выпусках.

Такие сообщения называются Hello .

2. Когда соседи обнаружены, устанавливается TCP соединение с ними, тоже по порту 646 - Initialization . Дальнейшие сообщения (кроме Hello) передаются уже с TTL равным 255.

3. Теперь LSR периодически обмениваются сообщениями Keepalive адресно по TCP и по-прежнему не оставляют попыток найти соседей с помощью Hello.

4. В какой-то момент один из LSR обнаруживает в себе вторую личность - Egress LSR - то есть он является выходным для какого-то FEC. Это факт, о котором нужно сообщить миру.
В зависимости от режима он ждёт запроса на метку для данного FEC, либо рассылает его сразу же.

Эта информация передаётся в сообщении Label Mapping Message . Исходя из названия, оно несёт в себе соответствие FEC и метки.

R5 получает информацию о соответствии FEC 6.6.6.6/32 и метки 3 (implicit null) и записывает её в свою таблицу меток. Теперь, когда ему нужно будет отправить данные на 6.6.6.6 он будет знать, что нужно удалить верхний заголовок MPLS и отправить оставшийся пакет в интерфейс FE1/0.

Теперь R5 знает, что если пришёл пакет MPLS с меткой 20, его нужно передать в интерфейс FE1/0, сняв метку, то есть выполнив процедуру PHP.

R2 получает от R5 информацию о соответствии FEC-метка (6.6.6.6 - 20), вносит её в таблицу и, создав свою входную метку (18), передаёт её ещё выше. И так далее, пока все LSR не получат свою выходную метку.

Таким образом у нас построен LSP от R1 до R6. R1 при отправке пакета на 6.6.6.6/32 добавляет к нему метку 18 (Push Label) и посылает его в порт FE0/0. R2, получив пакет с меткой 18, меняет метку на 20 (Swap Label) и отправляет его в порт FE0/0. R5 видит, что для пакета с меткой 20, надо выполнить PHP (выходная метка - 3 - implicit null), снимает метку (Pop Label) и отправляет данные в порт FE1/0.

При этом параллельно оказались построены LSP от R2 до R6, от R5 до R6, от R4 до R6 итд. То есть ото всех LSR - просто я не показал это на иллюстрации.

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

Естественно, вы понимаете, что не только R6 вдруг начал рассылать свои соответствия FEC-метка, но и все другие - R1 про 1.1.1.1/32, R2 - 2.2.2.2/32 итд. Все эти сообщения молниеносно разносятся по сети MPLS, строя десятки LSP. В результате каждый LSR будет знать про все существующие FEC и будет построен соответствующий LSP.

Опять же на гифке выше процесс показан не до конца, R1 потом передаёт информацию на R3, R3 на R4, R4 на R5.
И если мы посмотрим на R5, то увидим, что для FEC 6.6.6.6/32 у нас не одна выходная метка, как ожидалось, а 3:

Более того, сам R6 запишет метку для FEC 6.6.6.6, которую получит от R5:

Inuse - правильная - imp-null в сторону R6. Но две других из кольца - от R2 и R4. Это не ошибка и не петля - просто R2 и R4 сгенерировали эти метки для известного им из таблицы маршрутизации FEC 6.6.6.6/32.

Возникает два вопроса:
1) Как он планирует ими воспользоваться? Они же бестолковые. Ответ: а никак. Не может быть в нашей сети такой ситуации, когда 2.2.2.2 или 4.4.4.4 будут следующими узлами на пути к 6.6.6.6 - IGP так маршрут не построит. А значит и использованы метки не будут. Просто LDP-то глупый - его сообщения разбредаются по всей сети, пробиваясь в каждую щёлочку. А умный LSR уже решит каким пользоваться.
2) Что насчёт петель? Не будут сообщения LDP курсировать по сети пока TTL не истечёт?
А тут всё просто - получение нового сообщения Label Mapping Message не инициирует создание нового - полученное соответствие просто записывается в таблицу LDP. То есть в нашем случае R5 уже придумал один раз метку для FEC 6.6.6.6/32 и разослал её своим вышестоящим соседям и она уже не поменяется, пока процесс LDP не перезагрузится.

Возможно, вы уже заметили, что при настройке LDP есть возможность включить функционал Loop Detection, но спешу вас успокоить - это для сетей, где нет TTL, например, ATM. Этот функционал переключит LDP в режим DoD.

Это базовая информация о том, как работает LDP.
На самом деле здесь всё очень сильно зависит от производителя. В принципе LDP поддерживает всевозможные режимы работы с метками: и DoD/DU, и Independent Control/Ordered Control, и Conservative/Liberal Label Retention. Это никак не регламентируется RFC, поэтому каждый вендор волен выбирать свой путь.
Например, в основном все используют DU для LDP, но при этом в Juniper метки раздаются упорядоченно, а в Cisco независимо.
В качестве FEC в Huawei и Juniper выбираются только Loopback-интерфейсы LSR, а Cisco FEC создаётся для всех записей в таблице маршрутизации.

Но это всё едва ли как-то отразится на реальной сети.

Самое важное, что нужно понимать относительно LDP - он не использует в своей работе протоколы динамической маршрутизации - по принципу работы он похож на : наводняет всю сеть метками, но при этом он опирается на информацию из таблицы маршрутизации LSR. И если на R1 придёт две метки для одного FEC от разных соседей, то он выберет для LSP только ту, которая получена через лучший интерфейс до этого FEC по информации из ТМ.
Это означает три вещи:

• Вы вольны выбирать IGP, который вам больше нравится, хоть RIP .
• LDP всегда строит только один (лучший) маршрут и не может построить, например, резервный.
• При изменении топологии сети LSP перестроится в соответствии с обновившейся таблицей маршрутизации, то есть сначала должен сойтись IGP, и только потом поднимется LSP.

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

Для включения MPLS глобально, необходимо дать две команды:
R1(config)#ip cef R1(config)#mpls ip
Первая - это уже стандарт де факто и де юре почти на любом сетевом оборудовании - она запускает механизм CEF на маршрутизаторе, вторая стартует MPLS и LDP глобально (тоже может быть дана по умолчанию).

Router ID (а в более общей (нецисковской) терминологии LSR ID) в MPLS выбирается незамысловато:

1. Самый большой адрес Loopback-интерфейсов
2. Если их нет - самый большой IP-адрес, настроенный на маршрутизаторе.

Естественно, не стоит доверять автоматике - настроим LSR ID вручную:
R1(config)# mpls ldp router-id Loopback0 force
Если не добавлять ключевое слово «force» , Router ID изменится только при переустановлении LDP-сессии. «Force» заставляет маршрутизатор сменить Router ID насильно и при необходимости (если тот поменялся) переустанавливает соединение LDP.

Далее на нужных интерфейсах даём команду mpls ip :
R1(config)#interface FastEthernet 0/0 R1(config-if)#mpls ip R1(config)#interface FastEthernet 0/1 R1(config-if)#mpls ip
Cisco здесь опять использует свой принцип ленивого инженера - минимум усилий со стороны персонала. Команда mpls ip включает на интерфейсе LDP одновременно с MPLS, желаем мы этого или нет. Точно так же команда ip pim sparse-mode включает IGMP на интерфейсе, как я описывал это в статье про мультикаст .
После активации LDP маршрутизатор начинает прощупывать почву по UDP:

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

Теперь повторяем все те же манипуляции на R2
R2(config)#ip cef R2(config)#mpls ip R2(config)# mpls ldp router-id Loopback0 force R2(config)#interface FastEthernet 0/0 R2(config-if)#mpls ip R2(config)#interface FastEthernet 0/1 R2(config-if)#mpls ip
и наслаждаемся результатом.
R2 тоже ищет соседей.

Узнали друг про друга, и R2 поднимает LDP-сессию:

Если интересно, как они устанавливают TCP-соединение

Теперь они соседи, что легко проверяется командой show mpls ldp neighbor .

Вот тут уже видно детали - R1 передаёт сразу 12 FEC - по одной для каждой записи в своей таблице маршрутизации. В такой же ситуации Huawei или Juniper передали бы только шесть FEC - адреса Loopback-интерфейсов, потому что они по умолчанию считают за FEC только /32-префиксы.
В этом плане Cisco очень неэкономно относится к ресурсу меток.
Впрочем, это поведение можно изменить на любом оборудовании. В нашем случае может помочь команда mpls ldp advertise-labels .

Но как так, спросите вы? Разве достаточно иметь метки только в Loopback?

Если в Cisco по умолчанию анонсируются метки для всех сетей (кроме полученных по BGP), то в Juniper, по умолчанию анонсируется только loopback.

Схема

Все маршрутизаторы, кроме R5, это маршрутизаторы Juniper.

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

Конфигурация R5

ip cef ! interface Loopback0 ip address 5.5.5.5 255.255.255.255 ip router isis ! interface FastEthernet0/0 description to R4 ip address 10.0.45.5 255.255.255.0 ip router isis mpls ip ! interface FastEthernet0/1 description to R2 ip address 10.0.25.5 255.255.255.0 ip router isis mpls ip ! interface FastEthernet1/0 description to R6 ip address 10.0.56.5 255.255.255.0 ip router isis mpls ip ! router isis net 10.0000.0000.0005.00 ! mpls ldp router-id Loopback0 force

И после этого посмотрим повторно на таблицу коммутации MPLS на R1 :

Для всех FEC уже появились метки.
Давайте пройдёмся по LSP от R1 до R6 и посмотрим как меняются метки по пути

Значит
1. Когда R1 21 Fa0/0 и поменять метку на 18 .
2. Когда R2 получает пакет MPLS с меткой 18 , он должен передать его в интерфейс Fa0/0 и поменять метку на 20 .
3. Когда R5 получает пакет MPLS с меткой 20 , он должен передать его в интерфейс Fa1/0 и снять метку - PHP .

В этом случае LSR даже не задумываются о том, чтобы глянуть что-то в таблице маршрутизации или в ip cef - они просто жонглируют метками.

Таблица коммутации, которую мы уже смотрели командой show mpls forwarding table - это LFIB (Lable Forwarding Information Base ) - почти что прописная истина для передачи данных - это Data Plane. Но что же там с Control Plane? Вряд ли LDP знает столько же? Наверняка у него ещё есть козыри в рукаве?
Так и есть:

Для каждого FEC мы тут видим информацию о различных метках:
local binding - что этот LSR передаёт соседям
remote binding - что этот LSR получил от соседей.

На иллюстрации выше вы можете видеть слово «tib». TIB - это Tag Information Base , которая правильно называется Label Information Base - LIB.
Это пережиток почившего в бозе TDP - прародителя LDP.

Обратите внимание, что везде по 2 remote binding - это два пути получения меток. Например, до R2 можно добрать от R1 напрямую, а можно через R3-R4-R5-R2.
То есть, понимаете да? Мало того, что он из каждой записи в таблице маршрутизации делает FEC, так этот негодяй ещё и Liberal Retention Mode использует для удержания меток.
Давайте подытожим: по умолчанию LDP в Cisco работает в следующих режимах:

• Independent Control
• Liberal Retention Mode
• В качестве FEC выбираются все записи в таблице маршрутизации

Короче говоря, щедроты его не знают границ.

Есть ещё команда show mpls ip binding . Она показывает нечто похожее и позволяет кроме того быстро узнать, какой путь сейчас активен, то есть как построен LSP:

И последний, пожалуй, вопрос, который возникает в связи со всеми этими LSP - когда маршрутизатор сам является Ingress LSR, как он понимает, что нужно делать с пакетами, как выбрать LSP?
А для этого вот и придётся заглянуть в IP CEF. Вообще именно на Ingress LSR ложится всё бремя обработки пакета, определения FEC и назначения правильных меток.

Тут вам и Next Hop и выходной интерфейс и выходная метка

И тут уже вы должны заметить, что в LDP понятия LER, Ingress LSR, Egress LSR - это не роль каких-то конкретных узлов или характеристика местоположения узла в сети. Они неотделимы от FEC и LSP, индивидуальны для них. То есть для каждого конкретного FEC есть один или несколько Egress LSR и множество Ingress LSR (как правило, все маршрутизаторы), до которых ведут LSP.
Даже скажем так, понятия LER возникают когда мы говорим о конкретном LSP, тогда мы можем сказать, кто является Ingress, кто Egress.

MPLS и BGP

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

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

Главное отличие BGP от IGP заключается в том, что MPLS не создает метки для маршрутов BGP. Если вспомнить о том, какое количество маршрутов передает BGP, то становится понятно, что это очень хорошая идея. Как же тогда состыковать MPLS и BGP?
Все просто:

1. создаем метки только для адресов, которые будут указаны как next-hop для маршрутов, которые мы получаем по BGP (тут надо не забыть про next-hop-self для IBGP-соседей).
2. Когда нашему Ingress LSR понадобится передать пакеты по маршруту, который был получен по BGP, отправляем их к next-hop, который указан в маршруте и используем ту метку, которая была создана для него.

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

Посмотрим на примере сети:

Если нам надо добраться с R1 до сетей Филькин Сертификат, мы смотрим, что они доступны через R6 и «пролетаем» через MPLS до адреса 6.6.6.6. А когда мы добираемся до R6, он уже знает куда идти дальше. Аналогично будет и наоборот, в Балаган-Телеком.

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

В сети настроены MPLS и OSPF. MPLS настроен во всей сети, кроме соединения между R7 и R1.
Между маршрутизаторами R1-R2-R3-R4-R5-R6 трафик должен передаваться силами MPLS.
В сети также настроен BGP, который работает между R1 и R6.

Для маршрутов BGP не генерируются метки.
Для того чтобы R1 мог добраться до маршрутов, которые получены по BGP от R6, пакеты передаются средствами MPLS до IP-адреса, который указан как next-hop в маршрутах BGP.

Сейчас с R7 недоступен маршрут, который анонсируется по BGP маршрутизатором R6.

Задание:
Восстановить работу сети, чтобы с R7 пинговался адрес 100.0.0.1.

Ограничения:
Нельзя менять настройки BGP.

Схема

Подробности задачи и конфигурации узлов .
=====================

RSVP-TE

LDP хорош. Работает он просто и понятно. Но есть такая технология, как MPLS TE - Traffic Engineering. И ей недостаточно лучшего маршрута, который может обеспечить LDP.
Управление трафиком подразумевает, что вы можете направить трафик между узлами как вам угодно, учитывая различные ограничения.
Например, в нашей сети клиент имеет две точки подключения своих узлов - на R1 и на R6. И между ними он просит предоставить ему VPN с гарантированной шириной канала в 100 Мб/с. Но при этом у нас в сети ещё и обычные ШПДшники видео гоняют с вконтактика и дюжина других клиентов, которые VPN арендуют, но полосу им резервировать не надо.
Если не вмешаться в эту ситуацию, где-нибудь на R2 может возникнуть перегруз, и 100 Мб/с для дорогого клиента не достанется.

MPLS TE позволяет пройти по всей сети от отправителя до получателя и зарезервировать ресурсы на каждом узле. Если вы знакомы с концепцией IntServ, то да, это именно она - организовать QoS на всём протяжении пути, вместо того, чтобы позволить каждому маршрутизатору самому принимать решение для проходящего пакета.
Собственно, протокол RSVP (Resource ReSerVation Protocol ) изначально (в 1993-м году) и был задуман для организации IntServ в IP-сетях. Он должен был донести информацию о QoS для какого-то конкретного потока данных до каждого узла и заставить его зарезервировать ресурсы.

В первом приближении работает он просто.

1) Узел-источник хочет отправить поток данных со скоростью 5 Мб/с. Но перед этим он посылает RSVP запрос на резервирование полосы до получателя - Path Message . Это сообщение содержит некие идентификаторы потока, по которым узел потом сможет идентифицировать принадлежность полученных IP-пакетов потоку, и требуемую ширину полосы.
2) Сообщение Path передаётся от узла к узлу до самого получателя. Куда его послать, определяется на основе таблицы маршрутизации.
3) Каждый маршрутизатор, получив Path, проверяет свои ресурсы. Если у него есть достаточно свободной полосы, он настраивает свои внутренние алгоритмы так, чтобы пакеты потока были обработаны как следует и пропускной способности всегда хватало.
4) Если же у него нет необходимых 5 Мб/с (занято другими потоками), он отказывает в выделении ресурсов и возвращает соответствующее сообщение отправителю.
5) Пакет Path доходит до получателя потока, тот отправляет назад сообщение Resv , подтверждая выделение ресурсов на всём протяжении пути.
6) Изначальный отправитель, получив Resv, понимает, что всё для него готово, и он может отправлять данные.

На самом деле под этими четырьмя простыми шагами лежат гораздо более сложные процессы, но нам это не интересно.

А вот что нам интересно - так это расширение RSVP для Traffic Engineering , или проще - RSVP TE , которое было разработано специально для MPLS TE.
Его задача такая же, как у LDP - распределить метки между LSR и скомпилировать в итоге LSP от получателя до отправителя. Но теперь, как вы уже поняли, появляются нюансы - LSP должен удовлетворять определённым условиям.

RSVP TE позволяет строить основной и запасной LSP, резервировать ресурсы на всех узлах, обнаруживать аварии на сети, строить заранее обходные пути, делать быстрое перенаправление трафика, избегать каналов, которые физически проходят по одному пути.
Но всё это мы будем обсуждать в статье о MPLS TE через пару выпусков. А сегодня же мы сосредоточимся на принципах, согласно которым RSVP TE строит LSP.

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

Для начала мы отбросим функционал резервирования ресурсов - пусть наша задача только создать LSP, то есть распределить метки между LSR.

Чтобы это стало возможно, стандартный RSVP расширяется добавлением нескольких объектов. Рассмотрим простейший вариант.
0) R1 нужен LSP до FEC 6.6.6.6/32. Это выглядит как интерфейс Tunnel на R1, у которого адрес назначений 6.6.6.6 и тип Traffic Engineering.
1) Он посылает сообщение RSVP Path в направлении 6.6.6.6. В этом сообщении появляется новый объект - Label Request . Сообщение Path провоцирует узел выделить метку для данного FEC - то есть это запрос метки.
2) Следующий узел формирует новое сообщение Path и также отправляет его в сторону 6.6.6.6. Итд.
3) Path достигает Egress LSR. Тот видит, что пакет-то ему адресован, выделяет метку и отправляет источнику сообщение Resv. В последнем тоже добавлен новый объект - Label . В нём Egress LSR передаёт свою метку для этого FEC предпоследнему, предпоследний предпредпоследнему свою итд.
4) Resv достигает источника, распределяя по пути метки. Таким образом создан LSP, а источник уведомлён, что всё готово.

Метки запрашиваются вниз по течению (сообщение Path от отправителя к получателю), а передаются вверх по течению (сообщение Resv от получателя к отправителю).
При этом обратите ваше внимание на то, что это уже самый что ни на есть Downstream on Demand + Ordered Control. Path выступает запросом метки, а Resv идёт от получателя шаг за шагом и, пока метку не выслал нижестоящий LSR, вышестоящий не может её отправить своим соседям.

Стоп! Мы говорили, что RSVP TE в отличие от LDP позволяет строить как мы хотим, не привязываясь к таблице маршрутизации и IGP, а тут пока просто «в направлении 6.6.6.6».
И вот тут мы подошли вплотную к фундаментальному отличию RSVP TE от LDP. RSVP TE очень тесно связан с протоколами динамической маршрутизации, он не просто опирается на результат их работы - он адаптирует их под себя, эксплуатирует в прямом смысле слова.
Во-первых , годятся только протоколы, основанные на алгоритмах по состоянию связи (link-state), то есть OSPF и ISIS.
Во-вторых , OSPF и ISIS расширяются введением новых элементов в протоколы. Так в OSPF появляется новый тип LSA - Opaque LSA , а в ISIS - новые TLV IS Neighbor и IP Reachability .
В-третьих , для расчёта пути между Ingress LSR и Egress LSR используется специальная модификация алгоритма SPF - CSPF (Constrained Shortest Path First ).

Теперь подробнее.

Сообщение Path в принципе передаётся юникастом адресно. То есть адрес отправителя у него - адрес R1, а получателя - 6.6.6.6. И оно могло бы дойти и просто по таблице маршрутизации.

Но фактически Path передаётся по сети не как FIB на душу положит на каждом узле, ведь мы тогда не сможем ни резервирование обеспечить, ни поиск запасных маршрутов. Нет, он следует определённому пути.
Этот путь определяется на Ingress LSR с точностью до каждого узла.
Чтобы построить этот путь, RSVP TE нужно знать топологию сети. Понимаете да, к чему мы приближаемся? Сам RSVP не утруждает себя её изучением, да и зачем, когда её можно получить у OSPF или ISIS. И тут же становится очевидно, почему сюда не подходят RIP, IGRP и EIGRP - ведь они не изучают топологию, максимум на что они способны - это Feasible Successor.
Но классический алгоритм SPF на входе имеет топологию сети, а на выходе может выдать только наибыстрейший маршрут с учётом метрик и , хотя просчитать может и все возможные пути.
И тут на сцену выходит CSPF. Именно этот алгоритм может посчитать лучший путь, второй по приоритетности путь и, например, ещё какой-нибудь запасной, чтобы хоть как-то добраться, пусть и через Китай .
То есть RSVP TE может обращаться к CSPF с просьбой вычислить для него какой-либо путь между двумя узлами.
Ну хорошо, а зачем для этого менять сами протоколы IGP? Вооот. А это уже Constraints - ограничения. RSVP TE может предъявлять требования к пути - ширина полосы пропускания, минимально доступная ширина, тип линии или даже узлы, через которые LSP должен пролегать. Так вот, чтобы CSPF мог учитывать ограничения, он должен знать и о них и о доступных ресурсах на узлах всей сети. Входными данными для него являются ограничения, заданные в туннеле и топология сети - логично будет, если топология будет содержать кроме префиксов и метрик ещё и информацию о доступных ресурсах.
Для этой цели маршрутизаторы обмениваются между собой через сообщения OSPF и ISIS не только базовой информацией, но и характеристиками линий, интерфейсов итд. Как раз в новых типах сообщений и передаётся эта информация.
Например, в OSPF для этого ввели 3 дополнительных типа LSA:

• Type 9 - link-local scope
• Type 10 - area-local scope
• Type 11 - AS scope

Opaque значит непрозрачный (для OSPF). Это специальные типы LSA, которые никак не учитываются в самом OSPF при расчёте таблицы маршрутизации. Их могут использовать любые другие протоколы для своих нужд. Так TE их использует для построения своей топологии (она называется TED - Traffic Egineering Database ). Но теоретически за TE они не закреплены - если вы напишете своё приложение для маршрутизаторов, которое будет требовать обмена какой-то информацией о топологии, вы тоже можете использовать Opaque LSA.
Точно так же работает и ISIS. Новые сообщения: IS-IS TLV 22 (Extended IS Reachability), 134 (Traffic Engineering router ID), 135 (Extended IP reachability).

Итак, взглянем более детализированно на весь этот процесс.

0) На R1 мы включили MPLS TE и настроили ISIS (OSPF) на передачу данных для поддержки TE. Маршрутизаторы обменялись информацией о доступных ресурсах. На этом шаге сформирована TED. RSVP молчит.

1) Мы создали туннельный интерфейс, где указали его тип (Traffic Engineering), адрес назначения (6.6.6.6) и необходимые требования по ресурсам. LSR запускает CSPF: нужно вычислить кратчайший путь от R1 до 6.6.6.6 с учётом накладываемых условий. На этом шаге мы получаем оптимальный путь - список узлов от источника до получателя (R2, R5, R6).

2) Результат предыдущего шага скармливается RSVP и трансформируется в объект ERO . R1 компилирует RSPV Path, куда, естественно, добавляет ERO. Адресат пакета - 6.6.6.6. Кроме того, имеется и объект Label Request, сообщающий о том, что при получении пакета нужно выделить метку для данного FEC (6.6.6.6/32).

ERO - Explicit Route Object - специальный объект сообщения RSVP Path. Он содержит список узлов, через которые суждено пройти этому сообщению.

3) Сообщение RSVP Path передаётся специальным образом - не по таблице маршрутизации, а по списку ERO. В нашем случае лучший маршрут IGP и ERO совпадают, поэтому пакет посылается на R2.

4) R2, получив RSVP Path, проверяет наличие требуемых ресурсов и, если они есть, выделяет метку MPLS для FEC 6.6.6.6/32. Старый пакет Path уничтожается и создаётся новый, причём объект ERO меняется - из него удаляется сам R2. Делается это для того, чтобы следующий узел не пытался вернуть пакет на R2. То есть новый ERO выглядит уже так: (R5, R6). В соответствии с ним R2 отправляет обновлённый Path на R5.

5) R5 совершает аналогичные операции: проверяет ресурсы, выделяет метку, удаляет себя из ERO, пересоздаёт пакет Path и передаёт в интерфейс, через который ему известен следующий объект ERO - R6.

6) R6, получив пакет, понимает, что он виновник всей суматохи. Он уничтожает Path, выделяет метку для FEC 6.6.6.6 и вставляет её как объект Label в ответное сообщение Resv.
Заметьте, до этого шага метки только выделялись, но не распространялись, теперь же они начинают анонсироваться тем LSR, которые их запрашивали.
7) Сообщение RESV продвигается к R1 (Ingress LSR), оставляя за собой растущий хвост LSP. Resv должно пройти через те же узлы, что Path, но в обратном порядке.

8) В конце концов LSP от R1 до 6.6.6.6 сформирован. Данные по нему могут передаваться только от R1 к R6. Чтобы позволить передачу данных в обратном направлении, нужно создать туннельный интерфейс на R6 с адресом назначения 1.1.1.1 - все действия будут точно такими же.

Возникает вопрос - почему адресат пакета Path 6.6.6.6, если передаётся он узел за узлом и их адреса известны? Вопрос этот не праздный - он ведёт нас к одной важной особенности. Объект ERO может на самом деле содержать не все узлы от Ingress LSR до Egress LSR - некоторые могут быть опущены. Поэтому каждый LSR должен знать, куда в итоге направляется сообщение. И происходить это может не потому что Ingress LSR лень просчитать весь путь.
Проблема в зонах IGP. Вы знаете, что и в OSPF и в ISIS существует это понятие для того, чтобы упростить маршрутизацию. В больших сетях (сотни и тысячи узлов) встаёт проблема широковещательных рассылок служебных пакетов и просчёт огромного количества комбинация алгоритмом SPF. Поэтому один глобальный домен делится на зоны маршрутизации.
И вся загвоздка в том, что если внутри зоны IGP и является протоколом по состоянию связи (link-state), то между ними - он самый настоящий дистанционно-векторный - топология сети строится только внутри зоны, любые внутренние маршрутизаторы не знают, как устроены другие зоны - они только поставлены в известность, что для того, чтобы попасть в ту или иную сеть, им нужно отправлять пакеты на конкретный ABR .
Иными словами, если у вас сеть поделена на зоны, то с MPLS TE возникают затруднения - CSPF не может просчитать весь путь, потому что в его топологии адресат из другой зоны - это облако, а не конкретный узел.
И тут на помощь приходит Explicit Path (не путать с объектом ERO). Это самый, что ни на есть, прямой способ управления путём построения LSP - администратор может самостоятельно и явно задать те узлы, через которые нужно проложить LSP. Ingress LSR должен точно следовать таким указаниям. Это вносит в жизнь алгоритма CSPF ещё немного разнообразия.
Как Explicit Path помогает пробить зону? Давайте на примере.

Мы возьмём и укажем, что обязательно должны быть промежуточные точки:
Explicit-path: R1, R3, R5.

Когда этот Explicit Path мы скармливаем CSPF, он строит тот кусок, который может, то есть в пределах Area 0: от R1 до R3.
То, что он насчитал, заносится в ERO, плюс в него добавляются и ещё один узел из Explicit-path - R5. Получается: R1, R2, R3. Path отправляется по сети согласно ERO, доходит до R3. Тот видит, что он в общем-то не адресат, а только перевалочный пункт, берёт заданные условия по требуемым ресурсам и адрес узла-получателя из Explicit-path и запускает CSPF. Последний выдаёт полный список узлов до адресата (R3, R4, R5), который преобразуется в ERO, и дальше всё происходит по стандартному сценарию.
То есть в случае нахождения Ingress LSR и Egress LSR в разных зонах вычисление пути выполняется отдельно для каждой зоны, а контрольной точкой является ABR.

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

Меня могут упрекнуть в лукавстве, сказав, что не настолько уж и обязателен Link-State IGP. Ну вот хочется на моноцисочной сети запустить EIGRP, сил нет. Или вообще некрофильные позывы заставляют откопать RIP. И что теперь? Отказаться от TE?
В общем есть спасение, но только на оборудовании Cisco - называется оно Verbatim .

Ведь для чего нам нужен Link-State протокол? Он собирает информацию о топологии TE, а CSPF строит путь от Ingress LSR до Egress LSR. Таак. Отлично. А что если мы возьмём и состряпаем Explicit Path, где перечислим все узлы один за другим? Ведь тогда не надо ничего считать.
На самом деле, как бы подробно вы ни составили явный путь, он всё равно будет передан CSPF.
Но такое поведение можно отключить. Как раз для случаев, описанных выше.
Поможет такая команда:
Router(config-if)# tunnel mpls traffic-eng path-option 1 explicit name test verbatim
То ест данный путь будет взят как заведомо верный безо всяких проверок и пересчётов CSPF.
Такой сценарий стоит под большим вопросом, а его плюсы весьма призрачны. Однако возможность есть, и не говорите потом, что я вам про неё не рассказал.

Практика RSVP TE

Команда mpls ip была нам нужна для работы LDP. Теперь в ней больше нет нужды - удаляем её и начинаем с чистого листа .
Теперь нам понадобится mpls traffic-eng tunnels . Она глобально включает поддержку TE-туннелей и собственно RSVP TE:
R1(config)#mpls traffic-eng tunnels
Также необходимо включить то же самое на интерфейсах:

R1(config)# interface FastEthernet 0/0 R1(config-if)# mpls traffic-eng tunnels R1(config)# interface FastEthernet 0/1 R1(config-if)# mpls traffic-eng tunnels
Пока ничего не происходит. RSVP молчит.

Сейчас мы расширим IGP на передачу данных TE. В своём примере мы используем ISIS:
R1(config)#router isis R1(config-router)# metric-style wide R1(config-router)# mpls traffic-eng router-id Loopback0 R1(config-router)# mpls traffic-eng level-2
Включить режим расширенных меток - обязательно, иначе TE не заработает.
Задать LSR-ID, как мы это делали и в LDP,
Необходимо задать конкретный уровень ISIS, иначе, TE не заработает.

Если вдруг вы используете OSPF

R1(config)# mpls traffic-eng area 0
R1(config-router)# mpls traffic-eng router-id Loopback0

Эти шаги нужно повторить на других маршрутизаторах.

Сразу после этого ISIS начинает обмениваться информацией о TE:

Как видите передаётся информация о LSR-ID, расширенная информация о соседях (которые поддерживают TE), расширенная информация о интерфейсах.

На этом этапе сформирована TED.

Саму топологию вы можете посмотреть в ISIS: #show isis database verbose

RSVP пока молчит.

Теперь настроим TE-туннель.
R1(config)# interface Tunnel1 R1(config-if)# ip unnumbered Loopback0 R1(config-if)# tunnel destination 6.6.6.6 R1(config-if)# tunnel mode mpls traffic-eng R1(config-if)# tunnel mpls traffic-eng path-option 10 dynamic
Туннельные интерфейсы - вещь очень универсальная на маршрутизаторах. Они могут использоваться для L2TP, GRE, IPIP и, как видите, для MPLS TE.
ip unnumbered Loopback0 означает, что отправной точкой туннеля должен быть адрес интерфейса Loopback0.
tunnel destination 6.6.6.6 - универсальная для туннельных интерфейсов команда, определяет точку терминации, окончания туннеля.
tunnel mode mpls traffic-eng - задаёт тип. Именно здесь и определяется алгоритм работы туннеля, как его строить.
tunnel mpls traffic-eng path-option 10 dynamic - эта команда позволяет CSPF построить путь динамически, без задания промежуточных узлов.

Если до этого вы всё сделали правильно, то туннельный интерфейс должен подняться:
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up

Что при этом произошло?
R1 отправил Path.

Дамп снят на линии R1-R2.

Нас в нём интересуют адрес назначения, объекты ERO и Label Request.
Адрес назначения - 6.6.6.6, как и настроили в туннеле.
Explicit Route:
10.0.12.2 -> 10.0.25.2 -> 10.0.25.5 -> 10.0.56.5 -> 10.0.56.6.
То есть в нём прописан линковый адрес выходного интерфейса и линковый же адрес следующего узла. Каждый LSR таким образом точно знает, в какой интерфейс нужно отправить Path.
В данном ERO нет 10.0.12.1, потому что R1 уже удалил его перед отправкой.
Факт наличия Label Request говорит о том, что LSR должен выделить метку для данного FEC.
При этом он никак не отвечает на этот Path пока - он посылает обновлённый дальше.
Resv ниже посылается после того, как пришёл Resv от нижестоящего LSR.

То же самое происходит на R5:

Дамп снят на линии R2-R5.

Дамп снят на линии R2-R5.

Так Path доходит до R6. Тот отправляет назад RSPV Resv:

Дамп снят на линии R5-R6.

На дампе хорошо видно, что Resv передаётся от узла к узлу.
В объекте Label передаётся метка, выделенная данному FEC.

Обратите внимание, что R6 присвоил метку 0 - Expliсit Null. Вообще это нормальная ситуация - делается это для того, чтобы метка MPLS между R5 и R6 была (для обработки пакета согласно значению в поле EXP, например), но R6 сразу же понял, что метку 0 надо сбрасывать и обрабатывать то, что под ней, а не производил поиск в таблице меток.
Проблема в том, что в пакете меток может быть больше одной (например, для VPN), но согласно RFC 3032 (да и мы раньше об этом говорили) R5 должен удалить весь стек меток, сколько бы их ни было, и передать пакет с одной меткой 0. При этом, конечно, всё сломается.
На самом деле, требование того, чтобы метка 0 была единственной в стеке, выглядит неоправданным - применений этому нет. Поэтому в RFC 4182 это ограничение убрали. Теперь метка 0 может быть не единственной в стеке.
Интересная особенность - PHP. Несмотря на то, что для этого есть специальная метка - 3 - LSR совершит PHP даже при получении метки 0. Подробнее у того же Пепельняка .

R5 передаёт Resv на R2, а R2 на R1.


Дамп снят на линии R1-R2.

Тут, как видите, уже метка нормальная - 16.

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

ВиО

В1: Чем отличаются RSVP TE LSP и LDP LSP?

Строго говоря, с точки зрения как вышестоящиех протоколов, так и самого MPLS таких понятий нет вообще. LSP - он и есть LSP - это просто путь коммутации меток.
Можно выделить термин CR-LSP (ConstRaint-based LSP) - он строится RSVP TE. В этом плане разница в том, что CR-LSP удовлетворяет условиям заданным в туннельном интерфейсе.

В2: Как соотносятся Explicit Path и ERO?

Если для туннеля задан Explicit Path, то RSVP формирует ERO, учитывая требования Explicit Path. При этом даже если вы в Explicit-Path пропишите каждый узел до Egress LSR, RSVP всё равно загонит данные в CSPF.

В3: Если один из промежуточных узлов не будет поддерживать LDP (RSVP TE) или протокол будет выключен на интерфейсе/платформе, будет ли построен LSP так, например, чтобы на этом узле он переходил в IP, а потом на следующем снова в MPLS?

В случае RSVP TE Ingress LSR не будет иметь данного узла в TED и не сможет выстроить путь до Egress LSR, соответственно не пошлёт Path, соответственно, не будет и меток и LSP.
Трафик через туннель передаваться не сможет.

Если же речь о LDP, то ситуация интереснее. Например, если на R2 выключить LDP на интерфейсе FE0/0 (в сторону R5), то
1) на R1 будет метка для FEC 6.6.6.6/32. Причём их будет 2: одна через R2, другая - через R3, поскольку согласно таблице маршрутизации лучший - через R2, то и LSP будет лежать в сторону R2.
2) на R2 метка будет, но только одна - в сторону 1.1.1.1. Это не лучший путь, поэтому он не будет использован. То есть здесь LSP от R1 к FEC 6.6.6.6/32 прекращает своё существование.
3) на R5 метка для FEC 6.6.6.6/32 будет

То есть, вроде бы, мы получаем разорванный LSP: {R1-R2, R5-R6}. Но на самом деле, это не так. LSP на то и Label Switched, чтобы на протяжении всего пути на нём менялись метки, а у нас получается от R1 до R2 MPLS, от R2 до R5 IP, а от R5 до R6 опять MPLS. LSP для FEC 6.6.6.6/32 здесь нет . Обычный трафик тут пройдёт, в принципе, но если говорить о каких-то применениях MPLS, таких, например, как VPN, то это работать не будет.

В4: Хорошо, зачем нужен MPLS будет понятно из следующих статей - пока это вообще какая-то искусственная ерунда, чтобы усложнить жизнь инженера, но зачем мне MPLS TE-то? Ведь трафик можно направить нужным мне путём с помощью метрик IGP.

Начнём с того, что это тема будущих выпусков. Но…
Вообще говоря, если вы хотите определять путь, по которому пойдёт трафик, то это действительно можно сделать путём хитрой настройки стоимости линков, интерфейсов итд. Но обслуживание такой системы доставит вам те ещё хлопоты с одной стороны, а с другой у вас всё равно не получится направить два разных потока разными путями. То есть если стоит задача разгрузить сеть путём распределения трафика, то с помощью метрик вы просто перенесёте проблему с одного плеча на другое.
А вот если у вас будет несколько разных LSP и вы сможете направить в них трафик, то это пожалуйста. Хотя в плане простоты поддержки TE тоже вызывает вопросы.

Ну и вообще подумайте, если вам нужны для двух клиентов гарантированные каналы 40 Мб/с и 50 Мб/с соответственно, как вы будете отслеживать утилизацию линий? Ну хорошо, один раз вы вычислили и настроили каким-то чудесным образом маршрутизацию и QoS так, чтобы обеспечить нужный уровень услуги, но вдруг у вас срезают в трёх местах 3 километра оптики разом и вы неделю не можете починить. И у вас даже есть три резервных канала по 50Мб/с, но трафик обоих клиентов попёр в одно место, наплевав на все ваши формальные SLA .

В5: Так чем всё-таки отличаются метки Explicit Null и Implicit Null? Нужно ли мне о них действительно знать?

Нужно. Первоначально предполагается, что по сети MPLS пакет всегда коммутируется по меткам от первого до последнего LSR. А на последнем пролёте метка будет «0», чтоб Egress LSR сразу знал, что её нужно снять. Эта метка позволяет не потерять приоритет, заданный в поле TC заголовка MPLS, который копируется по мере передачи пакета по сети. В итоге даже последний маршрутизатор обработает данные в правильных очередях.

В концепции с использованием метки «3» решили отказаться от лишних действий на Egress LSR. Если вас не волнует QoS (или вы скопировали приоритет, например, в поле DSCP), то острой нужды в транспортной метке на последнем пролёте нет - главное отправить в правильный интерфейс, а там Egress LSR разберётся. Если там был чистый IP-пакет - отдать его процессу IP, если был какой-нибудь E1, передать поток в нужный интерфейс, если стек меток, то сделать lookup в LFIB и посмотреть, какие дальнейшие действия нужно предпринять.

В6: Для одного FEC LSR всегда будет выделять одну и ту же метку всем своим соседям?

Существует понятие пространства меток:

• пространство меток интерфейса
• пространство меток слота
• пространство меток платформы

Если метки специфичны для каждого интерфейса, тогда для одного FEC в разные порты могут быть отправлены разные метки.
И наоборот - если метки специфичны для платформы (читай всего LSR), то маршрутизатор во все порты для одного FEC обязан отправить одинаковые метки.
В примерах ниже вы увидите, что у нас для одного FEC отправляются одинаковые метки разным соседям, но это ещё не говорит о том, как организовано пространство меток. Это вещь сугубо индивидуальная и завязана на аппаратном обеспечении.

Важно понимать, что технология MPLS никак не регламентирует протокол распространения меток, но конечные результаты на конкретной сети вполне могут различаться при использовании разных протоколов. Вышестоящие протоколы и приложения используют LSP безотносительно того, кем и как они построены.
Кстати нередко в современных сетях встречается сценарий LPD over TE. В этом случае RSVP-TE используется для организации транспорта и реализации Traffic Engineering, а LDP для обмена метками VPN, например.
Egress LSR, записывая в заголовок MPLS первую метку, определяет весь путь пакета. Промежуточные маршрутизаторы просто меняют одну метку на другую. Содержимое может быть совершенно любым. Как раз вот эта мультипротокольность позволяет MPLS служить основой для разнообразных сервисов VPN.

MPLS TE

LSP

LSR

FEC

Добавить метки

Спецификация кодирования стека меток MPLS определена в RFC3032 "MPLS Label Stack Encoding". Данный документ содержит детальную информацию о метках и о том, как они используются с различными сетевыми технологиями, а также определяет ключевое для технологии MPLS понятие – стек меток. Возможность иметь в пакете более одной метки в виде стека позволяет создавать иерархию меток, что открывает дорогу многим приложениям.

MPLS может выполнить со стеком следующие операции:

помещать метку в стек;

удалять метку из стека;

и заменять метку.

Эти операции могут использоваться для слияния и разветвления информационных потоков. Операция помещения метки в стек (push operation) добавляет новую метку поверх стека, а операция удаления метки из стека (pop operation) удаляет верхнюю метку стека.

Функциональные возможности стека MPLS позволяют объединять несколько LSP в один. К стеку меток каждого из этих LSP сверху добавляется общая метка, в результате чего образуется агрегированный тракт MPLS. В точке окончания такого тракта происходит его разветвление на составляющие его индивидуальные LSP. Так могут объединиться тракты, имеющие общую часть маршрута. Следовательно, MPLS способна обеспечивать иерархическую пересылку, что может стать важной и востребованной функциональной возможностью. При ее использовании не нужно переносить глобальную маршрутную информацию, и это делает сеть MPLS более стабильной и масштабируемой, чем сеть с традиционной маршрутизацией.

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

Пример четырехуровневого стека меток представлен на рис. 2.

Заголовок MPLS № 1 был первым заголовком MPLS, помещенным в пакет, затем в него были помещены заголовки № 2, № 3 и, наконец, заголовок № 4. Коммутация по меткам всегда использует верхнюю метку стека, и метки удаляются из пакета так, как это определено выходным узлом для каждого LSP, по которому следует пакет. Рассмотренный в предыдущем параграфе бит S имеет значение 1 в нижней метке стека и 0 – во всех остальных метках. Это позволяет привязывать префикс к нескольким меткам, другими словами – к стеку меток (Label Stack). Каждая метка стека имеет собственные значения поля EXP, S-бита и поля TTL.

Рис. 2. Четырехуровневый стек меток

Инкапсуляция меток

При использовании протоколов коммутации на уровне звена данных, таких как ATM и Frame Relay, верхняя MPLS-метка вписывается в поле идентификаторов этих протоколов. Далее будет показано, как при применении ATM для размещения MPLS-метки используется поле VPI/VCI, а при применении Frame Relay – поле DLCI (Data LinkConnection Identifier). В тех случаях, когда MPLS обеспечивает пересылку IP-пакетов сетевого уровня и когда технология уровня звена данных не поддерживает собственное поле меток, MPLS-заголовок должен инкапсулироваться между заголовками уровня звена данных и сетевого уровня.

Механизм инкапсуляции переносит один или более протоколов верхних уровней внутри полезной нагрузки дейтаграммы инкапсулирующего протокола. В сущности, вводится новый заголовок, который делает из инкапсулированного заголовка и поля данных новое поле данных. Общая модель инкапсуляции представлена на рис. 10.3, где подразумевается, что инкапсуляция MPLS может быть использована с любой технологией уровня 2. Метка MPLS может быть помещена в существующий формат заголовка уровня 2, как в случае АТМ или FR, или вписана в специальный заголовок MPLS, как в случае Ethernet или PPP. Bo всех случаях любые дополнительные метки находятся между верхней меткой стека и IP-заголовком уровня 3.

Показанный на рис 3 заголовок MPLS часто называют shim header ("заголовком - клином"), подчеркивая в метафорической форме тот факт, что этот заголовок "уровня 2.5" вклинивается в пакет между заголовками уровня данных и сетевого уровня.

Рис. 3. Принцип инкапсуляции заголовка MPLS

Одной из самых сильных сторон технологии MPLS (и потому отраженной в ее названии) является то, что она может использоваться совместно с различными протоколами уровня 2. Среди этих протоколов – ATM , Frame Relay , PPP и Ethernet , FDDI и другие, предусмотренные документами по MPLS .

Покажем, как метка может вписываться в заголовок уровня звена данных (VCI/VPI для сети ATM, DLCI для сети Frame Relay и т.п.) или "вставляться" между заголовками уровня звена данных и сетевого уровня. С самого начала рабочая группа IETF MPLS решила, что во всех случаях, когда это возможно, MPLS должна использовать имеющиеся форматы. По этой причине информация метки MPLS может передаваться в пакете несколькими разными методами:

как часть заголовка второго уровня ATM, когда информация метки передается в идентификаторах виртуального канала VCI и виртуального тракта VPI, что показано на рис. 10.4;

как часть кадра AAL5 уровня адаптации ATM (ATM Adaptation Layer 5) перед сегментацией и сборкой SAR (Segmentation and Reassembly), что выполняется в ATM-окружении в случае, когда эта информация содержит данные о стеке меток (несколько полей MPLS-меток);

как часть заголовка второго уровня Frame Relay, когда информация метки передается в идентификаторах DLCI, что изображено на рис. 10.5;

как новая 4-байтовая метка, называемая клином или прокладкой (shim), которая вставляется между заголовками второго и третьего уровней, что показано на рис. 10.5, – во всех остальных случаях.

Размещение метки MPLS в заголовке ATM представлено на рис. 4.

Рис. 4. MPLS-метка, передаваемая в полях VPI/VCI заголовка АТМ

Использование MPLS поверх ATM сейчас довольно распространено, особенно для транспортировки по сетям ATM трафика IP. АТМ-коммутаторы, которые конфигурированы для поддержки MPLS (ATM-LSR), выполняют протоколы маршрутизации TCP/IP и используют пересылку данных в ATM фиксированной длины 53 байта. Внутри этих ATM-LSR верхняя метка MPLS помещается в поля VCI/VPI заголовка ячейки ATM, а данные о стеке меток MPLS - в поле данных ячеек ATM.

MPLS в сетях Frame Relay была развернута рядом крупных поставщиков услуг и до сих пор широко используется. Подобно ATM, FR-коммутаторы, поддерживающие MPLS, применяют протоколы маршрутизации TCP/IP для пересылки данных под управлением FR. При использовании FR текущая метка помещается в поле идентификатора канала звена данных DLCI в заголовке FR. Любые дополнительные записи в стек меток MPLS переносятся после заголовка FR, но до заголовка сетевого уровня, содержащегося в поле данных кадра FR. Стандарт MPLS позволяет FR использовать адрес Q.922 длиной либо 2 октета, либо 4 октета. Формат представлен на рис. 5.

Рис. 5. Размещение метки MPLS в кадре FR

Примечание. Длина поля DLCI может составлять 10, 17 или 23 бита

В отношении ячеек ATM и кадров Frame Relay договорились использовать для MPLS имеющиеся форматы заголовков, а во всех остальных случаях – собственную метку MPLS, "прокладку" между заголовками второго и третьего уровней. Отсюда видно, что MPLS позволяет создавать новые форматы меток без изменения протоколов маршрутизации, а потому распространение этой технологии на вновь появляющиеся виды оптического транспорта, такие как плотное мультиплексирование с разделением по длине волны DWDM (Dense Wave Division Multiplexing) и оптическая коммутация, представляет собой относительно простую задачу.

Принцип, представленный на рис. 10.3, подходит для каналов типа "точка-точка" (Point-to-Point – РРР) и для локальных сетей Ethernet (всех типов). Подобным методом можно передать одну MPLS-метку или стек меток.

Протокол РРР фактически представляет собой семейство родственных протоколов IETF, используемое для передачи многопротокольных дейтаграмм по двухточечным каналам связи. РРР определяет метод инкапсуляции дейтаграмм разных протоколов сетевого уровня, протокола управления звеном данных LCP и набора протоколов управления сетью NCP. Для использования MPLSCP с управлением коммутацией по меткам через звено РРР был определен специальный протокол, который управляет передачей пакетов MPLS по каналу РРР. Этот протокол обозначается аббревиатурой MPLSCP. Формат показан на рис. 6.

Рис. 6. Формат для введения MPLS-метки в пакет РРР и в кадр Ethernet

Когда пакеты MPLS передаются по Ethernet, в каждом кадре Ethernet переносится только один снабженный меткой пакет. Метка помещается между заголовком уровня звена данных и заголовком сетевого уровня. Использование MPLS в сетях Ethernet, особенно в городских сетях, является еще одной перспективной возможностью MPLS. В стандарт Ethernet вносятся изменения, позволяющие увеличить скорость и дальность передачи Ethernet-пакетов. В настоящее время начинают применяться Ethernet-интерфейсы на скоростях 10 Гбит/с, а в скором времени появятся Ethernet-интерфейсы и на еще больших скоростях.

К сожалению, добавление MPLS-метки или стека меток к 1492-байтовому пакету может привести к необходимости его фрагментации. При передаче пакетов MTU-размера (Maximum Transmission Unit – максимально возможный размер передаваемого блока данных) с MPLS-меткой протокол управления передачей TCP определяет, что в MPLS-сети нужно произвести фрагментацию. Однако следует отметить, что многие Ethernet-каналы поддерживают передачу 1500-байтовых или 1508-байтовых пакетов. Более того, в большинстве сетей пакеты с метками обычно передаются по ATM- или РРР-каналам, а не по сегментам локальных сетей.

Итак, метка может быть помещена в пакет разными способами – вписывается в специальный заголовок, помещаемый либо между заголовками уровня 2 и уровня 3, либо в свободное и доступное поле заголовка одного из этих двух уровней, если, конечно, таковое имеется. Очевидно, что вопрос о том, куда следует помещать заголовок, содержащий метку, должен согласовываться между объектами, ее использующими.

Таблицы пересылки

Ранее отмечалось, что когда пакет MPLS попадает в маршрутизатор коммутации по меткам LSR, этот маршрутизатор просматривает имеющуюся у него таблицу с так называемой информационной базой меток LIB (Label Information Base) для того, чтобы принять решение о дальнейшей обработке пакета. Эту информационную базу иногда называют также Next Hop Label Forwarding Entry (NHLFE), и, согласно RFC 3031, в нее обычно входит следующая информация:

операция, которую надо произвести со стеком меток пакета (заменить верхнюю метку стека, удалить верхнюю метку, поместить поверх стека новую метку);

следующий маршрутизатор в LSP, причем "следующим" может быть тот же самый LSR;

используемая при передаче пакета инкапсуляция на уровне звена данных;

способ кодирования стека меток при передаче пакета;

другая информация, относящаяся к пересылке пакета.

Содержащая эту информацию таблица пересылки, которую ведет каждый LSR, как, впрочем, и любые другие таблицы, представляет собой последовательность записей. Каждая запись таблицы пересылки LSR состоит из входящей метки и одной или более подзаписей, причем каждая подзапись содержит значение исходящей метки, идентификатор выходного интерфейса и адрес следующего маршрутизатора в LSP. Пример простой таблицы пересылки LIB представлен в таблице 1.

Таблица 1 Таблица пересылки LIB

Разные подзаписи внутри одной записи могут иметь либо одинаковые, либо разные значения исходящих меток. Более одной подзаписи бывает нужно для поддержки многоадресной рассылки пакета, когда пакет, который поступил к одному входящему интерфейсу, должен затем рассылаться через несколько исходящих интерфейсов. Обращение к таблице записей производится по значению входящей метки, т.е. по входящей метке к происходит обращение к к-й записи в таблице.

Запись в таблице может также содержать информацию, указывающую, какие ресурсы имеет возможность использовать пакет, например, определенную выходную очередь.

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

Привязка "метка-FEC"

Каждая запись в таблице пересылки, которую ведет LSR, содержит одну входящую метку и одну или более исходящих меток. В соответствии с этими двумя типами меток обеспечивается два типа привязки меток к FEC:

первый тип – метка для привязки выбирается и назначается в LSR локально. Такая привязка называется локальной;

второй тип – LSR получает от некоторого другого LSR информацию о привязке метки, которая соответствует привязке, созданной на этом другом LSR. Такая привязка называется удаленной.

Средства управления коммутацией по меткам используют для заполнения таблиц пересылки как локальную, так и удаленную привязку меток к FEC . Это может делаться в двух вариантах : upstream и downstream . Первый: когда метки на локальной привязке используются как входящие метки, а метки из удаленной привязки - как исходящие. Второй вариант – прямо противоположный, т.е. метки из локальной привязки используются как исходящие метки, а метки из удаленной привязки – как входящие. Рассмотрим каждый из этих вариантов.

Первый вариант называется привязкой метки к FEC "снизу" (downstream label binding), потому что в этом случае привязка переносимой пакетом метки к тому FEC, которому принадлежит этот пакет, создается нижестоящим LSR, т.е. LSR, расположенным ближе к адресату пакета, чем LSR, который помещает метку в пакет. При привязке "снизу" пакеты, которые переносят определенную метку, передаются в направлении, противоположном направлению передачи информации о привязке этой метки к FEC.

Второй вариант называется привязкой метки к FEC "сверху" (upstream label binding ) , потому что в этом случае привязка переносимой пакетом метки к тому FEC, которому принадлежит этот пакет, создается тем же LSR, который помещает метку в пакет; т.е. создатель привязки расположен "выше" (ближе к отправителю пакета), чем LSR, к которому пересылается этот пакет. При привязке "сверху" пакеты, которые переносят определенную метку, передаются в том же направлении, что и информация о привязке этой метки к FEC.

LSR обслуживает также пул "свободных" меток (т.е. меток без привязки). При начальной установке LSR пул содержит все метки, которые может использовать LSR для их локальной привязки к FEC. Именно емкость этого пула и определяет, в конечном счете, сколько пар "метка-FEC" может одновременно поддерживать LSR. Когда маршрутизатор создает новую локальную привязку, он берет метку из пула; когда маршрутизатор уничтожает ранее созданную привязку, он возвращает метку, связанную с этой привязкой, обратно в пул.

Вспомним, что LSR может вести либо одну общую таблицу пересылки, либо несколько таблиц – по одной на каждый интерфейс. Когда маршрутизатор ведет общую таблицу пересылки, он имеет один пул меток. Когда LSR ведет несколько таблиц, он имеет отдельный пул меток для каждого интерфейса.

LSR создает или уничтожает привязку метки к FEC вследствие определенного события. Такое событие может инициироваться либо пакетами данных, которые должны пересылаться маршрутизатором LSR, либо управляющей (маршрутной) информацией, которая должна обрабатываться LSR. Когда создание или уничтожение привязки инициируется пакетами данных, эта привязка называется привязкой под воздействием данных (data-driven). Когда создание или уничтожение привязки инициируется управляющей информацией, данная привязка называется привязкой под воздействием управляющей информации (control-driven).

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

Важной проблемой качества функционирования, возникающей при использовании схем привязки под воздействием данных (и, в меньшей степени, – схем привязки под воздействием управляющей информации), является производительность. Каждый раз, когда LSR решает, что поток должен коммутироваться по меткам, ему необходимо обмениваться информацией о привязке меток со смежными LSR, и ему может также потребоваться внести некоторые изменения в привязке меток к FEC. Все эти процедуры требуют передачи трафика, управляющего раздачей информации о привязке, и, следовательно, потребляют ресурсы средств управления коммутацией по меткам. Более того, эти процедуры потребляют тем больше ресурсов средств управления, чем больше доля потоков, выбранных для коммутации по меткам. Трудно количественно оценить, насколько дорогой является процедура назначения и распределения меток, но не подлежит сомнению, что производительность схем, работающих под воздействием данных, чувствительна к этому фактору. Если LSR не может назначать и распределять метки со скоростью, требуемой алгоритмом обнаружения потоков, то коммутироваться по меткам будет меньший процент потоков, и от этого будет страдать общая производительность.

В меньшей степени это относится к схемам, работающим под воздействием управляющей информации. Пока топология остается стабильной, весь трафик, который поступает в непограничный маршрутизатор LSR, может коммутироваться по меткам без обработки пакетов управляющим процессором. Схемы, работающие под воздействием управляющей информации, могли получить информацию о привязке маршрутов от соседних LSR, которые не являлись следующими участками этих маршрутов. Когда топология изменится так, что эти "соседи" станут следующими участками маршрутов, коммутация по меткам будет продолжаться без прерывания. Но на производительность схем, работающих под воздействием данных, изменение топологии влияет. Если изменяется маршрут прохождения потока, новые LSR на этом маршруте воспринимают это так, как если бы был создан новый поток. Любой такой новый поток должен вначале пересылаться традиционно. Таким образом, изменение топологии может налагать очень тяжелое бремя на LSR, который только что стал новым следующим маршрутизатором для некоторого другого LSR. Во-первых, он внезапно получает большое число потоков, которые ранее шли по другому маршруту. Кроме того, не прекращается поступление новых потоков от вновь запущенных приложений. Все эти потоки должны пересылаться и анализироваться алгоритмами обнаружения потоков. Это в свою очередь создает дополнительную нагрузку как на средства пересылки при традиционной маршрутизации, так и на средства управления коммутацией по меткам. Во время таких переходных процессов производительность средств пересылки LSR может приблизиться к производительности его средств пересылки при традиционной маршрутизации, т.е. стать примерно на порядок ниже, чем максимальная производительность LSR.

магистрант

Тишкова Ю.И. СибГУТИ

Аннотация:

Данная статья посвящена рассмотрению вопроса о виртуальной частной сети на базе многопротокольной коммутации по меткам.

This article deals with the issue of virtual private network based on multiprotocol label switching.

Ключевые слова:

Виртуальная частная сеть, пограничный маршрутизатор, внутренний маршрутизатор, маршрутизаторов с коммутацией меток

virtual Private Network, Edge Router , Internal Router, Label Switch Router

УДК 004.7

Представим, гипотетически, предприятие, работающее на мировом уровне: Офисы разбросаны по всему миру, десятки сотрудников в командировках, работающие «из дома» сотрудники - и все это необходимо объединить в единую сеть. Причем не просто объединить, а организовать доступ, разделить полномочия, обеспечить надежность и безопасность. Естественно можно проложить каналы связи, установить маршрутизаторы и устройства доступа - т.е. организовать свою частную сеть, и действительно с построением такой сети практически решена проблема безопасности, доступа к услугам. Предприятие, имеющее такую сеть ни от кого не зависит - ни от операторов, владеющих каналами, ни от производителей. Но везде где есть плюсы, должны быть и минусы. Любое устройство и, тем более, сеть требует технического обслуживания, ремонта и заботы, не говоря уже об усовершенствовании, развитии и контроле. Кроме того, прокладка собственных физических каналов очень дорогостоящее мероприятие, выгоднее воспользоваться существующими каналами, например, арендовать у сервис-провайдеров, с целью организации единой сети. И здесь помогает технология VPN (Virtual Private Network), на основе которой и соединяются все подразделения и филиалы, что обеспечивает достаточную гибкость и одновременно высокую безопасность сети, а также существенную экономию затрат.

В зависимости от того, кто реализует сети VPN, они подразделяются на два вида:

• Поддерживаемая клиентом виртуальная частная сеть(Customer Provided Virtual Private Network, CPVPN). Провайдер предоставляет только «простые» традиционные услуги общедоступной сети по объединению узлов клиента, а специалисты предприятия самостоятельно конфигурируют средства VPN и управляют ими.
• Поддерживаемая поставщиком виртуальной частной сети(Provider Provisioned Virtual Private Network, PPVPN). Поставщик услуг на основе собственной сети воспроизводит частную сеть для каждого своего клиента, изолируя и защищая ее от остальных.

Помимо деления сетей VPN на CPVPN и PPVPN также можно классифицировать в зависимости от места расположения устройств, выполняющих функции VPN.

Виртуальная частная сеть может строиться:

• на базе оборудования, установленного на территории заказчика (Customer Edge based VPN, или CE-based VPN). Оборудование VPN расположено на территории клиента, но поставщик управляет им удаленно, что освобождает специалистов предприятия-клиента от достаточно сложных и специфических обязанностей.
• на базе собственной инфраструктуры поставщика (Provider Edge based VPN, или PE-based VPN). Поставщик управляет расположенным в его сети оборудованием.

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

К недостаткам VPN можно отнести: проблемы защиты данных, недостаток надежности и производительности, а также, отсутствие открытых стандартов затрудняют широкое распространение виртуальных частных сетей.

Разработка единой модели обслуживания виртуальной частной сети могла бы упростить сетевые операции, но такой подход не может удовлетворить различным требованиям клиентов, так как они уникальны. Каждый клиент предъявляет свои требования к безопасности, числу сайтов, сложности маршрутизации, критичным приложениям, моделям и объемам трафика. Для удовлетворения широкого спектра требований, поставщики услуг должны предлагать клиентам разные модели доставки услуг.

Все сети VPN условно можно разделить на три вида:.

1) Intranet VPN (внутрикорпоративные VPN) Представляет собой наиболее простой вариант VPN, он позволяет объединить в единую защищенную сеть несколько распределенных филиалов одной организации, взаимодействующих по открытым каналам связи.

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

3) Remote Access VPN (VPN с удаленным доступом)- позволяет реализовать защищенное взаимодействие между сегментом корпоративной сети (центральным офисом или филиалом) и одиночным пользователем, который подключается к корпоративным ресурсам удаленно.

Технологии, с помощью которых строятся виртуальные частные сети, оказывают существенное влияние на их свойства. Среди технологий построения VPN можно назвать такие технологии, как: IPSec VPN, MPLS VPN, VPN на основе технологий туннелирования PPTP и L2TP. Во всех перечисленных случаях трафик посылается в сеть провайдера по протоколу IP, что позволяет провайдеру оказывать не только услуги VPN, но и различные дополнительные сервисы (контроль за работой клиентской сети, хостинг Web и почтовых служб, хостинг специализированных приложений клиентов).

Виртуальные частные сети на основе MPLS (MPLS VPN) привлекают сегодня всеобщее внимание. Использование MPLS для построения VPN позволяет сервис-провайдерам быстро и экономично создавать защищенные виртуальные частные сети любого размера в единой инфраструктуре. От других способов построения виртуальных частных сетей, подобно VPN на базе ATM/FR или IPSec, MPLS VPN выгодно отличает высокая масштабируемость, возможность автоматического конфигурирования и естественная интеграция с другими сервисами IP.

Сеть MPLS VPN делится на две области: IP-сети клиентов и внутренняя (магистральная) сеть провайдера, которая служит для объединения клиентских сетей. У каждого клиента может быть несколько территориально обособленных сетей IP, каждая из которых в свою очередь может включать несколько подсетей, связанных маршрутизаторами. Такие территориально изолированные сетевые элементы корпоративной сети называются сайтами.

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

Структура MPLS VPN, представленная на рисунке 1, предполагает наличие трех основных компонентов сети:

• Customer Edge Router (CE) - пограничный маршрутизатор клиента;
• Provider Router (P) - внутренний маршрутизатор магистральной сети провайдера;
• Provider Edge Router (PE) - пограничный маршрутизатор сети провайдера.

Рис. 1 Компоненты MPLS VPN

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

Магистральная сеть провайдера является сетью MPLS, где пакеты IP продвигаются на основе не IP-адресов, а локальных меток. Сеть MPLS состоит из маршрутизаторов с коммутацией меток (Label Switch Router, LSR), которые направляют трафик по предварительно проложенным путям с коммутацией меток (Label Switching Path, LSP) в соответствии со значениями меток. Устройство LSR — это своеобразный гибрид маршрутизатора IP и коммутатора, при этом от маршрутизатора IP берется способность определять топологию сети с помощью протоколов маршрутизации и выбирать рациональные пути следования трафика, а от коммутатора — техника продвижения пакетов с использованием меток и локальных таблиц коммутации.

В сети провайдера среди устройств LSR выделяют пограничные маршрутизаторы (Provider Edge router, PE), к которым через маршрутизаторы CE подключаются сайты клиентов и внутренние маршрутизаторы магистральной сети провайдера (Provider router, P).

Маршрутизаторы CE и PE обычно связаны непосредственно физическим каналом, на котором работает какой-либо протокол канального уровня — например, PPP, FR, ATM или Ethernet. Общение между CE и PE идет на основе стандартных протоколов стека TCP/ IP. Каждый PE-маршрутизатор должен поддерживать столько таблиц маршрутизации, сколько сайтов пользователей к нему подсоединено, то есть на одном физическом маршрутизаторе организуется несколько виртуальных. Причем маршрутная информация, касающаяся конкретной VPN, содержится только в PE маршрутизаторах, к которым подсоединены сайты данной VPN. Таким образом решается проблема масштабирования, неизбежно возникающая в случае наличия этой информации во всех маршрутизаторах сети оператора.

Если рассматривать сеть с позиций VPN, то маршрутизаторы провайдера P непосредственно не взаимодействуют с маршрутизаторами заказчика CE, а просто располагаются вдоль туннеля между входным и выходным маршрутизаторами PE.

Маршрутизаторы PE являются функционально более сложными, чем P. На них возлагаются главные задачи по поддержке VPN, а именно разграничение маршрутов и данных, поступающих от разных клиентов. Маршрутизаторы PE служат также оконечными точками путей LSP между сайтами заказчиков, и именно PE назначает метку пакету IP для его транзита через внутреннюю сеть маршрутизаторов P.

Пути LSP могут быть проложены двумя способами: либо с применением технологии ускоренной маршрутизации (IGP) с помощью протоколов LDP, либо на основе технологии Traffic Engineering с помощью протоколов RSVP или CR-LDP.

MPLS VPN сочетает свойства VPN второго и третьего уровней, так как доставка трафика до пограничного устройства сети провайдера осуществляется с помощью протокола IP (третий уровень), а внутри сети провайдера — с помощью MPLS.

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

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

Библиографический список:

1. MPLS на службе VPN. [Электронный ресурс]. -Режим доступа: . http://www.masters.donntu.edu.ua/2011/fkita/shepelenko/library/tez8.htm
2. Сети VPN на базе технологии MPLS. [Электронный ресурс]. -Режим доступа: http://www.lessons-tva.info/archive/nov030.html

Рецензии:

20.02.2014, 17:09 Копылов Алексей Филиппович
Рецензия : Следует указать, откуда взята информация, изложенная в статье - ссылок на литературу нет, откуда взяты картинки - не указано. Так не пойдет. После исправления можно рекомендовать к публикации.