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

Авторы: Юшков Т.


Источник: http://www.opennet.ru/docs/RUS/mpls/mplsvpn.html

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


Данная статья описывает принципы организации и функционирования VPN на базе MPLS


Общие понятия

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

Определим следующие понятия:

Пусть сеть оператора использует технологию MPLS/VPN. Маршрутизаторы сети Оператора образуют MPLS домен. К оператору подключены несколько клиентов. Каждому клиенту организован его личный VPN. Список узлов клиентов представлен в табл. N1, схема их подключения на рис. N1.


Схема MPLS домена подключенных узлов клиентов 

Рис.1.  — Схема MPLS домена и подключенных узлов клиентов


Табл. N1. Пример схемы объединения узлов в VPN 

Клиент
 VPNs
 Узлы
КлиентN1
 A
 1, 6
КлиентN2
 B
 3, 4, 5
КлиентN3
 C
 2, 8
КлиентN4
 D
 7, 9

Каждый клиент в рамках своей VPN может свободно обмениваться IP трафиком.
В рамках MPLS/VPN допускается организация взаимодействия нескольких разных узлов в соответствии со следующими схемами:

Примечание: Узел может быть как членом закрытой абонентской группы, так и членом группы центр-периферия (как в качестве центрального узла, так и в качестве периферийного).

 

В примере, приведенном на рисунке, VPN могут объединяться в группы так:

В этом случае, допускается пересечения адресных пространств у узлов 3, 4, 5 с 1, 6 и 3, 4, 5 с 2, 8.


Функционирование PE

Для обслуживания клиентов разных VPN на устройстве PE (к которому эти клиенты присоединены) создается несколько виртуальных объектов (по одной на каждый VPN). Называются  такие объекты - VPN Routing and Forwarding (VRF). VRF образовываются:

Между устройствами CE и PE необходима настройка статической маршрутизации или протокола динамической маршрутизации. В качестве протокола динамической маршрутизации может быть использован RIP, OSPF или BGP. Маршрутная информация, полученная от устройства CE устанавливается в соответствующую VRF-таблицу. Рассмотрим пример на рис. N2. К устройству PE1 подключено три узла CE1, CE2, CE3. CE1 и CE2 принадлежат VPN-у A, а CE3 VPN-у B.

Рис.2 Пример подключения маршрутизаторов 

Рис. 2.  — Пример подключения узлов маршрутизаторов CE к PE.

 

Табл. 2. Разбиение интерфейсов по VRF. 

Интерфейс
 Сосед
 VPN
 VRF
int0
 CE3
 B
 B
int1
 CE2
 A
 A
int2
 CE1
 A
 A

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


Табл. 4. Таблица маршрутизации на устройстве 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

Примечание: Для удобства я объединил все таблицы маршрутизации в одну. Принадлежность маршрута той или иной VRF таблице определяется значением в колонке "VRF".

Описание полей таблицы: Протокол - название протокола маршрутизации, по которому была получена маршрутная информация о префиксе. VRF - название VRF-таблицы, которой принадлежит префикс. Подсеть, Next-hop - уже знакомые нам поля.

Запись N1 и N2 в таблице маршрутизации PE1 были созданы на основании маршрутной информации полученной от CE1 и CE2 по протоколу OSPF. Так как данные маршруты были получены от устройств CE1 и CE2, принадлежащих VPN A, то записи принадлежат VRF-таблице A (колонка VRF).

Запись N3 была создана на основании маршрутной информации полученной от устройства CE3 по протоколу RIP. Так как данный маршрут был получен от устройства CE3, принадлежащего VPN B, то запись принадлежит VRF-таблице B.
Заметим, что устройства CE1 и CE2 могут обмениваться трафиком друг с другом через PE1. Для маршрутизации пакетов между устройствами CE1 и CE2 на PE1 используется VRF-таблица А (записи N1 и N2). Устройство CE3 не может обмениваться трафиком ни c CE1, ни с CE2, так как для маршрутизации пакетов пришедших от CE3 используется VRF-таблица B. В этой таблице нет маршрутной информации от CE1 и CE2.
Таким образом, PE1 может осуществлять маршрутизацию трафика для разных VPN на основании разных таблиц маршрутизации. Для того, что бы различные CE, принадлежащие одной VPN и подключенные к разным PE могли обмениваться трафиком необходимо наличие механизмов:

