VPLS — Virtual Private LAN Service. По своей сути — это коммутатор. Провайдер подключает несколько точек заказчика к своей сети в разных её концах и обеспечивает L2 связность. И теперь это задача транспортной сети провайдера — заботиться о правильной коммутации кадров, то есть изучении MAC-адресов.

Терминология

VPLS-домен — изолированная виртуальная L2-сеть, то есть, грубо говоря, один отдельный L2VPN. Два разных клиента — два разных VPLS-домена.

VSI — Virtual Switching Instance. Виртуальный коммутатор в пределах одного узла.
Для каждого клиента (или сервиса) он свой. То есть трафик разных VSI не может кочевать из одного в другой.
В терминах Cisco это VFI — Virtual Forwarding Instance.
Можно считать, что VPLS-домен, VSI и VFI синонимы

VE — VPLS Edge — узел PE, участник VPLS-домена.

Data Plane

В общих чертах передача пользовательского трафика выглядит, как и для случая VPWS, но добавляется шаг изучения MAC'ов и проверки MAC-таблицы при передаче трафика.

1. На AC-порт PE-маршрутизатора пришёл пользовательский кадр.
2. PE-маршрутизатор смотрит в заголовок Ethernet и проверяет MAC-адрес отправителя.
   А) Если он уже есть в таблице MAC-ов данного VSI, PE сразу переходит к шагу 3.
   Б) Если этого адреса ещё нет — он записывает соответствие MAC-порт в таблицу и тоже переходит к шагу 3.
3. PE-маршрутизатор смотрит в заголовок Ethernet и проверяет MAC-адрес получателя.
   А) если таковой присутствует в таблице MAC-адресов данного VSI:
   1. PE ищет выходной интерфейс для кадра с данным MAC'ом. Это может быть физический интерфейс или PW.
   2. Если порт назначения — физический интерфейс — просто отправляет в этот порт.
   Если это PW, то добавляет соответствующую метку — сервисную. Эта метка будет неизменна до конца пути.
   3. PW — это всегда канал между двумя IP-узлами, поэтому зная IP-адрес удалённого PE, локальный PE из таблицы меток извлекает транспортную и ставит её сверху стека — она будет меняться на каждом P-маршрутизаторе.

   Б) Если же MAC-адрес неизвестен, то как порядочный коммутатор наш PE должен выполнить широковещательную рассылку кадра по всем PE данного VSI.

4. Локальный PE составляет список всех удалённых PE этого VSI, и, создав копии этого кадра, вставляет в них сервисные метки — каждому своя.
5. Далее на каждую копию кадра навешивается ещё и транспортная метка (тоже своя для каждого PE).
6. Весь этот ворох кадров рассылается по сети провайдера.
7. Также копии широковещательного кадра отправляются в AC-интерфейсы, если такие есть, без заголовков MPLS.
8. Удалённый PE после получения кадра и снятия меток (то есть когда уже определил VSI) тоже действует как обычный коммутатор:
   А) Если MAC-адрес источника пока не известен, вносит его в таблицу. В качестве входного интерфейса будет указан PW к Ingress PE.
   Б) Если MAC-адрес назначения ему известен, отсылает кадр в тот порт, за которым он изучен. Отсылается уже чистый Ethernet-кадр, без каких-либо заголовков MPLS.
   В) Если этот MAC не удалось найти в таблице? Широковещательная рассылка по всем AC-портам этого VSI. Заметьте, PE не будет рассылать этот кадр в PW данного VSI, потому что все другие PE уже получили копию этого кадра от входного PE. Это всё то же правило расщепления горизонта (Split Horizon), и так достигается отсутствие петель коммутации и широковещательных штормов. (Ах, если бы всё было так просто...)

Как и в обычном коммутаторе записи в MAC-таблице VSI периодически протухают и удаляются.
В вопросе изучения MAC-адресов в VPLS есть один нюанс, который резко отличает его от L3VPN.
PE должен не просто знать физический порт, откуда пришёл кадр — важно определить соседа или, точнее PW как виртуальный интерфейс. Дело в том, что клиентский кадр нужно отправить не просто в какой-то физический порт, а именно в правильный PW, иными словами, правильному соседу.
Для этой цели каждому соседу выдаётся личная метка, с которой тот будет отправлять кадр этому PE в данном VPLS-домене.
И в дальнейшем по VPN-метке, заглянув в LFIB, PE узнает, от какого соседа пришёл кадр.
Напомню, что L3VPN без разницы, откуда пришёл IP-пакет, поэтому для префикса в VRF всем соседям сообщается одна и та же метка.

Control Plane

Из работы Data Plane уже видно, что для VPLS требуется полносвязная топология PE для каждого VSI. Причём не все PE MPLS-сети провайдера будут соседями, а только те, где есть этот же VSI.
Поэтому один из главных вопросов в VPLS — обнаружение всех PE, куда подключены клиенты данного VSI.
Существует здесь два подхода: ручная настройка и автоматическое обнаружение. Первый путь изначально предложила Cisco (драфт Мартини), отцом второго является Juniper (драфт Компелла).

