Il BGP come è noto è un po' l'architrave dell'intera Internet, che può essere vista globalmente come un insieme di reti (nel gergo BGP Autonomous System, AS) interconnesse tra loro (ad oggi circa 60.000). Sul piano dati le informazioni viaggiano utilizzando il protocollo IP (oggi per la maggior parte IPv4, con IPv6 che sta pian piano, ma molto piano, crescendo), mentre sul piano di controllo le informazioni di routing vengono scambiate tra i vari AS utilizzando il protocollo BGP.
Il BGP è nato storicamente proprio per questo, per lo scambio delle informazioni di routing tra i vari AS. Poi nel tempo ha avuto altri importanti utilizzi. Infatti, benché nato come protocollo di routing inter-dominio, il BGP ha esteso negli anni il suo ambito di applicazione e oggi viene utilizzato:
Il BGP è nato storicamente proprio per questo, per lo scambio delle informazioni di routing tra i vari AS. Poi nel tempo ha avuto altri importanti utilizzi. Infatti, benché nato come protocollo di routing inter-dominio, il BGP ha esteso negli anni il suo ambito di applicazione e oggi viene utilizzato:
- Nelle moderne reti dei grandi ISP (Internet Service Provider), dove gioca un ruolo chiave nell’architettura di routing complessiva poiché, grazie alla sua provata scalabilità, si è dimostrato uno strumento molto efficiente per distribuire all’interno di un AS i prefissi IP esterni all’AS.
- Nel piano di controllo di vari servizi L3VPN/L2VPN basati sul modello BGP/MPLS.
- Come protocollo di accesso di reti private (reti Enterprise) alle reti degli ISP.
Il BGP è sicuramente il protocollo di routing più importante delle reti IP, e nonostante la versione attualmente utilizzata (la versione 4) sia stata standardizzata nel lontano Marzo 1995 (RFC 1771), con un "tagliando" effettuato nel Gennaio 2006 (RFC 4271), nonostante nel tempo siano stati introdotti miglioramenti e ne sono state estese le funzionalità (es. l'introduzione dell'estensione multi protocollo), i concetti base sono rimasti sempre gli stessi. E concetti che erano validi al tempo della nascita del BGP, che, faccio notare fu introdotto nella sua prima versione nel lontano 1989 (RFC 1105, Giugno 1989) agli albori dell'Internet, prima dell'esplosione che conosciamo oggi, nello scenario attuale vanno rivisti.
In particolare, una ben nota proprietà delle sessioni eBGP, quella secondo la quale il BGP propaga automaticamente sulle sessioni eBGP i best-path (a meno di eventuali filtri outbound), si è rivelata nel tempo fonte di vari problemi. Ed è proprio questo problema che è stato affrontato recentemente in ambito IETF, e che ha prodotto una variazione significativa (benché concettualmente banale) al comportamento di default del BGP, standardizzata nella RFC 8212, pubblicata pochi mesi fa (Luglio 2017). Ma prima di vedere cosa dice questa nuova RFC, voglio richiamarvi alcuni concetti, più commerciali che tecnici, che però sono necessari per comprendere fino in fondo la novità introdotta dalla RFC 8212.
RELAZIONI TRA ISP: PEERING E TRANSITO
Uno dei problemi fondamentali dell'Internet, ben noto dai tempo del vecchio mondo telefonico, è come mettere in comunicazione tutti gli apparati (PC, smartphone, tablet, server, ecc.) che hanno un indirizzo IP pubblico e che sono dispersi sull'intero pianeta.
E' ovviamente impensabile che ciascun ISP, per raggiungere tutti i vari apparati collegati alle reti degli ISP stessi, sia direttamente collegato con tutti gli altri ISP nel mondo. Deve necessariamente esistere un meccanismo di interconnessione tra le reti, con varie reti che svolgono il servizio di transito per altre reti. L'interconnessione può essere diretta o indiretta (transito) tramite una o più reti che accettano di trasportare il traffico.
Gli accordi economici tra ISP per l'interconnessione sono di due tipi:
ISP TIER 1/2/3
E' ovviamente impensabile che ciascun ISP, per raggiungere tutti i vari apparati collegati alle reti degli ISP stessi, sia direttamente collegato con tutti gli altri ISP nel mondo. Deve necessariamente esistere un meccanismo di interconnessione tra le reti, con varie reti che svolgono il servizio di transito per altre reti. L'interconnessione può essere diretta o indiretta (transito) tramite una o più reti che accettano di trasportare il traffico.
Gli accordi economici tra ISP per l'interconnessione sono di due tipi:
- Peering: quando due o più ISP si interconnettono direttamente l'uno con l'altro per scambiare traffico tra i loro clienti. Questo viene spesso fatto senza addebito per l'interconnessione o il traffico (come si dice nella letteratura anglosassone, sono accordi settlement-free). Si noti che il peering è una relazione non transitiva, ossia se ISP-A ha un accordo di peering con ISP-B e ISP-B ha un accordo di peering con ISP-C, questo non implica che ISP-A ha un accordo di peering con ISP-C. Gli accordi di peering sono esclusivamente tra due ISP (bilaterali). Di più, in una situazione del genere, ISP-A non può utilizzare ISP-B come transito per scambiare traffico con ISP-C.
- Transito: quando un ISP accetta di trasportare il traffico che fluisce tra un altro ISP e tutti gli altri ISP. Poiché nessun ISP si connette direttamente a tutti gli altri ISP, un ISP che fornisce il servizio di transito consegnerà parte del traffico indirettamente tramite uno o più altri ISP di transito. Il fornitore del servizio di transito riceve un corrispettivo economico per il servizio.
Nonostante non vi sia una definizione formale della "gerarchia dei Livelli in Internet", la definizione generalmente accettata tra i professionisti del networking per classificare gli ISP è la seguente:
Anche gli ISP Tier-2 hanno tra loro generalmente accordi di peering. Il peering tra ISP Tier-2 avviene di solito attraverso collegamenti diretti privati. In questo caso si parla di peering privato, in opposizione al peering pubblico, dove invece gli ISP si connettono utilizzando una struttura pubblica condivisa gestita da terze parti, nota come Internet Exchange Point (IXP). Esempi di IXP in Italia sono il MIX di Milano, il NAMEX a Roma, il TOP-IX a Torino.
Per ottimizzare i costi, gli ISP Tier-3 possono avere accordi di peering con altri ISP Tier-3. L’interconnessione avviene di solito negli IXP.
Vi sono molte ragioni per cui i professionisti del networking usano la "gerarchia a livelli" per descrivere le reti, ma la più importante è la maggiore comprensione delle motivazioni politiche ed economiche di una data rete, in relazione a come e con chi comunica.
- Primo livello (Tier-1): è una rete IP (tipicamente ma non necessariamente un ISP) in grado di connettersi all'intera Internet senza acquistare servizi di transito da altri ISP. Nel mondo esistono poco più di una decina di ISP Tier-1. Tra questi: AT&T (AS 7018), Deutsche Telekom AG (AS 3320), NTT Communications (America) (AS 2914), Telecom Italia Sparkle (AS 6762).
- Secondo livello (Tier-2): un ISP che comunica alla pari con altri ISP, ma che comunque acquista un transito IP per raggiungere almeno una porzione di Internet e che può fornire un servizio di transito a ISP di livello inferiore. Esempi in Italia sono le reti di grandi ISP nazionali come Telecom Italia (AS 3269), Fastweb (AS 12874), ecc. .
- Terzo livello (Tier-3): un ISP che per raggiungere Internet ha bisogno di acquistare il diritto di transito da altre reti. Di solito gli ISP Tier-3 operano un ambito geografico ristretto (tipicamente regionale), sono molto aggressivi nel pricing, ma per contro non sono in grado di offrire una gran quantità di banda. La loro clientela è tipicamente quella retail o small business.
Anche gli ISP Tier-2 hanno tra loro generalmente accordi di peering. Il peering tra ISP Tier-2 avviene di solito attraverso collegamenti diretti privati. In questo caso si parla di peering privato, in opposizione al peering pubblico, dove invece gli ISP si connettono utilizzando una struttura pubblica condivisa gestita da terze parti, nota come Internet Exchange Point (IXP). Esempi di IXP in Italia sono il MIX di Milano, il NAMEX a Roma, il TOP-IX a Torino.
Per ottimizzare i costi, gli ISP Tier-3 possono avere accordi di peering con altri ISP Tier-3. L’interconnessione avviene di solito negli IXP.
Vi sono molte ragioni per cui i professionisti del networking usano la "gerarchia a livelli" per descrivere le reti, ma la più importante è la maggiore comprensione delle motivazioni politiche ed economiche di una data rete, in relazione a come e con chi comunica.
ESEMPI DI ROUTE LEAK
Uno dei punti di debolezza del BGP è che una errata applicazione delle politiche di interconnessione con gli altri ISP può provocare vari problemi, come ad esempio routing non ottimo, black-hole del traffico, intercettazione fraudolenta del traffico e tanto altro.
La recente RFC 7908 - Problem Definition and Classification of BGP Route Leaks, Giugno 2016, ha definito una casistica completa di queste problematiche, note come route leak (letteralmente, trabocco degli annunci). Alcune di queste sono pertinenti alla variazione del comportamento di default del BGP introdotto dalla RFC 8212 (vedi prossima sezione).
La RFC 7908, nella sezione 2 da la seguente definizione di route leak:
A route leak is the propagation of routing announcement(s) beyond their intended scope (Traduzione: un route leak è la propagazione di un annuncio BGP al di la dell'ambito previsto (dagli accordi tra ISP)).
Vi riporto un paio di esempi per chiarire meglio il fenomeno. Gli esempi sono tratti dalla classificazione introdotta nella RFC 7908. Per altri esempi rimando alla stessa RFC. Faccio notare che a ciascuno di questi esempi corrispondono "incidenti" verificatisi varie volte nelle applicazioni reali.
Esempio 1:
Si consideri il caso di una rete Enterprise che per l'accesso a Internet ha un collegamento multi-homed a due diversi ISP (upstream provider). Lo scenario è descritto nella figura seguente.
Si supponga che ISP-A annunci un proprio prefisso (P) sia direttamente a ISP-B, con il quale ha una relazione di peering, che alla rete Enterprise, alla quale invece offre un servizio di transito. Se il gestore della rete Enterprise applica le politiche di default del BGP (ossia, non applica alcuna politica di filtraggio outbound), l'annuncio ricevuto da ISP-A viene automaticamente propagato a ISP-B. Se ISP-B, che a questo punto si trova due annunci del prefisso P, scegliesse come best-path l'annuncio proveniente dalla rete Enterprise, quest'ultima si troverebbe a divenire di transito per il traffico che ISP-B invia verso il prefisso P. Con due effetti deleteri, il primo è che alla rete Enterprise viene sottratta banda, che paga profumatamente, e poi che le risorse della rete Enterprise non sono sufficienti a smaltire i grossi volumi di traffico che gli ISP si scambiano direttamente. Per cui molto del traffico tra gli ISP verrebbe per perso per "insufficienza di risorse". (NOTA: la soluzione di questo problema è molto semplice e chi ha un po' di dimestichezza con il BGP la conosce certamente. Si tratta di applicare una semplice politica di filtraggio outbound sul router (o sui router) della rete Enterprise dove sono attive le sessioni BGP verso gli upstream provider. Che tipo di politica lo lascio come esercizio).
Questo tipo di route leak è classificato nella RFC 7908 come tipo 1 - Hairpin Turn with Full Prefix.
Esempio 2:
Si consideri il caso di tre ISP in sequenza che hanno tra loro relazioni bilaterali di peering, ossia ISP-A ha una relazione di peering con ISP-B e ISP-B a sua volta ha una relazione di peering con ISP-C (vedi figura seguente).
Le politiche di default degli ISP in questo caso sono che un ISP non deve mai propagare a un altro ISP (nemmeno a eventuali upstream ISP che offrono il servizio di transito) gli annunci che riceve da un ISP con cui ha una relazione di peering. Ad esempio, con relazione alla figura, ISP-B non deve propagare a ISP-C l'annuncio del prefisso P-A ricevuto da ISP-A, e viceversa, ISP-B non deve propagare a ISP-A l'annuncio del prefisso P-C ricevuto da ISP-C. In caso contrario, ISP-B diverrebbe un ISP di transito tra gli ISP-A e ISP-C, violando le regole della relazione di peering, che è solamente bilaterale. Ricordo che una relazione di peering prevede solo ed esclusivamente lo scambio di traffico diretto, mai di transito.
Questo tipo di route leak è classificato nella RFC 7908 come tipo 2 - Lateral ISP-ISP-ISP Leak.
Altri due esempi di questo tipo riportati nella RFC 7908 sono:
VARIAZIONE AL COMPORTAMENTO DI DEFAULT DEL BGP INTRODOTTA DALLA RFC 8212
L'applicazione delle politiche di interconnessione avviene attraverso strumenti di configurazione a volte molto complessi, diversi da vendor a vendor e anche all'interno dello stesso vendor. Errori nell'applicazione di queste politiche possono derivare sia da una errata progettazione che da una errata configurazione.
Per cui sarebbe bene che di default, innanzitutto, sia vietata la propagazione automatica degli annunci eBGP, obbligando così gli amministratori degli ISP a costruire sempre politiche di routing appropriate (si spera senza errori, ma su questo nessuna RFC potrà mai porre rimedio !).
La RFC 8212 - Default External BGP (EBGP) Route Propagation Behavior without Policies, Luglio 2017, introduce due variazioni al comportamento di default del BGP, una riguardante gli annunci entranti (inbound), l'altra gli annunci uscenti (outbound):
Routes contained in an Adj-RIB-In associated with an EBGP peer SHALL NOT be considered eligible in the Decision Process if no explicit Import Policy has been applied.
Routes SHALL NOT be added to an Adj-RIB-Out associated with an EBGP peer if no explicit Export Policy has been applied.
Traduzione per noi comuni mortali: nessun annuncio entrante e/o uscente può essere accettato/propagato se non sia stata esplicitamente configurata una politica di routing inbound/outbound.
All'atto pratico ciò implica che le configurazioni di base non dovrebbero consentire né l'accettazione né la propagazione automatica degli annunci eBGP. In altre parole, giusto per fare un esempio pratico, una classica configurazione del tipo:
router bgp 1234
neighbor 1.1.1.1 remote-as 5678
tra un eBGP speaker dell'AS 1234 e uno dell'AS 5678, non dovrebbe consentire né l'invio né la ricezione di annunci BGP.
SUPPORTO DEI VENDOR
Al momento sono solo 2 le implementazioni BGP che supportano la RFC 8212: l'IOS XR Cisco (tutte le versioni) e l'implementazione open BIRD (a partire dalla version 2.0.1), sviluppata dal progetto BIRD. Nokia ha recentemente annunciato l'intenzione di supportare la RFC 8212 nelle prossime versioni del suo sistema operativo SR OS. Una lista completa e continuamente aggiornata del supporto della RFC 8212 da parte dei vendor è consultabile a questo link.
L'IOS XR Cisco ha implementato questo nuovo comportamento di default prima ancora che fosse standardizzato nella RFC 8212 (NOTA: lo stesso comportamento non è invece implementato nell'IOS, IOS XE e NX-OS che invece al momento seguono la regola tradizionale). Infatti, nelle piattaforme Cisco che utilizzano l’IOS XR (es. router della serie CRS-X, ASR9k) da sempre, un eBGP speaker di default non accetta e non invia annunci eBGP. La sessione eBGP raggiunge comunque lo stato Established, ma è praticamente inservibile.
L’IOS XR segnala la mancanza delle routing policy con un messaggio nel comando "show bgp ipv4 unicast summary".La figura seguente riporta il messaggio visualizzato. Si noti che nell’ultima colonna della visualizzazione, sotto la voce "St/PfxRcd", compare "0!". Lo zero indica che non è stato ricevuto alcun prefisso, e il "!" che per quel eBGP peer non sono state abilitate routing policy. Si noti che lo stesso messaggio compare anche omettendo uno dei due filtri. Ad esempio, omettendo il filtro outbound, compare un identico messaggio, ma nell’ultima colonna, oltre al "!" potrebbe comparire un numero non nullo per indicare che qualche prefisso è stato comunque ricevuto.
Per far si che sulle sessioni eBGP possano essere inviati e ricevuti annunci BGP, è necessario definire dei filtri attraverso delle routing policy, e abilitarli sia nella direzione inbound che outbound. La prossima figura riporta un esempio "minimale" di configurazione.
La routing policy configurata nel router di destra, che utilizza l'IOS XR, è del tipo "passa-tutto", e come tale applicabile nelle situazioni pratiche solo in casi particolari. Nelle reti in produzione queste routing policy andrebbero scritte in modo da soddisfare le politiche inbound/outbound desiderate dall'amministratore dell'AS. Si noti che il comando "show bgp ipv4 unicast summary" riporta nell’ultima colonna della visualizzazione, sotto la voce "St/PfxRcd", il valore 1 senza "!", per indicare che è stato ricevuto un prefisso dal eBGP peer 172.16.12.1 e che sono stati applicati sia un filtro inbound che outbound.
UNA CONSIDERAZIONE SULL'APPLICABILITA' AI DATA CENTER IGP-FREE
Per chiudere, una piccola considerazione riguardante l'applicazione in ambito Data Center. Come ho argomentato in questo post, c'è una tendenza, almeno nei Data Center di grandi dimensioni, a utilizzare il BGP anche come unico protocollo di routing nella rete underlay (fabric), realizzando sessioni eBGP tra switch Leaf e Spine.
In questo caso particolare le politiche di routing non vengono minimamente applicate e quindi implementare il supporto della RFC 8212 negli switch di Data Center non è conveniente, poiché aumenta solo la complessità di configurazione. Ma ovviamente non è possibile chiedere ai vendor di implementare il supporto alla RFC 8212 in alcune piattaforme e in altre no. In una situazione del genere si può pensare di configurare delle route policy di tipo passa-tutto e applicarle alle varie sessioni eBGP. E' un po' fastidioso, ma con un buon tool di Network Automation, il problema si risolve facilmente. Oppure potreste chiedere al vostro vendor di implementare un comando del tipo "bgp no-rfc-8212" !
CONCLUSIONI
Il BGP, benché anzianetto, è un protocollo vivo e vegeto, che però come tutti i protocolli, essendo nato in tempi in cui l'Internet non era quella che conosciamo oggi, ha bisogno di tanto in tanto di un po' di "manutenzione". Recentemente sono state introdotte alcune novità, una delle quali, il Graceful Shutdown, ho trattato in questo post precedente. In questo post ho invece trattato di una novità, che ancorché all'apparenza banale, rende il BGP molto più robusto a errori di applicazione delle politiche inbound/outbound. L'idea di fondo, come ho spiegato, è molto semplice: obbligare gli amministratori di rete a implementare sempre e comunque delle politiche di routing inbound/outbound, senza delle quali, a differenza di quanto avviene oggi (a parte in un paio di implementazioni del BGP), un BGP speaker non annuncia alcunché ai suoi eBGP peers, e scarta tutti gli annunci ricevuti da eBGP peers. Ritengo questa novità molto importante poiché obbliga in qualche modo gli amministratori di rete a implementare, possibilmente "cum grano salis", delle politiche di routing, evitando così fenomeni di route leak che ogni tanto creano problemi a parte dell'Internet (se volete curiosare sugli incidenti che di tanto in tanto capitano nell'Internet, guardatevi il sito bgpmon.net). Pertanto invito tutti gli interessati a premere sui vostri vendor preferiti affinché implementino il supporto alla RFC 8212, con la minaccia di passare alla concorrenza.
RINGRAZIAMENTI
Vorrei ringraziare il fantasmagorico e spumeggiante Job Snijders di NTT Communications (un Tier-1, AS 2914) per avermi stimolato a scrivere questo post e per lo scambio di interessanti considerazioni sulle novità introdotte di recente nel BGP.
La recente RFC 7908 - Problem Definition and Classification of BGP Route Leaks, Giugno 2016, ha definito una casistica completa di queste problematiche, note come route leak (letteralmente, trabocco degli annunci). Alcune di queste sono pertinenti alla variazione del comportamento di default del BGP introdotto dalla RFC 8212 (vedi prossima sezione).
La RFC 7908, nella sezione 2 da la seguente definizione di route leak:
A route leak is the propagation of routing announcement(s) beyond their intended scope (Traduzione: un route leak è la propagazione di un annuncio BGP al di la dell'ambito previsto (dagli accordi tra ISP)).
Vi riporto un paio di esempi per chiarire meglio il fenomeno. Gli esempi sono tratti dalla classificazione introdotta nella RFC 7908. Per altri esempi rimando alla stessa RFC. Faccio notare che a ciascuno di questi esempi corrispondono "incidenti" verificatisi varie volte nelle applicazioni reali.
Esempio 1:
Si consideri il caso di una rete Enterprise che per l'accesso a Internet ha un collegamento multi-homed a due diversi ISP (upstream provider). Lo scenario è descritto nella figura seguente.
Si supponga che ISP-A annunci un proprio prefisso (P) sia direttamente a ISP-B, con il quale ha una relazione di peering, che alla rete Enterprise, alla quale invece offre un servizio di transito. Se il gestore della rete Enterprise applica le politiche di default del BGP (ossia, non applica alcuna politica di filtraggio outbound), l'annuncio ricevuto da ISP-A viene automaticamente propagato a ISP-B. Se ISP-B, che a questo punto si trova due annunci del prefisso P, scegliesse come best-path l'annuncio proveniente dalla rete Enterprise, quest'ultima si troverebbe a divenire di transito per il traffico che ISP-B invia verso il prefisso P. Con due effetti deleteri, il primo è che alla rete Enterprise viene sottratta banda, che paga profumatamente, e poi che le risorse della rete Enterprise non sono sufficienti a smaltire i grossi volumi di traffico che gli ISP si scambiano direttamente. Per cui molto del traffico tra gli ISP verrebbe per perso per "insufficienza di risorse". (NOTA: la soluzione di questo problema è molto semplice e chi ha un po' di dimestichezza con il BGP la conosce certamente. Si tratta di applicare una semplice politica di filtraggio outbound sul router (o sui router) della rete Enterprise dove sono attive le sessioni BGP verso gli upstream provider. Che tipo di politica lo lascio come esercizio).
Questo tipo di route leak è classificato nella RFC 7908 come tipo 1 - Hairpin Turn with Full Prefix.
Si consideri il caso di tre ISP in sequenza che hanno tra loro relazioni bilaterali di peering, ossia ISP-A ha una relazione di peering con ISP-B e ISP-B a sua volta ha una relazione di peering con ISP-C (vedi figura seguente).
Questo tipo di route leak è classificato nella RFC 7908 come tipo 2 - Lateral ISP-ISP-ISP Leak.
Altri due esempi di questo tipo riportati nella RFC 7908 sono:
- Tipo 3: la propagazione di annunci che un ISP riceve da un upstream provider (che gli offre un servizio di transito) verso un ISP con cui ha una relazione di peering.
- Tipo 4: è l'inverso del tipo 3, ossia un ISP propaga a un upstream provider annunci provenienti da ISP con cui ha relazioni di peering.
VARIAZIONE AL COMPORTAMENTO DI DEFAULT DEL BGP INTRODOTTA DALLA RFC 8212
L'applicazione delle politiche di interconnessione avviene attraverso strumenti di configurazione a volte molto complessi, diversi da vendor a vendor e anche all'interno dello stesso vendor. Errori nell'applicazione di queste politiche possono derivare sia da una errata progettazione che da una errata configurazione.
Per cui sarebbe bene che di default, innanzitutto, sia vietata la propagazione automatica degli annunci eBGP, obbligando così gli amministratori degli ISP a costruire sempre politiche di routing appropriate (si spera senza errori, ma su questo nessuna RFC potrà mai porre rimedio !).
La RFC 8212 - Default External BGP (EBGP) Route Propagation Behavior without Policies, Luglio 2017, introduce due variazioni al comportamento di default del BGP, una riguardante gli annunci entranti (inbound), l'altra gli annunci uscenti (outbound):
Routes contained in an Adj-RIB-In associated with an EBGP peer SHALL NOT be considered eligible in the Decision Process if no explicit Import Policy has been applied.
Routes SHALL NOT be added to an Adj-RIB-Out associated with an EBGP peer if no explicit Export Policy has been applied.
Traduzione per noi comuni mortali: nessun annuncio entrante e/o uscente può essere accettato/propagato se non sia stata esplicitamente configurata una politica di routing inbound/outbound.
All'atto pratico ciò implica che le configurazioni di base non dovrebbero consentire né l'accettazione né la propagazione automatica degli annunci eBGP. In altre parole, giusto per fare un esempio pratico, una classica configurazione del tipo:
router bgp 1234
neighbor 1.1.1.1 remote-as 5678
tra un eBGP speaker dell'AS 1234 e uno dell'AS 5678, non dovrebbe consentire né l'invio né la ricezione di annunci BGP.
SUPPORTO DEI VENDOR
Al momento sono solo 2 le implementazioni BGP che supportano la RFC 8212: l'IOS XR Cisco (tutte le versioni) e l'implementazione open BIRD (a partire dalla version 2.0.1), sviluppata dal progetto BIRD. Nokia ha recentemente annunciato l'intenzione di supportare la RFC 8212 nelle prossime versioni del suo sistema operativo SR OS. Una lista completa e continuamente aggiornata del supporto della RFC 8212 da parte dei vendor è consultabile a questo link.
L'IOS XR Cisco ha implementato questo nuovo comportamento di default prima ancora che fosse standardizzato nella RFC 8212 (NOTA: lo stesso comportamento non è invece implementato nell'IOS, IOS XE e NX-OS che invece al momento seguono la regola tradizionale). Infatti, nelle piattaforme Cisco che utilizzano l’IOS XR (es. router della serie CRS-X, ASR9k) da sempre, un eBGP speaker di default non accetta e non invia annunci eBGP. La sessione eBGP raggiunge comunque lo stato Established, ma è praticamente inservibile.
Per far si che sulle sessioni eBGP possano essere inviati e ricevuti annunci BGP, è necessario definire dei filtri attraverso delle routing policy, e abilitarli sia nella direzione inbound che outbound. La prossima figura riporta un esempio "minimale" di configurazione.
La routing policy configurata nel router di destra, che utilizza l'IOS XR, è del tipo "passa-tutto", e come tale applicabile nelle situazioni pratiche solo in casi particolari. Nelle reti in produzione queste routing policy andrebbero scritte in modo da soddisfare le politiche inbound/outbound desiderate dall'amministratore dell'AS. Si noti che il comando "show bgp ipv4 unicast summary" riporta nell’ultima colonna della visualizzazione, sotto la voce "St/PfxRcd", il valore 1 senza "!", per indicare che è stato ricevuto un prefisso dal eBGP peer 172.16.12.1 e che sono stati applicati sia un filtro inbound che outbound.
UNA CONSIDERAZIONE SULL'APPLICABILITA' AI DATA CENTER IGP-FREE
Per chiudere, una piccola considerazione riguardante l'applicazione in ambito Data Center. Come ho argomentato in questo post, c'è una tendenza, almeno nei Data Center di grandi dimensioni, a utilizzare il BGP anche come unico protocollo di routing nella rete underlay (fabric), realizzando sessioni eBGP tra switch Leaf e Spine.
In questo caso particolare le politiche di routing non vengono minimamente applicate e quindi implementare il supporto della RFC 8212 negli switch di Data Center non è conveniente, poiché aumenta solo la complessità di configurazione. Ma ovviamente non è possibile chiedere ai vendor di implementare il supporto alla RFC 8212 in alcune piattaforme e in altre no. In una situazione del genere si può pensare di configurare delle route policy di tipo passa-tutto e applicarle alle varie sessioni eBGP. E' un po' fastidioso, ma con un buon tool di Network Automation, il problema si risolve facilmente. Oppure potreste chiedere al vostro vendor di implementare un comando del tipo "bgp no-rfc-8212" !
Il BGP, benché anzianetto, è un protocollo vivo e vegeto, che però come tutti i protocolli, essendo nato in tempi in cui l'Internet non era quella che conosciamo oggi, ha bisogno di tanto in tanto di un po' di "manutenzione". Recentemente sono state introdotte alcune novità, una delle quali, il Graceful Shutdown, ho trattato in questo post precedente. In questo post ho invece trattato di una novità, che ancorché all'apparenza banale, rende il BGP molto più robusto a errori di applicazione delle politiche inbound/outbound. L'idea di fondo, come ho spiegato, è molto semplice: obbligare gli amministratori di rete a implementare sempre e comunque delle politiche di routing inbound/outbound, senza delle quali, a differenza di quanto avviene oggi (a parte in un paio di implementazioni del BGP), un BGP speaker non annuncia alcunché ai suoi eBGP peers, e scarta tutti gli annunci ricevuti da eBGP peers. Ritengo questa novità molto importante poiché obbliga in qualche modo gli amministratori di rete a implementare, possibilmente "cum grano salis", delle politiche di routing, evitando così fenomeni di route leak che ogni tanto creano problemi a parte dell'Internet (se volete curiosare sugli incidenti che di tanto in tanto capitano nell'Internet, guardatevi il sito bgpmon.net). Pertanto invito tutti gli interessati a premere sui vostri vendor preferiti affinché implementino il supporto alla RFC 8212, con la minaccia di passare alla concorrenza.
RINGRAZIAMENTI
Vorrei ringraziare il fantasmagorico e spumeggiante Job Snijders di NTT Communications (un Tier-1, AS 2914) per avermi stimolato a scrivere questo post e per lo scambio di interessanti considerazioni sulle novità introdotte di recente nel BGP.
Nessun commento:
Posta un commento