Bouw de EVPN-grens rond exportbeleid, niet rond aansluitingen

De gangbare aanname is dat het Layer 2-aansluitmodel op de grens alles daarboven bepaalt, dus het ontwerp begint bij een vPC-paar en werkt omhoog. Het eindigt meestal met routeringsbeslissingen die per ongeluk zijn genomen. Een EVPN-grens is in de eerste plaats een routeringsgrens: een tenant-routeringscontext ontmoet een extern routeringsdomein, en wat die lijn oversteekt is een beleidsverklaring. Kies de routes, de ASN-relatie en de faalpaden voordat iemand over port-channels begint te discussiëren. Het aansluitmodel volgt dan uit een vereiste in plaats van er een voor te schrijven.

Begin met wat de grens oversteekt

Schrijf de routes op die aan elke kant zichtbaar moeten zijn, de richting waarin ze gaan en wie een wijziging in die lijst goedkeurt. Een grens die alles accepteert en alles aankondigt heeft geen beleid, alleen een kabel.

Benoem dan de storing die je van plan bent te bedrijven: één uplink down, één border leaf down, of het hele externe domein onbereikbaar. Elk antwoord verandert of je twee onafhankelijke buren nodig hebt, een gedeelde Layer 2-aansluiting, of beide.

Pas nadat die twee lijsten bestaan wordt de aansluitvraag beantwoordbaar. Daarvoor lijkt elk mechanisme even geldig. Daarna sluiten de meeste zichzelf uit. Dat is het hele argument om het routeringswerk eerst te doen.

Leg de ASN- en peeringgrens vast

Een private-AS-fabric peert gewoonlijk met het openbare grensdomein via eBGP, en het interessante deel is het beleid aan beide kanten. Bepaal welke prefixen worden geaccepteerd, welke worden aangekondigd en welk AS path de upstream moet ontvangen.

RFC 6996 reserveert een ASN-bereik voor privégebruik, en die ASN's horen niet in wereldwijde aankondigingen te verschijnen. Pas het door het platform ondersteunde verwijderings- of filterbeleid toe en verifieer de resulterende aankondiging in plaats van aan te nemen dat het apparaat het deed. Die stap geeft je ook geen bevoegdheid om een willekeurig openbaar prefix aan te kondigen; dat is een apart gesprek met de adreseigenaar.

Een confederatie of een local-AS-functie is een ontwerpkeuze voor een specifieke topologie. Geen van beide is verplicht alleen omdat de fabric en de upstream verschillende ASN-rollen gebruiken, en er een aannemen zonder de vereiste voegt bewegende delen toe aan elke toekomstige wijziging.

Layer 3-uplinks hebben geen multichassis LAG nodig

Onafhankelijke gerouteerde interfaces met hun eigen BGP-buren geven twee duidelijke paden en twee duidelijke faaldomeinen. vPC of een andere multichassis LAG dient een Layer 2-aansluitvereiste, en het is het juiste hulpmiddel wanneer die vereiste bestaat.

Een algemene regel dat elk grenspaar vPC moet gebruiken, of het juist moet vermijden, verbergt de voorwaarden die de zaak werkelijk beslissen. Vraag wat de aansluiting moet dragen en kies dan het mechanisme dat dat draagt met de minste gedeelde faalmodi.

Het routeringsbeleid dat je eerst schreef verandert niet wanneer het aansluitmechanisme verandert, wat een goed teken is dat de volgorde juist was.

Exporteer alleen wat de tenant nodig heeft

Een tenant kan een standaardroute nodig hebben, een set geselecteerde externe prefixen, of een veel grotere tabel. Kies die omvang tegen echte forwarding- en controle-plane-capaciteit, niet tegen een oude telling van internetroutes die niemand opnieuw heeft gemeten.

De EVPN IP Prefix-route, gewoonlijk Type 5 genoemd en gedefinieerd in RFC 9136draagt prefixinformatie in de overlay. De implementatie heeft nog steeds passend export- en importbeleid nodig plus next-hop-resolutie, dus een externe BGP-route op de grens ontvangen betekent niet dat elke tenant-VRF die importeert.

Niet elke leaf heeft de volledige tabel nodig alleen omdat de grens die vasthoudt. Verdeel wat het verkeer van de tenant vereist, en laat de grens de rest bezitten.

Verifieer één prefix van begin tot eind

Kies een representatief extern prefix en volg het door de bedoelde VRF van de grens, het exportbeleid, de forwarding-context van de ontvangende leaf en het retourpad naar een tenant-bron. Een prefix dat op de ene plaats verschijnt en op de volgende niet, lokaliseert de fout onmiddellijk.

Bevestig hoe de next hop via de overlay wordt opgelost, want een route die aanwezig is met een onopgeloste next hop stuurt niets door. Herhaal de controle dan na een uplink-wijziging, want dan lopen beleid en next-hop-resolutie het vaakst uiteen.

Werkorde: lijst de kruisende routes op, stem het ASN-beleid af, kies de aansluiting voor haar werkelijke taak, bepaal de export per tenant en verifieer dan één prefix en zijn retourpad.