Bygg EVPN-gränsen kring exportpolicy, inte kring anslutningar

Det vanliga antagandet är att Layer 2-anslutningsmodellen vid gränsen bestämmer allt ovanför den, så designen börjar med ett vPC-par och arbetar uppåt. Det slutar oftast med routningsbeslut som fattas av misstag. En EVPN-gräns är först och främst en routningsgräns: en hyresgästs routningskontext möter en extern routningsdomän, och det som korsar den linjen är ett policypåstående. Välj rutterna, ASN-relationen och felvägarna innan någon börjar bråka om port-channels. Anslutningsmodellen följer sedan av ett krav i stället för att diktera ett.

Börja med det som korsar gränsen

Skriv ned de rutter som ska vara synliga på varje sida, riktningen de färdas i och vem som godkänner en ändring i den listan. En gräns som accepterar allt och annonserar allt har ingen policy, bara en kabel.

Namnge sedan det fel du avser att driva: en uplink nere, en border leaf nere, eller hela den externa domänen onåbar. Varje svar ändrar om du behöver två oberoende grannar, en delad Layer 2-anslutning, eller båda.

Först när dessa två listor finns blir anslutningsfrågan besvarbar. Före det ser varje mekanism lika giltig ut. Efter det eliminerar de flesta sig själva. Det är hela argumentet för att göra routningsarbetet först.

Fäst ASN- och peering-gränsen

En private-AS-fabric peerar vanligtvis med den publika gränsdomänen över eBGP, och det intressanta är policyn på båda sidor. Bestäm vilka prefix som accepteras, vilka som annonseras och vilken AS path upstream ska ta emot.

RFC 6996 reserverar ett ASN-intervall för privat bruk, och dessa ASN ska inte förekomma i globala annonseringar. Tillämpa plattformens stödda borttagnings- eller filtreringspolicy och verifiera den resulterande annonseringen i stället för att anta att enheten gjorde det. Det steget ger dig inte heller befogenhet att annonsera ett godtyckligt publikt prefix, vilket är ett separat samtal med adressägaren.

En konfederation eller en local-AS-funktion är ett designval för en specifik topologi. Ingen av dem är obligatorisk bara för att fabricen och upstream använder olika ASN-roller, och att anta en utan kravet lägger till rörliga delar i varje framtida ändring.

Layer 3-uplinkar behöver ingen multichassis LAG

Oberoende routade gränssnitt med egna BGP-grannar ger två tydliga vägar och två tydliga feldomaner. vPC eller en annan multichassis LAG tjänar ett Layer 2-anslutningskrav, och det är rätt verktyg när det kravet finns.

En generell regel att varje gränspar måste använda vPC, eller måste undvika det, döljer de villkor som faktiskt avgör saken. Fråga vad anslutningen måste bära och välj sedan den mekanism som bär det med minst delade fellägen.

Routningspolicyn du skrev först ändras inte när anslutningsmekanismen ändras, vilket är ett gott tecken på att ordningen var rätt.

Exportera bara det hyresgästen behöver

En hyresgäst kan behöva en standardrutt, en uppsättning utvalda externa prefix, eller en mycket större tabell. Välj den omfattningen mot verklig vidarebefordrings- och kontrollplanskapacitet, inte mot en gammal siffra över internetrutter som ingen har mätt om.

EVPN IP Prefix-rutten, vanligen kallad Type 5 och definierad i RFC 9136bär prefixinformation i overlayen. Implementeringen behöver fortfarande matchande export- och importpolicy plus next-hop-uppslagning, så att ta emot en extern BGP-rutt vid gränsen betyder inte att varje hyresgästs VRF importerar den.

Inte varje leaf behöver den kompletta tabellen bara för att gränsen håller den. Fördela det hyresgästens trafik kräver och låt gränsen äga resten.

Verifiera ett prefix från början till slut

Välj ett representativt externt prefix och följ det genom gränsens avsedda VRF, exportpolicyn, den mottagande leafens vidarebefordringskontext och returvägen till en hyresgästkälla. Ett prefix som dyker upp på ett ställe och inte nästa lokaliserar felet omedelbart.

Bekräfta hur next hop löses upp genom overlayen, eftersom en rutt som finns med en oupplöst next hop inte vidarebefordrar något. Upprepa sedan kontrollen efter en uplink-ändring, eftersom det är då policy och next-hop-uppslagning oftast går isär.

Arbetsordning: lista de korsande rutterna, enas om ASN-policyn, välj anslutningen för dess faktiska jobb, avgränsa exporten per hyresgäst och verifiera sedan ett prefix och dess returväg.