Questo post prende spunto da una e-mail che ho ricevuto tempo fa da un brillante ex-allievo che lavora in un piccolo ISP, uno di quelli che nel gergo degli ISP è un Tier-2. Ricordo che un ISP Tier-2 è un ISP che comunica direttamente con altre reti, ma che comunque acquista un transito IP per raggiungere almeno una porzione di Internet.
Vi riporto la parte chiave della e-mail:
Vi riporto la parte chiave della e-mail:
. . .
In allegato trovi uno schema abbastanza semplice della rete attuale, i clienti sono collegati sull'anello ai vari switch (gli anelli in realtà sono piu' di uno) sui due Cisco 7609 arrivano in connessione diretta altri clienti via WDM, ed infine sempre sui 7609 sono connessi 3/4 AS pubblici a cui noi facciamo da upstream. La nostra connessione verso il mondo esterno come puoi vedere avviene tramite 6 link ad 1Gbps cosi' distribuiti:
- 3 LAN di peering su tre IXP (Internet eXchange Point) dalle quali impariamo, con Local Preference più alta rispetto ai transiti, le network specifiche dei vari peer quali Wind , Fastweb, Akamai, ecc.
- 3 IP TRANSIT i quali ci passano la FIRT.
Chi ha configurato la rete a suo tempo ha lasciato i 3 transiti con stessa Local Preference in modo che fosse il BGP a decidere i best path e poter cosi' sfruttare il traffico di tutti e 3 i link. Purtroppo a causa della massa di network quando parte lo scanner BGP o quando cade un neighbor, la CPU va alle stelle e la convergenza delle rotte è lentissima , di questo i clienti si accorgono.
A breve metteremo 2 macchine nuove ... <omissis>..., la mia paura è che lasciare la FIRT possa mettere in seria difficoltà anche le nuove macchine.
Che mi consigli per diminuire il carico delle CPU e comunque lasciare che il traffico bilanci tra tutti e 6 i nodi ?
. . .
Molto interessante. Tutto ruota (secondo me) sul mito sbagliato (sempre secondo me) che è "cosa buona e giusta" avere in casa la Full Internet Routing Table (FIRT), ossia, quello che è sintetizzato nel titolo di questo post come "il mito della FIRT".
Mito che però è preso per buono da molti e devo dire acriticamente. Conosco molti amministratori di rete, anche Enterprise, che si fanno inviare dagli ISP a cui sono interconnessi, l'intera FIRT (nel caso del mio ex-allievo, addirittura da 3 ISP). Alla mia domanda, "ma a cosa vi serve l'intera FIRT ?", le risposte sono sempre state o "ma non lo so, l'ho trovata qui", oppure un Mozartiano "così fan tutti" (in realtà l'operetta buffa di Mozart era la K588, "Così fan tutte"), o infine "così sono in grado ottimizzare il traffico (uscente, ovviamente)".
Tralascio le prime due risposte che non sono degne di commento, la terza, che è un po' più tecnica, sembra essere una motivazione ragionevole. La mia (ovvia) domanda successiva è sempre stata questa: ma è così importante per voi avere la possibilità di ottimizzare il percorso verso prefissi IP il cui traffico è quasi nullo, se non addirittura nullo per la stragrande maggioranza ? O meglio, perché voi vi tenete in casa (nei router di peering) milioni di annunci BGP, quando il 95% del traffico è verso poche migliaia di prefissi IP (questo lo dicono le statistiche, non io) ? Ma è proprio necessario ottimizzare il traffico per raggiungere un sito delle Isole Tonga ? Non sarebbe meglio lasciarlo al destino della default-route ?
Ricordate che, come mostrerò nel seguito, avere in casa la FIRT ha un costo, sia in termini di CAPEX (apparati molto costosi) che di OPEX (apparati complessi da gestire ed energivori).
Ricordate che, come mostrerò nel seguito, avere in casa la FIRT ha un costo, sia in termini di CAPEX (apparati molto costosi) che di OPEX (apparati complessi da gestire ed energivori).
Bene, è ora di fare un po' di chiarezza su questo mito e analizzare un po' meglio il problema, anche per cercare di smontarlo. Mito che oltretutto, come ho detto sopra, non viene gratis.
UN PO' DI NUMERI
La FIRT può essere virtualmente considerata come una sorta di "Elenco Telefonico" dell'intera Internet. La differenza fondamentale con l'elenco telefonico è che invece di mettere in corrispondenza un nome con un numero (aspetto che nell'Internet come noto è compito del servizio DNS), la FIRT vi da un'idea circa gli oggetti (prefissi IP) che compaiono e scompaiono dall'Internet.
Ma quanti sono questi oggetti, ossia i prefissi IP della FIRT ? Dare un numero esatto è praticamente impossibile, però gli ordini di grandezza sono noti. Ad esempio, il celebre sito http://bgp.potaroo.net/, tenuto aggiornato da Geoff Huston, mantiene un insieme di statistiche sull'Internet IPv4 e IPv6. Da questo sito ho tratto il diagramma seguente, che da un'idea dell'attuale dimensione dell'Internet IPv4.
Come si può vedere, la FIRT a fine 2016 ammonta a circa 700.000 prefissi. Ho avuto la fortuna recentemente di mettere le mani su un Route Server di un grande ISP (un Juniper M120), utilizzato per fornire la FIRT ai suoi Clienti. La tentazione di fare uno "show route summary" è stata forte, ed ecco il risultato (NOTA: ho mascherato tutti i dati che potessero portare all'identificazione dell'ISP).
xyz@root-server> show route summary
Autonomous system number: yyyyy
Router ID: xxx.xxx.xxx.xxx
inet.0: 770561 destinations, 1536195 routes (770554 active, 26 holddown, 1 hidden)
Direct: 3 routes, 3 active
Local: 2 routes, 2 active
OSPF: 5732 routes, 5711 active
BGP: 1530453 routes, 764833 active
Static: 2 routes, 2 active
IGMP: 1 routes, 1 active
PIM: 2 routes, 2 active
Il numero chiave da osservare è il numero di route BGP attive, ossia 764.833, in linea più o meno con quanto detto sopra. Questo numero cresce, come si evince dal grafico, esponenzialmente. Si noti che l'altro numero, ossia il numero delle route BGP, pari a 1.530.452, rappresenta il numero degli annunci BGP che questo router mantiene in memoria. Questo è pari circa al doppio delle route BGP attive, poiché evidentemente questo router riceve la FIRT da due BGP peer.
Prima di valutare l'utilità o meno di avere la FIRT in casa, è importante valutare l'impatto della FIRT sui router. Di quanta memoria si ha bisogno ? Quali sono i limiti di scalabilità che un router deve avere per poter "mantenere" la FIRT ? Quanto costa un simile router, sia in termini economici che di dispendio energetico ?
IMPATTO DELLA FIRT SUI ROUTER
Prima di vedere quale è l'impatto della FIRT su un router, devo richiamarvi un concetto che sicuramente vi è familiare, ma che in questo contesto è fondamentale: la differenza tra RIB e FIB:
Ora, nell'esempio mostrato nella sezione precedente, la RIB contiene 1.536.195 entry, di cui 1.530.452 appresi attraverso il protocollo BGP, mentre la FIB contiene 770.554 entry, di cui 764.833 sono le route BGP attive. Mentre per la RIB mantenere tutte queste route non è un grosso problema, poiché la RAM commerciale è abbastanza economica, per la FIB il discorso è parecchio diverso. (NOTA: a proposito, nella figura precedente che descrive la crescita nel tempo della FIRT, la dicitura dell'asse delle ordinate non è corretta; a essere precisi dovrebbe essere "Active BGP Entries (FIB), come riportato in un'altra pagina del sito di Geoff Huston).
Giusto per dare alcuni numeri, un po' spannometrici poiché dipendenti dalla particolare piattaforma, ho fatto delle prove su una vecchia piattaforma Cisco (un router 3850) e su un più recente CSR1kv. Nel caso del router 3850, questo utilizza, per ciascun prefisso BGP, 136 byte di memoria più 52 byte per gli attributi associati. Nel caso di due annunci dello stesso prefisso, l'occupazione della RAM è pari a 136 + 2*52 = 240 byte. Per 700.000 prefissi annunciati da due BGP peer, quindi un totale di 1.400.000 annunci, l'occupazione risulta essere:
700k * 136 + 1.400k * 52 = 168 Mbyte
Poiché il BGP utilizza anche altra memoria (poca), e che poi è necessario considerare anche la memoria utilizzata da altri protocolli e processi, diciamo che con 256 MByte si dovrebbe stare tranquilli. Ma visto il basso costo della RAM sui router attuali, si può abbondare ancor di più (se il router lo consente !).
Nel CSR1kv, l'occupazione di memoria è invece di 248 byte di memoria per ciascun prefisso BGP più 120 byte per gli attributi associati. Lo stesso conto conto di cui sopra porta a un'occupazione di memoria di:
700k * 248 + 1.400k * 120 = 341,6 Mbyte
Si noti che l'incremento di memoria necessaria non è lineare, ossia raddoppiando il numero di BGP peer la memoria necessaria non raddoppia. La figura seguente, tratta da una presentazione a un Cisco Live tenuto a Melbourne nel 2014 (titolo della presentazione: Routing Operations and Features in Cisco IOS Routers), mostra l'incremento di memoria passando da uno a tre BGP peer.
Ben diverso è il discorso per la FIB, qui abbondare può avere costi enormi. Oggi, un router in grado di contenere nella sua FIB la FIRT, ha costi (di listino) che si aggirano intorno ai 500 kEuro, può arrivare ad avere una potenza fino a 12 KW, e occupare uno spazio di più di 10 RU. Una roba mostruosa. E' chiaro che questo tipo di router è necessario per gli ISP Tier-1, che sono pochi al mondo (tra questi anche Telecom Italia Sparkle), ma siamo sicuri che sia necessario per piccoli ISP o per reti Enterprise, che di solito sono multi-homed a più ISP ?
E poi c'è un altro problema. A causa della continua crescita nella dimensione della FIRT, può accadere che il router non sia più in grado di contenerla. Ne sanno qualcosa i possessori di router ormai considerati di vecchia generazione, come ad esempio i Cisco Catalyst 6500 e i router Cisco della serie 76xx, che avevano una limitazione di 512k entry della memoria TCAM (NOTA: 1k = 1.024 entry). Nell'Agosto 2014 questo numero è stato superato dalla FIRT, e vista la larga diffusione di questo tipo di macchine (guarda caso, l'ISP in cui lavora il mio allievo la cui e-mail ho riportato all'inizio, utilizza dei Cisco 7609), questo ha provocato una certa instabilità nell'Internet (vedi ad esempio questo articolo).
Cisco ha subito messo in campo dei workaround, che però hanno vita limitata poiché la crescita della FIRT è costante e ad un certo punto neanche più questi workaround saranno in grado di risolvere la situazione. Solo per fare un esempio, questo è quello che si può fare su un Catalyst 6500. Attraverso un opportuno comando di configurazione è possibile spostare spazio della TCAM da IPv6 (ancora poco utilizzato, la FIRT IPv6 ad oggi arriva a malapena 40.000 righe) a IPv4.
(Prima di riconfigurare la memoria)
6500# show mls cef maximum-routes
FIB TCAM maximum routes :
=======================
Current :
---------
IPv4 + MPLS - 512k (default)
IPv6 + IP Multicast - 25k (default)
6500(config)# mls cef maxzimum-routes ip 768
Maximum routes set to 786432. Configuration will be effective on reboot.
(Dopo un reload)
6500# show mls cef maximum-routes
FIB TCAM maximum routes:
=======================
IPv4 - 768k
MPLS - 16k (default)
IPv6 + IP Multicast - 120k (default)
Ma sono tutte "pezze a colori" che eludono il vero problema: ma è realmente necessario avere in casa tutta la FIRT ? Naturalmente gli ISP Tier-1 devono necessariamente averla, ma per quanto riguarda i piccoli ISP o le reti Enterprise, come potrebbero essere ad esempio quelle dei Content Provider (Spotify, Netflix, YouTube ecc.), è reale questa necessità ? Io ho sempre detto che è un inutile spreco di risorse, e nella prossima sezione argomenterò il perché.
FIRT, O NON FIRT, QUESTO E' IL PROBLEMA
Ci sono alcune domande chiave che un ISP o un amministratore di una rete Enterprise dovrebbero porsi, prima di prendere una decisione sulla FIRT:
La seconda domanda ha una risposta correlata alla prima. Io non credo che per raggiungere in modo ottimo destinazioni verso le quali il traffico è molto esiguo, vale la pena di tenersi in casa la FIRT. C'è sempre il famoso "Gateway of Last Resort", ovvero la default-route. Per tutte queste destinazioni, e anche per tutte quelle che probabilmente i vostri Clienti raggiungeranno una sola volta della vita, fatevi mandare (via BGP) dai vostri ISP upstream una sana default-route, e utilizzate il BGP multipath. Considerate inoltre che la stragrande maggioranza del traffico Internet o è distante un AS o al massimo due. Per cui basta un semplice filtro che agisca sull'AS_PATH con una regular expression opportuna, e potete già ridurre notevolmente l'insieme dei prefissi della FIRT accettati. Per i più curiosi, questa è la regular expression da applicare in ambiente Cisco: "^[0-9]+_[0-9]*$". Tutto il resto lasciatelo al destino della default-route. E poi c'è un altro aspetto di cui tener conto, oggi la maggior parte del traffico Internet è generato da OTT (es. Google, Facebook, ecc.) e da CDN (es. Akamai), che hanno peering diretti con gli ISP. Statistica molto recente, solo il 30 % del traffico Internet fa transito, il resto va su peering diretti.
Infine, per quanto riguarda il terzo punto, nella prossima sezione vi citerò un esempio reale (che sarà approfondito in un prossimo post), dove il risparmio in termini di CAPEX (costo degli apparati) e OPEX (esercizio degli apparati, tra cui il consumo di energia) è di almeno un ordine di grandezza.
Per concludere, vi posso garantire che uno dei maggiori ISP Italiani, un Tier-2, ma molto molto grande, non ha nei suoi router l'intera FIRT, ma le sole route verso gli altri ISP nazionali, e una default-route verso il proprio Tier-1 (che nella fattispecie è uno solo, che se è serio è più che sufficiente, basta solo avere Internet gateway ridondati, meglio se in diversità geografica, e banda sufficiente !). Questa default-route viene inviata via BGP dal Tier-1 e propagata all'interno del backbone dell'ISP attraverso una redistribuzione nel protocollo IGP (NOTA: in architetture BGP core-free sarebbe sufficiente propagarla ai soli router di bordo via iBGP). Questo ISP ha dei Route Server con la FIRT, ma per il solo scopo di inviarla ai Clienti che la richiedono (che purtroppo sono tanti !). I Route Server sono completamente fuori dal forwarding path (un po' come i vRR di cui ho parlato in questo post).
UNO STRUMENTO PER L'ANALISI DEL TRAFFICO
Un aspetto chiave per evitare di avere la FIRT nella propria rete, è la necessità di conoscere verso quali prefissi si ha maggior traffico. E per questo sono necessari strumenti di analisi del traffico. Vorrei consigliarvene uno, ideato dal mio amico Paolo Lucente, da poco approdato in NTT America, dopo un periodo passato in Cariden/Cisco. Paolo ha ideato e iniziato qualche anno fa un progetto open source dal nome impronunciabile, ma di elevato spessore tecnico. Il progetto si chiama pmacct e l'obiettivo è (direttamente dal sito):
pmacct is a small set of multi-purpose passive network monitoring tools. It can account, classify, aggregate, replicate and export forwarding-plane data, ie. IPv4 and IPv6 traffic; collect and correlate control-plane data via BGP and BMP; collect infrastructure data via streaming network telemetry.
Questo software è stato utilizzato con successo in produzione da Spotify, che (anche) grazie a questo è riuscito a ottimizzare i suoi costi di connessione, passando dall'utilizzo di router giganteschi dal costo di circa 500k USD e consumi elettrici di circa 12 Kw, a piccoli router da 30k USD che consumano meno di 500 watt. Ho chiesto al mio amico Paolo di illustrare il suo progetto al pubblico di questo blog, e anche l'applicazione di pmacct al progetto di Spotify, quindi aspettatevi un prossimo post su questo. Nel frattempo, se volete portarvi avanti potete leggervi questa presentazione, che lui e David Barroso, ex-Spotify, hanno fatto all'ESNOG 17 a Barcellona, nel Maggio 2016.
La realizzazione della loro idea non è stata banale, comunque il succo è che con piccoli switch tipicamente utilizzati in ambito Data Center, che hanno FIB di capacità limitata, ad esempio 128k entry (in realtà nel loro progetto l'obiettivo era utilizzare switch con limite della FIB di 32k entry), sono riusciti nell'intento di gestire il traffico uscente con costi nettamente inferiori. E il traffico gestito da Spotify non è poco, e ha bisogno anche di requisiti di qualità abbastanza stringenti. (NOTA: non fatevi ingannare dal nome commerciale, questi switch sono veri e propri router con molte interfacce Ethernet, tipicamente 10G lato server e 40G/100G uplink).
CONCLUSIONI
Spero, se non di avervi convinto, almeno di avervi insinuato il dubbio che avere in casa l'intera FIRT non è proprio necessario (a meno che non siate Tier-1 !). I risparmi in termini di CAPEX e OPEX sono notevoli e notevoli sono i grattacapi in meno. E poi ricordate sempre che a farvi raggiungere i web server delle Isole Tonga ci pensano i vostri Tier-1, altrimenti che li pagate a fare ?
RINGRAZIAMENTI: un particolare grazie al mio amico Paolo Lucente, per le fruttuose illuminanti discussioni e scambi di idee sull'argomento trattato in questo post.
Prima di valutare l'utilità o meno di avere la FIRT in casa, è importante valutare l'impatto della FIRT sui router. Di quanta memoria si ha bisogno ? Quali sono i limiti di scalabilità che un router deve avere per poter "mantenere" la FIRT ? Quanto costa un simile router, sia in termini economici che di dispendio energetico ?
IMPATTO DELLA FIRT SUI ROUTER
Prima di vedere quale è l'impatto della FIRT su un router, devo richiamarvi un concetto che sicuramente vi è familiare, ma che in questo contesto è fondamentale: la differenza tra RIB e FIB:
- RIB (= Routing Information Base): è una tabella software, meglio nota come "Tabella di Routing", dove sono memorizzate tutte le informazioni di routing (annunci dei vari prefissi, metriche associate, Next-Hop, interfaccia di uscita, ecc.). Come noto viene costruita a partire dalle informazioni ricevute dai protocolli di routing dinamici attivi nel router, da eventuali route statiche e dalle reti direttamente connesse.
- FIB (= Forwarding Information Base): è una tabella hardware, che contiene il sottoinsieme della RIB costituito da tutti percorsi effettivamente utilizzati per il forwarding del traffico (route attive). Di solito per ciascun entry (prefisso IP), la FIB mantiene tutte le informazioni necessarie per il forwarding dei pacchetti (Next-Hop, interfaccia di uscita, incapsulamento di Livello 2, eventuali etichette MPLS, ecc.).
Ora, nell'esempio mostrato nella sezione precedente, la RIB contiene 1.536.195 entry, di cui 1.530.452 appresi attraverso il protocollo BGP, mentre la FIB contiene 770.554 entry, di cui 764.833 sono le route BGP attive. Mentre per la RIB mantenere tutte queste route non è un grosso problema, poiché la RAM commerciale è abbastanza economica, per la FIB il discorso è parecchio diverso. (NOTA: a proposito, nella figura precedente che descrive la crescita nel tempo della FIRT, la dicitura dell'asse delle ordinate non è corretta; a essere precisi dovrebbe essere "Active BGP Entries (FIB), come riportato in un'altra pagina del sito di Geoff Huston).
Giusto per dare alcuni numeri, un po' spannometrici poiché dipendenti dalla particolare piattaforma, ho fatto delle prove su una vecchia piattaforma Cisco (un router 3850) e su un più recente CSR1kv. Nel caso del router 3850, questo utilizza, per ciascun prefisso BGP, 136 byte di memoria più 52 byte per gli attributi associati. Nel caso di due annunci dello stesso prefisso, l'occupazione della RAM è pari a 136 + 2*52 = 240 byte. Per 700.000 prefissi annunciati da due BGP peer, quindi un totale di 1.400.000 annunci, l'occupazione risulta essere:
700k * 136 + 1.400k * 52 = 168 Mbyte
Poiché il BGP utilizza anche altra memoria (poca), e che poi è necessario considerare anche la memoria utilizzata da altri protocolli e processi, diciamo che con 256 MByte si dovrebbe stare tranquilli. Ma visto il basso costo della RAM sui router attuali, si può abbondare ancor di più (se il router lo consente !).
Nel CSR1kv, l'occupazione di memoria è invece di 248 byte di memoria per ciascun prefisso BGP più 120 byte per gli attributi associati. Lo stesso conto conto di cui sopra porta a un'occupazione di memoria di:
700k * 248 + 1.400k * 120 = 341,6 Mbyte
Si noti che l'incremento di memoria necessaria non è lineare, ossia raddoppiando il numero di BGP peer la memoria necessaria non raddoppia. La figura seguente, tratta da una presentazione a un Cisco Live tenuto a Melbourne nel 2014 (titolo della presentazione: Routing Operations and Features in Cisco IOS Routers), mostra l'incremento di memoria passando da uno a tre BGP peer.
Ben diverso è il discorso per la FIB, qui abbondare può avere costi enormi. Oggi, un router in grado di contenere nella sua FIB la FIRT, ha costi (di listino) che si aggirano intorno ai 500 kEuro, può arrivare ad avere una potenza fino a 12 KW, e occupare uno spazio di più di 10 RU. Una roba mostruosa. E' chiaro che questo tipo di router è necessario per gli ISP Tier-1, che sono pochi al mondo (tra questi anche Telecom Italia Sparkle), ma siamo sicuri che sia necessario per piccoli ISP o per reti Enterprise, che di solito sono multi-homed a più ISP ?
E poi c'è un altro problema. A causa della continua crescita nella dimensione della FIRT, può accadere che il router non sia più in grado di contenerla. Ne sanno qualcosa i possessori di router ormai considerati di vecchia generazione, come ad esempio i Cisco Catalyst 6500 e i router Cisco della serie 76xx, che avevano una limitazione di 512k entry della memoria TCAM (NOTA: 1k = 1.024 entry). Nell'Agosto 2014 questo numero è stato superato dalla FIRT, e vista la larga diffusione di questo tipo di macchine (guarda caso, l'ISP in cui lavora il mio allievo la cui e-mail ho riportato all'inizio, utilizza dei Cisco 7609), questo ha provocato una certa instabilità nell'Internet (vedi ad esempio questo articolo).
Cisco ha subito messo in campo dei workaround, che però hanno vita limitata poiché la crescita della FIRT è costante e ad un certo punto neanche più questi workaround saranno in grado di risolvere la situazione. Solo per fare un esempio, questo è quello che si può fare su un Catalyst 6500. Attraverso un opportuno comando di configurazione è possibile spostare spazio della TCAM da IPv6 (ancora poco utilizzato, la FIRT IPv6 ad oggi arriva a malapena 40.000 righe) a IPv4.
(Prima di riconfigurare la memoria)
6500# show mls cef maximum-routes
FIB TCAM maximum routes :
=======================
Current :
---------
IPv4 + MPLS - 512k (default)
IPv6 + IP Multicast - 25k (default)
6500(config)# mls cef maxzimum-routes ip 768
Maximum routes set to 786432. Configuration will be effective on reboot.
(Dopo un reload)
6500# show mls cef maximum-routes
FIB TCAM maximum routes:
=======================
IPv4 - 768k
MPLS - 16k (default)
IPv6 + IP Multicast - 120k (default)
Ma sono tutte "pezze a colori" che eludono il vero problema: ma è realmente necessario avere in casa tutta la FIRT ? Naturalmente gli ISP Tier-1 devono necessariamente averla, ma per quanto riguarda i piccoli ISP o le reti Enterprise, come potrebbero essere ad esempio quelle dei Content Provider (Spotify, Netflix, YouTube ecc.), è reale questa necessità ? Io ho sempre detto che è un inutile spreco di risorse, e nella prossima sezione argomenterò il perché.
FIRT, O NON FIRT, QUESTO E' IL PROBLEMA
Ci sono alcune domande chiave che un ISP o un amministratore di una rete Enterprise dovrebbero porsi, prima di prendere una decisione sulla FIRT:
- La maggior parte del traffico verso quali prefissi è diretto ? E quanti sono questi prefissi ?
- Vale la pena o no ottimizzare il traffico verso destinazioni che vengono raggiunte da volumi esigui ? O non è meglio lasciare questo traffico al destino della default-route ?
- Quale è l'extra costo, in termini di CAPEX e OPEX, che si deve sostenere affinché si possa mantenere la FIRT ?
La seconda domanda ha una risposta correlata alla prima. Io non credo che per raggiungere in modo ottimo destinazioni verso le quali il traffico è molto esiguo, vale la pena di tenersi in casa la FIRT. C'è sempre il famoso "Gateway of Last Resort", ovvero la default-route. Per tutte queste destinazioni, e anche per tutte quelle che probabilmente i vostri Clienti raggiungeranno una sola volta della vita, fatevi mandare (via BGP) dai vostri ISP upstream una sana default-route, e utilizzate il BGP multipath. Considerate inoltre che la stragrande maggioranza del traffico Internet o è distante un AS o al massimo due. Per cui basta un semplice filtro che agisca sull'AS_PATH con una regular expression opportuna, e potete già ridurre notevolmente l'insieme dei prefissi della FIRT accettati. Per i più curiosi, questa è la regular expression da applicare in ambiente Cisco: "^[0-9]+_[0-9]*$". Tutto il resto lasciatelo al destino della default-route. E poi c'è un altro aspetto di cui tener conto, oggi la maggior parte del traffico Internet è generato da OTT (es. Google, Facebook, ecc.) e da CDN (es. Akamai), che hanno peering diretti con gli ISP. Statistica molto recente, solo il 30 % del traffico Internet fa transito, il resto va su peering diretti.
Infine, per quanto riguarda il terzo punto, nella prossima sezione vi citerò un esempio reale (che sarà approfondito in un prossimo post), dove il risparmio in termini di CAPEX (costo degli apparati) e OPEX (esercizio degli apparati, tra cui il consumo di energia) è di almeno un ordine di grandezza.
Per concludere, vi posso garantire che uno dei maggiori ISP Italiani, un Tier-2, ma molto molto grande, non ha nei suoi router l'intera FIRT, ma le sole route verso gli altri ISP nazionali, e una default-route verso il proprio Tier-1 (che nella fattispecie è uno solo, che se è serio è più che sufficiente, basta solo avere Internet gateway ridondati, meglio se in diversità geografica, e banda sufficiente !). Questa default-route viene inviata via BGP dal Tier-1 e propagata all'interno del backbone dell'ISP attraverso una redistribuzione nel protocollo IGP (NOTA: in architetture BGP core-free sarebbe sufficiente propagarla ai soli router di bordo via iBGP). Questo ISP ha dei Route Server con la FIRT, ma per il solo scopo di inviarla ai Clienti che la richiedono (che purtroppo sono tanti !). I Route Server sono completamente fuori dal forwarding path (un po' come i vRR di cui ho parlato in questo post).
UNO STRUMENTO PER L'ANALISI DEL TRAFFICO
Un aspetto chiave per evitare di avere la FIRT nella propria rete, è la necessità di conoscere verso quali prefissi si ha maggior traffico. E per questo sono necessari strumenti di analisi del traffico. Vorrei consigliarvene uno, ideato dal mio amico Paolo Lucente, da poco approdato in NTT America, dopo un periodo passato in Cariden/Cisco. Paolo ha ideato e iniziato qualche anno fa un progetto open source dal nome impronunciabile, ma di elevato spessore tecnico. Il progetto si chiama pmacct e l'obiettivo è (direttamente dal sito):
pmacct is a small set of multi-purpose passive network monitoring tools. It can account, classify, aggregate, replicate and export forwarding-plane data, ie. IPv4 and IPv6 traffic; collect and correlate control-plane data via BGP and BMP; collect infrastructure data via streaming network telemetry.
Questo software è stato utilizzato con successo in produzione da Spotify, che (anche) grazie a questo è riuscito a ottimizzare i suoi costi di connessione, passando dall'utilizzo di router giganteschi dal costo di circa 500k USD e consumi elettrici di circa 12 Kw, a piccoli router da 30k USD che consumano meno di 500 watt. Ho chiesto al mio amico Paolo di illustrare il suo progetto al pubblico di questo blog, e anche l'applicazione di pmacct al progetto di Spotify, quindi aspettatevi un prossimo post su questo. Nel frattempo, se volete portarvi avanti potete leggervi questa presentazione, che lui e David Barroso, ex-Spotify, hanno fatto all'ESNOG 17 a Barcellona, nel Maggio 2016.
La realizzazione della loro idea non è stata banale, comunque il succo è che con piccoli switch tipicamente utilizzati in ambito Data Center, che hanno FIB di capacità limitata, ad esempio 128k entry (in realtà nel loro progetto l'obiettivo era utilizzare switch con limite della FIB di 32k entry), sono riusciti nell'intento di gestire il traffico uscente con costi nettamente inferiori. E il traffico gestito da Spotify non è poco, e ha bisogno anche di requisiti di qualità abbastanza stringenti. (NOTA: non fatevi ingannare dal nome commerciale, questi switch sono veri e propri router con molte interfacce Ethernet, tipicamente 10G lato server e 40G/100G uplink).
CONCLUSIONI
Spero, se non di avervi convinto, almeno di avervi insinuato il dubbio che avere in casa l'intera FIRT non è proprio necessario (a meno che non siate Tier-1 !). I risparmi in termini di CAPEX e OPEX sono notevoli e notevoli sono i grattacapi in meno. E poi ricordate sempre che a farvi raggiungere i web server delle Isole Tonga ci pensano i vostri Tier-1, altrimenti che li pagate a fare ?
RINGRAZIAMENTI: un particolare grazie al mio amico Paolo Lucente, per le fruttuose illuminanti discussioni e scambi di idee sull'argomento trattato in questo post.
Articolo veramente molto interessante! Se la necessita' di avere la Full Routing Table in un ISP tier 2 o 3 e' gia' discutibile non vedo proprio la necessita' in ambito enterprise.
RispondiEliminaPer un'azienda accollarsi i costi che comporta per avere 0 vantaggi e' proprio assurdo.
Ti ringrazio per avermi fatto conoscere il tool per monitorare il traffico, sembra veramente interessante!
Il tool è molto interessante. Come ho scritto nel post, il mio amico Paolo Lucente mi ha promesso un post in cui illustrerà gli aspetti più importanti di pmacct e la sua applicazione realizzata per Spotify insieme a David Barroso.
EliminaBuonasera Ammiraglio,
RispondiEliminanegli anni 2003-2005 assieme ad altri colleghi di TILAB abbiamo sviluppato un tool dal nome MATRIX il cui compito era incrociare i dati di traffico netflow con i dati delle tabelle BGP. Questo metodo è stato applicato con successo al miglioramento della copertura upstream di TI sparkle passando dall'85% al 94% a fine 2004.
Quanto lei dice in questo documento è giustissimo. Credo che molti in ambito security vogliano avere la full table BGP per poter classificare gli IP sorgente dei possibili attacchi che IDS o altri dispositivi registrano in ingresso.
Posso anche dire sulla base della mia esperienza che non esiste una unica full table: un full table europea contiene dettagli su reti gestite dal RIPE, una tabella asiatica è sempre una full table ma contiene maggiori dettagli sui prefissi asiatici e così via.
Le riporto le indicazioni dei nostri brevetti:
Patents
Evaluating connectivity on data-communication networks
United States 7,451,230
Method for determining prospective peering partners for an Internet Service Provider (ISP)
United States 8050193 , 12/226,740
Issued July 30, 2009
Non conoscevo il tool di Paolo Lucente cercherò di darci una occhiata.
Cordiali Saluti
Giuseppe Larosa
Giuseppe,
RispondiEliminagrazie per il commento. Non conoscevo il vostro strumento MATRIX, ma conoscendo abbastanza bene il valore delle persone TILAB (ho molti amici da quelle parti), ho la certezza matematica che il vostro lavoro sia di elevato livello.
Circa la tua affermazione "Credo che molti in ambito security vogliano avere la full table BGP per poter classificare gli IP sorgente dei possibili attacchi che IDS o altri dispositivi registrano in ingresso.", bene credo che questa sia un'altra motivazione, sicuramente importante. Ma c'è un ma, il succo del mio post non è contro l'avere la FIRT nella BGP RIB, ma averla nella FIB. D'altra parte, è quantomai improbabile che un Tier-1 si metta a filtrare gli annunci che invia ai downstream ISP (tecnicamente si può fare con la funzionalità ORF, Outbound Route Filtering, ma non la vedo molto applicata in giro). Per cui prendersi la FIRT da un upstream provider va bene, ma è però opportuno filtrare ciò che si invia alla FIB. Nell'applicazione che ho citato di Spotify, che spero verrà illustrata a dovere da Paolo Lucente, questo viene fatto attraverso la funzionalità di BGP Selective Download. Quindi l'intera FIRT in casa si può avere, il problema è non portare tutta la FIRT nella FIB, perché è quello che esplodere i costi.
Infine, grazie per aver dedicato un po' del tuo tempo a leggere le mie "pippe mentali", è per me lusinghiero sapere che il blog è frequentato da persone di altissimo livello come te.
Buon anno Ammiraglio,
RispondiEliminaho conosciuto il suo blog tramite un ex collega Pasquale Vinci che pubblica update su linkedin con i post del suo blog così per esempio ho seguito i post su EVPN.
Ho appena fatto peering con Paolo Lucente su linkedin e due peers che abbiamo in comune Francesco Chiappini e Pierfrancesco Caci possono confermare i buoni risultati ottenuti con il tool MATRIX.
>> Quindi l'intera FIRT in casa si può avere, il problema è non portare tutta la FIRT nella FIB, perché è quello che esplodere i costi.
Temo purtroppo che non si possa fare a meno di portare la FIRT nella FIB se si vuole usare netflow direttamentee sul device di rete in line.
Diverso è il discorso se si mettono in campo delle sonde dedicate con HW dedicato che potrebbero agire da shadow router.
Sto dando una occhiata al tool di Paolo Lucente ed è davvero impressionante il numero di cose che riesce a fare.
>> è per me lusinghiero sapere che il blog è frequentato da persone di altissimo livello come te.
Troppo buono. Se posso dare un consiglio suggerirei di scrivere i futuri post sia in italiano sia in inglese perchè i contenuti sono davvero validi (chiedo scusa in anticipo se questo avviene già).
Io personalmente ho scritto più di 13000 posts su Cisco Support Forum e sono nella Hall of Fame del CSC principalmente ho postato su WAN, LAN ed MPLS. Negli ultimi 3 anni ho scritto molto di meno.
Ho avuto occasione di leggere alcune pagine del suo libro su MPLS e devo dire che già allora dissi al mio collega che era un libro scritto da qualcuno che aveva veramente messo le mani sui router e che conosceva l'argomento molto bene.
Cordiali Saluti
Giuseppe Larosa
Buon Anno Ammiraglio,
RispondiEliminaabbiamo lavorato con persone di TI Sparkle che Paolo Lucente conosce come Francesco Chiappini e Pierfrancesco Caci. Ho appena fatto il peering con Paolo Lucente su linkedin e li ho visti tra le shared connections.
>> Quindi l'intera FIRT in casa si può avere, il problema è non portare tutta la FIRT nella FIB, perché è quello che esplodere i costi.
Dando una occhiata al BGP selective download è una feature nata per i BGP route reflector server in modo che non tentino di allocare risorse sulla FIB per prefissi / NLRI per i quali non sono nel forwarding path.
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/15-s/irg-15-s-book/irg-selective-download.html#d211366e814a1635
Comunque se si riesce a non far installare la FIRT nella FIB a quel punto il netflow accounting molto probabilmente non riesce ad accedere ai dati della FIRT ed a fare la classificazione dei flussi.
A questo punto per fare accounting si devono usare delle sonde dedicate che agiscano da shadow router lasciando l'apparato di rete libero di fare forwarding sulla base di poche rotte dinamiche o statiche.
Immagino sia questa la soluzione adottata per spotify.
>> il blog è frequentato da persone di altissimo livello come te.
Troppo buono professore.
Cordiali Saluti
Giuseppe Larosa
Giuseppe, grazie per i commenti. Conosco anch'io le persone di Sparkle, e non ho il seppur minimo dubbio sugli ottimi risultati ottenuti via Matrix. Circa il limitare la quantità di prefissi RIB-->FIB, l'approccio seguito da Paolo Lucente e David Barroso è molto interessante ed è in produzione. Il BGP Selective Download è vero che Cisco lo consiglia per i RR, ma in realtà può anche essere applicato a qualsiasi router. Ed è proprio questo l'approccio utilizzato nella soluzione Lucente-Barroso: pmacct per le statistiche e BGP Selective Download per limitare il numero di prefissi nella FIB. Comunque fra poco uscirà un post di Paolo che descriverà il tutto.
EliminaPer il resto grazie dei complimenti. Il libro su MPLS si è invecchiato e mi sono ripromesso, come ultima opera della mia umile carriera, prima di appendere il router al chiodo, di scrivere la seconda edizione.
Circa il problema dei post in Inglese, mi sono posto il problema all’inizio e ancora oggi me lo pongo. La mia decisione di mirare più ad un pubblico nazionale è forse un po’ provinciale, ma ho considerato che di blog in Inglese ve ne sono un’infinità (e sicuramente migliori del mio), in Italiano nessuno, per cui ho puntato a far crescere la cultura interna. Magari vedendo un post in Italiano, i nostri tecnici sono più stimolati. Comunque ho messo il Google Translator, per cui i post sono disponibili anche in cirillico e aramaico !!!
Credo che un'altra argomentazione per ricevere la FRT, contestualmente al fatto di avere un AS pubblico direttamente in casa del (piccolo) cliente, sia anche quella di poter avere dei pubblici propri provider indipendent, che consentano di cambiare fornitore o fare della gare. In questo caso avere la FRt teoricamente potrebbe darti maggiore ridondanza nel caso uno dei due provider subisca una perdita parziale di raggiungibilità di rotte internet. Credo sia un evento raro e in gran parte dei casi solamente teorico, ma forse per grandi istituzioni e banche, tutto ciò ha una sua ragion d'essere.
RispondiElimina