Nel post precedente sulle Reti di Clos, ho accennato alla fine alcune problematiche legate alla scelta del protocollo di routing da utilizzare in questo tipo di topologie, siano esse a due o tre livelli.
Per le IP Fabric dei Data Center di dimensioni medio-piccole ho detto che i classici protocolli IGP, come OSPF o IS-IS vanno più che bene. Per Data Center di grandi dimensioni, come potrebbero ad esempio essere quelli dei grandi fornitori di servizi Cloud pubblici, questi protocolli mostrano però seri limiti di scalabilità a causa della complessa struttura dati di cui necessitano (in particolare il Link State DataBase (LSDB) e il numero di adiacenze da mantenere).
Nel post precedente mi sono limitato ad enunciare quali caratteristiche dovrebbe avere un protocollo di routing in una IP Fabric di grandi dimensioni. Riporto qui l'elenco per completezza:
- Essere scalabile in termini di gestione dei prefissi IP, ossia poter gestire senza problemi tabelle di decine di migliaia di prefissi IP.
- Avere una implementazione semplice, stabile e supportata da tutti i principali costruttori, così da consentire l’interlavoro senza problemi.
- Minimizzare l’ambito di propagazione di un fuori servizio di un nodo o di un link, in modo da avere una rete più stabile ed avere tempi di convergenza molto contenuti (dell’ordine delle decine di msec).
- Consentire un minimo di gestione del traffico, preferibilmente attraverso un controllo diretto del Next-Hop, utilizzando metriche facilmente manipolabili.
- Consentire in modo semplice il multipath (o ECMP o Load balancing, tutti sinonimi).
- Infine, dovrebbe poter funzionare senza l’ausilio di altri protocolli di routing.
Ma negli ultimi 2-3 anni si va facendo sempre più strada questa idea, tanto che c'è anche un draft IETF che ne traccia le idee fondamentali. E ci sono già realizzazioni pratiche (vedi le conclusioni per un esempio "eclatante"). Tanto che si parla (in modo un po' improprio) di reti IGP-free. Dico improprio perché in realtà è il BGP a giocare il ruolo di protocollo IGP, quindi un protocollo IGP c'è. Ma poiché storicamente il BGP è considerato un protocollo EGP, da qui la nomenclatura che qualcuno utilizza di IGP-free.
Perché questa idea è venuta fuori solo ora ? Perché il BGP non è mai stato considerato in passato un candidato plausibile per giocare il ruolo di protocollo IGP ? Come spesso accade, le ragioni son un po' storiche e un po' di miti sbagliati che circondano il BGP.
- Il BGP è stato sempre percepito come un protocollo "degli ISP", e sempre poco considerato nelle reti Enterprise e nelle applicazioni nei Data Center, se non per il collegamento agli ISP che forniscono l'accesso a Internet.
- Il BGP è stato sempre percepito come un protocollo lento a convergere. Ma per sfatare questo mito negativo, ho scritto molto in passato, e in questo post potete trovare le indicazioni per scaricare il documento conclusivo.
- Nelle reti grandi dimensioni, il BGP viene utilizzato internamente per importare i prefissi esterni al dominio di routing. E questo richiede la presenza di un protocollo IGP per realizzare sessioni iBGP tra router remoti, e l'utilizzo di Route Reflector o (più raramente) di Confederazioni BGP per mitigare il numero di sessioni iBGP richieste.
- Infine, il BGP è un protocollo che richiede molta configurazione manuale, mancando della proprietà di auto-discovery tipica dei protocolli IGP, che scoprono automaticamente i neighbor attraverso il classico (sotto-)protocollo Hello.
A tutti questi pregiudizi si può rispondere punto per punto. Il BGP può essere preferibile ai classici protocolli IGP, nelle IP Fabric di grandi dimensioni, per questa serie di ragioni:
- Il BGP è molto meno complesso di un protocollo IGP, e la struttura dati necessaria al suo funzionamento è molto più semplice. In particolare, non ha bisogno della conoscenza precisa della topologia della rete (logica) e quindi non ha bisogno di avere e mantenere aggiornato un LSDB. Inoltre non ha bisogno di un protocollo specializzato per creare e mantenere le adiacenze di routing. Il BGP come noto, utilizza per lo scambio dei messaggi di routing il classico protocollo TCP (porta well-known 179).
- In caso di fuori servizio di un link, l'ambito di propagazione dei messaggi BGP UPDATE è di norma inferiore. Pensate ad esempio a un fuori servizio di un link tra un Leaf e uno Spine, come riportato nella figura seguente. Per SP-1 il best-path non cambia, per cui non invia nessun nuovo annuncio. Ciò che avviene è semplicemente la cancellazione dalla tabella BGP di SP-1, dell'annuncio ricevuto da L2. Per contro, in una situazione del genere con un protocollo Link-State, sia esso OSPF o IS-IS, l'ambito di propagazione dei LSA/LSP che annunciano il cambio di topologia, è l'intera area (o Backbone IS-IS). Ci sarebbe poi anche un altro aspetto, sebbene meno importante. Nei protocolli Link-State la validità dei LSA/LSP ha un tempo limitato, e quindi questi devono essere continuamente "rinfrescati", anche se il periodo dei rinfreschi è di norma molto lungo e non crea alcun problema di scalabilità. Per contro nel BGP, un annuncio non scade mai, e può essere ritirato solo esplicitamente con un nuovo messaggio BGP UPDATE.
- L'implementazione del BGP nelle IP Fabric con la classica topologia Leaf-and-Spine, non richiede la configurazione di politiche di routing complesse, che sono la parte più "spinosa" del BGP. L'applicazione del BGP in questo scenario, richiede la semplice propagazione delle informazioni di routing.
- Il BGP, se implementato senza o con poche minimali politiche di routing, è molto più semplice da gestire in fase di troubleshooting. Infatti, è abbastanza semplice consultare le tabelle degli annunci BGP e da queste dedurre i malfunzionamenti. Per contro, nei protocolli IGP Link-State, il troubleshooting richiede una profonda conoscenza delle regole di funzionamento del protocollo e di saper "leggere" molto bene il (complesso) contenuto del LSDB.
- Anche se è vero che la configurazione del BGP è più "manuale" rispetto a quella dei classici protocolli IGP, questo è un problema che può essere risolto con buone tecniche di Network Automation. Inoltre, utilizzando i "trucchi del mestiere", è possibile realizzare in modo relativamente semplice dei template di configurazione, che consentano di facilitare il deployment (molto semplice per gli Spine, un po' meno per i Leaf). Poi, ci sono alcune implementazioni molto "creative" del BGP che consentono di semplificare ulteriormente le procedure di configurazione (vedi ad esempio alcune soluzioni introdotte da Cumulus Network, descritte in questo post).
L'elenco potrebbe continuare, ma credo sia sufficiente per convincervi. Ma è ora di passare agli aspetti progettuali. Prima di questo però è doveroso dirvi che ciò che dirò nel seguito, per chi conosce il BGP, rasenta la banalità. Nel senso che l'utilizzo del BGP nelle IP Fabric dei Data Center, non richiede alcuna nuova funzionalità, ma solo quelle ben note e a volte meno note ma comunque presenti da tempo nelle implementazioni BGP dei principali vendor (es. Cisco, Juniper).
ALCUNE LINEE GUIDA
L'utilizzo del BGP come protocollo IGP nelle reti di Clos, pone alcune questioni progettuali interessanti. In questa sezione voglio darvi alcune linee guida generali. Nelle prossime vedremo qualche dettaglio.
Però, prima di parlare di linee guida, è necessario risolvere un dilemma preliminare: è meglio utilizzare sessioni iBGP o eBGP ? Una questione simile è stata affrontata in questo post e questo sulle DMVPN.
In questo scenario, l'utilizzo di sessioni iBGP, benché a prima vista più semplice, non è conveniente per almeno queste ragioni:
SCELTA DEI NUMERI DI AS
Come appena detto sopra, la best-practice è utilizzare numeri di AS privati. Nel caso di AS a 16 bit, i numeri disponibili sono 1.023. Qualora si volesse assegnare a ciascun Leaf e Spine un diverso numero di AS (pratica comunque sconsigliata poiché renderebbe la configurazione e l'esercizio molto più pesanti), questi 1.023 numeri potrebbero non essere sufficienti.
Ci sono due modi per aggirare il problema:
Ovviamente i vendor mettono a disposizione dei workaround per evitare il problema. Nelle piattaforme Cisco, tutto si risolve con il comando "neighbor ... allowas-in [numero]" eseguito sui Leaf. Il valore numero, che se omesso è pari a 3, indica che il controllo dell'AS-PATH viene disabilitato se il numero di volte che il proprio numero di AS compare nell'AS_PATH, è inferiore o al più uguale a numero. Nel nostro esempio è sufficiente porre numero = 1, o in ogni caso ometterlo.
Nelle piattaforme Juniper la storia è leggermente più complessa perché vi è bisogno di due comandi. Il primo, "neighbor ... advertise-peer-as" va eseguito sugli Spine, e consente a questi di inviare annunci a BGP peer che appartengono a un AS già presente nell'AS_PATH. Senza questo comando, gli Spine non propagherebbero ai Leaf gli annunci ricevuti dagli altri Leaf, poiché tutti i Leaf appartengono allo stesso AS. Il secondo comando è l'analogo di quello visto per i router Cisco, consente di disabilitare il controllo dell'AS_PATH: "neighbor ... {family inet {unicast { loops [numero] }}}". Il valore numero ha lo stesso significato visto sopra per i router Cisco.
In topologie più complesse sono possibili diversi schemi di allocazione e riutilizzo dei numeri di AS. Nel già citato draft IETF "draft-ietf-rtgwg-bgp-routing-large-dc-07", vi è un esempio di allocazione per una rete di Clos a tre livelli (5 stadi), in cui la topologia è ripartita in cluster, e l'interconnessione tra cluster avviene attraverso pochi potenti switch, collocati al terzo livello della rete di Clos. I singoli cluster hanno un'architettura Leaf-and-Spine a due livelli. Per semplificare la gestione, il draft propone di riutilizzare gli stessi numeri di AS tra i singoli cluster, assegnando però all'interno di ciascun cluster numeri di AS diversi sia ai Leaf che agli Spine. Agli switch di interconnessione al terzo livello, viene invece assegnato lo stesso numero di AS.
AGGREGAZIONE DEI PREFISSI
Una rete di Clos ha molti prefissi, in parte interni, ad esempio le subnet dei link punto-punto e delle interfacce di Loopback, e in parte esterni, ad esempio le subnet dei server. Inserire tutti questi prefissi nel processo BGP e quindi annunciarli, potrebbe portare a FIB molto grandi. Per cui è bene valutare accuratamente i prefissi da annunciare via BGP.
Ad esempio, le subnet dei link punto-punto, potrebbero anche non essere annunciate, ma questo complicherebbe le operazioni di monitoring della rete (es. il classico traceroute verso gli indirizzi IP dei link punto-punto non sarebbe possibile). Un'alternativa è quella di predisporre un piano di numerazione che consenta di aggregare le subnet dei link punto-punto, riducendo così drasticamente il numero degli annunci.
Le interfacce di Loopback vanno invece sempre annunciate, perché vengono tipicamente utilizzate come indirizzi IP delle interfacce VTEP nelle VXLAN, o per altri tipi di incapsulamento nelle Overlay Virtual Network.
Le subnet dei server vanno annunciate singolarmente. Non è buona regola eseguire alcun tipo di aggregazione sugli Spine, poiché si potrebbero avere facilmente situazioni di black-holing del traffico. Vediamo un esempio, con l'ausilio della figura seguente.
I due Leaf L1 e L2 annunciano a SP-1 e SP-2 le 4 subnet 10.1.X.0/24, X=0,...,3. Su SP-1 è configurata l'aggregazione per annunciare il singolo prefisso aggregato 10.1.0.0/22. Lo stesso accade su SP-2, non riportato nella figura per motivi di spazio. Il Leaf L3 (come gli altri due) riceverà due annunci del prefisso aggregato 10.1.0.0/22, rispettivamente da SP-1 e SP-2. Supponiamo che su L3 sia abilitato il BGP multipath. Ciò significa che il traffico Leaf-to-Leaf generato da L3 verrà ripartito più o meno equamente tra SP-1 e SP-2. Ora, si supponga che collegamento tra L1 e SP-1 vada fuori servizio. Ne segue che tutto il traffico originato da L3 e diretto alle due subnet attestate a L1, che fa transito su SP-1, non arriverà mai a destinazione (a destinazione arriva solo la porzione di traffico che fa transito su SP-2).
Vi sono dei workaround a questo problema, ma la soluzione migliore è di evitarlo alla radice, non eseguendo sugli Spine alcun tipo di aggregazione. Tenete conto che il BGP è in grado di gestire un elevato numero di prefissi senza alcun tipo di problema (pensate un attimo ai router della Big Internet), quindi anche senza effettuare aggregazioni, tutto è gestibile.
LOAD BALANCING
Il Load Balancing (che nel gergo del BGP viene indicato come BGP Multipath) è un po' l'essenza stessa delle reti di Clos. Il BGP, come noto, supporta sia ECMP (Equal Cost Multi-Path) che (forse un po' meno noto) weighted ECMP, attraverso l'utilizzo dell'attributo "Bandwidth Extended Community" (chi non conoscesse l'utilizzo di questo attributo, può consultare il mio libro "BGP: dalla Teoria alla Pratica" Ed. Reiss Romoli, 2011, Capitolo 12, sezione 12.2.5).
I percorsi utilizzabili dal BGP Multipath dipendono dalla topologia della rete di Clos. Nel caso semplice di rete a tre stadi, ogni Leaf ha a disposizione un numero di percorsi da sfruttare per il BGP Multipath pari al numero degli Spine. Nel caso di topologie a cinque stadi il numero di percorsi aumenta notevolmente. Però attenzione, gli switch hanno sempre un limite massimo di percorsi su cui fare Load Balancing. Quale sia questo limite dipende dalla piattaforma utilizzata.
In funzione dei numeri di AS adottati, potrebbe essere necessario adottare qualche accorgimento aggiuntivo. Ad esempio, nel caso si utilizzassero per i Leaf, numeri di AS diversi, potrebbe accadere che i Leaf ricevano annunci della stessa subnet con AS_PATH di uguale lunghezza ma con diversi numeri di AS. Ora, una regola adottata da alcuni vendor (NOTA: la RFC 4271 non dice alcunché circa il BGP Multipath, lasciando ai costruttori la sua implementazione) è che affinché il BGP Multipath sia possibile, gli attributi AS_PATH devono coincidere sia in lunghezza che nei numeri di AS. L’IOS Cisco mette a disposizione il comando “bgp bestpath as-path multipath-relax”, per rilassare questo vincolo. Con questo comando, gli AS_PATH possono essere diversi, ma devono comunque avere la stessa lunghezza.
INTERCONNESSIONE CON L'ESTERNO
L'interconnessione di un Data Center IGP-free con l'esterno segue regole abbastanza classiche, sempre con qualche accorgimento.
L'interconnessione con l'esterno avviene di norma attraverso switch dedicati, chiamati "Border Router", interconnessi al livello più alto della rete di Clos (quindi agli Spine). Lo scambio delle informazioni di routing con ISP esterni, avviene in modo assolutamente classico attraverso sessioni eBGP.
Un accorgimento da adottare, quando si annuncia un prefisso verso gli ISP, è la rimozione degli AS (privati) utilizzati all'interno della IP Fabric. Questo per evitare collisioni con altri AS che potrebbero utilizzare gli stessi numeri (possibile in quanto privati). Benché non standard, la rimozione degli AS privati è supportata sia da Cisco che da Juniper. Cisco mette a disposizione il comando IOS "neighbor ... remove-private-as", che consente di eliminare una stringa nell'AS_PATH, di AS privati contigui. Maggiori dettagli sulla documentazione Cisco (vedi ad esempio questo documento). L'analogo comando nel JUNOS è "neighbor ... { remove-private;}". Anche qui, maggiori dettagli sulla documentazione del JUNOS (vedi ad esempio questo documento).
Per quanto riguarda la gestione del traffico uscente dal Data Center (outbound), la soluzione più semplice è farsi inviare dagli ISP una default-route e quindi propagarla via eBGP all'interno della IP Fabric. Questo consente anche di garantire automaticamente un percorso alternativo, in caso di fuori servizio di un link verso un ISP. Inoltre, consente un ritiro automatico della default-route in caso di perdita di connettività verso tutti gli ISP, evitando che il traffico outbound si propaghi inutilmente dai Leaf verso i Border Router. Alternative basate su complicati meccanismi di conditional route advertisement, sebbene percorribili, sono da evitare.
Per la gestione del traffico entrante nel Data Center (inbound), anche qui le tecniche da utilizzare sono quelle classiche del BGP. L'unico accorgimento che è possibile adottare, ma è un classico, è aggregare il più possibile sui Border Router, i prefissi annunciati agli ISP.
CONCLUSIONI
In questo post ho illustrato un'applicazione abbastanza atipica del BGP: il suo utilizzo come protocollo IGP, senza l'ausilio, come di norma avviene, di un protocollo IGP classico, come ad esempio OSPF o IS-IS. L'idea è per certi versi un po' rivoluzionaria, ma nello scenario delle IP Fabric dei grandi Data Center ha un suo razionale, che in questo post ho cercato di mettere in luce.
Non so se vi ho convinto, ma qualora non ci fossi riuscito, volete un esempio di un gigantesco Data Center la cui IP Fabric è IGP-free e utilizza solo BGP (in particolare, eBGP) ? Guardate qui, dovrebbe esservi familiare ... Una sorta di Back to the future !!!
Coming up Next ... un post sull'Inter-VXLAN Routing.
ALCUNE LINEE GUIDA
L'utilizzo del BGP come protocollo IGP nelle reti di Clos, pone alcune questioni progettuali interessanti. In questa sezione voglio darvi alcune linee guida generali. Nelle prossime vedremo qualche dettaglio.
Però, prima di parlare di linee guida, è necessario risolvere un dilemma preliminare: è meglio utilizzare sessioni iBGP o eBGP ? Una questione simile è stata affrontata in questo post e questo sulle DMVPN.
In questo scenario, l'utilizzo di sessioni iBGP, benché a prima vista più semplice, non è conveniente per almeno queste ragioni:
- L'utilizzo di sessioni iBGP obbliga all'utilizzo di Route Reflector (RR) (NOTA: l'alternativa sarebbe utilizzare un full mesh di sessioni iBGP, ma credo che nessuno possa pensare, neanche lontanamente, a questo, in un Data Center di grandi dimensioni ...). Infatti, quando un Leaf annuncia a uno Spine una subnet IP, questa deve necessariamente essere annunciata agli altri Leaf. Per la classica regola dello Split Horizon delle sessioni iBGP, questo non avverrebbe senza l'ausilio di RR, che sono gli unici tipi di router a cui è permesso violare la regola dello Split Horizon. Il lettore potrebbe pensare che il problema sia facilmente aggirabile attraverso la generazione di una default-route da parte dei router Spine. In teoria si, ma in pratica si avrebbero facilmente situazioni in cui il traffico cade in un black-hole. Ritornate un momento alla figura precedente, supponendo che i due Spine generino verso i tre Leaf una default-route via BGP. Il Leaf L3 (come gli altri due) riceverà due default-route, rispettivamente da SP-1 e SP-2. Supponiamo che su L3 sia abilitato il BGP multipath. Ciò significa che il traffico Leaf-to-Leaf generato da L3, verrà ripartito più o meno equamente tra SP-1 e SP-2. Ora, si supponga come nella figura sopra, che collegamento tra L2 e SP-1 vada fuori servizio. Ne segue che tutto il traffico originato da L3 e diretto a L2, che fa transito su SP-1, non arriverà mai a destinazione (a destinazione arriva solo la porzione di traffico L3-->L2 che fa transito su SP-2).
- L'utilizzo di sessioni iBGP insieme ai RR, impone la presenza di un protocollo IGP (a meno di possibili escamotage offerti dai vendor). Si consideri ancora la figura sopra, ipotizzando la presenza di sessioni iBGP tra Leaf e Spine e che i due Spine svolgano anche il ruolo di RR. La subnet IP 10.1.1.0/24 viene annunciata da L1 (e anche da L2) a SP-1, che essendo un RR, propaga l'annuncio ai suoi RR-Client, tra cui L3. Nel fare questo, come noto, i RR non cambiano il BGP Next-Hop. Per cui l'annuncio arriverà a R3 con un BGP Next-Hop che coincide con l'indirizzo IP 172.16.11.11. Ora, senza un protocollo IGP che annunci a L3 un percorso verso questo indirizzo, L3 scarta l'annuncio (chi conosce le basi elementari del BGP sa bene perché). Questo va contro i desiderata esposti all'inizio (vedi l'ultimo punto). Alcuni vendor, ad esempio Cisco, mettono a disposizione un comando che consente di evitare questo problema. Il comando è "neighbor ... next-hop-self all", che quando eseguito sui RR, consente a questi di cambiare il BGP Next-Hop (contravvenendo alla regole di default dei RR), sostituendo al BGP Next-Hop originale, il proprio indirizzo IP utilizzato per le sessioni iBGP. Ma non tutti supportano un comando simile.
- La presenza dei RR distrugge la possibilità di effettuare il Load balancing (o meglio, BGP multipath). Ho già discusso questo problema nel documento riassuntivo sulla convergenza BGP che potete scaricare qui. Comunque, per ripasso, considerate di nuovo la figura sopra. Entrambi i Leaf L1 e L2 annunciano agli Spine SP-1 e SP-2 la subnet IP 10.1.1.0/24. SP-1 e SP-2, che hanno il ruolo di RR, eseguono il processo di selezione sui due annunci ricevuti da L1 e L2, e annunciano i best-path risultanti a L3. Entrambi questi best-path, per come è fatta la rete, avranno identico BGP Next-Hop, impedendo così la possibilità del BGP Multipath (manca la Path diversity !) Questo è sicuramente il difetto maggiore nell'utilizzo delle sessioni iBGP, difetto che in realtà può essere "corretto" attraverso l'utilizzo di funzionalità tipo Add Path o Diverse Path (vedi il documento riassuntivo sulla convergenza del BGP). Ma non sempre gli switch supportano queste funzionalità.
- Il troubleshooting risulterebbe più complesso poiché non è possibile "tracciare" il percorso degli annunci BGP, mancando completamente l'AS_PATH. Da questo punto di vista sarebbe più utile utilizzare Confederazioni BGP piuttosto che RR, ma la progettazione risulterebbe più complessa.
In conclusione, è meglio utilizzare sessioni eBGP, piuttosto che sessioni iBGP (spero di avervi convinto ...). Assodato ciò, vediamo alcune linee guida progettuali.
- Nella realizzazione delle sessioni eBGP, utilizzare gli indirizzi IP dei link punto-punto. Non utilizzare indirizzi IP di interfacce di Loopback, nemmeno nel caso di collegamenti multi-link. Questo consente di velocizzare il rilevamento della perdita di una sessione eBGP, grazie alla funzionalità di BGP Fast External Fallover. Per quanto riguarda la numerazione IP, per i link punto-punto, se supportato dalle piattaforme utilizzate, è buona regola utilizzare prefissi /31, tutti tratti da una unica rete IP (es. 172.16/16).
- Utilizzare numeri di AS privati. E' sufficiente utilizzare numeri di AS a 16 bit. Ricordo che l'intervallo di numeri di AS privati è 64.512 - 65.534 (RFC 6996, Luglio 2013).
- Per risparmiare numeri di AS e soprattutto per semplificare le procedure di configurazione, utilizzare lo stesso numero di AS per tutti gli switch dello stesso livello nella rete di Clos.
- Evitare l'aggregazione dei prefissi a livello di Spine, perché potrebbe portare a situazioni di black-hole del traffico (il motivo verrà spiegato nel seguito).
Illustrerò ora qualche dettaglio.
SCELTA DEI NUMERI DI AS
Come appena detto sopra, la best-practice è utilizzare numeri di AS privati. Nel caso di AS a 16 bit, i numeri disponibili sono 1.023. Qualora si volesse assegnare a ciascun Leaf e Spine un diverso numero di AS (pratica comunque sconsigliata poiché renderebbe la configurazione e l'esercizio molto più pesanti), questi 1.023 numeri potrebbero non essere sufficienti.
Ci sono due modi per aggirare il problema:
- Utilizzare numeri di AS a 32 bit (RFC 6793, Dicembre 2012). Il problema con questa soluzione è che non tutti i Leaf e Spine potrebbero supportare numeri di AS a 32 bit, e inoltre renderebbe tutta la gestione della rete molto più complessa.
- Riutilizzare i numeri di AS (già citato sopra). Così facendo si semplificano di molto le configurazioni, e il troubleshooting diviene più semplice. Per queste ragioni, è questo il metodo da preferire. Metodo che però richiede qualche accorgimento aggiuntivo.
Ovviamente i vendor mettono a disposizione dei workaround per evitare il problema. Nelle piattaforme Cisco, tutto si risolve con il comando "neighbor ... allowas-in [numero]" eseguito sui Leaf. Il valore numero, che se omesso è pari a 3, indica che il controllo dell'AS-PATH viene disabilitato se il numero di volte che il proprio numero di AS compare nell'AS_PATH, è inferiore o al più uguale a numero. Nel nostro esempio è sufficiente porre numero = 1, o in ogni caso ometterlo.
Nelle piattaforme Juniper la storia è leggermente più complessa perché vi è bisogno di due comandi. Il primo, "neighbor ... advertise-peer-as" va eseguito sugli Spine, e consente a questi di inviare annunci a BGP peer che appartengono a un AS già presente nell'AS_PATH. Senza questo comando, gli Spine non propagherebbero ai Leaf gli annunci ricevuti dagli altri Leaf, poiché tutti i Leaf appartengono allo stesso AS. Il secondo comando è l'analogo di quello visto per i router Cisco, consente di disabilitare il controllo dell'AS_PATH: "neighbor ... {family inet {unicast { loops [numero] }}}". Il valore numero ha lo stesso significato visto sopra per i router Cisco.
In topologie più complesse sono possibili diversi schemi di allocazione e riutilizzo dei numeri di AS. Nel già citato draft IETF "draft-ietf-rtgwg-bgp-routing-large-dc-07", vi è un esempio di allocazione per una rete di Clos a tre livelli (5 stadi), in cui la topologia è ripartita in cluster, e l'interconnessione tra cluster avviene attraverso pochi potenti switch, collocati al terzo livello della rete di Clos. I singoli cluster hanno un'architettura Leaf-and-Spine a due livelli. Per semplificare la gestione, il draft propone di riutilizzare gli stessi numeri di AS tra i singoli cluster, assegnando però all'interno di ciascun cluster numeri di AS diversi sia ai Leaf che agli Spine. Agli switch di interconnessione al terzo livello, viene invece assegnato lo stesso numero di AS.
AGGREGAZIONE DEI PREFISSI
Una rete di Clos ha molti prefissi, in parte interni, ad esempio le subnet dei link punto-punto e delle interfacce di Loopback, e in parte esterni, ad esempio le subnet dei server. Inserire tutti questi prefissi nel processo BGP e quindi annunciarli, potrebbe portare a FIB molto grandi. Per cui è bene valutare accuratamente i prefissi da annunciare via BGP.
Ad esempio, le subnet dei link punto-punto, potrebbero anche non essere annunciate, ma questo complicherebbe le operazioni di monitoring della rete (es. il classico traceroute verso gli indirizzi IP dei link punto-punto non sarebbe possibile). Un'alternativa è quella di predisporre un piano di numerazione che consenta di aggregare le subnet dei link punto-punto, riducendo così drasticamente il numero degli annunci.
Le interfacce di Loopback vanno invece sempre annunciate, perché vengono tipicamente utilizzate come indirizzi IP delle interfacce VTEP nelle VXLAN, o per altri tipi di incapsulamento nelle Overlay Virtual Network.
Le subnet dei server vanno annunciate singolarmente. Non è buona regola eseguire alcun tipo di aggregazione sugli Spine, poiché si potrebbero avere facilmente situazioni di black-holing del traffico. Vediamo un esempio, con l'ausilio della figura seguente.
I due Leaf L1 e L2 annunciano a SP-1 e SP-2 le 4 subnet 10.1.X.0/24, X=0,...,3. Su SP-1 è configurata l'aggregazione per annunciare il singolo prefisso aggregato 10.1.0.0/22. Lo stesso accade su SP-2, non riportato nella figura per motivi di spazio. Il Leaf L3 (come gli altri due) riceverà due annunci del prefisso aggregato 10.1.0.0/22, rispettivamente da SP-1 e SP-2. Supponiamo che su L3 sia abilitato il BGP multipath. Ciò significa che il traffico Leaf-to-Leaf generato da L3 verrà ripartito più o meno equamente tra SP-1 e SP-2. Ora, si supponga che collegamento tra L1 e SP-1 vada fuori servizio. Ne segue che tutto il traffico originato da L3 e diretto alle due subnet attestate a L1, che fa transito su SP-1, non arriverà mai a destinazione (a destinazione arriva solo la porzione di traffico che fa transito su SP-2).
Vi sono dei workaround a questo problema, ma la soluzione migliore è di evitarlo alla radice, non eseguendo sugli Spine alcun tipo di aggregazione. Tenete conto che il BGP è in grado di gestire un elevato numero di prefissi senza alcun tipo di problema (pensate un attimo ai router della Big Internet), quindi anche senza effettuare aggregazioni, tutto è gestibile.
LOAD BALANCING
Il Load Balancing (che nel gergo del BGP viene indicato come BGP Multipath) è un po' l'essenza stessa delle reti di Clos. Il BGP, come noto, supporta sia ECMP (Equal Cost Multi-Path) che (forse un po' meno noto) weighted ECMP, attraverso l'utilizzo dell'attributo "Bandwidth Extended Community" (chi non conoscesse l'utilizzo di questo attributo, può consultare il mio libro "BGP: dalla Teoria alla Pratica" Ed. Reiss Romoli, 2011, Capitolo 12, sezione 12.2.5).
I percorsi utilizzabili dal BGP Multipath dipendono dalla topologia della rete di Clos. Nel caso semplice di rete a tre stadi, ogni Leaf ha a disposizione un numero di percorsi da sfruttare per il BGP Multipath pari al numero degli Spine. Nel caso di topologie a cinque stadi il numero di percorsi aumenta notevolmente. Però attenzione, gli switch hanno sempre un limite massimo di percorsi su cui fare Load Balancing. Quale sia questo limite dipende dalla piattaforma utilizzata.
In funzione dei numeri di AS adottati, potrebbe essere necessario adottare qualche accorgimento aggiuntivo. Ad esempio, nel caso si utilizzassero per i Leaf, numeri di AS diversi, potrebbe accadere che i Leaf ricevano annunci della stessa subnet con AS_PATH di uguale lunghezza ma con diversi numeri di AS. Ora, una regola adottata da alcuni vendor (NOTA: la RFC 4271 non dice alcunché circa il BGP Multipath, lasciando ai costruttori la sua implementazione) è che affinché il BGP Multipath sia possibile, gli attributi AS_PATH devono coincidere sia in lunghezza che nei numeri di AS. L’IOS Cisco mette a disposizione il comando “bgp bestpath as-path multipath-relax”, per rilassare questo vincolo. Con questo comando, gli AS_PATH possono essere diversi, ma devono comunque avere la stessa lunghezza.
INTERCONNESSIONE CON L'ESTERNO
L'interconnessione di un Data Center IGP-free con l'esterno segue regole abbastanza classiche, sempre con qualche accorgimento.
L'interconnessione con l'esterno avviene di norma attraverso switch dedicati, chiamati "Border Router", interconnessi al livello più alto della rete di Clos (quindi agli Spine). Lo scambio delle informazioni di routing con ISP esterni, avviene in modo assolutamente classico attraverso sessioni eBGP.
Un accorgimento da adottare, quando si annuncia un prefisso verso gli ISP, è la rimozione degli AS (privati) utilizzati all'interno della IP Fabric. Questo per evitare collisioni con altri AS che potrebbero utilizzare gli stessi numeri (possibile in quanto privati). Benché non standard, la rimozione degli AS privati è supportata sia da Cisco che da Juniper. Cisco mette a disposizione il comando IOS "neighbor ... remove-private-as", che consente di eliminare una stringa nell'AS_PATH, di AS privati contigui. Maggiori dettagli sulla documentazione Cisco (vedi ad esempio questo documento). L'analogo comando nel JUNOS è "neighbor ... { remove-private;}". Anche qui, maggiori dettagli sulla documentazione del JUNOS (vedi ad esempio questo documento).
Per quanto riguarda la gestione del traffico uscente dal Data Center (outbound), la soluzione più semplice è farsi inviare dagli ISP una default-route e quindi propagarla via eBGP all'interno della IP Fabric. Questo consente anche di garantire automaticamente un percorso alternativo, in caso di fuori servizio di un link verso un ISP. Inoltre, consente un ritiro automatico della default-route in caso di perdita di connettività verso tutti gli ISP, evitando che il traffico outbound si propaghi inutilmente dai Leaf verso i Border Router. Alternative basate su complicati meccanismi di conditional route advertisement, sebbene percorribili, sono da evitare.
Per la gestione del traffico entrante nel Data Center (inbound), anche qui le tecniche da utilizzare sono quelle classiche del BGP. L'unico accorgimento che è possibile adottare, ma è un classico, è aggregare il più possibile sui Border Router, i prefissi annunciati agli ISP.
CONCLUSIONI
In questo post ho illustrato un'applicazione abbastanza atipica del BGP: il suo utilizzo come protocollo IGP, senza l'ausilio, come di norma avviene, di un protocollo IGP classico, come ad esempio OSPF o IS-IS. L'idea è per certi versi un po' rivoluzionaria, ma nello scenario delle IP Fabric dei grandi Data Center ha un suo razionale, che in questo post ho cercato di mettere in luce.
Non so se vi ho convinto, ma qualora non ci fossi riuscito, volete un esempio di un gigantesco Data Center la cui IP Fabric è IGP-free e utilizza solo BGP (in particolare, eBGP) ? Guardate qui, dovrebbe esservi familiare ... Una sorta di Back to the future !!!
Coming up Next ... un post sull'Inter-VXLAN Routing.
Bel post ! sui Cisco l'approccio sulla propagazione delle rotte non è uniforme, sulle macchine Nexus dovrebbe funzionare come nei Juniper (il comando per rimuovere il filro automatico è "disable-peer-as-check").
RispondiElimina