Seite 4: Routing-Policies

Inhaltsverzeichnis

Router-Politik

Beim Routing selbst gelten in jedem AS eigene Regeln, die so genannten Routing-Policies. Entscheidungskriterien für die Wegewahl sind beispielsweise die Länge eines AS-Pfads oder unterschiedliche Nutzungspreise der Verbindungen. So kommt es oft vor, dass ein Paket einen längeren Weg durchs Internet zurücklegt als eigentlich nötig, weil der absendende Provider wegen der höheren Kosten eine teure Transit-Abkürzung meidet und stattdessen den Weg über ein Peering wählt.

Die aus den Routing-Strategien resultierenden Regeln bestimmen den Weg von IP-Paketen über mehrere Netze hinweg. Bei der gängigen Hot-Potato-Strategie ist der Provider darauf aus, den Durchgangsverkehr rasch wieder los zu werden, um die eigenen Ressourcen zu schonen. Er routet den Verkehr möglichst schnell zu anderen autonomen Systemen weiter, fasst ihn also wie eine heiße Kartoffel an.

Das Cold-Potato-Routing verfolgt den umgekehrten Ansatz. Hier möchte der Provider möglichst lange die Kontrolle über den Traffic behalten, um Quality-of-Service-Anforderungen gerecht werden zu können. Jeder Provider tariert seine Strategie zwischen Hot- und Cold-Potato-Prinzip individuell aus. Er bewegt sich dabei im Spannungsfeld zwischen Dienstgüte und Kosten.

Dieser Konflikt wird größer, je mehr die breite Masse Echtzeit-Anwendungen wie IP-Telefonie oder Video-Streaming nutzt. Allgemein gefasste Qualitätszusicherungen reichen da oft nicht mehr aus. Die Übermittlung nach dem Best-Effort-Prinzip, das heißt der Gleichbehandlung aller IP-Pakete, wird daher an Bedeutung verlieren. In Zukunft spielen neben der puren ausgetauschten Datenmenge auch Qualitätszusicherungen, etwa bezüglich Paketverlustrate, Verzögerung und Schwankungen (Jitter) eine größere Rolle.

Pannensicher

Der Blick hinter die Routing-Kulissen zeigt, dass das Internet gegen Ausfälle von Geräten oder ganzen autonomen Systemen gut gewappnet ist. Als Beispiel kann hier noch einmal der Eingangs erwähnte Teilausfall des deutschen Peering-Punkts DE-CIX dienen: Als am 17. Oktober 2005 einer von drei DE-CIX-Switches plötzlich den Dienst verweigerte, konnten viele der angeschlossenen autonomen Systeme ad hoc ohne manuellen Eingriff auf dieses Ereignisse reagieren. Die Auswirkungen der Panne waren kaum spürbar.

Neben der physischen Verbindung der autonomen Systeme bietet DE-CIX den Providern auch die Möglichkeit, die neu gewonnenen Routen bekanntzumachen. Dazu betreibt der DE-CIX-Eigner eco einen Routeserver. ISPs nutzen diesen, um Routen beim DE-CIX zu annoncieren und vom DE-CIX zu empfangen. Der Routeserver fungiert als eine Art Vermittlungsstelle, indem er die Routen eines Peer annimmt und an die anderen weitergibt.

Zum Zeitpunkt des Ausfalls waren an dem betroffenen Switch etwa 40 Provider ohne Redundanz-Port angeschlossen. Die Panne bewirkte zuerst einen Abbruch der BGP-Sessions zwischen den Border-Routern der Provider. Die Router konnten keine Nachrichten zum Aufrechterhalten der Verbindung mehr senden. Sie kappten, nachdem ihr Timer abgelaufen war, die Verbindungen und strichen die DE-CIX-Routen aus ihren Tabellen. Sodann suchten die Router in den betroffenen autonomen Systemen automatisch nach Alternativ-Routen. In dieser Situation machten sich vorherige Überlegungen der Netzplaner in Richtung möglichem DE-CIX-Ausfall und diesbezüglicher Redundanzen bezahlt. Viele Provider leiteten ihren Traffic binnen weniger Sekunden über ihre Anschlüsse am Amsterdamer AMS-IX oder am Londoner LINX um. Aber auch innerhalb Deutschlands standen regionale Internet-Austauschpunkte zur Verfügung. Der öffentliche Peering-Knoten INXS in München etwa verzeichnete sofort einen Durchsatzanstieg von etwa 2,8 auf rund 3,8 GBit/s.

Der Hoster und Provider Schlund beispielsweise verfügt über Ports an zwei der damals drei DE-CIX-Switches. Vom Zeitpunkt des Ausfalls dauerte es weniger als 90 Sekunden, bis die so genannte Rekonvergenz einsetzte, die Schlund-internen Nachbar-Router des vom Ausfall betroffenen Routers Alternativpfade vorschlugen. Als sich die vom Ausfall abgetrennten Gegenstellen zurückmeldeten, beendete das AS sein Alternativ-Routing automatisch.

Einige Provider, die neben dem öffentlichen DE-CIX-Peering hauptsächlich über Upstream-Transits verfügen, konnten den Ausfall nicht komplett über andere öffentliche Peerings ausgleichen. So kann eine länger andauernde Panne viel Geld kosten, nämlich dann, wenn sie beispielsweise auf Ausweich-Transitstrecken vereinbarte Datenvolumina kurzfristig überschreiten.