Construiește granița EVPN în jurul politicii de export, nu al atașărilor

Ipoteza obișnuită este că modelul de atașare Layer 2 de la graniță determină tot ce se află deasupra lui, așa că proiectarea începe cu o pereche vPC și urcă. De obicei se termină cu decizii de rutare luate din întâmplare. O graniță EVPN este mai întâi o graniță de rutare: un context de rutare al unui chiriaș întâlnește un domeniu de rutare extern, iar ceea ce traversează acea linie este o declarație de politică. Alege rutele, relația ASN și căile de defectare înainte ca cineva să înceapă să dispute port-channels. Modelul de atașare decurge apoi dintr-o cerință în loc să o dicteze.

Începe cu ceea ce traversează granița

Notează rutele care ar trebui să fie vizibile pe fiecare parte, direcția în care merg și cine aprobă o modificare a acelei liste. O graniță care acceptă tot și anunță tot nu are politică, doar un cablu.

Apoi numește defectarea pe care intenționezi să o operezi: un uplink căzut, un border leaf căzut sau întregul domeniu extern inaccesibil. Fiecare răspuns schimbă dacă ai nevoie de doi vecini independenți, de o atașare Layer 2 partajată sau de ambele.

Abia după ce aceste două liste există devine întrebarea despre atașare una la care se poate răspunde. Înainte, fiecare mecanism pare la fel de valid. După, majoritatea se elimină singure. Acesta este tot argumentul pentru a face munca de rutare mai întâi.

Fixează granița ASN și de peering

O fabrică cu AS private face de obicei peering cu domeniul public de graniță prin eBGP, iar partea interesantă este politica de ambele părți. Decide ce prefixe sunt acceptate, care sunt anunțate și ce cale AS trebuie să primească upstream-ul.

RFC 6996 rezervă un interval de ASN pentru uz privat, iar aceste ASN nu ar trebui să apară în anunțurile globale. Aplică politica de eliminare sau filtrare susținută de platformă și verifică anunțul rezultat în loc să presupui că dispozitivul a făcut-o. Acel pas nu îți dă nici autoritatea de a anunța un prefix public arbitrar, ceea ce este o discuție separată cu proprietarul adresei.

O confederație sau o funcție local-AS este o alegere de proiectare pentru o topologie anume. Niciuna nu este obligatorie doar pentru că fabrica și upstream-ul folosesc roluri ASN diferite, iar adoptarea uneia fără cerință adaugă piese mobile la fiecare schimbare viitoare.

Uplink-urile Layer 3 nu au nevoie de multichassis LAG

Interfețele rutate independente cu propriii vecini BGP oferă două căi clare și două domenii de defectare clare. vPC sau un alt multichassis LAG servește o cerință de atașare Layer 2 și este instrumentul potrivit atunci când acea cerință există.

O regulă generală că fiecare pereche de graniță trebuie să folosească vPC sau trebuie să îl evite ascunde condițiile care decid de fapt cazul. Întreabă ce trebuie să transporte atașarea, apoi alege mecanismul care o transportă cu cele mai puține moduri de defectare comune.

Politica de rutare pe care ai scris-o prima nu se schimbă când se schimbă mecanismul de atașare, ceea ce este un semn bun că ordinea a fost corectă.

Exportă doar ce are nevoie chiriașul

Un chiriaș poate avea nevoie de o rută implicită, de un set de prefixe externe selectate sau de o tabelă mult mai mare. Alege acel cadru în raport cu capacitatea reală de forwarding și de plan de control, nu cu o numărătoare veche de rute de internet pe care nimeni nu a remăsurat-o.

Ruta EVPN IP Prefix, numită de obicei Type 5 și definită în RFC 9136transportă informații de prefix în overlay. Implementarea are în continuare nevoie de politică de export și import potrivită plus rezolvarea next-hop, așa că primirea unei rute BGP externe la graniță nu înseamnă că fiecare VRF de chiriaș o importă.

Nu fiecare leaf are nevoie de tabela completă doar pentru că granița o ține. Distribuie ce cere traficul chiriașului și lasă granița să dețină restul.

Verifică un prefix de la un capăt la altul

Alege un prefix extern reprezentativ și urmărește-l prin VRF-ul intenționat al graniței, prin politica de export, prin contextul de forwarding al leaf-ului receptor și prin calea de întoarcere către o sursă a chiriașului. Un prefix care apare într-un loc și nu în următorul localizează imediat greșeala.

Confirmă cum se rezolvă next hop prin overlay, pentru că o rută prezentă cu un next hop nerezolvat nu forwardează nimic. Apoi repetă verificarea după o schimbare de uplink, fiindcă atunci diverg cel mai des politica și rezolvarea next-hop.

Ordinea lucrului: listează rutele care traversează, convenește politica ASN, alege atașarea pentru sarcina ei reală, delimitează exportul pe chiriaș, apoi verifică un prefix și calea lui de întoarcere.