8. Opzioni aggiuntive per il progetto

8.1. Iniezione di route da terze parti

BGP consente a un parlante BGP « terzo », cioè direttamente collegato, di iniettare route in qualsiasi punto della topologia di rete, soddisfando REQ5. Ciò si può ottenere effettuando peering BGP multi-hop con alcuni o anche tutti i dispositivi della topologia. Inoltre, la distribuzione di percorsi BGP diversificati [RFC6774] potrebbe essere usata per iniettare più next hop BGP per lo stesso prefisso per facilitare il bilanciamento del carico, oppure la capacità BGP ADD-PATH [RFC7911] se supportata dall'implementazione. Purtroppo, in molte implementazioni, ADD-PATH si è rivelato supportare correttamente solo l'IBGP per i casi d'uso per cui era stato originariamente ottimizzato; ciò limita il peering « terzo » all'IBGP soltanto.

Per implementare l'iniezione di route nel progetto proposto, un parlante BGP terzo può effettuare peering con switch Tier 3 e Tier 1, iniettando lo stesso prefisso ma usando un insieme speciale di next hop BGP per i dispositivi Tier 1. Si assume che tali next hop si risolvano ricorsivamente via BGP e potrebbero essere, ad esempio, indirizzi IP su dispositivi Tier 3. La programmazione risultante della tabella di inoltro può fornire la distribuzione di traffico desiderata tra cluster diversi.

8.2. Summarizzazione delle route nella topologia Clos

Come già menzionato, la summarizzazione delle route non è possibile nella topologia Clos proposta poiché rende la rete suscettibile a buchi neri di routing in caso di guasto di un singolo collegamento. Il problema principale è il numero limitato di percorsi ridondanti tra elementi di rete, ad es. esiste un solo percorso tra ogni coppia di dispositivi Tier 1 e Tier 3. Tuttavia alcuni operatori possono trovare desiderabile l'aggregazione delle route per migliorare la stabilità del piano di controllo.

Se si pianifica una tecnica di summarizzazione entro la topologia, vanno modellati il comportamento di routing e il potenziale di buchi neri non solo per guasti singoli o multipli di collegamento, ma anche per guasti di percorsi in fibra o di domini ottici quando la topologia si estende oltre una sede fisica. Una modellazione semplice può consistere nel verificare la raggiungibilità sui dispositivi che eseguono summarization in condizione di guasto di collegamento o percorso tra un insieme di dispositivi in ogni tier nonché verso i router WAN quando è presente connettività esterna.

La summarizzazione delle route sarebbe possibile con una piccola modifica alla topologia di rete, ma il compromesso sarebbe la riduzione della dimensione complessiva della rete e congestione di rete in specifici guasti. Questo approccio è molto simile alla tecnica descritta sopra, che consente ai Border Router di riassumere l'intero spazio di indirizzi del data center.

8.2.1. Compressione dello strato di dispositivi Tier 1

Per aggiungere più percorsi tra dispositivi Tier 1 e Tier 3, raggruppare i dispositivi Tier 2 a coppie, quindi collegare le coppie allo stesso gruppo di dispositivi Tier 1. Ciò equivale logicamente a « comprimere » i dispositivi Tier 1 in un gruppo di metà dimensione, fondendo i collegamenti sui dispositivi « compressi ». Il risultato è illustrato nella Figura 6. Ad esempio, in questa topologia DEV C e DEV D si collegano allo stesso insieme di dispositivi Tier 1 (DEV 1 e DEV 2), mentre prima si collegavano a gruppi distinti di dispositivi Tier 1.

              Tier 2       Tier 1       Tier 2
             +-----+      +-----+      +-----+
+------------| DEV |------| DEV |------|     |-------------+
|       +----|  C  |--++--|  1  |--++--|     |-----+       |
|       |    +-----+  ||  +-----+  ||  +-----+     |       |
|       |             ||           ||             |       |
|       |    +-----+  ||  +-----+  ||  +-----+     |       |
| +-----+----| DEV |--++--| DEV |--++--|     |-----+-----+ |
| |     | +--|  D  |------|  2  |------|     |---+ |     | |
| |     | |  +-----+      +-----+      +-----+   | |     | |
| |     | |                                      | |     | |
+-----+ +-----+                                +-----+ +-----+
| DEV | | DEV |                                |     | |     |
|  A  | |  B  | Tier 3                  Tier 3 |     | |     |
+-----+ +-----+                                +-----+ +-----+
  | |     | |                                    | |     | |
  O O     O O          <- Servers ->             O O     O O

                Figure 6: 5-Stage Clos Topology

Con questo progetto in atto, i dispositivi Tier 2 possono essere configurati per annunciare solo una route predefinita verso i dispositivi Tier 3. Se un collegamento tra Tier 2 e Tier 3 fallisce, il traffico verrà reindirizzato tramite il secondo percorso disponibile noto allo switch Tier 2. Resta impossibile annunciare una route di riepilogo che copra i prefissi di un singolo cluster dai dispositivi Tier 2, poiché ciascuno ha un solo percorso verso tale prefisso. Servirebbero server dual-homed. Si noti inoltre che questo progetto è resiliente solo a guasti di singolo collegamento. Un doppio guasto di collegamento può isolare un dispositivo Tier 2 da tutti i percorsi verso uno specifico dispositivo Tier 3, causando un buco nero di routing.

