Технология MPLS L3VPN

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

Существует два варианта сетей MPLS VPN.

В обоих случаях внутри сети поставщика услуг клиентский трафик передается с помощью технологии MPLS.

ПРИМЕЧАНИЕ

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

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

Полная связность при абсолютной изолированности

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

Эту задачу современному поставщику услуг приходится решать в противоречивых условиях доминирования технологии IP как универсального транспорта. Действительно, один из основных принципов работы составной IP-сети заключается в автоматическом связывании всех сетей в одно целое за счет распространения по сети маршрутной информации протоколами маршрутизации, такими как BGP, OSPF, IS-IS, RIP. С помощью подобного механизма на каждом маршрутизаторе сети автоматически создается таблица маршрутизации, в которой указываются пути следования пакетов к каждой из сетей, включенных в составную сеть (пути к отдельным сетям могут агрегироваться, но это не меняет сути).

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

Для того чтобы изолировать сети друг от друга, достаточно поставить между ними заслон на пути распространения маршрутной информации. Для обмена маршрутной информацией в пределах сети узлы пользуются одним из внутренних протоколов маршрутизации (IGP), таким как RIP, OSPF или IS-IS, область действия которого ограничена автономной системой. Если в таблице маршрутизации узла А нет записи о маршруте к узлу В (и отсутствует запись о маршруте по умолчанию), то говорят, что узел А не «видит» узла В.

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

Рис. 1. Изоляция клиентских сетей с помощью туннелей

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

Но как же все-таки связать территориально разнесенные сети клиента в единую виртуальную частную сеть, если внутренняя сеть поставщика услуг ничего о них не знает, во всяком случае, на уровне обычных таблиц маршрутизации? Для этого применяется достаточно традиционное средство — туннель между пограничными маршрутизаторами внутренней сети. Особенность рассматриваемой технологии состоит в применение туннеля MPLS (альтернативные решения могли бы основываться на туннелях IPSec или других туннелях класса «IP поверх IP»). Преимуществом туннелей MPLS VPN являются автоматический способ их прокладки и выгоды, получаемые за счет применения технологии MPLS как таковой и касающиеся ускоренного продвижения пакетов по сети поставщика услуг и управления качеством обслуживания (QoS) для туннелей с инжинирингом трафика.

Для того чтобы описанные принципы построения MPLS VPN смогли найти воплощение в реальной сети, было разработано несколько специфических сетевых механизмов и компонентов.

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

В сети MPLS VPN легко выделить две области (рис. 2):

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

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

Маршрутизатор, с помощью которого сайт клиента подключается к магистрали поставщика, называется пограничным устройством клиента (Customer Edge router, CE). Будучи компонентом сети клиента, маршрутизатор CE ничего не знает о существовании VPN. Он может быть соединен с магистральной сетью поставщика услуг несколькими каналами.

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

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

Маршрутизаторы CE и PE обычно связаны непосредственно физическим каналом, на котором работает какой-либо протокол канального уровня, например, PPP, FR, ATM или Ethernet. Общение между CE и PE идет по стандартным протоколам стека TCP/IP. Поддержка MPLS нужна только для внутренних интерфейсов PE и всех интерфейсов P. Иногда полезно различать относительно направления продвижения трафика входной и выходной ( удаленный) маршрутизаторы PE.

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

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

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

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

Разграничение маршрутной информации

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

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

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

На рис. 3 показана схема разграничения маршрутной информации. На маршрутизаторе PE установлено несколько протокольных модулей IGP. Один из них сконфигурирован для приема и распространения маршрутных объявлений только с тех трех внутренних интерфейсов, которые связывают этот маршрутизатор PE с маршрутизаторами P. Два других модуля IGP обрабатывают маршрутную информацию от сайтов клиентов.

Рис. 3. Схема разграничения маршрутной информации

Аналогичным образом настроены и остальные устройства PE. Внутренние маршрутизаторы P принимают и обрабатывают маршрутную информацию протокола IGP, поступающую со всех интерфейсов. В результате на всех маршрутизаторах (и PE, и P) создается по таблице маршрутизации, где содержатся все маршруты в пределах внутренней сети поставщика услуг. Подчеркнем, что никакой информации о маршрутах к сетям клиентов в таблицах внутренних маршрутизаторов нет. Сети клиентов также ничего не «знают» о маршрутах в сети поставщика услуг.

