Il lato oscuro dell' mlag

Nella giornata di stamattina abbiamo avuto un failure parziale della rete core rendendo alcune rotte internazionali irraggiungibili. Alle 6.37 del mattino il NOC, riceve un alert per irraggiungibilità, da alcune locations. I nostri tecnici in smart working son intervenuti immediatamente alla verifica del problema riuscendo a connettersi correttamente dalla propria linea di casa.

L’ anomalia nasce quando uno dei nostri tecnici si accorge che da rete TIM effettivamente la rete è irraggiungibile, mentre Fastweb, Iliad etc ci raggiungono correttamente. A quel punto iniziamo la verifica dei transit routers che risultano correttamente raggiungibili, nel mentre iniziamo a ricevere alert di sessioni BGP down tra i Transit Routers (tutti, o quasi!) e i Core Router.

Dobbiamo prima di tutto conoscere com’è strutturata la nostra rete

Da questa rappresentazione ho rimosso tutti i link di management, del sistema AntiDDoS, IP Transit e alcuni devices che non sono interessanti per questo articolo.

I due concentratori, switch con porte 100G sono configurati in mlag, protocollo proprietario che permette di “unire” i due switch. In caso di failure di uno dei due switch, tutti i router Transit possono parlare coi Core Routers. La rete è composta da un ulteriore router, chiamato IX (Un juniper MX240) che svolge la funzione di collegamento con gli Internet exchanges e connessioni private.

Perchè i concentratori? Perchè, la nostra rete ha una capacità internet di 1,21 Tbps, ma il reale utilizzo del datacenter, in condizioni normali è più basso, quindi non necessitiamo di avere la stessa capacità internet verso i Core Router. Parte del traffico inoltre, durante l’ attacco passa per la rete di Mitigazione DDoS (Qui non mostrata) e in parte è riservato ai clienti Transito Protetto.

Ma torniamo a noi, per un motivo ancora a noi sconosciuto, i due “Concentratori”, hanno smesso contemporaneamente di fare forwarding dei pacchetti. Appurata la problematica il nostro reperibile si è mosso per chiamare, in H24, il presidio del datacenter che ospita l’ architettura, Irideos S.p.A. . Nessuna risposta….

Ma perchè la nostra rete era a tratti raggiungibile? Perchè il router IX non è stato impattato!

Immaginatevi, durante il guasto di avere la rete in questa configurazione:

Facile capire le conseguenze no? La rete era raggiungibile solo per le rotte inviate dal router IX & PNI.

Nel mentre abbiamo aperto una TAC al nostro vendor per capire, dall’ analisi dei log, cosa ha portato al blocco contemporaneo di due switch in configurazione mlag (bug sul protocollo?). In aggiunta abbiamo riscontrato le problematiche della nuova società che ha acquisito il datacenter in cui abbiamo il POP primario di Milano. Le emergenze bloccanti vengono gestite così “Apri un ticket e aspetti, qualcuno in giornata risponderà”. Così la soluzione più rapida è stata mandare un reperibile in datacenter ed eseguire un riavvio degli switch (operazione da 3 minuti, ma che dovendo recarsi fisicamente in datacenter ha permesso di risolvere la problematica solo alle 10.12, imperdonabile!… ndr).

Ok, lezione imparata. Chi fa da sè….

Siamo subito corsi ai ripari modificando l’ architettura di rete, spostando un transit router fuori dagli switch. In questo modo, in caso di nuovo problema agli switch la rete sarà comunque funzionante. E ora vi chiederete, ma se per un riavvio dovete aspettare una giornata, rischiamo di “rimanere zoppi” fino al ripristino? No! Ed è per questo che abbiamo tardato a scrivere il post-mortem, habemus solution .

Su tutti i pop (quindi non solo a milano), installeremo un Router 4G connesso ad un management server. Tale soluzione ci permetterà l’ accesso anche a rete irraggiungibile. Tutti gli apparati verranno collegati a delle PDU intelligenti in grado di rimuovere la corrente. Per garantire la ridondanza delle fasi elettriche, ogni PDU sarà connessa ad una differente fase.

In caso di blocco, ci collegheremo al management server ed effettueremo un riavvio in piena autonomia.

  • E quanto sarebbe stato il disservizio se aveste già questa soluzione? Probabilmente inferiore ai 15 minuti…. sigh
  • Ma perchè non ci avete pensato prima? Perchè quando posiamo un POP, firmiamo contratti H24 con presenza On-Site. Tali contratti prevedono un numero da chiamare e un riavvio viene eseguito in pochi minuti… anzi veniva. A Milano abbiamo scoperto che questo punto è stato unilateralmente modificato (e senza avvisi).

Nei prossimi giorni ci muoveremo alla correzione della rete. Non ci saranno downtime o degrado nel servizio, sarà tutto totalmente trasparente. Daremo priorità al POP di Milano e poi a Cascata.

La rete sarà così (in verde quello già fatto, in rosso quello che faremo). Ho messo solo alcuni link rossi per non renderla troppo complicata da leggere, ma sarà tutto ridondato

Dura la vita del network engineer…

 

Per domande scrivetemi pure a matteob [at] seflow [dot] net

 

Matteo Berlonghi