Политика на защитната стена в EVPN: централизиран шлюз срещу разпределен IRB

Два дизайна на EVPN поставят шлюза на наемателя на различни места и защитната стена вижда различен трафик при всеки. При централизиран шлюз трафикът между подмрежите стига до защитната стена, защото точно там се извършва маршрутизирането. При разпределен IRB листовите комутатори маршрутизират локално и защитната стена не вижда нищо, освен ако не я вмъкнете нарочно. Нито един модел не е грешен. Грешно е да закачите защитна стена на границата и да предполагате, че фабриката ще достави трафика до нея.

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

Първо назовете потоците, които се нуждаят от проверка, защото двата модела ги третират различно.

Трафикът в една и съща подмрежа е редът, който хората забравят. Два хоста в един VLAN говорят чрез мостово свързване и в този път не стои маршрутизираща защитна стена, освен ако отделен дизайн за проверка на Layer 2 не го прихване. Това е вярно и при двата модела, така че е празнина в дизайна, а не сравнение между тях.

Другите три реда са мястото, където моделите наистина се разминават.

Централизиран шлюз: проста проверка, реална цена на транзита

Запазете VLAN на наемателя като услуги от Layer 2 и поставете маршрутизиращите им шлюзове на защитната стена. Трафикът между подмрежите след това пътува до този шлюз и обратно, възможно дори когато двата хоста са на един и същ листов комутатор. Точката на проверка е еднозначна и това е целият аргумент за дизайна. Цената е транзитно натоварване на защитната стена плюс централна зависимост от капацитет и наличност, която сега трябва да проектирате.

Ограничете промяната до шлюзовете на наемателя, които възнамерявате. Премахването на всеки VLAN адрес е твърде широко, когато интерфейсите за управление, underlay и платформата имат отделни задачи. Проверете и за втори активен шлюз, защото такъв, който все още маршрутизира около защитната стена, тихо обезсмисля дизайна.

Този модел е по-лесен за обяснение пред одитор. Не е автоматично по-евтин за експлоатация.

Разпределен IRB: бърз път без проверка по подразбиране

При разпределени anycast шлюзове всеки листов комутатор маршрутизира трафика на наемателя локално и RFC 9135 описва защо това избягва връщането през централен шлюз. Ползата е реална и има пряка последица: проверката не може да се изведе от това къде е включена защитната стена. Защитна стена, свързана към граничен листов комутатор, вижда външния трафик и всичко, което изрично пренасочите към нея.

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

Четете инсталираните маршрути, а не предвидения по подразбиране. По-конкретен префикс на наемателя, импортиран директно, може да заобиколи маршрута по подразбиране, който сочи към защитната стена, и нищо в конфигурацията няма да изглежда грешно.

Симетрията е свойство на маршрутизирането, а не гаранция за проверка

Симетричният IRB описва как входящите и изходящите provider edge възли обработват маршрутизиране и мостово свързване за поток. Той не казва нищо за това дали двете посоки достигат до едно и също stateful устройство. ECMP, anycast и високата наличност на защитната стена влияят кой възел вижда върнатия трафик, а поддържаният модел на състояние на клъстера решава дали това е приемливо.

Проследявайте обратния път изрично за всеки поток, който ви интересува. NAT не е универсален заместител на тази работа и дизайните, които разчитат на него, обикновено откриват празнината по време на failover, а не по време на изграждането.

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

Как да изберете и какво да тествате и в двата случая

Изберете централизирания шлюз, когато покритието на проверката е по-важно от транзитния капацитет и можете да си позволите централната зависимост. Изберете разпределен IRB, когато локалното маршрутизиране е целта, и предвидете бюджет за изрично вмъкване на услуга, вместо да го предполагате.

След това тествайте маршрутизирането, което действително сте инсталирали, защото точно там двата дизайна се различават най-много:

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

Включете в теста отказ и възстановяване на сервизния възел. Резервен маршрут, който тихо заобикаля проверката, е различно решение от планирана политика fail-open и обикновено се има предвид само едно от двете. Завършеният дизайн посочва къде се маршрутизира всеки клас трафик, къде се проверява и какво се случва, когато този път за проверка е недостъпен.