Транспортные LSP строятся как обычно LDP или RSVP-TE.

Точно также, независимо от используемого режима, VPLS при более детальном рассмотрении разваливается на point-to-point PW. То есть мы имеем не некое централизованное облако коммутации, а просто набор виртуальных линий между всем соседями. Решение о передаче кадра принимает Ingress PE или, проще говоря, выбирает нужный PW.

На данный момент draft-martini переродился в RFC 4447 — Интернет-стандарт про PWE3, а драфт-Компелла устарел и умер.
Если же говорить именно о VPLS, то тут есть два стандарта:
“Virtual Private LAN Service (VPLS) Using BGP for Auto-discovery and Signaling”. RFC 4761.
“Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling” RFC 4762.

VPLS Martini Mode (targeted LDP)

В начале двухтысячных индустрия усиленно занялась поисками решений для L2VPN в масштабах оператора.
Критерии были следующими:
- Простота внедрения (очевидное требование)
- На существующем железе (протоколы не должны требовать аппаратной доработки)
- Поддержка уже функционирующих протоколов на сетях операторов.
- Принцип работы нового механизма не должна кардинально отличаться от существующих моделей.

Люка Мартини — бывший сотрудник Cisco — на этот необъявленный конкурс предоставил решение на основе LDP.
Работать оно будет поверх MPLS-сети.
Для сигнализации меток будет использоваться LDP, который уже является частью MPLS.
VPLS Martini Mode описан в стандарте RFC4762.

Именно это лаконичное решение и стало стандартом де факто в большинстве сетей по всему миру.
С тем, как работает Martini-mode мы уже познакомились в части про VPWS. Ровно то же самое и здесь, только удалённые LDP сессии создаются для каждого VSI не с одним соседом, а с несколькими.

LDP используется для распределения сервисных меток.
Удалённые сессии с каждым соседом в VPLS-домене настраиваются вручную.
Поскольку заранее известны все участники этого VPLS, каждому из них LDP выделяет индивидуальную метку в сообщении LDP Label Mapping Message.
Если добавляется новый PE в VPLS-домен, необходимо настроить LDP-соседство со всеми существующими PE этого VPLS. После чего с каждым из них новый PE обменятся метками.
В течение всего времени, LDP проверяет доступность своих соседей. Если какой-то из соседей выходит из группы или становится недоступным, сессия разрывается и все изученные MAC'и в PW к этому соседу очищаются.

Если состояние какого-либо из AC-портов VPLS-домена переходит в состояние Down, либо происходит другое событие, заставляющее очистить MAC-адреса с AC-порта, то PE сообщает об этом всем своим соседям, настаивая на удалении MAC-адресов в сообщении LDP MAC Withdraw

Практика

Итак на шаге 0 у нас готовы необходимые транспортные LSP, а соответственно, и маршрутизация итд.

1. Создаём VFI — Virtual Forwarding Instance
   

   Linkmeup_R1(config)#l2vpn vfi context Blue 
   Linkmeup_R1(config-vfi)#vpn id 63
   Linkmeup_R1(config-vfi)#member 3.3.3.3 encapsulation mpls
   Linkmeup_R1(config-vfi)#member 4.4.4.4 encapsulation mpls

   Режим по умолчанию — LDP signaling.
   VPN ID — аналог VCID из предыдущего примера — уникальный идентификатор VPN. Он должен совпадать на всех узлах.
   Следующими двумя командами мы указываем соседей, которые тоже являются членами этого VPLS-домена.
   По сути это указание LDP установить удалённую сессию с ними, после которого он начинает отправлять LDP Hello настроенным соседям.

   Аналогичные команды выполняем на Linkmeup\_R3 и Linkmeup\_R4

   Linkmeup_R3(config)#l2vpn vfi context Blue
   Linkmeup_R3(config-vfi)#vpn id 63
   Linkmeup_R3(config-vfi)#member 1.1.1.1 encapsulation mpls
   Linkmeup_R3(config-vfi)#member 3.3.3.3 encapsulation mpls

   Linkmeup_R4(config)#l2vpn vfi context Blue
   Linkmeup_R4(config-vfi)#vpn id 63
   Linkmeup_R4(config-vfi)#member 1.1.1.1 encapsulation mpls
   Linkmeup_R4(config-vfi)#member 4.4.4.4 encapsulation mpls

2. Создаём Service Instance на AC-интерфейсах
   

   Linkmeup_R1(config)#interface gigabitEthernet 3
   Linkmeup_R1(config-if)#service instance 10 ethernet
   Linkmeup_R1(config-if-srv)#description Blue-A
   Linkmeup_R1(config-if-srv)#encapsulation default

   Linkmeup_R1(config)#interface gigabitEthernet 4
   Linkmeup_R1(config-if)#service instance 12 ethernet
   Linkmeup_R1(config-if-srv)#description Blue-C
   Linkmeup_R1(config-if-srv)#encapsulation default

   В режиме конфигурации интерфейса мы создаём Service Instance — это привязка интерфейса к сервисам.
   Каким именно — настроим позднее. Номер Service Instance произвольный — он локальнозначимый для интерфейса (как и у классического сабинтерфейса).
   **encapsulation _default_** означает, что мы хватаем все кадры без разбора (а могли бы выбирать по метке VLAN или по факту наличия двух меток — QinQ, например), то есть весь физический интерфейс привязываем к VFI.

   Резонный вопрос — зачем какие-то service instance — недостаточно ли просто bridge-domain прописать?
   Мысль верная, но service-instance — это «новый» подход к концепции обработки тегированного трафика и называется он EVC — Ethernet Virtual Circuit.
   Тут мы на минуту переключимся на Ethernet-коммутаторы, чтобы понять истоки появления этой идеи.

   Традиционно метка VLAN использовалась как для разделения трафика в транках, так и для принятия решения о его коммутации в пределах устройства.
   То есть если с двух разных интерфейсов пришли два кадра с тегом 802.1q 10, то они оба попадали в один VLAN 10 на коммутаторе, соответственно оказывались в одном широковещательном домене. При этом физически нельзя было принять на устройстве больше 4094 VLAN (если не считать QinQ).
   Концепция EVC разделяет эти функции — тег 802.1q по-прежнему служит для разделения трафика в транках, однако решение о коммутации теперь на стороне Service instance.
   То есть Service-instance — это удобный способ разделить один физический интерфейс на несколько логических и в зависимости от метки VLAN и других параметров помещать пришедшие кадры в тот или иной сервис.

   Например VLAN 10 может быть назначен разным клиентам на разных портах одного коммутатора и далее прокинут через PW на другой конец сети, однако при этом нет необходимости настраивать VLAN 10 глобально на устройстве и тем самым помещать все порты с VLAN 10 в один широковещательный домен.
   То есть два кадра с тегом 10, придя на разные порты одного коммутатора сразу передадутся по xconnect и нигде не пересекутся. Таким образом понятие VLAN становится локально значимым для порта.

   При этом Service Instance может проверять не только верхний тег VLAN, но и внутренний или оба в случае QinQ или значение приоритета CoS. Можно задать также диапазон VLAN, помещаемых в данный сервис, настроить снятие, добавление или изменение тегов.
   Варианты коммутации: передать в xconnect или в bridge-domain.

   В случае маршрутизатора классический саб-интерфейс (типа GE1/1**.1234**) заменяется на Service instance с более широкими возможностями по выбору инкапсуляции.

3. Теперь нам нужно связать сервисы на AC-интерфейсах (service instance) с VFI. Для этого нам понадобятся bridge-domain.
   

   Linkmeup_R1(config)#bridge-domain 255
   Linkmeup_R1(config-bdomain)# member vfi Blue
   Linkmeup_R1(config-bdomain)# member gigabitEthernet 3 service-instance 10
   Linkmeup_R1(config-bdomain)# member gigabitEthernet 4 service-instance 12

   Цифра 255 в общем-то произвольная (0-4096). Может выбираться в соответствии с клиентским VLAN, например. Строго локальный для устройства и никуда не передаётся.

   Команда **member** позволяет к bridge-domain привязать различные сервисы.
   Первой командой подключаем VFI, двумя другими AC-интерфейсы — теперь все они в одном широковещательном домене.

   Bridge-domain это что-то вроде виртуального коммутатора в пределах одного устройства. Если вы привяжете к одному brdige-domain пару физических интерфейсов, то они окажутся в одном широковещательном сегменте. Похоже на VLAN, но более гибкое. То есть, дословно переводя, это L2-мостик между двумя сущностями. В нашем случае между физическим интерфейсом и VPLS.

   Конфигурация других PE

   Linkmeup_R3(config)#interface gigabitEthernet 3
   Linkmeup_R3(config-if)#service instance 13 ethernet
   Linkmeup_R3(config-if-srv)#description Blue-D
   Linkmeup_R3(config-if-srv)#encapsulation default
   
   Linkmeup_R3(config)#bridge-domain 255
   Linkmeup_R3(config-bdomain)# member vfi Blue
   Linkmeup_R3(config-bdomain)# member gigabitEthernet 3 service-instance 13

   Linkmeup_R4(config)#interface gigabitEthernet 3
   Linkmeup_R4(config-if)#service instance 11 ethernet
   Linkmeup_R4(config-if-srv)#description Blue-B
   Linkmeup_R4(config-if-srv)#encapsulation default
   
   Linkmeup_R4(config)#bridge-domain 255
   Linkmeup_R4(config-bdomain)# member vfi Blue
   Linkmeup_R4(config-bdomain)# member gigabitEthernet 3 service-instance 11

На этом настройка VPLS Martini Mode закончена.

На некотором оборудовании существует два способа настройки VPLS Martini Mode. Другой сейчас считается устаревшим, но допустимым. Вместо команды l2vpn vfi context Blue используется l2 vfi Blue. Главным образом разница заключается в том, что member меняется на neighbor, а привязка к Bridge-domain делается не в секции bridge-domain, а в собственно секции vfi или на интерфейсе в режиме настройки Service instance.