Martedì scorso 12 agosto 2014, verso le 10 uno dei nostri clienti ci ha segnalato che i servizi da noi ospitati non erano più disponibili. Tuttavia, il monitoraggio dei nostri server e servizi non aveva segnalato nessun malfunzionamento e nemmeno il nostro servizio di sorveglianza esterna era scattato. Inoltre, alcuni clienti ci hanno informati tramite i social media che i nostri servizi attraverso alcuni provider di accesso non erano raggiungibili.

La situazione iniziale faceva pensare che si trattasse di un problema di routing esterno. Abbiamo preso in esame un’ampia gamma di possibili spiegazioni coinvolgendo anche il nostro partner IP-Transit. Ricostruire la dinamica dei problemi di questo tipo richiede spesso molte risorse perché sono coinvolte più reti e svariate parti terze. A seguito di approfonditi test è emerso che la causa del problema non era da ricercare qui.

Per questo ci siamo poi concentrati sui router che collegano la nostra infrastruttura con il mondo esterno. Questi router utilizzano le tabelle di routing, per essere in grado di conoscere attraverso quale delle reti a noi collegate può essere raggiunto un determinato destinatario nel minor tempo possibile. Già all’inizio del problema avevamo appurato che non si trattava né di errori nelle entry delle tabelle di routing, né di mancate entry. Anche dopo un’analisi più attenta tutto è risultato essere a posto e che i router avevano funzionato correttamente.

Quando sono emerse segnalazioni relative ad attuali problemi di altri provider internet a livello mondiale, che sembravano essere causati da un aumento improvviso e al di fuori dalle norma delle entry nelle tabelle di routing, abbiamo verificato anche questa opzione. Le nostre sessioni BGP non potevano essere intaccate da questo problema perché i nostri router hanno sufficiente RAM. Ma tenendo conto che i router, indipendentemente dal BGP, per il routing basato su hardware hanno un limite artificiale di 512 000 entry, abbiamo deciso di approfondire le verifiche, anche se questi non erano più sovraccarichi. Controlli a campione degli indirizzi IP coinvolti hanno mostrato che gli stessi erano presenti nelle tabelle hardware (TCAM). Questa constatazione e il fatto che un reboot di componenti di tale importanza durante il giorno viene effettuato solo in casi eccezionali, ci hanno spinto in un primo momento a non riavviare i router.

Tuttavia a seguito di ulteriori indagini è emerso che la causa del problema era il sovraccarico delle tabelle hardware, nonostante non fosse emerso nulla dai controlli a campione. Dopo aver eseguito il reboot tutto ha ripreso a funzionare normalmente. Abbiamo quindi concluso che il superamento del limite abbia portato a dimenticare alcuni percorsi critici che purtroppo non sono stati subito identificati dai nostri controlli a campione. Inoltre, nonostante il riavvio delle sessioni BGP, questi percorsi non sono stati sostituiti dopo che si era ritornati al di sotto del limite.

Misure introdotte
A seguito dell’accaduto abbiamo introdotto alcune misure in ambito tecnico:

  • Il limite per il routing basato su hardware è stato innalzato a 800 000 entry. Questo riduce notevolmente la possibilità che possa ripresentarsi una situazione simile.
  • Il monitoraggio del router sarà incrementato in modo da poter individuare in futuro tali anomalie più rapidamente.
  • Inoltre stiamo cercando di chiarire il motivo per cui è stato possibile superare il problema solo con un reboot, anche se si era già tornati al di sotto del limite massimo.

Desideriamo scusarci per gli inconvenienti causati. Vogliamo assicuravi che trattiamo questi eventi con la massima serietà e che faremo tutto il possibile per poter offrire i nostri servizi di nuovo con la massima qualità, alla quale siete abituati e che avete il diritto di richiedere anche in futuro.

Spiegazione dei problemi di rete del 12 agosto 2014

Markus Gebert

Markus Gebert è co-proprietario di Hostpoint e responsabile per l'ingegneria e lo sviluppo.

0