Incidència connectivitat diumenge 30 d’agost de 2020
El diumenge 30 d’agost de 2020 un dels majors proveïdors de connectivitat a nivell mundial (CenturyLink/Level3) va experimentar una caiguda total de la seva xarxa de comunicacions. Aquesta caiguda va afectar tant a clients de CenturyLink/Level3 com a altres serveis i proveïdors a tot Internet.
Mentre seguim esperant un informe per part de CenturyLink/Level3 especificant l’origen de la caiguda, com es va actuar per posar-hi remei i que mesures s’estan prenent per evitar que torni a produir una situació similar, volem fer-te arribar el nostre informe sobre com es va gestionar la incidència des Clouding.io.
Antecedents
A Clouding.io treballem amb múltiples proveïdors de connectivitat, per assegurar la major disponibilitat i velocitat d’accés als servidors allotjats a Clouding.io, des de qualsevol punt geogràfic.
Afegim o retirem puntualment proveïdors de la nostra “pool” de connectivitat en funció de la seva qualitat i fiabilitat.
CenturyLink/Level3 va ser agregat fa aproximadament dos anys a la nostra plataforma, ja que entre altres coses aporta una connectivitat excel·lent cap a tots els clients de Movistar a Espanya.
Durant els últims dos anys -i fins aquesta última incidència- ha estat el millor proveïdor de la nostra “pool” de connectivitat i el que en l’actualitat transporta més trànsit des de i cap a Clouding.io.
Incidència 30 agost 2020
A les 12:18 CEST -hora local d’Espanya- nostres sistemes de monitorització van detectar els primers problemes de connectivitat. El nostre sistema de monitorització funciona tant des Clouding.io cap a l’exterior -comprovant la connectivitat des de la nostra plataforma cap Internet- com des de l’exterior cap a Clouding.io.
El monitoratge extern de connectivitat de la plataforma, es realitza mitjançant un proveïdor de monitorització, de manera que es monitoritza la connectivitat un cop per segon des de múltiples ubicacions geogràfiques.
El sistema de monitorització externa va començar a reportar de problemes puntuals de connectivitat a les 00:18:31 PM CEST els quals es recuperaven al cap de 2 o 3 minuts.
Al rebre la primera alerta, un dels nostres tècnics de guàrdia va revisar el flux de trànsit als diferents proveïdors, detectant que no s’estava enviant ni rebent trànsit a CenturyLink/Level3 però que la sessió BGP fins a ell mateix seguia activa.
Aquest tipus de situacions no haurien de passar, ja que, en cas d’una error en un proveïdor, el comportament esperant és que la sessió BGP es desconnecti i el proveïdor quedi desactivat automàticament.
La situació que es va produir va ser el que se sol anomenar un “BGP Blackholing”, situació en la qual un proveïdor deixa de d’utilitzar trànsit correctament sense arribar a desconnectar la sessió BGP.
Davant d’aquestes situacions excepcionals, el nostre protocol d’actuació és molt senzill: Simplement desactivem manualment la sessió BGP amb el proveïdor afectat i ens posem en contacte amb ells per saber que ha passat. Un cop el proveïdor ens indica que la situació ha estat solucionada, es programa una finestra per reactivar la connectivitat amb el mateix.
Per precaució la connectivitat se sol restablir en hores de baixa càrrega, habitualment de matinada, per evitar problemes de connectivitat en el cas que el proveïdor no hagi solucionat la incidència correctament.
La “pool” de proveïdors de connectivitat de Clouding.io aquesta dimensionada de manera que fins i tot amb un sol proveïdor actiu, disposem d’ample de banda més que suficient perquè el rendiment del servei no vegi afectat gens ni mica.
Per què ens es va solucionar la incidència en aquest moment?
Bé, això és una cosa que ens seguim fins a cert punt preguntat. Estem esperant un informe detallat per part de CenturyLink/Level3 , però des de l’equip de Clouding.io hem pogut recopilar força informació.
Segons la informació que hem pogut demanar, CenturyLink/Level3 va seguir anunciant les nostres IPs a la resta d’Internet, tot i que havíem tancat manualment la sessió BGP amb ells.
Això és una cosa que mai hauria de passar, ja que un proveïdor només hauria d’anunciar les nostres adreces a altres proveïdors sempre que nosaltres les hi estiguem anunciant en aquest moment.
Al tancar manualment la sessió BGP de Clouding.io cap CenturyLink/Level3, CenturyLink/Level3 hauria d’haver deixat d’anunciar les adreces IP de Clouding.io a la resta d’Internet, de manera que el trànsit passés a ser redirigit a altres proveïdors.
A l’ésser CenturyLink/Level3 un proveïdor Tier 1 és a dir, uns dels proveïdors de connectivitat més grans amb àmplia presència a nivell mundial-. I al seguir anunciant les nostres adreces IP a la resta d’Internet, part del trànsit d’entrada a Clouding.io no es va redirigir normalment cap als altres proveïdors amb els quals treballem i es va seguir intentat enviar per la xarxa de CenturyLink/Level3 la qual es trobava inoperativa.
Què vam fer des Clouding.io per solucionar el problema?
El primer pas va ser identificar l’origen de el problema, per al que vam haver de consultar a altres proveïdors per veure que anuncis estaven rebent.
Paral·lelament vam obrir incidències amb tots els nostres altres proveïdors, per assegurar-nos que estaven al tant de la situació i que ells prenguessin també mesures pal·liatives.
Un cop vam detectar que molts proveïdors seguien rebent els anuncis d’adreces de CenturyLink/Level3 vam començar a realitzar canvis en la forma en què vam anunciar les nostres adreces IP a la resta de proveïdors.
El protocol BGP sol optar sempre per l’anunci més específic. És a dir, si per exemple un anunci conté un grup de 2048 IPs i un altre un grup de 1024 IPs, donarà preferència -excepte en alguns casos en què el trànsit estigui forçat- a l’anunci més específic, és a dir el de 1024 IPs.
Per tant, la primera mesura pal·liativa va ser canviar tots els nostres anuncis a anuncis més específics, per suplantar els anuncis que CenturyLink/Level3 seguia fent. Aquest procediment és una mica complex, ja que implica reconfigurar els nostres Edge Routers i en alguns casos s’ha de coordinar amb els diferents proveïdors, ja que ells també han de realitzar canvis en els seus filtres d’anuncis.
Aquesta estratègia ens va permetre anar recuperant la connectivitat de la major part d’Internet, si bé no va ser una solució completa, ja que alguns proveïdors de connectivitat externs a Clouding.io ens seguien intentant enviar el trànsit mitjançant CenturyLink/Level3.
Quina va ser l’escala de temps exacta de la incidència?
És bastant difícil identificar l’escala de temps exacta, ja que aquesta incidència afecte a multitud de proveïdors i serveis d’Internet. Entre ells a sistema de monitorització externa que fem servir, però segons la informació que hem pogut recaptar l’escala aproximada va ser:
12:18 CEST – Es detecta la primera incidència.
12:21 CEST – Desactivem la connectivitat amb CenturyLink/Level3 manualment.
12:45 CEST Aprox. – Comencem a publicar nous anuncis BGP recuperant progressivament major connectivitat.
Entre 12:30 i 14:30 – Diversos proveïdors mundials desactiven manualment les seves sessions BGP amb CenturyLink/Level3 per eliminar els anuncis falsos, procés que ens ajuda a recuperar encara més gran connectivitat.
16:00 CEST Aprox – CenturyLink/Level3 aconsegueix eliminar els anuncis “falsos” que estava realitzant i es recupera el 100% de connectivitat.
Conclusió
A causa de la naturalesa d’Internet -una gran xarxa conformada per altres xarxes interconectadas- sempre existiran factors que s’escaparan al nostre control. Si bé la nostra filosofia sempre ha estat -i seguirà sent- treballar amb els millors proveïdors, per minimitzar el risc d’incidències en el servei.
Aquesta ha estat una de les majors caigudes d’Internet a nivell mundial dels últims temps i malauradament no hi ha una forma senzilla d’automatitzar un sistema capaç de reaccionar a aquest tipus de situacions.
En tot cas, considerem que una incidència en el servei sempre ha de comportar millores, ja sigui en els nostres sistemes o en els nostres protocols d’actuació. Per tant, hem començat a treballar en una forma més ràpida i senzilla de canviar els anuncis de rangs IP que vam realitzar a Internet. D’aquesta manera en l’estrany cas que una situació així es torni a produir, podrem reaccionar més ràpid i recuperar el major percentatge de el servei en un menor espai de temps.
Links Noticies relacionades
https://blog.cloudflare.com/analysis-of-todays-centurylink-level-3-outage/
https://edition.cnn.com/2020/08/30/tech/internet-outage-cloudflare/index.html
Deixa un comentari