Мережі для найбільш досвідчених. Частина дванадцята. MPLS L2VPN

Довго чи коротко, але шестерні в черговий раз провернули і linkmeup став на щабель Tier 2. І кілька достатньої платежоспособности энтерпрайзов виявили зацікавленість в організації зв'язку між своїми філіями через мережі linkmeup.

L3VPN, який ми розглянули у минулому випуску, покриває собою величезну кількість сценаріїв, необхідних більшості замовників. Величезна, але не всі. Він дозволяє здійснювати зв'язок тільки на мережевому рівні і тільки для одного протоколу IP. Як бути з даними телеметрії, наприклад, або трафіком від базових станцій, що працюють через інтерфейс E1? Існують також сервіси, які використовують Ethernet, але теж вимагають зв'язку на канальному рівні. Знову ж Цод між собою люблять мовою L2 спілкуватися.
Ось і нашим клієнтам вийми та поклади L2.

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

Ми ж в цей раз зосередимося на MPLS L2VPN.





Отже, сьогодні у програмі:
  • Про технології L2VPN
  • VPWS
    • Data Plane
    • Control Plane

    • Практика

    • Види VPWS
  • VPLS
    • Data Plane
    • Control Plane

    • VPLS Martini Mode (targeted LDP)
      • Практика
    • VPLS Kompella Mode (BGP)
      • Виявлення сусідів або Auto-Discovery
      • Передача префіксів

      • Розподіл міток і механізм Label Block
      • Практика
  • Ієрархічний VPLS (H-VPLS)
    • Практика H-VPLS
  • Проблеми VPLS
  • Корисні посилання



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


Чому він переможець? Головна причина, безумовно, у здатності маршрутизаторів, передавальних MPLS-пакети абстрагуватися від їх вмісту, але при цьому розрізняти трафік різних сервісів.
Наприклад, Е1-кадр приходить на PE, відразу ж інкапсулюється в MPLS і вже ніхто навіть не запідозрить, що там всередині — важливо тільки вчасно змінити мітку.
А на інший порт приходить Ethernet-кадр і по тому ж самому LSP він може пройти по мережі, тільки з іншого міткою VPN.
А крім того MPLS TE дозволяє будувати канали з урахуванням вимог трафіку до параметрів мережі.
У зв'язку ж з LDP і BGP стає більш просто налаштувати VPN і автоматично знаходити сусідів.

Можливість инкапсулировать трафік будь-якого канального рівня в MPLS називається AToMAny 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
Для побудови будь-якого L2VPN існують два концептуально різних підходу.
  • Point-to-Point. Застосуємо до будь-яких типів протоколів канального рівня і в принципі, в повній мірі вичерпує всі сценарії застосування L2VPN. Підтримує всі мислимі і немислимі протоколи. Причому деякі з них ще й по-різному може реалізовувати.
    В основі лежить концепція PW — PsewdoWire — псевдопровод.
    Ви хочете з'єднати два вузла один з одним. Тоді мережа провайдера для вас буде як один віртуальний кабель — те, що ввійшло в нього на одному кінці обов'язково вийде на іншому без змін.
    Загальна назва послуги: VPWSVirtual Private Wire Service.

  • Point-to-Multipoint. Цей режим тільки для Ethernet, оскільки тільки в ньому фактично така необхідність є. У цьому випадку у клієнта може бути три-п'ять-десять-сто точок підключення/філій, і всі вони повинні передавати інформацію один одному, причому, як одному конкретному філії, так і всіх відразу. Це до болю нагадує звичайний Ethernet-комутатор, але було б страшною банальністю про це говорити.
    Назва технології: VPLSVirtual Private LAN Service.




Термінологія
Традиційно терміни будуть вводитися по мірі необхідності. Але про деякі відразу.
PEProvider Edge — граничні маршрутизатори MPLS-мережі провайдера, до яких підключаються пристрої (CE).
CECustomer Edge — обладнання клієнта, безпосередньо подключающееся до маршрутизатора провайдера (PE).
ACAttached Circuit — інтерфейс на PE для підключення клієнта.
VCVirtual Circuit — віртуальне односпрямоване з'єднання через загальну мережу, що імітує оригінальну середовище для клієнта. З'єднує між собою AC-інтерфейси різних PE. Разом вони складають цілісний канал: AC→VC→AC.
PWPsewdoWire — віртуальний двонаправлений канал передачі даних між двома PE — складається з пари односпрямованих VC. У цьому і є відмінність PW від VC.





VPWS. Точка-точка
VPWSVirtual Private Wire Service.
В основі будь-якого рішення MPLS L2VPN лежить ідея PW — PsewdoWire — віртуальний кабель, прокинутый з одного кінця мережі в інший. Але для 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, отримавши пакет, аналізує сервісну мітку і визначає, в якій інтерфейс потрібно передати розпакований кадр.



Якщо ви читали попередній випуск про L3VPN, то в питанні передачі користувача трафіку не побачите нічого нового — пара MPLS-міток і передача по транспортному LSP. Ingress PE перевіряє які мітки поставити і в якій інтерфейс надіслати P змінює транспортну мітку, а Egress PE по мітці VPN приймає рішення, в якій AC-інтерфейс передати отриманий кадр.

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?
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. В іншому випадку образ або не запуститься, або будуть різні проблеми, на зразок того, що порти не піднімаються або спостерігаються втрати.



Практика VPWS
Спростимо топологію до чотирьох магістральних вузлів. По кліку можете відкрити її в новій вкладці, щоб дивитися на неї Alt+Tab'ом, а не перевертати сторінку вверх-вниз.



Наше завдання — прокинути Ethernet від Linkmeup_R1 (порт Gi3) до Linkmeup_R4 (порт Gi3).

На кроці 0 IP-адресація, IGP-маршрутизація і базовий MPLS вже налаштовані (див. ).
Файл початкової конфігурації.


  1. Налаштовуємо xconnect на обох кінцях на AC-інтерфейси (PE-CE), звертаємо увагу, що VC-ID повинен бути однаковим.

    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-інтерфейсах — це покажчик того, що їх потрібно відновити.
  2. Профіт.




На цьому конфігурація 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-сусідство


--Ст. Пішов обмін мітками:
/5c9/2ec/4ca5c92ec15f45b2af460c48ad6381ee.PNG"/>

У самому низу можна бачити, що 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.1 q і мітку VLAN 0x3F, або 63 в десятковій системі.

Якщо ми перенесемо конфігурацію xconnect на сабинтерфейс із зазначенням VLAN, то він буде терминировать даний VLAN і відправляти в PW кадр без заголовка 802.1 q.




Види VPWS
Розглянутий приклад — це EoMPLS (Ethernet over MPLS). Він є частиною технології PWE3, яка суть розвиток VLL Martini Mode. І все це разом і є VPWS. Тут головне не заплутатися у визначеннях. Дозвольте мені бути вашим провідником.
Отже, VPWS — загальна назва рішень для L2VPN виду точка-точка.
PW — це віртуальний L2-канал, який лежить в основі будь-якої технології L2VPN і служить тунелем для передачі даних.
VLL (Virtual Leased Line) — це вже технологія, яка дозволяє инкапсулировать кадри різних протоколів канального рівня в MPLS і передавати їх через мережу провайдера.
Виділяють наступні види VLL:
VLL CCCCircuit Cross Connect. У цьому випадку немає мітки VPN, а транспортні призначаються вручну (статичний LSP) на кожному вузлі, включаючи правила swap. Тобто в стеку буде завжди тільки одна позначка, а кожен такий LSP може нести трафік тільки одного VC. Жодного разу не зустрічав його в життя. Головне його достоїнство — він може забезпечити зв'язність двох вузлів, підключених до одного PE.

VLL TCCTranslational Cross Connect. Те ж, що CCC, але дозволяє з різних кінців використовувати різні протоколи канального рівня.
Працює це тільки з IPv4. PE при отриманні видаляє заголовок канального рівня, а при передачі в AC-інтерфейс вставляє новий.
Цікаво? Почніть отсюда.

VLL SVCStatic Virtual Circuit. Транспортний LSP будується звичайними механізмами (LDP або RSVP-TE), а сервісна мітка VPN призначається вручну. tLDP в цьому випадку не потрібний. Не може забезпечити локальну зв'язність (якщо два вузла підключені до одного PE).

Martini VLL — це приблизно те, з чим ми мали справу вище. Транспортний LSP будується звичайним чином, мітки VPN розподіляються tLDP. Краса! Не підтримує локальну зв'язність.

Compella VLL — Транспортний LSP звичайним чином, для розподілу міток VPN — BGP (як і годиться, з RD/RT). Уау! Підтримує локальну зв'язність. Ну та гаразд.


PWE3Psewdo Wire Emulation Edge to Edge. Строго говорячи, сфера застосування цієї технологія ширше, ніж тільки MPLS. Проте в сучасному світі в 100% випадків вони працюють у зв'язці. Тому PWE3 можна розглядати як аналог Martini VLL з розширеним функціоналом — сигналізацією так само займаються LDP+tLDP.
Коротко його відмінності від Martini VLL можна представити так:
  • Повідомляє статус PW, використовуючи повідомлення LDP Notification.
  • Підтримує Multi-Segment PW, коли end-to-end канал складається з декількох більш дрібних шматків. У цьому випадку один і той же PW може стати сегментів для декількох каналів.
  • Підтримує TDM-інтерфейси.
  • Надає механізм узгодження фрагментації.
  • ...
