Byg EVPN-grænsen omkring eksportpolitik, ikke omkring tilslutninger

Den almindelige antagelse er, at Layer 2-tilslutningsmodellen ved grænsen bestemmer alt over den, så designet starter med et vPC-par og arbejder opad. Det ender normalt med rutevalg, der træffes ved et tilfælde. En EVPN-grænse er først og fremmest en routinggrænse: en lejers routingkontekst møder et eksternt routingdomæne, og det, der krydser den linje, er en politikerklæring. Vælg ruterne, ASN-forholdet og fejlvejene, før nogen begynder at diskutere port-channels. Tilslutningsmodellen følger derefter et krav i stedet for at diktere et.

Start med det, der krydser grænsen

Skriv de ruter ned, der skal være synlige på hver side, den retning de rejser i, og hvem der godkender en ændring af den liste. En grænse, der accepterer alt og annoncerer alt, har ingen politik, kun et kabel.

Navngiv derefter den fejl, du har til hensigt at drive: ét uplink nede, én border leaf nede eller hele det eksterne domæne utilgængeligt. Hvert svar ændrer, om du har brug for to uafhængige naboer, en delt Layer 2-tilslutning eller begge dele.

Først når de to lister findes, kan tilslutningsspørgsmålet besvares. Inden da ser enhver mekanisme lige gyldig ud. Derefter udelukker de fleste sig selv. Det er hele argumentet for at gøre routingarbejdet først.

Fastlæg ASN- og peering-grænsen

Et private-AS-fabric peerer normalt med det offentlige grænsedomæne over eBGP, og det interessante er politikken på begge sider. Beslut, hvilke præfikser der accepteres, hvilke der annonceres, og hvilken AS path upstream skal modtage.

RFC 6996 reserverer et ASN-interval til privat brug, og disse ASN skal ikke optræde i globale annonceringer. Anvend platformens understøttede fjernelses- eller filtreringspolitik, og verificér den resulterende annoncering i stedet for at antage, at enheden gjorde det. Det trin giver dig heller ikke ret til at annoncere et vilkårligt offentligt præfiks, det er en separat samtale med adresseejeren.

En konføderation eller en local-AS-funktion er et designvalg til en bestemt topologi. Ingen af dem er obligatoriske, blot fordi fabrikken og upstream bruger forskellige ASN-roller, og at vælge en uden kravet tilføjer bevægelige dele til enhver fremtidig ændring.

Layer 3-uplinks har ikke brug for multichassis LAG

Uafhængige routed interfaces med deres egne BGP-naboer giver to klare stier og to klare fejldomæner. vPC eller en anden multichassis LAG tjener et Layer 2-tilslutningskrav, og det er det rigtige værktøj, når det krav findes.

En generel regel om, at hvert grænsepanel skal bruge vPC eller skal undgå det, skjuler de betingelser, der faktisk afgør sagen. Spørg, hvad tilslutningen skal bære, og vælg derefter den mekanisme, der bærer det med færrest fælles fejltilstande.

Den routingpolitik, du skrev først, ændrer sig ikke, når tilslutningsmekanismen ændrer sig, hvilket er et godt tegn på, at rækkefølgen var rigtig.

Eksportér kun det, lejeren har brug for

En lejer kan have brug for en standardrute, et sæt udvalgte eksterne præfikser eller en meget større tabel. Vælg det omfang ud fra reel videresendelses- og kontrolplankapacitet, ikke ud fra et gammelt antal internetruter, som ingen har målt igen.

EVPN IP Prefix-ruten, almindeligvis kaldet Type 5 og defineret i RFC 9136, bærer præfiksinformation i overlayet. Implementeringen kræver stadig matchende eksport- og importpolitik plus next-hop-opløsning, så det at modtage en ekstern BGP-rute ved grænsen betyder ikke, at hver lejers VRF importerer den.

Ikke enhver leaf har brug for den fulde tabel, blot fordi grænsen har den. Distribuér det, lejerens trafik kræver, og lad grænsen eje resten.

Verificér ét præfiks fra ende til ende

Vælg et repræsentativt eksternt præfiks, og følg det gennem grænsens tilsigtede VRF, eksportpolitikken, den modtagende leafs videresendelseskontekst og returvejen til en lejerskilde. Et præfiks, der optræder ét sted og ikke det næste, lokaliserer fejlen med det samme.

Bekræft, hvordan next hop opløses gennem overlayet, fordi en rute, der er til stede med en uopløst next hop, ikke videresender noget. Gentag derefter kontrollen efter en uplink-ændring, da det er der, politik og next-hop-opløsning oftest divergerer.

Arbejdsrækkefølge: list de krydsende ruter, aftal ASN-politikken, vælg tilslutningen til dens faktiske job, afgræns eksporten pr. lejer, og verificér derefter ét præfiks og dets returvej.