Введение в архитектуру MPLS. Коммутаторы D-Link с поддержкой MPLS для работы в сетях операторов связи

Что касается протокола X.25, то в нем изначально была заложена высокая надежность . Когда X.25 создавался, преобладали аналоговые системы передачи данных и медные линии связи. Стремясь нивелировать невысокое качество каналов того времени, стандарт использует систему обнаружения и коррекции ошибок, что существенно повышает надежность связи, но зато замедляет общую скорость передачи данных. Кроме того, каждый коммутатор , через который проходит пакет информации, выполняет анализ его содержимого, что также требует времени и больших процессорных мощностей. С появлением оптоволоконных сетей столь высокие требования надежности, реализуемые X.25, стали излишними – достоинство протокола превратилось в его недостаток. Скорость передачи по протоколу Х.25 не превышает 64 Кб/с.

Протоколом, призванным исправить недостатки X.25, стал Frame Relay . Он использует тот же принцип виртуальных каналов, однако анализ ошибок осуществляется только на пограничных точках сети, что привело к существенному увеличению скорости (в настоящее время – до 45 Мб/с). Существенным достоинством протокола стала возможность приоритезации разнородного трафика (включая данные, голос и видео), то есть пакетам различных приложений могут предоставляться различные классы обслуживания, благодаря чему пакеты с более высоким приоритетом доставляются "вне очереди". Эти преимущества Frame Relay были развиты при создании технологии асинхронной передачи (АТМ).

Протокол ATM разбивает весь трафик на пакеты строго фиксированной длины (их называют ячейками), которые асинхронно мультиплексируются в единый цифровой тракт в соответствии с присвоенным приоритетом. Благодаря малой длине ячеек (53 байта), можно организовать одновременную передачу потока данных сразу нескольких служб, критичных ко времени доставки – ячейки с данными различных приложений будут вставляться в поток попеременно, обеспечивая каждому приложению необходимую скорость обмена данными. Технология ATM обеспечивает совместный пропуск трафика на скоростях от 1,5 Мб/с до 40 Гб/с. Как Frame Relay , так и ATM обеспечивают высокую степень безопасности - благодаря тому, что весь трафик в магистральной сети не маршрутизируется, а коммутируется на основе локальных меток DLCI (Frame Relay ) или VPI / VCI (АТМ) по виртуальным каналам, к которым несанкционированный пользователь не может подключиться, не изменив таблицы коммутации узлов сети.

Однако, при создании сетей с большим количеством точек доступа по виртуальным каналам, тот самый, "телефонный" принцип соединения, заложенный еще в технологии X.25 начинает доставлять определенные неудобства пользователям. Виртуальные сети ( VPN ) на основе протоколов Frame Relay и ATM становятся слишком громоздкими и трудно управляемыми. Действительно, чтобы обеспечить связь "каждый с каждым" необходимо выполнить операции по конфигурированию каждого канала. Сколько? Количество виртуальных каналов можно посчитать по формуле N*(N – 1)/2, где N – количество точек доступа. Допустим, что у компании 50 подразделений. В таком случае ей придется организовать 2450 двунаправленных каналов или 4900 однонаправленных. То есть при увеличении числа точек доступа вероятность ошибки в конфигурировании сети возрастает в квадратичной прогрессии. Да и стоить такая сеть будет немало, ведь операторы обычно требуют оплату в зависимости от количества каналов. Построение же сети на основе протокола ATM является и само по себе достаточно дорогой технологией, не считая необходимости адаптации оконечного оборудования к ATM . Поэтому сейчас этот протокол используется в основном для предоставления услуг на магистральном уровне, для передачи больших объемов информации.

По данным операторов сетей, до 90% от информации, пересылаемой в сетях Frame Relay и ATM , составляет IP -трафик. Таким образом, абсолютно логичной выглядит идея объединить в одной технологии те преимущества, что дает протокол IP , одновременно предоставляя гарантию качества и надежность протоколов ATM и Frame Relay .

В 1996 году Ipsilon, Cisco, IBM и несколько других компаний объединили свои фирменные разработки и создали технологию многопротокольной коммутации на основе меток (MPLS – Multiprotocol Label Switching ). Основная идея разработки состояла в том, чтобы реализовать возможность передачи трафика по наименее загруженным маршрутам IP -сети и обеспечить легкость конфигурирования VPN с одновременной поддержкой гарантии качества передачи, а также присвоения приоритетов различным видам трафика.

Введение в MPLS

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

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

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

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

• управление трафиком;
• поддержка классов обслуживания (CoS);
• организация виртуальных частных сетей (VPN).

Расположение технологии MPLS в семиуровневой модели ВОС показано на рис. 9.1 .

Рис. 9.1.

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

Мы немного забежали вперед, но теперь, когда стало понятнее какие преимущества дает даже базовый MPLS, мы можем окунуться в понятийный аппарат в мире 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

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.

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

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

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

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

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

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

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

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

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

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

PHP

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

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

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

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

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

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

LDP

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

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

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 - он не использует в своей работе протоколы динамической маршрутизации - по принципу работы он похож на : наводняет всю сеть метками, но при этом он опирается на информацию из таблицы маршрутизации 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-адрес, настроенный на маршрутизаторе.

Далее на нужных интерфейсах даём команду 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

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. Как это решается?

ВиО

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

Если для туннеля задан 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.

Внимание: для каждой ноды CSR1000V требуется 2,5 ГБ RAM. В противном случае образ либо не запустится, либо будут различные проблемы, вроде того, что порты не поднимаются или наблюдаются потери.

Практика VPWS

Наша задача - прокинуть Ethernet от Linkmeup_R1 (порт Gi3) до Linkmeup_R4 (порт Gi3).

На шаге 0 IP-адресация, IGP-маршрутизация и базовый MPLS уже настроены (см. как).



Давайте проследим, что там происходило за кулисами протоколов (дамп снят с интерфейса GE1 Linkmeup_R1). Можно выделить основные вехи:

0) IGP сошёлся, LDP определил соседей, поднял сессию и раздал транспортные метки. Как видите, Linkmeup_R4 выделил транспортную метку 19 для FEC 4.4.4.4.

1) А вот tLDP начал свою работу.

--А. Сначала мы настроили его на Linkmeup_R1 и tLDP начал периодически отправлять свой Hello на адрес 4.4.4.4

Как видите, это юникастовый IP пакет, который отправляется с адреса Loopback-интерфейса 1.1.1.1 на адрес такого же Loopback удалённого PE - 4.4.4.4.

Упакован в UDP и передаётся с одной меткой MPLS - транспортной - 19. Обратите внимание на приоритет - поле EXP - 6 - один из наивысших, поскольку это пакет служебного протокола. Подробнее мы об этом поговорим в выпуске о QoS.

Состояние PW пока в DOWN, потому что с обратной стороны ничего нет.

--Б. После того, как настроили xconnect на стороне Linkmeup_R4 - сразу Hello и установление соединения по TCP.

В этот момент установлено LDP-соседство:

--В. Пошёл обмен метками:

В самом низу можно видеть, что FEC в случае VPWS - это VC ID, который мы указали в команде xconnect - это идентификатор нашего VPN - 127 .

А чуть ниже выделенная ему Linkmeup_R4 метка - 0х16 или 22 в десятичной системе.

То есть этим сообщением Linkmeup_R4 сообщил Linkmeup_R1, мол, если ты хочешь передать кадр в VPN с VCID 127, то используй сервисную метку 22.

Тут же вы можете видеть ещё кучу других сообщений Label Mapping - это LDP делится всем, что нажил - информацией про все FEC. Нас это мало интересует, ну а Lilnkmeup_R1 и подавно.

После этого поднимаются VC и мы можем увидеть метки и текущие статусы:

Команды и show l2vpn atom vc detail в целом идентичны для наших примеров.

3) Теперь всё готово для передачи пользовательских данных. В этот момент мы запускаем ping. Всё предсказуемо просто: две метки, которые мы уже видели выше.

Почему-то Wireshark не разобрал внутренности MPLS, но я вам покажу, как прочитать вложение:

Два блока, выделенных, красным - это MAC-адреса. DMAC и SMAC соответственно. Жёлтый блок 0800 - поле Ethertype заголовка Ethernet - значит внутри IP.

Теперь вы можете в Wireshark!

Если VPWS - это просто провод, то он должен спокойно передать и кадр с меткой VLAN? Да, и нам для этого не придётся ничего перенастраивать. Вот пример кадра с меткой VLAN:

Здесь вы видите Ethertype 8100 - 802.1q и метку VLAN 0x3F, или 63 в десятичной системе.

Если мы перенесём конфигурацию xconnect на сабинтерфейс с указанием VLAN, то он будет терминировать данный VLAN и отправлять в PW кадр без заголовка 802.1q.

Виды VPWS

Итак, VPWS - общее название решений для L2VPN вида точка-точка.

PW - это виртуальный L2-канал, который лежит в основе любой технологии L2VPN и служит туннелем для передачи данных.

VLL (Virtual Leased Line) - это уже технология, которая позволяет инкапсулировать кадры различных протоколов канального уровня в MPLS и передавать их через сеть провайдера.

Выделяют следующие виды VLL:

VLL CCC - Circuit Cross Connect . В этом случает нет метки VPN, а транспортные назначаются вручную (статический LSP) на каждом узле, включая правила swap. То есть в стеке будет всегда только одна метка, а каждый такой LSP может нести трафик только одного VC. Ни разу не встречал его в жизни. Главное его достоинство - он может обеспечить связность двух узлов, подключенных к одному PE.

VLL TCC - Translational Cross Connect . То же, что CCC, но позволяет с разных концов использовать разные протоколы канального уровня.

Работает это только с IPv4. PE при получении удаляет заголовок канального уровня, а при передаче в AC-интерфейс вставляет новый.

VLL SVC - Static Virtual Circuit . Транспортный LSP строится обычными механизмами (LDP или RSVP-TE), а сервисная метка VPN назначается вручную. tLDP в этом случае не нужен. Не может обеспечить локальную связность (если два узла подключены к одному PE).

Martini VLL - это примерно то, с чем мы имели дело выше. Транспортный LSP строится обычным образом, метки VPN распределяются tLDP. Красота! Не поддерживает локальную связность.

Kompella VLL - Транспортный LSP обычным образом, для распределения меток VPN - BGP (как и полагается, с RD/RT). Уау! Поддерживает локальную связность. Ну и ладно.

Коротко его отличия от Martini VLL можно представить так:

• Сообщает статус PW, используя сообщение LDP Notification.
• Поддерживает Multi-Segment PW, когда end-to-end канал состоит из нескольких более мелких кусков. В этом случае один и тот же PW может стать сегментов для нескольких каналов.
• Поддерживает TDM-интерфейсы.
• Предоставляет механизм согласования фрагментации.
• Другие...

Я тут везде говорю об Ethernet для того, чтобы показать наиболее наглядный пример. Всё, что касается других канальных протоколов, это, пожалуйста, на самостоятельное изучение.

VPLS. Point-to-Multipoint

VPLS - Virtual Private LAN Service. По своей сути - это коммутатор. Провайдер подключает несколько точек заказчика к своей сети в разных её концах и обеспечивает L2 связность. И теперь это задача транспортной сети провайдера - заботиться о правильной коммутации кадров, то есть изучении MAC-адресов.

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

VSI - Virtual Switching Instance . Виртуальный коммутатор в пределах одного узла.

Для каждого клиента (или сервиса) он свой. То есть трафик разных VSI не может кочевать из одного в другой.

В терминах Cisco это VFI - Virtual Forwarding Instance . Я позволю себе вольно обращаться с терминами VPLS-домен, VSI и VFI, иногда используя их как синонимы.
VE - VPLS Edge - узел PE, участник VPLS-домена.

VPLS Data Plane

1. На AC-порт PE-маршрутизатора пришёл пользовательский кадр.
2. PE-маршрутизатор смотрит в заголовок Ethernet и проверяет MAC-адрес отправителя.
   А) Если он уже есть в таблице MAC-ов данного VSI, PE сразу переходит к шагу 3.
   Б) Если этого адреса ещё нет - он записывает соответствие MAC-порт в таблицу и тоже переходит к шагу 3.
3. PE-маршрутизатор смотрит в заголовок Ethernet и проверяет MAC-адрес получателя.

   А) если таковой присутствует в таблице MAC-адресов данного VSI:

   1. PE ищет выходной интерфейс для кадра с данным MAC"ом. Это может быть физический интерфейс или PW.
   2. Если порт назначения - физический интерфейс - просто отправляет в этот порт.
      Если это PW, то добавляет соответствующую метку - сервисную. Эта метка будет неизменна до конца пути.
   3. PW - это всегда канал между двумя IP-узлами, поэтому зная IP-адрес удалённого PE, локальный PE из таблицы меток извлекает транспортную и ставит её сверху стека - она будет меняться на каждом P-маршрутизаторе.

   Б) Если же MAC-адрес неизвестен, то как порядочный коммутатор наш PE должен выполнить широковещательную рассылку кадра по всем PE данного VSI. И он делает, подлец.

   1. Локальный PE составляет список всех удалённых PE этого VSI, и, создав копии этого кадра, вставляет в них сервисные метки - каждому своя.
   2. Далее на каждую копию кадра навешивается ещё и транспортная метка (тоже своя для каждого PE).
   3. Весь этот ворох кадров рассылается по сети провайдера.
   4. Также копии широковещательного кадра отправляются в AC-интерфейсы, если такие есть, без заголовков MPLS.
4. Удалённый PE после получения кадра и снятия меток (то есть когда уже определил VSI) тоже действует как обычный коммутатор:

   А) Если MAC-адрес источника пока не известен, вносит его в таблицу. В качестве входного интерфейса будет указан PW к Ingress PE.
   Б) Если MAC-адрес назначения ему известен, отсылает кадр в тот порт, за которым он изучен. Отсылается уже чистый Ethernet-кадр, без каких-либо заголовков MPLS.
   В) Если этот MAC не удалось найти в таблице? Широковещательная рассылка по всем AC-портам этого VSI. Заметьте, PE не будет рассылать этот кадр в PW данного VSI , потому что все другие PE уже получили копию этого кадра от входного PE. Это всё то же правило расщепления горизонта (Split Horizon), и так достигается отсутствие петель коммутации и широковещательных штормов. (Ах, если бы всё было так просто...)

Как и в обычном коммутаторе записи в MAC-таблице VSI периодически протухают и удаляются.

В вопросе изучения MAC-адресов в VPLS есть один нюанс, который резко отличает его от L3VPN. PE должен не просто знать физический порт, откуда пришёл кадр - важно определить соседа или, точнее PW как виртуальный интерфейс. Дело в том, что клиентский кадр нужно отправить не просто в какой-то физический порт, а именно в правильный PW, иными словами, правильному соседу.

Для этой цели каждому соседу выдаётся личная метка, с которой тот будет отправлять кадр этому PE в данном VPLS-домене. И в дальнейшем по VPN-метке, заглянув в LFIB, PE узнает, от какого соседа пришёл кадр.

Напомню, что L3VPN без разницы, откуда пришёл IP-пакет, поэтому для префикса в VRF всем соседям сообщается одна и та же метка.

Схема доставки пользовательского трафика незамысловата. Но что же с пресловутым Control Plane"ом? Опять придётся поломать мозги или малыми жертвами?

VPLS Control Plane

Поэтому один из главных вопросов в VPLS - обнаружение всех PE, куда подключены клиенты данного VSI. Существует здесь два подхода: ручная настройка и автоматическое обнаружение . Первый путь изначально предложила Cisco (драфт Мартини), отцом второго является Juniper (драфт Компелла).

11 выпусков СДСМ пропагандировал упрощение жизни инженера и автоматизацию всего и вся. И вот, настал тот момент, когда нужно забыть всё, чему вас учили. Это первый случай (если не поднимать холивар вокруг VTP), когда решение с ручной настройкой соседей оказывается более популярным.
Стало интересно?

Прежде чем приоткроем кулисы, хочу сделать замечание: независимо от того, что мы вытворяем с VPN-метками, транспортные LSP строятся как обычно LDP или RSVP-TE. Поэтому далее касаться транспорта мы будем только вскользь.

Точно также, независимо от используемого режима, VPLS при более детальном рассмотрении разваливается на point-to-point PW. То есть мы имеем не некое централизованное облако коммутации, а просто набор виртуальных линий между всем соседями. Решение о передаче кадра принимает Ingress PE или, проще говоря, выбирает нужный PW.

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

На данный момент draft-martini переродился в RFC 4447 - Интернет-стандарт про PWE3, а драфт-Компелла устарел и умер.
Если же говорить именно о VPLS, то тут есть два стандарта:

“Virtual Private LAN Service (VPLS) Using BGP for Auto-discovery and Signaling”. RFC 4761 .
“Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling” RFC 4762 .
Историческая справка по методам.

VPLS Martini Mode (LDP)

• Простота внедрения (очевидное требование)
• На существующем железе (протоколы не должны требовать аппаратной доработки)
• Поддержка уже функционирующих протоколов на сетях операторов.
• Принцип работы нового механизма не должна кардинально отличаться от существующих моделей.

Для сигнализации меток будет использоваться LDP, который уже является частью MPLS. VPLS Martini Mode описан в стандарте RFC4762 .

Именно это лаконичное решение и стало стандартом де факто в большинстве сетей по всему миру. С тем, как работает Martini-mode мы уже познакомились в части про VPWS. Ровно то же самое и здесь, только удалённые LDP сессии создаются для каждого VSI не с одним соседом, а с несколькими.

LDP используется для распределения сервисных меток. Удалённые сессии с каждым соседом в VPLS-домене настраиваются вручную. Поскольку заранее известны все участники этого VPLS, каждому из них LDP выделяет индивидуальную метку в сообщении LDP Label Mapping Message.

Если добавляется новый PE в VPLS-домен, необходимо настроить LDP-соседство со всеми существующими PE этого VPLS. После чего с каждым из них новый PE обменятся метками.

В течение всего времени, LDP проверяет доступность своих соседей. Если какой-то из соседей выходит из группы или становится недоступным, сессия разрывается и все изученные MAC"и в PW к этому соседу очищаются.

Если состояние какого-либо из AC-портов VPLS-домена переходит в состояние Down, либо происходит другое событие, заставляющее очистить MAC-адреса с AC-порта, то PE сообщает об этом всем своим соседям, настаивая на удалении MAC-адресов в сообщении LDP MAC Withdraw (К сожалению CSR1000V на тестовом стенде этого не делает).

Известны случаи, когда в случае изменения состояния AC-порта, PE отправляет сообщение LDP MAC withdraw без уточнения, какие именно MAC"и. Это означает, что каждый сосед должен очистить всю таблицу MAC-адресов данного VPLS-домена.

Теперь представьте, что счёт идёт на сотни, возможно, тысячи записей. И по всей сети все PE начинают изучать MAC-адреса. А что они делают с кадром, когда не находят MAC получателя? Рассылают всем. Возникает кратковременный широковещательный шторм без петли коммутации.

Пока без петли. Ирония в том, что такой взрыв броадкаста можно забить каналы передач данных, особенно узкие, например, РРЛ. И тогда начнут теряться пользовательские данные. А если забьются очереди приоритетного трафика CS6-CS7, в котором передаются пакеты протоколов, то и STP может поломаться и ERPS сомкнуть кольцо - и образуется вполне себе реальная петля коммутации с нарастающим эффектом.

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

Теперь нам нужно связать сервисы на AC-интерфейсах (service instance) с VFI. Для этого нам понадобятся bridge-domain.

Linkmeup_R1(config)#bridge-domain 255 Linkmeup_R1(config-bdomain)# member vfi Blue Linkmeup_R1(config-bdomain)# member gigabitEthernet 3 service-instance 10 Linkmeup_R1(config-bdomain)# member gigabitEthernet 4 service-instance 12
Цифра 255 в общем-то произвольная (0-4096). Может выбираться в соответствии с клиентским VLAN, например. Строго локальный для устройства и никуда не передаётся.

Команда member позволяет к bridge-domain привязать различные сервисы. Первой командой подключаем VFI, двумя другими AC-интерфейсы - теперь все они в одном широковещательном домене.

Хочу знать больше про Bridge-domain...

Bridge-domain это что-то вроде виртуального коммутатора в пределах одного устройства. Если вы привяжете к одному brdige-domain пару физических интерфейсов, то они окажутся в одном широковещательном сегменте. Похоже на VLAN, но более гибкое. То есть, дословно переводя, это L2-мостик между двумя сущностями. В нашем случае между физическим интерфейсом и VPLS.

Конфигурация других PE...

Linkmeup_R3
Linkmeup_R3(config)#interface gigabitEthernet 3 Linkmeup_R3(config-if)#service instance 13 ethernet Linkmeup_R3(config-if-srv)#description Blue-D Linkmeup_R3(config-if-srv)#encapsulation default
Linkmeup_R3(config)#bridge-domain 255 Linkmeup_R3(config-bdomain)# member vfi Blue Linkmeup_R3(config-bdomain)# member gigabitEthernet 3 service-instance 13

Linkmeup_R4
Linkmeup_R4(config)#interface gigabitEthernet 3 Linkmeup_R4(config-if)#service instance 11 ethernet Linkmeup_R4(config-if-srv)#description Blue-B Linkmeup_R4(config-if-srv)#encapsulation default
Linkmeup_R4(config)#bridge-domain 255 Linkmeup_R4(config-bdomain)# member vfi Blue Linkmeup_R4(config-bdomain)# member gigabitEthernet 3 service-instance 11

На этом настройка VPLS Martini Mode закончена.
Файл конфигурации VPLS Martini Mode .

На некотором оборудовании существует два способа настройки VPLS Martini Mode. Другой сейчас считается устаревшим, но допустимым. Вместо команды l2vpn vfi context Blue используется l2 vfi Blue . Главным образом разница заключается в том, что member меняется на neighbor , а привязка к Bridge-domain делается не в секции bridge-domain, а в собственно секции vfi или на интерфейсе в режиме настройки Service instance.

