VPN - это принцип объединения узлов клиента, находящихся под
единым административным подчинением, через публичную сеть оператора(ов).
Определим следующие понятия:
CE - маршрутизатор со стороны узла клиента, который
непосредственно подключается к маршрутизатору оператора.
PE - граничный маршрутизатор со стороны оператора (MPLS домена),
к которому подключаются устройства CE.
PE устройства выполняют функции E-LSR-ов.
P - маршрутизатор внутри сети Оператора (MPLS домена). P
устройства выполняют функции LSR.
Пусть сеть оператора использует технологию MPLS/VPN. Маршрутизаторы
сети Оператора образуют MPLS домен. К оператору подключены несколько
клиентов. Каждому клиенту организован его личный VPN. Список узлов
клиентов представлен в табл. N1, схема их подключения на рис. N1.
Рис. N1. Схема 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 допускается организация взаимодействия нескольких
разных узлов в соответствии со следующими схемами:
закрытая абонентская группа
(Closed User Group - CUG). данная схема предусматривает взаимодействия
узлов только друг с другом. Например, в CUG может входить
узлы 1, 3, 4, 5, 6. Это означает, что данные узлы будут свободно
обмениваться IP
трафиком. В рамках CUG не допускается пересечения адресного
пространства узлов.
центр-периферия (hub-and-spoke).
Схема подразумевает объединение нескольких узлов, один или несколько из
которых объявляется центральным, а остальные периферийными. Центральные
узлы могут обмениваться IP трафиком друг с другом. Периферийные узлы
могут обмениваться трафиком с центральными. Но периферийные узлы не
могут
обмениваться трафиком друг с другом.
Примечание: Узел может быть как
членом закрытой абонентской группы, так и членом
группы центр-периферия (как в качестве центрального узла, так и в
качестве периферийного). В примере, приведенном на
рисунке,
VPN могут объединяться в группы
так:
Узлы 3, 4, 5, 7, 9 - образуют закрытую абонентскую группу (Closed
User
Group - CUG).
VPN 1, 2, 6, 7, 8, 9 - hub-and-spoke, где узлы 1 и 6 -
центральные, 2, 7, 8 и 9
- периферийные VPN (spokes).
В этом случае, допускается пересечения адресных пространств у
узлов 3, 4, 5 с 1, 6 и 3, 4, 5 с 2, 8.
Функционирование PE
Для обслуживания клиентов разных VPN на устройстве PE (к которому эти
клиенты
присоединены) создается несколько виртуальных объектов (по
одной на каждый VPN). Называются такие объекты - VPN Routing and
Forwarding (VRF). VRF образовываются:
отдельной таблицей IP-маршрутизации, использующейся для
маршрутизации пакетов VPN (далее VRF-таблица);
множеством интерфейсов устройства PE, по которым подключены
устройства CE, принадлежащие одной VPN. То есть, интерфейс на
устройстве PE, к которому
подключен узел, входящий в VPN Х, принадлежит VRF Х.
Между устройствами CE и PE необходима настройка статической
маршрутизации или
протокола динамической маршрутизации. В качестве протокола динамической
маршрутизации может быть использован RIP, OSPF или BGP. Маршрутная
информация, полученная от устройства CE устанавливается в
соответствующую
VRF-таблицу. Рассмотрим пример на рис. N2. К
устройству PE1
подключено три узла CE1, CE2, CE3. CE1 и CE2 принадлежат VPN-у
A, а CE3 VPN-у B.
Рис. N2. Пример подключения узлов маршрутизаторов CE к PE.
Табл. N2. Разбиение интерфейсов
по VRF.
Интерфейс
Сосед
VPN
VRF
int0
CE3
B
B
int1
CE2
A
A
int2
CE1
A
A
Таблица маршрутизации на устройстве 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
Примечание: Для удобства я
объединил все таблицы маршрутизации в одну.
Принадлежность маршрута той или иной 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 внутри MPLS домена
(устройствами LSR);
обмена маршрутной информацией между устройствами PE,
включая информацию о VPN.
Далее эти механизмы будут рассмотрены детально.
Отличие понятий VPN и
VRF
VPN - это принцип объединения узлов клиента, находящихся под
единым административным подчинением, через публичную сеть
оператора(ов). Описывается VPN множеством узлов, которые он объединяет
и
технологией использующейся для организации VPN. Например: MPLS/VPN,
IPSec/VPN и т.д.
VRF - это объект в состав которого входят:
множество интерфейсов PE, к которым подключаются CE из одного VPN;
VRF-таблица;
атрибуты и правила распространения маршрутной информации (об этом
будет рассказано далее).
VRF локален для каждого устройства PE. Понятие VPN распространяется на
всю сеть. Таким образом, VPN не равно VRF. VRF это, скорее, описание
VPN-а в рамках одного устройства PE.
Потому, сколько различных узлов VPN-ов подключено к PE, столько и
VRF-ов необходимо создать.
Механизм коммутации
пакетов
Определим следующие понятия:
входной PE - первое устройство PE на пути следования IP пакета от
одного устройства CE до другого через MPLS домен;
выходной PE - последнее устройство PE на пути следования IP
пакета от одного устройства CE до другого через MPLS домен.
Понятия входной/выходной 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-таблицы)
представлена в табл. N4.
Рис 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
нет
Предполагается, что PE2 использует режим Penumilate Hop Popping,
то есть
пакет к нему приходит уже без "внешней" метки (она снимается на
последнем LSR-е). Это означает, что VPN пакеты приходят к PE только с
одной меткой - "внутренней".
Возможно два режима назначения "внутренней" метки устройством PE:
"внутренняя" метка определяет выходной интерфейс на
выходном PE. В этом случае выходной
интерфейс (и соответственно CE которому
предназначен пакет) определяется значением этой метки;
"внутренняя" метка определяет VRF на выходном PE. В этом случае
выходной
интерфейс (и соответственно CE которому предназначен пакет)
определяется после анализа соответствующей VRF-таблицы.
Примечание: В примере таблицы
коммутации PE2 в колонке "Выходной интерфейс" указано два значения
через "/". Первое для режима "внутренняя метка определяет интерфейс",
второе для режима "внутренняя метка определяет 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
В данном разделе рассмотрим механизм распространения маршрутной
информации о сетях VPN и "внутренних" метках. Для
распространения
данной информации используется протокол BGP.
Традиционно маршрутная информация передаваемая по BGPv4 состояла из
двух компонент:
NLRI - Network Layer Reachability Information - данная компонента
описывала только префикс маршрута (например: 10.1.1.0/24).
Path attributes - атрибуты маршрута, включая адрес next-hop.
К сожалению, такое представление маршрутной информации было
ориентировано
только на традиционные маршруты IPv4. В RFC 2858 "Multiprotocol
Extentions for BGP4" и RFC 3107 "Carrying Label
Information in BGP-4"
форма представления маршрутной информации была
переработана.
Компонента NLRI была переведена в класс атрибутов маршрута, поменяла
свою структуру и стала называться MP_REACH_NLRI (attribute type
code = 14). Состав атрибута:
Address Family Identifier (AFI) (2 байта) = 1 (маршрут класса
IPv4);
Subsequent Address Family Identifier (AFI) (1 байт) = 4 (описание
маршрута включает "внутренние" метки VPN);
Next-hop;
SNPA - Subnetwork Points of Attachment - параметр мутный, для
MPLS/VPN не используется;
Примечание: Некоторые
реализации MPLS/VPN используют значение SAFI=128, это устаревший
подход. В соответствии с
RFC3107 и распределением
IANA значение SAFI должно равняться 4.
Заметим, что информация о next-hop и NLRI (описание подсети)
мигрировала из отдельных атрибутов в
состав структуры MP_REACH_NLRI. Изменения так же
коснулись и структуры представления next-hop и адреса подсети.
Так как подсети различных VPN могут пересекаться, то для обеспечения их
уникальности префиксы подсетей VPN состоят из двух частей:
Особого смысла значение административной
компоненты и "номера" не имеют. Основная их цель формировать 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) табл.N3.
Route Target является обязательным атрибутом, в то время как Site of
Origin нет.
Оба атрибута являются транзитивными, то есть сохраняются при передаче
маршрутов по EBGP сессиям между разными Автономными системами.
В состав атрибутов одного VPN маршрута может входит несколько атрибутов
RT. Далее мы будем говорить о множестве
атрибутов RT, ассоциированных с данным VPN маршрутом.
Организация VPN
К каждому объекту VRF на каждом PE привязывается два множества
атрибутов RT:
import;
export.
Множество могут содержать один или более атрибутов RT. Правила
распространения маршрутной информации следующие:
Все маршруты, полученные от CE, принадлежащие VRF X, передаются
другим PE с добавлением множества атрибутов RT "export" VRF-а X.
Маршрут, полученный от другого PE, будет установлен в VRF-таблицу
Y,
только если множество
атрибутов RT полученное с маршрутом и множество "import" VRF-а Y
имеют хотя бы один общий атрибут.
Рассмотрим пример. Схема представлена на рис. N4. Маршрутная
информация, получаемая маршрутизатором PE1 представлена в табл. N7.
Рис. 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
Так как маршрутная информация получена от 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. Рассмотрим схему
назначения меток.
Табл. 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
нет
Предположим, что значение метки, используемой для коммутации пакета от
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 сессию.
Примечание: Непосредственно по
iBGP передаются только поля:
префикс+RD, RT, VPN метка и next-hop. Примечание: Назначение
"внутренних" меток личное дело каждого PE, то есть одинаковая метка от
разных PE вовсе не означает один и тот же VPN. Отметим, что PE1 получает маршрут
10.1.1.0/24 от двух разных CE (CE1 и CE3), но так как эти CE
принадлежат разным VRF, то этим префиксам назначаются разные RD,
множество RT и VPN метка.
Итак, подводя итоги долгому и нудному повествованию:
VPN пакеты передаются через MPLS домен с двумя метками ("внешней"
и "внутренней").
"Внешняя" метка определяет LSP от одного PE до другого.
"Внутренняя" метка определяет или VRF или выходной интерфейс на
устройстве PE.
Правила импорта маршрутной информации задаются значением множеств
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.
Табл. N 11. Сравнение основных
технологий по организации VPN.
Критерии
MPLS/VPN
ATM/Frame Relay
IPSec
GRE
Масштабируемость
высокая
низкая
низкая
низкая
Требования к оператору
поддержка технологии MPLS/VPN
поддержка ATM/Frame Relay
нет
нет
Требования к клиенту
нет
поддержка ATM/Frame Relay
наличие средств шифрования
поддержка туннелирования трафика
Обеспечение целостности и
конфиденциальности
нет
нет
да
нет
Пересечение адресных пространств
узлов подключенных в разные VPN
допускается
допускается
необходимо использовать NAT со
стороны клиента
необходимо использовать NAT со
стороны клиента
Особо необходимо отметить, что технология MPLS/VPN не обеспечивает целостности
и конфиденциальности передаваемых данных.
