return

Сети для самых маленьких. Микровыпуск №7. Взаимодействие между VPN

13 марта 2016, 19:24

Взаимодействие между VPN

Где-то там — далеко вверху — мы предположили существование некого третьего клиента — R2D2, у которого есть некоторые виды на C3PO — а конкретно они должны обмениваться маршрутами, находясь при этом в разных VPN.
Вот такая схема:
Здесь мы поработаем с RT — сделаем так, чтобы маршруты из VPN C3PO передавались в R2D2 протоколом BGP. Ну, и обратно — куда без этого?
Конфигурация маршрутизатора R2D2:

R2D2(config)#interface Loopback0
R2D2(config-if)#ip address 10.10.10.10 255.255.255.255

R2D2(config)#interface FastEthernet0/0
R2D2(config-if)#description To Linkmeup
R2D2(config-if)#ip address 10.10.10.2 255.255.255.252

R2D2(config)#router ospf 1
R2D2(config-router)#network 10.10.10.0 0.0.0.255 area 0

Настройка VRF на Linkmeup_R3:

Linkmeup_R3(config)#ip vrf R2D2
Linkmeup_R3(config-vrf)#rd 64500:300
Linkmeup_R3(config-vrf)#route-target both 64500:300
Linkmeup_R3(config-vrf)#route-target import 64500:100

Linkmeup_R3(config-router)#interface FastEthernet1/1
Linkmeup_R3(config-if)#ip vrf forwarding R2D2
Linkmeup_R3(config-if)#ip address 10.10.10.1 255.255.255.252

Linkmeup_R3(config-vrf)#router ospf 3 vrf R2D2
Linkmeup_R3(config-router)#redistribute bgp 64500 subnets
Linkmeup_R3(config-router)#network 10.10.10.0 0.0.0.3 a 0

Linkmeup_R3(config)#router bgp 64500
Linkmeup_R3(config-router)#address-family ipv4 vrf R2D2
Linkmeup_R3(config-router-af)#redistribute ospf 3

Собственно ничего здесь нового нет, за исключением настройки route-target в VRF.
Как видите, кроме обычной команды «route-target both 64500:300» мы дали ещё и «route-target import 64500:100». Она означает, что в VRF необходимо импортировать маршруты с RT 645500:100, то есть из VPN C3PO, как мы этого и хотели.
Сразу после этого маршруты появляются на R2D2: После этого пинг успешно проходит до 192.168.255.2: Но, если запустить пинг до адреса 192.168.255.1, то он не пройдёт. Почему? Для интереса вы можете добавить на TARS_2 Loopback 1 с адресом 10.10.10.10/32 — такой же, как у Loopback 0 R2D2 и посмотреть что из этого получится.
Полная конфигурация всех узлов для сценария взаимодействия между VPN.

Доступ в Интернет из VPN

Эта тема очень плохо раскрыта в рунете. Мне не удалось найти сколько-нибудь вменяемого описания что это вообще такое.
Восполняя этот пробел, я добавляю этот параграф в статью.
Вполне вероятно, что вы сейчас читаете эксклюзивный материал.
Итак, может статься, что провайдер в тот же самый VPN продаёт и доступ в Интернет. Именно в VPN, не отдельный кабель, не отдельный VLAN, а именно доступ в Интернет через то же самое подключение, через те же адреса. Это может быть также капризом заказчика.
Ясное дело, что понадобится NAT, чтобы спрятать частные сети.
Так вот есть 3 подхода к реализации этого функционала, которые различаются лишь местом, где происходит трансляция адресов:

  1. В сети заказчика, например, на CE.
  2. На Ingress PE — маршрутизаторе, к которому подключен CE.
  3. На Egress PE — маршрутизаторе, который подключен к Интернету.

Каждый из них имеет право на жизнь. Рассмотрим все.

NAT на CE

Такой NAT возможен, например, когда у клиента уже есть публичные адреса. Тогда в этот пул транслируются внутренние адреса. Всё, что остаётся сделать провайдеру — настроить маршрутизацию между VRF и глобальной таблицей.
Учитывая, что трансляция будет на CE, то нужно выбрать только один филиал, пусть это будет TARS_2 — там как раз у нас линковая сеть публичная — 100.0.1.0/30. Как видите, для этого теста нам нужно что-то в качестве Интернета и компьютер, которому доступ туда нужен.
В новом GNS есть такой чудесный объект, как VPCS, который прекрасно подходит на эту роль.
На TARS_2 нужно настроить NAT, ниже его конфигурация:

TARS_2(config)#interface Loopback0
TARS_2(config-if)#ip address 172.16.255.2 255.255.255.255

TARS_2(config)#interface FastEthernet0/0
TARS_2(config-if)#description To Linkmeup
TARS_2(config-if)#ip address 100.0.1.2 255.255.255.252
TARS_2(config-if)#ip nat outside

TARS_2(config)#interface FastEthernet0/1
TARS_2(config-if)#description To LAN
TARS_2(config-if)#ip address 172.16.1.1 255.255.255.0
TARS_2(config-if)#ip nat inside

TARS_2(config)#router bgp 64502
TARS_2(config-router)#network 172.16.1.0 mask 255.255.255.0
TARS_2(config-router)#network 172.16.255.2 mask 255.255.255.255
TARS_2(config-router)#neighbor 100.0.1.1 remote-as 64500

TARS_2(config)#ip nat inside source list 100 interface FastEthernet0/0 overload

TARS_2(config)#access-list 100 deny ip 172.16.0.0 0.0.255.255 172.16.0.0 0.0.255.255
TARS_2(config)#access-list 100 permit ip 172.16.0.0 0.0.255.255 any

access-list 100 состоит из двух строк — первая запрещает трансляцию адресов для пакетов, которые идут из своей сети в свою же сеть, находящуюся на другом конце провайдера.
Вторая строка разрешает трансляцию только для адресов своей сети. Если вдруг вы пропишите permit ip any any, то сразу же упадёт BGP-сессия с Linkmeup_R3.
Подробности по настройке NAT были освещены в пятой части СДСМ.
Конфигурация Интернета:

Internet(config)#interface Loopback0
Internet(config-if)#ip address 101.0.0.101 255.255.255.255

Internet(config)#interface FastEthernet0/0
Internet(config-if)#description To linkmeup
Internet(config-if)#ip address 101.0.0.1 255.255.255.252

Internet(config)#router bgp 64501
Internet(config-router)#network 101.0.0.0 mask 255.255.240.0
Internet(config-router)#neighbor 101.0.0.2 remote-as 64500

Internet(config)#ip route 101.0.0.0 255.255.240.0 Null0

Настройки BGP на Internet точно такие же, как были в Балаган-Телекоме в восьмом выпуске, мы только позволили себе некоторые вольности с IP-адресами.
Интерфейс Loopback 0 на узле с именем Internet олицетворяет собой весь интернет. Пинг до него и будем проверять.
Соответствующим образом настроен и Linkmeup_R1 для связи с Internet:

Internet(config)#interface FastEthernet1/1
Internet(config-if)#description To Balagan-Telecom
Internet(config-if)#ip address 101.0.0.2 255.255.255.252

Internet(config)#router bgp 64500
Internet(config-router)#network 100.0.0.0 mask 255.255.254.0
Internet(config-router)#network 101.0.0.0 mask 255.255.255.252
Internet(config-router)#neighbor 101.0.0.1 remote-as 64501

Internet(config)#ip route 100.0.0.0 255.255.254.0 Null0

Что же касается доступа в Интернет из VPN, то в данном случае конфигурацию нужно менять только на ближайшем к CE PE — в нашем случае Linkmeup_R3.
1. Создадим маршрут по умолчанию для VRF TARS. Это для того, чтобы пакеты, пришедшие от TARS_2 не были отброшены и знали куда двигаться.

Linkmeup_R3(config)#ip route vrf TARS 0.0.0.0 0.0.0.0 101.0.0.2 global

Обратить внимание здесь нужно на две вещи:
Ключевое слово global. Оно говорит о том, что Next Hop (101.0.0.2) нужно искать в глобальной таблице маршрутизации.
В качестве адрес Next-Hop выбран линковый адрес Linkmeup_R1 в сторону Интернета. Почему не Loopback, как мы любим? Это позволяет избежать так называемого blackholing’a. Дело в том, что loopback всегда доступен, а в случае падения канала между нашим шлюзом (Linkmeup_R1) и Интернетом TARS_2 этого никак не заметит и продолжит слать трафик на Linkmeup_R3, а тот, тоже ничего не подозревая, на Linkmeup_R1. Если же мы укажем линковый адрес, то он пропадёт из таблиц маршрутизации сразу, как упадёт линия.
В результате предыдущей операции на Linkmeup_3 появляется маршрут по умолчанию: 2. Теперь его нужно сообщить клиенту, чтобы у того тоже появился маршрут по умолчанию (хотя он мог бы настроить его и самостоятельно).