Зараз PWE3 — стандарт де-факто і саме він був у прикладі вище.

Я тут скрізь говорю про Ethernet для того, щоб показати найбільш наочний приклад. Все, що стосується інших канальних протоколів, це, будь ласка, на самостійне вивчення.





VPLS. Point-to-Multipoint
Мені дуже подобається термін " точка-багатоточка. Є в ньому щось дитяче, грайливе. І це те, про що ми поговоримо зараз.
VPLS — Virtual Private LAN Service. По своїй суті — це комутатор. Провайдер підключає кілька точок замовника до своєї мережі в різних її кінцях і забезпечує L2 зв'язність. І тепер це завдання транспортної мережі провайдера — піклуватися про правильну комутації кадрів, тобто вивчення MAC-адрес.

Термінологія
VPLS-домен — ізольована віртуальна L2-мережу, тобто, грубо кажучи, один окремий L2VPN. Два різних клієнта — два різних VPLS-домену.
VSIVirtual Switching Instance. Віртуальний комутатор в межах одного сайту.
Для кожного клієнта (або сервісу) він свій. Тобто трафік різних VSI не може кочувати з одного в інший.
Аналог VRF/VPN-instance L3VPN.
У термінах Cisco це VFIVirtual Forwarding Instance. Я дозволю собі вільно звертатися з термінами VPLS-домен, VSI і VFI, іноді використовуючи їх як синоніми.
ЕVPLS Edge — вузол PE, учасник VPLS-домену.

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-маршрутизаторі.
  4. Віддалений 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'ом? Знову доведеться поламати мізки або малими жертвами?
Вибачте, але далі починається треш і содомія. Не одразу — пізніше, але буде. Ви дієте на свій страх і ризик.

VPLS Control Plane
З роботи Data Plane вже видно, що для VPLS потрібно повнозв'язна топологія PE для кожного VSI. Причому не всі PE MPLS-мережі провайдера будуть сусідами, а тільки ті, де є цей же VSI.

Тому одне з головних питань в VPLS — виявлення всіх PE, куди підключені клієнти даного VSI.
Існує тут два підходи: ручна настройка та автоматичне виявлення. Перший шлях спочатку запропонувала Cisco (драфт Мартіні), батьком другого є Juniper (драфт Компелла).

11 випусків СДСМ пропагував спрощення життя інженера і автоматизацію всього і вся. І ось, настав той момент, коли потрібно забути все, чому вас учили. Це перший випадок (якщо не піднімати холівар навколо VTP), коли рішення з налаштуванням сусідів виявляється більш популярним.
Стало цікаво?

Перш ніж відкриємо куліси, хочу зробити зауваження: незалежно від того, що ми витворяємо з VPN-мітками, транспортні LSP будуються як зазвичай LDP або RSVP-TE. Тому далі стосуватися транспорту ми будемо тільки побіжно.

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

Слово «драфт», міцно закрепившееся за цими двома підходами, вже давно неправомірно і використовується за історичною інерцією. Драфтом пропозиція може бути тільки шість місяців.
На даний момент draft-martini переродився в RFC 4777 — Інтернет-стандарт про 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 (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 (На жаль CSR1000V на тестовому стенді цього не робить).
Відомі випадки, коли в разі зміни стану AC-порту, PE відправляє повідомлення LDP MAC withdraw без уточнення, які саме повне mac ' і. Це означає, що кожен сусід повинен очистити всю таблицю MAC-адрес даного VPLS-домену.
Тепер уявіть, що рахунок йде на сотні, можливо, тисячі записів. І по всій мережі всі PE починають вивчати MAC-адреси. А що вони роблять з кадром, коли не знаходять MAC одержувача? Розсилають усім. Виникає короткочасний широкомовний шторм без петлі комутації.
Поки без петлі. Іронія в тому, що такий вибух броадкаста можна забити канали передачі даних, особливо вузькі, наприклад, РРЛ. І тоді почнуть губитися дані користувача. А якщо заб'ються черзі пріоритетного трафіку CS6-CS7, в якому передаються пакети протоколів, то і STP може зламатися і ERPS зімкнути кільце — і утворюється цілком собі реальна петля комутації з наростаючим ефектом.
Якщо VPLS-домен не обмежено невеликою ділянкою мережі (а зазвичай це не так) прилягти може все.
Немає повісті сумнішої на світі, ніж шторм в VPLS-мережі.
Будь ласка, не робіть так.
В кінці я розповім про інших неприємних ситуаціях, які можуть виникнути в VPLS мережі.



Практика VPLS
Розберемо роботу VPLS на практиці по кроках ось за цією схемою. Це все та ж мережа, але тепер клієнт вирішив, що йому недостатньо двох точок, він хоче чотири і об'єднати їх в одну мережу.

Кликабельно.

Забули про те, що у нас до цього був сервіс VPWS — цій конфігурації більше немає.
Файл початкової конфігурації.


Отже на кроці 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
    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




  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)#default encapsulation
    

    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)#default encapsulation
    


    В режимі конфігурації інтерфейсу ми створюємо Service Instance — це прив'язка інтерфейсу до сервісів. Яким саме — налаштуємо пізніше. Номер Service Instance довільний — він локальнозначимый для інтерфейсу (як і у класичного сабинтерфейса).
    encapsulation default означає, що ми хапаємо всі кадри без розбору (а могли б вибирати по мітці VLAN або за фактом наявності двох підписів — QinQ, наприклад), тобто весь фізичний інтерфейс прив'язуємо до VFI.

    Хочу знати більше про Service Instance...Резонне питання від прихильників бритви Оккамы — навіщо якісь service instance — недостатньо просто bridge-domain прописати?
    Думка вірна, але service-instance — це «новий» підхід до концепції обробки тегированного трафіку і називається він EVC — Ethernet Virtual Circuit.
    Тут ми на хвилину перемкнемося на Ethernet-комутатори, щоб зрозуміти витоки появи цієї ідеї.

    Традиційно мітка VLAN використовувалася як для поділу трафіку в транках, так і для прийняття рішення про його комутації в межах пристрої.
    Тобто якщо з двох різних інтерфейсів прийшли два кадри з тегом 802.1 q 10, то вони обидва попадали в один VLAN 10 на комутаторі, відповідно опинялися в одному широкомовному домені. При цьому фізично не можна було прийняти на пристрої більше 4094 VLAN (якщо не вважати QinQ).
    Концепція EVC розділяє ці функції — тег 802.1 q раніше служить для поділу трафіку в транках, однак рішення про комутації тепер на боці 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 і російською.

  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...Bridge-domain це щось на зразок віртуального комутатора в межах одного пристрою. Якщо ви прив'яжете до одного brdige-domain пару фізичних інтерфейсів, то вони опиняться в одному широкомовному сегменті. Схоже на VLAN, але більш гнучке. Тобто, дослівно переводячи, це L2-місток між двома сутностями. У нашому випадку між фізичним інтерфейсом і VPLS.


    Конфігурація інших PE...

    Linkmeup_R3
    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
    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.
На певному обладнанні існує два способи налаштування VPLS Martini Mode. Інший зараз вважається застарілим, але допустимим. Замість команди l2vpn vfi context Blue використовується l2 vfi Blue. Головним чином різниця полягає в тому, що member змінюється на neighbor, а прив'язка до Bridge-domain робиться не у секції bridge-domain, а у власне секції vfi або на інтерфейсі в режимі налаштування Service instance.
Детальніше ви можете подивитися альтернативному файлі конфігурації VPLS Martini Mode.


Що сталося?

1. Відразу після цього встановлюються з'єднання LDP і відбувається обмін мітками. Технічно LDP досить прив'язки до bridge-domain — не обов'язково, щоб були AC-інтерфейси (це поведінка залежить від виробника.).

От обмін між Linkmeup_R1 і Linkmeup_R3:


FEC 63 — номер нашого VPN. Мітка виділена 0x18 (або 24).


Тобто, коли Linkmeup_R3 буде відправляти кадри в цьому VFI AC-інтерфейсу, підключеному до Linkmeup_R1, він повинен додати VPN-мітку 24. А транспортна при цьому — 17.


Зауважте, що різним сусідам Linkmeup_R1 видає різні мітки — це для того, щоб можна було коректно вивчити MAC-адреси потім.

2. Якщо запустити пінг з Blue-A, то в дампі (на інтерфейсі Gi1 Linkmeup_R1) можна побачити спочатку ARP-запит:



Оскільки він широкомовний, то слідом за ним можна побачити його точну копію з однією лише різницею — мітки VPN і транспортна:


Один кадр був відправлений на Linkmeup_R3, інший — на Linkmeup_R4.

3. В таблиці МАСов бачимо MAC-адреса вузла Blue-A (AABB-CC00-0700) — він знаходиться за портом GE3.EFP10 (Ethernet Flow Point і Service instance 10) — і MAC, відповідний IP-адресою 192.168.0.2 (AABB-CC00-0300) — за інтерфейсом Pseudoport Blue.100401a.


На жаль, встановити залежність між Pseudoport і pseudowire мені так і не вдалося. Як інженеру визначити, з якого PW вивчається MAC-адресу?
Наприклад show l2vpn vfi показує очевидне відповідність, але ці імена ніяк не перегукуються.


Якщо комусь вдасться простежити зв'язок між Pseudoport і pseudowire, ця стаття стане трішки повніше.


Природно, це все строго локально. Як і звичайні комутатори — VPLS не сигналізує повне mac ' і іншим PE, а займається їх вивченням виключно в рамках Data Plane.

