Вообще, существуют следующие виды L2VPN:
Возможность инкапсулировать трафик любого канального уровня в MPLS называется AToM — Any Transport over MPLS.
Вот список поддерживаемых AToM протоколов:
- ATM Adaptation Layer Type-5 (AAL5) over MPLS
- ATM Cell Relay over MPLS
- Ethernet over MPLS
- Frame Relay over MPLS
- PPP over MPLS
- High-Level Data Link Control (HDLC) over MPLS
Для построения любого 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, так и 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?
Упростим топологию до четырёх магистральных узлов.
Наша задача — прокинуть 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 mpls Linkmeup_R4(config)#interface Gi 3 Linkmeup_R4(config-if)#xconnect 1.1.1.1 127 encapsulation mpls
Команда xconect **4.4.4.4 127 encapsulation mpls** заставляет LDP поднять удалённую сессию с узлом 4.4.4.4 и создаёт MPLS PW с VC ID 127. Важно, чтобы VC ID совпадали на двух противоположных AC-интерфейсах — это указатель того, что их нужно срастить.
Как результат:
Добавить комментарий