наверх

Главная, «Журнал сетевых решений/LAN», № 03, 2002 7201 прочтение

MPLS на службе VPN

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

Олифер Виктор, Олифер Наталья

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

«Не в совокупности ищи единства,

но более — в единообразии разделения».

Козьма Прутков

Виртуальные частные сети на основе MPLS (MPLS VPN) привлекают сегодня всеобщее внимание. Количество ведущих провайдеров услуг, предлагающих своим клиентам воспользоваться новым видом сервиса для экономичного построения сетей Intranet и Extranet, постоянно растет, делая MPLS VPN доступными для пользователей все большего числа стран и регионов. От других способов построения виртуальных частных сетей, подобно VPN на базе ATM/FR или IPSec, MPLS VPN выгодно отличает высокая масштабируемость, возможность автоматического конфигурирования и естественная интеграция с другими сервисами IP, которые сегодня входят в обязательное меню любого успешного провайдера: доступом к Internet, Web и почтовыми службами, хостингом. Несмотря на критику, порой весьма острую, некоторых аспектов MPLS VPN (дискуссия по поводу достоинств и недостатков MPLS VPN по отношению к другим способам построения VPN анализируется в статье авторов «Виртуальные частные сети на основе MPLS» в январском номере «Журнала сетевых решений/LAN» за 2001 г.), эта технология уверенно прокладывает дорогу в жизнь и потому заслуживает детального изучения. В данной статье рассматриваются базовые механизмы виртуальных частных сетей на основе MPLS, знание которых позволит читателю более объективно оценить новую технологию. Основным документом, регламентирующим организацию MPLS VPN, является информационный RFC 2547bis.

ПОЛНАЯ СВЯЗНОСТЬ ПРИ АБСОЛЮТНОЙ ИЗОЛИРОВАННОСТИ

Каждый клиент хочет, чтобы провайдер услуг VPN связал между собой его сети, при этом полученная единая сеть должна быть совершенно изолирована от подобных сетей других клиентов. Эту задачу современному провайдеру приходится решать в противоречивых условиях доминирования технологии IP как универсального транспорта. Действительно, один из основных принципов работы составной сети IP заключается в автоматическом связывании всех сетей в одно целое за счет распространения по сети маршрутной информации протоколами маршрутизации, такими как BGP, OSPF, IS-IS, RIP. С помощью подобного механизма на каждом маршрутизаторе сети создается таблица маршрутизации, в которой указываются пути следования пакетов к каждой из сетей, включенных в составную сеть (пути к отдельным сетям могут агрегироваться, но это не меняет сути рассматриваемого вопроса). Провайдер может, конечно, обойти указанную проблему, вообще отказавшись от применения протокола IP для объединения сайтов клиента, — так поступают операторы, которые предлагают подключаться к своим сетям по другим протоколам, чаще всего по frame relay и ATM. Но тогда теряется возможность оказывать клиенту услуги IP, а пойти на это провайдеру на нынешнем рынке с высоким уровнем конкуренции очень нелегко. Конечно, можно поддерживать различные наборы услуг с помощью разных протоколов (как и действуют многие провайдеры), но и это не самое лучшее решение — и клиенту, и провайдеру «мешанина» протоколов создает много сложностей. Привлекательность MPLS VPN как раз и состоит в том, что они относятся к классу услуг IP, причем изолированность сетей достигается без отказа от этого всепроникающего протокола.

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

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

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

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

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

КОМПОНЕНТЫ MPLS VPN

Прежде всего, сеть MPLS VPN делится на две области: сети IP клиентов и внутренняя (магистральная) сеть MPLS провайдера, которая необходима для объединения сетей клиентов (см. Рисунок 2).

В общем случае у каждого клиента может быть несколько территориально обособленных сетей IP, каждая из которых в свою очередь может включать несколько подсетей, связанных маршрутизаторами. Такие территориально изолированные сетевые «островки» корпоративной сети принято называть сайтами. Принадлежащие одному клиенту сайты обмениваются пакетами IP через сеть провайдера и образуют виртуальную частную сеть этого клиента. Например, о корпоративной сети, в которой сеть центрального отделения связывается с тремя удаленными филиалами, можно сказать, что она состоит из четырех сайтов. Для обмена маршрутной информацией в пределах сайта узлы пользуются одним из внутренних протоколов маршрутизации (Interior Gateway Protocol, IGP), область действия которого ограничена автономной системой: RIP, OSPF или IS-IS.

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

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

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

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

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

Пути LSP могут быть проложены двумя способами: либо с применением технологии ускоренной маршрутизации (IGP) с помощью протоколов LDP, либо на основе технологии Traffic Engineering с помощью протоколов RSVP или CR-LDP. Прокладка LSP означает создание таблиц коммутации меток на всех маршрутизаторах PE и P, образующих данный LSP (примеры таких таблиц можно найти в статье авторов «Искусство оптимизации трафика» в декабрьском номере «Журнала сетевых решений/LAN» за 2001 г.).

Различитель маршрутов RD имеет длину 8 байт и состоит из трех полей. Первое поле Type длиной 2 байт определяет тип и разрядность второго поля, которое называется Administrator и однозначно идентифицирует провайдера. Значение 0 поля Type говорит о том, что в поле Administrator указывается IP-адрес интерфейса маршрутизатора PE, и длина данного поля составляет, естественно, 4 байт. Если же значение Type равно 1, то в качестве идентификатора провайдера выбрано значение номера его автономной системы, так что длина поля Administrator составит уже 2 байт. Третье поле носит название Assigned Number, его назначение — обеспечить уникальность адресов VPN в пределах сети провайдера. Значения поля Assigned Number выбирает сам провайдер, при этом использование в качестве поля Administrator IP-адресов интерфейса PE более удобно, так как ограничивает требование уникальности значений Assigned Number пределами отдельного PE.

На Рисунке 4 показано, как входной маршрутизатор PE1 добавляет различитель маршрутов 123.45.67.89:1 (123.45.67.89 — это глобальный адрес интерфейса маршрутизатора PE, а 1 — назначенный администратором номер) ко всем адресам с префиксом 10.1/16, которые он получает от маршрутизатора CE сайта 1 в VPN A, и пересылает эти маршруты на два других выходных маршрутизатора PE. Аналогично, маршрутизатор PE1 добавляет различитель маршрутов 123.45.67.89:2 к адресам с префиксом 10.1/16 в маршрутах, которые он получает от маршрутизатора CE сайта 1 в VPN B, и передает сформированные маршруты на другие два маршрутизатора PE. Только благодаря этим добавлениям, протокол BGP, работающий на удаленных PE, принимает во внимание маршруты с совпадающими адресами IPv4, относящиеся к разным VPN.

Когда выходной PE получает маршрут к сети VPN-IPv4, он делает обратное преобразование, отбрасывая префикс RD, и только потом помещает его в таблицу VRF и объявляет этот маршрут связанному с ним маршрутизатору заказчика CE из данной VPN. Таким образом, все маршруты в таблицах VRF содержат адреса в формате IPv4.

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

ЭКСПОРТНО/ИМПОРТНЫЕ ОПЕРАЦИИ

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

  • Адрес сети назначения в формате VPN-IPv4.
  • Адрес следующего маршрутизатора (BGP next hop). Протокол BGP указывает в данном случае адрес одного из внутренних (идущих к маршрутизаторам P) интерфейсов того PE, на котором он работает. Этот адрес также записывается в формате VPN-IPv4 с RD=0, поскольку протокол MP-BGP требует, чтобы в маршрутном объявлении адрес следующего маршрутизатора соответствовал по своему типу адресу назначения.
  • Метка (VPN label) уникально определяет внешний интерфейс маршрутизатора PE и подключенный к нему сайт клиента, куда ведет объявляемый маршрут. Она назначается маршруту входным PE при получении им локального маршрута от присоединенного CE.
  • Расширенные атрибуты сообщества (Extended community attributes), один из которых - route-target (RT) - является обязательным. Этот атрибут идентифицирует набор сайтов (VRF), входящих в данную VPN, которым PE должен посылать маршруты.

Значение атрибута route-target в объявлении о маршруте определяется политикой экспорта маршрутных объявлений (export target policy), которая была задана при конфигурировании таблицы VRF, содержащей данный маршрут. Если же маршрут не входит в число экспортируемых, то он не передается другим PE, а используется локально. Такое возможно в случае, когда два маршрутизатора CE в одной и той же VPN прямо подключены к одному и тому же маршрутизатору PE. Формат атрибута route-target аналогичен формату различителя маршрутов RD, что обеспечивает его уникальность в пределах всех VPN.

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