Ще раз кроки налаштування:
  1. Створити VFI, з однаковим VPN ID на всіх PE і налаштувати зв'язність з усіма сусідами.
  2. Прив'язати AC-інтерфейси до Service Instance.
  3. Зв'язати VFI і Service Instance з допомогою Bridge-domain.


Отже підсумуємо про Martini mode:
  • Для сигналізації міток VPN використовується протокол LDP (метод DU).
  • Мітки використовуються раціонально — без якого-небудь запасу. Це дуже важливий момент, оскільки ресурс міток обмежений і легко може стати вузьким місцем.
  • Сусіди на кожному вузлі настроюються уручну. (Але до цього питання ми ще повернемося — все зовсім не так погано).
  • Масштабованість оригінального режиму Martini, строго кажучи, не велика — це обмеження повнозв'язної топології. Але й для цієї проблеми вже є рішення.



VPLS Kompella Mode (BGP)
Проблему пошуку сусідів вирішив Кирити Компелла — співробітник Juniper. Він відштовхувався від тих же критеріїв, але вирішив, що MBGP, випробуваний на L3VPN, краще підійде на роль протоколу розподілу міток.
Схема обміну маршрутною інформацією, одного разу розширена до VPNv4 маршрутів, цілком може бути застосована й для доставкою міток VPLS.
Механізм Route Target допоможе з автовизначенням сусідів.
А рут-рефлектори вирішать завдання реалізації повнозв'язної топології, яка гостро стоїть у Martini Mode.

Інша назва VPLS Kompella-mode — VPLS Auto-Discovery, тому що саме це є його якісною відмінністю від Martini. Також ви можете почути VPLS BGP Signaling.

Control Plane виконує тут дві основні функції:
— Виявлення сусідів
— Передача маршрутної інформації та обмін мітками.

Виявлення сусідів або Auto-Discovery
Нічого нового вигадувати тут не довелося. Схема виявлення сусідів вже застосована в L3VPN прекрасно працює і тут.
Route Target, який є Extended Community — головна ознака приналежності до певного VSI.
Грубо кажучи — якщо RT збігаються — значить в одному VSI.
Строго кажучи: Якщо RT отриманого анонсу збігається з налаштованим в VSI, значить цей VSI хоче знати інформацію з анонсу.
Як і в L3VPN можна гнучко організувати взаємодію між різними VSI. Але так украй рідко хто робить.

Трохи докладніше


Кожен VSI має свій RT.

У секції BGP для VPLS є своя Address Family: L2VPN AFI (25) і VPLS SAFI (65)
В ній налаштовується сусідство з абсолютно усіма PE, які можуть брати участь у якому-небудь VPLS-домені. Зауважте, тут без прив'язки до конкретного VSI.
Якщо використовуються RR, то сусідство піднімається тільки з ними.

Коли BGP хоче повідомити L2-префікс всім PE даного VSI, він висилає BGP Update всім налаштованим тут сусідам, знову ж таки незалежно від того, хочуть вони отримувати даний префікс чи ні. Тут все так само, як в L3VPN — там vpnv4-префікси теж розсилаються всім PE.
Коли віддалений PE отримує цей BGP Update, він перевіряє RT в поле NLRI і порівнює їх з тими, які налаштовані в його VSI.
Якщо збіг знайдено, PE імпортує цей префікс в потрібний VSI. Якщо ні — відкидає.
Ось так і реалізовано Auto-Discovery.
Тобто це не якась окрема фаза, щоб виявити всіх учасників VPLS-домену і скласти їх список, а просто механізм розпізнавання свій-чужий по відношенню до анонсу.

Передача префіксів
В цілому префікс L2VPN — річ досить штучна — PE своїм BGP Update, скоріше, повідомляє сам факт своєї участі в VPLS-домені і мітку цього факту. Але це не грає великої ролі.
Якогось адреси, тим більш повне mac ' а, в полі NLRI повідомлення BGP Update VPLS не передає. Пам'ятайте, що вивчення MAC-адрес — це повністю функція Data Plane.
Однак розрізняти анонси різних VSI все одно потрібно, тому знайомий нам Route Distinguisher теж присутня. Зазвичай він становить автоматично з номера AS і VPN ID.

Однак що ж передається в NLRI? Тільки мітка і RD?
Не зовсім:


Формально, префікс — це RD+порядковий номер вузла у VPLS-домені+блок міток.

Розподіл міток
Пам'ятаєте фразу "Хочеш нагодувати людину один раз — дай йому рибу. Хочеш нагодувати його на все життя — дай йому вудку"? Для виділення міток в VPLS Kompella mode використовується механізм блоків міток. Один PE іншому не повідомляє точне значення — він дає йому інформацію для її обчислення.

Я по собі я знаю, що намагатися зрозуміти що-то доки ти не знаєш, навіщо воно потрібно — шлях до несварению і витрачання зайвого часу. В кінці цієї глави я розповім, навіщо потрібна така дивна схема, а поки ви розбираєтеся, просто повірте мені і Кирити Компелле — потрібна.

Є думка, що відео перед текстом допомагає краще розібратися.



Якщо не вдаватися в конфігурацію, то виглядає це так:
  1. У кожному VSI налаштовується RD і RT — їх функції рівно ті ж самі, що в L3VPN. На CSR1000V це відбувається автоматично, не вимагаючи ручного налаштування.
    RD дозволяє розділяти інформацію різних VSI при передачі.
    RT дозволяє маршрутизатора-одержувачу визначити, в якій VSI потрібно цю інформацію транслювати.
    RD і RT пізніше будуть передаватися в повідомленні BGP Update.
  2. В секції BGP налаштовується нова адреса-фемілі L2VPN VPLS, всередині якої піднімається сусідство з усіма PE.
    Взагалі-то потрібно створити повнозв'язну топологію сусідства. Але ми ж пам'ятаємо, що механізм Route-Reflector'ів дозволяє обійти це вимог, встановивши сусідство тільки з одним RR (або декількома у разі кластера RR)?
  3. Під кожен VSI PE-маршрутизатор виділяє блок з простору міток. І ось тут-то і починається цікаве.
    В BGP Update від локального PE віддаленого передається наступна інформація:
    • RD
    • RT

    • Порядковий номер вузла у VPLS-домені.
    • Блок міток MPLS
      • VE ID
      • VE Block Offset

      • VE Block Size
      • Label Base
Нагадаю, що ЕVPLS Edge — межа мережі VPLS — PE-маршрутизатор на якому запущений VPLS.

Перш ніж я вдарюся у всі тяжкі про формули і значення, я вважаю себе зобов'язаним пояснити на пальцях загалом як це працює, тому що витратив купу часу і нервів, щоб розібратися.
Я щиро вірю, що RFC є джерелом безумовної ясності, але іноді в тому ж вигляді, в якому їм є формула еквівалентності маси і енергії для Ньютона.


Коли на PE приходить L2VPN кадр з боку MPLS мережі, потрібно точно знати, від якого він сусіда — це потрібно, щоб вивчити MAC-адресу, тому як і у випадку з режимом Martini основна ідея полягає в тому, що PE кожному сусідові в конкретному VSI повинен повідомити унікальну мітку, щоб бачити, від кого прийшов кадр.

Ось на такий простий картинці подивимося детальніше:


Нехай R1 за головного.
0. В Kompella mode R1 не передає мітку в явному вигляді своїм сусідам R2 і R3.
1. Замість цього він повідомляє їм з якогось діапазону потрібно мітки вибирати, щоб ідентифікувати даний VC.
2. У кожного РЕ є свій порядковий номер n VPLS-домені. Знаючи ваш номер і діапазон позначок, сусіди обчислюють вихідну сервісну мітку: відраховують n-шу за рахунком з початку. Тобто R2 взяв другу (2), а R3 — третю (3).
3. R2 і R3 повідомляють свої номери R1, і він теж обчислює, яка входить сервісна мітка буде від R2, яка від R3, відраховуючи від початку діапазону 2 і 3.
4. Аналогічно свої власні діапазони визначають R2 і R3 і повідомляють їх один одному і R1. І цикл обчислень повторюється.
5. В кінці кінців всі будуть знати і вихідні мітки для даного VPLS та вхідні.

Тепер друга ітерація: копнемо глибше, який матан лежить під цією простою ідеєю.

VE ID налаштовується вручну — це ідентифікатор PE-маршрутизатора в домені VPLS (його порядковий номер). Повинен бути унікальним у межах одного VSI.
LBLabel Base — це початок діапазону, перша мітка, яка може бути використана.
VBSVE Block Size — це довжина блоку міток, або простіше, мінімальна кількість міток в цьому VSI. Для Cisco за замовчуванням це 10. Для Juniper — 8 (може бути зменшений до 2 або збільшений).

Ось як буде виглядати набір тегів: {LB, LB+1, .., LB+VBS-1}.

Загалом, схема проста:

VE ID 100-109 взяті від балди для прикладу

На цій анімації показаний процес розподілу міток на PE1: Якщо PEX хоче відправляти трафік на PE1, він повинен використовувати відповідну мітку X.

Ось ще приклад для PE5:


Мітки виділяються по порядку — перша з блоку — сусідові з найменшим VE-ID. Друга — другого за величиною ітд.
Тобто така ситуація неможлива:


Однак якщо виділеного кількості міток мало, то допоможе параметр VBOVE Block Offset — зсув блоку. Він дозволяє створити декілька блоків. І тим сусідам, кому не вистачило, мітки розподіляються за тим же принципом, але з нового блоку, з новим LB.
Необхідний VBO обчислюється за формулою: VBO = ЦІЛЕ(VE-ID/VBS)*DOS.
Хочеться зауважити, що VBO — це не про зміщення міток, про це діапазон, в який потрапляє порядковий номер VE. Якщо потрапив у перший діапазон — береться перший блок міток, якщо другий — то другий ітд.
Таким чином у разі використання декількох блоків, набір міток буде виглядати так само, як і раніше {LB, LB+1,… LB+VBS-1}, але LB при цьому залежить від VBO. Тобто у нас зв'язка <LB, VBO, VBS>


Тобто маємо суворе відповідність: вузлу з VE ID (VBO+n) відповідає мітка (LB+n).

Третя ітерація — на реальному прикладі.

Візьмемо клієнта з десятьма сайтами.
VBS у нас стандартний — 10.
VE-ID відповідають номеру маршрутизатора: PE1 — 101, PE2-102,… PE 10 — 110.
Розглянемо як будуть взаємодіяти PE1 і PE5.

1. PE1 вибирає в якості Label 1000 Base — тобто 1000-1009 — це блок міток, з якого його сусіди зможуть взяти собі по одній.
2. PE1 обчислює VBO. VBO=ЦІЛЕ(101/10)*10=100.
3. PE1 передає збирає всі дані в BGP Update всім своїм сусідам: LB: 1000, VBS:10, VBO:100, VE-ID:101. Ну і всякі RD, RT, які нам зараз не цікаві.
Сам PE1 поки ніяких міток не вважає — він чекає Update від сусідів.
4. BGP Update від PE1 досягає PE5. Його VE-ID: 105. І зараз йому потрібно обчислити вихідну мітку для даного VSI (чий RT вказаний так само в BGP Update)в бік PE1.
5. Перше, що робить PE5 — перевіряє, а вміщується він у блок, анонсований PE1. Ось тут і знадобиться VBO. Повинно виконатися нерівність VBO ≤ PE5 VE-ID ≤ VBO+VBS-1. І воно виконується 100≤105≤109.
Поясню. PE1 обчислив, що його ID в діапазоні 100-109 (зі зміщенням 100 і довжиною 10) — відповідно всі вузли з VE ID з цього набору будуть вибирати одну з першого блоку.
6. Отже PE5 в межах анонсованого діапазону, тому він може йти далі і вирахувати свою вихідну мітку за формулою (PE1 LB + PE5 VE-ID — VBO) = (1000 + 105 — 100) = 1005.
Ще раз вся ця арифметика, означає, що від LB треба відлічити стільки міток, яким за рахунком йде VE-ID від VBO.
Значить, PE5, щоб відправити L2 кадр даного VSI на PE1 вставить в MPLS-заголовок VPN-мітку 1005.
PE1 поки не знає, про мітку 1005 — йому належить її обчислити, як це зробив PE5. А для цього потрібно дізнатися його VE ID.
7. Тепер PE5 теж повинен відправити BGP Update всім сусідам (технічно, не треба чекати 7 кроку — таку послідовність я взяв для прикладу. PE5 відправляє свій BGP Update як тільки все було налаштовано).
  • а. Вибрав LB, наприклад 5000.
  • б. Обчислив VBO = RND(105/10)*10=100.
  • ст. Скомпонував BGP Update. LB: 5000, VBS:10, VBO:100, VE-ID: 105.
  • р. Відправив його всім PE.
8. Коли PE1 дізнався VE-ID сусіда (BGP Update), він може порахувати входить мітку для даного сусіда і VSI.
І він робить те ж саме:
  • а. Перевіряє нерівність за отриманими VBO І VBS: VBO ≤ PE1 VE-ID ≤ VBO+VBS. 100≤101≤109. Відмінно.
  • б. Обчислює входить тег: (PE1 LB + PE5 VE-ID — VBO) = (1000 + 105 — 100) = 1005 — те ж саме число, що вважав і PE5 для вихідної мітки. Тобто коли PE1 отримає кадр з міткою VPN 1005, він буде знати відразу і те, яким VPN він призначений і від якого сусіда прийшов, тобто як вивчити його MAC, якщо необхідно.
9. Але це ще не все. PE1 повинен тепер знайти і вихідну мітку до PE5. І всі дані для цього в нього є.
(PE5 LB + PE1 VE-ID — VBO) = (5000 + 101 — 100) = 5001. Тобто PE1 при відправці кадрів в цей VSI до PE5 вставить у них VPN-мітку 5001.
10. PE5 обчислює входить: (PE5 LB + PE1 VE-ID — VBO) = (5000 + 101 — 100) = 5001.

Ось це я називаю взаємовиручкою!

На жаль, досить очевидний і в корені своєму логічний механізм я можу описати лише таким складним мовою.
Якщо ви ще не еволюціонували до розуміння механізму Label Block, поверніться до відео чотирма екранами вище.

Цікава доля PE10, яка зробить свій вплив на життя всіх інших PE.
Справа в тому, що він не вкладається в блок 100-109 зі своїм VE ID 110. Його VBO 110=ЦІЛЕ(110/10)*10. А як LB він вибрав 10000.
Коли PE10 надішле результати своїх калькуляцій PE5, нерівність не виконається: 110 ≤ 105 ≤ 119.
В цьому випадку запускається процес виділення нового блоку.
1. PE5 вибирає новий LB 5030, VBS вже вибраний PE10 — 10.
2. Маючи вже дані від PE10,
  • А. PE5 обчислює вихідну мітку до PE10: (PE10 LB + PE5 VE-ID — PE5 VBO) = (10000 + 101 — 100) = 10001. Зверніть увагу, що віднімається локальний VBO.
  • Б. Обчислює входить мітку від PE10: (PE5 New LB + PE10 VE-ID — PE10 VBO) = (5030 + 110 — 110) = 5030. Використовується новий LB і VBO PE10.

3. PE5 висилає PE10 новий BGP Update, анонсуючи вже два префікса: перший — старий, а другий — LB: 5030, VE ID: 105, VBS:10, VBO:110.
4. VE-ID PE10 в цей раз входить в новий діапазон 110-119,
  • А. тому він може обчислити вихідну мітку: (PE5 LB + PE10 VE-ID — PE10 VBO) = (5030 + 110 — 110) = 5030. Тобто PE10 при відправці кадру цього VSI на PE5 повинен вставити VPN-мітку 5030.
  • Б. Може він знайти і вхідну від PE5: (PE10 LB + PE5 VE-ID — PE5 VBO) = (10000 + 101 — 100) = 10001. Тут він використовує той VBO, в який входить PE5, а не PE10.
5. Кожен PE повинен буде виділити з другого блоку міток, щоб спілкуватися з PE10. Обчислення тривають.

Скрупульозне пояснення механізму Label Block від винуватців: Juniper.

І в цей момент має стати моторошно.
По-перше ми тільки що втратили 10 міток на КОЖНОМУ PE (9 не використано з другого блоку і одна мітка з першого — яка для самого цього PE).
По-друге, від того, як ми призначимо VE-ID, залежить, наскільки раціонально будуть використані мітки.
По-третє, ми повинні своїми власними руками налаштувати VE-ID і VE-range! Оцими ось руками, якими ми MPLS піднімали в пару команд!

Повинні бути дуже вагомі аргументи, чому протокол реалізований саме так, а не за аналогією з LDP або MBGP для L3VPN.

Знаєте, що з цього приводу говорить RFC 4761?
Using a distinct BGP Update message to send a demultiplexor to each
remote PE would require the originating PE to send N such messages
for N remote PEs. The solution described in this document allows a
PE to send a single (common) Update message that contains
demultiplexors for all the remote PEs, instead of N individual
messages. Doing this reduces the control plane load both on the
originating PE as well as on the BGP Route Reflectors that may be
involved in distributing this Update to other PEs.
Не дуже зрозуміло, які там навантаження на Control Plane.

Як це водиться в СДСМ, далі ви читаєте ексклюзив. Причому на цей раз, мабуть, не тільки рунетовського рівня, але і взагалі в усьому Інтернеті я не знайшов адекватного пояснення, навіщо ця система блоків була винайдена. Не смійтеся сильно, але я навіть писав Компелле, коли ні один з оточуючих мене CCIE не відповів на це питання.

Все це з-за такої бажаної функції Auto-discovery (про яку вже було вище) і специфіки L2, а саме вивчення MAC-адрес. І все буде зрозумілішим у порівнянні з L3VPN, де про призначення блоку міток ніхто навіть не думав.

Отже, як працює Auto-Discovery в L3VPN? Деякий PE страждет розповісти всьому світу про дві речі — по-перше, про те, які префікси він знає, по-друге про те, кому вони призначені. І він хоче розповісти про це всім без розбору — всі, хто є його MBGP сусідами отримають його Update, а по RT зрозуміють, цікаві їм ці анонси. На нема й суду нема — відкинуть. А якщо цікаві, то в свою таблицю маршрутизації VPN занесуть отриманий префікс і його VPN-мітку.