Подробнее вы можете посмотреть в альтернативном фaйле конфигурации VPLS Martini Mode .

Что произошло?

1. Сразу после этого устанавливаются соединения LDP и происходит обмен метками. Технически LDP достаточно привязки к bridge-domain - не обязательно, чтобы были AC-интерфейсы (это поведение зависит от производителя.).

Вот обмен между Linkmeup_R1 и Linkmeup_R3:

FEC 63 - номер нашего VPN. Метка выделена 0x18 (или 24).

То есть, когда Linkmeup_R3 будет отправлять кадры в этом VFI AC-интерфейсу, подключенному к Linkmeup_R1, он должен добавить VPN-метку 24. А транспортная при этом - 17.

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

2. Если запустить пинг с Blue-A, то в дампе (на интерфейсе Gi1 Linkmeup_R1) можно увидеть сначала ARP-запрос:

Поскольку он широковещательный, то следом за ним можно увидеть его точную копию с одной лишь разницей - метки VPN и транспортная:

Один кадр был отправлен на Linkmeup_R3, другой - на Linkmeup_R4.

3. В таблице MACов видим MAC-адрес узла Blue-A (AABB-CC00-0700) - он находится за портом GE3.EFP10 (Ethernet Flow Point и Service instance 10 ) - и MAC, соответствующий IP-адресу 192.168.0.2 (AABB-CC00-0300) - за интерфейсом Pseudoport Blue.100401a .

К сожалению, установить зависимость между Pseudoport и pseudowire мне так и не удалось. Как инженеру определить, с какого PW изучается MAC-адрес? Например show l2vpn vfi показывает очевидное соответствие, но эти имена никак не перекликаются.

Если кому-то удастся проследить связь между Pseudoport и pseudowire, эта статья станет чуточку полнее.

Естественно, это всё строго локально. Как и обычные коммутаторы - VPLS не сигнализирует MAC"и другим PE, а занимается их изучением исключительно в рамках Data Plane.

Ещё раз шаги настройки:

1. Создать VFI, с одинаковым VPN ID на всех PE и настроить связность со всеми соседями.
2. Привязать AC-интерфейсы к Service Instance.
3. Связать VFI и Service Instance с помощью Bridge-domain.

Итак подытожим про Martini mode:

VPLS Kompella Mode (BGP)

Проблему поиска соседей решил Кирити Компелла - сотрудник Juniper. Он отталкивался от тех же критериев, но решил, что MBGP , опробованный на L3VPN, подойдёт лучше на роль протокола распределения меток.

Схема обмена маршрутной информацией, однажды расширенная до VPNv4 маршрутов, вполне может быть применена и для доставкой меток VPLS. Механизм Route Target поможет с автоопределением соседей. А рут-рефлекторы решат задачу реализации полносвязной топологии, которая остро стоит в Martini Mode.

Другое название VPLS Kompella-mode - VPLS Auto-Discovery, потому что именно это является его качественным отличием от Martini. Также вы можете услышать VPLS BGP Signaling.

Control Plane выполняет здесь две основные функции:

Обнаружение соседей
- Передача маршрутной информации и обмен метками.

Обнаружение соседей или Auto-Discovery

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

Route Target, который является Extended Community - главный признак принадлежности к определённому VSI. Грубо говоря - если RT совпадают - значит в одном VSI.

Строго говоря: Если RT полученного анонса совпадает с настроенным в VSI, значит этот VSI хочет знать информацию из анонса.

Как и в L3VPN можно гибко организовать взаимодействие между различными VSI. Но так крайне редко кто делает.

Чуть подробнее

Каждый VSI имеет свой RT.

В секции BGP для VPLS есть своя Address Family: L2VPN AFI (25) и VPLS SAFI (65)
В ней настраивается соседство с абсолютно всеми PE, которые могут участвовать в каком-либо VPLS-домене. Заметьте, здесь без привязки к конкретному VSI.

Если используются RR, то соседство поднимается только с ними.

Когда BGP хочет сообщить L2-префикс всем PE данного VSI, он высылает BGP Update всем настроенным здесь соседям, опять же независимо от того, хотят они получать данный префикс или нет. Здесь всё так же, как в L3VPN - там vpnv4-префиксы тоже рассылаются всем PE.

Когда удалённый PE получает этот BGP Update, он проверяет RT в поле NLRI и сравнивает с теми, которые настроены в его VSI.

Если совпадение найдено, PE импортирует этот префикс в нужный VSI. Если нет - отбрасывает.
Вот так и реализован Auto-Discovery.

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

Передача префиксов

В целом префикс L2VPN - вещь довольно искусственная - PE своим BGP Update, скорее, сообщает сам факт своего участия в VPLS-домене и метку этого факта. Но это не играет большой роли.

Какого-то адреса, тем более MAC"а, в поле NLRI сообщения BGP Update VPLS не передаёт. Помните, что изучение MAC-адресов - это полностью функция Data Plane .

Однако различать анонсы разных VSI всё равно нужно, поэтому знакомый нам Route Distinguisher тоже присутствует. Обычно он составляет автоматически из номера AS и VPN ID.

Однако что-же передаётся в NLRI? Только метка и RD? Не совсем:

Формально, префикс - это RD+порядковый номер узла в VPLS-домене+блок меток .

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

Помните фразу "Хочешь накормить человека один раз - дай ему рыбу. Хочешь накормить его на всю жизнь - дай ему удочку "? Для выделения меток в VPLS Kompella mode используется механизм блоков меток. Один PE другому не сообщает точное значение - он даёт ему информацию для её вычисления.

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

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

Если не вдаваться в конфигурацию, то выглядит это так:

1. В каждом VSI настраивается RD и RT - их функции ровно те же самые, что в L3VPN. На CSR1000V это происходит автоматически, не требуя ручной настройки. RD позволяет разделять информацию разных VSI при передаче. RT позволяет маршрутизатору-получателю определить, в какой VSI нужно эту информацию транслировать. RD и RT позже будут передаваться в сообщении BGP Update.
2. В секции BGP настраивается новая адрес-фэмили L2VPN VPLS, внутри которой поднимается соседство со всеми PE.
   Вообще-то нужно создать полносвязную топологию соседства. Но мы же помним, что механизм Route-Reflector"ов позволяет обойти это требований, установив соседство только с одним RR (или несколькими в случае кластера RR)?
3. Под каждый VSI PE-маршрутизатор выделяет блок из пространства меток. И вот тут-то и начинается интересное. В BGP Update от локального PE удалённому передаётся следующая информация:
   • Порядковый номер узла в VPLS-домене.
   • Блок меток MPLS
     • VE ID
     • VE Block Offset
     • VE Block Size
     • Label Base

Напомню, что VE - VPLS Edge - граница сети VPLS - PE-маршрутизатор на котором запущен VPLS.

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

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

Когда на PE приходит L2VPN кадр со стороны MPLS сети, нужно точно знать, от какого он соседа - это нужно, чтобы изучить MAC-адрес, поэтому как и в случае с режимом Martini основная идея заключается в том, что PE каждому соседу в конкретном VSI должен сообщить уникальную метку, чтобы видеть, от кого пришёл кадр.

Вот на такой простой картинке посмотрим поподробнее:

Пусть R1 за главного.

0. В Kompella mode R1 не передаёт метку в явном виде своим соседям R2 и R3.
1. Вместо этого он им сообщает из какого диапазона нужно метки выбирать, чтобы идентифицировать данный VC.
2. У каждого РЕ есть свой порядковый номер n в VPLS-домене. Зная свой номер и диапазон меток, соседи вычисляют исходящую сервисную метку: отсчитывают n-ую по счёту с начала. То есть R2 взял вторую (2), а R3 - третью (3).
3. R2 и R3 сообщают свои номера R1, и он тоже вычисляет, какая входящая сервисная метка будет от R2, какая от R3, отсчитывая от начала диапазона 2 и 3.
4. Аналогично свои собственные диапазоны определяют R2 и R3 и сообщают их друг другу и R1. И цикл вычислений повторяется.
5. В конце концов все будут знать и исходящие метки для данного VPLS и входящие.

Теперь вторая итерация : поглубже копнём, какой матан лежит под этой простой идеей.

VE ID настраивается вручную - это идентификатор PE-маршрутизатора в домене VPLS (его порядковый номер). Должен быть уникален в пределах одного VSI.

LB - Label Base - это начало диапазона, первая метка, которая может быть использована.
VBS - VE Block Size - это длина блока меток - или проще, минимальное количество меток в этом VSI. Для Cisco по умолчанию это 10. Для Juniper - 8 (может быть уменьшен до 2 или увеличен).

Вот как будет выглядеть набор меток: {LB, LB+1, .., LB+VBS-1}.

В целом, схема простая:

VE ID 100-109 взяты от балды для примера

На этой анимации показан процесс распределения меток на PE1: Если PEX хочет отправлять трафик на PE1, он должен использовать соответствующую метку X .

Вот ещё пример для PE5:

Метки выделяются по порядку - первая из блока - соседу с наименьшим VE-ID. Вторая - второму по величине итд.
То есть такая ситуация невозможна :

Однако если выделенного количества меток мало, то поможет параметр VBO - VE Block Offset - смещение блока. Он позволяет создать несколько блоков. И тем соседям, кому не хватило, метки распределяются по тому же принципу, но из нового блока, с новым LB.

Необходимый VBO вычисляется по формуле: VBO = ЦЕЛОЕ(VE-ID/VBS)*VBS.

Хочется заметить, что VBO - это не про смещение меток, это про диапазон, в который попадает порядковый номер VE. Если попал в первый диапазон - берётся первый блок меток, если во второй - то второй итд.

Таким образом в случае использования нескольких блоков, набор меток будет выглядеть так же, как и прежде {LB, LB+1,… LB+VBS-1}, но LB при этом зависит от VBO. То есть у нас связка

То есть имеем строгое соответствие: узлу с VE ID (VBO+n) соответствует метка (LB+n).

Третья итерация - на реальном примере.

Возьмём клиента с десятью сайтами. VBS у нас стандартный - 10. VE-ID соответствуют номеру маршрутизатора: PE1 - 101, PE2-102,… PE 10 - 110. Рассмотрим как будут взаимодействовать PE1 и PE5.

1. PE1 выбирает в качестве Label Base 1000 - то есть 1000-1009 - это блок меток, из которого его соседи смогут взять себе по одной.

2. PE1 вычисляет VBO. VBO=ЦЕЛОЕ(101/10)*10=100 .

3. PE1 передаёт собирает все данные в BGP Update всем своим соседям: LB: 1000, VBS:10, VBO:100, VE-ID:101 . Ну и всякие RD, RT, которые нам сейчас не интересны. Сам PE1 пока никаких меток не считает - он ждёт Update от соседей.

4. BGP Update от PE1 достигает PE5. Его VE-ID: 105 . И сейчас ему нужно вычислить исходящую метку для данного VSI (чей RT указан так же в BGP Update)в сторону PE1.

