EVPN-brandmuurbeleid: gesentraliseerde gateway teenoor verspreide IRB
Gesentraliseerde gateways stuur die huurder se verkeer deur die brandmuur; verspreide IRB doen dit nie. Vergelyk waar elkeen ondersoek, en wat die vinnige pad nodig het.
Twee EVPN-ontwerpe plaas die huurder se gateway op verskillende plekke, en die brandmuur sien in elkeen andersoortige verkeer. By 'n gesentraliseerde gateway bereik verkeer tussen subnetwerke die brandmuur, want dit is waar die routering plaasvind. By verspreide IRB routeer die leaf-skakelaars plaaslik en die brandmuur sien niks, tensy jy dit doelbewus daar insteek. Nie een model is verkeerd nie. Wat verkeerd is, is om 'n brandmuur by die grens aan te bring en te aanvaar dat die fabric die verkeer daarheen sal aflewer.
Twee modelle, twee verskillende ondersoekpunte
Noem eers die vloei wat ondersoek moet word, want die twee modelle hanteer hulle verskillend.
| Flow class | Centralized gateway | Distributed IRB |
|---|---|---|
| Same subnet | Bridged, not routed | Bridged, not routed |
| Inter-subnet | Routed at the firewall | Routed at the leaf |
| Inter-VRF | At the firewall | Needs leaking or service insertion |
| External | Border firewall | Border firewall |
Verkeer binne dieselfde subnet is die ry wat mense vergeet. Twee hosts op een VLAN praat deur bridging, en geen geroteerde brandmuur sit in daardie pad nie, tensy 'n aparte Laag 2-ondersoekontwerp dit onderskep. Dit geld in beide modelle, dus is dit 'n leemte in die ontwerp eerder as 'n verskil tussen hulle.
Die ander drie rye is waar die modelle werklik verskil.
Gesentraliseerde gateway: eenvoudige ondersoek, werklike deurvoerkoste
Hou die huurder se VLAN's as Laag 2-dienste en plaas hul routeringsgateways op die brandmuur. Verkeer tussen subnetwerke reis dan na daardie gateway en terug, moontlik selfs wanneer beide hosts op dieselfde leaf sit. Die ondersoekpunt is ondubbelsinnig, en dit is die hele argument vir die ontwerp. Die koste is deurvoerlas op die brandmuur plus 'n sentrale kapasiteit- en beskikbaarheidsafhanklikheid wat jy nou moet ingenieurs.
Beperk die verandering tot die huurder-gateways wat jy beoog. Om elke VLAN-adres te verwyder is te breed wanneer bestuur, underlay en platform-koppelvlakke aparte take het. Kyk ook vir 'n tweede aktiewe gateway, want een wat steeds om die brandmuur routeer, verydel die ontwerp stilweg.
Hierdie model is makliker om aan 'n ouditeur te verduidelik. Dit is nie outomaties goedkoper om te bedryf nie.
Verspreide IRB: vinnige pad, geen ondersoek by verstek
Met verspreide anycast-gateways routeer elke leaf die huurder se verkeer plaaslik, en RFC 9135 beskryf waarom dit die terugvoer van 'n gesentraliseerde gateway vermy. Die voordeel is werklik, en dit het 'n direkte gevolg: ondersoek kan nie afgelei word uit waar die brandmuur ingeprop is nie. 'n Brandmuur wat aan 'n grens-leaf gekoppel is, sien eksterne verkeer en alles wat jy doelbewus daarheen herlei.
Voeg die diens in met 'n meganisme wat die platform werklik ondersteun: beleidsgebaseerde herleiding, 'n diensnode, of beheerde routering tussen VRF's deur die brandmuur. Pas die beoogde verkeer by sy werklike ingangspunt. 'n Beleid wat op 'n host-gerigte koppelvlak geskryf is, dek nie 'n pakket wat uit die overlay aankom nie.
Lees die geinstalleerde roetes eerder as die beoogde verstek. 'n Meer spesifieke huurder-prefiks wat direk ingevoer word, kan die verstekroete wat na die brandmuur wys, omseil, en niks in die konfigurasie sal verkeerd lyk nie.
Simmetrie is 'n routeringseienskap, nie 'n ondersoekwaarborg nie
Simmetriese IRB beskryf hoe inkomende en uitgaande provider-edge-nodes routering en bridging vir 'n vloei hanteer. Dit se niks oor of beide rigtings dieselfde stateful toestel bereik nie. ECMP, anycast en brandmuur-hoe beskikbaarheid beinvloed almal watter node die terugverkeer sien, en die cluster se ondersteunde toestandmodel besluit of dit aanvaarbaar is.
Volg die terugpad eksplisiet vir elke vloei wat vir jou saak maak. NAT is nie 'n universele plaasvervanger vir daardie werk nie, en ontwerpe wat daarop leun, vind die leemte gewoonlik tydens 'n failover eerder as tydens die bou.
Stap een vereiste vloei en een doelbewus uitgeslote vloei deur, in beide rigtings, voordat jy die ontwerp goedkeur.
Hoe om te kies, en wat om in elk geval te toets
Kies die gesentraliseerde gateway wanneer ondersoekdekking belangriker is as deurvoerkapasiteit en jy die sentrale afhanklikheid kan bekostig. Kies verspreide IRB wanneer plaaslike routering die punt is, en begroot vir eksplisiete diensinvoeging in plaas daarvan om dit te aanvaar.
Toets dan die routering wat jy werklik geinstalleer het, want dit is waar die twee ontwerpe die meeste verskil:
show ip route vrf TENANT 10.20.0.0/16
show bgp l2vpn evpn route-type prefixSluit diensnode-faling en herstel by die toets in. 'n Terugvalroete wat stilweg die ondersoek omseil, is 'n ander besluit as 'n beplande fail-open-beleid, en gewoonlik is net een van die twee bedoel. Die voltooide ontwerp noem waar elke verkeersklas routeer, waar dit ondersoek word, en wat gebeur wanneer daardie ondersoekpad onbeskikbaar is.