RFC 2174: Der Eintrag war gültig, der Ausgang blieb gesperrt

Zusammenfassung

• RFC 2174 verband Distance-Vector-Unicast-Routing mit genau einem, vom Virtual Source Switch aus berechneten Baum für Broadcast und Multicast.
• MAPOS-Frames besaßen weder Quelladresse noch TTL; eine vorübergehende Schleife konnte daher weder den wirklichen Ursprung prüfen noch durch Ablauf des Frames enden.
• Route, VSS, Metrik unter 16 und gesetztes Port-Bit waren lokale Steuerzustände, keine Belege für sichere Freigabe oder erfolgreiche Zustellung.

Der Port war bekannt und trotzdem geschlossen

SSP verschickte standardmäßig alle zehn Sekunden eine vollständige Routingtabelle an jeden benachbarten Switch. Der Empfänger addierte die Linkkosten, meist eins, verglich die Metriken und übernahm bei einem besseren Weg den eingehenden Port als Next Hop. Fiel ein lokaler Port aus oder verschlechterte sich eine Route, konnte ein Triggered Update sofort folgen.

Für Broadcast galt eine zusätzliche Bedingung. Erkannte ein Switch hinter einem Port einen neuen Downstream, startete er den FORWARD_DELAY_TIMER. Standardwert waren dreißig Sekunden, drei vollständige Update-Perioden. Die Beziehung durfte intern bereits sichtbar sein; Broadcast- und Multicast-Frames blieben auf diesem Port dennoch verboten.

Die Verzögerung kompensierte zwei Grenzen des Frameformats. MAPOS führte keine Quelladresse. Ein Switch konnte deshalb den realen Sender nicht als Wurzel einer üblichen Reverse-Path-Prüfung verwenden. Es gab auch keine TTL. Wären zwei vorübergehend unterschiedliche Bäume zu einer Schleife verbunden worden, hätte der Frame keinen eigenen Ablaufzähler besessen.

SSP wartete also nicht, weil der Weg unbekannt war. Es wartete, weil ein bekannter Weg noch in einer unstabilen gemeinsamen Sicht lag.

Eine virtuelle Quelle ordnete alle Kopien

Virtual Reverse Path Broadcast setzte einen künstlichen Ursprung. Sämtliche Broadcast- und Multicast-Frames galten rechnerisch als unter einem VSS erzeugt. Dieses Virtual Source Switch war der erreichbare Switch mit der kleinsten Nummer.

Jeder Switch suchte die Nummer in seiner eigenen Unicast-Tabelle und bestimmte den kürzesten Rückweg. Nicht-Wurzeln hatten einen Upstream-Port und konnten mehrere Downstream-Ports besitzen. Das VSS hatte keinen Upstream. Im gesamten Segment bestand jeweils nur ein Baum.

Die Regel war keine globale Wahltransaktion. Gleiche Logik bedeutete nicht gleiche Eingabedaten zum gleichen Zeitpunkt. Während einer Topologieänderung konnte ein Gerät das neue VSS bereits sehen, während ein anderes noch mit dem alten Weg arbeitete. Die ausgewählte Nummer war eine lokale Schlussfolgerung, kein Konsensbeleg.

Darum machte ein neues oder unerreichbares VSS die gesamte Broadcast-Tabelle ungültig. Ein einzelner Downstream-Wechsel wirkte enger und musste andere Äste nicht berühren. RFC 2174 unterschied die Tragweite der Zustandsänderung.

Ein gesetztes Bit war noch keine Beobachtung

Die Broadcast-Tabelle war ein Bitmap. Jedes Bit stand für einen Port. Eins bedeutete: über diesen Port zu einem lokalen Knoten oder einem Upstream- beziehungsweise Downstream-Switch weiterleiten. Ohne markiertes Bit wurde der Frame still verworfen.

Das Bitmap beschrieb einen Plan. Es berichtete nicht, ob das Signal gesendet wurde, der Nachbar den Frame erhielt, denselben Baum benutzte oder ein Endknoten die Nutzlast annahm. Während des Forward Delay war sogar die Beziehung bekannt, ohne dass das Bit schon eine aktuelle Sendeerlaubnis darstellte.