Далее эти механизмы будут рассмотрены детально.


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


VPN - это принцип объединения узлов клиента, находящихся под единым административным подчинением, через публичную сеть оператора(ов). Описывается VPN множеством узлов, которые он объединяет и технологией использующейся для организации VPN. Например: MPLS/VPN, IPSec/VPN и т.д.
VRF - это объект в состав которого входят:

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


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


Определим следующие понятия:

Понятия входной/выходной PE определяются для конкретного направления трафика. Например, если пакет следует от CE1 до CE2 (см. рис. N3), то устройство PE1 будет входным PE, а PE2 выходным. Если же пакет следует в обратную сторону, то наоборот, устройство PE2 будет входным, а PE1 выходным.
Для коммутации пакетов VPN между устройствами PE используется две метки, образующие стек. Это означает, что IP пакету, полученному от CE, входной PE назначает стек из двух меток. Одна ("внешняя") используется непосредственно для коммутации пакета устройствами LSR (или P). "Внешняя" метка определяет LSP от одного PE до другого. Вторая метка - "внутренняя" идентифицирует VRF на выходном PE, которому принадлежит пакет.

Примечание: "Внутренняя" метка может идентифицировать даже не VRF на выходном PE, а конкретный интерфейс на устройстве выходном PE, через который должен быть переслан пакет. Подробнее об этом случае будет сказано далее.


Рассмотрим MPLS домен, к которому подключены два VPN A и B (рис. N3). VPN A образован узлами CE1 и CE2, VPN B - узлами CE3 и CE4. Как видно из рисунка IP адресация внутри VPN A и B пересекается. Таблица маршрутизации (включая VRF-таблицы) представлена в табл. 4.


 

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


Табл. 4. Таблица маршрутизации на 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
 нет

Предполагается, что PE2 использует режим Penumilate Hop Popping, то есть пакет к нему приходит уже без "внешней" метки (она снимается на последнем LSR-е). Это означает, что VPN пакеты приходят к PE только с одной меткой - "внутренней".
Возможно два режима назначения "внутренней" метки устройством PE:

Примечание: В примере таблицы коммутации PE2 в колонке "Выходной интерфейс" указано два значения через "/". Первое для режима "внутренняя метка определяет интерфейс", второе для режима "внутренняя метка определяет VRF".


 

Рис. 3.  — Схема прохождения пакета 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


В данном разделе рассмотрим механизм распространения маршрутной информации о сетях VPN и "внутренних" метках. Для распространения данной информации используется протокол BGP.
Традиционно маршрутная информация передаваемая по BGPv4 состояла из двух компонент:

К сожалению, такое представление маршрутной информации было ориентировано только на традиционные маршруты IPv4. В RFC 2858 "Multiprotocol Extentions for BGP4"и RFC 3107 "Carrying Label Information in BGP-4" форма представления маршрутной информации была переработана.
Компонента NLRI была переведена в класс атрибутов маршрута, поменяла свою структуру и стала называться MP_REACH_NLRI (attribute type code = 14). Состав атрибута:

Примечание: Некоторые реализации MPLS/VPN используют значение SAFI=128, это устаревший подход. В соответствии с RFC3107 и распределением IANA значение SAFI должно равняться 4.

Заметим, что информация о next-hop и NLRI (описание подсети) мигрировала из отдельных атрибутов в состав структуры MP_REACH_NLRI. Изменения так же коснулись и структуры представления next-hop и адреса подсети.
Так как подсети различных VPN могут пересекаться, то для обеспечения их уникальности префиксы подсетей VPN состоят из двух частей:

  • Route Distinguisher (RD) - дискриминатор маршрутной информации. RD обеспечивает уникальность префикса VPN (8 байт);
  • IPv4 network address - традиционный префикс IPv4 (4 байта).

Форма представление префикса подсети как пары RD и IPv4 называется VPN-IPv4 address family.
RD состоит из трех полей:

  • тип (2 байта) - данное поле определяет структуру и размер следующих полей;
  • глобальная (административная) компонента;
  • локальная компонента (индекс).