На каждом из маршрутизаторов PE создается два типа таблиц маршрутизации:

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

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

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

Возможно и другое соотношение между сайтами и таблицами VRF. Например, если к некоторому пограничному маршрутизатору подключено несколько сайтов одной и той же сети VPN, то для них может быть создана одна общая таблица VRF. На рис. 3 показаны две таблицы VRF, одна из которых содержит описание маршрутов к узлам сайта А (VRF А), а другая — к узлам сайта В (VRF В).

Использование протокола MP-BGP для связывания сайтов

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

Механизмом, с помощью которого сайты, принадлежащие одной и той же сети VPN, обмениваются маршрутной информацией, является уже упоминавшееся многопротокольное расширение для протокола BGP (MultiProtocol extensions for BGP, MP-BGP). Подробное описание этого протокола можно найти в спецификации RFC 2858. С его помощью пограничные маршрутизаторы организуют сеансы связи, в рамках которых обмениваются маршрутной информацией из своих таблиц VRF.

Особенность протокола BGP и его расширений заключается в том, что он получает и передает свои маршрутные объявления не всем непосредственно связанным с ним маршрутизаторам, как протоколы IGP, а только тем, которые указаны в его конфигурационных параметрах в качестве соседей. Причем соседями могут быть «назначены» маршрутизаторы, находящиеся на расстоянии многих хопов. Маршрутизатор PE сконфигурирован так, что все получаемые от клиентских сайтов маршрутные объявления он с помощью MP-BGP пересылает только определенным в качестве соседей другим пограничным маршрутизаторам PE. Целенаправленное распространение маршрутов между маршрутизаторами PE обеспечивается надлежащим выбором атрибутов протокола MP-BGP (эти атрибуты описаны в документе «BGP Extended Communities Attribute», имеющем пока статус проекта стандарта Интернета).

Вопрос о том, кому отправлять маршрутные объявления, а кому нет, целиком зависит от топологии виртуальных частных сетей, поддерживаемых данным поставщиком услуг. Так, на рис. 2 маршрутизатор PE1 передает маршруты из таблицы VRF сайта 1, относящегося к сети VPN A, маршрутизаторам PE2, PE3, PE5, к которым подключены остальные сайты 2, 3 и 4 той же сети VPN A. Полученные маршруты заносятся в таблицы VRF соответствующих сайтов.

Итак, помимо маршрутов, поступающих от непосредственно подсоединенных к устройству PE сайтов, каждая таблица VRF дополняется маршрутами, получаемыми от других сайтов данной сети VPN по протоколу MP-BGP. Таким путем создаются таблицы, описывающие маршруты в рамках отдельной сети VPN.

Независимость адресных пространств

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

Ограничение области распространения маршрутной информации пределами отдельных сетей VPN изолирует адресные пространства каждой сети VPN, позволяя применять в ее пределах как публичные адреса Интернета, так и частные адреса, зарезервированные в соответствии со спецификацией RFC 1819.

Почему же в таком случае не сделать выбор адресов в пределах VPN совершенно произвольным и ограниченным только общими правилами адресации стека TCP/IP? Дело в том, что во многих случаях клиенты не хотят полной изоляции VPN: в частности, они нуждаются в выходе в Интернет. Независимое же (не согласованное с регламентирующими органами Интернета) назначение адресов узлам VPN может привести к совпадению внутренних адресов сайтов с уже использованными в Интернете публичными адресами, в результате чего связь с Интернетом станет невозможной. При применении зарезервированных частных адресов проблема связи клиентов VPN с внешним миром решается с помощью стандартной техники трансляции адресов (NAT). В любом случае должно соблюдаться требование уникальности адресов в пределах VPN.

Однако использование в разных сетях VPN одного и того же адресного пространства создает проблему для маршрутизаторов PE. Протокол BGP изначально был разработан в предположении, что все адреса, которыми он манипулирует, во-первых, относятся к семейству адресов IPv4 и, во-вторых, однозначно идентифицируют узлы сети, то есть являются глобально уникальными в пределах всей составной сети. Ориентация на глобальную уникальность адресов выражается в том, что получив очередное маршрутное объявление, протокол BGP анализирует его, не обращая внимания на то, какой сети VPN принадлежит этот маршрут. Если на вход BGP поступают описания маршрутов к узлам разных сетей VPN, но с совпадающими адресами IPv4, то протокол BGP считает, что все они ведут к одному и тому же узлу, а, следовательно, как и предусмотрено в алгоритме его работы, он помещает в соответствующую таблицу VRF только один лучший (в соответствии с правилами выбора BGP) маршрут.

Эта проблема была решена в MPLS VPN применением вместо потенциально неоднозначных адресов IPv4 расширенных и однозначных адресов нового типа, а именно адресов VPN-IPv4, получаемых путем преобразования исходных адресов IPv4. Преобразование заключается в том, что ко всем адресам IPv4, составляющим адресное пространство той или иной сети VPN, добавляется префикс, который называется различителем маршрутов (Route Distinguisher, RD) и который уникально идентифицирует эту сеть. В результате на маршрутизаторе PE все адреса, относящиеся к разным сетям VPN, обязательно будут отличаться друг от друга, даже если они имеют совпадающую часть — адрес IPv4.

Именно здесь оказалась полезной способность расширенного протокола MP-BGP переносить в маршрутных объявлениях адреса разных типов, в том числе IPv6, IPX, а главное — VPN-IPv4. Адреса VPN-IPv4 используются только для маршрутов, которыми маршрутизаторы PE обмениваются по протоколу BGP. Прежде чем передать своему напарнику некоторый маршрут, входной маршрутизатор PE добавляет к его адресу назначения IPv4 префикс RD для данной сети VPN, тем самым преобразуя его в адрес VPN-IPv4.

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

RD имеет длину 8 байт и состоит из трех полей.

Рис. 4 иллюстрирует сложный процесс обмена маршрутными объявлениями в сети MPLS VPN. Этот процесс включает преобразование адресов из формата IPv4 в формат VPN-IPv4, фильтрацию маршрутных объявлений (операции экспорта-импорта) и добавление к объявлениям меток VPN. Мы последовательно будем рассматривать эти вопросы, поэтому читатель должен быть готов к тому, что не все на рисунке ему будет нужно и понятно с самого начала.

Рис. 4. Маршрутные объявления MP-BGP

Итак, на рис. 4 показан пример преобразования адресов формата IPv4 с целью обеспечения уникальности адресов в рамках всех сетей VPN одного поставщика услуг. При формировании RD для каждой из сетей VPN администратор сети сначала выбирает глобальный адрес одного из внешних интерфейсов маршрутизатора PE1 (на рисунке это адрес 123.45.67.89), затем добавляет к нему через двоеточие 1, получая значение RD, равное 123.45.67.89:1. Формат RD представлен в табл. 1.

Таблица 1. Формат RD

Поле типа (2 байта)

Поле администратора (4 байта)

Поле назначенного номера (2 байта)

0

123.45.67.89

1

Указанное значение RD администратор назначает для сети VPN A. При конфигурировании маршрутизаторов PE администратор указывает это значение для всех таблиц VRF, которые соответствуют сети VPN A. В частности, он задает это значение при создании VRF 1 A, так что для протокола MP- BGP все адреса формата IPv4, которые находятся в таблице VRF1 A, будут иметь значение RD, равное 123.45.67:1, в том числе все адреса с префиксом 10.1/16, которые PE1 получает от маршрутизатора CE1 сайта 1 в сети VPN  A.

Аналогично, администратор выбирает для сетей VPN B значение RD, равное 123.45.67.89:2, которое он указывает при конфигурировании VRF 1 B на маршрутизаторе PE1. Это значение RD будет добавляться ко всем адресам IPv4, хранящимся в таблицах VRF 1 B, при обработке их протоколом MP- BGP.

ПРИМЕЧАНИЕ

Все маршруты в таблицах VRF содержат адреса в формате IPv4.

Сформированные маршруты в формате VPN- IPv4 маршрутизатор PE1 передает по протоколу MP-BGP на маршрутизатор PE2, к которому подключен сайт 2 сети VPN  B. Только благодаря добавлениям значения RD протоколы BGP, работающие на удаленных маршрутизаторах PE, различают маршруты с совпадающими адресами IPv4, относящимися к разным сетям VPN.