5. Первое, что делает PE5 - проверяет, а умещается ли он в блок, анонсированный PE1. Вот здесь и понадобится VBO. Должно выполниться неравенство VBO ≤ PE5 VE-ID ≤ VBO+VBS-1. И оно выполняется 100≤105≤109. Поясню. PE1 вычислил, что его ID в диапазоне 100-109 (со смещением 100 и длиной 10) - соответственно все узлы с VE ID из этого набора будут выбирать метку из первого блока.

6. Итак PE5 в пределах анонсируемого диапазона, поэтому он может идти дальше и вычислить свою исходящую метку по формуле 1005 . Ещё раз вся эта арифметика, означает, что от LB нужно отсчитать столько меток, каким по счёту идёт VE-ID от VBO. Значит, PE5, чтобы отправить L2 кадр данного VSI на PE1 вставит в MPLS-заголовок VPN-метку 1005. PE1 пока не знает, про метку 1005 - ему предстоит её вычислить, как это сделал PE5. А для этого нужно узнать его VE ID.

7. Теперь PE5 тоже должен отправить BGP Update всем соседям (технически, не надо дожидаться 7 шага - такую последовательность я взял для примера. PE5 отправляет свой BGP Update как только всё было настроено).

• а. Выбрал LB , например, 5000 .
• б. Вычислил VBO = RND(105/10)*10=100 .
• в. Скомпоновал BGP Update. LB: 5000, VBS:10, VBO:100, VE-ID: 105 .
• г. Отправил его всем PE.

8. Когда PE1 узнал VE-ID соседа (из BGP Update), он может посчитать входящую метку для данного соседа и VSI. И он делает то же самое:

• а. Проверяет неравенство по полученным VBO И VBS: VBO ≤ PE1 VE-ID ≤ VBO+VBS. 100≤101≤109. Отлично.
• б. Вычисляет входящую метку: (PE1 LB + PE5 VE-ID - VBO) = (1000 + 105 - 100) = 1005 - то же самое число, что посчитал и PE5 для исходящей метки. То есть когда PE1 получит кадр с меткой VPN 1005, он будет знать сразу и то, какому VPN он предназначен и от какого соседа пришёл, то есть как изучить его MAC, если необходимо.

9. Но это ещё не всё. PE1 должен теперь вычислить и исходящую метку к PE5. И все данные у него для этого имеются.

5001 . То есть PE1 при отправке кадров в этот VSI к PE5 вставит в них VPN-метку 5001.

10. PE5 вычисляет входящую: (PE5 LB + PE1 VE-ID - VBO) = (5000 + 101 - 100) = 5001 .

Вот это я называю взаимовыручкой!

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

Если вы ещё не эволюционировали до понимания механизма Label Block, вернитесь к .

Интересна судьба PE10, которая окажет своё влияние на жизни всех других PE. Дело в том, что он не укладывается в блок 100-109 со своим VE ID 110 . Его VBO будет 110=ЦЕЛОЕ(110/10)*10 . А в качестве LB он выбрал 10000 .

Когда PE10 пришлёт результаты своих калькуляций PE5, неравенство не выполнится: 110 ≤ 105 ≤ 119.
В этом случае запускается процесс выделения нового блока.

1. PE5 выбирает новый LB 5030 , VBS уже выбран PE10 - 10 .
2. Имея уже данные от PE10,

• А. PE5 вычисляет исходящую метку к PE10: (PE10 LB + PE5 VE-ID - PE5 VBO) = 5 - 100) = 10005 . Обратите внимание, что отнимается локальный VBO .
• Б. Вычисляет входящую метку от PE10: (PE5 New LB + PE10 VE-ID - PE10 VBO) = (5030 + 110 - 110) = 5030 . Используется новый LB и VBO PE10.

3. PE5 высылает PE10 новый BGP Update, анонсируя уже два префикса: первый - старый, а второй - LB: 5030, VE ID: 105, VBS:10, VBO:110 .
4. VE-ID PE10 в этот раз входит в новый диапазон 110-119,

• А. поэтому он может вычислить исходящую метку: (PE5 LB + PE10 VE-ID - PE10 VBO) = (5030 + 110 - 110) = 5030 . То есть PE10 при отправке кадра этого VSI на PE5 должен вставить VPN-метку 5030.
• Б. Может он вычислить и входящую от PE5: (PE10 LB + PE5 VE-ID - PE5 VBO) = (10000 + 105 - 100) = 10005 . Здесь он использует тот VBO, в который входит PE5, а не PE10.

5. Каждый PE должен будет выделить по второму блоку меток, чтобы общаться с PE10. Вычисления продолжаются.

Скрупулёзное объяснение механизма Label Block от виновников: Juniper .

И в этот момент должно стать жутко. Во-первых мы только что потеряли 10 меток на КАЖДОМ PE (9 не использовано из второго блока и одна метка из первого - которая для самого этого PE). Во-вторых, от того, как мы назначим VE-ID, зависит, насколько рационально будут использованы метки. В-третьих, мы должны своими собственными руками настроить VE-ID и VE-range! Вот этими вот руками, которыми мы MPLS поднимали в пару команд!

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

Знаете, что по этому поводу, говорит RFC 4761 ?

Using a distinct BGP Update message to send a demultiplexor to each
remote PE would require the originating PE to send N such messages
for N remote PEs. The solution described in this document allows a
PE to send a single (common) Update message that contains
demultiplexors for all the remote PEs, instead of N individual
messages. Doing this reduces the control plane load both on the
originating PE as well as on the BGP Route Reflectors that may be
involved in distributing this Update to other PEs.

Не очень понятно, какие там нагрузки на Control Plane.

Как это водится в СДСМ, дальше вы читаете эксклюзив. Причём на этот раз, вероятно, не только рунетовского уровня, но и вообще во всём Интернете я не нашёл адекватного пояснения, зачем эта система блоков была изобретена. Не смейтесь сильно, но я даже писал Компелле, когда ни один из окружающих меня CCIE не ответил на этот вопрос .

Всё это из-за столь желанной функции Auto-discovery (про которую уже было выше) и специфики L2, а именно изучения MAC-адресов. И всё будет понятнее в сравнении с L3VPN, где про назначения блока меток никто даже не думал.

Итак, как работает Auto-Discovery в L3VPN? Некоторый PE страждет рассказать всему миру о двух вещах - во-первых, о том, какие префиксы он знает, во-вторых о том, кому они предназначены. И он хочет рассказать об этом всем сразу без разбора - все, кто являются его MBGP соседями получат его Update, а по RT поймут, интересны ли им эти анонсы. На нет - и суда нет - отбросят. А если интересны, то в свою таблицу маршрутизации VPN занесут полученный префикс и его VPN-метку.

Всё то же самое верно и для L2VPN. За исключением одного: изучения MAC-адресов . BGP в L3VPN сообщает всем одну и ту же метку - ему совершенно без разницы, откуда потом придёт пакет с данными, главная его забота - передать его в правильный клиентский интерфейс.

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

И здесь-то и кроется дьявол. В BGP Auto-Discovery происходит в тот же момент, что и анонс префикса .

И, во-первых, совершенно не в духе BGP будет, если сначала отсылать пустой Update с целью поиска всех участников VPLS-домена, а потом отдельно то же самое, но с конкретными метками каждому из них.

И даже, если вы приемлете «во-первых» (Фуфуфу), появляется, «во-вторых». Во-вторых, анонс конкретных меток найденным соседям. Хорошо , когда нет RR, и один PE может отправить другому Update адресно. Тогда каждый PE получит только своё сообщение и только свою метку. Но реальность такова, что RR стали её (реальности) частью и, имея соседство только с RR, PE шлёт Update ему, а тот рассылает всем своим клиентам. А если PE шлёт несколько Update"ов, то все они разлетятся по всем. Получается, что каждый его сосед получит не только свою метку, но и все остальные, которые ему даром не сдались.

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

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

И знаете, пока эта концепция блока меток не сформировалась в непротиворечивый набор синапсов в моём мозге, я с пренебрежением относился к ней. Она казалась мне топорной и устаревшей. Примерно, как DVMRP . Но теперь я проникся идеей и даже несколько удивлён тому, что внятного объяснения нигде нет.

Замечу также, что ситуацию с потерянными метками несколько пересмотрели с выпуском RFC 6624 (в котором, кстати, Компелла тоже принял непосредственное участие):

Label blocks and label values are managed by the PEs. As sites get
added and removed, labels are allocated and released. The easiest
way to manage these is to use fixed-size label blocks rather than
variable-size blocks, although the signaling described here supports
either. If an implementation uses fixed-size blocks, then allocating
a label for a new site may requiring allocating a new block;
similarly, freeing a label may require freeing a block.
If the implementation requires fixed-size blocks, there is probably a
default block size, but the implementation SHOULD allow the
administrator to choose a size. Larger label block sizes mean more
potential «wasted» labels but less signaling overhead, a trade-off
that the administrator might want to control.

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

Практика VPLS Kompella (BGP Signalling)

Остаёмся с той же сетью:

Предыдущая конфигурация снова очищается до начальной.
Файл начальной конфигурации.

1. Создаём VFI, как это делали в режиме Martini:

   Linkmeup_R1(config)#l2vpn vfi context Blue Linkmeup_R1(config-vfi)#vpn id 63 Linkmeup_R1(config-vfi)#autodiscovery bgp signaling bgp Linkmeup_R1(config-vfi-autodiscovery)#ve id 101
   Этот способ позволяет настроить три типа VFI: ручной Martini с настройкой соседей. BGP Autodiscovery + BGP Signalling , либо BGP Autodiscovery + LDP Signalling . В нашем случае мы выбрали оба - BGP.

   Опционально мы можем задать количество членов VPLS-домена. В cisco по умолчанию - 10. Командой ve range Х можно увеличить от 11 до 100 (но не уменьшить). Huawei - по умолчанию 10, можно изменять (1-16000). Juniper - по умолчанию 8, можно изменять (2,4,8, 16...)

   Route Distinguisher и Route Target мы можем не настраивать - они будут назначены автоматически. Разве что вам хочется странного - объединить в один домен разные VFI.

   Далее я даю команду mpls label range 1000 1999 . Она глобально задаёт диапазон динамически используемых меток. Вообще говоря этого делать не нужно, поскольку так всем приложениям MPLS (LDP, TE, BGP) мы указываем, какие метки выбирать, а я не люблю кому-то что-то указывать. Но я делаю это для более наглядной иллюстрации вычисления меток.

   Linkmeup_R1(config)#mpls label range 1000 1999 Label range change will cause 5 labels in the old dynamic range to go out of range
   Предупреждение говорит как раз о том, что распределённые прежде транспортные метки не укладываются в новый диапазон.

2. Привязываем интерфейсы к Service Instance:

   Linkmeup_R1(config)#interface gigabitEthernet 3 Linkmeup_R1(config-if)#service instance 10 ethernet Linkmeup_R1(config-if-srv)#description Blue-A Linkmeup_R1(config-if-srv)#encapsulation default Linkmeup_R1(config)#interface gigabitEthernet 4 Linkmeup_R1(config-if)#service instance 12 ethernet Linkmeup_R1(config-if-srv)#description Blue-C Linkmeup_R1(config-if-srv)#encapsulation default

3. Связываем VFI и Service Instance.

   Linkmeup_R3(config)#bridge-domain 255 Linkmeup_R1(config-bdomain)#member vfi Blue Linkmeup_R1(config-bdomain)#member gigabitEthernet 3 service-instance 10 Linkmeup_R1(config-bdomain)#member gigabitEthernet 4 service-instance 12

4. Ну что же, дело осталось за малым - BGP.

   Сначала поднимаем базовое соседство с Linkmeup_R3 и Linkmeup_R4.

   Linkmeup_R1(config)#router bgp 64500 Linkmeup_R1(config-router)#neighbor 3.3.3.3 remote-as 64500 Linkmeup_R1(config-router)#neighbor 3.3.3.3 update-source Loopback 0 Linkmeup_R1(config-router)#neighbor 4.4.4.4 remote-as 64500 Linkmeup_R1(config-router)#neighbor 4.4.4.4 update-source Loopback 0
   Потом создаём Address-Family L2VPN VPLS и указываем соседей, которые будут участвовать в L2VPN. Заметьте, не в конкретном VFI Blue, а вообще.

   Linkmeup_R1(config-router)#address-family l2vpn vpls Linkmeup_R1(config-router-af)#neighbor 3.3.3.3 activate Linkmeup_R1(config-router-af)#neighbor 3.3.3.3 send-community extended Linkmeup_R1(config-router-af)#neighbor 3.3.3.3 suppress-signaling-protocol ldp Linkmeup_R1(config-router-af)#neighbor 4.4.4.4 activate Linkmeup_R1(config-router-af)#neighbor 4.4.4.4 send-community extended Linkmeup_R1(config-router-af)#neighbor 4.4.4.4 suppress-signaling-protocol ldp
   Здесь вы должны помнить, что обычно мы используем Route Reflector"ы - не нужно настраивать всех соседей вручную, иначе смысл Auto-Discovery теряется. То есть если всего PE-устройств в сети MPLS - 100, в данном VPLS-домене - 20, а L2VPN RR - 2, то на каждом PE нужно поднять соседство только с этими двумя RR. Ну вы же не маленькие, чтобы я вам это рассказывал?

   send-community extended - как и в L3VPN включаем передачу Extended Community (RT).
   suppress-signaling-protocol ldp - и запрещаем сигнализацию LDP.

   Вот что BGP знает о VPLS, ещё даже не имея соседей:

   Верхняя строка - это RD, выбранный автоматически: AS:VPN ID. Нижняя - это префикс, который будет передаваться соседям.

   Аналогичные манипуляции производим на Linkmeup_R3 и Linkmeup_R4.

   Конфигурация всех PE

   Linkmeup_R1
   Linkmeup_R1(config)#l2vpn vfi context Blue Linkmeup_R1(config-vfi)#vpn id 63 Linkmeup_R1(config-vfi)#autodiscovery bgp signaling bgp Linkmeup_R1(config-vfi-autodiscovery)#ve id 101 Linkmeup_R1(config)#mpls label range 1000 1999 Linkmeup_R1(config)#bridge-domain 255 Linkmeup_R1(config-bdomain)#member vfi Blue Linkmeup_R1(config-bdomain)#member gigabitEthernet 3 service-instance 10 Linkmeup_R1(config-bdomain)#member gigabitEthernet 4 service-instance 12 Linkmeup_R1(config)#interface gigabitEthernet 3 Linkmeup_R1(config-if)# service instance 10 ethernet Linkmeup_R1(config-if-srv)#description Blue-A Linkmeup_R1(config-if-srv)#encapsulation default Linkmeup_R1(config)#interface gigabitEthernet 4 Linkmeup_R1(config-if)# service instance 12 ethernet Linkmeup_R1(config-if-srv)#description Blue-C Linkmeup_R1(config-if-srv)#encapsulation default Linkmeup_R1(config)#router bgp 64500 Linkmeup_R1(config-router)#neighbor 3.3.3.3 remote-as 64500 Linkmeup_R1(config-router)#neighbor 3.3.3.3 update-source Loopback 0 Linkmeup_R1(config-router)#neighbor 4.4.4.4 remote-as 64500 Linkmeup_R1(config-router)#neighbor 4.4.4.4 update-source Loopback 0 Linkmeup_R1(config-router)#address-family l2vpn vpls Linkmeup_R1(config-router-af)#neighbor 3.3.3.3 activate Linkmeup_R1(config-router-af)#neighbor 3.3.3.3 send-community extended Linkmeup_R1(config-router-af)#neighbor 3.3.3.3 suppress-signaling-protocol ldp Linkmeup_R1(config-router-af)#neighbor 4.4.4.4 activate Linkmeup_R1(config-router-af)#neighbor 4.4.4.4 send-community extended Linkmeup_R1(config-router-af)#neighbor 4.4.4.4 suppress-signaling-protocol

   Linkmeup_R3
   Linkmeup_R3(config)#l2vpn vfi context Blue Linkmeup_R3(config-vfi)#vpn id 63 Linkmeup_R3(config-vfi)#autodiscovery bgp signaling bgp Linkmeup_R3(config-vfi-autodiscovery)#ve id 103 Linkmeup_R3(config)#mpls label range 3000 3999 Linkmeup_R3(config)#bridge-domain 255 Linkmeup_R3(config-bdomain)#member vfi Blue Linkmeup_R3(config-bdomain)#member gigabitEthernet 3 service-instance 13 Linkmeup_R3(config)#interface gigabitEthernet 3 Linkmeup_R3(config-if)#service instance 13 ethernet Linkmeup_R3(config-if-srv)#description Blue-D Linkmeup_R3(config-if-srv)#encapsulation default Linkmeup_R3(config)#router bgp 64500 Linkmeup_R3(config-router)#neighbor 1.1.1.1 remote-as 64500 Linkmeup_R3(config-router)#neighbor 1.1.1.1 update-source Loopback 0 Linkmeup_R3(config-router)#neighbor 4.4.4.4 remote-as 64500 Linkmeup_R3(config-router)#neighbor 4.4.4.4 update-source Loopback 0 Linkmeup_R3(config-router)#address-family l2vpn vpls Linkmeup_R3(config-router-af)#neighbor 1.1.1.1 activate Linkmeup_R3(config-router-af)#neighbor 1.1.1.1 send-community extended Linkmeup_R3(config-router-af)#neighbor ppress-signaling-protocol ldp Linkmeup_R3(config-router-af)#neighbor 4.4.4.4 activate Linkmeup_R3(config-router-af)#neighbor 4.4.4.4 send-community extended Linkmeup_R3(config-router-af)#neighbor 4.4.4.4 suppress-signaling-protocol ldp

   Linkmeup_R4
   Linkmeup_R4(config)#l2vpn vfi context Blue Linkmeup_R4(config-vfi)#vpn id 63 Linkmeup_R4(config-vfi)#autodiscovery bgp signaling bgp Linkmeup_R4(config-vfi-autodiscovery)#ve id 104 Linkmeup_R4(config)#mpls label range 4000 4999 Linkmeup_R4(config)#bridge-domain 255 Linkmeup_R4(config-bdomain)#member vfi Blue Linkmeup_R4(config-bdomain)#member gigabitEthernet 3 service-instance 131 Linkmeup_R4(config)#interface gigabitEthernet 3 Linkmeup_R4(config-if)#service instance 11 ethernet Linkmeup_R4(config-if-srv)#description Blue-B Linkmeup_R4(config-if-srv)#encapsulation default Linkmeup_R4(config)#router bgp 64500 Linkmeup_R4(config-router)#neighbor 1.1.1.1 remote-as 64500 Linkmeup_R4(config-router)#neighbor 1.1.1.1 update-source Loopback 0 Linkmeup_R4(config-router)#neighbor 3.3.3.3 remote-as 64500 Linkmeup_R4(config-router)#neighbor 3.3.3.3 update-source Loopback 0 Linkmeup_R4(config-router)#address-family l2vpn vpls Linkmeup_R4(config-router-af)#neighbor 1.1.1.1 activate Linkmeup_R4(config-router-af)#neighbor 1.1.1.1 send-community extended Linkmeup_R4(config-router-af)#neighbor 1.1.1 suppress-signaling-protocol ldp Linkmeup_R4(config-router-af)#neighbor 3.3.3.3 activate Linkmeup_R4(config-router-af)#neighbor 3.3.3.3 send-community extended Linkmeup_R4(config-router-af)#neighbor 3.3.3 suppress-signaling-protocol ldp

   Для разных устройств я указал разные mpls label range, чтобы более наглядной была разница между локальными и удалённым метками.
   

Что произошло?

0. Связность между CE уже появилась

1. BGP установил сессии и разослал свои Update"ы.

А в Update нас интересует NLRI

Это Linkmeup_R1 сообщает Linkmeup_R3, как вычислить VPN-метку для трафика, предназначенного ему для VPLS с RT 65400:63. CE-ID (он же VE ID)=101, VBO=100, VBS=10, LB=1000.

Это уже Linkmeup_R3 сообщает Linkmeup_R1: CE-ID=103, VBO=100,VBS=10, LB=3000

И вот Linkmeup_R4 сообщает Linkmeup_R1: CE-ID=104, VBO=100,VBS=10, LB=4000

Linkmeup_R1 на Linkmeup_R4 передал то же, что и на Linkmeup_R3 .

Давайте, не заглядывая в таблицы меток на PE, посчитаем, какие метки будут назначены?

Linkmeup_R3→Linkmeup_R1
Метка: LB + Local VE ID - VBO = 1000+103-100=1003.
Метку 1003 вставит Linkmeup_R3 в кадр, который хочет отправить на Linkmeup_R1 в этом VFI.

Linkmeup_R1→Linkmeup_R3
Метка: LB + Local VE ID - VBO = 3000+101-100=3001.
Метку 3001 вставит Linkmeup_R1 в кадр, который хочет отправить на Linkmeup_R3 в этом VFI.

Linkmeup_R1→Linkmeup_R4
Неравенство VBO ≤ Local VE ID ≤ VBO+VBS-1 выполняется: 100≤101≤109.
Метка: LB + Local VE ID - VBO = 4000+101-100=4001.

Linkmeup_R4→Linkmeup_R1
Метка: LB + Local VE ID - VBO = 1000+104-100=1004.

Осталось вычислить пару Linkmeup_R4→Linkmeup_R3 и Linkmeup_R3→Linkmeup_R4.
Linkmeup_R4→Linkmeup_R3
Неравенство VBO ≤ Local VE ID ≤ VBO+VBS-1 выполняется: 100≤104≤109.
Метка: LB + Local VE ID - VBO = 3000+104-100=3004.

Linkmeup_R3→Linkmeup_R4
Неравенство VBO ≤ Local VE ID ≤ VBO+VBS-1 выполняется: 100≤103≤109.
Метка: LB + Local VE ID - VBO = 4000+103-100=4003.