Значение компонент определяется полем тип. Возможные варианты указаны в таблице N6.

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

 
Значение поля "тип"
 Размер глобальной компоненты (байт)
 Значение глобальной компоненты
 Размер локальной компоненты (байт)
 Значение локальной компоненты
0
 2
 Номер автономной системы в соответствии  с RFC1930 
 4
 Номер уникально идентифицирующий RD.
1
 4
 IPv4 адрес
 2
2
 4
 Номер автономной системы в соответствии с  (draft-ietf-idr-as4bytes) 2

Особого смысла значение административной компоненты и "номера" не имеют. Основная их цель формировать RD по правилам, обеспечивающим глобальную уникальность префиксов VPN. Именно поэтому, RD должен образовываться или IP адресом или номером Автономной системы. Данные номера (адреса) распределяются централизовано (например:RIPE NNC), тем самым обеспечена их глобальная уникальность в рамках всех сетей.

Так же "BGP Extended Communities Attribute" (draft-ietf-idr-bgp-ext-communities) вводит понятие расширенные атрибуты маршрута включающее в себя следующие атрибуты:

  • Site of Origin - атрибут, идентифицирующий точку подключения клиента (site).
  • Route Target - набор идентификаторов, описывающих правила импорта/экспорта.

Эти атрибуты свойственны только маршрутам VPN при использовании MPLS/VPN.
Форма представления расширенных атрибутов следующая:

  • тип атрибута атрибута (1 байт);
  • идентификатор атрибута (1 байт) Site of Origin = 3, Route Target = 2;
  • глобальная компонента (длинна перемена);
  • локальная компонента (длинна перемена);

Оба атрибута кодируются по схеме аналогичной дискриминатору маршрутной информации (RD) табл.3.
Route Target является обязательным атрибутом, в то время как Site of Origin нет.
Оба атрибута являются транзитивными, то есть сохраняются при передаче маршрутов по EBGP сессиям между разными Автономными системами.
В состав атрибутов одного VPN маршрута может входит несколько атрибутов RT. Далее мы будем говорить о множестве атрибутов RT, ассоциированных с данным VPN маршрутом.


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


К каждому объекту VRF на каждом PE привязывается два множества атрибутов RT:
  • import;
  • export.
Множество могут содержать один или более атрибутов RT. Правила распространения маршрутной информации следующие:
  1. Все маршруты, полученные от CE, принадлежащие VRF X, передаются другим PE с добавлением множества атрибутов RT "export" VRF-а X.
  2. Маршрут, полученный от другого PE, будет установлен в VRF-таблицу Y, только если множество атрибутов RT полученное с маршрутом и множество "import" VRF-а Y имеют хотя бы один общий атрибут.
Рассмотрим пример. Схема представлена на рис. N4. Маршрутная информация, получаемая маршрутизатором PE1 представлена в табл.7.
 

Рис. 4.  — Схема подключения маршрутизаторов 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

Так как маршрутная информация получена от PE2, то значение атрибута next-hop у всех маршрутов одинаково: 172.16.1.1. Это виртуальный интерфейс маршрутизатора PE2, от которого организована iBGP сессия. Как видно из таблицы маршруты VPN представляют собой пару RD:префикс. Назначение RD обсуждалось ранее.  Заметим, что префиксы 8:1:10.2.1.0/24 и 8:2:10.2.1.0/24 отличаются только значением RD (IPv4 адрес подсети одинаковый). Это означает, что маршруты разные, принадлежат разным VPN и соответственно, ассоциированы с разным набором атрибутов RT.

В соответствии с правилами использования атрибутов RT префиксы распределяются по таблицам маршрутизации следующим образом:
  • 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.

Таблицы маршрутизации VRF на PE показаны в табл. N9. Рассмотрим схему назначения меток.

Табл.10. Таблицы маршрутизации 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
 нет

Предположим, что значение метки, используемой для коммутации пакета от PE1 до PE2, равно 1001. То есть метка 1001 определяет LSP от PE1 до PE2. Напомним, что пакетам VPN при прохождении через MPLS домен назначается две метки:

  • "внешняя" - определяет LSP от одного PE до другого (в нашем случае 1001);
  • "внутренняя" - определяет VRF или интерфейс на PE, к которому присоединен абонент (данная метка распространяется по BGP, значения для нашего случая представлены в табл. N8, колонка "VPN-label")

Таким образом, IP пакету, пришедшему от CE1 и предназначенному для подсети 10.2.1.0/24 назначается стек из двух меток: внутренняя 100 - идентификатор VRF на PE2 и "внешняя" 1001, определяющая LSP до PE2.
Отметим, что префиксам 10.2.1.0/24 в разных VRF-таблицах (A и C) устанавливается разная "внутренняя" метка. Это означает, что IP пакет, предназначенный для подсети 10.2.1.0/24 и пришедший от CE1 будет переправлен с "внутренней" меткой 100, а пришедший от CE3 с "внутренней" меткой 200. Таким образом, эти пакеты попадут в разные VRF на PE2 и соответственно, будут перенаправлены разным CE. Таким образом, MPLS/VPN позволяет объединять узлы с пересекающимися адресными пространствами в различные VPN.

Рассмотрим пример маршрутной информации передаваемой от PE1 до PE2 по протоколу BGP. PE1 получает, от подключенных к нему CE, три префикса. Каждый префикс принадлежит определенному VRF (см табл N10). В соответствии с настройками VRF-ов (см. табл. N7), каждому префиксу назначается RD и множество атрибутов RT. Например, префикс 10.1.1.0/24, полученный от CE1 принадлежит к VRF А, так как CE1 принадлежит к VPN A. В соответствии с конфигурацией VRF A данному префиксу назначается RD 6:1 и множество RT, которое полностью копируется из множества "export" VRF-а A. Так же PE1 назначает "внутреннюю" метку для префикса 6:1:10.1.1.0/24. Метка назначается автоматически в зависимости от режима назначения меток: или VRF-а, или интерфейса, через которые получен маршрут. Так как, VPN маршруты образовываются на PE1, то значение атрибута next-hop устанавливается равным 172.16.1.2 - виртуальный интерфейс, от которого PE1 устанавливает iBGP сессию.

Табл. 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

Примечание: Непосредственно по iBGP передаются только поля: префикс+RD, RT, VPN метка и next-hop

.

Примечание: Назначение "внутренних" меток личное дело каждого PE, то есть одинаковая метка от разных PE вовсе не означает один и тот же VPN.

Отметим, что PE1 получает маршрут 10.1.1.0/24 от двух разных CE (CE1 и CE3), но так как эти CE принадлежат разным VRF, то этим префиксам назначаются разные RD, множество RT и VPN метка.
Итак, подводя итоги долгому и нудному повествованию:

  1. VPN пакеты передаются через MPLS домен с двумя метками ("внешней" и "внутренней").
  2. "Внешняя" метка определяет LSP от одного PE до другого.
  3. "Внутренняя" метка определяет или VRF или выходной интерфейс на устройстве PE.
  4. Правила импорта маршрутной информации задаются значением множеств VRF import и export (подробно о том как использовать эти возможности будет сказано в отдельной статье).

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



Основными преимуществами организации VPN на базе MPLS можно назвать:

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

Масштабируемость достигается за счет того, что подключение нового узла в существующий VPN производиться только перенастройкой одного PE, к которому подключается данный узел.
В различных VPN адресные пространства могут пересекаться, что может быть чрезвычайно полезным, в случае если оператору необходимо предоставить VPN нескольким клиентам, использующим одинаковое приватное адресное пространство, например адреса 10.0.0.0/8.
Устройства P (LSR) при коммутации анализируют только внешнюю метку, определяющую LSP между PE, и не анализируют заголовок IP пакета, то справедливо говорить о том, что P устройства выполняют функции коммутации на втором уровне модели OSI. Устройства PE так же разделяют маршрутную информацию, таблицы маршрутизации, интерфейсы, направленные в сторону устройств CE, между VRF. Тем самым процессы маршрутизации разных VPN полностью разделяются, и обеспечивается разделение трафика от разных VPN на втором уровне модели OSI. На этот предмет компания Miercom провела исследование, и показала, что технология MPLS/VPN в реализации компании Cisco Systems обеспечивает такой же уровень безопасности как сети Frame Relay и ATM.

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

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

Табл.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)