Документ RFC 2547bis не требует, чтобы все маршруты внутри одной сети VPN индексировались одним и тем же значением RD. Более того, один и тот же сайт, подключенный к разным интерфейсам одного маршрутизатора PE или к разным маршрутизаторам PE, может иметь разные значения RD. Благодаря этому путь к одному и тому же узлу может описываться разными маршрутами, что дает возможность выбора того или иного маршрута для различных пакетов. Однако принципиально важно, чтобы значения RD разных сетей VPN не совпадали.

Генерация маршрутных объявлений MP-BGP

При получении от сайта клиента нового маршрута по протоколу класса IGP, такому как RIP, OSPF или IS-IS, маршрутизатор PE заносит его в соответствующую таблицу VRF и распространяет дальше между другими сайтами данной сети VPN. Обмен маршрутной информацией между сайтами каждой отдельной сети VPN выполняется под управлением протокола MP-BGP. Маршрутное объявление MP-BGP имеет следующий набор атрибутов, расширенный по сравнению с протоколом BGP:

Пусть, например, маршрутизатор PE1 получает с сайта 1 сети VPN A по протоколу класса IGP следующее объявление о маршруте в формате IPv4 (см. рис. 4):

Net = 10.1.0.0

NextHop = CE1

На основании этого объявления в таблицу VRF 1 A заносится соответствующая запись. Протокол BGP периодически просматривает таблицу VRF 1 A, и обнаружив новую запись, генерирует объявление о маршруте, для чего выполняет следующие действия.

В результате получается такое маршрутное объявление:

VPN - IPv 4: 123.45.67.89:1:10.1.0.0

Nexthop = 123.45.7.5

LVPN = 7

RT = WHITE

Это объявление протокол MP-BGP посылает всем своим соседям (на рисунке объявление помещено внутрь широкой стрелки).

Когда выходной маршрутизатор PE получает маршрут к сети VPN-IPv4, он делает обратное преобразование, отбрасывая префикс RD, и только потом помещает маршрут в таблицу VRF2 A и объявляет о нем связанному с ним маршрутизатору заказчика CE3 из данной сети VPN A. В результате в таблице VRF2 A появляется новая запись:

Net = 10.1/16

Nexthop = 123.45.7.5 (BGP)

LVPN = 7

Перемещение пакета по сети MPLS VPN

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

Пусть, например, с сайта 2 сети VPN A узел с адресом 10.2.1.1/16 отправляет пакет узлу сайта 1 этой же сети VPN, имеющему адрес 10.1.0.3/16 (рис. 5). Стандартными транспортными средствами IP-пакет доставляется на пограничный маршрутизатор сайта CE3, в таблице которого для номера сети 10.1.0.0 в качестве следующего маршрутизатора указан маршрутизатор PE2. На маршрутизатор PE2 пакет поступает с интерфейса 2, поэтому для дальнейшего продвижения пакета он обращается к таблице VRF2А, связанной с данным интерфейсом.

Рис. 5. Путешествие пакета по сети MPLS VPN

В таблице VRF2A адресу 10.1.0.0 соответствует запись протокола BGP, которая указывает, что следующим маршрутизатором ( next hop) для пакета определен маршрутизатор PE1. Поле метки содержит значение LVPN = 7, определяющее интерфейс выходного маршрутизатора PE1. Это значения должно быть присвоено пакету для того, чтобы он попал в нужную сеть VPN. Здесь также указывается, что запись была сделана протоколом BGP, а не IGP. На этом основании маршрутизатор PE2 «понимает», что очередной маршрутизатор не является непосредственным соседом, и путь к нему надо искать в глобальной таблице маршрутизации.

В глобальной таблице для адреса PE1 указывается начальное значение метки пути LSP, равное 3. Мы не будем останавливаться на способе прокладки пути между маршрутизаторами PE1 и PE2 — этот вопрос мы обсуждали в главе 20 при изучении технологии MPLS.

В сетях MPLS VPN используются иерархические свойства путей MPLS, за счет которых пакет может быть снабжен несколькими метками, помещаемыми в стек. На входе во внутреннюю сеть поставщика, образуемую маршрутизаторами P, пакет будет снабжен двумя метками LVPN = 7 и L = 3. Метка LVPN интерпретируется как метка нижнего уровня — оставаясь на дне стека, она не используется, пока пакет путешествует по туннелю PE1-PE2. Продвижение пакета происходит на основании метки верхнего уровня L. Каждый раз, когда пакет проходит очередной маршрутизатор P вдоль туннеля, метка L анализируется и заменяется новым значением. И только после достижения конечной точки туннеля — маршрутизатора PE1 — из стека извлекается метка LVPN. В зависимости от ее значения пакет направляется на тот или иной выходной интерфейс маршрутизатора PE1 (на рис. 4 этот интерфейс обозначен как int7).

Из таблицы VRF1А, связанной с данным интерфейсом и содержащей маршруты VPNA, извлекается запись о маршруте к узлу назначения, указывающая на устройство CE1 в качестве следующего маршрутизатора. Заметим, что запись об этом маршруте была помещена в таблицу VRF1А протоколом IGP. Последний отрезок путешествия пакета от CE1 до узла 10.1.0.3 осуществляется традиционными средствами IP.

Механизм формирования топологии VPN

Политика экспорта/импорта маршрутов — мощный инструмент создания сетей VPN разных топологий.

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

Маршрутные объявления MP-BGP всегда несут атрибут RT, говорящий об экспорте маршрута. Сравнение значений атрибутов RT в маршрутном объявлении и в параметрах VRF позволяет решить вопрос о принятии или отклонении предлагаемого маршрута. А это и означает формирование топологии сети. Рассмотрим этот механизм на примере.

Пусть изображенный на рис. 4 маршрутизатор PE2 получил объявление от PE1. Прежде, чем сохранить информацию о маршруте, он проверяет значение атрибута RT, содержащееся в объявлении, на совпадение с политикой импорта всех своих таблиц VRF, в данном случае VRF2A и VRF2B. Значение атрибута RT равно WHITE, поэтому маршрут добавляется (после преобразования в формат IPv4 путем удаления префикса RD) только в таблицу VRF2A, так как для нее определена политика импорта WHITE. Таблица VRF2B остается в неизменном виде, так как ее политика импорта говорит о том, что в нее должны помещаться только маршруты с атрибутом RT, равным GRAY.

Задание одного и того же значения для политики экспорта и импорта для всех таблиц VRF определенной сети VPN (именно этот случай для сети VPN A показан на рис. 4) приводит к полносвязной топологии — каждый сайт может посылать пакеты непосредственно тому сайту, в котором находится сеть назначения.

Существуют и другие варианты топологии VPN. Например, за счет конфигурирования политики экспорта/импорта можно реализовать такую популярную топологию, как «звезда», когда все сайты (spoke) общаются друг с другом через выделенный центральный сайт (hub).

Для достижения этого эффекта достаточно определить для VRF центрального сайта политику импорта как Import = spoke, а экспорта как Export = hub, а на таблицах VFR периферийных сайтов поступить наоборот, задав Import = hub, а Export  = spoke (рис.  6). В результате таблицы VRF периферийных сайтов не будут принимать маршрутные объявления друг от друга, поскольку они передаются по сети протоколом MP-BGP с атрибутом RT = spoke, между тем как их политика импорта разрешает получать объявления с атрибутом RT = hub. Зато объявления VRF периферийных сайтов принимает таблица VRF центрального сайта, для которого как раз и определена политика импорта spoke. Этот сайт обобщает все объявления периферийных сайтов и отсылает их обратно, но уже с атрибутом RT = hub, что совпадает с политикой импорта периферийного сайта. Таким образом, в таблицах VRF каждого периферийного сайта появляются записи о сетях в других периферийных сайтах. А в качестве следующего транзитного узла указывается адрес интерфейса PE, связанного с центральным сайтом, поскольку объявление пришло от него. Поэтому пакеты между периферийными сайтами проходят транзитом через пограничный маршрутизатор PE3, подключенный к центральному сайту.

Рис. 6. Конфигурирование звездообразной топологии для сети VPN  A

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

Степень защищенности

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

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

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