Mpls vpn что это такое
Перейти к содержимому

Mpls vpn что это такое

  • автор:

Организация VPN на базе MPLS

Таблица маршрутизации на устройстве PE1 представлена в табл N3.

Табл. N4. Таблица маршрутизации на устройстве PE1

N Протокол VRF Подсеть Next-Hop
1 OSPF A 10.1.1.0/24 CE1
2 OSPF А 10.3.1.0/24 CE2
3 RIP B 10.1.1.0/24 CE3
  • коммутации пакетов разных VPN внутри MPLS домена (устройствами LSR);
  • обмена маршрутной информацией между устройствами PE, включая информацию о VPN.

Отличие понятий VPN и VRF

  • множество интерфейсов PE, к которым подключаются CE из одного VPN;
  • VRF-таблица;
  • атрибуты и правила распространения маршрутной информации (об этом будет рассказано далее).

Механизм коммутации пакетов

  • входной PE — первое устройство PE на пути следования IP пакета от одного устройства CE до другого через MPLS домен;
  • выходной PE — последнее устройство PE на пути следования IP пакета от одного устройства CE до другого через MPLS домен.

Рис N3. Схема прохождения пакета VPN через MPLS домен.


Табл. N4. Таблица маршрутизации на PE1.

N Протокол VRF Подсеть Next-Hop Метка Комментарий
1 OSPF A 10.1.1.0/24 CE1
2 iBGP A 10.2.1.0/24 PE2 1000/345 О назначении меток будет сказано далее
3 RIP B 10.1.1.0/24 CE3
4 iBGP B 10.2.1.0/24 PE2 1020/345 О назначении меток будет сказано далее
5 OSPF/LDP PE2 P1 345 О назначении меток будет сказано далее

Рассмотрим записи таблицы маршрутизации устройства PE1.
Запись N1 была создана на основании маршрутной информации полученной от CE1 по протоколу OSPF. Так как данный маршрут был получен от устройства CE1, принадлежащего VPN A, то запись отнесена в VRF-таблицу A (колонка VRF).
Запись N3 была создана на основании маршрутной информации полученной от CE3 по протоколу RIP. Так как данный маршрут был получен от устройства CE3, принадлежащего VPN B, то запись отнесена в VRF-таблицу B.
Запись N5 была создана на основании протокола маршрутизации, функционирующего внутри MPLS домена, и протокола LDP. Метка 345 будет назначаться пакетам, предназначенным для PE2. То есть данная метка определяет LSP от PE1 до PE2.
Записи N2 и N4 были созданы на основании маршрутной информации полученной от PE2 (выходного PE) по протоколу iBGP. Данная информация содержала префиксы подсетей с указанием «внутренней» метки, которая для выходного PE определяет VRF-таблицу, к которой данные префиксы относятся. То есть, для каждого VPN маршрута (префикса) PE2 назначил метку, определяющую его локальный VRF к которому данный префикс относиться. Для VPN A это метка 1000, для В это 1020. Метки 1000 и 1020 — «внутренние» метки.
Так как next-hop-ом для маршрутов VRF является устройство не присоединенное к PE1 непосредственно, то для обеспечения коммутации сквозь MPLS домен назначается дополнительная «внешняя» метка 345, определяющая LSP до PE2. Таким образом, пакетам VPN назначается две метки. Рассмотрим таблицу коммутации на выходном PE (PE2).

Табл N5. Таблица коммутации на PE2.

Входной интерфейс Входная метка Выходной интерфейс Выходная метка
int0 1000 int1/VRF A нет
int0 1020 int2/VRF B нет
  • «внутренняя» метка определяет выходной интерфейс на выходном PE. В этом случае выходной интерфейс (и соответственно CE которому предназначен пакет) определяется значением этой метки;
  • «внутренняя» метка определяет VRF на выходном PE. В этом случае выходной интерфейс (и соответственно CE которому предназначен пакет) определяется после анализа соответствующей VRF-таблицы.

Рис N3. Схема прохождения пакета VPN через MPLS домен (повторение).


Рассмотрим прохождения пакета из VPN A от CE1 до CE2 через MPLS-домен.
1.1 PE1 получает пакет от CE1. По интерфейсу от которого пришел пакет PE1 определяет, что пришедший пакет принадлежит VRF А.
1.2 По VRF-таблице PE1 определяет, что подсеть 10.2.1.0/24 (которой предназначен пакет) доступна через MPLS-домен и пакету необходимо назначить две метки 1000/345. Метки назначаются, и пакет пересылается устройству P1
1.3, 1.4 Устройства P1 и P2 на основании своих таблиц коммутации переправляют пакет устройству PE2. Отметим то, что «внешняя» метка 345 назначенная пакету устройством PE1 определяет LSP от PE1 до PE2.
1.5 PE2 получает пакет только со «внутренней» меткой 1000 и на основании таблицы коммутации определяет выходной интерфейс, через который должен быть переслан пакет (уже без метки).
Примечание: Прохождения пакета из VPN B от CE3 до CE4 через MPLS-домен происходит аналогично предыдущему примеру. Отличие, лишь, в значении «внутренней» метки, которая определяет, или другой исходящий интерфейс на PE2, или другой VRF.
Примечание: Прохождение пакета в обратную сторону, например от CE2 до CE1 происходит, так же аналогично приведенному примеру, за исключением значений меток. «внешняя» метка в этом случае будет определять LSP от PE2 до PE1, а «внутренняя» метка будет назначаться устройством PE1 и обозначать VRF или интерфейсы на устройства PE1.