2. Сверимся с ситуацией на PE.

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

3. Соответственно, если сейчас мы отправим ping с Blue-A на Blue-D, то должны увидеть VPN-метку 3001 в ICMP-Request и 1003 в ICMP-Reply:

А в этот раз Wireshark почему-то распознал ICMP в MPLS

Вы по-прежнему можете использовать команды show mpls l2transport vc detail и show l2vpan atom vc detail для просмотра деталей:

Командой show bgp l2vpn vpls rd X ve-id Y block-offset Z вы можете вывести всю информацию о блоке меток от данного соседа.

А так посмотреть утилизацию блока меток:

Сложность и количество команд настройки выглядит больше, чем для режима Martini, но нужно помнить, что:

1) Это однократная настройка. При добавлении нового PE в VPLS-домен, настраивать нужно только его (в случае использования RR). Для Martini придётся пройтись по всем существующим PE этого VPLS-домена.
2) Конфигурация по большей части одинаковая - меняется только VE ID. Секция BGP вообще берётся копипастом (в случае использования RR).

Ещё раз повторим шаги конфигурации:

1. Настраиваем VFI, указывая VPN ID, протоколы, VE ID.
2. Создаём Service Instance на AC-интерфейсах.
3. Связываем VFI и Service Instance через bridge-domain.
4. В секции BGP поднимаем соседство с RR в Address-family L2VPN VPLS.

Теория и практика VPLS Kompella mode на примере Juniper: . Конфигурация и примеры вычисления меток: Сама cisco .

Matini vs Kompella

В результате, какие преимущества даёт использование BGP Kompella mode перед Martini Mode?

• Auto-Discovery. Нет необходимости на каждом PE настраивать удалённые LDP-сессии со всем участниками этого VPLS-домена. При использовании RR вопрос полной связности совсем отпадает.
• Вместе с Auto-Discovery BGP поддерживает и обмен префиксами/метками. Это обычно ставится в плюс методу, хотя это необходимая функция. Здесь, вероятно, лучше заметить, что если у оператора уже есть инфраструктура BGP, то L2VPN сигнализацией через BGP впишется в неё органично. А вот если этот протокол до сих пор не использовался, то выглядеть он может, как пятая нога.
• У BGP всё схвачено на предмет Inter-AS VPN. Option C позволит организовать бесшовный (seamless) MPLS между различными AS и протянуть через него тысячи PW.

Однако всё ли так очевидно? Копнём поглубже.

Междоменные (Inter-AS) VPN не такая уж большая сложность для Martini при организации иерархического VPLS - тогда нет нужды создавать полносвязную топологию PE-устройств в VPLS-домене. Про H-VPLS мы ещё . Можем вычеркнуть это из его слабых сторон.

Что же касается столь активно эксплуатируемого Auto-Discovery в Kompella , то тут есть два замечания:

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

H-VPLS разделяет маршрутизаторы VPLS-домена на два ранга: PE-rs и MTU-s.

PE-rs - PE - routing and switching . Это ядро сети VPLS. Это большие производительные железки, которые функционируют как обычные PE. Другие названия PE-rs: PE-POP , n-PE .

MTU-s - Multi-Tenant Unit - switching . Это могут быть более слабые устройства, которые подключаются к PE-rs с одной стороны. А с другой к ним подключаются CE. Другие названия MTU-s: u-PE , PE-CLE .

MTU-s обычно имеют восходящие интерфейсы к двум PE-rs - для отказоустойчивости. Но может быть и один. Механизмы подключения MTU-s к PE-rs: MPLS PW или QinQ. Поскольку мы тут про MPLS, то будем рассматривать только первый способ.

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

При взаимодействии PE-rs и MTU-s, PE-rs воспринимает PW от MTU-s как AC-интерфейс, то есть, как рядового клиента. А значит:

Всё, что PE-rs получил от MTU-s он рассылает всем соседним PE-rs и всем подключенным MTU-s,
- То, что PE-rs получил от соседнего PE-rs он рассылает всем подключенным к нему MTU-s, но не отправляет другим PE-rs.

Таким образом, каждому MTU-s нужно поддерживать связь только с двумя (или одним) соседом, а количество PE-rs достаточно невелико, чтобы организовать между ними полносвязную топологию. При добавлении нового узла нужно настроить только его и вышестоящий PE-rs.

Для организации Inter-AS VPN H-VPLS тоже может сослужить службу. Например, два подключенных друг к другу ASBR могут быть PE-rs более высокого уровня иерархии.

Итак H-VPLS - это решение трёх задач:

• Улучшение масштабируемости сети в плане Contol Plane.
• Оптимизация Data Plane за счёт уменьшения числа копий широковещательных кадров.
• Возможность делить VPLS-домен на сегменты и ставить на доступ более дешёвое оборудование.

Так! Стоп, а что насчёт MAC-таблицы на PE-rs? То, что в обычном VPLS было P, в H-VPLS стало PE, а соответственно, должно заниматься клиентскими данными - изучать MAC-адреса. Причём от всех MTU-s, которые к нему подключены. А вместе с тем заниматься рассылкой и репликацией клиентских кадров.

Получается, что, введя иерархию на Control Plane мы форсировали создание иерархии и на Data Plane. Справившись с одной проблемой масштабируемости, H-VPLS создал новую. Счёт MAC-адресов в этом случае может идти на тысячи и сотни тысяч, вопрос флудинга встаёт на новом уровне, нагрузка на CPU может значительно возрасти. Но решения для этой ситуации H-VPLS не предлагает.

Впрочем, удешевление устройств уровня доступа, видимо, вполне окупает этот лёгкий дискомфорт.

Ну что, попробуем настроить?

Практика H-VPLS

Мы не будем усложнять себе жизнь резервированиями и Dual-Homing"ом. Вместо этого останемся в рамках нашей же топологии, но Linkmeup_R1 станет MTU-s, а Linkmeup_R2 - PE-rs.

Технически H-VPLS может быть реализован и на базе режима Kompella, но вот такой необходимости там нет, поэтому мы отталкиваемся от режима Martini.

1. Начнём с понятного - PE-rs. Сейчас Linkmeup_R2, Linkmeup_R3 и Linkmeup_R4 выступают в качестве PE-rs - между ними настраивается полносвязная топология в VFI.

   Linkmeup_R2(config)#l2vpn vfi context Blue Linkmeup_R2(config-vfi)# vpn id 63 Linkmeup_R2(config-vfi)# member 3.3.3.3 encapsulation mpls Linkmeup_R2(config-vfi)# member 4.4.4.4 encapsulation mpls
   Интерфейсов на Linkmeup_R2 нет, поэтому bridge-domain не нужен.

   Конфигурация Linkmeup_R3 и Linkmeup_R4

   Linkmeup_R3
   Linkmeup_R3(config)#l2vpn vfi context Blue Linkmeup_R3(config-vfi)# vpn id 63 Linkmeup_R3(config-vfi)# member 2.2.2.2 encapsulation mpls Linkmeup_R3(config-vfi)# member 4.4.4.4 encapsulation mpls Linkmeup_R3(config-vfi)#bridge-domain 255 Linkmeup_R3(config-bdomain)# member vfi Blue Linkmeup_R3(config-bdomain)# member gigabitEthernet 3 service-instance 13 Linkmeup_R3(config-bdomain)#interface GigabitEthernet3 Linkmeup_R3(config-if)# service instance 13 ethernet Linkmeup_R3(config-if-srv)# description Blue-D Linkmeup_R3(config-if-srv)# encapsulation default

   Linkmeup_R4
   Linkmeup_R4(config)#l2vpn vfi context Blue Linkmeup_R4(config-vfi)# vpn id 63 Linkmeup_R4(config-vfi)# member 2.2.2.2 encapsulation mpls Linkmeup_R4(config-vfi)# member 3.3.3.3 encapsulation mpls Linkmeup_R4(config-vfi)#bridge-domain 255 Linkmeup_R4(config-bdomain)# member vfi Blue Linkmeup_R4(config-bdomain)# member gigabitEthernet 3 service-instance 11 Linkmeup_R4(config-bdomain)#interface GigabitEthernet3 Linkmeup_R4(config-if)# service instance 13 ethernet Linkmeup_R4(config-if-srv)# description Blue-D Linkmeup_R4(config-if-srv)# encapsulation default

2. На Linkmeup_R1 создаём PW до Linkmeup_R2.

   Linkmeup_R1(config)#l2vpn xconnect context Blue_10 Linkmeup_R1(config-xconnect)# member GigabitEthernet3 service-instance 10 Linkmeup_R1(config-xconnect)# member 2.2.2.2 6310 encapsulation mpls
   Первой командой входим в режим настройки xconnect, следующими двумя связываем AC-интерфейс и VC-канал.

   ID 6310 произвольный, но должен совпадать с тем, который мы настроим на PE-rs. Здесь я выбрал 63 - как индикатор VPN ID, а 11 - порядковый номер VC на данном MTU-s.

   Настройка интерфейса остаётся прежней:

   Linkmeup_R1(config-xconnect)#interface GigabitEthernet3 Linkmeup_R1(config-if)# service instance 10 ethernet Linkmeup_R1(config-if-srv)#encapsulation default
   

   Для интерфейса Gi4 делаем то же самое

   Linkmeup_R1(config)#l2vpn xconnect context Blue_10 Linkmeup_R1(config-xconnect)# member GigabitEthernet4 service-instance 12 Linkmeup_R1(config-xconnect)# member 2.2.2.2 6320 encapsulation mpls Linkmeup_R1(config-xconnect)#interface GigabitEthernet4 Linkmeup_R1(config-if)# service instance 12 ethernet Linkmeup_R1(config-if-srv)#encapsulation default
   

3. Осталось терминировать эти PW на стороне Linkmeup_R2:

   Linkmeup_R2(config)#bridge-domain 255 Linkmeup_R2(config-bdomain)# member vfi Blue Linkmeup_R2(config-bdomain)# member 1.1.1.1 6310 encapsulation mpls Linkmeup_R2(config-bdomain)# member 1.1.1.1 6320 encapsulation mpls

На этом базовая настройка H-VPLS Martini Mode закончена.
Файл конфигурации H-VPLS

Что произошло? PW поднялись:

VFI на Linkmeup_R2 про них знает:

MAC"и отлично изучает:

С H-VPLS появляется ряд вопросов, которые уже за рамками этой статьи:

1. Резервирование. Dual-Homing MTU-s к двум PE-rs. Очень распространённый дизайн.
2. H-VPLS с QinQ на доступе, вместо MPLS PW.
3. Технологии защиты от петель и проброс STP BPDU через сеть VPLS.

Немного приоткроют завесу над этими вопросами следующие два документа: H-VPLS PE-rs Redundancy for QinQ Access и .

А теперь пара историй о коварстве L2 c механизмом широковещательных рассылок.

Случай А

В общем-то даже не случай - а то, как обычно это всё работает.

