Am vergangenen Dienstag, 12. August 2014 erhielten wir ab ca. 10.00 Uhr Meldungen von Kunden, dass bei uns gehostete Dienstleistungen nicht mehr verfügbar gewesen seien. Das Monitoring unserer Server und Services zeigte hingegen keine Ausfälle und auch unser externer Überwachungsservice schlug nicht an. Ausserdem erfuhren wir durch Kunden, die sich über Social Media meldeten, dass unsere Dienste lediglich über einzelne Zugangsanbieter nicht erreichbar waren.

Diese Ausgangslage nährte den Verdacht, dass es sich um ein externes Routing-Problem handelte. Wir trafen umgehend entsprechende Abklärungen und zogen unsere IP-Transit-Partner bei. Diese Art Probleme sind meist sehr aufwändig nachzuvollziehen, da immer mehrere Netzwerke und entsprechend mehrere Parteien involviert sind. Nach diversen weitergehenden Untersuchungen zeigte sich dann aber, dass die Ursache des Problems nicht hier zu suchen war.

Wir konzentrierten uns deshalb als nächstes auf die Router, welche unsere Infrastruktur mit der Aussenwelt verbinden. Diese führen Routing-Tabellen, um zu wissen, über welches an uns angebunden Netz sie einen bestimmten Adressaten am schnellsten erreichen. Schon zu Beginn der Probleme hatten wir überprüft, ob Einträge in den Routing-Tabellen fehlerhaft waren, oder gar fehlten, was nicht der Fall war. Auch bei genauerem Hinsehen war alles in Ordnung und die Router hätten sich dementsprechend korrekt verhalten müssen.

Als dann erste Hinweise auf aktuelle Probleme anderer grosser Internet-Provider weltweit auftauchten, die scheinbar von einem plötzlichen, übermässigen Anstieg der Einträge in der Internet-Routing-Tabelle ausgelöst wurden, überprüften wir auch dies. Unsere BGP-Sessions konnten aber nicht von diesem Anstieg betroffen sein, da unsere Router über mehr als genug RAM verfügen. Weil die Router aber unabhängig von BGP eine künstliche Limite für hardware-basiertes Routing von 512’000 Einträgen definiert haben, entschieden wir an dieser Stelle noch etwas genauer zu forschen, obwohl diese schon wieder nicht mehr überschritten war. Stichproben von betroffenen IP-Adressen zeigten dann aber, dass diese in den Hardware-Tabellen (TCAM) vorhanden waren. Diese Feststellung und die Tatsache, dass wir Reboots solch kritischer Komponenten während des Tages generell nur in Ausnahmefällen durchführen, hat uns vorerst davon abgehalten, die Router neu zu starten

Nach weiteren Abklärungen zeigte sich dann aber, dass das Überlaufen der Hardware-Tabellen trotz erfolgreicher Stichproben die Ursache für die Probleme war. Als wir daraufhin die Reboots durchführten, funktionierte alles wieder normal. Wir gehen schlussendlich davon aus, dass die Überschreitung der Limite dazu geführt hat, dass sehr kritische Routen, die wir bei unseren Stichproben leider nicht sofort entdeckt hatten, verloren gingen. Zudem wurden diese Routen durch Neustarts der BGP-Sessions auch nicht ersetzt, nachdem die Limite wieder unterschritten war.

Eingeleitete Massnahmen
Die Vorkommnisse haben uns zu diversen Massnahmen im technischen Bereich bewogen:

  • Die Limite für hardware-basiertes Routing wurde auf 800’000 Einträge erhöht. Dies senkt die Wahrscheinlichkeit entscheidend, dass dieser Zustand erneut ausgelöst werden kann.
  • Das Monitoring der Router wird weiter ausgebaut, um solche Anomalien in Zukunft schneller feststellen zu können.
  • Zudem versuchen wir abzuklären, warum das Fehlverhalten nur durch einen Reboot behoben werden konnte, obwohl die Limite schon wieder unterschritten war.

Für die entstandenen Unannehmlichkeiten möchten wir uns in aller Form entschuldigen. Wir nehmen dieses Ereignis sehr ernst und versichern, dass wir alles daran setzen, unsere Dienstleistungen weiterhin in hoher Qualität anbieten zu können – wie man das von uns gewohnt ist und auch weiterhin erwarten darf.

Hintergründe zur Netzwerkstörung vom 12. August 2014

Markus Gebert

Markus Gebert ist Co-Founder & CEO von Hostpoint.

0