Будуйте межу EVPN навколо політики експорту, а не навколо підключень

Поширене припущення полягає в тому, що модель підключення Layer 2 на межі визначає все вище неї, тому проєктування починається з пари vPC і рухається вгору. Зазвичай це закінчується рішеннями про маршрутизацію, ухваленими випадково. Межа EVPN — це насамперед межа маршрутизації: контекст маршрутизації орендаря зустрічається із зовнішнім доменом маршрутизації, і те, що перетинає цю лінію, є заявою політики. Виберіть маршрути, відношення ASN і шляхи відмов, перш ніж хтось почне сперечатися про port-channels. Модель підключення потім випливає з вимоги, а не диктує її.

Почніть з того, що перетинає межу

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

Далі назвіть відмову, яку ви збираєтеся експлуатувати: один uplink недоступний, один border leaf недоступний або весь зовнішній домен недосяжний. Кожна відповідь змінює, чи потрібні вам два незалежні сусіди, спільне підключення Layer 2 або і те, і інше.

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

Зафіксуйте межу ASN і peering

Фабрика з приватними AS зазвичай встановлює peering із публічним доменом межі через eBGP, і цікава частина — політика з обох боків. Вирішіть, які префікси приймаються, які анонсуються і який AS path має отримати upstream.

RFC 6996 резервує діапазон ASN для приватного використання, і ці ASN не повинні з'являтися в глобальних анонсах. Застосуйте підтримувану платформою політику видалення або фільтрування та перевірте отриманий анонс, а не припускайте, що пристрій це зробив. Цей крок також не дає вам права анонсувати довільний публічний префікс — це окрема розмова з власником адрес.

Конфедерація або функція local-AS — це проєктне рішення для конкретної топології. Жодне з них не є обов'язковим лише тому, що фабрика й upstream використовують різні ролі ASN, а прийняття одного без вимоги додає рухомі частини в кожну майбутню зміну.

Uplink-и Layer 3 не потребують multichassis LAG

Незалежні маршрутизовані інтерфейси з власними сусідами BGP дають два чіткі шляхи й два чіткі домени відмов. vPC або інший multichassis LAG обслуговує вимогу підключення Layer 2 і є правильним інструментом, коли така вимога існує.

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

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

Експортуйте лише те, що потрібно орендарю

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

Маршрут EVPN IP Prefix, зазвичай званий Type 5 і визначений у RFC 9136несе інформацію про префікс в overlay. Реалізація все ще потребує узгодженої політики експорту та імпорту плюс розв'язання next-hop, тому отримання зовнішнього маршруту BGP на межі не означає, що кожен VRF орендаря його імпортує.

Не кожному leaf потрібна повна таблиця лише тому, що межа її тримає. Розподіляйте те, що вимагає трафік орендаря, а решту нехай тримає межа.

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

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

Підтвердьте, як next hop розв'язується через overlay, бо маршрут, наявний із нерозв'язаним next hop, нічого не пересилає. Потім повторіть перевірку після зміни uplink, адже саме тоді політика й розв'язання next-hop найчастіше розходяться.

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