Все те ж саме вірно і для L2VPN. За винятком одного: вивчення MAC-адрес. BGP L3VPN повідомляє всім одну і ту ж мітку — йому абсолютно без різниці, звідки потім прийде пакет з даними, головна його турбота — передати його в правильний клієнтський інтерфейс.
Але не такий VPLS. Щоб у майбутньому відправляти дані конкретного сусіда, потрібно спочатку вивчити MAC-адреси клієнта, підключеного до цього сусіда. І зробити це можна тільки, якщо від різних сусідів приходять кадри з різними мітками.
І тут-то і криється диявол. В BGP Auto-Discovery відбувається в той же момент, що і анонс префікса.
І, по-перше, зовсім не в дусі BGP буде, якщо спочатку відсилати порожній Update з метою пошуку всіх учасників VPLS-домену, а потім окремо те ж саме, але з конкретними мітками кожному з них.
І навіть, якщо ви приймаєте «по-перше» (Фуфуфу), з'являється, «по-друге». По-друге, анонс конкретних міток знайденим сусідам. Гаразд, коли немає RR, і один PE може надіслати іншій Update адресно. Тоді кожен PE отримає тільки своє повідомлення і тільки свою мітку. Але реальність така, що RR стали її (реальності) частиною і, маючи сусідство тільки з RR, PE шле Update йому, а той розсилає всім своїм клієнтам. А якщо PE шле кілька Update ів, то вони всі розлетяться по всьому. Виходить, що кожен його сусід отримає не тільки свою мітку, але і всі інші, які йому даром не здалися.
Просто уявіть собі дамп у якому ви бачите сотню Update ів для лівих пристроїв.

І ось тут механізм автоматичного обчислення міток виходить на перший план, як дуже елегантне рішення цієї проблеми.
Тут варто віддати належне гнучкості думки Кирити Компеллы.

І знаєте, поки ця концепція блоку міток не сформувалася в несуперечливий набір синапсів в моєму мозку, я зневажливо ставився до неї. Вона здавалася мені грубій і застарілою. Приблизно, як DVMRP. Але тепер я перейнявся ідеєю і навіть дещо здивований тому, що чіткого пояснення ніде немає.

Зауважу також, що ситуацію з втраченими мітками кілька переглянули з випуском RFC 6624 (в якому, до речі, Компелла теж взяв безпосередню участь):
Label blocks and label values are managed by the PEs. As sites get
added and removed, labels are allocated and released. The easiest
way to manage these is to use fixed-size label blocks rather than
variable-size blocks, although the signaling described here supports
either. If an implementation uses fixed-size blocks, then allocating
a label for a new site may requiring allocating a new block;
similarly, freeing a label may require freeing a block.
If the implementation requires fixed-size blocks, there is probably a
default block size, but the implementation SHOULD allow the
administrator to choose a size. Larger label block sizes mean more
potential «wasted» labels but less signaling overhead, a trade-off
that the administrator might want to control.


І більше того, режим LDP-Signalling + BGP Auto-Discovery дозволяє поєднати переваги обох методів. Хоча і з'являється ось цей самий двокроковий механізм — спочатку вивчаємо сусідів, потім розсилаємо мітки.

Практика VPLS Kompella (BGP Signalling)
Залишаємося з тією ж мережею:


Попередня конфігурація знову очищається до початкової.
Файл початкової конфігурації.


  1. Створюємо VFI, як це робили в режимі Martini:
    Linkmeup_R1(config)#l2vpn vfi context Blue 
    Linkmeup_R1(config-vfi)#vpn id 63 
    Linkmeup_R1(config-vfi)#autodiscovery bgp signaling bgp 
    Linkmeup_R1(config-vfi-autodiscovery)#ve id 101

    Цей спосіб дозволяє налаштувати три типи VFI: ручний Martini з налаштуванням сусідів. BGP Autodiscovery + BGP Signalling, або BGP Autodiscovery + LDP Signalling.
    У нашому випадку ми вибрали обидва — BGP.

    Опціонально ми можемо задати кількість членів VPLS-домену. В cisco за замовчуванням — 10. Командою ve range Х можна збільшити від 11 до 100, але не зменшити. Huawei — за замовчуванням 10, можна змінювати (1-16000). Juniper — за замовчуванням 8, можна змінювати (2,4,8, 16...)
    Route Distinguisher і Route Target ми можемо не налаштовувати — вони будуть призначені автоматично. Хіба що вам хочеться дивного — об'єднати в один домен різні VFI.

    Далі я даю команду mpls label range 1000 10000. Вона глобально задає діапазон динамічно використовуваних міток. Взагалі кажучи цього робити не потрібно, оскільки так всім додаткам MPLS (LDP, TE, BGP) ми вказуємо, які мітки вибирати, а я не люблю комусь щось вказувати. Але я роблю це для більш наочної ілюстрації обчислення міток.

    Linkmeup_R1(config)#mpls label range 1000 1999
    Label range change will cause 
    5 labels in the old dynamic range [16-1048575] to go out of range

    Попередження говорить як раз про те, що розподілені перш транспортні мітки не вкладаються в новий діапазон.

  2. Прив'язуємо інтерфейси до Service Instance:
    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)#default encapsulation
    
    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 

  3. Пов'язуємо VFI і Service Instance.

    Linkmeup_R3(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

  4. Ну що ж, справа залишилася за малим — BGP.

    Спочатку піднімаємо базове сусідство з Linkmeup_R3 і Linkmeup_R4.
    Linkmeup_R1(config)#router bgp 64500 
    Linkmeup_R1(config-router)#neighbor 3.3.3.3 remote-as 64500
    Linkmeup_R1(config-router)#neighbor 3.3.3.3 update-source Loopback 0
    Linkmeup_R1(config-router)#neighbor 4.4.4.4 remote-as 64500
    Linkmeup_R1(config-router)#neighbor 4.4.4.4 update-source Loopback 0

    Потім створюємо Address-Family L2VPN VPLS і вказуємо сусідів, які будуть брати участь у L2VPN. Зауважте, не в конкретному VFI Blue, а взагалі.
    Linkmeup_R1(config-router)#address-family l2vpn vpls 
    Linkmeup_R1(config-router-af)#neighbor 3.3.3.3 activate 
    Linkmeup_R1(config-router-af)#neighbor 3.3.3.3 send-community extended 
    Linkmeup_R1(config-router-af)#neighbor 3.3.3.3 suppress-signaling-protocol ldp
    
    Linkmeup_R1(config-router-af)#neighbor 4.4.4.4 activate 
    Linkmeup_R1(config-router-af)#neighbor 4.4.4.4 send-community extended 
    Linkmeup_R1(config-router-af)#neighbor 4.4.4.4 suppress-signaling-protocol ldp

    Тут ви повинні пам'ятати, що зазвичай ми використовуємо Route Reflector'и — не потрібно налаштовувати всіх сусідів вручну, інакше сенс Auto-Discovery втрачається.
    Тобто якщо все PE-пристроїв в мережі MPLS — 100, в даному VPLS-домені — 20, а L2VPN RR — 2, то на кожному PE потрібно підняти сусідство тільки з цими двома RR.
    Ну ви ж не маленькі, щоб я вам про це розповідав?

    send-community extended — як і в L3VPN включаємо передачу Extended Community (RT).
    suppress-signaling-protocol ldp і забороняємо сигналізацію LDP.

    Ось що BGP знає про VPLS, ще навіть не маючи сусідів:


    Верхній рядок — це RD, вибраний автоматично: AS:VPN ID.
    Нижня — це префікс, який буде передаватися сусідам.

    Аналогічні маніпуляції виробляємо на Linkmeup_R3 і Linkmeup_R4.
    Конфігурація всіх PE

    Linkmeup_R1
    Linkmeup_R1(config)#l2vpn vfi context Blue 
    Linkmeup_R1(config-vfi)#vpn id 63 
    Linkmeup_R1(config-vfi)#autodiscovery bgp signaling bgp 
    Linkmeup_R1(config-vfi-autodiscovery)#ve id 101
    
    Linkmeup_R1(config)#mpls label range 1000 1999
    
    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
    
    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)#default encapsulation 
    
    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)#default encapsulation 
    
    
    Linkmeup_R1(config)#router bgp 64500 
    Linkmeup_R1(config-router)#neighbor 3.3.3.3 remote-as 64500
    Linkmeup_R1(config-router)#neighbor 3.3.3.3 update-source Loopback 0
    Linkmeup_R1(config-router)#neighbor 4.4.4.4 remote-as 64500
    Linkmeup_R1(config-router)#neighbor 4.4.4.4 update-source Loopback 0
    
    Linkmeup_R1(config-router)#address-family l2vpn vpls 
    Linkmeup_R1(config-router-af)#neighbor 3.3.3.3 activate 
    Linkmeup_R1(config-router-af)#neighbor 3.3.3.3 send-community extended 
    Linkmeup_R1(config-router-af)#neighbor 3.3.3.3 suppress-signaling-protocol ldp 
    Linkmeup_R1(config-router-af)#neighbor 4.4.4.4 activate 
    Linkmeup_R1(config-router-af)#neighbor 4.4.4.4 send-community extended 
    Linkmeup_R1(config-router-af)#neighbor 4.4.4.4 suppress-signaling-protocol



    Linkmeup_R3
    Linkmeup_R3(config)#l2vpn vfi context Blue
    Linkmeup_R3(config-vfi)#vpn id 63
    Linkmeup_R3(config-vfi)#autodiscovery bgp signaling bgp
    Linkmeup_R3(config-vfi-autodiscovery)#ve id 103
    
    Linkmeup_R3(config)#mpls label range 3000 3999
    
    Linkmeup_R3(config)#bridge-domain 255
    Linkmeup_R3(config-bdomain)#member vfi Blue
    Linkmeup_R3(config-bdomain)#member gigabitEthernet 3 service-instance 13
    
    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)#default encapsulation 
    
    Linkmeup_R3(config)#router bgp 64500
    Linkmeup_R3(config-router)#neighbor 1.1.1.1 remote-as 64500
    Linkmeup_R3(config-router)#neighbor 1.1.1.1 update-source Loopback 0
    Linkmeup_R3(config-router)#neighbor 4.4.4.4 remote-as 64500
    Linkmeup_R3(config-router)#neighbor 4.4.4.4 update-source Loopback 0
    
    Linkmeup_R3(config-router)#address-family l2vpn vpls 
    Linkmeup_R3(config-router-af)#neighbor 1.1.1.1 activate 
    Linkmeup_R3(config-router-af)#neighbor 1.1.1.1 send-community extended 
    Linkmeup_R3(config-router-af)#neighbor ppress-signaling-protocol ldp 
    Linkmeup_R3(config-router-af)#neighbor 4.4.4.4 activate
    Linkmeup_R3(config-router-af)#neighbor 4.4.4.4 send-community extended 
    Linkmeup_R3(config-router-af)#neighbor 4.4.4.4 suppress-signaling-protocol ldp



    Linkmeup_R4
    Linkmeup_R4(config)#l2vpn vfi context Blue
    Linkmeup_R4(config-vfi)#vpn id 63
    Linkmeup_R4(config-vfi)#autodiscovery bgp signaling bgp
    Linkmeup_R4(config-vfi-autodiscovery)#ve id 104
    
    Linkmeup_R4(config)#mpls label range 4000 4999
    
    Linkmeup_R4(config)#bridge-domain 255
    Linkmeup_R4(config-bdomain)#member vfi Blue
    Linkmeup_R4(config-bdomain)#member gigabitEthernet 3 service-instance 131
    
    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)#default encapsulation 
    
    Linkmeup_R4(config)#router bgp 64500
    Linkmeup_R4(config-router)#neighbor 1.1.1.1 remote-as 64500
    Linkmeup_R4(config-router)#neighbor 1.1.1.1 update-source Loopback 0
    Linkmeup_R4(config-router)#neighbor 3.3.3.3 remote-as 64500
    Linkmeup_R4(config-router)#neighbor 3.3.3.3 update-source Loopback 0
    
    Linkmeup_R4(config-router)#address-family l2vpn vpls 
    Linkmeup_R4(config-router-af)#neighbor 1.1.1.1 activate 
    Linkmeup_R4(config-router-af)#neighbor 1.1.1.1 send-community extended 
    Linkmeup_R4(config-router-af)#neighbor 1.1.1 suppress-signaling-protocol ldp 
    Linkmeup_R4(config-router-af)#neighbor 3.3.3.3 activate
    Linkmeup_R4(config-router-af)#neighbor 3.3.3.3 send-community extended 
    Linkmeup_R4(config-router-af)#neighbor 3.3.3 suppress-signaling-protocol ldp



    Для різних пристроїв я вказав різні mpls label range, щоб більш наочною була різниця між локальними і віддаленими мітками.

