Як працює MPLS VPN
Всім привіт. Сьогодні наша розмова піде про таку технологію, як MPLS VPN. У попередній статті мережа була цієї технології. Я демонстрував, як захищатися від флуду маршрутів з боку клієнта. У цій статті ми розберемо, як працює сама мережа.
Я трохи відступлю від звичайної схеми свого оповідання. Моя розповідь буде про те, що відбувається в мережі. А як що конфігурується, можна прочитати в конфіги в кінці статті, та й в інтернеті маса прикладів. Але ось що в інтернеті дуже складно знайти, так це поетапне опису, як така мережа працює, які етапи проходить пакет, чому не потрібно організовувати тунелі і найголовніше, як перевірити чи все правильно.
Отже, що ж це таке мультипротокольна комутація по мітках і чому вона краще маршрутизації? Основна суть полягає в тому, що між заголовками канального і мережевого рівнів (а в деяких стандартах на кшталт Frame Relay або ATM в заголовок канального рівня) маршрутизатором PE (Provider Edge) вставляється мітка і цей пакет пересилається наступному маршрутизатору MPLS або, як його ще називають, LSR (Label Switch Router). Отримавши такий пакет, LSR читає мітку і відповідно до таблиці змінює поточну мітку на мітку наступного стрибка в напрямку пункту призначення і відправляє пакет в потрібний інтерфейс, який також записаний в таблиці.
А вся сіль в тому, що немає ніякого вивчення таблиці міток. LSR відразу звертається до запису, порядковий номер якої в таблиці дорівнює значенню мітки. В результаті досягається дуже висока швидкість обробки потоку пакетів. Майже так само швидко, як комутація другого рівня. Майже, тому що заголовок другого рівня треба міняти все-таки і виробляти все зв'язкові з цим операції. Ще одне відносно вузьке місце - PE маршрутизатори, яким тепер не тільки таблицю маршрутизації вивчати потрібно при пересиланні пакетів, але ще і таблицю міток. Таким чином, виграючи в продуктивності в одному місці, втрачаємо в іншому. Але зате виграш в ядрі мережі дуже істотний, що і зумовило популярність MPLS у провайдерів.
Давайте тепер перейдемо ближче до справи і подивимося на практиці, як це працює. Для демонстрації заміни міток в процесі передачі пакетів додамо до нашої попередньої схемою ще два маршрутизатора. Навіщо - буде зрозуміло в процесі. Ось так тепер виглядає наша мережа.
Отже, у нас тут є CE маршрутизатори D_apad і D_Vostok, підключені до PE маршрутизаторів Zapad і Vostok. Маршрутизатор Yug1,2 і Sever1,2 зображують ядро мережі провайдера. Підключення клієнтів організовано з використання BGP (це не дуже важливо), а всередині мережі провайдера маршрутизація здійснюється з використанням OSPF (це важливо, спільно з LDP може працювати тільки IGP). Ну і нарешті, для розповсюдження влучний використовується LDP.
Трохи про поширення міток. Мітки призначаються на PE маршрутизаторах мереж записаним таблиці маршрутизації. Просто призначаються по порядку, починаючи з 16 (чому з 16 не важко буде знайти в інтернеті). Потім, з використанням LDP в даному випадку, інформація про призначені мітках передається на сусідні маршрутизатори, які в свою чергу призначають свої мітки для підмереж, переданих PE маршрутизаторами і передають їх далі вже з новими мітками. І так далі, і так далі. З першого разу може не зрозуміло. Прошу набратися терпіння, в процесі розповіді все стане ясно.
Подивимося на таблицю міток на маршрутизаторі Zapad.
Отже, що миздесь бачимо. Перший стовпець Local Label це і є список міток, який привласнив Маршрутизат подсетям з таблиці маршрутизації, і з цього стовпцю відбуватимуться звернення до таблиці, коли маршрутизатор отримає MPLS пакет.
Другий стовпець - виходить мітка. Це та мітка, яка буде присвоєна пакету, який скеровується в MPLS мережа. Pop Label позначає, що MPLS заголовок буде вирізаний, а пакет буде відправлений вузлу вказаною як Next Hop, який буде приймати рішення про його подальшу пересилання з використанням вже звичайною маршрутизацією. No Label в даному випадку означає, що MPLS на відповідних інтерфейсах не включений. І справді, обидві підмережі, у яких варто No Label відносяться до vrf Zapad, а там ні на одному інтерфейсі MPLS не включений.
Давайте тепер подивимося, які пригоди чекають пакет в процесі подорожі по мережі. Для цього ми пропінгуем інтерфейс lo0 на маршрутизаторі D_Vostok від імені інтерфейсу lo0 на маршрутизаторі D_Zapad. Подивимося, що нам покаже WireShark і розпитаємо маршрутизатори, чи не бреше він нам.
Все в порядку, мережа працює, пакети бігають. Дивимося, що показує наш сніфер.
Від маршрутизатора D_Zapad до маршрутизатора Zapad біжить абсолютно звичайний кадр Ethernet з IPv4 пакетом. Дивимося далі. Лінк між Zapad і Yug_1.
І тут ми бачимо цікаву річ. Замість одного заголовка MPLS ми бачимо два. Як же так вийшло? Йдемо на маршрутизатор Zapad і дивимося, що він з цього приводу може пояснити. Спочатку перевіряємо таблицю маршрутизації vrf Zapad, так як інтерфейс, на якому ми отримуємо наш пакет, належить саме цьому віртуальному маршрутизатора.
Отже, тут ми бачимо, що наша мережа призначення 192.168.20.1/32 знаходиться за вузлом 192.168.0.3, але ось маршруту до цього вузлу тут немає. Де ж його шукати? Оскільки у нас включений MPLS, будемо перевіряти таблицю передачі MPLS.
Добре. Тут розібралися. Але звідки взявся другий MPLS заголовок з міткою 24? Мітка 24 є, але вона вказує на вузол 192.168.0.2, а про нього жодної розмови і згадки не було.
Тут потрібно згадати заголовок статті, що у нас не тільки MPLS, але ще і VPN. Тобто, раз є два заголовка одного протоколу, значить є туннелирование, тобто мережу в мережі. І дійсно, vrf для клієнтів організовується саме для цього - зробити мережу в мережі.
Тут читач може поставити резонне питання. Ми ж MPLS на віртуальних Маршрутизатор не конфігурували. Логічніше було б побачити IP тунелювання. Звідки береться MPLS?
Тут мова йде про одне з розширень протоколу BGP - Multiprotocol BGP або MP-BGP. У конфіге bgp-процесу на маршрутизаторі Zapad є така секція:
Аналогічна є і на маршрутизаторі Vostok. Саме ця секція відповідає за включення MP-BGP між маршрутизаторами Zapad і Vostok і передачу маршрутів між vrf на цих маршрутизаторах. Як це працює, найкраще проілюструє debug bgp update. Для появи апдейта вимкнемо і включимо lo1 на D_Vostok.
У цьому висновку ми бачимо, що в рамках розширеного співтовариства (а простіше VPN мережі) RT: 1: 1000 (це той самий, який ми створювали командами import і export) отримано оновлення з новим маршрутом до підмережі 192.168.20.2/32, яка відноситься до RD 1: 100 і його мітка (цього маршруту) 29. Список всіх таких маршрутів з відповідними їм мітками:
Тепер видно, звідки взявся другий (а якщо бути точним, то перший) заголовок MPLS.
Подивимося, як пакети з мітками далі подорожують по мережі. Ось пакет між маршрутизаторами Yug_1 і Yug_2:
Ми бачимо, що змінився Ethernet заголовок (природно) і змінилася верхня мітка з одночасним зменшенням TTL. Що нам з цього приводу скаже маршрутизатор Yug_1:
Все вірно. Всі пакети з міткою 21 повинні отримати мітку 18 і відправлені вузлу 10.100.6.1 через інтерфейс Et1 / 1. Тобто ми бачимо, що MPLS мітка має локальне значення, тільки для даного маршрутизатора. Дійсно, якщо ми глянемо на таблицю пересилання маршрутизатора Zapad, то там ми теж знайдемо мітку 21. Тільки вказувати вона буде на зовсім іншу підмережу.
Але поки ми тут розводячись, наш пакет уже побіг далі і пройшов маршрутизатор Yug_2. Подивимося, що з ним сталося.
Тут ми бачимо, що залишився тільки один заголовок MPLS. Перевіряємо таблицю передачі на маршрутизаторі Yug_2.
Дійсно, якщо попадається пакет в міткою 18, то цю мітку потрібно вирізати. Але як же так, адже Yug_2 ще не PE маршрутизатор. Чому ж мітка вирізається тут?
А відбувається просто поділ навантаження. Підмережа 192.168.0.3/32 це вже наступний маршрутизатор (це повідомив OSPF), і виходить, що якщо на нього прийде пакет з міткою, доведеться виконувати подвійну роботу: і по MPLS таблиці обробити, і по таблиці маршрутизації. Навіщо це робити, якщо мітку може вирізати попередній маршрутизатор, а пакет все одно відправити за призначенням з використанням відповідного заголовка Ethernet кадру.
Саме це ми і спостерігаємо. Мітка вирізана, пакет відправлений вузлу 10.100.4.2 через інтерфейс Et1 / 1.
Що ж буде робити з цим пакетом маршрутизатор Vostok? Дивимося таблицю передачі:
Мітка 24 якраз і вказує нам, куди потрібно відправляти пакет. В даному випадку не потрібно ніяке проміжне дію, пов'язане з тим, що інтерфейс Et1 / 2 належить до vrf. Точно так само ми можемо, наприклад, задати статичний маршрут із зазначенням інтерфейсу. Незалежно від приналежності зазначеного інтерфейсу до якого-небудь vrf, пакет буде переданий. Те ж правило справедливо і для таблиці MPLS.
Перевіряємо, як виглядає пакет після маршрутизатора Vostok:
Ну ось, як і очікувалося, звичайний icmp пакет без жодних доповнень.
На цьому пригоди даного icmp-запиту закінчуються, а у вас, я сподіваюся, додалося розуміння, як працює MPLS VPN.
Авер'янов Кирило
network-lab.ru