Передача L3VPN: приватні маршрути, маршрут за замовчуванням чи повна таблиця?

Ваш канал піднято, VRF налаштовано, і провайдер ставить коротке питання, яке визначає решту проєкту: що має отримати клієнтський край? Три відповіді поширені, і жодна не випливає з того, що існує стек міток. Це сервісні рішення про те, звідки трафік залишає філію.

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

Почніть із трафіку, який ніхто не планував

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

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

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

Запишіть приватні префікси разом зі сценарієм відмови

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

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

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

Перевірте, що CE справді встановив

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

show ip bgp vpnv4 vrf BRANCH neighbors 192.0.2.1 received-routes
show ip bgp vpnv4 vrf BRANCH
show ip route vrf BRANCH 0.0.0.0

Виконайте всі три в день передачі, а не через місяць, поки хтось ще пам'ятає, про що домовилися. Перший вивід залежить від soft-reconfiguration inbound або збереженого оновлення маршрутів; без одного чи іншого CE не може показати, що він відхилив. Другий показує прийняті та найкращі маршрути після політики. Третій каже, куди маршрут за замовчуванням іде насправді, і це найкорисніший рядок у всій передачі.

Виконайте ті самі перевірки на другому CE, якщо майданчик підключено двома лініями. Асиметричне прийняття між двома краями — часта причина "працює з одного сервера і не працює з іншого", і воно непомітне в різниці конфігурації, яка виглядає симетричною.

Оцініть більший потік, а не припускайте його

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

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

Специфікація BGP/MPLS IP VPN розглядає кілька схем доступу до інтернету поряд із самим сервісом VPN і не оголошує повну таблицю чи маршрут за замовчуванням обов'язковими для кожного клієнта, і саме на цей розділ варто вказувати, коли з'являється твердження про "стандартну практику": RFC 4364.

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