Wie im Krimi: So verlief der Netzausfall bei Things Mobile
So verlief der tagelange Netzausfall bei Things Mobile
Logo: Things Mobile
Tarife für die Vernetzung von Sensoren, Maschinen und Trackern gibt es nicht mehr nur für teures Geld bei den Netzbetreibern. Zahlreiche Discounter bieten inzwischen günstige Tarife für eine weltweite Vernetzung an, oft sind die Tarife in vielen Ländern weltweit verwendbar - was bei einem weltweiten Warenverkehr auch sinnvoll ist.
Der 2017 gestartete IoT-Discounter Things Mobile aus Italien, den teltarif.de seinerzeit ausführlich getestet hatte und der von denselben Betreibern wie die Reise-SIM ChatSIM stammt, informiert seine Kunden nun über einen größeren Netzausfall, der zwischenzeitlich offenbar ungeahnte Ausmaße angenommen hatte.
Server geben falsches Datum und falsche Uhrzeit aus
So verlief der tagelange Netzausfall bei Things Mobile
Logo: Things Mobile
In einer langen E-Mail an die Kunden berichtet Things Mobile ungewöhnlich offen und technisch detailliert über den Ausfall des weltweiten Datendienstes, der am 12. Juli begonnen hatte und bis zum 14. Juli andauerte. Dieser Vorfall sei der kritischste gewesen, den der Netzwerk-Partner (MNO-Partner) von Things Mobile jemals erlebt habe, und er sei sowohl hinsichtlich seines Ausmaßes als auch seiner Dauer außergewöhnlich gewesen.
Wie bei den meisten Telekommunikationsbetreibern basieren die Dienste des MNO-Partners auf einem vollständig ausfallsicheren IP-Netzwerk. Der MNO-Partner betreibt ein Netzwerk, das aus rund 100 IP-Routern besteht, die von Cisco bereitgestellt und nach einem von Cisco genehmigten Design konfiguriert wurden. Diese Router sind über das IP-Netzwerk mit zwei Quellen verbunden, die Datum und Uhrzeit vorgeben (Network-Time-Protocol-Server/NTP - aus Gründen der Ausfallsicherheit als primäre und sekundäre verwaltet).
Am 12. Juli erzeugte eine der beiden Uhrzeit-Quellen ein falsches Datum (27/11/2000). Da die Quellentaktung aus Service-Sicht verfügbar war, wechselten die Router, deren primäre Uhrzeit- und Datums-Quelle dieser Server war, nicht zur sekundären Taktquelle, sondern begannen stattdessen, diesen falschen Zeitstempel an die anderen Netzwerkrouter des MNO-Partners weiterzugeben.
Das Unglück nahm seinen Lauf
Unter dem Gesichtspunkt der Synchronisation sind die IP-Router so ausgelegt, dass sie entweder einem falschen Datum beziehungsweise Zeitstempel oder sogar dem völligen Fehlen eines Taktsignals standhalten, da sie alle über eine lokale Uhr verfügen, auf die sie umschalten können.
Um Routing-Informationen untereinander auszutauschen, verwenden IP-Router ein Protokoll namens IS-IS (Intermediate Systems to Intermediate Systems), ein Protokoll, das von der Internet Engineering Task Force (IETF) entwickelt wurde. Dieses Protokoll ist auf allen Routern des MNO-Partners implementiert. Um das IS-IS-Protokoll zu sichern, authentifiziert sich jeder Router bei seinem Nachbarn mit einem lokal gespeicherten Passwort.
Der Grund, warum dieser falsche Datums- beziehungsweise Zeitstempel so dramatische Auswirkungen auf die Router hatte, wird durch ein unerwartetes Zusammenspiel erklärt, bei dem das lokale Kennwort vom IP-Router nur ab einem explizit konfigurierten Datum im Router ab dem 1. Juli 2012 als gültig angesehen werden kann. Things Mobile vermutet, dass dies das Datum ist, an dem die ersten Cisco-IP-Router bereitgestellt wurden.
Da das übertragene Datum (27.11.2000) vor dem Startdatum der Kennwortgültigkeit (01.07.2012) lag, funktionierte der Router nicht mehr, da er kein gültiges Passwort mehr für die Kommunikation mit seinen Nachbar-Routern hatte.
Sogar Untersee-Kabelverbindungen fielen komplett aus
Am 12. Juli haben schließlich 15 von insgesamt 100 Routern bei Things Mobile das falsche Datum erhalten und sich vom Rest des Netzwerks isoliert. Auf diese Weise konnten 35 andere Router nicht erreicht werden. Nachdem etwa die Hälfte des gesamten Netzwerks "verloren gegangen" war, ging die inhärente Ausfallsicherheit und Redundanz des Netzwerkdesigns verloren, und das Netzwerk versagte, was zu den oben beschriebenen Konsequenzen für die Endbenutzerdienste führte.
Unter diesen betroffenen Routern trennten zwei Router sogar die unterseeischen Kabelverbindungen nach Großbritannien (London) und ein Router die Untersee-Kabelverbindung nach Frankreich (Paris).
Um den Service wiederherzustellen, mussten die Techniker des MNO-Partners die verschiedenen Standorte, an denen sich die Router befinden, persönlich besuchen. Sie mussten die Uhrzeit auf jedem betroffenen Router manuell ändern, um das falsche Datum zu ersetzen. Der letzte Router in Paris wurde am 13. Juli korrigiert.
Nachdem die Uhrzeit auf den isolierten Routern aktualisiert worden war, wurden die meisten Dienste wiederhergestellt. Es dauerte jedoch weitere 36 Stunden, bis alle international lokalisierten Geräte wieder verbunden waren. Dies kann durch die plötzliche Rückkehr der Konnektivität erklärt werden, die zu einem Aktivitätsschub auf den Plattformen der Roaming-Partner führt. Diese Plattformen waren technisch mit ihrer Kapazität zwar weitgehend überdimensioniert, jedoch nicht so dimensioniert, dass sie sich von einem vollständigen Ausfall erholen konnten. Einige der Telekommunikationspartner interpretierten diese Last-Spitzen auch als abnormales und verdächtiges Verhalten und stellten vorsorglich die Verbindungen zu dem MNO-Partner von Things Mobile automatisch ab.
Fazit: Things Mobile gelobt Besserung
Things mobile entschuldigt sich für die Auswirkungen dieses Ausfalls auf alle Kunden. Während die Ursache des Ausfalls eine Abfolge von Ereignissen war, die kaum vorhersehbar war, erkennt der Provider, dass man sowohl aus den Fehlern als auch aus den Erfolgen bei der Wiederherstellung der Situation viel lernen könne. Das Hauptaugenmerk liege eindeutig auf der Ausfallsicherheit und Zuverlässigkeit des Netzwerks.
Dies zeige sich darin, dass Things Mobile noch nie einen so großen Ausfall gehabt habe. Things Mobile werde die Anstrengungen verdoppeln, um sicherzustellen, dass ein solches Ereignis nie wieder auftritt. Things Mobile verspricht, auch alle Vorkommnisse zu dokumentieren und daraus lernen, wie man in Zukunft schneller reagiert, die Services schneller wiederherstellt und mit den Kunden bei zukünftigen Vorfällen besser kommuniziert.