Автор: Тарас Юшков. Рубрики: Сети и телекоммуникации. Опубликовано: Май 20th, 2010

Отличие понятий 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 (см. рис. №3), то устройство PE1 будет входным PE, а PE2 выходным. Если же пакет следует в обратную сторону, то наоборот, устройство PE2 будет входным, а PE1 выходным.
Для коммутации пакетов VPN между устройствами PE используется две метки, образующие стек. Это означает, что IP пакету, полученному от CE, входной PE назначает стек из двух меток. Одна («внешняя») используется непосредственно для коммутации пакета устройствами LSR (или P). «Внешняя» метка определяет LSP от одного PE до другого. Вторая метка — «внутренняя» идентифицирует VRF на выходном PE, которому принадлежит пакет.


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


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


Протокол 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.
Запись №1 была создана на основании маршрутной информации полученной от CE1 по протоколу OSPF. Так как данный маршрут был получен от устройства CE1, принадлежащего VPN A, то запись отнесена в VRF-таблицу A (колонка VRF).
Запись №3 была создана на основании маршрутной информации полученной от CE3 по протоколу RIP. Так как данный маршрут был получен от устройства CE3, принадлежащего VPN B, то запись отнесена в VRF-таблицу B.

Запись №5 была создана на основании протокола маршрутизации, функционирующего внутри MPLS домена, и протокола LDP. Метка 345 будет назначаться пакетам, предназначенным для PE2. То есть данная метка определяет LSP от PE1 до PE2.
Записи №2 и №4 были созданы на основании маршрутной информации полученной от 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).

Входной интерфейс Входная метка Выходной интерфейс Выходная метка
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».

Рассмотрим прохождения пакета из 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 не используется;
• Структура MP_NLRI — Multi Protocol Network Layer Reachability Information (определена в RFC 3107 «Carrying Label Information in BGP-4″):
— метка;
—  префикс подсети VPN маршрута.

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

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

Значение поля «тип» Размер глобальной компоненты (байт) Значение глобальной компоненты Размер локальной компоненты (байт) Значение локальной компоненты
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 имеют хотя бы один общий атрибут.

Рассмотрим пример. Схема представлена на рис. №4. Маршрутная информация, получаемая маршрутизатором PE1 представлена в табл. №7.

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. Содержание информации представлено в табл. №8.


Префикс Атрибуты 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 показаны в табл.  Рассмотрим схему назначения меток.

Табл. №9. Таблицы маршрутизации 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, значения для нашего случая представлены в табл. №8, колонка «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 (см табл №10). В соответствии с настройками VRF-ов (см. табл. №7), каждому префиксу назначается 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 сессию.

Табл. №10. Маршрутная информация, отправляемая по 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 приведено в табл. № 11.

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

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

Поделиться

Опубликовать в Facebook
Опубликовать в Google Buzz
Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Мой Мир
Опубликовать в Одноклассники
Опубликовать в Яндекс

Мы в социальных сетях

Читать ProITClub в TwitterЧитать ProITClub в RSSЧитать ProITClub в п&##1086;чтовой подпискеЧитать ProITClub в Живом ЖурналеЧитать ProITClub в LinkedInЧитать ProITClub в LinkedIn
Вы можете оставить комментарий, или поставить трэкбек со своего сайта.

Написать комментарий

Вы должны войти чтобы добавить сообщение.