На цьому конфігурація MPLS Kompella Mode закінчена.
Файл конфігурації VPLS Kompella Mode.
Альтернативного методу, як у випадку з Martini тут немає.


Що сталося?

0. Зв'язність між CE вже з'явилася


1. BGP встановив сесії і розіслав свої Update ' и.


А в Update нас цікавить NLRI


Це Linkmeup_R1 повідомляє Linkmeup_R3, як обчислити VPN-мітку для трафіку, призначеного йому для VPLS з RT 65400:63.
CE-ID (він же VE ID)=101, VBO=100, VBS=10, LB=1000.



Це вже Linkmeup_R3 повідомляє Linkmeup_R1:
CE-ID=103, VBO=100,VBS=10, LB=3000


І ось Linkmeup_R4 повідомляє Linkmeup_R1:
CE-ID=104, VBO=100,VBS=10, LB=4000

Linkmeup_R1 на Linkmeup_R4 передав те ж, що і на Linkmeup_R3.

Давайте, не заглядаючи в таблиці міток на PE, порахуємо, які мітки будуть призначені?
Linkmeup_R3→Linkmeup_R1
Нерівність VBO ≤ Local VE ID ≤ VBO+VBS-1 виконується: 100≤103≤109.
Мітка: LB + Local VE ID — VBO = 1000+103-100=1003.
Мітку 1003 вставить Linkmeup_R3 в кадр, який хоче відправити на Linkmeup_R1 в цьому VFI.

Linkmeup_R1→Linkmeup_R3
Нерівність VBO ≤ Local VE ID ≤ VBO+VBS-1 виконується: 100≤101≤109.
Мітка: LB + Local VE ID — VBO = 3000+101-100=3001.
Мітку 3001 вставить Linkmeup_R1 в кадр, який хоче відправити на Linkmeup_R3 в цьому VFI.

Linkmeup_R1→Linkmeup_R4
Нерівність VBO ≤ Local VE ID ≤ VBO+VBS-1 виконується: 100≤101≤109.
Мітка: LB + Local VE ID — VBO = 4000+101-100=4001.

Linkmeup_R4→Linkmeup_R1
Нерівність VBO ≤ Local VE ID ≤ VBO+VBS-1 виконується: 100≤104≤109.
Мітка: LB + Local VE ID — VBO = 1000+104-100=1004.

Залишилося обчислити пару Linkmeup_R4→Linkmeup_R3 і Linkmeup_R3→Linkmeup_R4.
Linkmeup_R4→Linkmeup_R3
Нерівність VBO ≤ Local VE ID ≤ VBO+VBS-1 виконується: 100≤104≤109.
Мітка: LB + Local VE ID — VBO = 3000+104-100=3004.

Linkmeup_R3→Linkmeup_R4
Нерівність VBO ≤ Local VE ID ≤ VBO+VBS-1 виконується: 100≤103≤109.
Мітка: LB + Local VE ID — VBO = 4000+103-100=4003.

2. Звіримося з ситуацією на PE.




Ну, начебто, все правильно.

На жаль, в реальному житті таких красивих цифр не побачиш, там будуть нагромадження тарабарщини. Але з іншого боку, і вчитуватися в них вам особливо не доведеться — зазвичай, якщо мітка виділена, то вже не принципово, яка.

3. Відповідно, якщо зараз ми відправимо ping з Blue-A Blue-D, то повинні побачити VPN-мітку 3001 в ICMP-Request та 1003 у ICMP-Reply:


А в цей раз Wireshark чомусь розпізнав ICMP в MPLS



Ви як і раніше можете використовувати команди show mpls l2transport vc detail та show l2vpan atom vc detail для перегляду деталей:




Командою show bgp l2vpn vpls rd X ve-id Y block-offset Z ви можете вивести всю інформацію про блоці міток від цього сусіда.


А так подивитися утилізацію блоку міток:





Складність і кількість команд налаштування виглядає більше, ніж для режиму Martini, але треба пам'ятати, що
1) Це одноразова налаштування. При додаванні нового PE в VPLS-домен, налаштовувати треба тільки його (у випадку використання RR). Для Martini доведеться пройтися по всім існуючим PE цього VPLS-домену.
2) Конфігурація здебільшого однакова — змінюється тільки VE ID. Секція BGP взагалі береться копіпастом (у разі використання RR).

Ще раз повторимо кроки конфігурації:
  1. Налаштовуємо VFI, вказуючи VPN ID, протоколи, VE ID.
  2. Створюємо Service Instance на AC-інтерфейси.
  3. Пов'язуємо VFI і Service Instance через bridge-domain.
  4. В секції BGP піднімаємо сусідство з RR у Address-family L2VPN VPLS.


Теорія і практика VPLS Kompella mode на прикладі Juniper: російською для росіян.
Конфігурація та приклади обчислення міток: Сама cisco.



Matini vs Kompella
В результаті, які переваги дає використання BGP Kompella mode перед Martini Mode?
  • Auto-Discovery. Немає необхідності на кожному PE налаштовувати видалені LDP-сесії з усім учасниками цього VPLS-домену. При використанні RR питання повної зв'язності зовсім відпадає.
  • Разом з Auto-Discovery BGP підтримує і обмін префіксами/мітками. Це зазвичай ставиться в плюс методом, хоча це необхідна функція.
    Тут, ймовірно, краще помітити, що якщо в оператора вже є інфраструктура BGP, то L2VPN сигналізацією через BGP впишеться в неї органічно.
  • BGP все схоплено на предмет Inter-AS VPN. Option C дозволить організувати безшовний (seamless) MPLS між різними AS і протягнути через нього тисячі PW.


Однак чи все так очевидно? Копнемо глибше.

Міждоменні (Inter-AS) VPN не така вже велика складність для Martini при організації ієрархічного VPLS — тоді немає потреби створювати повнозв'язну топологію PE-пристроїв в VPLS-домені. Про H-VPLS ми ще поговоримо пізніше. Можемо викреслити це з його слабких сторін.