Net = 10.1.0.0,
Next-Hop=CE1

До передачи этого объявления далее PE1 транслирует его в формат VPN-IPv4, для чего выполняет следующие действия:

  • добавляет к адресу сети назначения различитель маршрутов RD (в данном случае он равен 123.45.67.89:1);
  • переписывает значение поля Next-Hop, заменяя адрес внешнего интерфейса CE1 на адрес внешнего интерфейса PE1, через который пролегает путь к адресу назначения (пусть в данном случае это будет 123.45.7.5);
  • назначает метку VPN, указывающую на VRF1А и интерфейс маршрутизатора PE1, к которому подключен сайт клиента, содержащий узел назначения (в данном случае значение метки равно 4);
  • задает атрибут RT (на Рисунке 4 значение атрибута RT условно обозначено Green, что идентифицирует набор всех сайтов, входящих в VPN A).

Полученное в результате маршрутное объявление:

VPN-IPv4: 123.45.67.89:1:10.1.0.0
Next-hop=123.45.7.5
Lvpn=4
RT=Green,

протокол MP-BGP посылает всем своим соседям.

При получении объявлений MP-BGP вступает в действие политика импорта маршрутов; как и политика экспорта, она задается при конфигурировании каждой таблицы VRF. Так, маршрутизатор PE2, получив объявление от PE1, проверяет атрибут route-target содержащихся в нем маршрутов VPN-IPv4 на совпадение с политикой импорта всех своих VFR, в данном случае VRF2A и VRF2B. Значение атрибута route-target равно GREEN, поэтому маршрут добавляется (после преобразования в формат IPv4 путем удаления различителя маршрутов RD) только в таблицу VRF2A, так как для нее определена политика импорта GREEN. Таблица VRF2B остается в неизменном виде, так как ее политика импорта говорит о том, что в нее должны помещаться только маршруты с атрибутом route-target RED.

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

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

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

ПУТЕШЕСТВИЕ ПАКЕТА ПО СЕТИ MPLS VPN

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

Пусть, например, из сайта 1 в VPN A узел с адресом 10.2.1.1/16 отправляет пакет узлу сайта 2 этой же VPN, имеющему адрес 10.1.0.3/16 (см. Рисунок 6). Стандартными транспортными средствами IP пакет доставляется на пограничный маршрутизатор сайта CE1A, в таблице которого для номера сети 10.1.0.0 в качестве следующего маршрутизатора указан PE1. На маршрутизатор PE1 пакет поступает с интерфейса int2, поэтому для выбора дальнейшего продвижения пакета он обращается к таблице VRF1а, связанной с данным интерфейсом.

В таблице VRF1A адресу 10.1.0.0 соответствует запись протокола BGP, которая указывает, что очередным маршрутизатором для пакета определен PE2. Следующее поле записи содержит значение метки Lvpn=7, определяющей интерфейс выходного маршрутизатора PE, которое должно быть присвоено пакету для того, чтобы он попал в нужную VPN. Здесь также указывается, что запись была сделана протоколом BGP, а не IGP. На этом основании маршрутизатор PE «понимает», что очередной маршрутизатор не является непосредственным соседом, и путь к нему надо искать в глобальной таблице маршрутизации.

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

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

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

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

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

Наталья Олифер — обозреватель «Журнала сетевых решений/LAN». С ней можно связаться по адресу: olifer@lanmag.ru. Виктор Олифер — главный специалист «Корпорации ЮНИ». С ним можно связаться по адресу: volifer@uni.ru.

Страница 1 2 3

Комментарии


20/05/2016 №05

Купить выпуск

Анонс содержания
«Журнал сетевых решений/LAN»

Подписка:

«Журнал сетевых решений/LAN»

на месяцев

c

Средство массовой информации - www.osp.ru. Свидетельство о регистрации СМИ сетевого издания Эл.№ ФС77-62008 от 05 июня 2015 г. Выдано Федеральной службой по надзору в сфере связи, информационных технологий и массовых коммуникаций (Роскомнадзором)