Чи потрібен VPNv4 MPLS у ядрі? Не обов'язково

BGP VPNv4 узгоджує контекст розподілу маршрутів, а не шлях пересилання. Відокремте імпорт, розв'язання наступного переходу та інкапсуляцію, яку ви можете запустити.

Увімкнення сімейства адрес VPNv4 між двома маршрутизаторами створює лише контекст розподілу маршрутів і нічого більше. Воно не встановлює шлях пересилання і не повідомляє, яка інкапсуляція понесе клієнтський пакет до віддаленої кінцевої точки. Коли ці два факти відокремлено, питання «чи потрібен тут MPLS у ядрі» стає вужчим і таким, на яке можна відповісти, питанням про площину даних, яку підтримує платформа.

Що насправді узгоджує сімейство адрес

Багатопротокольний BGP передає інформацію про досяжність мережевого рівня VPNv4 у межах AFI 1 і SAFI 128, і кожен запис зіставляє розрізнювач маршруту з префіксом і міткою. Сеанс узгоджує, що обидві сторони вміють кодувати й декодувати цю інформацію. Чого він не узгоджує, то це площини даних. Усе після цього абзацу стосується пересилання, і ніщо з цього не вирішується підняттям сеансу.

Отже, успішний сеанс є доказом можливостей площини керування, а не пересилання. Маршрутизатор може тримати тисячі записів VPNv4 і все одно відкидати кожен клієнтський пакет, і саме тому ці два класи відмов плутають із самого початку.

Зверніть увагу на мітку в NLRI. Це мітка служби, прив'язана до префікса всередині VRF, і вона має роль у пересиланні, коли пакет досягає вихідної кінцевої точки. Чи читає її якийсь транзитний пристрій — окреме проєктне рішення.

Приймання, імпорт і пересилання — це три кроки

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

Step in the chainWhat has to be trueHow it fails quietly
NLRI exchangeBoth speakers negotiate the VPNv4 capabilitySession stays up while the family is never activated
Import eligibilityA route target on the received route matches the VRF import policyThe route exists in the table but never enters the VRF
Next-hop resolutionThe advertised next hop resolves to a usable tunnel or label pathBest path is selected, then marked unreachable or unusable
EncapsulationThe egress endpoint can decapsulate what the ingress producedPackets arrive and are discarded for a format mismatch

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

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

IP-ядро може нести стек, який ніколи не комутує

Розрізнення, яке варто зберегти, — між «ядро не запускає MPLS» і «в службі ніде немає мітки». Це різні твердження, і лише перше стосується транзитних пристроїв. RFC 4023 визначає перенесення MPLS через тунелі IP або GRE, і саме цей механізм робить друге твердження можливим у повністю IP-ядрі.

customer packet + service label
  encapsulated in GRE, addressed to the egress tunnel endpoint
  forwarded by ordinary IP routers on the outer header
  decapsulated at the endpoint, label still meaningful

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

Чого цей проєкт вам не дає, то це універсальної гарантії. Це не доказ, що кожен маршрутизатор розв'язує кожен наступний перехід VPNv4 через будь-який інтерфейс GRE, і не причина видаляти робочу власну конфігурацію MPLS. Це контрприклад до універсального твердження, і практичне питання залишається локальним для платформи. Запишіть це питання як обмеження платформи, а не як правило протоколу.

Пройдіть ланцюг на пристрої, доки він не зламається

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

show bgp vpnv4 unicast all summary
show bgp vrf CUSTOMER_A ip route 198.51.100.0/24
show ip route vrf CUSTOMER_A 198.51.100.0
show mpls forwarding-table vrf CUSTOMER_A

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

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

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

Схожі статті