Про виртуальные сети (часть 19). L2VPN + VRF

Всем привет. Сегодня мы будем рассматривать такого зверя, как L2VPN. Что он из себя представляет? С точки зрения клиента – это просто Ethernet канал между двумя его маршрутизаторами, один широковещательный домен. А вот с точки зрения провайдера, все намного сложнее. Нужно поймать кадр Ethernet (ну или что там используется на канальном уровне), запаковать, передать через всю сеть, снова распаковать и отдать клиенту. Вот настройкой этой цепочки мы и займемся. Заодно проверим, что можно сделать, если взаимодействие провайдера с клиентом уже осуществляется и организовано с помощью VRF.

Представим, что у провайдера есть клиент, которому уже предоставляется пропускная способность сети для объединения подсетей клиента, подключенных так, как показано на рисунке 1 и рисунке 2.

Phyzik_L2VPN

Рисунок 1 – Физическая топология сети

L2VPN_Logic

Рисунок 2 – логическая топология.

И тут этому клиенту, кроме объединения сетей по L3 вдруг очень понадобилось (понятия не имею зачем) объединить сети еще и по L2, причем сам он это делать не захотел. А нам-то что, чем больше услуг оказали, тем больше денег заработали.

В общем виде настройка производится в следующем порядке:
— создаем loopback интерфейс, он будет отправной и приемной точкой нашего L2-туннеля;
— создаем настройку псевдокабеля (pseudowire), в котором и будут определяться основные параметры L2-туннеля, такие как локальный отправной интерфейс, протокол инкапсуляции, тип инкапсуляции, тип обслуживания и пр.;
— ну и, собственно, включить L2-туннель на интерфейсе, на котором мы будем отлавливать Ethernet кадры клиента, указав при этом псевдокабель, номер соединения и другую сторону туннеля.

Итак, поехали. Настройка на обоих СЕ маршрутизаторах абсолютно одинакова, поэтому привожу только сторону Zapad.

Создаем, прежде всего, необходимые интерфейсы.

D_Zapad#conf t
D_Zapad(config)#interface FastEthernet0/0.20
D_Zapad(config-subif)#encapsulation dot1Q 20
D_Zapad(config-subif)#ip address 10.1.20.2 255.255.255.252

 

Zapad#conf t
Zapad(config)#interface Ethernet1/0.20
Zapad(config-subif)#encapsulation dot1Q 20
Zapad(config-subif)#vrf forwarding Zapad
Zapad(config-subif)#interface Loopback0
Zapad(config-if)#vrf forwarding Zapad
Zapad(config-if)#ip address 10.0.0.1 255.255.255.255

 

Теперь создаем класс псевдокабеля:

Zapad(config)#pseudowire-class PW_CLASS
Zapad(config-pw-class)#encapsulation l2tpv3
Zapad(config-pw-class)#ip local interface Loopback0

 

Тут, в принципе, все понятно. И, наконец, последняя команда.

Zapad(config)#interface Ethernet1/0.20
Zapad(config-subif)#xconnect 192.168.0.3 1 pw-class PW_CLASS

 

И тут же получаем:

Incompatible with ip vrf command on Et1/0.20 — command rejected.

Вот те раз. Все так красиво было: отдельный vrf для клиента, с его туннелем и т.д.

Вообще говоря, команду xconnect интерфейс не примет, если на нем сконфигурировано что-то относящееся к уровню маршрутизиции: vrf или ip-адрес. И в этом есть своя логика. Любые виртуальные сети предназначены для того, чтобы выделить ресурсы одной сети для использования другой сетью, но при этом, чтобы логически эти сети не пересекались между собой и пользователи одной сети не могли получить доступ к ресурсам другой сети. И L2VPN  в виде настройки псевдокабеля, и L3VPN в виде настройки VRF и туннеля предназначены для решения этой задачи. И если попытаться объединить эти две технологии, получится масло масляное. Выгоды особо никакой, а вот накладные расходы на служебную информацию (передача, которой собственно тоже денег стоит) вырастают очень значительно. Видимо именно этими соображениями и руководствовались инженеры cisco, когда создавали запрет на одновременное конфигурирование L2  и L3 VPN на одном интерфейсе. А для нашей задачи остается только одно решение – создавать отдельное соединение.   Конфиг будет выглядеть так:

l2tp-class L2TP_CLASS
password 123456
!
pseudowire-class PW_CLASS
encapsulation l2tpv3
protocol l2tpv3 L2TP_CLASS
ip local interface Loopback1
!
interface Ethernet1/0.20
encapsulation dot1Q 20
xconnect 192.168.0.3 1 pw-class PW_CLASS

 Вот как-то так. На маршрутизаторе Vostok все то же самое, ну кроме ip-адреса, конечно. Прежде чем проверять соединение, после команды xconnect обязательно exit. До этого туннель не запустится. Еще один момент – это указание локального интерфейса. IP-адрес интерфейса обязательно должен быть указан с маской 32 бита, и сам интерфейс не должен принадлежать ни к одному vrf.

Давайте посмотрим, что у нас получилось. Сначала можно проверить, как там сами туннели поживают.

Zapad#sh l2tun
L2TP Tunnel and Session Information Total tunnels 1 sessions 1
LocTunID   RemTunID   Remote Name   State  Remote Address  Sessn L2TP Class/Count VPDN Group
1457022073 209659929  Vostok        est    192.168.0.3     1     L2TP_CLASS
LocID      RemID      TunID      Username, Intf/      State  Last Chg Uniq ID      Vcid, Circuit
2714503706 1723889736 1457022073 1, Et1/0.20:20       est    00:02:34 1

 

Что мы тут видим? У нас есть туннель в состоянии established с удаленным хостом 192.168.0.3, установленный через интерфейс Et1/0.20, ну и прочая служебная информация.

В исходном конфиге была настроена динамическая маршрутизация, поэтому грех не проверить таблицы маршрутизации у клиента (мы ж для него стараемся):

D_Zapad#sh ip route
10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
O        10.0.0.1/32 [110/2] via 10.1.10.1, 00:00:38, FastEthernet0/0.10
O        10.0.0.2/32 [110/3] via 10.1.20.1, 00:00:17, FastEthernet0/0.20
C        10.1.10.0/30 is directly connected, FastEthernet0/0.10
L        10.1.10.2/32 is directly connected, FastEthernet0/0.10
C        10.1.20.0/30 is directly connected, FastEthernet0/0.20
L        10.1.20.2/32 is directly connected, FastEthernet0/0.20
O        10.2.10.0/30 [110/2] via 10.1.20.1, 00:00:17, FastEthernet0/0.20
172.16.0.0/30 is subnetted, 1 subnets
O        172.16.0.0 [110/1001] via 10.1.10.1, 00:00:17, FastEthernet0/0.10
192.168.10.0/32 is subnetted, 1 subnets
C        192.168.10.1 is directly connected, Loopback0
192.168.20.0/32 is subnetted, 1 subnets
O        192.168.20.1 [110/2] via 10.1.20.1, 00:00:17, FastEthernet0/0.20

И мы видим, что путь ко всем подсетям на другой стороне лежит через интерфейс FastEthernet0/0.20, и это логично, поскольку с точки зрения маршрутизатора клиента, они теперь соединены непосредственно. Он совершенно не в курсе, что между ними там еще целая сеть провайдера пыхтит.

Если заглянуть еще и в саму сеть с помощью WireShark, например, то увидим там вот такие, ничем не примечательные пакеты:

L2TP_frame

Видно, конечно, что это L2 туннель, но что там внутри, сразу не очевидно. На самом деле все проще, чем кажется. Несмотря на то, что WireShark после L2TP показывает еще какие-то инкапсуляции, их нет. Все, что после заголовка L2TP — это тот самый Ethernet кадр, который мы перехватили на интерфейсе Et1/0.20 маршрутизатора Zapad. Внутри него свои протоколы и данные, но совсем не те, что пытается показать WireShark.

Несколько по-иному обстоит дело с mpls. Чтобы его использовать, нужно создать новый pseudowire-class и указать тип инкапсуляции encapsulation mpls(нельзя в уже существующем классе поменять тип инкапсуляции), перезадать xconnect с новым классом и вместо L2TP пакетов побегут пакеты MPLS. Их WireShark распознает более правильно:

MPLS_frame

Тут все четко. Видно и туннельный кадр, и инкапсулированные данные.

Ну вот и все. Вот такой зверь этот L2VPN.

Аверьянов Кирилл
network-lab.ru

Как всегда, полные конфиги: D_Zapad, Zapad, Sever, Yug, Vostok, D_Vostok


Комментарии:

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Hide me
Получать регулярно свежие материалы, лабораторные и вебинары
Email Имя
Show me