Per il periodo transitorio in cui non tutti i router avranno a disposizione la funzionalità BGP Add-Path, in ambito IETF è stata proposta una soluzione più semplice, che non richiede alcuna modifica dei messaggi BGP, e quindi di larga applicazione. Questa soluzione, nota come BGP Diverse Path, è oggetto della RFC 6774 (di tipo informational) "Distribution of Diverse BGP Paths", del Novembre 2012. E' un tipo di soluzione che si applica in un classico scenario in presenza di Route Reflector (RR) ridondati, ma al momento non è supportata da tutti i costruttori.

 

Nel post precedente sulla funzionalità BGP Add-Path, ho ricordato le proprietà dei RR, illustrando cosa avviene in uno scenario come quello della figura seguente.

 

 

Questo scenario, come visto, può generare problemi di routing sub-ottimo e inoltre non garantisce sempre la Path Diversity sul router PE-3, a meno di non "giocare" con le metriche IGP. Ma come detto in quel post, questa è una soluzione improponibile su larga scala.

Prima di esporre il funzionamento del BGP Diverse Path invito quindi il lettore a rileggersi la sezione "ROUTING SUB-OTTIMO IN PRESENZA DI ROUTE REFLECTOR" del post precedente sulla funzionalità BGP Add-Path.

 

Per ottenere in modo stabile la Path Diversity sul router PE-3, in un classico scenario con RR ridondati come quello della figura sopra, si può utilizzare una soluzione molto semplice, anche qui una sorta di "Uovo di Colombo": fare in modo che un RR si comporti in modo "tradizionale" e annunci il best-path, e che l'altro RR annunci il best-path di backup, ossia quello ottenuto da un processo di selezione in cui venga eliminato il best-path primario.

L'idea è illustrata nella figura seguente.

 

 