Що ж стосується настільки активно експлуатується Auto-Discovery в Kompella, то тут є два зауваження:
По-перше, вже давно для впровадження конфігурації використовуються зовнішні кошти. І ці зовнішні засоби можуть, проводячи аналіз конфігурації, знаходити сусідів та готувати сценарії для вузлів без ручної праці чорних інженерів.
Багато пропрієтарні системи управління підтримують цей функціонал. А мережі, в яких дійсно це потрібно зазвичай моновендорные і керуються такими NMS.
По-друге, RFC 4762 запроваджує механізм Auto-Discovery в режим Martini. Реалізований він може бути через RADIUS або через той же BGP.
Наприклад, обладнання cisco дозволяє налаштувати режим LDP + BGP Autodiscovery командою autodiscovery LDP signaling BGP в секції l2vpn vfi. З одного боку маємо простий і неизбыточный метод розподілу міток, з іншого механізм автоматичного пошуку сусідів (правда секцію BGP доведеться залишити).
Як б то ні було у Martini тепер є вирішення завдання виявлення сусідів і ще одне очко присуджується Гриффиндору.

Разом з дбайливим ставленням до мітках, простотою конфігурації та налагодження, Martini Mode не тільки не виглядає аутсайдером, але і, взагалі-то давно знайшов любов операторів. І сьогодні він займає переважну частку ринку.


Ну і під завісу ще одна оптимізація VPLS, яка робить життя трохи легше.

Ієрархічний VPLS (H-VPLS)
Спочатку VPLS — це плоска технологія — всі сусіди одного рангу. І якщо в Kompella mode RR в черговий раз ефективно вирішують проблему повнозв'язної топології, то Martini Mode в операторських мережах може викликати кризу робочої сили — усі інженери будуть тільки налаштовувати видалені LDP-сесії. Нагадаю складність завдання O(n^2): n*(n-1)/2, де n — число вузлів.



Така топологія приховує ще одну проблему — широкомовні кадри Ethernet — кожен пакет буде повторений стільки разів, скільки сусідів у даного PE.
А не можемо ми тут застосувати щось на зразок BGP-шних Route Reflector'ов?

Можемо. Наш шлях до порятунку — H-VPLS (Hierarchical VPLS), який описаний в RFC 4762.

H-VPLS поділяє маршрутизатори VPLS-домену на два рангу: PE-rs і MTU-s.
PE-rsPE — routing and switching. Це ядро мережі VPLS. Це великі продуктивні залозки, які функціонують як звичайні PE.
Інші назви PE-rs: PE-POP, n-PE.
MTU-sMulti-Tenant Unit — switching. Це можуть бути більш слабкі пристрої, які підключаються до PE-rs з одного боку. А з іншого до них підключаються CE.
Інші назви MTU-s: u-PE, PE-CLE.



MTU-s зазвичай мають висхідні інтерфейси до двох PE-rs — для відмовостійкості. Але може бути і один.
Механізми підключення MTU-s PE-rs: MPLS PW або QinQ. Оскільки ми тут про MPLS, то будемо розглядати тільки перший спосіб.

PE-rs між собою взаємодіють як звичайні PE, утворюючи повнозв'язну топологію і використовують правило розщеплення горизонту.
При взаємодії PE-rs і MTU-s, PE-rs сприймає PW від MTU-s як AC-інтерфейс, тобто, як пересічного клієнта.
А значить:
— Все, що PE-rs отримав від MTU-s він розсилає всім сусіднім PE-rs і всім підключеним MTU-s,
— Те, що PE-rs отримав від сусіднього PE-rs він розсилає всім підключеним до нього MTU-s, але не відправляє іншим PE-rs.

Таким чином, кожному MTU-s потрібно підтримувати зв'язок тільки з двома (або одним) сусідом, а кількість PE-rs досить невелика, щоб організувати між ними повнозв'язну топологію.
При додаванні нового вузла потрібно настроїти тільки його й вищий PE-rs.

Для організації Inter-AS VPN H-VPLS теж може стати в пригоді. Наприклад, два підключених один до одного ASBR можуть бути PE-rs більш високого рівня ієрархії.

Отже H-VPLS — це рішення трьох завдань:
  • Покращення масштабованості мережі в плані Contol Plane.
  • Оптимізація Data Plane за рахунок зменшення числа копій широкомовних кадрів.
  • Можливість ділити VPLS-домен на сегменти і ставити на доступ більш дешеве обладнання.


Так! Стоп, а що щодо MAC-таблиці на PE-rs?
Те, що в звичайному VPLS було P, H-VPLS стало PE, а відповідно, має займатися клієнтськими даними — вивчати MAC-адреси. Причому від всіх MTU-s, які до нього підключені. А разом з тим займатися розсилкою та реплікацією клієнтських кадрів.
Виходить, що, ввівши ієрархію на Control Plane ми форсували створення ієрархії і на Data Plane. Впоравшись з однією проблемою масштабованості, H-VPLS створив нову. Рахунок MAC-адрес в цьому випадку може йти на тисячі і сотні тисяч, питання флудинга встає на новому рівні, навантаження на CPU може значно зрости
Але рішення для цієї ситуації H-VPLS не пропонує.
Втім, здешевлення пристроїв рівня доступу, мабуть, цілком окупає цей легкий дискомфорт.

Ну що, спробуємо налаштувати?

Практика H-VPLS
Ми не будемо ускладнювати собі життя резервированиями і Dual-Homing'ом. Замість цього залишимося в рамках нашої ж топології, але Linkmeup_R1 стане MTU-s, а Linkmeup_R2 — PE-rs.


Знову знищуємо всю конфігурацію.
Файл початкової конфігурації.
Технічно H-VPLS може бути реалізований на базі режиму Kompella, але от такої необхідності немає, тому ми відштовхуємося від режиму Martini.

  1. Почнемо з зрозумілого — PE-rs. Зараз Linkmeup_R2, Linkmeup_R3 і Linkmeup_R4 виступають в якості PE-rs — між ними налаштовується повнозв'язна топологія у VFI.
    Linkmeup_R2(config)#l2vpn vfi context Blue
    Linkmeup_R2(config-vfi)# vpn id 63
    Linkmeup_R2(config-vfi)# member 3.3.3.3 encapsulation mpls
    Linkmeup_R2(config-vfi)# member 4.4.4.4 encapsulation mpls

    Інтерфейсів на Linkmeup_R2 немає, тому bridge-domain не потрібен.

    Конфігурація 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 2.2.2.2 encapsulation mpls
    Linkmeup_R3(config-vfi)# member 4.4.4.4 encapsulation mpls
    
    Linkmeup_R3(config-vfi)#bridge-domain 255
    Linkmeup_R3(config-bdomain)# member vfi Blue
    Linkmeup_R3(config-bdomain)# member gigabitEthernet 3 service-instance 13
    
    Linkmeup_R3(config-bdomain)#interface GigabitEthernet3
    Linkmeup_R3(config-if)# service instance 13 ethernet
    Linkmeup_R3(config-if-srv)# description Blue-D
    Linkmeup_R3(config-if-srv)# encapsulation default



    Linkmeup_R4
    Linkmeup_R4(config)#l2vpn vfi context Blue
    Linkmeup_R4(config-vfi)# vpn id 63
    Linkmeup_R4(config-vfi)# member 2.2.2.2 encapsulation mpls
    Linkmeup_R4(config-vfi)# member 3.3.3.3 encapsulation mpls
    
    Linkmeup_R4(config-vfi)#bridge-domain 255
    Linkmeup_R4(config-bdomain)# member vfi Blue
    Linkmeup_R4(config-bdomain)# member gigabitEthernet 3 service-instance 11
    
    Linkmeup_R4(config-bdomain)#interface GigabitEthernet3
    Linkmeup_R4(config-if)# service instance 13 ethernet
    Linkmeup_R4(config-if-srv)# description Blue-D
    Linkmeup_R4(config-if-srv)# encapsulation default




  2. На Linkmeup_R1 створюємо PW до Linkmeup_R2.
    Linkmeup_R1(config)#l2vpn xconnect context Blue_10
    Linkmeup_R1(config-xconnect)# member GigabitEthernet3 service-instance 10
    Linkmeup_R1(config-xconnect)# member 2.2.2.2 6310 encapsulation mpls

    Першою командою входимо в режим налаштування xconnect, наступними двома пов'язуємо AC-інтерфейс і VC-канал.
    ID 6310 довільний, але повинен співпадати з тим, який ми налаштуємо на PE-rs. Тут я вибрав 63 — як індикатор VPN ID, а 11 — порядковий номер VC на даному MTU-s.

    Налаштування інтерфейсу залишається колишньою:
    Linkmeup_R1(config-xconnect)#interface GigabitEthernet3
    Linkmeup_R1(config-if)# service instance 10 ethernet
    Linkmeup_R1(config-if-srv)#encapsulation default


    Для інтерфейсу Gi4 робимо те ж саме
    Linkmeup_R1(config)#l2vpn xconnect context Blue_10
    Linkmeup_R1(config-xconnect)# member GigabitEthernet4 service-instance 12
    Linkmeup_R1(config-xconnect)# member 2.2.2.2 6320 encapsulation mpls
    
    Linkmeup_R1(config-xconnect)#interface GigabitEthernet4
    Linkmeup_R1(config-if)# service instance 12 ethernet
    Linkmeup_R1(config-if-srv)#encapsulation default


  3. Залишилося терминировать ці PW на стороні Linkmeup_R2:
    Linkmeup_R2(config)#bridge-domain 255
    Linkmeup_R2(config-bdomain)# member vfi Blue
    Linkmeup_R2(config-bdomain)# member 1.1.1.1 6310 encapsulation mpls
    Linkmeup_R2(config-bdomain)# member 1.1.1.1 6320 encapsulation mpls

На цьому базова настройка H-VPLS Martini Mode закінчена.
Файл конфігурації H-VPLS



Що сталося?

PW піднялися


VFI на Linkmeup_R2 про них знає


