Разберём работу VPLS на практике по шагам вот по этой схеме. Это всё та же сеть, но теперь клиент решил, что ему недостаточно двух точек, он хочет четыре и объединить их все в одну сеть.
Кликабельно.
Итак на шаге 0 у нас готовы необходимые транспортные LSP, а соответственно, и маршрутизация итд.
Создаём 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**
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**
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
В режиме конфигурации интерфейса мы создаём Service Instance — это привязка интерфейса к сервисам. Каким именно — настроим позднее. Номер Service Instance произвольный — он локальнозначимый для интерфейса (как и у классического сабинтерфейса).
**encapsulation _default_** означает, что мы хватаем все кадры без разбора (а могли бы выбирать по метке VLAN или по факту наличия двух меток — QinQ, например), то есть весь физический интерфейс привязываем к VFI.
**Хочу знать больше про Service Instance…**
Резонный вопрос от сторонников бритвы Оккамы — зачем какие-то 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 с более широкими возможностями по выбору инкапсуляции.
Учитывая, что до сих пор не всё понятно с этим EVC, отсылаю вас к более пространным объяснениям: [на Cisco][44] и [на русском][45].
Теперь нам нужно связать сервисы на 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...**
Bridge-domain это что-то вроде виртуального коммутатора в пределах одного устройства. Если вы привяжете к одному brdige-domain пару физических интерфейсов, то они окажутся в одном широковещательном сегменте. Похоже на VLAN, но более гибкое. То есть, дословно переводя, это L2-мостик между двумя сущностями. В нашем случае между физическим интерфейсом и VPLS.
**Конфигурация других PE...**
* * *
**Linkmeup\_R3**
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)#bridge-domain 255 Linkmeup_R4(config-bdomain)# member vfi Blue Linkmeup_R4(config-bdomain)# member gigabitEthernet 3 service-instance 11
На некотором оборудовании существует два способа настройки VPLS Martini Mode. Другой сейчас считается устаревшим, но допустимым. Вместо команды l2vpn vfi context Blue используется l2 vfi Blue. Главным образом разница заключается в том, что member меняется на neighbor, а привязка к Bridge-domain делается не в секции bridge-domain, а в собственно секции vfi или на интерфейсе в режиме настройки Service instance.
Подробнее вы можете посмотреть в альтернативном фaйле конфигурации VPLS Martini Mode.
