7. Proprietà di convergenza del routing

Questa sezione esamina le proprietà di convergenza del routing nel progetto proposto. Si sostiene che una convergenza al di sotto del secondo è raggiungibile se l'implementazione supporta la disattivazione rapida delle sessioni di peering EBGP e aggiornamenti tempestivi di RIB e FIB in caso di guasto del collegamento associato.

7.1. Tempistiche di rilevamento dei guasti

BGP si affida in genere a un IGP per aggirare guasti di collegamento o nodo all'interno di un AS, e implementa un meccanismo a polling o guidato da eventi per ottenere aggiornamenti sugli cambi di stato dell'IGP. Il progetto di routing proposto non usa un IGP, quindi i meccanismi rimanenti per il rilevamento dei guasti sono il timeout dei keep-alive BGP (o altro tipo di keep-alive) e i trigger di guasto del collegamento.

Affidarsi solo ai pacchetti keep-alive BGP può comportare ritardi di convergenza elevati, dell'ordine di secondi multipli (in molte implementazioni BGP il valore minimo configurabile del timer di hold BGP è tre secondi). Tuttavia molte implementazioni BGP possono chiudere le sessioni EBGP locali in risposta all'evento « link down » per l'interfaccia in uscita usata per il peering BGP. Questa funzione è talvolta chiamata « fast fallover ». Poiché i collegamenti nei data center moderni sono prevalentemente in fibra punto-punto, un guasto dell'interfaccia fisica è spesso rilevato in millisecondi e innesca poi la riconvergenza BGP.

I collegamenti Ethernet possono supportare standard di segnalazione o rilevamento dei guasti come Connectivity Fault Management (CFM) descritto in [IEEE8021Q], rendendo il rilevamento più robusto. In alternativa, alcune piattaforme supportano Bidirectional Forwarding Detection (BFD) [RFC5880] per consentire rilevamento sub-secondo e segnalazione al processo BGP. L'uso dell'uno o dell'altro impone però requisiti aggiuntivi al software e possibilmente all'hardware del vendor, e può contraddire REQ1. Fino a poco tempo fa, con [RFC7130], BFD non consentiva neppure il rilevamento del guasto di un singolo membro di collegamento su un LAG, limitandone l'utilità in alcuni progetti.

7.2. Tempistiche di propagazione degli eventi

Nel progetto proposto va considerato l'impatto del MinRouteAdvertisementIntervalTimer BGP (timer MRAI), specificato nella Sezione 9.2.1.1 di [RFC4271]. Secondo lo standard, le implementazioni BGP devono distanziare i messaggi BGP UPDATE consecutivi di almeno MRAI secondi, spesso un valore configurabile. I messaggi BGP UPDATE iniziali dopo un evento che portano route ritirate di solito non sono influenzati da questo timer. Il timer MRAI può causare ritardi di convergenza significativi quando un parlante BGP « attende » che il nuovo percorso sia appreso dai peer e non dispone di informazioni di percorso di backup locali.

In una topologia Clos, ogni parlante EBGP ha tipicamente un solo percorso (i dispositivi Tier 2 non accettano percorsi da altri Tier 2 nello stesso cluster a causa dello stesso ASN) oppure N percorsi per lo stesso prefisso, dove N è molto grande, ad es. N=32 (fan-out ECMP verso il tier successivo). Quindi, se un collegamento verso un altro dispositivo da cui si riceve un percorso fallisce, non c'è alcun percorso di backup (ad es. dalla prospettiva di uno switch Tier 2 che perde il collegamento verso un dispositivo Tier 3), oppure il backup è già disponibile nel BGP Loc-RIB (ad es. da un dispositivo Tier 2 che perde il collegamento verso uno switch Tier 1). Nel primo caso, l'annuncio di ritiro BGP si propaga senza ritardo e innesca la riconvergenza sui dispositivi interessati. Nel secondo caso, il miglior percorso viene rivalutato e il gruppo ECMP locale corrispondente al nuovo insieme di next hop viene modificato. Se il percorso BGP era stato selezionato come migliore, un « implicit withdraw » viene inviato tramite messaggio BGP UPDATE come descritto nell'Opzione b della Sezione 3.1 di [RFC4271] a causa del cambiamento dell'attributo BGP AS_PATH.

