Alcune rotte L2VPN svaniscono dopo l’aggiunta di riflettori di rotta

Le sessioni restano attive, l’IGP è stabile e tuttavia un pugno di rotte L2VPN non compare mai su due dei quattro bordi del provider. Questo schema appartiene a un problema di riflessione e non di trasporto, perché una sessione rotta fallisce del tutto mentre un confine di riflessione riutilizzato fallisce in modo selettivo. L’anello fisico non c’entra; il grafo logico di distribuzione è il punto in cui quelle rotte si sono fermate. Trovare quel punto non richiede di ricostruire il piano di controllo.

La perdita è selettiva, il che restringe la ricerca

Quattro bordi del provider su un anello fisico richiedono sei sessioni logiche per una maglia completa, poiché ogni router si accoppia agli altri tre. Quelle sessioni viaggiano sul trasporto instradato, quindi il cablaggio non dice nulla su quante adiacenze esistano né su quale di esse rifletta. Quando due bordi perdono un insieme preciso di prefissi mentre tutto il resto converge, il cavo non è il sospetto.

La perdita selettiva punta alla prevenzione dei loop, alla policy o alla direzione della relazione, dove alcune rotte attraversano un confine e altre vengono scartate lungo il percorso. La perdita totale punta alla sessione o alla famiglia di indirizzi. Decidere quale delle due si sta guardando è il primo passo utile, e costa un solo comando.

Che cosa cambia davvero la riflessione

La riflessione delle rotte allenta la regola secondo cui un parlante iBGP non può riannunciare una rotta appresa da un altro parlante iBGP. RFC 4456 esprime l’eccezione tramite la relazione tra il parlante e l’origine della rotta, e la direzione di quella relazione conta più di quanto suggeriscano la maggior parte dei riassunti. Una rotta appresa da un client può essere riflessa verso altri client e verso non client, mentre una rotta appresa da un non client può essere riflessa solo verso i client. Leggete l’asimmetria due volte, perché spiega come aggiungere una relazione client possa nascondere un errore di progetto: apre un percorso che la topologia non aveva mai previsto.

L’attributo CLUSTER_LIST registra la cronologia della riflessione, e un riflettore che trova il proprio ID di cluster in quella lista deve ignorare l’annuncio. Questa è la prevenzione dei loop, ed è anche il meccanismo che elimina le rotte quando gli identificatori vengono riutilizzati per errore. ORIGINATOR_ID svolge un ruolo affine nel nominare il router che ha annunciato per primo la rotta.

Gli ID di cluster riutilizzati sono il modo in cui le rotte scompaiono

Una rete piccola invita a una scorciatoia: date a ogni router un ID di cluster uguale al suo loopback, aggiungete più tardi un altro riflettore e riutilizzate un loopback esistente perché è comodamente a portata di mano. Se quell’identificatore ora appare in due stadi di riflessione indipendenti, il secondo stadio vede il proprio ID in CLUSTER_LIST e scarta la rotta. Nulla registra un errore, perché scartare è la risposta corretta a un loop.

I riflettori ridondanti che servono un solo cluster sono l’eccezione legittima: condividono un ID di proposito affinché uno dei due possa servire gli stessi client. L’identificatore deve corrispondere al progetto della riflessione e non distinguere i nomi degli chassis.

Disegnate il grafo previsto prima di toccare qualsiasi configurazione: chi origina il prefisso, quale relazione client consente la prima riflessione, quale riflettore la porta allo stadio successivo e dove si trova l’ultimo client. Ogni salto di quel grafo è un punto in cui un identificatore riutilizzato, una relazione client mancante o un filtro di policy possono fermare la rotta. Con il grafo disegnato, una rotta mancante ha una posizione invece di un mistero.

Resistete alla tentazione di rendere ogni vicino un client

La riparazione rapida di una rotta mancante è rendere ogni vicino un client di ogni riflettore. La propagazione ritorna e il progetto smette di dirvi qualsiasi cosa: moltiplica le rotte che ogni parlante trasporta mentre nasconde quale relazione avrebbe dovuto fare il lavoro.

Una rete piccola di solito ha bisogno di una di due forme. Una maglia iBGP completa sono sei sessioni per quattro router senza alcuna riflessione, e una coppia designata di riflettori che serve i bordi rimanenti è l’altra. Entrambe sono più facili da ragionare di una maglia parziale in cui ogni router riflette un po’. Scegliete la forma in base alla scala e al comportamento in caso di guasto, non al diagramma del cablaggio.

Controllate la famiglia di indirizzi prima di incolpare la riflessione

Una sessione TCP sulla porta 179 prova che i due parlanti possono parlarsi, e nulla sul fatto che la famiglia di indirizzi VPN abbia scambiato una sola rotta. Stabilite lo stato della sessione, poi la famiglia, poi il singolo prefisso.

vtysh -c "show bgp summary"
vtysh -c "show bgp l2vpn evpn summary"
vtysh -c "show bgp l2vpn evpn"

Queste tre uscite separano un problema di adiacenza da un problema di scambio e da un problema di prefisso mancante. Se la famiglia non mostra alcun prefisso, ispezionate lo stato di attivazione e la policy di esportazione del vicino prima di guardare la riflessione. Se i prefissi compaiono su un bordo ma non su un altro, confrontate la lista dei cluster e l’originator sul lato ricevente, poi percorrete il grafo della sezione precedente.

Tenete la raggiungibilità del salto successivo e lo stato di inoltro fuori da quel controllo. Una rotta riflessa con un salto successivo irraggiungibile è presente e inutilizzabile, il che sembra un guasto di riflessione finché non guardate la colonna del salto successivo. Risolvete il salto successivo, confermate la voce di inoltro e solo allora decidete se il grafo di distribuzione ha bisogno di un altro riflettore.