Політика міжмережевого екрана в EVPN: централізований шлюз проти розподіленого IRB

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

Дві моделі, дві різні точки перевірки

Спершу назвіть потоки, яким потрібна перевірка, бо дві моделі обробляють їх по-різному.

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

Решта три рядки — там, де моделі справді розходяться.

Централізований шлюз: проста перевірка, реальна вартість транзиту

Тримайте VLAN орендаря як сервіси рівня 2 і розмістіть їхні маршрутизуючі шлюзи на міжмережевому екрані. Трафік між підмережами тоді йде до цього шлюзу й назад, можливо, навіть коли обидва хости на одному leaf. Точка перевірки однозначна, і це весь аргумент схеми. Ціна — транзитне навантаження на міжмережевому екрані плюс центральна залежність від ємності й доступності, яку тепер треба спроєктувати.

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

Цю модель легше пояснити аудитору. Вона не стає автоматично дешевшою в експлуатації.

Розподілений IRB: швидкий шлях, типово без перевірки

З розподіленими anycast-шлюзами кожен leaf маршрутизує трафік орендаря локально, і RFC 9135 описує, чому це уникає повернення через централізований шлюз. Вигода реальна, і в неї є прямий наслідок: перевірку не можна вивести з того, куди під'єднано міжмережевий екран. Міжмережевий екран, під'єднаний до граничного leaf, бачить зовнішній трафік і все, що ви явно скеровуєте до нього.

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

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

Симетрія — властивість маршрутизації, а не гарантія перевірки

Симетричний IRB описує, як вхідні та вихідні вузли provider edge обробляють маршрутизацію й мостове з'єднання для потоку. Він нічого не каже про те, чи обидва напрямки доходять до одного й того самого пристрою зі станом. ECMP, anycast і висока доступність міжмережевого екрана впливають на те, який вузол бачить зворотний трафік, а підтримувана модель стану кластера вирішує, чи це прийнятно.

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

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

Як вибирати і що перевіряти в будь-якому разі

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

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

show ip route vrf TENANT 10.20.0.0/16
show bgp l2vpn evpn route-type prefix

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