7.3. Impatto dei fan-out della topologia Clos

La topologia Clos ha fan-out elevati, che in alcuni casi possono influire sulla convergenza « dall'alto verso il basso », come descritto in questa sezione. In caso di guasto del collegamento tra dispositivo Tier 3 e Tier 2, il dispositivo Tier 2 invierà messaggi BGP UPDATE a tutti i dispositivi Tier 1 a monte, ritirando i prefissi interessati. I dispositivi Tier 1, a loro volta, inoltreranno questi messaggi a tutti i dispositivi Tier 2 a valle (eccetto l'origine). I dispositivi Tier 2 diversi da quello che origina l'UPDATE dovrebbero quindi attendere che TUTTI i dispositivi Tier 1 a monte inviino un messaggio UPDATE prima di rimuovere i prefissi interessati e inviare l'UPDATE corrispondente a valle verso i dispositivi Tier 3 collegati. Se il dispositivo Tier 2 originario o i dispositivi Tier 1 che inoltrano introducono ritardo nelle annunci UPDATE, il risultato può essere una « dispersione » dei messaggi UPDATE della durata di secondi multipli. Per evitare tale comportamento, le implementazioni BGP devono supportare le « update groups ». Un'« update group » è definita come un insieme di vicini che condividono la stessa policy in uscita: il parlante locale invierà gli aggiornamenti BGP ai membri del gruppo in modo sincrono.

L'impatto di tale « dispersione » cresce con la dimensione del fan-out della topologia e può crescere anche sotto churn di convergenza elevato. Alcuni operatori possono essere tentati di introdurre funzionalità di tipo « route flap dampening » incluse dai vendor per ridurre l'impatto sul piano di controllo dei prefissi che oscillano rapidamente. Tuttavia, a causa dei problemi descritti con falsi positivi in queste implementazioni, specialmente in tali eventi di « dispersione », non è raccomandabile abilitare questa funzione in questo progetto. Contesto e problemi del « route flap dampening » e possibili modifiche implementative sono ben descritti in [RFC7196].

7.4. Ambito di impatto del guasto

Una rete si considera convergente in risposta a un guasto una volta che tutti i dispositivi nell'ambito di impatto del guasto sono stati informati dell'evento e hanno ricalcolato le loro RIB e di conseguenza aggiornato le loro FIB. Un ambito di impatto più ampio di solito significa convergenza più lenta, poiché più dispositivi devono essere notificati, e produce una rete meno stabile. Questa sezione descrive i vantaggi di BGP rispetto ai protocolli link-state nel ridurre l'ambito di impatto dei guasti in una topologia Clos.

BGP si comporta come un protocollo distance-vector nel senso che solo il miglior percorso dal punto di vista del router locale viene inviato ai vicini. Pertanto alcuni guasti sono mascherati se il nodo locale trova immediatamente un percorso di backup e non deve inviare aggiornamenti oltre. Nel caso peggiore, tutti i dispositivi in una topologia di data center devono ritirare completamente un prefisso o aggiornare i gruppi ECMP nelle loro FIB. Tuttavia molti guasti non avranno un impatto così ampio. Vi sono due tipi principali di guasto in cui l'ambito si riduce:

