Oh, fastly.

Oh, fastly.

Oh, fastly.

Nel casino che e’ successo stamattina sono stato coinvolto di striscio perche’ uno dei due progetti ove sono allocato gestisce anche degli LSR (se i backbone sono le autostrade di internet, gli LSR sono il casello, e il BNG e’ lo svincolo).

Prima di arrivare al punto, ci sono due cose da dire.

Fastly pubblichera’, si spera, un cosiddetto “postmortem”, cioe’ un’analisi completa di quanto e’ successo alla rete, e del perche’ un numero enorme di AS sono improvvisamente scomparsi dalle tavole di routing.

Solo loro possono farlo, perche’ solo loro hanno tutti i tracciati e i log per farlo. Quello che si e’ visto da fuori consente solo ipotesi.

Si dice sui giornali che si e’ “spenta una CDN”. Ma una CDN non “si spegne” , e’ troppo distribuita: e’ una specie di sistema logistico dei contenuti, che porta i contenuti piu’ richiesti in una certa zona in un data center in quella zona. Come fa Amazon, che mette la pasta nei magazzini in Italia perche’ se ne consuma di piu’, e la birra nei magazzini tedeschi. Serve a minimizzare i costi.

Dicevo, una CDN non “si spegne”. Ma il problema e’ siccome il suo lavoro e’ quello di spostare i dati vicini a voi, una CDN deve essere molto intelligente a calcolare le distanze e la geometria. “Distanze e geometrie” nel gergo di internet sono il “routing”, gestito attraverso un “coso” che si chiama BGP.

Allora, come funziona il “routing”? Partiamo dal semplice. Immaginate di dover andare da Bologna a Milano. Allora potreste arrivare al casello di Casalecchio di Reno e chiedere. Quello vi dira’ “vada verso Modena Sud”. Poi arrivate a “Modena Sud”, e chiedete di nuovo. E vi dicono “Andate a Modena Nord e chiedete”. E cosi’ via, sino a Milano. I caselli sono i border routers, e dentro c’e’ un omino che ogni volta prende la carta, vi chiede dove andate e vi calcola la rotta (no,  i pacchetti IP non hanno il navigatore).

Potreste, ad un certo punto, avere un “reflector”. Diciamo che lavorate ad un casello e vi  rompete i coglioni di calcolare la rotta a tutti, e come voi, tutti i casellanti da parma a Milano decidono di chiamare l’amico Gianpiernaik a Milano. E tutti i caselli si allineano a quello.

In questo caso, l’amico di Milano si chiama “BGP reflector”. Perche’ e’ comodo? Perche’ se la strada dovesse cambiare, per qualsiasi motivo, basta che informiamo Gianpiernaik, cioe’ il reflector, invece di informare OGNI cazzo di casello dopo Parma.

Bene.

Adesso immaginate che Gianpiernaik da solo non ce la faccia, e KarenDeborah (uso dei nomi milanesi a caso) gli dia una mano ad informare tutti. La condizione perche’ questo funzioni e’ che Gianpiernaik e KarenDeborah siano sempre al lavoro (almeno uno dei due) e che diano le stesse indicazioni. IN quel caso abbiamo dei reflector clusters.

Bene. Ci sono due cose che avrete intuito.

Se tutti i casellanti chiamano il vostro amico e la vostra amica, le cose vanno storte nel caso:

  1. in cui il vostro amico e la vostra amica diano strade diverse.
  2. il caso in cui il vostro amico e la vostra amica  dicano a tutti “e ora vai AFFANCULO! Ti ODIO! _next:0.0.0.0! MUORI! “.

La numero due potrebbe essere l’equivalente di quello che si chiama “blackhole”, ovvero il caso in cui ai pacchetti viene detto di morire sul posto, e pure male.

Ecco, siccome una CDN deve essere MOLTO brava a decidere dove spostare cosa, e quindi a calcolare rotte, fara’ un uso smodato di queste tecniche. Il guaio e’ che, vista da fuori, e’ sembrato che per un attimo tutta la rete di Fastly sia finita in blackhole: nessuno sapeva piu’ come diavolo arrivarci,e  quando lo chiedevano la risposta era “_next: CREPASULPOSTOEPUREMALE”.

Questo, sia chiaro, non vuole dire che si possa dire da fuori cosa sia successo. Magari questo era un effetto di un altro guasto. Quindi occorre per forza aspettare il postmortem di Fastly.

Quello che sto dicendo e’ che l’effetto che abbiamo visto e’ quello che si vede quando un cluster di reflectors va a puttane. Ma NON SO se sia questo quanto avvenuto.

La domanda che farete e’:  supponiamo che un problema di reflection sia il problema, ma quanto e’ facile ottenere un effetto del genere? Basta un errore umano? La risposta e’…. brutte notizie.

Basta un errore umano.

Siccome in qualsiasi campo puo’ bastare un errore umano, chiariamoci pure: il BGP ha il piccolo difetto di PROPAGARE i problemi. Ha la bella caratteristica di PROPAGARE informazioni utili. Ma se ci mettete dentro immondizia, non vale il motto “immondizia in input, immondizia in output”. Vale di piu’ il motto “immondizia in input, nevica immondizia da qui a Betelgeuse”.

Bene. Cosi’ sapete che prima di mettere le mani sul BGP, ci si accerta che ci siano DUE persone dietro alla console, (se gestite reti molto grosse), si fanno riunioni che ITIL chiamerebbe CAB , e tutto quanto. E’ vero che col passare del tempo la resilienza e’ aumentata, ma se un attore come Fastly fa una cappella su un cluster di reflector, il resto del mondo LO SA.

Quindi la CDN non si e’ spenta. Semplicemente , apparentemente, nessuno sapeva come andare oltre il bordo: e’ come se fosse stato possibile arrivare a Parma, e da li’ i caselli non sapevano che fare.

E siccome la CDN gestisce anche dei DNS, sono stati ongoiati nel blackhole anche loro. E con loro i server sul bordo.  E via cosi’, a catena, e nevica immondizia sino a Betelgeuse.

E qui siamo al problema.

Internet e’ nato come sistema decentrato. Cose come BGP, a patto di avere dei border router (i caselli dell’autostrada di prima) capaci di tenere tutta la mappa per poter calcolare la rotta da A a B, qualsiasi A e B, erano sufficienti a tenere tutto sotto controllo.

Ma adesso , cioe’ nel 2021, abbiamo un problema: ci sono enti che fanno (come nel caso di Google) il 30% del traffico backbone da soli. E delle fette a due cifre del traffico appartengono piu’ o meno a tutti i GAFAM.

E quindi si, se per esempio in Facebook  o in Google facessero un cappellone col BGP, potrebbero davvero far cadere porzioni significative di Internet.

Anche perche’, come potreste immaginare, se spariscono tutte le rotte per Milano, il problema non e’ solo di quelli che vogliono ANDARE a Milano, ma anche tutti quelli che volevano solo passarci dovranno ricalcolare le rotte. Quindi se va giu’ un bel pezzo di rete, il resto segue, e l’effetto domino non e’ da escludersi: se anche non venisse giu’ tutto, ci sarebbe comunque da considerare il tempo di spegnere tutte le oscillazioni (nel nostro esempio gli automobilisti che decidono di prendere il casello di Torino e poi si accorgono che anche il reflector di Torino li sfancula, e decidono di tornare a Milano, eccetera). Oppure, se il reflector di Milano decide di mandare TUTTI a Quarto Oggiato, potrebbero succedere degli ingorghi: Quarto Oggiaro non puo’ reggere tutto il traffico di Milano.

La centralizzazione di Internet in pochi attori dal peso bestiale E’ UN PROBLEMA. E non migliorera’ in futuro.

Non migliorera’ perche’ tutti questi attori continuano a fare sempre piu’ traffico. Qual’e’ il problema?

Il problema e’ che su internet ci vogliamo far passare il fintech, l’ IoT, le auto connesse, la medicina a distanza, il LAVORO a distanza.

Stiamo mettendo la cristalleria e il toro nella stessa stanza. Cosa potrebbe mai andare storto?

Quando dici questo nel “mio” ambiente, le risposte sono di una cialtroneria incredibile.

  • Sta roba sta diventando pericolosa. Davvero volete mettere le smart cities su questa roba?
  • Ma cavo, esiste l’edge computing, mettevemo le cose che ti sevvono vicine a te. Cosi’ se google va in mevda , il tuo conto in banca lo vaggiungi lo stesso.
  • E sai che cazzo me ne faccio di internet allora, se con l’edge computing mi porti la banca nel Central office? Se Internet mi viene garantita solo per cose vicine, mi conviene andare a piedi nel cazzo di ufficio della banca!
  • Ma edge computing e’ fico. E’ cool. E se una cosa e’ cool, DEVE esseve la soluzione. Viempiamo di sevver il Centval Office, e la minchia ti si allunga.
  • Ma guarda che una CDN e’ proprio un sistema di edge computing, e sono proprio quelle che stanno avendo i problemi piu’ frequenti! Come fa il problema a diventare la soluzione?
  • Ma noi siamo bellissimi.

Potrei elencare tutta una serie di “rimedi” che si suppone funzioneranno in un mondo che dipende da internet, al prossimo crollo simile, e ogni volta avremmo un tizio che non sa configurare il router di casa , in cattedra, a spiegarti che no, mettere il toro nella stessa stanza ove hai i cristalli e’ una cosa saggia, a patto che l’argenteria te la ficchi nel culo.

Personalmente, sono scettico sul fatto che riempire di server un CO serva a qualcosa, (anche perche’ sarebbero comunque offband) , ma c’e’ sempre il “cool guru” di diciannove anni che ti spiega che P4 risolvera’ ogni problema e le smartNIC sono la soluzione, sempre e ovunque. (casualmente, “cool guru” vende chip P4 e SmartNIC, ma e’ un caso).

Ma il punto e’ questo: come avete notato oggi, mettere il  toro nella stessa stanza ove tenete la cristalleria non e’ una mossa saggia.

Se poi e’ il toro quello incaricato di lucidare i vostri Boemia, come capita per le CDN, secondo me  ci stiamo cercando guai, e prima o poi ci troveremo a discutere sul da farsi, URGENTEMENTE, dopo un incidente abbastanza grosso da fare DAVVERO male.

Esistono TROPPI attori capaci di mandare in merda pezzi consistenti di INternet. E l’unica sicurezza che abbiamo e’ “eh, ma quelli sono sistemisti con le palle”. Vero, ma sono umani. (anche se a volte, lo ammetto, sembrano Vogon). E se fai molte cose, fai molti errori. solo chi non fa niente non fa errori. Quelli fanno un sacco di cose.

Ripeto. So solo dire che la CDN non si e’ “spenta”, semplicemente e’ apparsa come se nessuno sapesse come diavolo raggiungerla , dopo i server sull’edge. Era li’, le macchine erano accese, ma nessuno sapeva come diavolo arrivarci. E’ come se tutti sapessero come arrivare in lombardia, arrivassero a Parma, e poi… boh.

Non e’ detto , ripeto alla nausea, che questa sia la “causa prima” di quanto accaduto, cioe’ la “root cause”. Bisogna aspettare che esca l’analisi “post-mortem” di quanto accaduto.

E qui c’e’ il secondo problema: queste aziende NON hanno alcun interesse a dire la verita’. Spesso fanno comunicati ambigui e difensivi per spiegare quanto successo: dopo quasi 10 anni stiamo ancora aspettando di sapere che diavolo sia una “storage storm”, fenomeno col quale Amazon ha “spiegato” un outage durato quasi tre giorni su AWS.

Quindi non e’ nemmeno detto che sapremo mai, di preciso, cosa sia successo.

E questa e’ un’altra conseguenza del fatto che non solo ci sono troppi attori “sistemici”, ma che questi attori non sono trasparenti e non sono obbligati ad esserlo.

In queste condizioni, ci stiamo costruendo da soli i problemi che verranno. Stiamo letteralmente lavorando alla costruzione del muro sul quale sbatteremo, prima o poi , la faccia.

Ma a quanto vedo, nessuno si sta ponendo il problema. Il motto di oggi e’ “cool before of important”: prima pensiamo a Tinder for Cats, e al routing… poi ci pensiamo.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *