Costruisci il confine EVPN attorno alla politica di export, non agli attachment

L'ipotesi comune è che il modello di attachment Layer 2 al confine determini tutto ciò che sta sopra, quindi il progetto parte da una coppia vPC e sale. Di solito finisce con decisioni di routing prese per caso. Un confine EVPN è prima di tutto un confine di routing: un contesto di routing del tenant incontra un dominio di routing esterno, e ciò che attraversa quella linea è una dichiarazione di policy. Scegli le rotte, la relazione ASN e i percorsi di guasto prima che qualcuno discuta di port-channels. Il modello di attachment segue poi un requisito invece di dettarlo.

Parti da ciò che attraversa il confine

Scrivi le rotte che devono essere visibili su ciascun lato, la direzione in cui viaggiano e chi approva una modifica a quell'elenco. Un confine che accetta tutto e annuncia tutto non ha policy, solo un cavo.

Poi nomina il guasto che intendi gestire: un uplink giù, un border leaf giù o l'intero dominio esterno irraggiungibile. Ogni risposta cambia se servono due vicini indipendenti, un attachment Layer 2 condiviso o entrambi.

Solo quando esistono questi due elenchi la domanda sull'attachment diventa rispondibile. Prima, ogni meccanismo sembra ugualmente valido. Dopo, la maggior parte si elimina da sola. È tutto l'argomento per fare prima il lavoro di routing.

Fissa il confine ASN e peering

Una fabric con AS privati fa di solito peering con il dominio di confine pubblico tramite eBGP, e la parte interessante è la policy su entrambi i lati. Decidi quali prefissi sono accettati, quali annunciati e quale AS path deve ricevere l'upstream.

RFC 6996 riserva un intervallo di ASN per uso privato, e quegli ASN non dovrebbero comparire negli annunci globali. Applica la politica di rimozione o filtraggio supportata dalla piattaforma e verifica l'annuncio risultante invece di presumere che il dispositivo l'abbia fatto. Quel passaggio non ti dà nemmeno l'autorità di annunciare un prefisso pubblico arbitrario, è una conversazione separata con il proprietario dell'indirizzo.

Una confederazione o una funzione local-AS è una scelta di progetto per una topologia specifica. Nessuna delle due è obbligatoria solo perché la fabric e l'upstream usano ruoli ASN diversi, e adottarne una senza il requisito aggiunge parti mobili a ogni modifica futura.

Gli uplink Layer 3 non richiedono multichassis LAG

Interfacce routed indipendenti con i propri vicini BGP danno due percorsi chiari e due domini di guasto chiari. vPC o un altro multichassis LAG serve un requisito di attachment Layer 2, ed è lo strumento giusto quando quel requisito esiste.

Una regola generale che ogni coppia di confine debba usare vPC, o debba evitarlo, nasconde le condizioni che decidono davvero il caso. Chiedi cosa deve trasportare l'attachment, poi scegli il meccanismo che lo trasporta con il minor numero di modalità di guasto condivise.

La politica di routing che hai scritto per prima non cambia quando cambia il meccanismo di attachment, il che è un buon segno che l'ordine era corretto.

Esporta solo ciò che serve al tenant

Un tenant può aver bisogno di una rotta predefinita, di un insieme di prefissi esterni selezionati o di una tabella molto più grande. Scegli quel perimetro in base alla capacità reale di inoltro e di control plane, non a un vecchio conteggio di rotte internet che nessuno ha rimisurato.

La rotta EVPN IP Prefix, comunemente chiamata Type 5 e definita in RFC 9136, trasporta informazioni di prefisso nell'overlay. L'implementazione richiede ancora policy di export e import corrispondenti più la risoluzione del next-hop, quindi ricevere una rotta BGP esterna al confine non significa che ogni VRF del tenant la importi.

Non ogni leaf ha bisogno della tabella completa solo perché il confine la detiene. Distribuisci ciò che richiede il traffico del tenant, e lascia che il confine possieda il resto.

Verifica un prefisso da un capo all'altro

Scegli un prefisso esterno rappresentativo e seguilo attraverso il VRF previsto del confine, la politica di export, il contesto di inoltro del leaf ricevente e il percorso di ritorno verso una sorgente del tenant. Un prefisso che appare in un punto e non nel successivo localizza subito l'errore.

Conferma come il next hop si risolve attraverso l'overlay, perché una rotta presente con un next hop non risolto non inoltra nulla. Poi ripeti il controllo dopo un cambio di uplink, perché è allora che policy e risoluzione del next-hop divergono più spesso.

Ordine di lavoro: elenca le rotte che attraversano, concorda la politica ASN, scegli l'attachment per il suo lavoro reale, delimita l'export per tenant, poi verifica un prefisso e il suo percorso di ritorno.