address-family ipv4 vrf TARS
neighbor 100.0.1.2 default-originate

Результат: Итак, маршруты туда, то есть в Интернет, у нас уже есть, теперь что касается обратно.
3. На Linkmeup_R3 настроим статический маршрут для сети 100.0.1.0/30:

ip route 100.0.1.0 255.255.255.252 FastEthernet1/0

Зачем нам это нужно? Чтобы был маршрут, логично ведь. Если из Интернета пакет прилетит на Linkmeup_R3, а на нём не будет маршрута к 100.0.1.0/30 в глобальной таблице маршрутизации (в VRF-то он, конечно, будет), пакет будет отброшен. Было: Маршрут-то есть, да только не туда. Пакет не будет отброшен, но и до адресата не дойдёт.
Стало: 4. Далее об этой сети нужно сообщить BGP-соседям — о ней должны узнать все. В частности нас интересует Linkmeup_R1.

router bgp 64500
network 100.0.1.0 mask 255.255.255.252

Результат:

BGP в принципе и прежде знал об этой сети, но только в address-family ipv4 vrf TARS, куда она попадала с помощью команды redistribute connected. В глобальной же таблице маршрутизации её не было.

Итак, всё готово, проверяем: Это говорит о том, что заработал Route Leaking, то есть доступ из VRF в глобальную таблицу маршрутизации и наоборот работает.
Проверка доступности Интернета с компьютера — это формальность, которая покажет, что мы правильно настроили NAT. Фактически вся магия происходит на Linkmeup_R3, а знакомая нам трансляция на TARS_2, то есть вещи это по большому счёту не связанные и если Интернет доступен с TARS_2, он будет доступен и с PC1.
Однако мы проверим: Интернет доступен. Ура!

Если вам интересно, давайте проследим, что происходит с пакетом по пути от PC1 до Internet.

Повторим шаги настройки:

  • Настроить NAT. На CE.
  • Настроить маршрут по умолчанию в сторону интернета для VRF с указанием Next Hop и ключевым словом Global. На PE.
  • Заставить PE анонсировать данный маршрут по умолчанию клиенту. На PE.
  • Настроить маршрут в глобальной ТМ в сторону клиента с указанием выходного интерфейса. На PE.
  • Сообщить этот маршрут MBGP-соседям, а точнее тому узлу, который смотрит в Интернет. На CE.

Полная конфигурация интересных нам узлов.
Этот сценарий называется Route Leaking — маршруты протекают из VRF в глобальную таблицу. Название функционала говорящее — прибегать к Route Leaking’у особенно через статические маршруты нужно только в крайних случаях, ибо жуткий костыль.

VRF-Aware NAT

Более правильный и чуть более масштабируемый вариант — настройка трансляции на Egress PE — на выходе в Интернет. В этом случае у нас есть централизованный узел, где выполняются все операции и нет необходимости в Route Leaking’е через статические маршруты. Единственное неудобство: несмотря на то, что ни один клиент может быть не подключенным к этому маршрутизатору, ему придётся поддерживать все VRF, из которых нужно получать доступ в Интернет. Собственно, поэтому он и VRF-Aware.
Egress PE в нашем случае — Linkmeup_R1, который является шлюзом в интернет для всей сети linkmeup — никаких абсолютно дополнительных настроек на других узлах.
Пусть PC2 из сети C3PO Electronic (C3PO_2) хочет получить доступ в Интернет.
PC1 из TARS’ Robotics не трогаем и оставляем без изменений — они со своими белыми адресами — отдельная история, хотя их тоже вполне можно натить таким же образом.
1) Итак, во-первых на Linkmeup_R1 должен быть VRF C3PO. Он уже есть, но если бы не было, нужно было бы, чтобы было бы.
Конфигурация VRF типичная и она не поменялась:

Linkmeup_R1(config)#ip vrf C3PO
Linkmeup_R1(config-vrf)#rd 64500:100
Linkmeup_R1(config-vrf)#route-target export 64500:100
Linkmeup_R1(config-vrf)#route-target import 64500:100

2) Настраиваем NAT
Включаем ip nat inside в ту сторону, откуда получаем пакеты для трансляции, то есть в сторону P-маршрутизатора Linkmeup_R2:

Linkmeup_R1(config)#interface FastEthernet 0/1
Linkmeup_R1(config-if)#ip nat inside

В сторону Интернета включаем ip nat outside:

Linkmeup_R1(config)#interface FastEthernet 1/1
Linkmeup_R1(config-if)#ip nat outside

Создаём ACL, где разрешаем доступ из сети C3PO в интернет:

Linkmeup_R1(config)#access-list 100 permit ip 192.168.0.0 0.0.255.255 any

И собственно сам NAT:

Linkmeup_R1(config)#$ip nat inside source list 100 interface FastEthernet 1/1 overload

3) В BGP, как и в прошлый раз, прописываем отправку маршрута по умолчанию в данный VRF:

Linkmeup_R1(config)#router bgp 64500
Linkmeup_R1(config-router)#address-family ipv4 vrf C3PO
Linkmeup_R1(config-router-af)#redistribute static
Linkmeup_R1(config-router-af)#default-information originate

Заметьте, что здесь недостаточно одной только команды redistribute static, чтобы забрать и анонсировать маршрут по умолчанию. Для этого дополнительно придётся выполнить явно команду default-information originate.
Чтобы этот маршрут анонсировался BGP, нужно, чтобы он был в таблице маршрутизации:

Linkmeup_R1(config)#ip route vrf C3PO 0.0.0.0 0.0.0.0 101.0.0.1 global

Сейчас сразу не заработает, потому что я слегка слукавил, говоря, что никакие настройки нигде кроме интернет-шлюза не понадобятся.
Дело в том, что мы сгенерировали маршрут по умолчанию для VRF C3PO на Linkmeup_R1 и по BGP передали его на Linkmeup_R3, но тут он и застрял, не дойдя до C3PO_2 — нужно заставить OSPF анонсировать маршрут по умолчанию. Как и в предыдущий раз без явной команды default-information originate он этого делать не будет:

Linkmeup_R3(config)#router ospf 2 vrf C3PO
Linkmeup_R3(config-router)# default-information originate

Проверяем: Было бы странно, если бы не заработало.

Что происходит с пакетом?

Полная конфигурация узлов для VRF Aware NAT.

Common Services

До сих пор мы обсуждали задачу передачи трафика из VPN в публичные сети и обратно.
Ещё один подход к предоставлению доступа в Интернет — вывести его в отдельный VRF.
Строго говоря — он наиболее масштабируемый, потому что нет необходимости настраивать что-то индивидуально для каждого клиентского VRF.
Важное условие — NAT происходит в сети клиента и в VRF Internet импортируются только маршруты к публичным сервисам префиксам.
Common Services, который часто называют Shared Services — это продолжение вопроса о взаимодействии между VRF, который мы рассмотрели ранее. Основная идея в том, что экспорт/импорт совершается засчёт особой настройки route-target. Только на этот раз нужно ограничить список передаваемых префиксов, чтобы избежать пересечения адресных пространств и разрешить только публичные маршруты.
Рассмотрим задачу снова на примере TARS, потому что у них уже есть публичные сети.
На шлюзе мы создаём VRF Internet.

Linkmeup_R1(config)#ip vrf Internet
Linkmeup_R1(config-vrf)#rd 64500:1
Linkmeup_R1(config-vrf)#route-target import 64500:11
Linkmeup_R1(config-vrf)#route-target export 64500:22

Обратите внимание, что route-target на импорт и на экспорт в этот раз разные и сейчас станет понятно почему.
2) Перенести интерфейс в сторону Интернета в VRF:

Linkmeup_R1(config)#interface FastEthernet 1/1
Linkmeup_R1(config-if)#ip vrf forwarding Internet
Linkmeup_R1(config-if)#ip address 101.0.0.2 255.255.255.252

3) Перенести BGP-соседство с маршрутизатором в Интернете в address-family ipv vrf Internet:

Linkmeup_R1(config-router)#router bgp 64500
Linkmeup_R1(config-router)#no neighbor 101.0.0.1 remote-as 64501
Linkmeup_R1(config-router)#address-family ipv4 vrf Internet
Linkmeup_R1(config-router-af)#neighbor 101.0.0.1 remote-as 64501
Linkmeup_R1(config-router-af)#neighbor 101.0.0.1 activate

4) Объявляем маршрут по умолчанию:

Linkmeup_R1(config)#router bgp 64500
Linkmeup_R1(config-router-af)#network 0.0.0.0 mask 00.0.0.0
Linkmeup_R1(config-router-af)#default-information originate
Linkmeup_R1(config)#ip route vrf Internet 0.0.0.0 0.0.0.0 101.0.0.1

5) В клиентском VRF TARS нужно также настроить RT:

Linkmeup_R1(config-vrf)#ip vrf TARS
Linkmeup_R(config-vrf)# route-target both 64500:200
Linkmeup_R1(config-vrf)# route-target export 64500:11
Linkmeup_R1(config-vrf)# route-target import 64500:22

Итак, помимо собственного RT, который обеспечивает обмен маршрутной информацией с другими филиалами (64500:200), здесь настроены и те RT, что и для VRF Internet, но наоборот:

  • то, что было на экспорт в VRF Internet (64500:22), то стало на импорт в VRF TARS
  • то, что было на импорт в VRF Internet (64500:11), то стало на экспорт в VRF TARS

Почему так? Почему нельзя просто дать route-target both 64500:1, например, на всех VRF?
Основная идея концепции Common Service — предоставить доступ к нужному VRF клиентам, но не позволить им общаться друг с другом напрямую, чтобы обеспечить изоляцию, как того требует определение VPN.
Если настроить одинаковый RT на всех VRF, то маршруты будут спокойно ходить между ними.
При указанной же выше конфигурации у всех клиентских VRF есть RT 64500:22 на импорт (все будут получать маршруты Internet), и также у них есть RT 64500:11 на экспорт, но только у VRF Internet есть такой RT 64500:11 на импорт — только VRF Internet будет получать маршруты клиентов. Друг с другом они обмениваться не смогут. Главное, чтобы Internet не занялся филантропией и не начал маршрутизировать клиентский трафик. Итак, в результате наших операций мы можем видеть следующее: На TARS_2 всё в порядке
На Linkmeup_R1 есть маршрут до сети 100.0.0.0/30, но есть и лишние маршруты до частных сетей: И в этом случае у нас даже будет приятная связность: Но что делать с этими лишними маршрутами в VRF Internet? Ведь если мы подключим ещё один VRF также, у нас и от него появятся ненужные серые подсети
Тут как обычно поможет фильтрация. А если конкретно, то воспользуемся prefix-list + route-map:

Linkmeup_R1(config)#ip prefix-list 1 deny 172.16.0.0/12 le 32
Linkmeup_R1(config)#ip prefix-list 1 deny 192.168.0.0/16 le 32
Linkmeup_R1(config)#ip prefix-list 1 deny 10.0.0.0/8 le 32
Linkmeup_R1(config)#ip prefix-list 1 permit 0.0.0.0/0 le 32

Первые три строки запрещают анонсы всех частных сетей. Четвёртая разрешает все остальные.
В нашем случае вполне можно было бы обойтись одной строкой: ip prefix-list 1 permit 100.0.0.0/23 le 32 — вся подсеть Linkmeup, но приведённый нами пример более универсальный — он допускает существование других публичных сетей и соответственно один prefix-list может быть применён для всех VRF.
Следующая конструкция применяет расширенное community к тем префиксам, что попали в prefix-list 1, иными словами устанавливает RT:

!!!!
Linkmeup_R1(config-map)#route-map To_Internet permit 10
Linkmeup_R1(config-map)#match ip address prefix-list 1
Linkmeup_R1(config-map)#set extcommunity rt 64500:11

Осталось дело за малым — применить route-map к VRF:

Linkmeup_R1(config)#ip vrf TARS
Linkmeup_R1(config-vrf)#export map To_Internet

После обновления маршрутов BGP (можно форсировать командой clear ip bgp all 64500) видим, что в VRF Internet остался только публичный маршрут: И, собственно, проверка доступности Интернета с PC1 (NAT уже настроен на TARS_2): Полная конфигурация всех узлов для Common Services.
Наиболее доступно тема Common Services описана Jeremy Stretch. Ноу него нет указания на то, что префиксы нужно фильтровать.
Вообще, у них там в ихних америках, все друг друга знают и уважают. Поэтому Джереми охотно ссылается на наше всё Ивана Пепельняка, а точнее его заметку о Common Services, а Инва в свою очередь на Джереми. Статьи их дополняют друг друга, но опять же до конца тему не раскрывают.
А вот и третья ссылка, которая в купе с первыми двумя позволяет сложить какое-то представление о том, как работает Common Services.
Все виды доступа в Интернет из VRF описаны в данной статье. Но она настолько запутанная, что именно поэтому я и решил посвятить такой большой кусок статьи настройке этого функционала.

