EVPN-brannmurpolitikk: sentralisert gateway kontra distribuert IRB

To EVPN-design plasserer leietakerens gateway på forskjellige steder, og brannmuren ser forskjellig trafikk i hvert av dem. Med en sentralisert gateway når trafikk mellom subnett frem til brannmuren fordi det er der rutingen skjer. Med distribuert IRB ruter leaf-svitsjene lokalt, og brannmuren ser ingenting med mindre du setter den inn med vilje. Ingen av modellene er feil. Det feil er å koble en brannmur på grensen og anta at fabric leverer trafikken til den.

To modeller, to forskjellige inspeksjonspunkter

Navngi først strømmene som trenger inspeksjon, fordi de to modellene behandler dem ulikt.

Trafikk innenfor samme subnett er raden folk glemmer. To verter på ett VLAN snakker via brokobling, og det sitter ingen rutet brannmur på den veien med mindre et eget inspeksjonsdesign for lag 2 fanger den opp. Det gjelder i begge modellene, så det er et hull i designet og ikke en sammenligning mellom dem.

De tre andre radene er der modellene faktisk skiller seg.

Sentralisert gateway: enkel inspeksjon, reell transittkostnad

Behold leietakerens VLAN-er som lag 2-tjenester og sett ruting-gatewayene deres på brannmuren. Trafikk mellom subnett reiser da til den gatewayen og tilbake, muligens også når begge vertene sitter på samme leaf. Inspeksjonspunktet er entydig, og det er hele argumentet for designet. Kostnaden er transittlast på brannmuren pluss en sentral avhengighet av kapasitet og tilgjengelighet som du nå må konstruere.

Begrens endringen til de leietaker-gatewayene du har til hensikt. Å fjerne hver VLAN-adresse er for bredt når administrasjon, underlay og plattformgrensesnitt har separate oppgaver. Sjekk også en annen aktiv gateway, fordi en som fortsatt ruter rundt brannmuren undergraver designet stille.

Denne modellen er lettere å forklare for en revisor. Den er ikke automatisk billigere å drive.

Distribuert IRB: rask vei, ingen inspeksjon som standard

Med distribuerte anycast-gatewayer ruter hver leaf leietakerens trafikk lokalt, og RFC 9135 beskriver hvorfor det unngår tilbaketransporten via en sentralisert gateway. Fordelen er reell, og den har en direkte konsekvens: inspeksjon kan ikke utledes fra hvor brannmuren er koblet til. En brannmur koblet til en grense-leaf ser ekstern trafikk og alt du eksplisitt omdirigerer til den.

Sett inn tjenesten med en mekanisme plattformen faktisk støtter: policybasert omdirigering, en tjenestenode eller kontrollert ruting mellom VRF-er gjennom brannmuren. Treff den tiltenkte trafikken på dens reelle inngangspunkt. En policy skrevet på et vertsvendt grensesnitt dekker ikke en pakke som kommer fra overlayet.

Les de installerte rutene i stedet for den tiltenkte standardruten. Et mer spesifikt leietaker-prefiks importert direkte kan omgå standardruten som peker på brannmuren, og ingenting i konfigurasjonen vil se feil ut.

Symmetri er en rutingegenskap, ikke en inspeksjonsgaranti

Symmetrisk IRB beskriver hvordan inngående og utgående provider edge-noder håndterer ruting og brokobling for en strøm. Det sier ingenting om hvorvidt begge retninger når samme stateful enhet. ECMP, anycast og brannmurens høye tilgjengelighet påvirker alle hvilken node som ser returtrafikken, og klyngens støttede tilstandsmodell avgjør om det er akseptabelt.

Følg returveien eksplisitt for hver strøm du bryr deg om. NAT er ikke en universell erstatning for det arbeidet, og design som lener seg på det finner vanligvis hullet under en failover og ikke under byggingen.

Gå gjennom én påkrevd strøm og én bevisst utelatt strøm, i begge retninger, før du godkjenner designet.

Hvordan velge, og hva du bør teste uansett

Velg den sentraliserte gatewayen når inspeksjonsdekning betyr mer enn transittkapasitet og du har råd til den sentrale avhengigheten. Velg distribuert IRB når lokal ruting er poenget, og budsjetter for eksplisitt tjenesteinnsetting i stedet for å anta den.

Test deretter rutingen du faktisk installerte, fordi det er der de to designene skiller seg mest:

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

Ta med tjenestenodens feil og gjenoppretting i testen. En reserve-rute som stille omgår inspeksjon er en annen beslutning enn en planlagt fail-open-policy, og vanligvis er bare én av dem tiltenkt. Det ferdige designet navngir hvor hver trafikkklasse ruter, hvor den inspiseres, og hva som skjer når den inspeksjonsveien ikke er tilgjengelig.