Mehrere Beobachtungsarten speisten die Tabelle. Eine NSP-Adressanfrage zeigte einen lokalen Knoten. Der Next Hop zum VSS bestimmte den Upstream. Ein über einen Port empfangenes Poisoned Reverse ließ darauf schließen, dass der dahinterliegende Switch diesen Weg zur Wurzel nutzte und damit Downstream war.

Beim neuen Downstream begann die Aktivierungsverzögerung. Danach überwachte ein ebenfalls dreißig Sekunden langer PORT_EXPIRATION_TIMER die fortgesetzten Poisoned-Reverse-Updates. Blieben sie aus, wurde das Bit gelöscht. Kam stattdessen ein gewöhnliches Update vom bisherigen Downstream, musste das Bit sofort verschwinden: Der Nachbar hatte einen anderen besten Weg oder ein anderes VSS gewählt.

Ein einzelnes Bit durchlief damit Kandidatur, Wartephase, Aktivität, Auffrischung, Ungültigkeit und Löschung. Wer nur den Endwert speichert, verliert die Begründung.

Eine tote Route blieb noch dreißig Sekunden sichtbar

Erhielt der Switch drei volle Perioden lang kein Refresh, oder meldete der aktuelle Nachbar Metrik 16, wurde die Route unerreichbar. Sie blieb anschließend noch dreißig Sekunden erhalten, damit 16 weiterverteilt werden konnte. Erst dann löschte die Garbage Collection den Eintrag.

RFC 1058 hatte den Hintergrund beschrieben: Distance-Vector-Protokolle können veraltete Annahmen bewahren und bis unendlich zählen. Die operative Unendlichkeit 16, Split Horizon mit Poisoned Reverse und Triggered Updates begrenzen bestimmte Verläufe. Sie schaffen keinen atomaren Abschluss. Eine schnelle schlechte Nachricht kann sich mit einer regelmäßigen alten Nachricht kreuzen.

Die vier Uhren trafen deshalb verschiedene Aussagen. Route Expiration entzog einer alten Annahme die Nutzbarkeit. Garbage Collection hielt die tote Annahme lange genug für ihre Bekanntmachung. Forward Delay hielt eine neue Beziehung von der Nutzung zurück. Port Expiration entzog einem Downstream die Gültigkeit, wenn sein periodischer Beleg ausblieb.

Ein Blackhole konnte weiterhin zuhören

RFC 2174 nennt das Half-Way-Connection-Problem. Der Empfangskanal konnte funktionieren, obwohl der Sendekanal ausgefallen war. Der Switch hörte SSP-Updates und hielt seine Tabelle frisch, während eigene Daten in einem Blackhole verschwanden.

SONET/SDH-Overhead konnte in manchen Fällen den Zustand des Sendekanals aus Sicht der Gegenstelle zurückmelden. Manche Dienste boten die nötige Transparenz aber nicht. Der Eingang eines Routingupdates war daher ein Richtungsbeleg, keine Bestätigung eines bidirektionalen Datenpfads.

Das Dokument war Informational, kein IETF-Working-Group-Ergebnis und nicht Standards Track. Es nahm wenige Switches an und lieferte keine Verbreitungszahlen, Messungen der Konvergenz, Interoperabilitätsraten oder realen Schleifenfälle. Sicherheitsfragen wurden nicht behandelt.

Sein historischer Beitrag ist die erkennbare Grenze: Route lernen, Wurzel auswählen, Wartezeit beenden, Port öffnen und Frame zustellen waren getrennte Tatsachen. Ein korrekter Eintrag durfte vorhanden sein, während korrektes Verhalten weiterhin Nicht-Senden bedeutete.

Quellen

1. RFC 1058 — Routing Information Protocol
2. RFC 2171 — MAPOS Version 1
3. RFC 2173 — Node Switch Protocol
4. RFC 2174 — Switch-Switch Protocol
5. RFC 2176 — IPv4 over MAPOS Version 1