Обмен маршрутной информацией между PE

  • NLRI — Network Layer Reachability Information — данная компонента описывала только префикс маршрута (например: 10.1.1.0/24).
  • Path attributes — атрибуты маршрута, включая адрес next-hop.
  • Address Family Identifier (AFI) (2 байта) = 1 (маршрут класса IPv4);
  • Subsequent Address Family Identifier (AFI) (1 байт) = 4 (описание маршрута включает «внутренние» метки VPN);
  • Next-hop;
  • SNPA — Subnetwork Points of Attachment — параметр мутный, для MPLS/VPN не используется;
  • Структура MP_NLRI — Multi Protocol Network Layer Reachability Information (определена в RFC 3107 «Carrying Label Information in BGP-4»):
    • метка;
    • префикс подсети VPN маршрута.
    • Route Distinguisher (RD) — дискриминатор маршрутной информации. RD обеспечивает уникальность префикса VPN (8 байт);
    • IPv4 network address — традиционный префикс IPv4 (4 байта).
    • тип (2 байта) — данное поле определяет структуру и размер следующих полей;
    • глобальная (административная) компонента;
    • локальная компонента (индекс).

    Табл. N6. Форма представления поля RD.

    Значение поля «тип» Размер глобальной компоненты (байт) Значение глобальной компоненты Размер локальной компоненты (байт) Значение локальной компоненты
    0 2 Номер автономной системы в соответствии с RFC1930 4 Номер уникально идентифицирующий RD.
    1 4 IPv4 адрес 2
    2 4 Номер автономной системы в соответствии с (draft-ietf-idr-as4bytes) 2
    • Site of Origin — атрибут, идентифицирующий точку подключения клиента (site).
    • Route Target — набор идентификаторов, описывающих правила импорта/экспорта.
    • тип атрибута атрибута (1 байт);
    • идентификатор атрибута (1 байт) Site of Origin = 3, Route Target = 2;
    • глобальная компонента (длинна перемена);
    • локальная компонента (длинна перемена);

    Организация VPN

    • import;
    • export.
    1. Все маршруты, полученные от CE, принадлежащие VRF X, передаются другим PE с добавлением множества атрибутов RT «export» VRF-а X.
    2. Маршрут, полученный от другого PE, будет установлен в VRF-таблицу Y, только если множество атрибутов RT полученное с маршрутом и множество «import» VRF-а Y имеют хотя бы один общий атрибут.

    Рис. N4. Схема подключения маршрутизаторов CE к PE
    Табл. N7. Конфигурация VRF на PE1

    VRF import export значение RD
    A 1:1, 2:1 2:1 6:1
    B 1:1, 3:2 3:2 7:2
    C 2:2, 3:1, 4:5 6:2, 6:4 7:1

    Маршрутизатор PE1 получает по iBGP от маршрутизатора PE2 информацию о маршрутах VPN. Содержание информации представлено в табл. N8.

    Табл. N8. Маршрутная информация, получаемая по BGP устройством PE1 от PE2.

    Префикс Атрибуты RT Next-hop VPN-label
    8:1:10.2.1.0/24 4:2, 2:1 172.16.1.1 100
    8:2:10.2.1.0/24 3:1 172.16.1.1 200
    8:3:172.16.1.0/24 1:1, 7:1 172.16.1.1 300
    • 8:1:10.2.1.0/24 устанавливается в таблицу VRF A, так как атрибут RT 2:1 входит только во множество import VRF-а A. Атрибут 4:2 не входит ни в какое множество import ни какого VRF в рамках данного PE;
    • 8:2:10.2.1.0/24 устанавливается в таблицу VRF C, так как атрибут RT 3:1 входит только во множество import VRF-а C;
    • 8:3:172.16.1.0/24 устанавливается в таблицы VRF A и B, так как атрибут RT 1:1 входит во множество import VRF-ов A и B. Атрибут 7:1 не входит ни в какое множество import ни какого VRF в рамках данного PE.

    Табл. N10. Таблицы маршрутизации VRF на PE1.

    VRF-таблица Протокол Префикс Выходной интерфейс Next-hop Метки для коммутации
    A iBGP 10.2.1.0/24 int3 172.16.1.1 100/1001
    A iBGP 172.16.1.0/24 int3 172.16.1.1 300/1001
    A OSPF 10.1.1.0/24 int2 CE1 нет
    B iBGP 172.16.1.0/24 int3 172.16.1.1 300/1001
    B OSPF 10.3.1.0/24 int1 CE2 нет
    C iBGP 10.2.1.0/24 int3 172.16.1.1 200/1001
    C RIP 10.1.1.0/24 int0 CE3 нет
    • «внешняя» — определяет LSP от одного PE до другого (в нашем случае 1001);
    • «внутренняя» — определяет VRF или интерфейс на PE, к которому присоединен абонент (данная метка распространяется по BGP, значения для нашего случая представлены в табл. N8, колонка «VPN-label»).

    Табл. N10. Маршрутная информация, отправляемая по BGP устройством PE1 устройству PE2.

    Источник маршрута VRF Префикс Префикс+RD Назначенный RT назначенная VPN метка Next-Hop
    CE1 A 10.1.1.0/24 6:1:10.1.1.0/24 2:1 200 172.16.1.2
    CE2 B 10.3.1.0/24 7:2:10.3.1.0/24 3:2 400 172.16.1.2
    CE3 C 10.1.1.0/24 7:1:10.1.1.0/24 6:2, 6:4 100 172.16.1.2
    1. VPN пакеты передаются через MPLS домен с двумя метками («внешней» и «внутренней»).
    2. «Внешняя» метка определяет LSP от одного PE до другого.
    3. «Внутренняя» метка определяет или VRF или выходной интерфейс на устройстве PE.
    4. Правила импорта маршрутной информации задаются значением множеств VRF import и export (подробно о том как использовать эти возможности будет сказано в отдельной статье).

    Преимущества организации VPN на базе MPLS

    • масштабируемость;
    • возможность пересечения адресных пространств, узлов подключенных в различные VPN;
    • изолирование трафика VPN друг от друга на втором уровне модели OSI.

    Сравнение механизмов организации VPN на базе MPLS и туннелей (IPSec и GRE)

    Сравнение основных технологий по организации VPN приведено в табл. N 11.
    Табл. N 11. Сравнение основных технологий по организации VPN.

    Критерии MPLS/VPN ATM/Frame Relay IPSec GRE
    Масштабируемость высокая низкая низкая низкая
    Требования к оператору поддержка технологии MPLS/VPN поддержка ATM/Frame Relay нет нет
    Требования к клиенту нет поддержка ATM/Frame Relay наличие средств шифрования поддержка туннелирования трафика
    Обеспечение целостности и конфиденциальности нет нет да нет
    Пересечение адресных пространств узлов подключенных в разные VPN допускается допускается необходимо использовать NAT со стороны клиента необходимо использовать NAT со стороны клиента

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

    Документация

    1. «Multiprotocol Extensions for BGP-4» (RFC2858)
    2. «BGP/MPLS VPNs» (draft-ietf-l3vpn-rfc2547bis)
    3. «Carrying Label Information in BGP-4» (RFC3107)
    4. «BGP Extended Communities Attribute» (draft-ietf-idr-bgp-ext-communities)
    5. «Applicability Statement for BGP/MPLS IP VPNs» (draft-ietf-l3vpn-as2547)

    MPLS — как работает и зачем нужен?

    img

    MPLS (Multiprotocol label switching) является протоколом для ускорения и формирования потоков сетевого трафика, что, по сути, означает сортировку MPLS и расстановку приоритетов в ваших пакетах данных на основе их класс обслуживания (например, IP-телефон, видео или данные Skype). При использовании протоколов MPLS доступная используемая пропускная способность увеличивается, а критически важные приложения, такие как передача голоса и видео, гарантируют 100% бесперебойную работу.

    Как работает MPLS?

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

    Виды маршрутизаторов

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

    CE взаимодействует с маршрутизатором со стороны оператора (PE) и обменивается маршрутами внутри PE. Используемый протокол маршрутизации может быть статическим или динамическим (протокол внутреннего шлюза, такой как OSPF, или протокол внешнего шлюза, такой как BGP).

    Раскроем не понятные аббревиатуры — маршрутизатор Customer Edge (CE) подключается к маршрутизатору Provider Edge (PE).

    PE маршрутизатор — граничный маршрутизатор со стороны оператора (MPLS домена), к которому подключаются устройства CE. Приставка PE к маршрутизатору, означает то, что он охватывает оборудование, способное к работе с широким диапазоном протоколов маршрутизации, в частности:

    • Протокол пограничного шлюза (BGP) (связь PE-PE или PE-CE);
    • Протокол динамической маршрутизации (OSPF) (связь между маршрутизатором и PE);
    • Многопротокольная коммутация по меткам (MPLS) (связь между маршрутизатором PE и P. Что такое P – маршутизатор поговорим дальше.);

    Некоторые маршрутизаторы PE также выполняют маркировку трафика.

    P — маршрутизатор — внутренний маршрутизатор сети оператора (провайдера) MPLS домена. В многопротокольной коммутации по меткам (MPLS) маршрутизатор P функционирует как транзитный маршрутизатор базовой сети. Маршрутизатор P обычно подключен к одному или нескольким маршрутизаторам PE.

    Принципы работы MPLS

    Входной маршрутизатор с MPLS (напомним, multiprotocol label switching, с английского) будет помечать пакеты данных при входе в сеть расставляя метки, поэтому, маршрутизаторы будут точно понимать, куда направляются данные, без необходимости снова и снова анализировать пакет с данными.

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

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

    Хедер (заголовок) фрейма MPLS хедер (заголовок) Хедер (заголовок) IP пакета IP пакет

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

    В чем преимущество переключения меток по методу MPLS?

    Схема с примером использования MPLS в сети

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

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

    Передача и управление трафиков происходит за счёт технологии Traffic Engineering, которая осуществляет передачу трафика по каналам по наиболее оптимальному маршруту, но с некоторыми ограничениями благодаря технологии CSPF (Constrained Shortest Path First), которая выбирает пути не только пользуясь критерием, основанном на его оптимальной длине маршрута, но еще и учитывает загрузку маршрутов. Используемые протоколы RSVP-TE позволяют резервировать полосы пропускания в сети.

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

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

    В заключении следует отметить, что на практике MPLS в основном используется для пересылки единиц данных протокола IP (PDU, (Protocol Data Unit)) и трафика виртуальной частной локальной сети (VPLS) Ethernet. Основными приложениями MPLS являются инженерия телекоммуникационного трафика и MPLS VPN.

    Mpls vpn что это такое

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

    В то же время между MPLS VPN третьего уровня и второго имеется много общего:

    q услуги предоставляются провайдером с помощью сети IP/MPLS;

    q пограничные маршрутизаторы PE выполняют всю работу по поддержанию VPN;

    q внутренние маршрутизаторы провайдера P нужны только для передачи MPLS пакетов между пограничными маршрутизаторами PE; они не знают о существовании VPN;

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

    Каждый пограничный маршрутизатор PE обменивается маршрутной информацией с соединенными с ним клиентскими маршрутизаторами CE по какому-нибудь протоколу маршрутизации класса IGP , например, OSPF или IS — IS (рис. 1). С каждым из клиентов может использоваться свой протокол IGP , то есть с сайтом А протокол OSPF , а с сайтом B — протокол IS — IS . С помощью этих протоколов маршрутизатор узнает о том, какие сети достижимы в сайтах клиентов. Кроме того, маршрутизатор PE поддерживает сеанс протокола IGP с остальными маршрутизаторами сети провайдера (как P , так и PE ) для того, чтобы знать топологию этой сети и маршрутизировать пакеты в пределах этой сети.

    Рис. 1 . Разграничение маршрутных объявлений в сети MPLS VPN третьего уровня

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

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

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

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

    Аналогичным образом настроены и остальные маршрутизаторы PE. Таблица маршрутизации, создаваемая на пограничных маршрутизаторах PE на основе объявлений из магистральной сети провайдера, имеет специальное название: глобальная таблица маршрутизации . В ней содержатся маршруты в пределах внутренней сети провайдера, информации о маршрутах в сетях клиентов в ней нет. Таблицы маршрутизации, которые PE формирует на основе объявлений, поступающих от сайтов клиентов, получили название таблиц VRF (VPN Routing and Forwarding). В них имеется только информация о сетях клиентов.

    Маршрутизаторы P принимают и обрабатывают маршрутную информацию IGP, поступающую со всех интерфейсов. В создаваемых ими таблицах маршрутизации имеется информация только о сетях провайдера.

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

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

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

    Обмен маршрутной информацией

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

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

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

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

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

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

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

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

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

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

    На рис. 2 показано, как входной маршрутизатор 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.

    Рис. 2 . Маршрутные объявления MB — BGP

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

    Конфигурирование топологии VPN

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

    Такая гибкая форма создания топологии VPN достигается за счет атрибутов экспорта-импорта маршрутов в объявлениях MP — BGP . Атрибут route-target ( RT ) идентифицирует входящих в данную сеть VPN набор сайтов ( VRF ), которым маршрутизатор PE должен посылать маршруты.

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

    При получении объявлений MP-BGP вступает в действие политика импорта маршрутов; как и политика экспорта, она задается при конфигурировании каждой таблицы VRF.

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

    Именно этот случай для VPN A и VPN B показан на рис. 2, так как таблицы VRF сайтов этих сетей VPN сконфигурированы с одинаковыми значениями политики экспорта и импорта: значением GREEN для VPN A и значением RED для VPN B .

    Пример конфигурирования звездообразной топологии представлен на рис. 3.

    Рис. 3 . Конфигурирование звездообразной топологии между сайтами VPNA .

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

    Mpls vpn что это такое

    E. Rosen. RFC-2547, March 1999 (Перевод Семенова Ю.А.)

    Описан метод, с помощью которого, например, сервис провайдер на IP опорной сети, может организовать для клиентов частные виртуальные сети (VPN). MPLS (мультипротокольная коммутация пакетов по меткам — Multiprotocol Label Switching) используется для переадресации пакетов по опорной сети, а BGP (Border Gateway Protocol) служит для прокладки маршрутов через опорную сеть. Главной целью метода является поддержка внешних опорных IP сетей, предлагающих услуги корпоративным сетям. Это делается достаточно просто для предприятия, сохраняя гибкость и масштабируемость для сервис провайдеров. Данная технология может быть также использована, чтобы формировать VPN , которая сама предоставляет IP-услуги клиентам.

    1.1. Частные виртуальные сети

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

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

    Если все сайты в VPN принадлежат одной и той же компании, VPN является корпоративной «интранет». Если разные сайты в VPN принадлежат различным компаниям, VPN считается «экстранетом». Сайт может состоять в более чем одной VPN, например, интранет и несколько экстранетов. Будем рассматривать интранеты и экстранеты, как VPN. Вообще, при использовании термина VPN в дальнейшем не будет делаться различия между интранетами и экстранетами.

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

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

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

    1.2. Оконечные устройства

    Предполагается, что на каждом сайте имеется одно или более оконечное устройство клиента CE (Customer Edge), каждое из которых подключено через какой-то канал (например, PPP, ATM, Ethernet, Frame Relay, GRE-туннель, и т.д.) к одному или более оконечному маршрутизатору провайдера PE (Provider Edge).

    Если конкретный сайт имеет одну ЭВМ, эта машина может быть оконечным устройством CE. Если конкретный сайт имеет одну субсеть, оконечным устройством CE может стать сетевой переключатель. Вообще, устройством CE может быть маршрутизатор, который называется в этом случае CE-маршрутизатором.

    Будем говорить, что PE-маршрутизатор подключен к определенной VPN, если он подключен к оконечному устройству CE, которое находится в VPN. Аналогично, будем считать, что маршрутизатор PE подключен к определенному сайту, если он подсоединен к устройству CE, которое находится в пределах этого сайта. Когда в качестве CE выступает маршрутизатор, он является маршрутным партнером PE, к которому подключен, но не является маршрутным партнером CE-маршрутизаторов в других сайтах. Маршрутизаторы в различных сайтах непосредственно не обмениваются маршрутной информацией. В действительности, они даже могут не знать о существовании друг друга (за исключением случая, когда это необходимо из соображений безопасности, смотри раздел 9). Как следствие, очень большие VPN (т.e., VPN с большим числом сайтов) хорошо поддерживаются, в то же время маршрутные стратегии каждого индивидуального сайта существенно упрощаются.

    Важно сохранять четкие административные границы между SP и их клиентами [4]. Маршрутизаторы PE и P должны администрироваться SP, а клиенты SP не должны иметь доступа к их управлению. Устройства CE должны управляться клиентом (если только клиент не заключил соглашение с SP).

    1.3. VPN с перекрывающимися адресными пространствами

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

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

    1.4. VPN с разными маршрутами до одной и той же системы

    Хотя сайт может находиться в нескольких VPN, не обязательно маршрут к данной системе в сайте будет тем же, что для всех прочих VPN. Предположим, например, что имеется интранет, состоящий из сайтов A, B и C , а также экстранет, включающий в себя A, B, C и «чужой» сайт D . Будем считать, что сайт A является сервером, и мы хотим предоставить клиентам из B, C или D доступ к этому серверу. Предположим также, что сайт B является файерволом. Мы хотим, чтобы весь трафик из сайта D к серверу проходил через файервол, так что может контролироваться доступ трафика из экстранета. Однако мы не хотим, чтобы трафик от C проходил через firewall на пути к серверу, поскольку это трафик интранет.

    Это означает, что нужно конфигурировать два маршрута к серверу. Один маршрут, используемый сайтами B и C, организует трафик к сайту A. Второй маршрут, используемый сайтом D, формирует трафик через firewall сайта B. Если firewall позволяет проходить трафику, он затем рассматривается как трафик, приходящий из сайта B, и следует маршрутом до узла A.

    1.5. Таблицы переадресации в PE

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

    1.6. Маршрутизаторы опорной сети SP

    Опорная сеть SP состоит из PE-маршрутизаторов, а также их других маршрутизаторов (P-маршрутизаторы), которые не подключены к CE устройствам.

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

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

    2. Сайты и CE

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

    CE-устройства всегда рассматриваются принадлежащими одному сайту (хотя как мы это увидим, сайт может состоять из множества «виртуальных сайтов»). Сайт, однако, может принадлежать многим VPN.

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

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

    3. Таблицы переадресации сайта в PE

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

    Как заполняются таблицы переадресации сайтов?

    В качестве примера, пусть PE1, PE2 и PE3 являются PE-маршрутизаторами, и пусть CE1, CE2 и CE3 являются CE-маршрутизаторами. Предположим, что PE1 узнает, от CE1 маршруты, которые достижимы в сайте CE1. Если PE2 и PE3 подключены соответственно к CE2 и CE3 и имеется VPN V, содержащая CE1, CE2 и CE3, тогда PE1 использует BGP для посылки маршрутной информации PE2 и PE3, которую он получил от CE1. PE2 и PE3 используют эти маршруты для заполнения таблиц переадресации, которые ассоциируются ими с сайтами CE2 и CE3, соответственно. Маршруты из сайтов, которые находятся вне VPN V, не заносятся в эти таблицы, поэтому пакеты от CE2 или CE3 не могут быть посланы сайтам, которые не принадлежат VPN V.

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

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

    Предположим, что пакет получен PE-маршрутизатором от определенного сайта, соединенного с ним непосредственно, но место назначения пакета не связано ни с одной из записей таблицы переадресации данного сайта. Если SP не предоставляет доступа к Интернет для данного сайта, тогда пакет отбрасывается. Если SP предоставляет доступ к Интернет для данного сайта, тогда просматривается таблица переадресации PE.

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

    (a) метка в верхней позиции стека действительно прислана маршрутизатором опорной сети в устройство не опорной сети, и

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

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

    3.1. Виртуальные сайты

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

    В качестве альтернативы можно разделить интерфейс на несколько субинтерфейсов, (в частности, если интерфейс следует стандарту Frame Relay или ATM), и ассоциировать пакет с VPN на основе суб-интерфейса, через который он вошел. Можно также просто использовать отдельный интерфейс для каждого виртуального сайта. В любом случае, для одного сайта нужен только один CE-маршрутизатор, даже в случае большого числа виртуальных сайтов. Конечно, если хочется, можно использовать разные маршрутизаторы CE для каждого виртуального сайта.

    Заметим, что во всех случаях, механизмы, как и политика для управления того, какой трафик пропускать и для какого VPN, находится в руках клиента.

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

    Эти схемы не требуют от CE поддержки MPLS. Раздел 8 содержит краткое описание того, как CE может поддерживать большое число виртуальных сайтов, если оно не поддерживает MPLS.

    4. Распределение маршрутов VPN посредством BGP

    Маршрутизаторы PE используют BGP для рассылки маршрутов между VPN (точнее, для вынуждения VPN обмениваться маршрутами между собой).

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

    4.1. Адресное семейство VPN-IPv4

    Мультипротокольное расширение BGP [3] позволяет этому протоколу работать со многими «адресными семействами». Введем обозначение «VPN-IPv4 address family». Адрес VPN-IPv4 имеет 12-байт и начинается с 8 байт идентификатора маршрута RD (Route Distinguisher) и завершается четырьмя байтами адреса IPv4. Если две VPN используют один и тот же адресный префикс IPv4, PE транслирует их в уникальный адресный префикс VPN-IPv4. Это гарантирует, что в случае использования одного и того же адреса в двух разных VPN, будет возможно установить два совершенно разных маршрута до этого адреса по одному для каждого VPN.

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

    RD может также использоваться для формирования множественных путей к одной и той же системе. В разделе 3, приводится пример, где маршрут к определенному серверу должен быть разным для интранет и экстранет. Это может быть достигнуто путем создания двух разных VPN-IPv4 маршрутов, которые имеют идентичную IPv4 часть, но разные RD. Это позволяет BGP установить несколько разных путей к одной и той же системе и разрешить использование политики (смотри раздел 4.2.3), чтобы решить, какие пакеты будут пользоваться данным маршрутом.

    RD структурированы так, что каждый сервис-провайдер может администрировать свою зону нумерации (т.e., может выполнить свои собственные присвоения для RD), не конфликтуя с RD, присвоенными другими сервис-провайдерами. RD состоит из двухбайтного поля типа, поля администратора и поля присвоенного номера. Значение поля типа определяет длины двух других полей, а также семантику поля администратор. Поле администратор идентифицирует систему присвоения номеров (assigned number authority), а поле присвоенного номера несет в себе число, которое служит для идентификации этой системы. Например, может существовать RD, чье поле администратор содержит ASN (Autonomous System number), и чье поле номера (4-байта) содержит число, присвоенное SP, которому этот код ASN присвоен IANA. Для RD выбрана такая структура, для того, чтобы гарантировать, что SP, который предоставляет услуги опорной сети, может всегда сформировать уникальный RD, когда это потребуется. Однако данная структура не предоставляет никакой семантики. Когда BGP сравнивает два таких адресных префикса, он полностью игнорирует структуру. Если субполя администратор и присвоенный номер адреса VPN-IPv4 установлены равными нулю, считается, что адрес VPN-IPv4 имеет то же значение, что и глобально уникальный адрес IPv4. В частности, этот VPN-IPv4 адрес и соответствующий ему глобально уникальный IPv4-адрес будут рассматриваться BGP как совместимые. Во всех других случаях, адрес VPN-IPv4 и соответствующий ему глобально уникальный IPv4-адрес будут рассматриваться BGP как несовместимые.

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

    PE должен быть сконфигурирован так, чтобы установить соответствие между маршрутами, ведущими к конкретному CE, и их RD. PE может быть сконфигурирован так, чтобы установить соответствие между всеми маршрутами, ведущими к одному CE и имеющими данный RD. Он может быть сконфигурирован и так, чтобы установить соответствие между разными маршрутами, имеющими различные RD даже если они ведут к одному и тому же CE.

    4.2. Управление рассылкой маршрутов

    В данном разделе, обсуждается способ управления рассылкой маршрутов VPN-IPv4.

    4.2.1. Атрибут Target VPN

    Каждая таблица переадресации соответствует одному или более атрибутам «Target VPN». Когда маршрут VPN-IPv4 сформирован маршрутизатором PE, он ассоциируется с одним или более атрибутами » Target VPN». Они рассматриваются протоколом BGP как атрибуты маршрута.

    Любой маршрут, ассоциированный с Target VPN T должен рассылаться каждому маршрутизатору PE, который имеет таблицу переадресации, ассоциированную с Target VPN T. Когда такой маршрут получен PE-маршрутизатором, он пригоден для инсталляции в каждой из таблиц переадресации PE, которая ассоциируется с Target VPN T. (Будет ли этот маршрут инсталлирован, зависит от процесса принятия решений BGP). По существу, атрибут Target VPN идентифицирует набор сайтов. Ассоциация конкретного атрибута Target VPN с маршрутом позволяет поместить маршрут в таблицу переадресации, которая используется для маршрутизации трафика, приходящего от соответствующих сайтов.

    Имеется набор Target VPN, которые маршрутизатор PE подключает к маршруту, полученному из сайта S. Имеется набор Target VPN, которые маршрутизатор PE использует для определения, будет ли маршрут, полученный от другого маршрутизатора PE, помещен в таблицу переадресации, ассоциированную с сайтом S. Эти два набора различны, и не должны быть идентичны.

    Функции, выполняемые атрибутом Target VPN, сходны с осуществляемыми атрибутом BGP Communities Attribute. Однако формат последнего не является адекватным, так как он позволяет только двухбайтовое пространство для нумерации. Самым простым решением является расширение пространства нумерации атрибута BGP Communities. Должно быть также возможно структурировать формат, аналогично тому, как это описано для RD (смотри раздел 4.1), так что поле тип определит длину поля администратор, а оставшаяся часть атрибута является номером из пространства нумерации администратора.

    Когда BGP маршрутизатор получил два маршрута до одного и того же префикса VPN-IPv4, он выбирает один, согласно BGP правилам предпочтения маршрутов.

    Заметим, что маршрут может иметь только один RD, но он может иметь несколько Target VPN. В BGP масштабируемость улучшается, если имеется один маршрут с несколькими атрибутами. Можно пренебречь атрибутом Target VPN, создавая больше маршрутов (т.e., используя большее число RD), но тогда свойства масштабируемости окажутся менее привлекательными.

    Как PE определяет, какой из атрибутов Target VPN, ассоциировать с данным маршрутом? Существует большое число различных способов. PE может быть сконфигурирован так, чтобы ассоциировать все маршруты, которые ведут к определенному сайту, с некоторым заданным Target VPN. Или PE может быть сконфигурирован так, чтобы определенные маршруты, вели к конкретномусайту с одним Target VPN, а к другому с другим. Или CE-маршрутизатор, когда он рассылает маршруты (смотри раздел 6), можно специфицировать один или более Target VPN для каждого маршрута. Последний метод перемещает управление механизмом, используемым для реализации политики VPN от SP к клиенту. Если используется этот метод, может быть желательным, чтобы PE удалил любую Target VPN, которая согласно его собственной конфигурации, не допустима, и/или добавил некоторую Target VPN, которая согласно его конфигурации является обязательной. Более точно было бы называть этот атрибут » Route Target» вместо «VPN Target».

    4.2.2. Расылка маршрутов между PE посредством BGP

    Если два сайта VPN подключены к PE, которые размещены в одной автономной системе, PE могут рассылать маршруты VPN-IPv4 друг другу посредством соединения IBGP.

    Если два сайта VPN находятся в разных автономных системах (например, из-за того, что они соединены с разными SP), тогда PE-маршрутизатор будет вынужден использовать маршрутизатор IBGP для перераспределения VPN-IPv4 маршрутов в маршрутизатор ASBR (Autonomous System Border Router), или в маршрутизатор-рефлектор, клиентом которого является ASBR. ASBR будет вынужден использовать EBGP, чтобы перераспределить эти маршруты в ASBR из другой AS. Это позволяет соединить различные сайты VPN различным сервис-провайдерам.Однако маршруты VPN-IPv4 должны восприниматься только соединениями EBGP в точках пирингового обмена. Маршруты VPN-IPv4 не должны никогда рассылаться и восприниматься общедоступным Интернет.

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

    Когда маршрутизатор PE рассылает маршрут VPN-IPv4 через BGP, он использует свой собственный адрес в качестве » BGP next hop». Он также определяет и рассылает метки MPLS. (Существенно, что маршрутизаторы PE рассылают не VPN-IPv4 маршруты, а маркированные маршруты VPN-IPv4. [8]) Когда PE обрабатывает пакет, который имеет эту метку на вершине стека, PE очистит стек, и пошлет пакет непосредственно сайту, от которого ведет маршрут. Это обычно означает, что он посылает пакет маршрутизатору CE, от которого он узнал о маршруте. Метка может также определить инкапсуляцию данных в канале.

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

    Заметим, что метка MPLS, которая рассылается таким способом, может использоваться, только если существует маркированный путь между маршрутизатором, его сформировавшим, и BGP-маршрутизатором на следующем шаге. Здесь не делается никакого предположения об используемой процедуре установления маркированного пути (процедура setup). Он может быть сформирован предварительно, или установлен, когда нужный маршрут будет инсталлирован. Это может быть оптимальный маршрут («best effort»), или это может быть маршрут созданный в результате процедуры формирования трафика (traffic engineered). Между конкретным маршрутизатором PE и его BGP агентом следующего шага для конкретного маршрута может быть один или несколько LSP, возможно с разными характеристиками QoS.

    Доступны все обычные методы использования отражателей маршрутов [2] для улучшения масштабируемости, например, иерархии отражателей маршрутов. Если используются отражатели маршрута, нет нужды иметь отражатель маршрутов, который знает все VPN-IPv4 маршруты для всех VPN, поддерживаемых опорной сетью. Можно иметь отдельные отражатели маршрута, которые не взаимодействуют друг с другом, каждый из которых поддерживает субнабор общего набора VPN.

    Если данный маршрутизатор PE не подключен ни к одной Target VPN данного маршрута, он не должен получать этот маршрут. Другие PE или рефлекторы маршрута, которые посылают ему маршруты должны использовать внешние фильтры, чтобы избежать рассылки ненужных маршрутов. Конечно, если маршрутизатор PE получает маршрут через BGP, а данный PE не подключен к какой-либо target VPN маршрута, PE должен применить к этому маршруту внутреннюю фильтрацию, ни анонсируя и не пересылая его.

    Маршрутизатор, который не подключен к какой-либо VPN, т.e., P-маршрутизатор, вообще никогда не анонсирует какие-либо маршруты VPN-IPv4.

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

    4.2.3. Атрибут VPN of Origin

    Маршрут VPN-IPv4 может быть опционно ассоциирован с атрибутом VPN of Origin. Это атрибут уникально идентифицирует набор сайтов и идентифицирует соответствующий маршрут, как пришедший из одного из сайтов этого набора. Типичным применением этого атрибута может быть идентификация предприятия, которое владеет сайтом, куда ведет маршрут, он может также идентифицировать интранет сайта. Однако возможны и другие применения. Этот атрибут может быть представлен как расширение атрибута BGP communities.

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

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

    Путем соответствующей установки атрибутов Target VPN и VPN of Origin, можно сконструировать VPN самого разного типа.

    Предположим, что нужно создать замкнутую группу пользователей CUG (Closed User Group), которая содержит определенный набор сайтов. Это может быть сделано путем формирования определенного атрибута Target VPN для CUG. Значение этого атрибута затем должно быть ассоциировано с таблицами переадресации сайта для каждого сайта в CUG, оно должно быть связано с каждым маршрутом, полученным от сайта в CUG. Любой маршрут, который имеет этот атрибут Target VPN, должен быть перераспределен так, чтобы достичь каждого маршрутизатора PE, подключенного к одному из сайтов.

    В качестве альтернативы, предположим, что желательно по какой-то причине создать VPN типа «hub and spoke» (ось и спица). Это может быть сделано путем использования двух значений атрибута Target, один со значением » Hub» а другой со значением «Spoke». Затем маршруты от spokes могут быть посланы hub, не вызывая посылки маршрутов в обратном направлении.

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

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

    5. Переадресация в опорной сети

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

    Маршрутизаторы PE (и ASBR, которые перераспределяют адреса VPN-IPv4) должны ввести адресные префиксы /32 для самих себя в таблицы маршрутизации опорной сети. Это позволяет MPLS, в каждом узле опорной сети присвоить метку, соответствующую маршруту к каждому маршрутизатору PE. (Определенные процедуры для установления коммутации меток в опорной сети могут не требовать присутствия адресного префикса /32.)

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

    Если пакет адресован не устройству CE, подключенному к тому же PE, важен «BGP Next Hop» пакета, а также метка, которую этот BGP следующего шага присвоил адресу места назначения пакета. Эта метка укладывается в стек меток пакета. Затем PE ищет маршрут IGP до BGP следующего шага, и таким образом определяет маршрутизатор следующего шага IGP, а также метку, приписанную адресу маршрутизатора следующего шага BGP. Эта метка заносится на верх стека меток пакета, а пакет затем переадресуется к маршрутизатору следующего шага IGP. (Если BGP следующего шага является тем же что и для IGP, вторая метка может не извлекаться из стека).

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

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

    Заметим, что двухуровневая маркировка делает возможным увод всех маршрутов VPN от маршрутизаторов P, а это в свою очередь важно для гарантии масштабируемости модели. Опорная сеть не должна иметь маршрутов к CE (только к PE).

    6. Как PE узнают о маршрутах от CE

    Маршрутизаторы PE, которые подключены к какой-то VPN, должны знать адреса для каждого сайта из данного VPN.

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

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

    Какой из методов рассылки маршрутов PE/CE возможен, зависит от того, является ли конкретное устройство CE «транзитным VPN» или нет. «Транзитная VPN» — это сеть, которая содержит маршрутизатор, получающий маршруты от «третей стороны» (т.e., от маршрутизатора, который находится вне VPN, но не является PE-маршрутизатором), и который перераспределяет эти маршруты в маршрутизатор PE. VPN, которая не является транзитной VPN, представляет собой «частичную VPN». Подавляющее большинство VPN, включая практически все корпоративные сети, следует считать такими. Возможные механизмы рассылки PE/CE:

    1. Может использоваться статическая маршрутизация (т.e., конфигурация).

    2. PE и CE-маршрутизаторы могут быть RIP-партнерами, а CE может использовать RIP, чтобы сообщить маршрутизатору PE набор адресных префиксов, которые достижимы для сайта CE. Когда RIP сконфигурирован в CE, следует позаботиться о том, чтобы адресные префиксы от других сайтов (т. e., адресные префиксы, полученные маршрутизатором CE от маршрутизатора PE) никогда не анонсировались PE. Точнее, если маршрутизатор PE, скажем PE1, получает VPN-IPv4 маршрут R1, и в результате посылает маршрут IPv4 R2 в CE, R2 не должен быть послан назад из сайта CE в маршрутизатор PE, скажем PE2, (где PE1 и PE2 может быть тем же маршрутизатором или разными маршрутизаторами), если только PE2 не ставит в соответствие R2 и маршрут VPN-IPv4, который отличается от (т.e., содержит другой RD) R1.

    3. Маршрутизаторы PE и CE могут быть партнерами OSPF. В этом случае, сайт должен быть единой областью OSPF, CE должно быть ABR для этой области, а PE должно быть ABR, который находится вне области. Кроме того, PE не должен анонсировать никакие связи маршрутизатора кроме тех, что существуют до CE, размещенном в том же сайте. (Этот метод должен использоваться только в частичных VPN.)

    4. Маршрутизаторы PE и CE могут быть партнерами BGP, а маршрутизатор CE может использовать BGP (В частности, EBGP, чтобы уведомить маршрутизатор PE о наборе адресных префиксов, которые находятся в сайте маршрутизатора CE. (Эта технология может использоваться в частичных или транзитных VPN).

    С чисто технической точки зрения это далеко не совершенная методика:

    a) В отличии от альтернатив IGP, это не требует от PE запускать несколько запросов алгоритму маршрутизации, для того чтобы взаимодействовать с несколькими CE.

    b) BGP сконструирован как раз для решения таких задач: пересылки маршрутной информации между системами, управляемыми разными администраторами.

    c) Если сайт содержит «BGP backdoors», т.e., маршрутизаторы с BGP-соединениями с маршрутизаторами, отличными от PE-маршрутизаторов, эта процедура будет работать корректно при любых обстоятельствах. Другие процедуры могут работать или нет, в зависимости от конкретных обстоятельств.

    d) Использование BGP упрощает для CE передачу атрибутов маршрутов PE. Например, CE может предложить определенный Target для каждого маршрута, из числа атрибутов Target, которые авторизованы PE для присвоения маршруту.

    С другой стороны, использование BGP вероятно является чем-то новым для CE администраторов, за исключением случая, когда клиент сам является Интернет сервис-провайдером. Если сайт не является транзитной VPN, он не должен иметь уникальный ASN (Autonomous System Number). Каждый CE, чей сайт не является транзитной VPN, может использовать один и тот же ASN. Значение может быть взято из частного ASN-пространства, оно будет ликвидировано PE. Маршрутные петли предотвращаются путем использования атрибута Site of Origin (см. ниже).

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

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

    Прежде чем PE сможет передать VPN-IPv4 маршрут, узнанный от сайта, он должен присвоить ему определенный атрибут. Существует три таких атрибута:

    — Исходный сайт (Site of Origin)

    Этот атрибут однозначно идентифицирует сайт, от которого маршрутизатор PE узнал о маршруте. Всем маршрутам, полученным от определенного сайта, должен быть присвоен один и тот же атрибут Site of Origin, даже если сайт имеет несколько соединений с одним PE, или соединен с несколькими PE. Определенные атрибуты Site of Origin должны использоваться с определенными сайтами. Этот атрибут может быть представлен как атрибут extended BGP communities (раздел 4.2.1).

    Смотри раздел 4.2.1.

    Смотри раздел 4.2.1.

    7. Как CE узнает маршруты от PE

    В данном разделе мы предполагаем, что устройством CE является маршрутизатор. Вообще, PE может послать любой маршрут в CE, который PE поместил в таблицу переадресации, которую он использует для маршрутизации пакетов из CE. Существует одно исключение: если атрибут маршрута Site of Origin идентифицирует конкретный сайт, такой маршрут не должен никогда посылаться какому-либо CE этого сайта.

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

    Какая бы из процедур ни использовалась для рассылки маршрутов от CE к PE, она же может служить для передачи маршрутов от PE к CE.

    8. Если CE поддерживает MPLS?

    В случае, когда CE поддерживает MPLS, и хочет импортировать весь набор маршрутов из своего VPN, PE может разослать метку для каждого такого маршрута. Когда PE получает пакет от CE с такой меткой, он (a) замещает эту метку соответствующей меткой, которую он получил через BGP, и (b) заносит метку в стек поверх метки, соответствующей BGP следующего шага для заданного маршрута.

    8.1. Виртуальные сайты

    Если рассылка маршрутов CE/PE выполнена через BGP, CE может использовать MPLS, чтобы осуществить поддержку большого числа сайтов. CE может сам содержать отдельную таблицу переадресации для каждого виртуального сайта, которую он заполняет, как это указано атрибутом Origin and Target VPN маршрутов, получаемых им от PE. Если CE получает от PE полный набор маршрутов, PE не будет должен просматривать адреса пакетов, полученных от CE. В качестве альтернативы PE может в некоторых случаях посылать CE отдельный (помеченный) маршрут по умолчанию для каждого VPN. Затем, когда PE получает помеченный пакет от CE, он узнает, какую таблицу переадресации следует просматривать. Метка, помещенная в пакет CE, будет идентифицировать только виртуальный сайт, от которого пакет пришел.

    8.2. Представление ISP VPN в качестве части VPN

    Если определенная VPN является в действительности ISP, но ее маршрутизаторы CE поддерживают MPLS, тогда VPN может рассматриваться как частичная VPN. Маршрутизаторы CE и PE должны только обмениваться маршрутами, которые являются внутренними по отношению к VPN. Маршрутизатор PE отправит маршрутизатору CE метку для каждого из этих маршрутов. Маршрутизаторы в других сайтах VPN могут тогда стать партнерами BGP. Когда маршрутизатор CE просматривает адрес назначения пакета, маршрутный поиск всегда возвращает внутренний адрес, обычно адрес BGP следующего шага. CE помечает пакеты соответствующим образом и посылает их к PE.

    9. Безопасность

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

    b) помеченные маршруты VPN-IPv4 не воспринимаются, если они пришли из источников не внушающих доверия, безопасность предоставляемая этой архитектурой виртуально идентична той, которая реализуется опорными сетями VPN Frame Relay или ATM.

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

    Использование MPLS позволяет также расширить зону действия VPN на несколько SP вне какой-либо зависимости от междоменной рассылки маршрутной информации.

    Для пользователя VPN возможно также обеспечить себя повышенной безопасностью путем применения туннельного режима IPSEC [5].

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

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

    Способ достижения этого предложен в [6]. Каждый маршрут VPN может иметь атрибут, который идентифицирует следующий маршрутизатор CE, через который пройдет путь. Если эта информация предоставлена всем маршрутизаторам CE в VPN, может использоваться стандартный туннельный режим IPSEC.

    Если CE и PE являются BGP-партнерами, естественно представить эту информацию в виде атрибута BGP.

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

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

    9.2. Многокомпонентные безопасные ассоциации

    Вместо построения безопасного туннеля между каждой парой маршрутизаторов CE, может оказаться более привлекательным сформировать одну безопасную ассоциацию с большим числом участников. В такой ассоциации, все маршрутизаторы CE, которые находятся в конкретной VPN, будут иметь идентичные параметры безопасности (например, некоторый ключ, определенный алгоритм и т.д.). Тогда устройство CE не должно будет знать, какое CE должно получать данные следующим, оно должно знать какой сети VPN предназначена эта информация. CE, которое принадлежит нескольким VPN, может использовать различные параметры безопасности для каждой из них, таким образом защищая, например, пакеты интранет от попадания в экстранет. Для такой схемы не может быть применен стандартный туннельный режим IPSEC, так как здесь нет способа заполнить поле IP-адреса места назначения внешнего заголовка. Однако когда MPLS используется для переадресации, реальной необходимости этого не существует; маршрутизатор PE может использовать MPLS, чтобы ввести пакет в конечную точку туннеля, даже не зная его IP-адреса; он только должен отслеживать IP-адреса места назначения внутреннего заголовка.

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

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

    10. Качество обслуживания

    Качество обслуживания (QoS) является ключевым компонентом любой системы VPN. В MPLS/BGP VPN, существующие возможности L3 QoS могут быть применены к помеченным пакетам посредством использования «экспериментальных» битов в промежуточном заголовке [10], или, в случае применения в качестве опорной сети ATM, за счет использования QoS-возможностей самой сети ATM. Управление трафиком, обсуждаемое в работе [1], также применимо к сетям VPN MPLS/BGP. Управление трафиком, если это желательно, может использоваться даже для установления LSP с конкретными параметрами QoS между определенными парами сайтов. Когда MPLS/BGP VPN охватывает нескольких SP, может быть применена архитектура, описанная в [7]. SP может реализовать либо intserv или diffserv возможности конкретной сети VPN.

    11. Масштабируемость

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

    (b) BGP отражателей маршрута,

    (c) P-маршрутизаторов (которые являются либо PE-маршрутизаторами, либо рефлекторами маршрута), и в случае мульти-провайдерской VPN,

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

    Маршрутизатор PE поддерживает VPN маршруты, но только для тех VPN, с которыми связан непосредственно.

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

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

    [1] Awduche, Berger, Gan, Li, Swallow, and Srinavasan, «Extensions to RSVP for LSP Tunnels», Work in Progress.

    [2] Bates, T. and R. Chandrasekaran, «BGP Route Reflection: An alternative to full mesh IBGP», RFC 1966, June 1996.

    [3] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, «Multiprotocol Extensions for BGP4», RFC 2283, February 1998.

    [4] Gleeson, Heinanen, and Armitage, «A Framework for IP Based Virtual Private Networks», Work in Progress.

    [5] Kent and Atkinson, «Security Architecture for the Internet Protocol», RFC 2401, November 1998.

    [6] Li, «CPE based VPNs using MPLS», October 1998, Work in Progress.

    [7] Li, T. and Y. Rekhter, «A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)», RFC2430, October 1998.

    [8] Rekhter and Rosen, «Carrying Label Information in BGP4», Work in Progress.

    [9] Rosen, Viswanathan, and Callon, «Multiprotocol Label Switching Architecture», Work in Progress.

    [10] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and Conta, «MPLS Label Stack Encoding», Work in Progress.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *