Zusammenfassung

  • Nutzer können einen entfernten Dienst verlieren, obwohl die Leitungen funktionieren, wenn das einzige Routingprotokoll den Weg nicht darstellen kann.
  • Nach einem Ausfall können alte Routen den Verkehr in die falsche Richtung schicken. Die 16 begrenzte das Zählen, versprach aber keine sofortige Reparatur.

Ein Weg kann zu lang sein, um zu existieren

Man stelle sich eine Beschäftigte an einem Außenstandort vor, die das Bestellsystem aufrufen will. Überschreitet der Pfad die RIP-Metrikgrenze, kann das Gateway ihn nicht als nutzbar ankündigen; die Verbindung kann scheitern, obwohl die Leitungen intakt sind. Ein anderer Fehler entsteht, wenn ein Gateway ein Ziel zurückzieht und sein Nachbar weiterhin auf es zurückweist. Das sind erklärende Szenarien, keine belegten Einzelfälle von 1988. RFC 1058 beschreibt den Mechanismus, nicht einen benannten Ausfall.

Die Spezifikation von 1988 setzte dem bewusst früh eine Grenze. In RFC 1058 waren Metriken von 1 bis 15 nutzbar; 16 stand für unerreichbar. Sechzehn war keine buchstäblich unendliche Entfernung, sondern die Protokollgrenze zwischen einer Route, die es ankündigen durfte, und einer, die zurückgezogen werden musste.

Der Preis: RIP konnte keinen gültigen Weg darstellen, dessen Metrik über 15 lag. Hedricks Memo beschreibt ein Protokoll für Netze mittlerer Größe und hält fest, dass die Entwickler es bei einem Durchmesser von mehr als 15 für wenig praktikabel hielten. Zugleich bedeutete der niedrige Wert, dass veraltete Informationen weniger Schritte lang weitergezählt werden konnten.

Eine Grenze macht den Fehler endlich, nicht harmlos

RFC 1058 stellt die 16 nicht als vollständige Lösung dar. Das Memo behandelt das Zählen bis unendlich als Konvergenzproblem und erläutert Split Horizon, Poisoned Reverse und ausgelöste Updates. Doch auch diese Verfahren schlossen Rennen nicht aus: Ein ausgelöstes Update konnte zu spät kommen, sodass ein Rest der falschen Route weiterlief. Das Dokument räumt ein, dass das Zählen bis unendlich weiterhin möglich war.

Ein Fehler, der irgendwann endet, kann in der Zwischenzeit Schaden anrichten. Solange Gateways die Metrik erhöhen, können sie Pakete über einen falschen Weg schicken. Die 16 markiert, wann die Kontrollebene die Route nicht mehr als nutzbar behandelt. Sie belegt nicht, dass jedes vorher gesendete Paket einen funktionierenden Pfad nahm.

RFC 2453 behielt 16 auch für RIP Version 2 als Unendlichkeitswert bei und dokumentierte Grenzen und Schleifenverhalten. RFC 1812 führt RIP unter den historischen Routingprotokollen. Eine sauber dokumentierte Mechanik ist noch kein Entwurf für jede Topologie.

Die Netzgröße gehörte zum Entwurf

Sechzehn könnte wie eine beliebige alte Konstante wirken. Das Memo liefert eine bessere Erklärung: Der Unendlichkeitswert soll klein bleiben, damit sich das Zählen nach einem Ausfall nicht unnötig hinzieht, aber nicht so klein, dass gewöhnliche Wege ausgeschlossen werden. Die Wahl tauscht Netzdurchmesser gegen die Erholungszeit bei fehlerhaften Restinformationen.

Damit war der Wert eine Betriebsannahme und nicht bloß ein Feld im Paket. Wer RIP einsetzte, akzeptierte einen topologischen Rahmen. Wuchs das Netz darüber hinaus, machten auch andere Timer eine Route mit Metrik 16 nicht gültig. Die Grenze der Darstellbarkeit war erreicht.

Ein begrenzter Wert kann die Ausbreitung eines Fehlers eindämmen, indem er mögliche Zustände ausschließt. Wer trägt die Kosten: der Konvergenzmechanismus, der Betreiber, der umbauen muss, oder Nutzer, deren Pfad nicht mehr darstellbar ist? RIP legte diese Abwägung 1988 offen. Bei 16 hörte seine Karte auf zu behaupten, den Weg zu kennen.

Primärdokumente: RFC 1058; RFC 2453; RFC 1812.