Virtual private lan service что это

Обновлено: 04.07.2024

В обычном мире, не касаясь MPLS, когда хост посылает фрейм в свитч: свитч бродкастит и лернит.

VPLS-instance работает как свитч, который тоже бродкастит и лернит.

На PE1 в VPLS прилетел фрейм, VPLS: запомнил какой mac, соотнес с портом: A -> int 1.
PE1 флудит его во все интерфейсы. А pseudo-wire, воспринимаем как интерфейс. Т.о. фрейм долетел до PE2.
PE2 заучивает mac: A -> pseudo-wire 1 (lsi interface).
Фрейм, пришедший с локального интерфейса, должен быть разослан всем PE.

Фрейм, пришедший с локального интерфейса флудится во все локальные интерфейсы и pseudo-wire. Фрейм, который пришел от pseudo-wire (lsi), флудится только в локальные интерфейсы. Чтобы не было петли.

Когда прилетает фрейм с dest-mac уже известным, то он идет по уже заученному для него пути.

То есть с точки зрения форвардинга VPLS - один большой свитч!

Внутри VPLS происходит lookup по маку => должен быть включен tunnel-services.

Pseudo-wire - строятся по LDP или BGP. В отличие от L2VPN, в VPLS - сигнализация по BGP имеет огромное приемущество.

BGP выполняет функцию signaling и auto-discovery. PE ищет какие PE законнектились в тот же VPLS и отправляет им NLRI.

Передается NLRI, аналогичный BGP L2VPN:

label base
label range
site-id
offset

То есть для работы VPLS в настройках BGP включаем тот же самый l2vpn signaling.

L2-circuit - это по сути метки (на выход, вход). В отличие от L2VPN каждому локальному интерфейсу назначать метку нет смысла, ведь внутри VPLS уже есть соответствие mac - interface. Поэтому в VPLS метка должна была бы назначиться целиком на RI (per instance, per site).

Но эта логика не правильная. =(

Learning mac-адресов! делает эту схему многоточкой!

Блок меток соответствует-выделяется удаленному site, чтобы когда пакет придет на РЕ понимать с какого site он пришел. Это требуется, чтобы сделать правильный learning.

В остальном весь остальной процесс signaling аналогичен L2VPN.

Site-ID в данной схеме принципиального значения не имеет. Требуется только для PE для внутренних вычислений, поэтому можно просто выбрать и назначить site-id, или задать auto-site-id.

Между PE требуется full-mesh.

В случае l2circuit указывали удаленный PE.

В VPLS, помимо всего прочего, потребуется добавить для всех удаленных PE remote-site-id ручками.

Как и у L2VPN в NLRI передается:

label base (начальная)
site-ID
label range

Исходя из полученных данных PE вычисляет свою метку для связи с тем PE, кот переслал блок:

Ниже описанное касается CE-facing интерфейс.

Для обычного Ethernet с vlan должна стоять: vlan-vpls. Она подходит как для qinq, так и для 802.1q.

Можно ставить ее как на логический интерфейс, так и на физический.

Если это не единственный тип инкапсуляции на физическом интерфейсе, то лучше на нем сразу указать тип инкапсуляции: flexible-ethernet-services.

В рамках vrf VPLS можно определять vlan для VPLS путем конфигурирования vlan-id | vlan-tags

vlan-id <vlan-id> - в VPLS будет работать только один указанный vlan-id
vlan-id none - у приходящего пакета будет сниматься vlan-id tag. У исходящего навешиваться тот vlan-id tag, который указан на исходящем из VPLS интерфейсе.
vlan-id all - используется с logical interface, на которых настроено двойное теггирование. При этом на выходе из VPLS outer-tag будет навешиваться (push), на входе в VPLS outer-tag будет сниматься (pop). В VPLS будут бегать маки с inner vlan-id.
vlan-tags inner <> outer <> - позволяет работать VPLS с двумя тегами.

Если в VPLS указывает vlan каким-то из способов, то на interface нельзя использовать input-vlan-map и output-vlan-map

Со стороны клиента: влан на разных site должен совпадать. Иначе связности не будет.

удобнее в трабшутинге
в отличие от L2VPN не требует указания remote-site
обеспечивает схему коммутации точка-многоточка

бродкаст домен => защита от петель между PE<>CE

STP на PE<>CE
ERP на CE
LAG на PE <> CE
Active/backup links on PE
Multihomed CE with two PEs.

может передавать только ethernet

BGP based VPLS

Минимальный рабочий конфиг:

На всех роутерах:

BGP-family:

encapsulation vlan-vpls (как для LDP signalling, так и для BGP signaling):

Дополнительные часто используемые параметры:

connectivity-type permanent - вне зависимости от состояния интерфейсов - поднимет VPLS.
mac-table-size 6000 packet-action drop - ограничение по макам в VPLS.
site-range 8 - ограничение по количеству site в рамках одного VPLS.

Multihoming (BGP signaling)

Используется для подключения одного site клиента к нескольким PE.

Только один PE будет активным и выбран в качестве designated forwarder, т.е. передавать трафик. Такой PE будет устанавливать с удаленным PE pseudo-wire.

Если что-то произойдет с активным PE, второй multihomed PE установит pseudo-wire до удаленного PE.

Удаленные PE, чтобы определить куда им все-таки нужно передавать трафик, используют процесс VPLS path-selection:

Если advertisement bit = 0, то эта NLRI отбрасывается.
Далее выбор идет по наибольшему site-preference приоритету.
Далее по меньшему RID.
Далее по меньшему ip адресу BGP Peer.

Удаленный PE выбрал активный multihomed PE, назначив его designated VE (VPLS edge). И стал использовать только 1 NLRI. До такого designated VE удаленный PE и построит pseudo-wire.

Если требуется использовать multihoming для VPLS, то нужно учесть, что это будет работать только с BGP сигнализацией. Не LDP.

Одинаковый site-id для multi homed PE.
Разный RD для multi homed PE.
Указать интерфейсы в VPLS.
Включить multihoming.
Если на сети используется схема, где один и тот же site растянут на 2 PE, оба PE имеют линки в сторону одного CE, то можно определять активный PE с помощью site-preference backup|primary. Либо руками задавать site-preference. Backup-PE поднимет connections с удаленными PE только в случае отвала primary PE того же site.
[В случае, если на одной PE несколько линков к CE]. Задаем active-interface. Если указываем any, то будет выбран один из перечисленных ниже интерфейсов. Если указываем primary, то активным сразу будет выбран явно заданный интерфейс. А остальные интерфейсы в порядке очереди будут использоваться при падении primary.

LDP based VPLS

instance-type vpls
lo должен быть добавлен в ldp
!!rt, rd - не обязательны!!

Есть несколько отличий:

Вводится vpls-id. Это просто идентификатор vpls. Аналогично virtual-circuit-id для l2vpn LDP signaling. То есть просто любое уникальное число.
Вручную указываются соседи - удаленные PE.

Дополнительные часто используемые параметры:

connectivity-type permanent - вне зависимости от состояния интерфейсов - поднимет VPLS.
mac-table-size 6000 packet-action drop- ограничение по макам в VPLS.
site-range 8 - ограничение по количеству site в рамках одного VPLS.

Multihoming (LDP signaling)

Когда два PE, смотрят в сторону одного и того же CE, без настройки дополнительных протоколов можно настроить VPLS таким образом => один из PE настраиваем как primary, второй backup.

Настройки делаются на удаленных PE. К neighbor добавляется backup PE:

На удаленном PE backup роутер будет находиться в статусе: BK -- Backup connection.

А если в конфиг к backup-neighbor добавить еще и standby, то на удаленных PE он будет болтаться в статусе: ST -- Standby connection. А сам backup роутер будет устанавливать сессию с удаленным PE (State = Up)

L3VPN, который мы рассмотрели в прошлом выпуске, покрывает собой огромное количество сценариев, необходимых большинству заказчиков. Огромное, но не все. Он позволяет осуществлять связь только на сетевом уровне и только для одного протокола - IP. Как быть с данными телеметрии, например, или трафиком от базовых станций, работающих через интерфейс E1? Существуют также сервисы, которые используют Ethernet, но тоже требуют связи на канальном уровне. Опять же ЦОДы между собой любят на языке L2 общаться.
Вот и нашим клиентам вынь да положь L2.

Традиционно раньше всё было просто: L2TP, PPTP да и всё по большому счёту. Ну в GRE ещё можно было спрятать Ethernet. Для всего прочего строили отдельные сети, вели выделенные линии ценою в танк (ежемесячно). Однако в наш век конвергентных сетей, распределённых ЦОДов и международных компаний это не выход, и на рынок выплеснулось некоторое количество масштабируемых технологий випиэнирования на канальном уровне.
Мы же в этот раз сосредоточимся на MPLS L2VPN.

Технологии L2VPN

VLAN/QinQ - их можно сюда отнести, поскольку основные требования VPN выполняются - организуется виртуальная L2 сеть между несколькими точками, данные в которой изолированы от других. По сути VLAN per-user организует Hub-n-Spoke VPN.
L2TPv2/PPTP - устаревшие и скучные вещи.
L2TPv3 вместе с GRE имеют проблемы с масштабированием.
VXLAN, EVPN - варианты для ЦОД"ов. Очень интересно, но DCI не входит в планы этого выпуска. Зато о них был отдельный подкаст (слушайте запись 25-го ноября)
MPLS L2VPN - это набор различных технологий, транспортом для которых выступает MPLS LSP. Именно он сейчас получил наиболее широкое распространение в сетях провайдеров.

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

Point-to-Point

Virtual Private Wire Service

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

Традиционно термины будут вводиться по мере необходимости. Но о некоторых сразу.
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 сравнительно прост, как в части передачи трафика, так и работы служебных протоколов.

VPWS Data Plane или передача пользовательского трафика

Туннельная метка - то же, что и транспортная, просто длинное слово "транспортное" не помещалось в заголовок.

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, получив пакет, анализирует сервисную метку и определяет, в какой интерфейс нужно передать распакованный кадр.

VPWS Control Plane или работа служебных протоколов

Транспортная метка может назначаться как 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?

Чтобы сильно далеко не убегать, сразу же практика.

Как собрать лабу для MPLS L2VPN?

В качестве тестового стенда использована связка UnetLab + CSR1000V. И то и другое вы можете получить совершенно бесплатно и законно.
UnetLab OVA.
Cisco CSR1000V IOS-XE.
Инструкции по установке UNL и добавлению образов CSR1000V: Тыц.

Соответственно далее все команды по настройке MPLS L2VPN даны в нотации Cisco IOS-XE.

Внимание: для каждой ноды CSR1000V требуется 2,5 ГБ RAM. В противном случае образ либо не запустится, либо будут различные проблемы, вроде того, что порты не поднимаются или наблюдаются потери.

Практика VPWS

Упростим топологию до четырёх магистральных узлов. По клику можете открыть её в новой вкладке, чтобы смотреть на неё Alt+Tab"ом, а не ворочать страницу вверх-вниз.

Наша задача - прокинуть Ethernet от Linkmeup_R1 (порт Gi3) до Linkmeup_R4 (порт Gi3).

На шаге 0 IP-адресация, IGP-маршрутизация и базовый MPLS уже настроены (см. как).

Давайте проследим, что там происходило за кулисами протоколов (дамп снят с интерфейса 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-соседство

--В. Пошёл обмен метками:

То же самое делает и 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.

Виды VPWS

Рассмотренный пример - это 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 можно представить так:

пятница, 8 июля 2016 г.

MPLS L2VPN VPLS

Кратко про первый вид сервиса в MPLS L2VPN я уже писал в посте про VLL. Конечно же понятно, что абоненту не всегда нужна труба точка-точка, зачастую абонент хочет развитую сеть точка-многоточка или скорее многоточка-многоточка. В таком случае, на сцену выходит Virtual Private LAN Service (VPLS)

Концепция VPLS умещается в пару строк и в состоянии предоставить клиенту виртуальную Ethernet сеть. В таком случае, сеть провайдера для абонента выглядит как один большой коммутатор. Этот коммутатор, как и любой другой, может понимать теги VLAN, обычно такой коммутатор знает что делать с двумя тегами VLAN (QinQ) или, скажем, умеет VLAN трансляцию. Более того, "большой коммутатор" может даже участвовать в клиентском STP или быть членом Link Aggregation Group. Об этом я напишу в посте про обеспечение отказоустойчивости в MPLS.

Все посты про MPLS VPN можно посмотреть по тегу MPLS или в обобщающем посте.

Рассмотрим базовую архитектуру подробнее. В ней все так же присутствует PSN (созданный LDP, RSPV-TE или GRE). Поверх PSN строятся pseudowire туннели (T-LDP) для каждого сервиса VPLS. В базовом варианте, в ядре провайдера pseudowire туннели должны строиться от каждого PE роутера до каждого, образовывая так называемый full-mesh (соединение по принципу "каждый с каждым"). К каждому PE подключен абонентский роутер (CE). VPLS сервис обеспечивает связность всех CE стройств.

VSI - это то, что делает VPLS випиэлэсом. Эта виртуальная сущность выполняет роль коммутатора на каждом PE роутере. Для каждого сервиса на роутере создается отдельный VSI. Тут можно проследить некую аналогию с VRF в L3VPN. Можно представить VSI как коммутатор внутри устройства в порты которого воткнуты провода идущие к точками подключения и pseudowire. На картинке выше я попытался это изобразить.

VPLS не уступает VLL в гибкости точек подключения клиентов. Как и в Epipe, attachment circuit может быть настроен на прием тегированных Ethernet кадров от заказчика (в том числе и несколькими метками), ATM кадров, Frame Relay и, скорее всего, чего-нибудь ещё.

Трафик в MPLS сети проходит ряд довольно очевидных этапов. Рассмотрим простой пример, когда в только что сконфигурированной VPLS сети побежал первый пакет.

Hierarchical VPLS

Везде где есть топология каждый с каждым есть проблема с огромным количеством "линков", посчитать которые можно формулой n(n-1)/2. В итоге была придумана концепция H-VPLS, которая немного сокращала число линков частично избавляя от full mesh топологии.

По сути, H-VPLS чисто технически отличается от обычного VPLS только введением нового типа pseudowire, который называется "spoke pseudowire". Этот тип отличается от обычного pseudowire туннеля в VPLS лишь отсутствием split horizon правила.

В обычном VPLS, трафик из pseudowire ("mesh pseudowire") не может быть отправлен в другую "mesh pseudowire". В H-VPLS, таковых ограничений нет, трафик из spoke pseudowire может быть отправлен в другую spoke pseudowire, в точку подключения абонента или в mesh pseudowire. В общем, если придерживаться визуализации с коммутатором и проводами, то mesh-pseudowire подключена к этому виртуальному коммутатору обычным проводом в порт, который действует как порт на обычном коммутаторе. А вот порт в который подключен mesh pseudowire туннель имеет на себе ряд ограничений в виде split horizon.

Наверное, на примерах будет понятнее. Рассмотрим сеть, в которой введен иерархический дизайн. Все PE маршрутизаторы теперь не обязаны иметь pseudowire до каждого другого PE.
Теперь среди PE выбрано три hub-PE, которые агрегируют spoke pseudowire туннели с spoke PE. Все hub-PE по прежнему имеют pseudowire-подключения по принципу каждый с каждым. Все pseudowire в ядре настроены как mesh pseudowire, что инструктирует VSI придерживаться правила split horizon в отношении таких туннелей. Трафик пришедший из такого туннеля не может быть отправлен в другой такой же. Это обеспечивает более ровное распределение трафика в ядре, неплохую отказоустойчивость и защиту от колец/петель.

Все spoke-PE теперь подключены всего одним spoke pseudowire к ближайшему hub-PE. Это существенно уменьшает количество туннелей, упрощает настройку, в случае добавления нового spoke-PE, ну и отказоустойчивость, конечно, чуть страдает (об этом как-нибудь в другой раз). Hub-PE имеет spoke pseudowire в сторону абонентов и mesh pseudowire в сторону ядра. Spoke pseudowire направлены в сторону абонентов и VSI не применяет правило split horizon на них. Т.е. трафик пришедший к hub-PE из одной spoke pseudowire вполне может быть отправлен в другую spoke pseudowire. Это штатный случай.

Ясно, что защита от петель тут достигается нормальным дизайном и правильной конфигурацией. Наряду со страдающей отказоустойчивостью, выбор между H-VPLS и обычным VPLS всегда вопрос баланса.

Определение spoke или mesh pseudowire носит локальный характер, по сути это всего лишь соответствуюшая настройка VSI, который выключает split horizon на spoke туннелях. Однако его можно включить назад, объединив несколько spoke pseudowire в группу. Таким образом получится некий аналог Private VLAN. Трафик из одной spoke pseudowire не будет передан в другую spoke pseudowire. Может быть клиент захотел такую топология, в которой его офисы не должны общаться напрямую, а весь трафик должен проходить через его центральный офис, в котором стоит файервол.

Вообще, имея сеть с MPLS для каждого клиента можно и, в некоторых случаях, даже нужно выбирать подходящую топологию под каждого абонента. Для кого-то будет лучше строить обычный VPLS (если мало точек подключения и критично "качественное" прохождение трафика), для кого-то нужно строить H-VPLS (точек много, но оптимальность прохождения трафика не так важна).

Пока все.
Хотя нет, не все.

Возможно, читая все эти многобуквы, у вас возникло чувство некоего дискомфорта в душе. И это абсолютно правильно, ведь все приходится настраивать руками. Фу. Сначала нужно настроить PSN туннели (GRE, LDP, RSVP-TE), потом поверх них нужно настроить pseudowire туннели, сконфигурировать на каждой ноде VSI сущность. Все это можно автоматизировать с помощь.

BGP-Auto Discovery (BGP AD)

Принцип использования MG-BGP в L2VPN VPLS примерно такой же как и в L3VPN VPRN. Настроив на каждом PE роутере BGP-AD, мы получаем возможность динамически добавлять в определенный VPLS определенные ноды, поднимать транспортные (PSN) туннели согласно определенным шаблонам и затем сигнализировать по другим шаблонам pseudowire до нужных PE через них. Короче, все круто. Обычно, есть ряд ограничений связанных с использование с BGP-AD. Тот же Алкатель, к примеру, не может сигнализировать PSN использую RSVP-TE, поэтому их главная рекомендация - настраивать необходимые PSN руками, а BGP-AD уже будет создать psewdowire по шаблонам. BGP AD оперирует двумя сущностями Route Target(RT) и Route Distiguisher(RD). С помощью настроенного импорта/экспорта этих значений в VPLS, мы можем строить различные VPLS топологии.

Если вы хоть раз сталкивались с RT и RD, то вы точно знаете, что тема их различия у многих вызывает конфуз. На столько у многих, что даже в некоторых учебных материалах просто игнорируют эту тему. Было у меня как-то собеседование, на котором я начал хвалится своими рыгалиями, на что интервьювер отреагировал примерно так:"Это все понятно. А вот в чем отличие RT от RD, вы знаете?".

Route Distinguisher (RD) - значение, которое использует BGP для того чтобы сделать все маршруты (NLRI) в сети уникальными. Получая NLRI, BGP добавляет к нему RD для того чтобы получить уникальный NLRI. Пример из L3VPN, есть у BGP префикс 192.168.0.0/24, который пришел от клиента. Есть такой же префикс, который пришел от другого клиента. BGP добивает к ним RD в соответствии с тем, из какого VPN пришли префиксы, и получаем две уникальных сущности 65000:1:192.168.0.0/24 и 6500:2:192.168.0.0/24. RD - имеет локальный характер.
Route Target (RT) - даже из названия понятно, что у RT совсем не локальный характер. Это некая метка для удаленного устройства, с помощью которой он решит в какой VPN засунуть маршрут. Манипулирую с импортом/экспортом различных значений RT, мы можем строить причудливые топологии в L2 и L3 VPN.

Допустим, у нас есть сеть из четырех маршрутизаторов, на каждом настроен BGP-AD c VPLS100. Мы хотим построить типичную hub-and-spoke топологию. R1 должен иметь связность с R2, R3 и R4, которые должны общаться только через центральную ноду R1. Сделать мы это можем с помощью манипулирования с RT, импорта и экспорта его в VPLS инстанс.
Нода R1 экспортирует из VPLS RT 65000:1 и импортирует в него RT 65000:2, 65000:3, 65000:4 Нода R2 экспортирует из VPLS RT 65000:2 и импортирует в него RT 65000:1 Нода R3 экспортирует из VPLS RT 65000:3 и импортирует в него RT 65000:1 Нода R4 экспортирует из VPLS RT 65000:4 и импортирует в него RT 65000:1

Добавляя определенные RT в импорт или экспорт, мы получаем возможность строить различные топологии. Например, добавим ещё один роутер R5. Путь этот роутер должен построить pseudowire до R1 и R2. Ок. Пусть он экспортит RT 65000:5 и импортит RT 65000:1 и 65000:2. На нодах R1 и R2 нужно добавить 65000:5 на импорт и соответсвубщие pseudowire сигнализируются.

Provider Backbone Bridge (PBB) 802.1ah

Мы уже рассмотрели как в VPLS была решена проблема многочисленных pseudowire (H-VPLS) и необходимости ручной настройки (BGP-AD). Пришло время решить ещё одну проблему, которая связана с количеством MAC адресов в VPLS сети. Помним, что VSI на каждом роутере участвующим в VPLS изучает MAC-адреса клиентов. Количество их может быть довольно большим, если не сказать огромным, если провайдер предоставляет несколько сервисов VPLS большим клиентам. PBB придумывался как средство для уменьшения MAC-адресов в сети и позднее был добавлен в VPLS. В PBB есть два типа устройств:

Backbone Edge Brindge (BEB) - добавляет к клиентскому трафику ещё один заголовок, в котором содержится:
- Instance TAG - позволяет идентифицировать клиента, по характеру похож на сервисную метку pseudowire в MPLS. В VPLS по I-TAG роутер понимает в какой VPLS инстанс засунуть трафик.
- Backbone VLAN (B-VID) - VLAN тэг, который позволяет разделить PBB сеть на сегменты.
- Backbone Source Address (B-SA) - MAC адрес источника в PBB сети
- Backbone Destination Address (B-DA) - MAC адрес назначения в PBB сети
PBB - это такая Ethernet сеть для Ethernet сетей. В чем-то есть схожесть с MPLS или TRILL. Сама суть проста - к абонентскому трафику (а это может быть и QinQ, к примеру) добавляем ещё VLAN и пару MAC адресов, дальнейшая обработка трафика будет происходить по ним.

Процесс адаптации PBB для VPLS просто убивает своей терминологией. Весь VPLS домен разделяется на две части. Одна часть смотрит в сторону клиента и носит название Edge Domain или Interface Domain (I-domain), вторая часть ассоциируется с ядром сети и носит название Backbone Domain (B-domain). Граница между доменами обычно проходит по hub-PE устройствам, которые агрегируют pseudowire c spoke-PE, которые уже подключены к клиенту. Такие hub-PE носят название IB-PE. На них настраивается фактически два VPLS инстанса с двумя разными VSI. Один (I-VPLS) подключен к обычной VPLS сети, где ещё бегают клиентские MACи, другой (B-VPLS) подключен в ядро, в котором коммутация происходит по новому заголовку. Все роутеры в ядре изучают только MAC адреса в новом заголовке. Есть и другой принцип, когда I-VPLS и B-VPLS располагаются на разных устройствах, но мы умеренно проигнорируем этот факт.

Трафик по такой сети ходит довольно причудливо.

В итоге, обычный Ethernet-трафик клиента, допустим даже без тегов, проходя через MPLS ядро, претерпевает множество инкапсуляций. На него навешивается новый заголовок PBB, сервисная и транспортная метки, после чего трафик попадает в сеть, в которой на него могут быть навешены ещё метки в случае FRR, например.

В ядре провайдера кадр будет выглядеть например так (часть полей не учитываем). Нарисуем HTML-табличку в стиле Web1.0.

1. VPLS BGP Autodiscovery + LDP Signaling
Иногда у конечного заказчика возникает необходимость объединить свои удаленные офисы в один широковещательный сегмент.
На помощь поставщику услуг в данном случае может придти технология, которая называется Virtual Private Lan Services (VPLS). Ее суть в том, что все MPLS облако провайдера предоставляет для заказчика прозрачный L2-коммутатор.
Разберемся как работает VPLS на конкретной задаче. Пусть существует заказчик, у которого есть 3 удаленных офиса (A, B и C) в разных городах.

Bridge-domain 710 (2 ports in all)
State: UP Mac learning: Enabled
Aging-Timer: 300 second(s)
GigabitEthernet2 service instance 10
vfi VPLS_BGP-LDP-VLAN710 neighbor 150.3.3.3 710
MAC address Policy Tag Age Pseudoport
FFFF.FFFF.FFFF flood static 0 OLIST_PTR:0xe807e820
5000.000A.0001 forward dynamic 259 GigabitEthernet2.EFP10
5000.0007.0001 forward dynamic 259 VPLS_BGP-LDP-VLAN710.100101f
В выводе листинга показываются как локально изученные MAC адреса (через интерфейс Gi2), так и те, которые были изучены через vfi интерфейсы.
Точно также, как и обычный коммутатор, через VPLS возможна передача мультикаст и широковещательного трафика. И этот факт может привести к проблеме, т.к. все PE маршрутизаторы связаны в full-mesh топологию (в рамках одного VPLS облака).

Чтобы этого не было, действует правило split-horizon: если пакет (фрейм) получен через виртуальный (VC) интерфейс, то такой пакет нельзя отсылать обратно в VPLS облако.

2. BGP Signaling

Читайте также: