L3VPN, который мы рассмотрели в прошлом выпуске, покрывает собой огромное количество сценариев, необходимых большинству заказчиков. Огромное, но не все. Он позволяет осуществлять связь только на сетевом уровне и только для одного протокола - IP. Как быть с данными телеметрии, например, или трафиком от базовых станций, работающих через интерфейс E1? Существуют также сервисы, которые используют Ethernet, но тоже требуют связи на канальном уровне. Опять же ЦОДы между собой любят на языке L2 общаться.
Вот и нашим клиентам вынь да положь L2.
Традиционно раньше всё было просто: L2TP, PPTP да и всё по большому счёту. Ну в GRE ещё можно было спрятать Ethernet. Для всего прочего строили отдельные сети, вели выделенные линии ценою в танк (ежемесячно). Однако в наш век конвергентных сетей, распределённых ЦОДов и международных компаний это не выход, и на рынок выплеснулось некоторое количество масштабируемых технологий випиэнирования на канальном уровне.
Мы же в этот раз сосредоточимся на MPLS L2VPN.
Прежде чем погрузиться в тёплый MPLS, взглянем на то, какие вообще виды L2VPN существуют.
Почему он победитель? Главная причина, безусловно, в способности маршрутизаторов, передающих MPLS-пакеты абстрагироваться от их содержимого, но при этом различать трафик разных сервисов.
Например, Е1-кадр приходит на PE, сразу же инкапсулируется в MPLS и уже никто по пути даже не заподозрит, что там внутри - важно только вовремя поменять метку.
А на другой порт приходит Ethernet-кадр и по тому же самому LSP он может пройти по сети, только с другой меткой VPN.
А кроме того MPLS TE позволяет строить каналы с учётом требований трафика к параметрам сети.
В связке же с LDP и BGP становится более просто настраивать VPN и автоматически находить соседей.
Возможность инкапсулировать трафик любого канального уровня в MPLS называется AToM - Any Transport over MPLS.
Вот список поддерживаемых AToM протоколов:
Для построения любого L2VPN существуют два концептуально разных подхода.
Традиционно термины будут вводиться по мере необходимости. Но о некоторых сразу.
PE - Provider Edge - граничные маршрутизаторы MPLS-сети провайдера, к которым подключаются клиентские устройства (CE).
CE - Customer Edge - оборудование клиента, непосредственно подключающееся к маршрутизаторам провайдера (PE).
AC - Attached Circuit - интерфейс на PE для подключения клиента.
VC - Virtual Circuit - виртуальное однонаправленное соединение через общую сеть, имитирующее оригинальную среду для клиента. Соединяет между собой AC-интерфейсы разных PE. Вместе они составляют цельный канал: AC→VC→AC.
PW - PseudoWire - виртуальный двунаправленный канал передачи данных между двумя PE - состоит из пары однонаправленных VC. В этом и есть отличие PW от VC.
VPWS - Virtual Private Wire Service.
В основе любого решения MPLS L2VPN лежит идея PW - PseudoWire - виртуальный кабель, прокинутый из одного конца сети в другой. Но для VPWS сам этот PW и является уже сервисом.
Эдакий L2-туннель, по которому можно беззаботно передавать всё, что угодно.
Ну, например, у клиента в Котельниках находится 2G-базовая станция, а контроллер - в Митино. И эта БС может подключаться только по Е1. В стародавние времена пришлось бы протянуть этот Е1 с помощью кабеля, радиорелеек и всяких конвертеров.
Сегодня же одна общая MPLS-сеть может использоваться, как для этого Е1, так и для L3VPN, Интернета, телефонии, телевидения итд.
(Кто-то скажет, что вместо MPLS для PW можно использовать L2TPv3, но кому он нужен с его масштабируемостью и отсутствием Traffic Engineering"а?)
VPWS сравнительно прост, как в части передачи трафика, так и работы служебных протоколов.
Туннельная метка - то же, что и транспортная, просто длинное слово "транспортное" не помещалось в заголовок.
0. Между R1 и R6 уже построен транспортный LSP с помощью протокола LDP или RSVP TE. То есть R1 известна транспортная метка и выходной интерфейс к R6.
1. R1 получает от клиента CE1 некий L2 кадр на AC интерфейс (то может оказаться Ethernet, TDM, ATM итд. - не имеет значения).
2. Этот интерфейс привязан к определённому идентификатору клиента - VC ID - в некотором смысле аналогу VRF в L3VPN. R1 даёт кадру сервисную метку, которая сохранится до конца пути неизменной. VPN-метка является внутренней в стеке.
3. R1 знает точку назначения - IP-адрес удалённого PE-маршрутизатора - R6, выясняет транспортную метку и вставляет её в стек меток MPLS. Это будет внешняя - транспортная метка.
4. Пакет MPLS путешествует по сети оператора через P-маршрутизаторы. Транспортная метка меняется на новую на каждом узле, сервисная остаётся без изменений.
5. На предпоследнем маршрутизаторе снимается транспортная метка - происходит PHP. На R6 пакет приходит с одной сервисной VPN-меткой.
6. PE2, получив пакет, анализирует сервисную метку и определяет, в какой интерфейс нужно передать распакованный кадр.
Если вы читали предыдущий выпуск про L3VPN, то в вопросе передачи пользовательского трафика не увидите ничего нового - пара MPLS-меток и передача по транспортному LSP. Ingress PE проверяет какие метки поставить и в какой интерфейс отправить, P меняет транспортную метку, а Egress PE по метке VPN принимает решение, в какой AC-интерфейс передать полученный кадр.
Транспортная метка может назначаться как LDP (см. выпуск про MPLS), так и RSVP-TE (ещё ждёт своего часа).
Для примера, возьмём LDP - по всей сети запускается этот протокол, который для каждого Loopback-адреса каждого MPLS-маршрутизатора распространит по сети метки.
В нашем случае R1 после работы LDP будет, грубо говоря, знать 5 меток: как добраться до каждого из оставшихся маршрутизаторов.
Нас интересует LSP R1→R6 и обратно. Заметьте, что для того, чтобы VC перешёл в состояние UP, должны быть оба LSP - прямой и обратный.
Существует несколько разных способов реализации услуги VPWS. Об этом мы поговорим чуть ниже, а для примера разберём ту, которая наиболее часто сейчас используется.
За распространение сервисных меток отвечает тот же LDP, только генно-модифицированный - Targeted LDP. Теперь он может устанавливать соединение с удалёнными маршрутизаторами и обмениваться с ними метками.
В нашем примере к R1 и R6 подключены клиенты. R1 через LDP сообщит свою метку для этого клиента R6 и наоборот.
На обоих концах вручную мы настраиваем удалённую LDP-сессию. Она никак не привязана к VPN. То есть одна и та же сессия может использоваться для обмена метками любым количеством VPN.
Обычный LDP - это link-local протокол и ищет соседей среди непосредственно подключенных маршрутизаторов, то есть TTL его пакетов - 1. Однако tLDP достаточна IP-связность.
Как только с обеих сторон появятся AC-интерфейсы с одинаковым VC-ID, LDP поможет им сообщить друг другу метки.
В чём отличия tLDP от LDP?
| LDP | tTLDP |
| Соседями могут быть только непосредственно подключенные маршрутизаторы | Соседом может быть любой маршрутизатор в сети, с которым есть IP-связность. |
| Поиск всех возможных соседей | Соседи уже определены конфигурацией |
| Широковещательная рассылка сообщений Discovery | Адресная отправка сообщения Discovery конкретным соседям. |
| В качестве FEC обычно выступает IP-адрес | В качестве FEC обычно выступает VC ID |
Чтобы сильно далеко не убегать, сразу же практика.
Как собрать лабу для MPLS L2VPN?
В качестве тестового стенда использована связка UnetLab + CSR1000V. И то и другое вы можете получить совершенно бесплатно и законно.
UnetLab OVA.
Cisco CSR1000V IOS-XE.
Инструкции по установке UNL и добавлению образов CSR1000V: Тыц.
Соответственно далее все команды по настройке MPLS L2VPN даны в нотации Cisco IOS-XE.
Внимание: для каждой ноды CSR1000V требуется 2,5 ГБ RAM. В противном случае образ либо не запустится, либо будут различные проблемы, вроде того, что порты не поднимаются или наблюдаются потери.
Упростим топологию до четырёх магистральных узлов. По клику можете открыть её в новой вкладке, чтобы смотреть на неё Alt+Tab"ом, а не ворочать страницу вверх-вниз.
Наша задача - прокинуть Ethernet от Linkmeup_R1 (порт Gi3) до Linkmeup_R4 (порт Gi3).
На шаге 0 IP-адресация, IGP-маршрутизация и базовый MPLS уже настроены (см. как).
Файл начальной конфигурации.
Linkmeup_R1(config)#interface Gi 3
Linkmeup_R1(config-if)#xconnect 4.4.4.4 127 encapsulation mplsLinkmeup_R4(config)#interface Gi 3
Linkmeup_R4(config-if)#xconnect 1.1.1.1 127 encapsulation mpls
На этом конфигурация VPWS закончена.
Файл конфигурации VPWS.
Давайте проследим, что там происходило за кулисами протоколов (дамп снят с интерфейса GE1 Linkmeup_R1). Можно выделить основные вехи:
0) IGP сошёлся, LDP определил соседей, поднял сессию и раздал транспортные метки.
Как видите, Linkmeup_R4 выделил транспортную метку 19 для FEC 4.4.4.4.
1) А вот tLDP начал свою работу.
--А. Сначала мы настроили его на Linkmeup_R1 и tLDP начал периодически отправлять свой Hello на адрес 4.4.4.4
Как видите, это юникастовый IP пакет, который отправляется с адреса Loopback-интерфейса 1.1.1.1 на адрес такого же Loopback удалённого PE - 4.4.4.4.
Упакован в UDP и передаётся с одной меткой MPLS - транспортной - 19. Обратите внимание на приоритет - поле EXP - 6 - один из наивысших, поскольку это пакет служебного протокола. Подробнее мы об этом поговорим в выпуске о QoS.
Состояние PW пока в DOWN, потому что с обратной стороны ничего нет.
--Б. После того, как настроили xconnect на стороне Linkmeup_R4 - сразу Hello и установление соединения по TCP.
В этот момент установлено LDP-соседство
--В. Пошёл обмен метками:
В самом низу можно видеть, что FEC в случае VPWS - это VC ID, который мы указали в команде xconnect - это идентификатор нашего VPN - 127.
А чуть ниже выделенная ему Linkmeup_R4 метка - 0х16 или 22 в десятичной системе.
То есть этим сообщением Linkmeup_R4 сообщил Linkmeup_R1, мол, если ты хочешь передать кадр в VPN с VCID 127, то используй сервисную метку 22.
Тут же вы можете видеть ещё кучу других сообщений Label Mapping - это LDP делится всем, что нажил - информацией про все FEC. Нас это мало интересует, ну а Lilnkmeup_R1 и подавно.
То же самое делает и Linkmeup_R1 - сообщает Linkmeup_R4 свою метку:
После этого поднимаются VC и мы можем увидеть метки и текущие статусы:
Команды show mpls l2transport vc detail и show l2vpn atom vc detail в целом идентичны для наших примеров.
2) Далее соседи будут только поддерживать контакт:
3) Теперь всё готово для передачи пользовательских данных. В этот момент мы запускаем ping. Всё предсказуемо просто: две метки, которые мы уже видели выше.
Почему-то Wireshark не разобрал внутренности MPLS, но я вам покажу, как прочитать вложение:
Два блока, выделенных, красным - это MAC-адреса. DMAC и SMAC соответственно. Жёлтый блок 0800 - поле Ethertype заголовка Ethernet - значит внутри IP.
Далее чёрный блок 01 - поле Protocol заголовка IP - это номер протокола ICMP. И два зелёных блока - SIP и DIP соответственно.
Теперь вы можете в Wireshark!
Соответственно ICMP-Reply возвращается только с меткой VPN, потому что на Linkmeup_R2 возымел место PHP и транспортная метка была снята.
Если VPWS - это просто провод, то он должен спокойно передать и кадр с меткой VLAN?
Да, и нам для этого не придётся ничего перенастраивать.
Вот пример кадра с меткой VLAN:
Здесь вы видите Ethertype 8100 - 802.1q и метку VLAN 0x3F, или 63 в десятичной системе.
Если мы перенесём конфигурацию xconnect на сабинтерфейс с указанием VLAN, то он будет терминировать данный VLAN и отправлять в PW кадр без заголовка 802.1q.
Рассмотренный пример - это EoMPLS (Ethernet over MPLS). Он является частью технологии PWE3, которая суть развитие VLL Martini Mode. И всё это вместе и есть VPWS. Тут главное не запутаться в определениях. Позвольте мне быть вашим проводником.
Итак, VPWS - общее название решений для L2VPN вида точка-точка.
PW - это виртуальный L2-канал, который лежит в основе любой технологии L2VPN и служит туннелем для передачи данных.
VLL (Virtual Leased Line) - это уже технология, которая позволяет инкапсулировать кадры различных протоколов канального уровня в MPLS и передавать их через сеть провайдера.
Выделяют следующие виды VLL:
VLL CCC - Circuit Cross Connect. В этом случает нет метки VPN, а транспортные назначаются вручную (статический LSP) на каждом узле, включая правила swap. То есть в стеке будет всегда только одна метка, а каждый такой LSP может нести трафик только одного VC. Ни разу не встречал его в жизни. Главное его достоинство - он может обеспечить связность двух узлов, подключенных к одному PE.
VLL TCC - Translational Cross Connect. То же, что CCC, но позволяет с разных концов использовать разные протоколы канального уровня.
Работает это только с IPv4. PE при получении удаляет заголовок канального уровня, а при передаче в AC-интерфейс вставляет новый.
Интересно? Начните отсюда.
VLL SVC - Static Virtual Circuit. Транспортный LSP строится обычными механизмами (LDP или RSVP-TE), а сервисная метка VPN назначается вручную. tLDP в этом случае не нужен. Не может обеспечить локальную связность (если два узла подключены к одному PE).
Martini VLL - это примерно то, с чем мы имели дело выше. Транспортный LSP строится обычным образом, метки VPN распределяются tLDP. Красота! Не поддерживает локальную связность.
Kompella VLL - Транспортный LSP обычным образом, для распределения меток VPN - BGP (как и полагается, с RD/RT). Уау! Поддерживает локальную связность. Ну и ладно.
PWE3 - Pseudo Wire Emulation Edge to Edge. Строго говоря, область применения этой технология шире, чем только MPLS. Однако в современном мире в 100% случаев они работают в связке. Поэтому PWE3 можно рассматривать как аналог Martini VLL с расширенным функционалом - сигнализацией так же занимаются LDP+tLDP.
Коротко его отличия от Martini VLL можно представить так:
Сейчас PWE3 - стандарт де факто и именно он был в примере выше.
Я тут везде говорю об Ethernet для того, чтобы показать наиболее наглядный пример. Всё, что касается других канальных протоколов, это, пожалуйста, на самостоятельное изучение.
Продолжение читайте на сайте linkmeup.
