Browsed by
Tag: networking

Telegram’s infrastructure and outages. Some updates.

Telegram’s infrastructure and outages. Some updates.

This post is meant as an (ongoing) sequence of updates to the previous one about Telegram’s outages in March and April 2018. Please read it here first.

Last updated: April 30th, 6:00 AM UTC

UPDATE 1

With the help of a friend (and his own HowIsResolved), we managed to confirm that for most open resolvers worldwide (25k+ tested) api.telegram.org is showing up as 149.154.167.220. Only outliers seem to be China (resolving as of now as 174.37.154.236) and Russia (85.142.29.248).

UPDATE 2

During my analysis this morning I created a new Telegram App, and the (only) suggested MTProto (the Telegram protocol) server was 149.154.167.50. This falls into the IP range analysed above, and seems to be solely located in Amsterdam.

Kipters was so kind to review and help me notice that this server is not used for real “data” communication, but just for a “discovery” API call (help.getConfig method) which will return the list of servers that will have to be used for sending messages. We are currently still in process of comparing ranges received across the world, but in the best case scenario (ie: they are spread over multiple geographic locations) this would mean that there is still a single point of failure in the hardcoded “directory” server.

UPDATE 3

What I found in the previous note was “too weird to be true”, so I went ahead and kept digging into TDLib and the official Desktop and Android Apps, to confirm wether they were bootstrapping a session beginning from a single MTProto endpoint or not.

Fortunately, turns out this is not the case (relevant snippets for TDLib, DesktopAndroid Apps): both of them contain, hardcoded, in addition to endpoints in the range 149.154.167.0/24 (Amsterdam, AS62041), endpoints in 149.154.175.0/24 (Miami, AS59930) and 149.154.171.0/24 (Singapore, AS62014).

Sounds like we should look into different reasons why many users worldwide outside of EMEA had issues today (or wait for an official, detailed post mortem if it will ever come): there are many, from broken dependencies to weird cases of mis-routing.

Some areas are left to explore (feel free to share your ideas if you have any): why third party apps don’t have access to the whole list of “initial” MTProto endpoints, and are pushed to use only a single, non redundant one? Why the main website and api.telegram.org (mainly used for bots I think) are based off a single location?

UPDATE 4

Telegram Web (https://web.telegram.org/) seems to be single-homed in Amsterdam too. As I haven’t had the opportunity to test during the outage, I don’t know whether it has been failed over somewhere else or not.

UPDATE 5

According to the official documentation, users (registered by phone number) are located off a single datacenter, picked at signup time based on geographical proximity: “During the process of working with the API, user information is accumulated in the DC with which the user is associated. This is the reason a user cannot be associated with a different DC by means of the client.

They are only moved if they keep connecting from a remote location for a prolonged period of time (ie: you permanently relocate to another continent): this might explain why there seem to be no failover scenario and 12+ hours outages are happening.

(Thanks to adjustableneutralism from Reddit for flagging)

Telegram is down (again): a deep look at their infrastructure

Telegram is down (again): a deep look at their infrastructure

I’ve been a strong Telegram advocate since its launch in 2013, mainly because of the advanced features and technical state of the art compared to competitors – as a consequence, I’ve been looking very closely at their infrastructure for the last few years.

The two large scale outages that recently hit their users and the sequence of events following them made me ask some questions around their platform. For most of them I have only found additional question marks rather than answers, but here it is what I have so far.

Let’s start from the outages: in case you missed that, on March 29th and April 29th this year, Telegram went down in their Amsterdam datacenter due to a power failure, causing disruptions, according to their official communications, to users in EMEA, MENA, Russia and CIS.

Zooming in on the latter: it’s still ongoing at time of writing this article (8:30AM UTC), and is showing up with clients unable to connect to the platform and both https://www.telegram.org/ (website) and https://api.telegram.org/ (api endpoint) failing with an HTTP error code 500.

Let’s start with the items that, to me, don’t add up: first and foremost, the outage. In case of “massive power outage” in the Amsterdam area, I would expect to see a traffic drop in AMS-IX, the largest Internet Exchange in the region, but there is none (it should be showing around 01 AM):

There are indeed reports of an outage that affected Amsterdam (below the one from Schiphol Airport), but no (public) reports of consequent large datacenter failures.

Who’s involved in running large scale platforms will be surprised by at least two things here: the fact that they are serving an huge geographical area from a single datacenter and their inability to reactively reroute traffic to the other locations they are operating, even in case of extended outage (no DR plans?).

A quick search on Twitter shows that even if the official communication states the issue is only affecting the EMEA region, users from Canada, US, Australia, Japan and other countries are facing it as well.

I used Host-Tracker to have a deeper look into this: an HTTP check to Telegram’s API endpoint and their website fails with an HTTP 500 error from every location across the world:

I went ahead and began digging to find out more about their infrastructure, network and the other locations they are running from.

And here comes the second huge question mark: the infrastructure.

A bunch of DNS lookups across the main endpoints show they are always resolving to the same v4 and v6 IPs, in a way that doesn’t look related to the source location of my queries.

They look to be announced by AS62041 (owned by Telegram LLP): this kind of DNS scheme made me think they were running an anycast based network, so next logical step has been analysing latencies from multiple locations.

Turns out, latency is averaging 20/30ms from EMEA, 100/150ms from AMER, and 250/300ms from APAC: as if from all of those countries you were being routed to the Amsterdam datacenter.

What I’m seeing in terms of latency is confirmed by analysing reverse lookups of routers found in the different paths to Telegram: in my trace from Australia the last visible hop is et3-1-2.amster1.ams.seabone.net (notice that “ams”), most of the traces from US are landing on xcr1.att.cw.net (195.2.1.14) which 1 millisecond away from my lab in Amsterdam and a couple of samples from US and Canada are running all the way up to ae-2-3201.ear3.Amsterdam1.Level3.net, which is self-explaining.

Important to highlight, there are no outliers: I couldn’t find a single example of very low latency from APAC / AMER, that would have proved the existence of a local point of presence. A summary of my tests in the table below:

To get the full picture, I decided to dig into AS62041 main upstream carriers (CW AS1273, TI Sparkle AS6762, Level3 AS3356) and see how they were handing over internet traffic to Telegram.

Turns out, CW is always preferring the path to xcr1.att.cw.net/195.2.1.14 (tested from some locations across the world), our little router-friend in Amsterdam. TI Sparkle always lands on amster1.ams.seabone.net and Level3 only has paths to ear3.Amsterdam1 (tested from Asia and US). Level3’s BGP communities are interesting: routes are tagged as “Europe Backbone” and “Level3_Customer Netherlands Amsterdam”:

Telegram is also peering with Hurricane Electric (AS6939): their routers in US, JP, AU have a next hop of ams-ix-gw.telegram.org/80.249.209.69 for 149.154.164.0/22. That hop seems to be Telegram’s AMS-IX facing router, and the IP is definitely part of AMS-IX:

 

As said in the opening, there are definitely more questions than answers in the article. It’s as if there was no Telegram infrastructure outside Amsterdam, and over there it was running in a single datacenter. This would explain why users across the world are seeing an outage that should only affect EMEA and close areas, and why Telegram is not taking steps to reroute users to another datacenter/location during the failure in AMS.

Am I missing something very obvious? Please let me know!

UPDATE: With the help of some friends and random people, I found out more details. Find them (with -ongoing- updates) in the dedicated post.

Ehi, c’è il World IPv6 Launch!

Ehi, c’è il World IPv6 Launch!

Me ne stavo dimenticando: domani, 6 Giugno 2012 è il World IPv6 Launch.

Un anno fa, l’8 Giugno 2011, ci son state le “prove generali” dell’implementazione globale di IPv6 (RFC 2460). Quel giorno più di 1000 grandi siti web (Google, Facebook, Yahoo, Akamai, Limelight e altri) hanno attivato il supporto IPv6 sui servizi principali per 24 ore, nell’ambito di un grande test coordinato su scala mondiale, allo scopo di far saltar fuori bug e/o errori a livello di implementazione e dare a tutti i players il tempo di correggerli e di adeguarsi.

Il test è stato un grande successo, ed è stata fissata, per domani appunto, la data dell’adozione definitiva di questa tecnologia (ai tecnici fa un pò ridere il chiamare IPv6 “tecnologia”, perchè esiste da 14 anni). “The Future is Forever” è il motto dell’iniziativa: da domani, il futuro è per sempre. Centinaia di siti, ISP e produttori di hardware adotteranno definitivamente IPv6. La lista completa dei partecipanti è qui.

D’ora in poi sarà supportato, ovunque: sui più grandi siti, sui più grandi CDN, sui router casalinghi, dagli ISP (in tunnel, quantomeno). Il mercato farà il resto del lavoro: finalmente, chi non si è svegliato e non si è aggiornato, inizierà a rimanere indietro e a perder colpi (e soldi).

Da domani, magicamente, un server dedicato con supporto IPv6 avrà più valore di uno che non ce l’ha. Un hosting con supporto IPv6, avrà più valore di un prodotto simile, in tutto e per tutto, ma senza IPv6. Una ADSL con supporto IPv6 nativo probabilmente avrà più valore di una concorrente forse un pochino più veloce, ma senza IPv6. Spendereste poi 150 € per comprare un nuovo router ADSL IPv4-only sapendo di doverlo buttare via tra un anno?

IPv6 diventerà un must, ovunque. Chi offre IPv6 corre, gli altri partono già doppiati. Bisogna muoversi, fare in fretta, perchè il rischio è quello di trovarsi con non una ma due internet prima di fine anno. Due reti separate, una v4 e una v6, non completamente connesse tra loro. Non è un bello scenario, per niente.

Non vorrei ritrovarmi a dover spedire pacchetti IP usando i piccioni (RFC 1149, che ci crediate o meno).

Per verificare lo stato del supporto IPv6 del vostro dispositivo / connessione, c’è un simpatico e utile tool qui. Se state cercando un Tunnel Broker decente e semplice da usare, consiglio Gogo6. Se invece avete un sito web con supporto IPv6, potete registrarlo al Launch Day qui.

Due curiosità: lo sapevate che chi ha progettato IPv4 (attuale RFC 791, Settembre 1981) negli anni ’70 si era reso perfettamente conto dei problemi legati allo scarso numero di indirizzi disponibili? Il problema è stato ignorato, perchè si trattava di un test e non si pensava ad una diffusione su scala mondiale in breve tempo. Il PIL mondiale di quegli anni non sarebbe bastato a comprare (ehm, costruire/creare) i 2^32 dispositivi che avrebbero potuto esaurire il numero di indirizzi disponibili.

Questo “casino” è “colpa” di chi ha sfruttato e diffuso una tecnologia che i suoi stessi creatori non ritenevano pronta ad uno sfruttamento e diffusione su larga scala, non si tratta di errori di progettazione o solamente di naturale crescita, come molti credono.

E la seconda curiosità: solo il 70% dei siti registrati al World IPv6 Launch sono globalmente raggiungibili via IPv6. Carina come cosa. Io, ovviamente, sono pronto da un pezzo (ma mi ero dimenticato di registrare questo blog).

Google ha pubblicato delle pagine informative, che puntano a spiegare in modo semplice e chiaro. Interessante il video in cui uno dei “fathers of the Internet”, Vint Cerf, spiega il problema dell’esaurimento di indirizzi, con l’aiuto di  immediata grafica. Da diffondere.

Correte, il conto alla rovescia è iniziato (e potete seguirlo anche su Twitter)!

Ps: Si, domani sarà anche un giorno importante, ma volete mettere con il mio compleanno, il 12 Giugno? Chi prepara il sito ed i badge?

Giorgio

RFC Ignorate: la fine del mondo inizia con Fastweb

RFC Ignorate: la fine del mondo inizia con Fastweb

Internet si basa su standard aperti, che vengono definiti attraverso discussioni “pubbliche” tra tecnici. Il meccanismo è semplice: per prima cosa, un gruppo di persone studia, disegna uno “standard”: decide che qualcosa debba essere fatto in un certo modo perchè pensa quella sia la soluzione migliore.

La seconda fase consiste nel pubblicare una RFC, Request for Comments, in modo che gli altri interessati possano leggerla e come il fantasioso nome suggerisce, commentarla. La proposta viene modificata per coprire le necessità di tutti e correggere eventuali errori e poi diventa “standard de facto”. Standard non imposti, che tutti rispettano perchè altrimenti sarebbe il caos più totale. E’ così che si va avanti da 30 anni, senza che mai il meccanismo abbia mostrato debolezze. E’ un pò lo stesso funzionamento dei semafori, niente impedisce a me di decidere che io passo quando è rosso e mi fermo quando è verde, ma non posso farlo perchè so che se anche uno solo si comportasse così tutto il sistema anrebbbe in panico.

Una importante Request for Comments, la RFC 1918, datata Febbraio ’96, ha stabilito che le classi di IP utilizzabili liberamente (senza richiederne l’assegnazione da parte dell’autorità) nelle reti private fossero:

192.168.0.0/16
172.16.0.0/12
10.0.0.0/8

Nell’Aprile 2012 a queste è stata aggiunta la classe 100.64.0.0/10, per i “Carrier Grade NAT” (RFC 6598).

Diverse entità, probabilmente allergiche agli standard, si sono appropriate di classi di IP senza averne titolo. A memoria, ricordo Fastweb, che usava (usa?) le classi 1.0.0.0/8, 2.0.0.0/8, 5.0.0.0/8 (and counting) per l’indirizzamento interno, H3G che ad oggi usa la 1.0.0.0/8, Hamachi e OpenVPN (nella versione a pagamento) che assegnano IP interni ai client dalla classe 5.0.0.0/8, Remobo, software simile ai precedenti che si è appropriato della classe 7.0.0.0/8 e così via.

L’ICANN, sapendo che queste classi erano di fatto utilizzate, pur non avendo intenzione di regolarizzarle (erano e sono utilizzate in modo assurdo, senza motivazione tecnica, sarebbe stato solo un enorme spreco di risorse) ha ritardato fino all’ultimo momento la loro assegnazione. Adesso però gli IP stanno finendo, e l’autorità per l’assegnazione è costretta ad utilizzarli.

Se un determinato ISP usa una classe in modo irregolare e questa viene assegnata, si ritroverà con un conflitto nel routing della sua rete interna: dovrebbe far “uscire” i pacchetti dalla sua rete per raggiungere il reale proprietario di quegli IP ma se lo facesse renderebbe irraggiungibili i suoi host interni che utilizzano (in modo, ci tengo a ricordarlo, illecito) tali indirizzi IP, creando disservizi. La questione è spiegata (anche) qui, in inglese.

A questo si aggiunge il problema del “Bogon Filtering“. Il bogon filtering è un semplice quanto effettivo metodo per filtrare pacchetti spoofed (attacchi, in altre parole): questa tecnica consiste nel filtrare direttamente alla frontiera della rete i pacchetti provenienti da IP non pubblici o da classi di IP non assegnate. Il motivo è chiaro: se gli IP che inviano quei pacchetti non sono stati assegnati a nessuno, la sorgente indicata non è quella reale e quindi si tratta di pacchetti “maligni” o di errori di configurazione. La logica conseguenza è che se una classe viene assegnata e l’ISP non aggiorna i suoi filtri continuerà a bloccarla credendola inutilizzata, rendendo ai suoi utenti impossibile raggiungere gli host remoti appartenenti a quella classe.

Alcuni ISP usano o hanno usato inoltre le classi non allocate per delle prove tecniche, annunciandole nelle tabelle di routing mondiali. Qualche annuncio “residuo”, al suo sovrapporsi con quelli nuovi e “leciti”, potrebbe quindi creare ulteriori conflitti nel routing delle nuove classi.

L’autorità per la registrazione si impegna a segnalare con adeguato anticipo le classi che stanno per essere assegnate, ma non tutti sembrano leggere queste pagine, come mostra questo grafico:

Si nota infatti che quasi il 10% degli AS mondiali non è in grado di raggiungere le classi indicate. Un grandissimo problema.

Temevo che qualcosa prima o poi sarebbe successo, e un messaggio di Marco questa notte me l’ha confermato: da rete Fastweb non si riescono a raggiungere IP della classe 5.0.0.0/8, assegnata in queste settimane a grossi ISP come Softlayer, Hetzner, OVH. Ne parlano qui, su HostingTalk.it. Leggendo poi questo topic su WebHostingTalk, scopro che il problema non è limitato a Fastweb, ma si verifica anche da altri ISP.

Ecco un traceroute da rete Fastweb verso un IP di Softlayer:

C:\Users\User>tracert 5.10.64.1

Traccia instradamento verso 5.10.64.1-static.reverse.softlayer.com [5.10.64.1]
su un massimo di 30 punti di passaggio:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2   226 ms    17 ms    17 ms  EDIT
  3    17 ms    16 ms    17 ms  EDIT
  4   492 ms    35 ms    17 ms  10.251.149.201
  5   122 ms    16 ms    16 ms  10.251.144.25
  6    47 ms   112 ms   164 ms  10.251.145.1
  7   537 ms   477 ms   250 ms  10.251.149.186
  8   351 ms    17 ms    17 ms  10.3.136.189
  9    41 ms    17 ms    20 ms  10.3.128.41
 10   135 ms    16 ms   471 ms  10.254.9.230
 11    69 ms    20 ms    21 ms  10.254.12.21
 12   150 ms    20 ms    20 ms  10.254.12.6
 13   125 ms    24 ms   417 ms  89.97.200.66
 14     *        *        *     Request timed out.
 15     *        *        *     Request timed out.
C:\Users\User>

Carino. Ecco cosa succede quando un grande ISP non rispetta gli standard che dovrebbero essere la base del suo lavoro. Crea un danno sia ai suoi utenti, che non riescono a raggiungere una parte di internet, sia alle entità a cui sono stati assegnati gli IP che lui usa in modo illecito.

Cosa fare quindi se vi trovate in una situazione simile, cioè se non riuscite a raggiungere alcuni IP (e quindi server)? Sarebbe totalmente sbagliato e inutile contattare il proprietario di quel nodo (server), perchè non ne ha colpa nè ha modo di risolvere il problema. La soluzione è chiamare il call center di Fastweb, bombardarlo, intasarlo giorno e notte ripetendo la segnalazione, perchè è una loro mancanza: offrono un servizio incompleto e non rispettano le RFC. Si tratta, a tutti gli effetti di un disservizio, quindi non esitate e soprattutto non accettate risposte che non contengano una promessa di immediata risoluzione del problema.

La parte più bella sta nel fatto che l’autorità (ICANN/RIPE) ha la possibilità di revocare le assegnazioni fatte a LIR (provider) che utilizzano senza averne titolo classi assegnate ad altri, come Fastweb sta facendo in questo momento. Se le segnalazioni all’autorità diventassero consistenti, Fastweb potrebbe rimanere completamente in mutande, senza più nemmeno un IP per far uscire i suoi utenti su internet. Meglio. Più IP disponibili per chi rispetta le regole.

E se invece siete voi proprietari di un server non raggiungibile da alcuni ISP? Anche qui, deve esser chiaro che non avrebbe senso (e non sempre sarebbe fattibile) richiedere a chi ve lo ha assegnato un nuovo IP “pulito”, o ritenere il vostro provider responsabile del problema.

Segnalate a ICANN/RIPE (tramite questo form) la violazione, perchè, come dicevo poco fa, Fastweb potrebbe pagarla davvero molto cara. Contattate voi stessi Fastweb, sia attraverso i canali di supporto ufficiali sia attraverso i contatti tecnici (reperibili tramite il RIPE), e, per finire, chiedete ai vostri utenti che stanno subendo un disservizio di fare lo stesso, chiedete che riportino il problema e che pretendano sia risolto in tempo reale. E’ davvero importante muoversi, perchè Fastweb sta danneggiando tutti.

Non sono un avvocato, ma immagino che sia i clienti Fastweb tagliati fuori da internet sia i proprietari dei server irraggiungibili possano chiedere pesanti risarcimenti al provider. E chissà che non si muova anche il CODACONS, che farebbe una delle prime mosse giuste e tecnicamente sensate della sua vita.

I LIR / AS a cui fossero stati assegnati gli IP “sfortunati”, potrebbero poi “convincere” gli ISP che creano loro tali problemi di raggiungibilità in diversi modi, più o meno leciti ma tutti visti negli anni: bloccando i peering, rendendo le loro reti completamente inaccessibili dagli ISP incriminati, droppando pacchetti a destra e a manca, in  modo che i clienti di questi ultimi, imbestialiti, aumentino la pressione.

Lo so, da tecnico non dovrei consigliare di “spammare” un call center e ripetere le segnalazioni, di solito non si fa così. Ma quando degli standard vengono violati tutto diventa lecito. “L’hai violato? Adesso assumi 250 persone per non far crollare il call center sotto le segnalazioni, e PEDALI, perchè non è così che si lavora.”.

Concedetemi un commento altamente tecnico nei confronti di Fastweb: “AHAHAHAHAHAHAHAHAHAHAHAHAH”.

Ricordatevi quindi: seppellite di segnalazioni chi ha sbagliato e chi vi sta veramente creando questo disservizio, non prendetevela con chi ha rispettato le regole e non ha nessuna colpa. Telefonate, telefonate e telefonate ancora, e quando siete stanchi fate chiamare anche i vostri parenti dalle altre stanze della casa. E il giorno dopo richiamateli, per chiedere aggiornamenti o anche solo per salutarli.

Se volete che il problema venga risolto, insomma, sostituite per i prossimi giorni il numero della vostra ragazza in rubrica con il numero del loro callcenter.

Concludo con un meritato #EPIC FAIL per Fastweb. Ovviamente non sono loro cliente. Non vorrei diventarlo neanche se mi pagassero loro stessi per usare i servizi che offrono. Però, ho ordinato ieri un server da Softlayer e rischio di ritrovarmi un IP appartenente alle classi di cui abbiamo parlato fino ad ora. Con le conseguenze di cui abbiamo parlato fino ad ora.

UPDATE: E’ quasi l’una di notte, del 19 Maggio, e ho appena visto il primo traceroute andare correttamente a destinazione da rete Fastweb. Tutti gli IP di test che avevo usato, Softlayer, OVH, Hetzner, vengono ora correttamente ruotati. Un traceroute in memoriam:

Traccia instradamento verso 5.10.64.1-static.reverse.softlayer.com [5.10.64.1]: 

  1 <1 ms <1 ms <1 ms  39.235.148.254 
  2    30 ms    49 ms    27 ms  10.128.96.1 
  3    49 ms    29 ms    29 ms  10.3.231.210 
  4    32 ms    32 ms    34 ms  10.251.143.209 
  5    30 ms    27 ms    28 ms  10.251.138.27 
  6    25 ms    27 ms    29 ms  10.251.139.1 
  7    32 ms    27 ms    29 ms  10.251.143.194 
  8    37 ms    32 ms    27 ms  10.3.134.241 
  9    32 ms    27 ms    28 ms  10.3.128.46 
 10    33 ms    28 ms    29 ms  10.254.11.69 
 11    36 ms    29 ms    35 ms  10.254.1.77 
 12    33 ms    95 ms    41 ms  89.97.200.62 
 13    28 ms    29 ms    38 ms  26.26.127.54 
 14    31 ms    37 ms    39 ms  93.55.241.54 
 15    37 ms    28 ms    29 ms  26.26.127.69 
 16    38 ms    39 ms    38 ms  93.57.68.21 
 17    30 ms    38 ms    39 ms  93.57.68.5 
 18    35 ms    36 ms    29 ms  if-5-0-0.core1.RCT-Rome.as6453.net [195.219.163.9] 
 19    59 ms    58 ms    59 ms  if-11-0-0-0.tcore1.PYE-Paris.as6453.net [80.231.154.41] 
 20    56 ms    59 ms    75 ms  if-2-2.tcore1.PVU-Paris.as6453.net [80.231.154.17] 
 21    57 ms    63 ms    76 ms  xe-6-3.r03.parsfr01.fr.bb.gin.ntt.net [129.250.8.177] 
 22    84 ms    58 ms    59 ms  ae-1.r21.parsfr01.fr.bb.gin.ntt.net [129.250.2.224] 
 23    79 ms    62 ms    75 ms  as-4.r22.amstnl02.nl.bb.gin.ntt.net [129.250.3.84] 
 24    64 ms    67 ms    69 ms  po-1.r01.amstnl02.nl.bb.gin.ntt.net [129.250.4.71] 
 25    64 ms   115 ms    62 ms  ae11.bbr01.eq01.ams02.networklayer.com.64.20.81.in-addr.arpa [81.20.64.50] 
 26    88 ms    61 ms    58 ms  ae5.dar01.sr01.ams01.networklayer.com [50.97.18.237] 
 27    65 ms    58 ms    65 ms  po1.fcr01.sr01.ams01.networklayer.com [159.253.158.131] 
 28    72 ms    62 ms    58 ms  5.10.64.1-static.reverse.softlayer.com [5.10.64.1]

Notate gli hop numero 1, 13 e 15. Il primo usa un IP appartenente ad una classe assegnata ad APNIC, che potrebbe entrare in uso a breve creando nuovi problemi di raggiungibilità. Il 13 e il 15 fanno parte di una classe assegnata al Dipartimento della Difesa americano. Inutile ripeterlo, Fastweb non ha titolo per usare nessuna di queste classi.

Com’è che si diceva del lupo?

Giorgio

Fibre vs rame: 2010 vs 1960

Fibre vs rame: 2010 vs 1960

In questo periodo sto facendo test senza scopo tirando in mezzo cavi seriali, paralleli, ethernet e fibre, tecnologie vecchie di 30 anni, e ne sto misurando latenze e velocità. Credo pubblicherò un report completo a breve, ma qualche appunto preso “on the road” lo trovate già QUI.

Oggi parlando con un amico mi è venuto in mente un paragone, tecnicamente non proprio completo e rigoroso*, ma veramente utile per capire, con una tecnica che definirei “da fruttivendolo”, il progresso e gli enormi vantaggi portati dalle fibre ottiche.

Un cavo in fibra ottica può portare 160 lunghezze d’onda. Ognuna di queste lunghezze d’onda porta un segnale da 10 Gbps. Ci sono quindi 1600 Gbps disponibili**. Un cavo seriale porta, in totale, al massimo 115200 bps. Quindi:

Velocità max fibra ottica = MaxFC = 1600 Gbps = 1 600 000 Mbps

Velocità max cavo seriale = MaxSC = 115200 bps = 0.1152 Mbps

Calcoliamo quindi quanti cavi seriali ci servono per raggiungere la velocità di una fibra ottica:

Numero cavi seriali = NSC = MaxFC / MaxSC = 1 600 000 Mbps / 0.1152 Mbps = 13 888 889

Adesso arriva la perla: un metro di cavo seriale pesa 50 grammi. Un metro di fibra ottica ne pesa meno di 2:

Peso fibra ottica = PFC = 2 g

Peso cavo seriale = PSC = 50 g

Per finire dobbiamo quindi calcolare quanti Kg di cavi seriali ci servono per raggiungere la velocità di un singolo cavo in fibra, dal peso di 2 grammi (0.002 Kg):

PtotSC = NSC x PSC = 13 888 889 x 50 g = 694 444 450 g = 694 444 , 450 Kg

Concludendo: per sostituire un cavo in fibra ottica (dal peso, come già detto, di due soli grammi) utilizzato per connettere due punti ad una velocità di 1600 Gbps ed alla distanza di un metro, ci servirebbero 14 milioni di cavi seriali, che avrebbero un peso totale di circa 700 tonnellate. Per UN SOLO metro di distanza. Vi lascio solo immaginare cosa vorrebbe dire sostituire anche solo le fibre transatlantiche.

C’è un’altro dato interessante: la fibra ottica ha una latenza di 5 microsecondi al Km, mentre un cavo seriale ha una latenza di 5 millisecondi al metro.

Latenza fibra ottica = LFC = 5 microsec / Km = 0.005 ms / Km

Latenza cavo seriale = LSC = 5 ms / m = 5000 ms / Km

Immaginiamo di dover collegare Amsterdam a New York e consideriamo una distanza in linea retta tra le due città di circa 6000 Km (inutile dire che chiaramente quella reale percorsa dai cavi sarebbe maggiore). Calcoliamo quindi la latenza, ovvero il tempo impiegato per percorrere questa distanza sui due tipi di cavi:

Distanza = D = 6000 Km

Tempo di percorrenza fibra ottica = TFC = LFC x D = (0.005 ms / Km) * 6000 Km = 30  ms

Tempo di percorrenza cavo seriale = TSC = LSC x D = (5000 ms / Km) * 6000 Km = 30 000 000 ms = 30 000 secondi = 500 minuti = 8 ore e 30 minuti

Questo, in linea teorica. Perchè per percorrere distanze così enormi il segnale deve essere rigenerato, e questo introduce tremendi ritardi nella trasmissione. Ricordo che per percorrere questi 6000 Km il segnale sul cavo in fibra (che percorre 50 Km senza rigenerazione) dovrebbe essere rigenerato (amplificato) 120 volte, mentre quello seriale dovrebbe essere rigenerato ogni 8 metri, ovvero 750 000 volte.

Numero rigenerazioni fibra ottica = NrFC = 120

Numero rigenerazioni cavo seriale = NrSC = 750 000

Qui azzardo una serie di conti, di cui non garantisco l’accuratezza teorica. Quello che è certo, è che comunque i numeri che otterrò saranno inferiori a quelli reali:

Il tempo reale di percorrenza in fibra ottica della linea Amsterdam – New York è di circa 80 ms. Quello teorico calcolato in linea retta è di 30 ms, quindi sembra ragionevole calcolare 40 ms teorici sulla tratta realmente percorsa. Significa che abbiamo circa 40 ms (sottraggo i 40 di tempo teorico agli 80 di tempo reale misurato) di tempo perso nelle 120 rigenerazioni. Questo vuol dire che una rigenerazione del segnale in fibra ottica ritarda il tutto di 0.34 ms.

Tempo reale percorrenza fibra ottica = TpFC = 80 ms

Tempo totale rigenerazione fibra ottica = TtotrFC = 40 ms

Tempo rigenerazione fibra ottica = TrFC = 0.34 ms

Con questi dati, calcolo il tempo impiegato da una rigenerazione del segnale per un cavo seriale. Uso la relazione LFC : TrFC = LSC : TrSC, quindi:

Tempo rigenerazione cavo seriale = TrSC = (LSC x TrFC) / LFC = (5000 ms / Km x 0.34 ms) / (0.005 ms / Km) = 340 000 ms

Come già detto, per percorrere questa distanza, il segnale di un cavo seriale deve essere rigenerato 750 000 volte, quindi calcoliamo il tempo totale di rigenerazione:

Tempo totale rigenerazione cavo seriale = TtotrSC = TrSC * NrSC = 340 000 ms * 750 000 = 225 000 000 000 ms

Per concludere devo calcolare il tempo totale impiegato per la percorrenza di questa tratta tramite cavo seriale:

Tempo reale percorrenza cavo seriale = TpSC = TtotrSC + TSC = 255 000 000 000 ms + 30 000 000 ms = 255 030 000 000 ms = 255 030 000 secondi = 4 250 500 minuti = 70 842 ore = 2951 giorni = 8 anni.

In fibra ottica, andiamo da Amsterdam a New York in 80 millisecondi. Con un cavo seriale, impiegheremmo 8 anni. Probabilmente sarebbe molto più conveniente inviare una lettera invece che una mail.

Giorgio

* RS 232 non è stato concepito per comunicazioni a lunga distanza: era usato per collegare i modem o i nodi di un cluster, comunque entro pochi metri. La sua portata è intorno agli 8 metri, questo vuol dire che ogni 8 metri serve un rigeneratore di segnale. Le fibre vanno invece per 50 Km o più senza essere toccate. Per finire, ad oggi non esiste modo di connettere due singoli punti utilizzando tutta la banda disponibile su un cavo in fibra ottica. Allo stesso modo non esiste un modo per connettere due host con 14 milioni di cavi seriali.

** Metto lì un dato senza approfondirlo ulteriormente: abbiamo una velocità di 1600 Gbps per singolo cavo. Le linee transoceaniche sono però composte di fasci di 864 cavi, e di solito sono stese a coppie.