Між AS VPNv4: що вимагає домовленість про пересилання міток

Читання мітки VPNv4 на граничному маршрутизаторі AS мало що дає, доки ви не знаєте, яку модель між AS реалізує передача. Мітка не є властивістю маршруту сама по собі; вона фіксує домовленість про інкапсуляцію та доставку між двома маршрутизаторами. Визначте модель, перш ніж читати показ. Інакше ви налагоджуєте домовленість, яку ніхто не записав.

Яку модель реалізує межа

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

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

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

Прочитайте один префікс від початку до кінця

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

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

Мітка локальна, і обіцянка також

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

RFC 4364 обмежує піринг VPNv4 з мітками довіреними схемами і застерігає від приймання міток, які ніколи не анонсувалися цьому піру. Це твердження про безпеку так само, як і про протокол. Тримайте відносини маршрутизації публічного інтернету подалі від обміну приватними маршрутами VPN. Якщо з'єднання — звичайний IP, не сподівайтеся, що якась мітка його переживе. А якщо лінк із мітками, підтвердьте, що зовнішня транспортна мітка правильно підміняється на кожному переході.

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

Що записати під час приймання

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

Ця нотатка дає наступному оператору змогу правильно прочитати той самий показ міток. Без неї модель виводять із конфігурації, а виведені припущення — це шлях повторення тієї самої помилки.Розділ RFC 4364 про між AS — те місце, де визначити, яку модель мали на увазі.