Повне mac ' і відмінно вивчає


З H-VPLS з'являється ряд питань, які вже за рамками цієї статті:
  1. Резервування. Dual Homing MTU-s до двох PE-rs. Дуже поширений дизайн.
  2. H-VPLS з QinQ на доступі, замість MPLS PW.
  3. Технології захисту від петель і кидок STP BPDU через мережу VPLS.
Трохи привідкриють завісу над цими питаннями наступні два документи: H-VPLS PE-rs Redundancy for QinQ Access і Налаштування VPLS Multihoming на маршрутизатори Juniper tutorial.



А тепер пара історій про підступність L2 c механізмом широкомовних розсилок.

Випадок А
Загалом-то навіть не випадок — а то, як зазвичай це все працює.

Великий клієнт, багато трафіку. І ось трапляється щось страшне, і таблиця MAC-адрес очищається. І сотні дурнопахнущих мегабіт спрямовуються у всі кінці VPLS-домену. І на лініях, де раніше проходив тільки трафік даного філіалу цього клієнта, тепер летить все-все-все.

Підступність цієї ситуації полягає в тому, що це короткочасні сплески, які миттєво забивають черзі QoS, викликаючи втрати, незважаючи на ширину каналу. І ви навіть не побачите ці сплески в статистиці інтерфейсу, бо обладнання просто не встигло їх зафіксувати.

Випадок Б
Взагалі-то він вже був описаний раніше, так і схожий трохи на Випадок А. В цей раз просто дам більше деталей.
Ось така мережа:


Як бачите, тут філія великого клієнта підключений через вузький орендований канал з смугою пропускання 100 Мб/с. І як би їх за очі.
Але, трапляється щось страшне і таблиця MAC-адрес очищається. І весь трафік цього VSI, для якого не вивчений в даний момент MAC-адресу призначення, буде широковещаться. І якщо, наприклад, загальний трафік цього клієнта становив 400 Мб/с, то це 400 Мб/с флуду по всій мережі, яка упреться в 100 Мб/с орендованого каналу. Після чого послідують короткочасні втрати трафіку на час переизучения MAC-ів. А для великих мереж це може зайняти кілька хвилин.

Випадок В
Розширимо випадок Б. Тепер у нас на доступ не один клієнт, а кільце комутаторів. І одна лінія між ними виконана у вигляді РРЛ-прольоту. Ситуація не така рідкісна, враховуючи масштаби відстаней в нашій неосяжній, а, швидше, навіть типова.


В цілому, відбувається все те ж, що і у випадку Б, але при цьому у нас тут є ще якесь рішення по захисту від петель: STP або якийсь закритий протокол. Суть їх одна — заблокувати зайвий порт. А якщо щось не так зі зв'язністю, про яку вони судять по наявності і відсутності повідомлень, розблокувати.

Тепер наступний крок наших роздумів — флуд, який завалює вузькі лінії і веде до втрат пакетів. Якщо в цьому трафік велика кількість высокоприоритетных пакетів CS6/CS7, то будуть губитися і кадри протоколів. І тоді починається цирк — протокол відновлює лінк, тому що думає, що топології хана, і що відбувається? У відкритий порт спрямовується 100 Мб/с трафіку, який погіршує ситуацію.
Це все може і далі по наростаючій піти, чіпляючи за собою всі великі і великі ділянки мережі.

Випадок
Буква ця навіть трохи говорить. Тому що такий випадок не може відбутися просто так.
Ось така мережа.


Дизайн в даному випадку передбачає, що між двома PE прокинут додатковий PW для сигналізації протоколу захисту від петель (як і у випадку В). Точніше їх два — один через прямий лінк, інший окольний через MPLS-мережі.
Тобто ми отримуємо фізичне кільце комутаторів, розділене одним заблокованим портом.
Так, автор знає, що так мережі не будують. Так, автор знає про наслідки. Ні, автор, не брав участі у розробці дизайну.


І ще одна деталь — в різних кільцях є точки підключення одного і того ж клієнта, відповідно, у них спрямований один і той же VSI.

Тепер уявіть собі ситуацію, що приїхав величезний такий трактор і почав точково занурювати свій ківш на землю поки не порвав оптику відразу в двох місцях. Насправді досить згадати про плоскі кільця, і ситуація вже не здається такою неможливою.

Отже, коли обривають відразу два кінці одного кільця, PE виявляється ізольованим, відповідно всі його PW переходять у стан Down, в тому числі і службовий для протоколу захисту від петель. Протокол думає, що кільця зараз розімкнуті (а вони дійсно розімкнуті) і відновлює заблокований інтерфейс в обох кільцях. Відчуваєте вже засідку? у нас є два ланцюжки комутаторів, які закінчуються на двох PE і підключені до інтерфейсів, прив'язаним до одного і того ж VSI. Два розімкнутих фізичних кільця зростаються в одне замкнуте логічне кільце. І якщо один PE ізольований і не може нашкодити іншої частини мережі, то другий цілком собі в бою і починає злісно розсилати широкомовний трафік.


Випадок Д
Є мережа VPLS з двома центральними PE. Наприклад, це мережа DCI. ДЦ1 підключений до двох PE — так званий Dual Homing — режимі Ad/Ad — тобто обидва плеча можуть приймати і передавати трафік. При цьому комутація всередині не відбувається — тому петля виключена.


Все чудово, поки трафік в обох напрямках ходить через одне і те ж плече. Цікаве починається у разі асиметричного шляху. Наприклад, трафік до ДЦ1 приходить по лівому плечу, а йде по правому.
Загалом, нормальна ситуація. Але не для L2. PE1 буде вивчати MAC-адреси інших ДЦ — весь такий молодець, але трафік від ДЦ1 буде приходити на PE2, який ні сном ні духом про MAC-адреси. Відповідно, він буде отриманий трафік широковещать і привіт ситуації А-Ст.



Так, частина цих проблем — це непродуманий дизайн. Так, є ті або інші рішення», які дозволяють зменшити вірогідність і серйозність проблем, але Ethernet — як вода, скрізь просочиться. І головна проблема — в механізмі широкомовних розсилок — це ахілесова п'ята по всьому іншому прекрасного протоколу, який завоював світ.
Зараз, ймовірно, ви думаєте, що всі біди на світі від L2, у тому числі торішній землетрус в Непалі, і треба від нього йти, надаючи L3VPN. Що ж, де-то ви праві. Ніхто не мріє позбутися від нього так, як я, який пройшов через всі перераховані вище ситуації.
Однак це даність, від якої нікуди не дітися. І якщо ми не можемо прибрати корінь проблеми у вигляді механізму широкомовної розсилки в Ethernet, то можна придумати спосіб боротися з нею.
Про нього ми і поговоримо наступного разу — EVPN. Революційне рішення, яке переносить функцію вивчення MAC-адрес на Control Plane і залучає для цього BGP.




Корисні посилання
Акумулюю всі матеріали, що використовувалися у статті в одному місці. Акуратно: висока концентрація знань.

  • Весело задерикувато про MPLS взагалі: Тиць.
  • Коротко про мирне AToM'е: Тыц.
  • Опис роботи Компелла:Тиць.
  • Juniper про те, як працює механізм Label Block: Тыц і Мыц.
  • Конфігурація VPLS BGP на Cisco та приклади обчислення міток: Тыц.
  • Про Мартіні від Мартіні: Тыц.
  • Скрупульозне порівняння двох методів: Тиць.
  • Історична довідка за методами: Тыц.
  • Простими англійськими словами про H-VPLS: Тиць.
  • H-VPLS від циски, як завжди складно: Тыц.
  • H-VPLS Multihoming і STP по-російськи: Тиць.
  • Позакласне читання — EVPN: Тыц.


Концептуальні речі
Luc De Ghein. MPLS Fundamentals 1st Edition.
Ina Minei, Julian Lucek. MPLS-Enabled Applications: Emerging Developments and New Technologies 3rd Edition.

Також нагадую, що список кращих книг по мережам зараз тут.

Всі абревіатури, використані у статті ви можете знайти на глосарії linkmeup.

Подяки
Дмитру Фиголю (@sourg), Олександру Клипперу і Дмитру (@jdima) за вичитку матеріалу та коментарі.
Антону Клочкову за організацію лаби.
Дарині Кормановой за ілюстрації.
Моїй дружині і дітям, що відпустили мене у відрядження, де я і зробив все це.

Всі випуски11.1. Мережі для самих маленьких. Микровыпуск №6. MPLS L3VPN і доступ в Інтернет
11. Мережі для самих маленьких. Частина Одинадцята. MPLS L3VPN
10. Мережі для самих маленьких. Частина десята. Базовий MPLS
9. Мережі для самих маленьких. Частина дев'ята. Мультикаст
8.1 Мережі для Самих Маленьких. Микровыпуск №3. IBGP
8. Мережі для самих маленьких. Частина восьма. BGP і IP SLA
7. Мережі для самих маленьких. Частина сьома. VPN
6. Мережі для самих маленьких. Частина шоста. Динамічна маршрутизація
5. Мережі для самих маленьких: Частина п'ята. NAT і ACL
4. Мережі для самих маленьких: Частина четверта. STP
3. Мережі для самих маленьких: Частина третя. Статична маршрутизація
2. Мережі для самих маленьких. Частина друга. Комутація
1. Мережі для самих маленьких. Частина перша. Підключення до обладнання cisco
0. Мережі для самих маленьких. Частина нульова. Планування

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.