EVPN политика на огнен ѕид: централизиран gateway наспроти распределен IRB

Два EVPN дизајни го поставуваат gateway-от на закупецот на различни места, а огнениот ѕид гледа различен сообраќај во секој. Со централизиран gateway, сообраќајот меѓу подмрежите стигнува до огнениот ѕид затоа што таму се врши рутирањето. Со распределен IRB, leaf комутаторите рутираат локално и огнениот ѕид не гледа ништо, освен ако намерно не го вметнете. Ниту еден модел не е погрешен. Погрешно е да се прикачи огнен ѕид на границата и да се претпостави дека fabric-от ќе му го достави сообраќајот.

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

Прво именувајте ги тековите што бараат проверка, зашто двата модели постапуваат со нив различно.

Сообраќајот во истата подмрежа е редот што луѓето го забораваат. Два хоста на еден VLAN разговараат преку мост, и на тој пат нема рутирачки огнен ѕид, освен ако не го пресретне посебен дизајн за проверка на слој 2. Тоа важи во двата модели, па затоа е празнина во дизајнот, а не споредба меѓу нив.

Останатите три реда се местото каде моделите навистина се разидуваат.

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

Задржете ги VLAN-ите на закупецот како услуги на слој 2 и ставете ги нивните рутирачки gateway-и на огнениот ѕид. Сообраќајот меѓу подмрежите потоа патува до тој gateway и се враќа, можеби дури и кога двата хоста се на истиот leaf. Точката на проверка е недвосмислена и тоа е целиот аргумент за дизајнот. Цената е транзитно оптоварување на огнениот ѕид плус централна зависност од капацитет и достапност што сега треба да ја проектирате.

Ограничете ја промената на gateway-ите на закупецот што ги намеравате. Отстранувањето на секоја VLAN адреса е премногу широко кога управувањето, underlay-от и интерфејсите на платформата имаат одделни задачи. Проверете и втор активен gateway, зашто оној што сѐ уште рутира околу огнениот ѕид тивко го поништува дизајнот.

Овој модел е полесно да се објасни на ревизор. Тој не е автоматски поевтин за работа.

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

Со распределени anycast gateway-и, секој leaf го рутира сообраќајот на закупецот локално, а RFC 9135 опишува зошто тоа го избегнува враќањето преку централизиран gateway. Придобивката е вистинска и има директна последица: проверката не може да се заклучи од тоа каде е приклучен огнениот ѕид. Огнен ѕид приклучен на граничен leaf гледа надворешен сообраќај и сѐ што експлицитно ќе го пренасочите кон него.

Вметнете ја услугата со механизам што платформата навистина го поддржува: пренасочување засновано на политики, сервисен јазол или контролирано рутирање меѓу VRF преку огнениот ѕид. Усогласете го предвидениот сообраќај на неговата вистинска влезна точка. Политика напишана на интерфејс кон хостовите не опфаќа пакет што доаѓа од overlay.

Читајте ги инсталираните рути, а не предвидениот стандард. Поточно префикс на закупецот увезен директно може да ја заобиколи стандардната рута што покажува кон огнениот ѕид, и ништо во конфигурацијата нема да изгледа погрешно.

Симетријата е својство на рутирањето, не гаранција за проверка

Симетричниот IRB опишува како влезните и излезните provider edge јазли се справуваат со рутирање и мост за еден тек. Тој не кажува ништо за тоа дали двете насоки стигнуваат до истиот stateful уред. ECMP, anycast и високата достапност на огнениот ѕид влијаат на тоа кој јазол го гледа повратниот сообраќај, а поддржаниот модел на состојба на кластерот одлучува дали тоа е прифатливо.

Следете го повратниот пат експлицитно за секој тек што ви е важен. NAT не е универзална замена за таа работа, а дизајните што се потпираат на него обично ја наоѓаат празнината за време на failover, а не за време на изградбата.

Поминете еден задолжителен тек и еден намерно исклучен тек во двете насоки пред да го одобрите дизајнот.

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

Изберете го централизираниот gateway кога покриеноста со проверка е поважна од транзитниот капацитет и можете да си ја дозволите централната зависност. Изберете распределен IRB кога локалното рутирање е поентата, и предвидете буџет за експлицитно вметнување услуга наместо да го претпоставите.

Потоа тестирајте го рутирањето што навистина сте го инсталирале, зашто токму таму двата дизајни најмногу се разликуваат:

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

Вклучете го во тестот откажувањето и обновувањето на сервисниот јазол. Резервната рута што тивко ја заобиколува проверката е поинаква одлука од планирана fail-open политика, и обично е наменета само една од двете. Завршениот дизајн именува каде рутира секоја класа сообраќај, каде се проверува и што се случува кога тој пат за проверка не е достапен.