Due PE, un prefisso: perché il RD decide la visibilità

Due router di bordo che annunciano lo stesso prefisso cliente descrivono un’unica destinazione VPNv4 finché qualcosa non li separa, e il separatore è il route distinguisher. Qualifica il prefisso; non decide chi importa il risultato, che è compito del route target. Assegni i RD dall’insieme delle rotte che devono restare distinguibili in ogni dominio in cui questi annunci possono incontrarsi, non dalla disposizione dei file di una singola macchina. Il numero che sceglie è un’identità da cui dipenderanno le revisioni successive, quindi va in un inventario prima di entrare in una configurazione.

Un RD più un prefisso è una sola destinazione

Un RD più un prefisso IPv4 forma la destinazione VPNv4 che il piano di controllo confronta. Dia a due PE lo stesso prefisso per clienti diversi e, senza RD diversi, annunciano percorsi verso un’unica destinazione. Nulla sullo schermo le dice che quel raggruppamento è errato, perché la piattaforma fa esattamente ciò che dice l’identità. Cambi il RD su uno dei due e l’annuncio vecchio viene ritirato mentre sotto un’altra identità ne appare uno nuovo. Tutto ciò che a valle si basava sulla vecchia identità, dalla selezione della rotta a un filtro operatore salvato, ora fa riferimento a qualcosa che non esiste più.

Più percorsi per destinazione è un comportamento BGP normale, non un sintomo. Uno speaker può tenere più percorsi ricevuti mentre seleziona un percorso migliore per l’inoltro, e il divario tra ricevuto e selezionato è dove vivono le domande di visibilità. Quando un percorso sembra essere sparito, verifichi se l’identità a cui apparteneva esiste ancora prima di guardare la sessione.

Stesso RD, stessa destinazione, percorsi diversi

Invii un RD e un prefisso da due router a nome dello stesso servizio ed entrambi offrono percorsi verso un’unica destinazione, di solito con next hop diversi. Quale di essi un route reflector propaghi è una decisione sul reflector: la sua selezione del percorso, la sua capacità di annuncio e qualsiasi policy sovrapposta. Nessuno dei due router di bordo controlla quella scelta. Dia ai due annunci RD distinti e ciascuno diventa la propria destinazione, così entrambi possono sopravvivere a un piano di controllo che altrimenti porta solo il percorso selezionato per un’identità.

Visibilità e multipath si incontrano nel VRF ricevente, ma non sono la stessa decisione, e un reflector che porta due identità non ha configurato un secondo percorso installato. Il VRF installa ciò che la sua policy di importazione ammette e ciò che la sua impostazione di massimo percorsi consente. Verifichi quell’impostazione separatamente quando vuole che il secondo percorso sia usato e non solo visibile.

Una regola locale di unicità non è una policy

Dare a ogni PE e a ogni istanza di routing il proprio RD è una convenzione sana: nomina l’origine, impedisce a servizi non correlati di collidere su un’identità e dà all’inventario una chiave stabile. Alcune piattaforme richiedono l’unicità solo all’interno della macchina e permettono esplicitamente ai router di condividere un RD per la stessa istanza VPN. Quel permesso è un vincolo di implementazione, non una regola tra reti che possa delegare a un fornitore. Se il dominio abbraccia più team, scriva lei stesso la politica di assegnazione.

L’appartenenza non viene mai dalle cifre. Uno schema come 65000:12 per un PE e 65000:13 per un altro è un’abitudine, mentre target di esportazione e importazione corrispondenti come 65000:112 sono ciò che mette una rotta in un VRF. Tratti il RD come l’identità di una rotta e il route target come il permesso che la porta in un VRF.

Dimostri la modifica sul VRF, non sul display

Prima di toccare un RD, annoti quattro cose: ciò che il PE annuncia oggi, ciò che il reflector riflette, ciò che il VRF ricevente importa e quale percorso seleziona. Un nuovo RD ritira un annuncio e ne introduce un altro, quindi la modifica appare su entrambi i lati della sessione ed è facile leggerla male se osserva solo il lato che annuncia. L’accettazione dovrebbe basarsi sulla raggiungibilità voluta, non su una riga in più che compare in una lista di prefissi. La tabella sotto impedisce ai tre identificatori di confondersi durante quella revisione.

Parta dal PE che annuncia e confronti entrambe le identità per lo stesso prefisso prima di rimuovere qualcosa. I comandi IOS sotto rispondono a tre domande in ordine: il vecchio annuncio è ancora lì, la nuova identità è visibile al reflector e il VRF seleziona il prefisso.

show bgp vpnv4 unicast rd 65000:12 203.0.113.0/24
show bgp vpnv4 unicast rd 65000:13 203.0.113.0/24
show ip route vrf CUSTOMER-A 203.0.113.0/24

Altre piattaforme stampano le stesse informazioni con una sintassi diversa, e le domande sopravvivono a quel cambiamento. Se la nuova identità manca al reflector mentre il PE la elenca come annunciata, il primo sospetto è la policy o la capacità di annuncio del reflector, non la numerazione.

Registri il PE, l’istanza, il RD, i target di esportazione e importazione e la proprietà del prefisso in un unico posto, perché l’assegnazione successiva è una ricerca e non una supposizione solo quando quel record esiste. Mantenga il vecchio RD finché la nuova identità non è visibile nel VRF ricevente, poi lo ritiri in un secondo passaggio così ogni fase resta reversibile.