Veidojiet EVPN robežu ap eksporta politiku, nevis ap pievienojumiem

Izplatīts pieņēmums ir, ka Layer 2 pievienojuma modelis uz robežas nosaka visu, kas ir virs tā, tāpēc projektēšana sākas ar vPC pāri un virzās uz augšu. Parasti tas beidzas ar maršrutēšanas lēmumiem, kas pieņemti nejauši. EVPN robeža vispirms ir maršrutēšanas robeža: nomnieka maršrutēšanas konteksts sastopas ar ārēju maršrutēšanas domēnu, un tas, kas šķērso šo līniju, ir politikas paziņojums. Izvēlieties maršrutus, ASN attiecības un atteices ceļus, pirms kāds sāk strīdēties par port-channels. Pievienojuma modelis pēc tam izriet no prasības, nevis to diktē.

Sāciet ar to, kas šķērso robežu

Pierakstiet maršrutus, kuriem jābūt redzamiem katrā pusē, to kustības virzienu un to, kurš apstiprina izmaiņas šajā sarakstā. Robežai, kas pieņem visu un paziņo visu, nav politikas, ir tikai kabelis.

Pēc tam nosauciet atteici, kuru plānojat ekspluatēt: viens uplink nedarbojas, viens border leaf nedarbojas vai viss ārējais domēns nav sasniedzams. Katra atbilde maina to, vai jums vajag divus neatkarīgus kaimiņus, kopīgu Layer 2 pievienojumu vai abus.

Tikai pēc tam, kad šie divi saraksti pastāv, pievienojuma jautājums kļūst atbildams. Pirms tam katrs mehānisms izskatās vienlīdz derīgs. Pēc tam lielākā daļa izslēdz sevi. Tas ir viss arguments, lai maršrutēšanas darbu veiktu vispirms.

Nostipriniet ASN un peering robežu

Fabric ar privātiem AS parasti veic peering ar publisko robežas domēnu, izmantojot eBGP, un interesantā daļa ir politika abās pusēs. Izlemiet, kuri prefiksi tiek pieņemti, kuri tiek paziņoti un kādu AS path jāsaņem upstream.

RFC 6996 rezervē ASN diapazonu privātai lietošanai, un šiem ASN nevajadzētu parādīties globālos paziņojumos. Piemērojiet platformas atbalstīto noņemšanas vai filtrēšanas politiku un pārbaudiet iegūto paziņojumu, tā vietā lai pieņemtu, ka ierīce to izdarīja. Šis solis arī nedod tiesības paziņot patvaļīgu publisku prefiksu, tā ir atsevišķa saruna ar adreses īpašnieku.

Konfederācija vai local-AS funkcija ir projektēšanas izvēle konkrētai topoloģijai. Neviens nav obligāts tikai tāpēc, ka fabric un upstream izmanto dažādas ASN lomas, un viena ieviešana bez prasības pievieno kustīgas daļas katrai nākamajai izmaiņai.

Layer 3 uplinkiem nav nepieciešams multichassis LAG

Neatkarīgas maršrutētas saskarnes ar saviem BGP kaimiņiem dod divus skaidrus ceļus un divus skaidrus atteices domēnus. vPC vai cits multichassis LAG kalpo Layer 2 pievienojuma prasībai, un tas ir pareizais instruments, kad šāda prasība pastāv.

Vispārīgs noteikums, ka katram robežas pārim ir jāizmanto vPC vai tas ir jāizvairās, slēpj nosacījumus, kas patiesībā izšķir gadījumu. Pajautājiet, kas pievienojumam jānes, un pēc tam izvēlieties mehānismu, kas to nes ar vismazāk kopīgiem atteices režīmiem.

Maršrutēšanas politika, ko uzrakstījāt pirmo, nemainās, kad mainās pievienojuma mehānisms, kas ir laba zīme, ka secība bija pareiza.

Eksportējiet tikai to, kas nomniekam nepieciešams

Nomniekam var būt nepieciešams noklusējuma maršruts, atlasītu ārējo prefiksu kopa vai daudz lielāka tabula. Izvēlieties šo apjomu pēc reālās pārraides un vadības plaknes jaudas, nevis pēc veca interneta maršrutu skaita, ko neviens nav pārmērījis.

EVPN IP Prefix maršruts, ko parasti sauc par Type 5 un kas definēts RFC 9136, pārnēsā prefiksa informāciju overlay. Ieviešanai joprojām nepieciešama atbilstoša eksporta un importa politika plus next-hop atrisināšana, tāpēc ārēja BGP maršruta saņemšana uz robežas nenozīmē, ka katrs nomnieka VRF to importē.

Ne katram leaf ir vajadzīga pilna tabula tikai tāpēc, ka robeža to tur. Sadaliet to, ko prasa nomnieka trafiks, un pārējo lai tur robeža.

Pārbaudiet vienu prefiksu no sākuma līdz beigām

Izvēlieties reprezentatīvu ārēju prefiksu un izsekojiet tam caur robežas paredzēto VRF, eksporta politiku, saņemošā leaf pārraides kontekstu un atgriešanās ceļu uz nomnieka avotu. Prefikss, kas parādās vienā vietā un ne nākamajā, nekavējoties lokalizē kļūdu.

Apstipriniet, kā next hop tiek atrisināts caur overlay, jo maršruts, kas pastāv ar neatrisinātu next hop, neko nepārsūta. Pēc tam atkārtojiet pārbaudi pēc uplink izmaiņas, jo tieši tad politika un next-hop atrisināšana visbiežāk atšķiras.

Darba secība: uzskaitiet šķērsojošos maršrutus, vienojieties par ASN politiku, izvēlieties pievienojumu tā faktiskajam uzdevumam, noteikti eksporta apjomu katram nomniekam un pēc tam pārbaudiet vienu prefiksu un tā atgriešanās ceļu.