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 г.).
В совокупности эти таблицы задают множество путей для разных видов трафика клиентов. В VPN применяется различная топология связей: полносвязная, «звезда» (часто называемая в англоязычной литературе hub-and-spoke) или ячеистая.
СНАЧАЛА НУЖНО РАЗМЕЖЕВАТЬСЯ
Для корректной работы VPN требуется, чтобы информация о маршрутах через магистральную сеть провайдера не распространялась за ее пределы, а сведения о маршрутах в клиентских сайтах не становились известными за границами определенных VPN.
Барьеры на пути распространения маршрутных объявлений могут устанавливаться соответствующим конфигурированием маршрутизаторов. Протокол маршрутизации должен быть оповещен о том, с каких интерфейсов и от кого он имеет право принимать объявления определенного сорта и на какие интерфейсы и кому их распространять.
Роль таких барьеров в сети MPLS VPN играют пограничные маршрутизаторы PE. Можно представить, что через маршрутизатор PE проходит невидимая граница между зоной клиентских сайтов и зоной ядра сети провайдера. По одну сторону располагаются интерфейсы, через которые PE взаимодействует с маршрутизаторами P, а по другую — интерфейсы, к которым подключаются сайты клиентов. С одной стороны на PE поступают объявления о маршрутах магистральной сети, с другой стороны — объявления о маршрутах в сетях клиентов.
На Рисунке 3 показан маршрутизатор PE, на котором установлены несколько протоколов класса IGP. Один из них сконфигурирован для приема и распространения маршрутных объявлений только с тех трех внутренних интерфейсов, которые связывают этот PE с маршрутизаторами P. Два других протокола IGP обрабатывают маршрутную информацию от сайтов клиентов.
Аналогичным образом настроены и остальные PE. Маршрутизаторы P принимают и обрабатывают маршрутную информацию IGP, поступающую со всех интерфейсов. В результате на всех маршрутизаторах PE и P создается по таблице маршрутизации, где содержатся все маршруты в пределах внутренней сети провайдера. Подчеркнем, что никакой информации о маршрутах в сетях клиентов в этих таблицах нет. Вместе с тем, и сети клиентов ничего не «знают» о маршрутах в сети провайдера. Таблица маршрутизации, создаваемая на пограничных маршрутизаторах PE на основе объявлений из магистральной сети, имеет специальное название «глобальная таблица маршрутизации». В отличие от нее таблицы, которые PE формирует на основе объявлений, поступающих из сайтов клиентов, получили название таблиц VRF (VPN Routing and Forwarding, VRF), которые PE формирует на основе объявлений, поступающих из сайтов клиентов.
Сайты клиентов представляют собой обычные сети IP, маршрутная информация в которых может передаваться и обрабатываться с помощью любого протокола маршрутизации класса IGP. Очевидно, что этот процесс никак не регламентируется провайдером. Маршрутные объявления свободно распространяются между узлами в пределах каждого сайта до тех пор, пока они не доходят до пограничных маршрутизаторов PЕ, служащих преградой для их дальнейшего распространения.
Разграничение маршрутов разных клиентов обеспечивает установка на маршрутизаторах PE отдельного протокола маршрутизации на каждый интерфейс, к которому подключен сайт клиента. Этот протокол принимает и передает клиентские маршрутные объявления только с одного определенного для него интерфейса, не пересылая их ни на внутренние интерфейсы, через которые PE связан с маршрутизаторами P, ни на интерфейсы, к которым подключены сайты других клиентов. В результате на маршрутизаторе PE создается несколько таблиц маршрутизации VRF.
Несколько упрощая, можно считать, что на каждом PE создается столько таблиц VRF, сколько сайтов к нему подключено. Фактически на маршрутизаторе PE организуется несколько виртуальных маршрутизаторов, каждый из которых работает со своей таблицей VRF. Возможно и другое соотношение между сайтами и таблицами VRF. Например, если к некоторому PE подключено несколько сайтов одной и той же VPN, то для них может быть создана общая таблица VRF. На Рисунке 3 показаны две таблицы VRF, одна из которых содержит описание маршрутов к узлам сайта А, а другая — к узлам сайта В. К каждой такой таблице можно получить доступ только с сайтов, относящихся к этой же VPN.
...А ПОСЛЕ ЭТОГО — ОБЪЕДИНИТЬСЯ
Чтобы связать территориально разнесенные сайты заказчика в единую сеть, необходимо, во-первых, создать для них общее пространство распространения маршрутной информации, а, во-вторых, проложить во внутренней сети пути, по которым принадлежащие разным сайтам узлы одной и той же VPN могли вести обмен данными защищенным образом.
Механизмом, с помощью которого сайты одной VPN обмениваются маршрутной информацией, является уже упоминавшееся многопротокольное расширение для BGP (MultiProtocol extensions for BGP-4, MP-BGP; RFC 2858). С помощью этого протокола пограничные маршрутизаторы PE организуют взаимные сеансы и в рамках этих сеансов обмениваются маршрутной информацией из своих таблиц VRF.
Особенность протокола BGP и его расширений заключается в том, что он получает и передает свои маршрутные объявления не всем непосредственно связанным с ним маршрутизаторам, как протоколы IGP, а только тем, которые указаны в конфигурационных параметрах в качестве соседей. Маршрутизаторы PE сконфигурированы так, что все получаемые от клиентских сайтов маршрутные объявления они адресно пересылают с помощью MP-BGP определенным пограничным маршрутизаторам PE. Вопрос о том, кому отправлять маршрутные объявления, а кому нет, целиком зависит от топологии виртуальных частных сетей, поддерживаемых данным провайдером. Так, на Рисунке 2 маршрутизатор PE1 передает маршруты из таблицы VRF сайта 1 в VPN A на маршрутизаторы PE2, PE3, PE5, к которым подключены остальные сайты 2, 3 и 4 той же VPN A. Полученный маршрут заносится в таблицу VRF соответствующего сайта.
Таким образом, кроме маршрутов, поступающих от непосредственно подсоединенных к PE сайтов, каждая таблица VRF дополняется маршрутами, получаемыми от других сайтов данной VPN по протоколу MP-BGP. Целенаправленное распространение маршрутов между маршрутизаторами PE обеспечивается надлежащим выбором атрибутов протокола MP-BGP (эти атрибуты описаны в документе «BGP Extended Communities Attribute», имеющем пока статус Internet Draft), что детально рассматривается ниже.
НЕЗАВИСИМОСТЬ АДРЕСНЫХ ПРОСТРАНСТВ
Если некоторое множество узлов никогда ни при каких условиях не получает маршрутную информацию от другого множества узлов, то адресация узлов в пределах каждого из этих множеств может выполняться независимым образом.
Ограничение области распространения маршрутной информации пределами отдельных VPN изолирует адресные пространства каждой VPN, позволяя применять в ее пределах как публичные адреса Internet, так и частные (private) адреса, зарезервированные в соответствии с RFC 1819.
Почему же в таком случае не сделать выбор адресов в пределах VPN совершенно произвольным и ограниченным только общими правилами адресации стека TCP/IP? Дело в том, что во многих случаях клиенты не хотят полной изоляции VPN: в частности, они нуждаются в выходе в Internet. Независимое же, не согласованное с регламентирующими органами Internet, назначение адресов узлам VPN может привести к совпадению внутренних адресов сайтов с уже выделенными публичными адресами, в результате чего связь с Internet станет невозможной. При использовании зарезервированных частных адресов проблема связи клиентов VPN с внешним миром решается с помощью стандартной техники трансляции адресов (Network Address Translator, NAT), описанной в RFC 3022 (подробнее об этом можно прочитать в статье одного из авторов «Маскарад» адресов» в декабрьском номере «Журнала сетевых решений/LAN» за 2001 г.). В любом случае должно соблюдаться требование уникальности адресов в пределах VPN.
Использование в разных VPN одного и того же адресного пространства создает проблему для маршрутизаторов PE. Протокол BGP изначально был разработан в предположении, что все адреса, которыми он манипулирует, во-первых, относятся к семейству адресов IPv4 и, во-вторых, однозначно идентифицируют узлы сети, т. е. являются глобально уникальными в пределах всей составной сети. Ориентация на глобальную уникальность адресов выражается в том, что, получив очередное маршрутное объявление, протокол BGP анализирует его, не обращая внимания на то, какой VPN принадлежит этот маршрут. Если на вход BGP поступают описания маршрутов к узлам разных VPN, но с совпадающими адресами IPv4, то BGP считает, что все они ведут к одному и тому же узлу, а, следовательно, как и полагается в таком случае, он помещает в соответствующую таблицу VRF только один кратчайший маршрут.
Проблема решается за счет применения вместо потенциально неоднозначных адресов IPv4 расширенных и однозначных адресов нового типа, а именно адресов VPN-IPv4, получаемых в результате преобразования исходных адресов IPv4. Преобразование заключается в том, что ко всем адресам IPv4, составляющим адресное пространство той или иной VPN, добавляется префикс, называемый различителем маршрутов (Route Distinguisher, RD), который уникально идентифицирует эту VPN. В результате на маршрутизаторе PE все адреса, относящиеся к разным VPN, обязательно будут отличаться друг от друга, даже если они имеют совпадающую часть — адрес IPv4.
Именно здесь оказалась полезной способность расширенного протокола MP-BGP переносить в маршрутных объявлениях адреса разных типов, в том числе IPv6, IPX, а, главное, VPN-IPv4. Адреса VPN-IPv4 используются только для маршрутов, которыми маршрутизаторы PE обмениваются по протоколу BGP. Прежде чем передать своему напарнику некоторый маршрут, входной маршрутизатор PE добавляет к его адресу назначения IPv4 префикс RD для данной VPN, тем самым преобразуя его в маршрут VPN-IPv4.
Как уже было сказано, различители маршрута должны гарантированно уникально идентифицировать VPN, чтобы избежать дублирования адресов. Упростить выбор RD, не создавая для этих целей дополнительных централизованных процедур (например, распределения RD органами Internet подобно распределению адресов IPv4), предлагается за счет использования в качестве основы для RD заведомо уникальных чисел — либо номеров автономных систем, либо глобальных адресов интерфейсов PE с магистральной сетью провайдера (сети провайдера всегда необходимы глобальные адреса для взаимодействия с сетями других провайдеров).
Различитель маршрутов 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.