RD проти RT в MPLS VPN: унікальність проти політики імпорту

Розрізнювач маршрутів робить перекривані префікси унікальними, а ціль маршруту визначає, які маршрути VRF може імпортувати. Простежте один маршрут MPLS в обох ролях.

Два клієнтські сайти можуть анонсувати 10.20.0.0/24, і обидва залишаються чинними в одній мережі провайдера. Розрізнювач маршрутів тримає ці анонси окремо; ціль маршруту вирішує, який клієнтський VRF може взяти копію. У конфігурації вони стоять поруч і виконують цілком різні завдання. Плутанина між ними призводить до змін, які виглядають розумно і нічого не виправляють.

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

Маршрут VPN-IPv4 — це RD плюс префікс IPv4

RFC 4364 визначає родину адрес VPN-IPv4 як восьмибайтовий розрізнювач маршрутів, за яким іде чотирибайтова адреса IPv4. RD додається перед клієнтським префіксом, тому два однакові префікси з різних сайтів стають двома різними маршрутами BGP.

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

Сам формат RD — це значення, яке вибирає адміністратор, зазвичай номер автономної системи та локальний номер. Його числова форма — це угода, а не ознака того, що два поля поділяють сенс із ціллю маршруту, яка випадково використовує ті самі цифри.

RD робить перекривані префікси розрізнюваними

Розгляньте два анонси одного й того самого префікса. Сайт A несе RD 65000:101, а сайт B несе RD 65000:202, обидва для 10.20.0.0/24. Тепер BGP має два маршрути VPN-IPv4, які можна незалежно порівнювати, фільтрувати й вибирати.

RD не каже, який VRF має отримати будь-який із цих маршрутів, і не ідентифікує клієнта чи послугу. Це поле ідентичності маршруту, а не список членства. Власний RD певного VRF не обов’язково має збігатися з RD маршруту, який він імпортує.

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

RT — це атрибут BGP, а не мітка в пакеті

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

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

Маршрут може нести кілька RT, а VRF може імпортувати кілька. Конфігурація часто виглядає як короткий блок:

vrf definition CUST-A
 rd 65000:101
 address-family ipv4
  route-target export 65000:500
  route-target import 65000:500

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

Право на імпорт — це не встановлення

Маршрут може бути прийнятним для VRF і все ж не з’являтися в його таблиці пересилання. Прийнятність — це фільтр; потім звичайний процес прийняття рішень BGP порівнює прийнятні маршрути й вибирає один. Старіший або менш бажаний маршрут може програти іншому прийнятному шляху.

Перевіряйте вибраний маршрут, а не лише політику імпорту. VRF, який імпортує RT 65000:500 і не показує маршруту для 10.20.0.0/24, міг отримати маршрут і відхилити його під час вибору, або не отримати його взагалі.

Ця різниця важлива й тоді, коли з’являється несподіваний префікс. Занадто широка політика імпорту може притягнути маршрути, які сайт не планував використовувати, і унікальність RD цьому аж ніяк не перешкоджає. Обсяг розповсюдження — це питання політики RT.

Знайдіть відсутній маршрут у порядку площини керування

Почніть з анонсу: чи експортує джерельний VRF потрібний RT і чи існує маршрут як маршрут VPN-IPv4 на відбивачі маршрутів або на приймальному PE? Потім перевірте атрибут таким, яким його отримано, а не таким, яким він налаштований у відправника.

Далі порівняйте список імпорту приймального VRF з фактичними значеннями RT маршруту. Насамкінець огляньте вибраний маршрут у цьому VRF і прив’язку мітки. Кожен крок відповідає на інше питання, а стрибок до RD зазвичай пропускає саме помилковий крок.

Запишіть RD, експортований RT, імпортований RT і вибраний наступний хоп для робочого та несправного сайту. Чотири значення поруч перетворюють розпливчасте «VPN не передає маршрути» на точний крок площини керування, який відрізняється.

Схожі статті