Du EVPN sprendimai nuomininko šliuzą talpina skirtingose vietose, o užkarda kiekvienu atveju mato skirtingą srautą. Esant centralizuotam šliuzui, srautas tarp potinkių pasiekia užkardą, nes būtent ten vyksta maršrutizavimas. Esant paskirstytajam IRB, leaf komutatoriai maršrutizuoja vietoje, o užkarda nieko nemato, nebent sąmoningai ją ten įterpsite. Nė vienas modelis nėra klaidingas. Klaidinga yra prijungti užkardą prie ribos ir manyti, kad fabric ją pasieks srautą.

Du modeliai, du skirtingi tikrinimo taškai

Pirmiausia įvardykite srautus, kuriems reikia tikrinimo, nes du modeliai juos traktuoja skirtingai.

Flow classCentralized gatewayDistributed IRB
Same subnetBridged, not routedBridged, not routed
Inter-subnetRouted at the firewallRouted at the leaf
Inter-VRFAt the firewallNeeds leaking or service insertion
ExternalBorder firewallBorder firewall

Srautas toje pačioje potinklyje yra eilutė, kurią žmonės pamiršta. Du mazgai viename VLAN kalbasi per tiltą, ir tame kelyje nėra maršrutizuojančios užkardos, nebent jį perimtų atskiras 2-ojo sluoksnio tikrinimo sprendimas. Tai galioja abiem modeliams, tad tai yra projektavimo spraga, o ne jų palyginimas.

Kitos trys eilutės yra ten, kur modeliai iš tiesų išsiskiria.

Centralizuotas šliuzas: paprastas tikrinimas, realios tranzito sąnaudos

Laikykite nuomininko VLAN kaip 2-ojo sluoksnio paslaugas ir įdėkite jų maršrutizavimo šliuzus į užkardą. Srautas tarp potinkių tada keliauja į tą šliuzą ir atgal, galbūt net kai abu mazgai yra tame pačiame leaf. Tikrinimo taškas yra vienareikšmis, ir tai yra visas šio sprendimo argumentas. Sąnaudos yra tranzito apkrova užkardai ir centrinė priklausomybė nuo pajėgumo bei prieinamumo, kurią dabar turite suprojektuoti.

Apribokite pakeitimą numatomais nuomininko šliuzais. Šalinti kiekvieną VLAN adresą yra per platu, kai valdymo, underlay ir platformos sąsajos turi atskiras pareigas. Patikrinkite ir antrą aktyvų šliuzą, nes tas, kuris vis dar maršrutizuoja aplink užkardą, tyliai panaikina sprendimą.

Šį modelį lengviau paaiškinti auditoriui. Jis nėra automatiškai pigesnis eksploatuoti.

Paskirstytasis IRB: greitasis kelias, pagal nutylėjimą jokio tikrinimo

Su paskirstytais anycast šliuzais kiekvienas leaf maršrutizuoja nuomininko srautą vietoje, o RFC 9135 aprašo, kodėl tai išvengia grąžinimo per centralizuotą šliuzą. Nauda yra reali, ir ji turi tiesioginę pasekmę: tikrinimo negalima nuspręsti iš to, kur užkarda prijungta. Užkarda, prijungta prie ribinio leaf, mato išorinį srautą ir viską, ką jai aiškiai nukreipiate.

Įterpkite paslaugą mechanizmu, kurį platforma iš tikrųjų palaiko: politikos pagrindu veikiančiu peradresavimu, paslaugos mazgu arba kontroliuojamu maršrutizavimu tarp VRF per užkardą. Suderinkite numatomą srautą jo tikrame įėjimo taške. Politika, parašyta į mazgus atgręžtoje sąsajoje, neapima paketo, ateinančio iš overlay.

Skaitykite įdiegtus maršrutus, o ne numatomą numatytąjį. Tikslesnis nuomininko priešdėlis, importuotas tiesiogiai, gali apeiti numatytąjį maršrutą, nukreiptą į užkardą, ir konfigūracijoje niekas neatrodys neteisingai.

Simetrija yra maršrutizavimo savybė, o ne tikrinimo garantija

Simetrinis IRB aprašo, kaip įeinantys ir išeinantys provider edge mazgai tvarko srauto maršrutizavimą ir tiltą. Jis nieko nesako apie tai, ar abi kryptys pasiekia tą patį būsenos įrenginį. ECMP, anycast ir didelis užkardos prieinamumas visi veikia tai, kuris mazgas mato grįžtamąjį srautą, o klasterio palaikomas būsenos modelis nusprendžia, ar tai priimtina.

Aiškiai sekite grįžimo kelią kiekvienam srautui, kuris jums svarbus. NAT nėra universalus to darbo pakaitalas, o sprendimai, kurie juo remiasi, spragą paprastai randa per failover, o ne statybos metu.

Prieš tvirtindami sprendimą, pereikite vieną privalomą ir vieną sąmoningai išbrauktą srautą abiem kryptimis.

Kaip pasirinkti ir ką tikrinti bet kuriuo atveju

Rinkitės centralizuotą šliuzą, kai tikrinimo aprėptis svarbesnė už tranzito pajėgumą ir galite sau leisti centrinę priklausomybę. Rinkitės paskirstytąjį IRB, kai vietinis maršrutizavimas yra esmė, ir numatykite biudžetą aiškiam paslaugos įterpimui, o ne manykite jį.

Tada išbandykite maršrutizavimą, kurį iš tikrųjų įdiegėte, nes būtent ten du sprendimai labiausiai skiriasi:

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

Į testą įtraukite paslaugos mazgo gedimą ir atkūrimą. Atsarginis maršrutas, kuris tyliai apeina tikrinimą, yra kitoks sprendimas nei suplanuota fail-open politika, ir paprastai numatomas tik vienas iš jų. Baigtas sprendimas įvardija, kur maršrutizuojamas kiekvienas srauto tipas, kur jis tikrinamas ir kas nutinka, kai to tikrinimo kelio nėra.

Susiję straipsniai