EVPN-firewallbeleid: gecentraliseerde gateway versus gedistribueerde IRB

Twee EVPN-ontwerpen plaatsen de gateway van de huurder op verschillende plekken, en de firewall ziet in elk ontwerp ander verkeer. Met een gecentraliseerde gateway bereikt verkeer tussen subnetten de firewall, omdat daar de routering plaatsvindt. Met gedistribueerde IRB routeren de leaf-switches lokaal en ziet de firewall niets, tenzij je die er bewust in zet. Geen van beide modellen is fout. Fout is om een firewall aan de grens te hangen en aan te nemen dat de fabric het verkeer daarheen brengt.

Twee modellen, twee verschillende inspectiepunten

Noem eerst de stromen die inspectie nodig hebben, want de twee modellen behandelen ze verschillend.

Verkeer binnen hetzelfde subnet is de rij die men vergeet. Twee hosts op één VLAN praten via bridging, en er staat geen gerouteerde firewall op dat pad tenzij een apart inspectieontwerp voor laag 2 het onderschept. Dat geldt in beide modellen, dus het is een gat in het ontwerp en geen vergelijking tussen beide.

De andere drie rijen zijn waar de modellen echt uiteengaan.

Gecentraliseerde gateway: eenvoudige inspectie, echte transitkosten

Houd de VLAN's van de huurder als laag 2-diensten en plaats hun routeringsgateways op de firewall. Verkeer tussen subnetten reist dan naar die gateway en terug, mogelijk zelfs wanneer beide hosts op dezelfde leaf zitten. Het inspectiepunt is ondubbelzinnig, en dat is het hele argument voor het ontwerp. De kosten zijn transittbelasting op de firewall plus een centrale afhankelijkheid van capaciteit en beschikbaarheid die je nu moet ontwerpen.

Beperk de wijziging tot de huurder-gateways die je bedoelt. Elk VLAN-adres verwijderen is te breed wanneer beheer, underlay en platforminterfaces aparte taken hebben. Controleer ook een tweede actieve gateway, want een die nog steeds om de firewall heen routeert, ondermijnt het ontwerp stil.

Dit model is makkelijker uit te leggen aan een auditor. Het is niet automatisch goedkoper in beheer.

Gedistribueerde IRB: snel pad, standaard geen inspectie

Met gedistribueerde anycast-gateways routeert elke leaf het verkeer van de huurder lokaal, en RFC 9135 beschrijft waarom dat de terugvoer via een gecentraliseerde gateway vermijdt. Het voordeel is reëel, en het heeft een direct gevolg: inspectie valt niet af te leiden uit waar de firewall is aangesloten. Een firewall op een grens-leaf ziet extern verkeer en alles wat je er expliciet naartoe leidt.

Voeg de dienst in met een mechanisme dat het platform echt ondersteunt: beleidsgebaseerde omleiding, een servicenode of gecontroleerde routering tussen VRF's via de firewall. Laat het bedoelde verkeer op zijn werkelijke ingress punt matchen. Een beleid op een hostgericht interface dekt geen pakket dat uit de overlay komt.

Lees de geïnstalleerde routes in plaats van de bedoelde standaardroute. Een specifieker huurder-prefix dat direct wordt geïmporteerd kan de standaardroute omzeilen die naar de firewall wijst, en niets in de configuratie zal er fout uitzien.

Symmetrie is een routeringseigenschap, geen inspectiegarantie

Symmetrische IRB beschrijft hoe inkomende en uitgaande provider edge-nodes routering en bridging voor een stroom afhandelen. Het zegt niets over of beide richtingen hetzelfde stateful apparaat bereiken. ECMP, anycast en hoge beschikbaarheid van de firewall beïnvloeden allemaal welke node het retourverkeer ziet, en het ondersteunde toestandsmodel van de cluster bepaalt of dat acceptabel is.

Volg het retourpad expliciet voor elke stroom die ertoe doet. NAT is geen universele vervanging voor dat werk, en ontwerpen die daarop leunen vinden het gat meestal tijdens een failover en niet tijdens de bouw.

Loop één vereiste stroom en één bewust uitgesloten stroom door, in beide richtingen, voordat je het ontwerp goedkeurt.

Hoe te kiezen, en wat je in elk geval moet testen

Kies de gecentraliseerde gateway wanneer inspectiedekking belangrijker is dan transicapaciteit en je de centrale afhankelijkheid kunt veroorloven. Kies gedistribueerde IRB wanneer lokale routering het punt is, en begroot expliciete dienstinvoeging in plaats van die aan te nemen.

Test vervolgens de routering die je werkelijk hebt geïnstalleerd, want daar verschillen de twee ontwerpen het meest:

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

Neem uitval en herstel van de servicenode op in de test. Een terugvalroute die inspectie stil omzeilt is een andere beslissing dan een gepland fail-open-beleid, en meestal is slechts één van beide bedoeld. Het voltooide ontwerp benoemt waar elke verkeersklasse routeert, waar die wordt geïnspecteerd en wat er gebeurt als dat inspectiepad niet beschikbaar is.