Большой клиент, много трафика. И вот случается что-то страшное, и таблица MAC-адресов очищается. И сотни дурнопахнущих мегабит устремляются во все концы VPLS-домена. И на линиях, где раньше проходил только трафик данного филиала этого клиента, теперь летит всё-всё-всё.

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

Случай Б

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

Как видите, тут филиал крупного клиента подключен через узкий арендованный канал с полосой пропускания 100 Мб/с. И как бы ему их за глаза.

Но, случается что-то страшное и таблица MAC-адресов очищается. И весь трафик этого VSI, для которого не изучен в данный момент MAC-адрес назначения, будет широковещаться. И если, например, общий трафик этого клиента составлял 400 Мб/с, то это 400 Мб/с флуда по всей сети, которая упрётся в 100 Мб/с арендованного канала. После чего последуют кратковременные потери трафика на время переизучения MAC-ов. А для больших сетей это может занять несколько минут.

Случай В

Расширим случай Б. Теперь у нас на доступе не один клиент, а кольцо коммутаторов. И одна линия между ними выполнена в виде РРЛ-пролёта. Ситуация не такая редкая, учитывая масштабы расстояний в нашей необъятной, а, скорее, даже типичная.

В целом, происходит всё то же, что и в случае Б, но при этом у нас здесь есть ещё какое-то решение по защите от петель: STP или какой-то проприетарный протокол. Суть их одна - заблокировать лишний порт. А если что-то не так со связностью, о которой они судят по наличию и отсутствию сообщений, разблокировать.

Теперь следующий шаг наших размышлений - флуд, который заваливает узкие линии и ведёт к потерям пакетов. Если в этом трафике большое количество высокоприоритетных пакетов CS6/CS7, то теряться будут и кадры протоколов. И тогда начинается цирк - протокол восстанавливает линк, потому что думает, что топологии хана, и что происходит? В открытый порт устремляется 100 Мб/с трафика, который усугубляет ситуацию.

Случай Г

Буква эта даже немного говорящая. Потому что такой случай не может произойти просто так. Вот такая сеть.

Дизайн в данном случае предполагает, что между двумя PE прокинут дополнительный PW для сигнализации протокола защиты от петель (как и в случае В). Точнее их два - один через прямой линк, другой окольный через MPLS-сеть.

То есть мы получаем физическое кольцо коммутаторов, разделённое одним заблокированным портом.

Да, автор знает, что так сети не строят. Да, автор знает о последствиях. Нет, автор, не принимал участия в разработке дизайна.

И ещё одна деталь - в разных кольцах есть точки подключения одного и того же клиента, соответственно, в них направлен один и тот же VSI.

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

Итак, когда обрывают сразу два конца одного кольца, PE оказывается изолированным, соответственно все его PW переходят в состояние Down, в том числе и служебный для протокола защиты от петель. Протокол думает, что кольца сейчас разомкнуты (а они действительно разомкнуты) и восстанавливает заблокированный интерфейс в обоих кольцах. Чувствуете уже засаду? у нас есть две цепочки коммутаторов, которые кончаются на двух PE и подключены к интерфейсам, привязанным к одному и тому же VSI. Два разомкнутых физических кольца срастаются в одно замкнутое логическое кольцо. И если один PE изолирован и не может навредить остальной части сети, то второй вполне себе в бою и начинает злостно рассылать широковещательный трафик.

Случай Д

Имеется сеть VPLS с двумя центральными PE. Например, это сеть DCI . ДЦ1 подключен к двум PE - так называемый Dual-Homing - режиме Active/Active - то есть оба плеча могут принимать и передавать трафик. При этом коммутация внутри не происходит - поэтому петля исключена.

Всё прекрасно, пока трафик в обоих направлениях ходит через одно и то же плечо. Интересное начинается в случае ассиметричного пути. Например, трафик к ДЦ1 приходит по левому плечу, а уходит по правому.

В целом, нормальная ситуация. Но не для L2. PE1 будет изучать MAC-адреса других ДЦ - весь такой молодец, но трафик от ДЦ1 будет приходить на PE2, который ни сном ни духом про MAC-адреса. Соответственно, он будет полученный трафик широковещать и привет ситуации А-В.

Да, часть этих проблем - это непродуманный дизайн. Да, есть те или иные «решения», которые позволяют уменьшить вероятность и серьёзность проблем, но Ethernet - как вода - просочится везде. И главная проблема - в механизме широковещательных рассылок - это ахилесова пята по всём остальном прекрасного протокола, который завоевал мир.

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

Однако это данность, от которой никуда не деться. И если мы не можем убрать корень проблемы в виде механизма широковещательной рассылки в Ethernet, то можно придумать способ с ней бороться.

О нём мы и поговорим в следующий раз - EVPN. Революционное решение, которое переносит функцию изучения MAC-адресов на Control Plane и привлекает для этого BGP.

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

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

• Весело задорно про MPLS вообще: Тыц .
• Коротко о мирном AToM"е: Тыц .. BGP
• Martini
• Kompella

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

Спецификация кодирования стека меток 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.

21.09.2006 Энно Рей, Петер Фирс

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

перед использованием VPN на базе MPLS или магистральных структур необходимо провести анализ рисков, в особенности в отношении передаваемого трафика.

Многопротокольная коммутация меток (Multi-Protocol Label Switching, MPLS) представляет собой специфицированную RFC 3031 и другими документами технологию продвижения пакетов. Разработчики стремились избежать неэффективной маршрутизации IP, когда маршрут каждого пакета определяется по его адресу назначения посредством объемных таблиц маршрутизации. В случае MPLS продвижение пакетов происходит на основании так называемых «меток». Для этого в заголовок добавляется блок данных размером 32 бит. Большую его часть составляет «тег» длиной 20 бит - собственно метка, на основании которой и принимается решение о дальнейшем перемещении пакета. Кроме того, имеется еще три поля, в том числе время жизни пакета (Time-To-Live, TTL).

Когда пакет IP достигает магистрали на базе MPLS, он в первую очередь классифицируется - по адресу назначения или по принадлежности к определенной клиентской виртуальной частной сети (Virtual Private Network, VPN), затем снабжается одной или несколькими метками и направляется дальше. На каждом транзитном узле верхняя метка заменяется на новую, после чего пакет передается следующему соседу. О метках и их значениях два соседних маршрутизатора договариваются при помощи специального протокола - в большинстве случаев протокола распределения меток (Label Distribution Protocol, LDP). Благодаря согласованию между соседними устройствами отпадает необходимость в централизованном механизме управления метками.

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

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

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

К таковым относятся:

• виртуальные частные сети на базе MPLS (иногда называемые виртуальными частными сетями третьего уровня);
• виртуальные частные сети второго уровня на базе MPLS; по ним передаются целые кадры второго уровня (подробнее об этом ниже);
• формирование трафика MPLS в целях оптимального использования имеющейся пропускной способности и предоставления резервных маршрутов;
• обобщенная технология MPLS (General MPLS, GMPLS) для сигнализации в оптических сетях.

Некоторые из перечисленных технологий, к примеру формирование трафика (Traffic Engineering, TЕ), имеют значение только для операторов магистральных сетей. Другие, в особенности технологии VPN, играют важную роль для многих организаций - когда подобная услуга приобретается у оператора или соответствующая служба используется в собственной территориальной локальной сети, к примеру для разделения трафика разных дочерних предприятий. Эти технологии будут представлены и подробно описаны ниже.

ОСНОВЫ ВИРТУАЛЬНОЙ ЧАСТНОЙ СЕТИ MPLS

В случае виртуальной частной сети MPLS речь идет о самостоятельной технологии на основе меток с собственной терминологией, описанной главным образом в RFC 2547 и 2917. Она часто сравнивается с ретрансляцией кадров и АТМ, поскольку в рамках одной сетевой инфраструктуры организуется несколько раздельных логических маршрутов, по которым передается трафик отдельных (клиентских) виртуальных частных сетей. Технология очень гибка в отношении возможных топологий VPN, поскольку благодаря использованию так называемых «целей маршрута» можно определять, какие сети и в каких таблицах маршрутизации упоминаются.

В первую очередь различие проводится между провайдерской сетью, где применяется MPLS, и клиентской, которая использует соответствующую службу, но не имеет никакого отношения к выделению меток или соответствующему продвижению данных. Транзитный пункт между клиентом и провайдером со стороны провайдера называют пограничным устройством провайдера (Provider Edge, PE), а со стороны клиента - пограничным устройством клиента (Customer Edge, CE).

Устройство РЕ обычно обслуживает нескольких клиентов, для чего помимо своей таблицы маршрутизации, которая в этом случае называется «глобальная», ведет дополнительные, специфичные для каждой VPN виртуальные экземпляры маршрутизации и продвижения данных (Virtual Routing and Forwarding Instance, VRF). Благодаря подобной виртуализации можно сделать так, чтобы разные клиенты пользовались одним и тем же адресным пространством или разными протоколами маршрутизации (см. Рисунок 2 и 3).

Устройства РЕ, к которым подключаются клиенты, обмениваются информацией о том, какую именно сеть (префикс) и какого клиента они обслуживают посредством многопротокольного BGP (Multiprotocol BGP, MP-BGP) - расширенного варианта пограничного шлюзового протокола (Border Gateway Protocol, BGP). Передаваемая информация выглядит примерно так: «Через меня (устройство РЕ) при помощи следующей метки можно достичь следующие префиксы (сети) таких-то клиентов».

Функциональность VPN можно обобщить следующим образом:

• маршрутизатор РЕ назначает индивидуально сконфигурированную метку при помощи так называемого «различителя маршрутов» каждой клиентской виртуальной частной сети;
• устройство РЕ при помощи MP-BGP передает данные о «различителе маршрутов», префиксе сети и соответствующей метки.

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

Если устройство РЕ получает от клиентского устройства пакет, оно снабжает его (минимум) двумя метками и направляет дальше: одна метка определяет, какому устройству РЕ ретранслируется пакет; вторая - к какому клиенту (клиентской сети) он относится. Таким образом, вся функциональность VPN реализуется при помощи двух меток.

При оценке безопасности этой технологии VPN часто цитируется старое исследование компании Miercom, главная мысль которого заключается в том, что технологию можно рассматривать как надежную, поскольку злоумышленник не в состоянии получить доступ к клиентским VPN или магистрали (см. Рисунок 4). Даже если придерживаться аргументации этого исследования - а Miercom часто обвиняют в чрезмерной близости к его заказчику, компании Cisco, - необходимо учитывать некоторые особенности:

• трафик в виртуальных частных сетях MPLS не шифруется. Если в представлении читателя понятие «виртуальная частная сеть» обязательно включает в себя шифрование, то от этого базового допущения придется отказаться. В данном случае VPN не означает ничего более, кроме разделения трафика;
• маршрутизатор РЕ обычно «делится» между различными клиентами и - при определенных условиях - задачами. Поэтому атаки, к примеру «отказ в обслуживании» (Denial of Service, DoS), из клиентской сети или - при условии соответствующей достижимости - из Internet могут иметь побочное негативное воздействие на безопасность или доступность других клиентов;
• авторы статьи в ходе оценки операторов столкнулись с тем, что технический персонал не проводит предписанной технической проверки устройств РЕ (сканирование), «чтобы отрицательно не повлиять на достижимость других клиентов».

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

