Kurkite EVPN ribą pagal eksporto politiką, o ne pagal prisijungimus

Įprasta prielaida, kad Layer 2 prisijungimo modelis prie ribos nulemia viską, kas yra virš jo, todėl projektavimas prasideda nuo vPC poros ir kyla aukštyn. Dažniausiai tai baigiasi atsitiktinai priimtais maršrutizavimo sprendimais. EVPN riba visų pirma yra maršrutizavimo riba: nuomininko maršrutizavimo kontekstas susitinka su išorine maršrutizavimo sritimi, o tai, kas kerta šią liniją, yra politikos pareiškimas. Pasirinkite maršrutus, ASN santykį ir gedimų kelius, kol niekas nepradėjo ginčytis dėl port-channels. Prisijungimo modelis tada išplaukia iš reikalavimo, o ne jį diktuoja.

Pradėkite nuo to, kas kerta ribą

Užrašykite maršrutus, kurie turi būti matomi kiekvienoje pusėje, jų judėjimo kryptį ir kas tvirtina to sąrašo pakeitimą. Riba, kuri priima viską ir skelbia viską, neturi politikos, tik kabelį.

Tada įvardykite gedimą, kurį ketinate eksploatuoti: vienas uplink neveikia, vienas border leaf neveikia arba visa išorinė sritis nepasiekiama. Kiekvienas atsakymas keičia, ar jums reikia dviejų nepriklausomų kaimynų, bendro Layer 2 prisijungimo, ar abiejų.

Tik kai egzistuoja šie du sąrašai, prisijungimo klausimas tampa atsakomas. Prieš tai kiekvienas mechanizmas atrodo vienodai tinkamas. Po to dauguma jų pasišalina savaime. Tai ir yra visas argumentas maršrutizavimo darbą atlikti pirmiausia.

Užfiksuokite ASN ir peering ribą

Fabric su privačiais AS paprastai daro peering su viešąja ribos sritimi per eBGP, o įdomioji dalis yra politika abiejose pusėse. Nuspręskite, kurie prefiksai priimami, kurie skelbiami ir kokį AS path turi gauti upstream.

RFC 6996 rezervuoja ASN diapazoną privačiam naudojimui, ir tie ASN neturėtų pasirodyti pasauliniuose skelbimuose. Taikykite platformos palaikomą šalinimo ar filtravimo politiką ir patikrinkite gautą skelbimą, o ne manykite, kad įrenginys tai padarė. Šis žingsnis taip pat nesuteikia teisės skelbti savavališko viešo prefikso, tai atskiras pokalbis su adreso savininku.

Konfederacija arba local-AS funkcija yra konkrečios topologijos projektinis pasirinkimas. Nė vienas nėra privalomas vien todėl, kad fabric ir upstream naudoja skirtingus ASN vaidmenis, o vieno priėmimas be reikalavimo prideda judančių dalių kiekvienam būsimam pakeitimui.

Layer 3 uplinkams nereikia multichassis LAG

Nepriklausomi maršrutizuoti sąsajos su savo BGP kaimynais duoda du aiškius kelius ir dvi aiškias gedimų sritis. vPC ar kitas multichassis LAG tarnauja Layer 2 prisijungimo reikalavimui, ir tai yra tinkamas įrankis, kai toks reikalavimas egzistuoja.

Bendroji taisyklė, kad kiekviena ribos pora turi naudoti vPC arba jo vengti, paslepia sąlygas, kurios iš tikrųjų nulemia atvejį. Paklauskite, ką prisijungimas turi nešti, tada pasirinkite mechanizmą, kuris tai neša su mažiausiai bendrų gedimų režimų.

Maršrutizavimo politika, kurią parašėte pirmą, nesikeičia, kai keičiasi prisijungimo mechanizmas, o tai geras ženklas, kad tvarka buvo teisinga.

Eksportuokite tik tai, ko reikia nuomininkui

Nuomininkui gali reikėti numatytojo maršruto, pasirinktų išorinių prefiksų rinkinio arba daug didesnės lentelės. Pasirinkite tą apimtį pagal realų persiuntimo ir valdymo plokštumos pajėgumą, o ne pagal seną interneto maršrutų skaičių, kurio niekas nepermatavo.

EVPN IP Prefix maršrutas, paprastai vadinamas Type 5 ir apibrėžtas RFC 9136dokumente, perneša prefikso informaciją overlay tinkle. Įgyvendinimui vis dar reikia atitinkančios eksporto ir importo politikos bei next-hop sprendimo, todėl išorinio BGP maršruto gavimas prie ribos nereiškia, kad kiekvienas nuomininko VRF jį importuoja.

Ne kiekvienam leaf reikia visos lentelės vien todėl, kad riba ją turi. Paskirstykite tai, ko reikalauja nuomininko srautas, o likusią dalį tegu turi riba.

Patikrinkite vieną prefiksą nuo pradžios iki pabaigos

Pasirinkite reprezentatyvų išorinį prefiksą ir sekite jį per numatytą ribos VRF, eksporto politiką, priimančio leaf persiuntimo kontekstą ir grįžimo kelią į nuomininko šaltinį. Prefiksas, kuris atsiranda vienoje vietoje, o ne kitoje, iškart lokalizuoja klaidą.

Patvirtinkite, kaip next hop išsprendžiamas per overlay, nes maršrutas, esantis su neišspręstu next hop, nieko nepersiunčia. Tada pakartokite patikrinimą po uplink pakeitimo, nes būtent tada politika ir next-hop sprendimas dažniausiai išsiskiria.

Darbo tvarka: išvardykite kertančius maršrutus, suderinkite ASN politiką, pasirinkite prisijungimą pagal jo tikrąją paskirtį, apibrėžkite eksporto apimtį kiekvienam nuomininkui ir galiausiai patikrinkite vieną prefiksą bei jo grįžimo kelią.