ВиО

Замечательная глава Вопросы и Ответы. Мне очень нравится, потому что сюда можно засунуть всё, чему не хватило места в основной статье.
В1: Можно ли говорить, что P — это Intermediate LSR, а PE — это LER?

Строго говоря, нет. Как минимум, потому что понятия LER, LSR — это базовый MPLS и касаются LSP, а P, PE, CE — только в VPN.
Хотя, конечно, обычно тот узел, к которому подключен клиент, выполняет и роль Ingress/Egress LSR в MPLS и роль PE в VPN.

В2: Почему MBGP — это MultiProtocol BGP, а не, например, MPLS BGP? Что в нём многопротокольного?

Задача BGP — передавать маршруты. Исторически и классически — это IPv4. Но помимо обычных префиксов BGP может передавать и массу других: IPv6, IPX, Multicast, VPN. Каждый тип префиксов настраивается как отдельный Address Family — то есть группа адресов одного типа. Собственно вот за эту возможность передавать маршрутные данные разных протоколов такой BGP и получил имя MBGP.

В3: Где передаются сами маршруты, RD и их атрибуты в MBGP?

RD является частью VPNv4-маршрута и вместе с ним передаётся в секции NLRI — Network Layer Reachability Information.
RT передаётся в секции Extended Community, поскольку им и является по своей сути.

В4: Так в чём всё-таки разница между RD и RT? Почему недостаточно только одного из них? И я правильно понял: RD не является идентификатором VPN, как и RT?

Да, ни RD, ни RT однозначно не идентифицируют VPN. Как для одного VPN на разных маршрутизаторах могут быть настроены разные RD/RT, так и для двух разных теоретически могут быть одинаковые RD/RT.
Ещё раз:
RD — Route Distinguisher — его основная и единственная задача — сделать так, чтобы маршруты не смешались в MBGP — два одинаковых маршрута из разных VPN должны быть таки двумя разными маршрутами. RD не говорит PE, куда нужно экспортировать маршрут и существует/работает только при передаче маршрута.
RT — Route Target. Он не помогает разделить маршруты разных VPN, но он позволяет экспортировать их в те VRF, в которые надо. То есть он имеет значение в момент импорта маршрута из VRF в самом начале и в момент экспорта в VRF на другом конце в самом конце. Передаётся в Extended Community.
Одного RD не хватит, потому что PE не будут знать, как правильно распорядиться маршрутами.
А одного RT не хватит, потому что маршруты смешаются при передаче и потеряются все, кроме одного.
Можно было бы оставить только RD, например, и на его основе решать, куда маршрут передать, но это и не гибко и идёт в разрез с принципами BGP.

В5: Если я не планирую подключать клиентов, то я зря прочитал это гигантскую статью, да? Иными словами, есть ли у MPLS L3VPN другие применения?

Вовсе не зря. Как минимум ещё одно применение — это разделение своих собственных услуг в пределах своей же сети.
Например, если вы оператор сотовой связи и предоставляете услуги в сетях 2G, 3G, 4G и строите уже вовсю 5G, то свою сеть Mobile Backhole (MBH!!!) вы можете разбить на 5 VPN: по одной для каждого поколения радиосвязи и одну для сети управления элементами. Это позволит к каждой сети применять свои правила маршрутизации, качества обслуживания, политики обработки трафика. А если совместить это ещё и с Traffic Engineering…
Причём тут даже не надо будет настраивать взаимосвязь между VPN в пределах MBH — каждая сеть изолирована от абонента до Core Network: у 2G в ядре стоит BSC, у 3G — RNC, у 4G — MME. И только в ядре сети на специальном маршрутизаторе или файрволе можно их скрестить.
А вот ещё пример: столь популярная ныне технология MVNO — Mobile Virtual Network Operator — когда одна сеть MBH используется для двух и более операторов. Здесь уже однозначно нужно будет разделять и властвовать.
Но как ни крути, да, MPLS VPN — это всё-таки преимущественно игрушка больших воротил.

В6: Не возьму в толк: как Egress PE, получив пакет с одной меткой, то есть если произошёл PHP, определяет что эта метка VPN, а не транспортная, и, соответственно, что по метке нужно передать его в VRF, а не скоммутировать куда-то дальше?

Всё очень просто — пространство меток для VPN, для LSP, для всевозможных FRR и CSC — общее. Не может быть такого, что для VPN и для LSP была выделена одна и та же метка. Ну а каждой метке при её создании ставится в соответствие её роль и действия при её получении.


В7: Молодой, человек, мы крупный оператор, мы занимаемся серьёзными вещами — строим Adnvanced LTE, пока поддерживаем 2G, у нас нет клиентов, которые хотят VPN, ваша статья бесполезна для нас.

Конечно же, нет. Операторы пользуются этим везде и всюду. Именно у них зачастую рождаются самые замысловатые схемы.
Идея в том, что операторы, стремясь создать конвергентную сеть, разносят разные типы трафика в разные VPN.
Так, например, в один VPN помещается пользовательский трафик 3G-пользователей, в другой — сеть управления базовыми станциями.
В третий VPN выносится сервис LTE, а с помощью L2VPN передаётся TDM-трафик 2G БС. Учитывая, что у них разное оборудование в ядре оператора, этим потокам не нужно нигде пересекаться и они прекрасно живут каждый в своём домике.

Полезные ссылки

Горячо мной любимый Джеф Дойл: VPN в двух частях: Part I, Part II.
Мне почему-то тяжеловато читать примеры конфигурации cisco, но лучше них эту тему пока никто не раскрыл: NAT — Integration with MPLS VPN.
О различиях RD и RT пишет Jeremy Stretch: Route Distinguishers and Route Targets.
Ещё раз приведу все ссылки на информацию о доступе в Интернет из VRF:
Все способы организации: Providing Internet Access for MPLS L3 VPNs.
Тот же Jeremy Stretch. MPLS VPN with Common Services.
Иван Пепельняк. MPLS VPN Common Services Design


Как вы могли заметить, создание L3VPN — это большое количество ручной работы. И в случае необходимости организовать взаимодействие между VPN, придётся настроить не только один Интернет-шлюз даже в самом правильном и красивом способе, но и клиентские PE.
Но вся эта работа необходима, здесь нет избыточности. Для контраста вспомните, во что бы вам встала настройка, VPN с помощью GRE или VRF-Lite.
И обратите внимание, маршрутизатор P — Linkmeup_R2 — оставался абсолютно неизменным в течение всех стадий настройки с момента первоначального включения на нём MPLS. Это ли не прелестно?!
Нельзя сказать, что этой небольшой статьёй мы объяли весь L3VPN, в частности остались за пределами общей картины такие интереснейшие вещи, как Inter-AS VPN, коих 3 вида, и CSC (Carrier Support Carrier). Но я надеюсь конкретно по этим двум механизмам написать отдельную статью.
L3VPN — вещь зрелая, продуманная и стандартизированная. У всех производителей она работает плюс/минус одинаково.

А вот впереди ещё статья про L2VPN, которая включит в себя AToM, VLL, PWE3 и VPLS. В ней узнаем, какую роль сыграли Cisco и Juniper в развитии этого направления, какие радости в нашу жизнь привносят такие услуги, как CES или EoMPLS. Наберитесь терпения — в этом году я постараюсь увеличить темпы, набрать обороты, раскрутиться и увеличить КПД.

like 223 views 2060 message 0

0 коментариев

Ещё статьи

Ответ к задаче №МВ3.5
В этой задаче проблема в том, что при агрегировании префиксов, префикс анонсируется из AS 64503, как ее локальный. И исчезли AS, которые были в префиксах, объединенных в один суммарный. Для ...
like 0 5131 4
19 октября 2013
Анонс подкаста. Выпуск 59 \\\\\Состоялся.
Внезапно мы осознали, что в подкасте для связистов не было темы про WDM. Ни разу за 5 лет. Упущение стремимся исправить, и в январский выпуск Антон Клочков ангажировал к нам ...
like 0 3216 0
15 января 2018
Сети для самых маленьких. Часть первая (которая после нулевой). Подключение к оборудованию ...
Все выпуски12. Сети для самых маленьких. Часть двенадцатая. MPLS L2VPN 11.1. Сети для самых маленьких. Микровыпуск №6. MPLS L3VPN и доступ в Интернет 11. Сети для самых маленьких. Часть одиннадцатая. ...
like 16 2536 61
30 октября 2012