Il RR-1 si comporta nel modo tradizionale e annuncia quindi il best-path, mentre RR-2, che viene chiamato shadow RR (il RR ombra !), annuncia il solo best-path di backup. Così facendo, su PE-3 si avrebbero due percorsi diversi per la destinazione "NET X", il best-path (ad esempio l'annuncio con BGP Next-Hop PE-1) ricevuto da RR-1, e un best-path di backup (quello con BGP Next-Hop PE-2) ricevuto da RR-2, rendendo applicabile la funzionalità PIC. 

Tutto qui, idea estremamente semplice ed efficace. C'è qualche piccolo dettaglio implementativo comunque di cui tener conto. Il più importante è questo. Supponiamo che RR-1 scelga come best-path il percorso con BGP Next-Hop PE-1, perché più vicino secondo la metrica IGP. Allo stesso modo, supponiamo che RR-2 (il RR ombra !) scelga come best-path il percorso con BGP Next-Hop PE-2 e come best-path di backup il percorso con BGP Next-Hop PE-1. Il risultato è che PE-3 avrà un solo percorso disponibile, quello con best-path PE-1, e quindi niente Path Diversity. Naturalmente il problema non si porrebbe se entrambi i RR scegliessero come best-path primario lo stesso percorso. Poiché questo problema, a parità delle metriche classiche del BGP (Local Preference, AS_PATH, ORIGIN, MED) si può avere a causa della diversa "distanza" IGP tra RR e router PE, è bene disabilitare il controllo della metrica IGP nel processo di selezione BGP (qualora sia disponibile un comando). Così facendo, RR-1 e RR-2 avranno identico best-path primario e quindi RR-2 avrà un diverso best-path di backup (che è quello che interessa).

 

Nelle piattaforme Cisco, il supporto del BGP Diverse Path è stato introdotto all'inizio nell'IOS XE 3.1S (probabilmente perché le piattaforme tipo ASR1k, che utilizzano l'IOS XE, sono molto utilizzate come RR) e poi anche in alcune versioni IOS come ad esempio l'IOS 15.2(4)S6 e 15.4(2)M. Il BGP Diverse Path non è invece supportato nell'IOS XR.

I passi generali di configurazione sullo shadow RR sono i seguenti:

 

   3.  Consentire l'annuncio ai RR-Clients del best-path di backup. Il comando da eseguire è il seguente : 

 

                  neighbor <IP-Client> advertise diverse-path [backup] [mpath]

 

Nella sezione "TEST DI LABORATORIO" sarà illustrerato l'utilizzo delle due opzioni "backup" e "mpath". Solo nel caso in cui il RR sia nel forwarding path (non molto frequente nella applicazioni pratiche), è bene abilitare il PIC con i comandi già visti in un post precedente. 

Sul RR primario è opportuno configurare solo il comando del punto 1. Per il resto sono solo richieste configurazioni ordinarie.

 

Il JUNOS non supporta il BGP Diverse Path ma solo il BGP Add-Path. Almeno, non sono riuscito a trovare nella documentazione JUNOS traccia di configurazione del BGP Diverse Path. Se qualcuno dovesse avere informazioni in merito, può contattarmi direttamente all'indirizzo e-mail Questo indirizzo email è protetto dagli spambots. È necessario abilitare JavaScript per vederlo.

 

Ho fatto un test di laboratorio per verificare la funzionalità BGP Diverse Path, utilizzando alcuni router con IOS 15.2(4)S6. Lo scenario utilizzato è quello della figura seguente, con la "NET X" coincidente con il prefisso 10.11.32.0/24. 

 

 

I router PE-X (X=1,2,3) hanno indirizzo IP dell'interfaccia Loopback 0, 192.168.0.X. I due RR-X (X=1,2) hanno invece indirizzo IP dell'interfaccia Loopback 0 pari a 192.168.1.X. Tutte le sessioni iBGP sono state stabilite utilizzando gli indirizzi IP delle interfacce Loopback 0. Lo shadow RR è il router RR-2.

Ho lasciato tutti gli attributi BGP al loro valore di default. Illustrerò dapprima cosa accade con le configurazioni base, senza applicare il BGP Diverse Path.

RR-1 e RR-2 ricevono ciascuno due annunci del prefisso 10.11.32.0/24, rispettivamente dai router PE-1 e PE-2. I due RR eseguono quindi il processo di selezione per determinare il best-path, che, come si evince dalle visualizzazioni seguenti, risulta essere il percorso con BGP Next-Hop PE-1 :

 

 

 

 

. . .  < legenda omessa >  . . . 

Su PE-3 si avranno quindi due annunci del prefisso 10.11.32.0/24:

 

     

Il gioco sembrerebbe fatto, due annunci su PE-3 e quindi funzionalità PIC applicabile. Purtroppo non è così, i due annunci, come si evince dalla visualizzazione, hanno entrambi lo stesso BGP Next-Hop (= 192.168.0.1), e come più volte detto, la Path Diversity impone che i due BGP Next-Hop siano diversi.

Qui entra in gioco il BGP Diverse Path. Come detto sopra, utilizzerò RR-2 come shadow RR. La configurazione del processo BGP su RR-2 è la seguente (NOTA: nel test ho utilizzato la address-family di default che è "IPv4 unicast", per cui non vi è bisogno di specificare i comandi all'interno dell' "address-family ipv4 unicast"):

 

 

La configurazione di RR-1 è molto simile. E' sufficiente togliere i comandi specifici del BGP Diverse path che sono "advertise diverse-path backup" all'interno del peer-policy template e "bgp additional-paths select backup".

Vediamo innanzitutto se e cosa cambia nelle Tabelle BGP dei due RR:

L'unica cosa diversa rispetto alle due tabelle BGP precedenti, è la presenza del codice "b" nell'annuncio non best-path della Tabella BGP di RR-2 (sul codice "i" non commento poiché arcinoto !). Come si può leggere dagli "status code" (vedi la visualizzazione completa del comando "show bgp ipv4 unicast" sopra), la "b" indica backup-path. Ciò significa che questo annuncio non best-path è stato selezionato per l'annuncio ai RR-Client. Ad esempio, con seguente visualizzazione si evince che RR-2 annuncia questo percorso non best-path a PE-3:

 

. . .  < legenda omessa >  . . .

 

Si noti la presenza dei tre codici "bia". Il codice aggiuntivo "a" indica additional-path, ossia che il percorso annunciato non è il best-path ma un percorso "aggiuntivo".

Infine, vediamo cosa accade su PE-3. Nella Tabella BGP troviamo i due annunci provenienti da RR-1 e da RR-2:

 

 

Come si può notare, questa volta i due annunci hanno BGP Next-Hop diverso e quindi sono entrambi utilizzabili dalla funzionalità PIC. Il passo sucessivo è quindi abilitare la funzionalità PIC su PE-3:

 

 

La Tabella CEF relativa al prefisso 10.11.32.0/24 mostra l'esistenza nella FIB di entrambi i percorsi:

 

 

Ciascun BGP Next-Hop ha due IGP Next-Hop. Il secondo BGP Next-Hop (= 192.168.0.2), come indicato dalla parola chiave "repair", viene utilizzato come backup sul piano di forwarding.

In alcune situazioni, soprattutto in reti di piccole dimensioni, i RR possono essere utilizzati anche sul piano dati, ossia sul forwarding path. In simili situazioni potrebbe essere utile abilitare sui RR il BGP multipath. Cosa avviene in questo caso sullo shadow RR ? Bene, poiché sono utilizzati entrambi i percorsi disponibili, il router annuncia il solo best-path e ignora i comandi specifici del BGP Diverse Path. Su PE-3 si ritorna quindi alla situazione come se il BGP Diverse Path non fosse abilitato (una piccola NOTA a latere: ricordo che in presenza di BGP multipath abilitato, il processo di selezione BGP viene comunque completato e il best-path determinato viene annunciato ai BGP peers, secondo le regole usuali del BGP).

Per abilitare il BGP Diverse Path nel caso di BGP multipath abilitato sui RR, è necessario utilizzare l'opzione "mpath" nel comando "neighbor <IP-Client> advertise diverse-path ...". La configurazione di RR-2 in questo caso diventa (si noti che il comando "bgp additional-paths select backup" non è più necessario):

 

 . . .  < comandi neighbor omessi > . . . 

 

Così facendo, PE-3 riceverà da RR-1 il percorso con BGP Next-Hop PE-1 (best-path per PE-1, nonostante l'abilitazione del BGP multipath), e da RR-2 il percorso con BGP Next-Hop PE-2 grazie alla clausola "mpath", che consente di annunciare un percorso non best-path marcato nella Tabella BGP di    RR-2 come multipath (indicato nella Tabella BGP con il codice "m").

 

Il BGP Diverse Path è meno generale della funzionalità BGP Add-Path, ma ha il vantaggio di non richiedere modifiche al messaggio BGP UPDATE, né ha bisogno di essere negoziato tra BGP peers. Per cui potrebbe essere di larga applicabilità, nel transitorio in cui tutti i router della rete (in particolare PE e RR) non siano dotati del supporto della funzionalità BGP Add-Path.

Lo scenario applicativo si trova spesso nelle applicazioni pratiche, dove di norma i RR sono sempre ridondati (o perlomeno, è bene che sia così !!!).

Con questo post chiudo l'ampia rassegna delle tecniche oggi disponibili per velocizzare la convergenza del BGP. Come ho promesso più volte, in futuro pubblicherò un documento organico che raccoglie tutti i 6 post che ho dedicato all'argomento, con eventuali migliorie e aggiornamenti. Quindi, "stay tuned" (o, per dirla alla romana "state in campana").

 

Siete nuovi al BGP, oppure avete bisogno di ulteriori approfondimenti ? Acquistate il mio libro "BGP: dalla teoria alla pratica" (al prezzo speciale di 30 Euro per gli utenti registrati al sito, spese di spedizione gratuite). Oppure seguite i nostro corsi IPN246 e IPN247.