• Guasto di un collegamento tra dispositivi Tier 2 e Tier 1 : In questo caso un dispositivo Tier 2 aggiorna i gruppi ECMP interessati rimuovendo il collegamento guasto. Non è necessario inviare nuove informazioni a valle ai dispositivi Tier 3, a meno che il percorso non sia stato selezionato come migliore dal processo BGP, nel qual caso basta un « implicit withdraw » e ciò non dovrebbe influire sull'inoltro. Il dispositivo Tier 1 interessato perde l'unico percorso disponibile per raggiungere un particolare cluster e dovrà ritirare i prefissi associati. Tale processo di ritiro del prefisso riguarda solo i dispositivi Tier 2 direttamente collegati al dispositivo Tier 1 interessato. I dispositivi Tier 2 che ricevono messaggi BGP UPDATE che ritirano prefissi dovranno semplicemente aggiornare i loro gruppi ECMP. I dispositivi Tier 3 non sono coinvolti nel processo di riconvergenza.

• Guasto di un dispositivo Tier 1 : In questo caso tutti i dispositivi Tier 2 direttamente collegati al nodo guasto dovranno aggiornare i loro gruppi ECMP per tutti i prefissi IP da un cluster non locale. I dispositivi Tier 3 non sono di nuovo coinvolti nel processo di riconvergenza, ma possono ricevere « implicit withdraw » come sopra.

Anche in caso di tali guasti in cui molti prefissi IP dovranno essere riprogrammati nella FIB, vale la pena notare che tutti questi prefissi condividono un singolo gruppo ECMP su un dispositivo Tier 2. Pertanto, per implementazioni con FIB gerarchica, è necessaria una sola modifica alla FIB. « FIB gerarchica » qui significa struttura FIB in cui le informazioni di inoltro next-hop sono memorizzate separatamente dalla tabella di lookup dei prefissi, e quest'ultima contiene solo puntatori alle rispettive informazioni di inoltro. Vedere [BGP-PIC] per la discussione sulle gerarchie FIB e la convergenza rapida.

Sebbene BGP riduca l'ambito del guasto in alcuni casi, un'ulteriore riduzione del dominio di guasto mediante summarization non è sempre possibile con il progetto proposto, poiché tale tecnica può creare buchi neri di routing come già menzionato. Pertanto il peggiore ambito di impatto del guasto sul piano di controllo è l'intera rete, ad es. in caso di guasto del collegamento tra dispositivi Tier 2 e Tier 3. La quantità di prefissi impattati in questo caso sarebbe molto inferiore rispetto a un guasto negli strati superiori di una topologia Clos. La proprietà di avere un ambito di guasto così ampio non derige dalla scelta di EBGP nel progetto ma dall'uso della topologia Clos.

7.5. Micro-loop di routing

Quando un dispositivo a valle, ad es. Tier 2, perde tutti i percorsi per un prefisso, ha normalmente la route predefinita verso il dispositivo a monte, in questo caso Tier 1. Di conseguenza può verificarsi la situazione in cui uno switch Tier 2 perde un prefisso ma uno switch Tier 1 ha ancora il percorso verso lo switch Tier 2; ciò produce un micro-loop transitorio, poiché lo switch Tier 1 continua a passare i pacchetti verso il prefisso interessato allo switch Tier 2, e Tier 2 li rimbalza di nuovo usando la route predefinita. Questo micro-loop dura quanto basta affinché il dispositivo a monte aggiorni completamente le tabelle di inoltro.

Per minimizzare l'impatto di tali micro-loop, gli switch Tier 2 e Tier 1 possono essere configurati con route statiche « discard » o « null » più specifiche della route predefinita per i prefissi mancanti durante la convergenza della rete. Per gli switch Tier 2, la route di scarto deve essere una route di riepilogo che copra tutte le sottoreti server dei dispositivi Tier 3 sottostanti. Per i dispositivi Tier 1, la route di scarto deve essere un riepilogo che copra le sottoreti di indirizzi IP server allocate per l'intero data center. Tali route di scarto hanno precedenza solo per la durata della convergenza della rete, finché il dispositivo non apprende un prefisso più specifico tramite un nuovo percorso.