Protokoll eines Ausfalls

Dienstagabend, 20 Uhr. Unsere Kolleginnen und Kollegen bei der Technik und im Kundenservice stellen sich auf einen ruhigen Abend ein. Das Anrufvolumen bewegt sich im überschaubaren Rahmen und das Monitoring meldet keine besonderen Auffälligkeiten. Alles im grünen Bereich also.

Zwischen ca. 20:30 und 21 Uhr. Erste Anrufer berichten darüber, dass ihre bei uns gehostete Webseiten nicht mehr erreichbar sind. Die ersten Überprüfungen können dies nicht bestätigen: Alle genannten Domainnamen funktionieren aus unserer Sicht und sowohl bei den Servern als auch im Netzwerk sind keine Störungen verzeichnet. Dennoch wird die Technik informiert, damit diese den Meldungen nachgehen kann.

Gegen 21 Uhr: Die Lage spitzt sich zu. Die Anzahl der Anrufer, die einen Ausfall melden, steigt drastisch an. Es kommt zu spürbaren Wartezeiten. Auch in unserem Kundenforum, auf unserer Facebook-Seite und bei Twitter häufen sich die Mitteilungen über ein Problem. Unsere Mitarbeiter nehmen sowohl im technischen Bereich als auch im Kundenservice eine vorsorgliche Notfall-Eskalation vor und informieren u.a. Vorgesetzte, damit diese unterstützend eingreifen und Verstärkung für z.B. die Telefonhotline organisieren können. Ob Feierabend oder nicht ist jetzt keine Frage: Es gibt ein Problem und das muss gelöst werden. Auch die Geschäftsleitung ist aktiv, um die weitere Entwicklung aktiv begleiten zu können.

Kurz nach 21 Uhr: Das anfangs unklare Problem zeichnet sich inzwischen deutlicher ab. Offensichtlich gibt es Routingschwierigkeiten, die einen Teil des Datenverkehrs aus dem Netz der DTAG betreffen. Wir schreiben einen ersten Statusseiteneintrag und geben die Mitteilung auch über unsere Social-Media Kanäle weiter. Alle Beteiligten arbeiten mit Hochtouren an einer Lösung und der Beantwortung aller Kundenanfragen. Das Ziel: Den Datenverkehr so umleiten, dass er wieder normal „fließen“ kann.

21:11 Uhr: Die Beeinträchtigung konnte durch eine vorgenommene Routingänderung im Netzwerk umgangen und somit die vollständige Erreichbarkeit aller Dienste für alle Nutzer wiederhergestellt werden. Der betroffene Datenverkehr wird über andere Netzverbindungen von uns geleitet und die „Unfallstelle“ somit umgangen. Parallel laufen weitere Analysen, zudem stehen wir mit dem betroffenen Uplinkprovider in Kontakt. Die Stautsseite wird erneut aktualisiert und auch auf Twitter, Facebook und im Forum sind wir weiterhin parallel dazu aktiv. Die Stimmung ist weiterhin angespannt.

21:30 Uhr: Der betroffene Uplinkprovider in München hat uns das in seinem Einflussbereich liegende Problem bestätigt. Die getroffene Einschätzung war also richtig und die Änderung unseres Routings die passende Entscheidung. Wir leiten den Datenverkehr daher auch weiterhin über andere Uplinks und können den um 21:11 Uhr wieder hergestellten reibungslosen Betrieb stabil aufrecht erhalten. Weitere Stellungnahmen auf der Statusseite, im Forum, bei Facebook und auf Twitter runden die Kundenkommunikation bis etwa 21:45 Uhr ab. Die Lage hat sich inzwischen, auch an der Hotline, wieder normalisiert. Wir heben daher die Alarmierung der zusätzlichen Personen auf; die Technik behält jedoch ein besonderes Augenmerk darauf, ob es erneut zu einem Problem kommt.

Mittwoch, 6 Uhr: Das alternative Routing hat gehalten und weitere für Kunden spürbare Einschränkungen sind nicht aufgetreten. Die Nacht ist im normalen Rahmen verlaufen. Wir sind erleichtert.

9 Uhr: Die in der Nacht noch eingetroffene Stellungnahme des betroffenen Uplink-Providers und das abschließende Ergebnis der internen Analyse liegen vor und werden besprochen. Aus den vorliegenden Informationen ergibt sich nun ein vollständiges Bild zu der Frage, weshalb das Problem aufgetreten und für uns anfangs überhaupt nicht eindeutig nachvollziehbar gewesen ist. Konkret kam es bei einem von uns genutzten Uplink, über den wir den DTAG-Datenverkehr abgewickelt haben, zu einem teilweisen Ausfall im Backbone. Dieser hat nicht zu einem vollständigen Ausfall des Standorts geführt, sondern nur bestimmte Absender- und Empfänger-IP-Adressen betroffen. Datenpakete, die über den „kaputten Teil“ des Datenkanals gesendet worden sind, haben ihr Ziel erreicht. Die anderen gingen „verloren“.

Aus diesem Grund konnten wir intern die Situation nicht so einfach reproduzieren sondern statt dessen sogar die für die betroffenen Kunden ausgefallenen Dienste ganz normal erreichen. Auch die automatische Routingänderung mittels BGP-Protokoll  hat daher nicht funktioniert, da der Backbone des betroffenen Uplinks eben nur zum Teil gestört gewesen ist und alle BGP-Verbindungen intakt geblieben sind. Unser Netzwerk hat daher weiterhin Daten mit dem Uplink ausgetauscht, ohne erkennen zu können, dass er für einen Teil der Internetnutzer nicht mehr funktioniert.