Una conseguenza della modifica di topologia proposta sarebbe una riduzione della capacità di porte dei dispositivi Tier 1. Ciò limita il numero massimo di dispositivi Tier 2 collegati e quindi la dimensione massima della rete del DC. Una rete più grande richiederebbe dispositivi Tier 1 diversi con maggiore densità di porte per implementare questo cambiamento.

Un altro problema è il ribilanciamento del traffico in caso di guasti di collegamento. Poiché esistono due percorsi da Tier 1 a Tier 3, un guasto del collegamento tra Tier 1 e switch Tier 2 farà sì che tutto il traffico che usava il collegamento guasto passi al percorso rimanente, raddoppiando l'utilizzo di quel collegamento.

8.2.2. Aggregazione virtuale semplice

È possibile un approccio completamente diverso alla summarizzazione delle route, purché l'obiettivo principale sia ridurre la dimensione della FIB consentendo al piano di controllo di diffondere l'informazione di routing completa. In primo luogo, si può osservare che in molti casi più prefissi, alcuni meno specifici, condividono lo stesso insieme di next hop (stesso gruppo ECMP). Ad esempio, dalla prospettiva dei dispositivi Tier 3, tutte le route apprese dai dispositivi Tier 2 a monte, inclusa la route predefinita, condivideranno lo stesso insieme di next hop BGP, purché non vi siano guasti nella rete. Ciò rende possibile usare una tecnica simile a quella descritta in [RFC6769] e installare solo la route meno specifica nella FIB, ignorando route più specifiche se condividono lo stesso insieme di next hop. Ad esempio, in condizioni normali di rete, solo la route predefinita deve essere programmata nella FIB.

Inoltre, se i dispositivi Tier 2 sono configurati con prefissi di riepilogo che coprono tutti i prefissi dei dispositivi Tier 3 collegati, la stessa logica può applicarsi anche ai dispositivi Tier 1 e, per induzione, agli switch Tier 2/Tier 3 in cluster diversi. Tali route di riepilogo dovrebbero comunque consentire la fuoriuscita di prefissi più specifici verso i dispositivi Tier 1 per rilevare disallineamenti negli insiemi di next hop se un particolare collegamento fallisce, cambiando l'insieme di next hop per un prefisso specifico.

Per ribadire, questa tecnica non riduce la quantità di stato del piano di controllo (cioè BGP UPDATE, dimensione BGP Loc-RIB), ma consente solo un utilizzo più efficiente della FIB rilevando prefissi più specifici che condividono il proprio insieme di next hop con un prefisso meno specifico che li include.

8.3. Mascheramento dei messaggi ICMP Destination Unreachable

Questa sezione discute alcuni aspetti operativi della mancata annunciazione in BGP delle sottoreti di collegamenti punto-punto, come precedentemente identificato come opzione nella Sezione 5.2.3. L'impatto operativo di questa decisione si vede usando il noto strumento « traceroute ». In particolare, gli indirizzi IP mostrati dallo strumento saranno gli indirizzi punto-punto del collegamento e quindi irraggiungibili per la connettività di gestione. Ciò complica alcune attività di troubleshooting.

Un modo per superare questa limitazione è usare il sottosistema DNS per creare voci « inverse » per questi indirizzi IP punto-punto che puntano allo stesso nome dell'indirizzo loopback. La connettività può essere stabilita risolvendo tale nome verso l'indirizzo IP « primario » del dispositivo, ad es. la sua interfaccia Loopback, sempre annunciata in BGP. Ciò crea però una dipendenza dal DNS, che può essere indisponibile durante un guasto.

Un'altra opzione è far eseguire al dispositivo di rete il mascheramento degli indirizzi IP, cioè riscrivere gli indirizzi IP sorgente dei messaggi ICMP appropriati inviati dal dispositivo con l'indirizzo IP « primario » del dispositivo. In particolare, il messaggio ICMP Destination Unreachable (tipo 3) codice 3 (port unreachable) e ICMP Time Exceeded (tipo 11) codice 0 sono richiesti per il corretto funzionamento di « traceroute ». Con questa modifica, le sonde « traceroute » inviate ai dispositivi torneranno sempre con l'indirizzo IP « primario » come sorgente, consentendo all'operatore di scoprire l'indirizzo IP « raggiungibile » del box. Lo svantaggio è nascondere l'indirizzo del « punto di ingresso » nel dispositivo. Se i dispositivi supportano [RFC5837], ciò può consentire il meglio dei due mondi fornendo informazioni sull'interfaccia in ingresso anche se l'indirizzo di ritorno è l'indirizzo IP « primario ».