МЕТОДЫ АТАК

При атаках на VPN первоочередная цель злоумышленника - чтение трафика или неавторизованный доступ. Атаки DoS в этом случае не рассматриваются. Все атаки можно разделить на атаки «извне» (из клиентской сети или Internet) и атаки «изнутри» (с магистрали MPLS).

Инжекция (ввод) предварительно маркированного трафика из клиентской сети. Злоумышленник, находящийся в клиентской сети, может попытаться проникнуть в другую виртуальную частную сеть, передав «своему» устройству РЕ пакеты, уже содержащие метку. Речь идет о метке, на основании которой пакет направляется в другую VPN. Но как написано в RFC 2547: «Пакеты с метками из не заслуживающих доверия источников не принимаются магистральными маршрутизаторами».

С точки зрения провайдера, клиентская сеть никогда «не заслуживает доверия», а значит, такие пакеты должны отклоняться маршрутизатором РЕ.

Инжекция (ввод) уже маркированного трафика из Internet. Злоумышленник может попытаться отправить на маршрутизатор РЕ уже маркированные пакеты из Internet, с целью передать их в клиентскую сеть. Для этого ему необходимо узнать или угадать используемые метки и IP-адреса, что вполне возможно. IP-адрес 10.1.1.1, к примеру, встречается в большинстве сетей, а кроме того, зная производителя оборудования, метки довольно легко угадать. Между тем уже имеется инструмент, который служит для автоматического определения используемых в сети меток (см. ссылку в ). Инструмент предназначен только для магистрали и не рассчитан на применение из Internet, и поэтому он не подходит для описанной атаки. Тем не менее его наличие - показатель того, что атаки на MPLS попали в сферу интересов хакеров. В ближайшем будущем наверняка появятся новые средства для автоматического проведения описанных здесь атак.

Маркированные соответствующим образом пакеты необходимо доставить до атакуемой точки (что маловероятно), а атакуемый маршрутизтор PЕ должен быть достижим из Internet (что зависит от организации конкретной сети провайдера) - только тогда атака будет успешной. Но благодаря тенденции к концентрации все большего количества функций на все меньшем числе многофункциональных устройств, такие условия нельзя полнос-тью исключать. Как уже упоминалось, RFC 2547 предписывает, чтобы пакеты с метками из не заслуживающих доверия источников, к каковым, безусловно, относится Internet, отбрасывались. В том, что это требование выполняется, мы могли убедиться, проведя различные тесты. Однако cоставители книги «Безопасность виртуальных частных сетей MPLS», выпущенной компанией Cisco, утверждают: такая атака на маршрутизаторы может быть успешной при использовании некоторых (старых) версий операционной системы IOS.

АТАКИ С МАГИСТРАЛИ

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

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

Скомпрометированные провайдерские устройства. Необходимо помнить, что провайдерские устройства могут быть взломаны. Опубликованная в 2003 г. на собрании Группы североамериканских сетевых операторов (North American Network Operators" Group, NANOG) статистика упоминает о подобных инцидентах с более чем 5000 маршрутизаторами в сетях провайдеров услуг Internet.

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

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

Атаки на транзитные узлы между провайдерами. Для того чтобы предлагать виртуальные частные сети MPLS в мировом масштабе, многие операторы заключают между собой контракты, благодаря которым они могут строить виртуальные частные сети MPLS, простирающиеся за пределы их собственной сети, и одновременно обмениваться маркированными пакетами. RFC 2547 описывает разные модели, и среди них по меньшей мере одна - по иронии судьбы, наиболее масштабируемая - может быть по сути своей ненадежной. Кроме того, в точках обмена трафика (Internet Exchange Points, IXP) операторы часто организуют межсоединения на базе Ethernet, в результате чего потенциально создаются условия для атак на интерфейс данных на втором уровне.

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

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

• как ретрансляция кадров, так и АТМ предполагают наличие специализированных устройств (коммутаторов), которые недостижимы из Internet. Виртуальные частные сети MPLS, для которых ключевыми словами являются консолидация и оптимизация затрат, часто реализуются на базе имеющихся платформ, а они, помимо прочего, берут или могут взять на себя дополнительные функции в сети провайдера услуг Internet и вследствие этого потенциально достижимы из Internet;
• многообразие протоколов на разных уровнях (второй уровень: АТМ/ретрансляция кадров, третий уровень: IP) повышает сложность эксплуатации (а значит, и затраты на нее), но затрудняет проведение атак.

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

АТАКИ ИЗ ЯДРА MPLS

Модификация маршрутизации MP-BGP. Когда злоумышленник в состоянии вмешаться в первоначальный информационный обмен в Multiprotocol BGP, он может добавлять в виртуальную частную сеть «дополнительные филиалы», и уже через них получить неавторизованный доступ к системам. Причем надо не только находиться на магистрали, но и иметь в наличии дополнительные инструменты для точечного доступа к трафику BGP, что требует значительных усилий.

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

Варианты атак различны. К примеру, в той, что показана на Рисунке 5, в двух разных VPN («альфа» и «бета») используется одно и то же адресное пространство. Поступающие на устройство PE пакеты для адресного пространства 172.31.1.0 различаются по их меткам (17 для «альфа» и 20 для «бета»):

pe_7204vxr>sh ip vp vpnv4 vrf alpha labels

Network Next HopIn label/Out label

Route Distinguisher: 100:1 (alpha)

20.20.20.21/32 10.10.10.25 nolabel/17

20.20.20.40/32 172.31.2.2 19/nolabel

172.31.1.0/29 10.10.10.25 nolabel/18

172.31.2.0/29 0.0.0.0 17/aggregate(alpha)

192.168.5.0 10.10.10.25 nolabel/19

Pe_7204vxr>sh ip bgp vpnv4 vrf beta labels

Network Next Hop In label/Out label

Route Distinguisher: 100:2 (beta)

172.31.1.0/29 10.10.10.25 nolabel/20

172.31.2.0/29 0.0.0.0 16/aggregate(beta)

Если теперь злоумышленник сможет читать пакеты (на Рисунке 6 простой ping), то он в состоянии изменить метку, ввести пакеты в сеть заново и таким образом проникнуть в VPN. В результате пакет будет транслироваться устройством в «не ту VPN» (перевод входящего пакета ping устройством в VPN «бета»):

01:55:45.993783 IP 172.31.1.2 > 172.31.2.2: icmp

40: echo request seq 17408

01:55:45.993815 IP 172.31.2.2 > 172.31.1.2: icmp

40: echo reply seq 17408

01:55:46.995175 IP 172.31.1.2 > 172.31.2.2: icmp

40: echo request seq 17664

01:55:46.995211 IP 172.31.2.2 > 172.31.1.2: icmp

40: echo reply seq 17664

01:55:47.996723 IP 172.31.1.2 > 172.31.2.2: icmp

40: echo request seq 17920

01:55:47.996756 IP 172.31.2.2 > 172.31.1.2: icmp

40: echo reply seq 17920

01:59:14.136855 IP 172.31.1.2 > 172.31.2.2: icmp

80: echo request seq 5725

01:59:14.136906 IP 172.31.2.2 > 172.31.1.2: icmp

80: echo reply seq 5725

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

Хотя для проведения подобных атак инструментов (пока!) не существует, даже односторонняя инжекция пакетов в виртуальную частную сеть может иметь серьезные последствия. Ее оказывается достаточно, к примеру, для атак на основе SNMP - среди которых есть сброс конфигурационного файла устройства - или для запуска «червей» на основе UDP («черви» SQL).

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

VPN ВТОРОГО УРОВНЯ

Под термином «виртуальная частная сеть второго уровня» в контексте MPLS обычно понимается передача произвольного трафика по MPLS (Any Transport over MPLS, AToM). Тогда по магистрали MPLS передаются не пакеты, а целые блоки второго уровня, к примеру ячейки АТМ, кадры Ethernet или frame relay.

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

Но у технологии AToM имеется две модификации, которые представляют особый интерес в рамках разговора о безопасности: Ethernet поверх MPLS (Ethernet over MPLS, EoMPLS) и служба виртуальной частной локальной сети (Virtual Private LAN Service, VPLS).

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

EoMPLS представляет собой двухточечную технологию соединения. Подключение дополнительного филиала предполагает построение от него нового туннеля ко всем уже имеющимся офисам, что ограничивает масштабируемость ЕоMPLS. Именно этот недостаток и должна исправить служба виртуальной частной локальной сети. При ее применении любое количество филиалов образуют общую сеть Ethernet с многоточечными соединениями. При добавлении филиала «псевдопровода» создаются автоматически посредством специальной системы сигнализации - однако необходимая протокольная база еще не специфицирована полностью. Все филиалы соединяются друг с другом «будто бы» напрямую, поэтому облако MPLS/VPLS часто характеризуют как «большой виртуальный коммутатор». Авторы, напротив, предпочитают рассматривать это облако MPLS/VPLS как «большой виртуальный канал» (в представлении Cisco), поскольку устройства VPLS в общем и целом не воспринимаются такими протоколами, как STP, DTP или VTP, для которых они совершенно прозрачны. Пограничными устройствами на стороне клиента в EoMPLS или VPLS чаще всего служат коммутаторы.

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

СВЯЗУЮЩЕЕ ДЕРЕВО

Поскольку разные филиалы образуют теперь общую сеть (Ethernet), на каждую виртуальную сеть выбирается лишь один корень STP (только в одном филиале). При избыточном подключении филиала (к примеру, из соображений повышения готовности) это потенциально ведет к тому, что внутренние каналы филиала между коммутаторами оказываются заблокированными (см. Рисунок 7).

Рисунок 7. Избыточные соединения иногда оказываются открытыми.

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

ВИРТУАЛЬНЫЕ ЛОКАЛЬНЫЕ СЕТИ

Проблемы с безопасностью возникают и в связи с виртуальными локальными сетями. Если, к примеру, в двух филиалах существуют одинаковые номера виртуальных сетей, то эти VLAN после соединения филиалов посредством EoMPLS/VPLS будут «видеть» друг друга. Когда в одном филиале имеется VLAN 10 для серверов, а в другом - VLAN 10 для беспроводной сети, все пользователи беспроводной сети второго филиала будут получать широковещательный трафик Windows первого филиала, и у находящегося в беспроводной сети злоумышленника появится доступ к серверу другого филиала.

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

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

Энно Рей и Петер Фирс занимаются сетевыми протоколами и их безопасностью. Эта статья базируется на докладе Энно Рея на конференции Blackhat 2006.

Ресурсы

Инструменты для проведения атак на MPLS: http://www.irmc.com/tools/irm-mpls-tools-1.0.tar.bz2 .

Майкл Берингер/Моник Морроу: «Безопасность виртуальных частных сетей MPLS» (Индианаполис, 2005).

Статистика взломов маршрутизаторов: http://www.nanog.org/tg-0306/pdf/thomas.pdf .