Inzwischen wurde der Defekt dort natürlich bereits behoben und die Verbindung wieder aktiviert. Insgesamt lässt sich festhalten, dass in der Spitze etwa 15% des während des Ausfalls regulär anfallenden Datenverkehrs von dem Problem betroffen worden ist. Dies ist – obwohl sich der Ausfall vollständig außerhalb unseres Einflussbereichs abgespielt hat – ohne jede Frage unerfreulich für die betroffenen Kunden und wir hoffen, den Ärger durch die schnellstmögliche Reaktion und zeitnahe Fehlerbehebung zumindest ein wenig reduziert zu haben.

Hier noch einige Screenshots zur ergänzenden Dokumenation:

End of article

Sara Marburg

Über den Autor

Sara Marburg

Geschäftsführung (bis 11/13)

12 Kommentare

Bitte füllen Sie das Captcha aus : *

Reload Image

Die von Ihnen hier erhobenen Daten werden von der domainfactory GmbH zur Veröffentlichung Ihres Beitrags in diesem Blog verarbeitet. Weitere Informationen entnehmen Sie bitte folgendem Link: www.df.eu/datenschutz


  • olto78
    olto78 - 7. September 2011 um 14:06 Uhr

    Hallo df-Team,

    wieder mal ein hervorragend transparenter und offenen Umgang
    mit den täglichen Widrigkeiten des (Techniker-)Alltags.

    Ich als Kunde kann wieder einmal sagen:
    Danke und weiter so!

    Grüße, Oliver

  • Peter
    Peter - 7. September 2011 um 14:19 Uhr

    Danke für die rasche Reaktion gestern Abend und vor allem die vorbildliche Kommunikation!

  • maRio
    maRio - 7. September 2011 um 14:35 Uhr

    Das waren gestern nicht die einzigen Probleme. Auch unsere Server nähe Nürnberg waren schwer zu erreichen und hatten hohen Packetloss. 15.20 Uhr hatten die Probleme angefangen. Schnell bekamen wir folgende Meldung „hiermit möchten wir Sie über eine Störung unseres Leitungsabschnittes zwischen
    Dürrengleina und Saaletal/Jena informieren. Bei Baggerarbeiten wurde ein Glasfaserkabel durchtrennt. Das LWL-Bereitschaftsteam ist bereits auf dem Weg. Sobald wir neue Erkenntnisse über den Fortlauf der Störungsbeseitigung haben, werden wir Sie unverzüglich darüber informieren.“ Das ist eine der Hauptleitungen der Backboneconnection Frankfurt/Main. Erst um 23.30 Uhr konnten durch die massive Zerstörung die Leitungen wieder in Betrieb genommen werden.

  • Michael
    Michael - 7. September 2011 um 14:44 Uhr

    Wir hatten vor einem Monat innerhalb von 7 Tagen gleich 2 Netzausfälle. War allerdings bei Colt.
    Als deren Hotlinemitarbeiter überzeugt war, dass es nicht an uns liegt, dauerte es ca. 4 Stunden, bis wir wieder am Netz waren. Auch wenn wir nichts hosten, ist die IT-Abteilung für andere Abteilungen immer die Schuldige, wenn’s um Störungen geht.
    Später, nach der 2ten Störung kam dann raus, dass die ein Hardwareteil in irgendeiner Schaltzentrale erst nach dem 2ten Ausfall ausgetauscht hatten und seit dem läuft’s.

  • Peter
    Peter - 7. September 2011 um 14:50 Uhr

    @maRio der Anbieter von dem du da redest hat aber auch einen etwas anderen (qualitativen) Anspruch als df ;-). Da wurde ziemlich offensichtlich die nötige Bandbreite nicht redundant vorgehalten, ansonsten hätte es nur höhere Latenzen aber keinen Packetloss verursacht. Domainfactory hat – zumindest würde ich es so einschätzen – durchaus die Möglichkeit beim Ausfall einzelner Leitungen noch ohne Beeinträchtigung erreichbar zu sein.
    Ein Fehler wie oben beschrieben ist aber für Kunden (in dem Fall DF) eher schwer zu bemerken. Imho hätte der andere Provider es vorher merken müssen und die BGP Session (mit Multihomed-Kunden) vorsorglich trennen sollen.

  • Yannick
    Yannick - 7. September 2011 um 15:19 Uhr

    Ich hatte auch Probleme über das Eplus Mobilfunknetz.
    Es waren also nicht nur Telekom Kunden betroffen.

  • Sara
    Sara - 7. September 2011 um 15:54 Uhr

    @Yannick: Interessante Information. Laut den uns bekannten Aussagen sollten nur (einige, nicht alle) DTAG-Kunden betroffen gewesen sein. Ob es da andere Wechselwirkungen gab, ist uns leider nicht bekannt.

  • demoreseller
    demoreseller - 7. September 2011 um 19:15 Uhr

    Warum gibt es denn keine direkte Anbindung zum rosa T ?

  • Roman
    Roman - 8. September 2011 um 21:35 Uhr

    Interessant. Nur scheint das Problem wieder aufgetreten zu sein…
    http://www.handy-faq.de kann ich seit heute Vormittags nicht mehr erreichen – nicht aus dem Büro (über M-Net) und nicht von Zuhause (T-Online).

  • Dietmar Leher
    Dietmar Leher - 9. September 2011 um 09:37 Uhr

    @Roman, Sie können sich gerne über Ihr Kundenmenü direkt an unsere Technikabteilung zur Klärung wenden.

  • Nils Dornblut
    Nils Dornblut - 9. September 2011 um 09:41 Uhr

    @Romam: Die Domain geht auf einen externen Server bei einem anderen Provider. Dort scheint etwas nicht zu stimmen.Bei dF liegt das Problem nicht.