Bygg EVPN-grensen rundt eksportpolicy, ikke tilkoblinger

Den vanlige antakelsen er at Layer 2-tilkoblingsmodellen ved grensen bestemmer alt over den, så designet starter med et vPC-par og arbeider oppover. Det ender som regel med rutingsbeslutninger som blir tatt ved en tilfeldighet. En EVPN-grense er først og fremst en rutingsgrense: en leietakers rutingskontekst møter et eksternt rutingsdomene, og det som krysser den linjen, er en policysetting. Velg rutene, ASN-forholdet og feilveiene før noen begynner å krangle om port-channels. Tilkoblingsmodellen følger deretter av et krav i stedet for å diktere et.

Begynn med det som krysser grensen

Skriv ned rutene som skal være synlige på hver side, retningen de går i, og hvem som godkjenner en endring i den listen. En grense som aksepterer alt og annonserer alt, har ingen policy, bare en kabel.

Navngi så feilen du har tenkt å drive med: én uplink nede, én border leaf nede, eller hele det eksterne domenet utilgjengelig. Hvert svar endrer om du trenger to uavhengige naboer, en delt Layer 2-tilkobling, eller begge.

Først etter at disse to listene finnes, blir tilkoblingsspørsmålet besvarlig. Før det ser hver mekanisme like gyldig ut. Etterpå eliminerer de fleste seg selv. Det er hele argumentet for å gjøre rutearbeidet først.

Fastsett ASN- og peering-grensen

En private-AS-fabrikk peeringer vanligvis med det offentlige grensedomenet over eBGP, og det interessante er policyen på begge sider. Bestem hvilke prefikser som aksepteres, hvilke som annonseres, og hvilken AS path upstream skal motta.

RFC 6996 reserverer et ASN-område for privat bruk, og disse ASN-ene skal ikke forekomme i globale annonseringer. Bruk plattformens støttede fjerning- eller filtreringspolicy og verifiser den resulterende annonseringen i stedet for å anta at enheten gjorde det. Det trinnet gir deg heller ikke myndighet til å annonsere et vilkårlig offentlig prefiks, som er en egen samtale med adresseeieren.

En konføderasjon eller en local-AS-funksjon er et designvalg for en bestemt topologi. Ingen av dem er obligatoriske bare fordi fabrikken og upstream bruker forskjellige ASN-roller, og å ta i bruk én uten kravet legger til bevegelige deler i hver fremtidig endring.

Layer 3-uplinker trenger ikke multichassis LAG

Uavhengige rutede grensesnitt med egne BGP-naboer gir to tydelige veier og to tydelige feildomener. vPC eller en annen multichassis LAG tjener et Layer 2-tilkoblingskrav, og det er riktig verktøy når det kravet finnes.

En generell regel om at hvert grenseepar må bruke vPC, eller må unngå det, skjuler betingelsene som faktisk avgjør saken. Spør hva tilkoblingen må bære, og velg deretter mekanismen som bærer det med færrest delte feilmodi.

Rutepolicyen du skrev først, endrer seg ikke når tilkoblingsmekanismen endres, og det er et godt tegn på at rekkefølgen var riktig.

Eksporter bare det leietakeren trenger

En leietaker kan trenge en standardrute, et sett utvalgte eksterne prefikser, eller en mye større tabell. Velg det omfanget mot reell videresendings- og kontrollplankapasitet, ikke mot et gammelt antall internett-ruter som ingen har målt på nytt.

EVPN IP Prefix-ruten, vanligvis kalt Type 5 og definert i RFC 9136bærer prefiksinformasjon i overlayet. Implementasjonen trenger fortsatt samsvarende eksport- og importpolicy pluss next-hop-oppslag, så å motta en ekstern BGP-rute ved grensen betyr ikke at hver leietaker-VRF importerer den.

Ikke hver leaf trenger den komplette tabellen bare fordi grensen holder den. Fordel det leietakerens trafikk krever, og la grensen eie resten.

Verifiser ett prefiks ende til ende

Velg et representativt eksternt prefiks og følg det gjennom grensens tiltenkte VRF, eksportpolicyen, den mottakende leafens videresendingskontekst og returveien til en leietakerkilde. Et prefiks som dukker opp ett sted og ikke det neste, lokaliserer feilen umiddelbart.

Bekreft hvordan next hop løses opp gjennom overlayet, for en rute som er til stede med en uoppløst next hop, videresender ingenting. Gjenta deretter kontrollen etter en uplink-endring, siden det er da policy og next-hop-oppslag oftest divergerer.

Arbeidsrekkefølge: list opp kryssrutene, bli enige om ASN-policyen, velg tilkoblingen for dens faktiske jobb, avgrens eksporten per leietaker, og verifiser deretter ett prefiks og returveien.