Mitte Februar kam es zu schweren Internetstörungen. Betroffen waren die großen Provider. Laut WDR gibt die Telekom ein Problem beim Software-Update als Ursache an. Zu solchen Fehlersituationen kommt es auch allzu oft in Unternehmen. Sich zurückzulehnen, mit dem Finger auf die Telekom zu zeigen und zu sagen: denen passiert das ja auch, ist die falsche Reaktion. Vielmehr sollte man sich überlegen, welche Lehren man für das eigene Vorgehen aus der Meldung ableiten kann.
Wie mein Kollege Dr. Moayeri bereits im November schrieb, beeinträchtigt der Ausfall eines Routers die Funktion der anderen nicht, oder zumindest nicht nachhaltig. Der Grund dafür ist die dezentrale Architektur, die bewusst fehlertolerant angelegt wurde. Jeder Router trifft seine eigenen Entscheidungen. Als Basis dienen die Informationen, die er selbst hat und die, die er von anderen Routern erfährt. Fällt ein Router aus, so kompensieren die verbliebenen diesen Ausfall, wenn möglich. Wesentlich dafür ist, dass alle Systeme über dieselben Informationen verfügen. Das ist ein ganz zentraler Aspekt bei der Entwicklung von Routing-Protokollen.
Problematisch wird es, wenn die Informationen der Router inkonsistent sind. Die Konsequenzen hängen dann vom Fehlerfall selbst ab: vom Routing-Loop eines einzelnen Subnetzes bis hin zum Totalausfall ist alles möglich.
Es gibt verschiedene Ursachen, die zu so einer Situation führen können. Drei typische Fälle sind:
- Konfiguration
- Unzureichende Hardware
- Fehlerhaftes Software-Update
Was kann man dagegen tun?
Ganz verhindern lassen sich Fehler nicht, aber es gibt eine Reihe von Maßnahmen, die man treffen kann:
- Fehlertolerante Architektur
Ob man mit zentralen Diensten oder mit einer verteilten Architektur wie beim Routing arbeitet: Redundanzen sind wichtig. Wenn es nur eine Leitung zwischen zwei Standorten gibt, kann kein Routing-Protokoll den Ausfall der Leitung kompensieren. Das gilt auch für Controller, Switches und Router.
Wichtig ist auch, diese Redundanz zu testen, oder wie Dr. Wetzlar es mal formuliert hat: „Redundanz ist keine Versicherung“. - Bewährte Standards
Wie bereits im Artikel von Dr. Moayeri erläutert, haben sich für das Internet und internetnahe Dienste verteilte Architekturen über Jahrzehnte hinweg bewährt. Diese Verfahren sind somit erprobt und die Software ist ausgereift.
Ohne zwingenden Grund sollte man von diesen Standards nicht abweichen und Protokolle oder Verfahren einführen, nur weil sie neu sind. - 4-Augen-Prinzip
Konfigurationsfehler sind menschlich. Jeder, der beispielsweise eine IPv6–Adresse manuell eingetragen hat, weiß das. Das 4-Augen-Prinzip ist keine Schwäche, sondern eine Stärke eines Mitarbeiters und sollte bei kritischen Änderungen unbedingt eingehalten werden. - Tests
Keine Software ist fehlerfrei. Vor dem Update kritischer Systeme sollte man sich somit fragen, ob das Update notwendig ist und wenn ja, muss es sorgfältig getestet werden. Bei verteilten Systemen, zu denen Netzwerkkomponenten gehören, reicht es nicht, die Software isoliert auf einem System zu testen. Vielmehr müssen die Tests sorgfältig geplant werden. Dabei ist immer auch das eigene Design zu beachten: Muss auch die Interoperabilität zwischen Herstellern getestet werden? Kann Last zu einem Problem werden? Gibt es Systeme, die man nicht mehr updaten kann?
Was für die Software gilt, gilt natürlich auch für neue Hardware und Konfigurationsänderungen.
