The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Каталог документации / Раздел "Cisco маршрутизаторы и коммутаторы" / Оглавление документа
Автор: Юшков Тарас (taras at mpls-exp.ru)

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

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

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

VPN - это принцип объединения узлов клиента, находящихся под единым административным подчинением, через публичную сеть оператора(ов).
Определим следующие понятия:
Пусть сеть оператора использует технологию 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 допускается организация взаимодействия нескольких разных узлов в соответствии со следующими схемами:

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

В примере, приведенном на рисунке, 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.

Рис. 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 и 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-таблицы) представлена в табл. 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:

Примечание: В примере таблицы коммутации 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 состояла из двух компонент:
К сожалению, такое представление маршрутной информации было ориентировано только на традиционные маршруты 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 состоят из двух частей:
Форма представление префикса подсети как пары RD и IPv4 называется VPN-IPv4 address family.
RD состоит из трех полей:
Значение компонент определяется полем тип. Возможные варианты указаны в таблице N6.
Табл. N6. Форма представления поля 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) вводит понятие расширенные атрибуты маршрута включающее в себя следующие атрибуты:
Эти атрибуты свойственны только маршрутам VPN при использовании MPLS/VPN.
Форма представления расширенных атрибутов следующая:
Оба атрибута кодируются по схеме аналогичной дискриминатору маршрутной информации (RD) табл.N3.
Route Target является обязательным атрибутом, в то время как Site of Origin нет.
Оба атрибута являются транзитивными, то есть сохраняются при передаче маршрутов по EBGP сессиям между разными Автономными системами.
В состав атрибутов одного VPN маршрута может входит несколько атрибутов RT. Далее мы будем говорить о множестве атрибутов RT, ассоциированных с данным VPN маршрутом.

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

К каждому объекту VRF на каждом PE привязывается два множества атрибутов RT:
Множество могут содержать один или более атрибутов RT. Правила распространения маршрутной информации следующие:
  1. Все маршруты, полученные от CE, принадлежащие VRF X, передаются другим PE с добавлением множества атрибутов RT "export" VRF-а X.
  2. Маршрут, полученный от другого 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 префиксы распределяются по таблицам маршрутизации следующим образом:
Таблицы маршрутизации 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 домен назначается две метки:
Таким образом, 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 производиться только перенастройкой одного 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 не обеспечивает целостности и конфиденциальности передаваемых данных.

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

  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)





Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2021 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру