Zusammenfassung

  • RFC 1863 ordnete Server nach der Zahl ihrer informierten Clients; der kleinste Bestand bekam den kürzesten DelayTimer und war der wahrscheinlichste, nicht der garantierte Gewinner.
  • Ein Eintrag in der Liste informierter Clients war die Sendezuständigkeit eines Servers, keine Empfangsbestätigung und kein Beleg für Auswahl, Installation oder funktionierende Erreichbarkeit.
  • Der Client fing identische Duplikate auf, und die Übernahme musste innerhalb der Hold Time gelingen. RFC 4223 hielt später fest, dass Implementierungen dieses speziellen Entwurfs nicht existierten.

Das Ende der Wartezeit war erst eine neue Prüfung

RFC 1863 schlug 1995 BGP/IDRP Route Server vor, um die Sitzungszahl eines vollständigen Meshs zu verringern. Für Redundanz verband sich ein Client mit allen Servern seines Clusters, obwohl normalerweise nur einer Updates liefern sollte.

Jeder Server führte seine eigene Liste informierter Clients und Kopien der Listen seiner Partner. Geordnet wurde nach Clientzahl, bei Gleichstand nach Serveradresse. Tauchte ein neuer Client nirgends auf, wartete Server N (N-1) × DelayGranularity. Weniger Last bedeutete eine kürzere Frist.

Bei Ablauf wurden alle Listen erneut durchsucht. Hatte inzwischen ein anderer Server den Client eingetragen, blieb der Kandidat still. Andernfalls ergänzte er seine Liste, plante sofort eine LIST-Nachricht und begann zu senden. Der zweite Blick verkleinerte das Fenster veralteter Information, machte aus verzögerten Kopien aber kein atomares Register. Das Dokument räumte ein, dass die Abstimmung Rennen nicht vollständig beseitigte.

Eingesparte Sitzungen waren keine eingesparten Routen

Der Route Server leitete externe Routen samt Attributen weiter und traf für die Verteilung keine Bestwegwahl. Der Client wendete weiterhin seine lokale Richtlinie an. RFC 1863 nannte das virtuelle Peering und begrenzte seinen Nutzen ausdrücklich: Weniger Verbindungen bedeuteten nicht weniger Routinginformation pro Client.

Darum bleiben Empfang beim Server, Weiterleitung, Empfang beim Client, Auswahl, Installation und Datenpfad getrennt. Ein zentraler Relay verschiebt die Topologie, nicht das Ergebnis.

ADVERTISER bewahrte die Adresse des Grenzrouters, der die Route ursprünglich eingereicht hatte. Das lieferte Kontext für Clientpolitik, aber keine Authentisierung. Der Sicherheitsteil sagte, Sicherheitsfragen würden nicht behandelt. RCID_PATH diente zwischen Clustern der Schleifenerkennung und wurde vor gewöhnlichen Clients entfernt; auch dieses Attribut war kein universeller Herkunftsnachweis.

Informiert war eine Aussage des Senders

LIST wurde vom zuständigen Server erzeugt. Ein Clientname darin bestätigte weder ein bestimmtes UPDATE noch dessen Speicherung oder Auswahl.

Schon der Initiation-Zustand trennte Verbindung und Zuständigkeit. Der Server durfte Sitzungen annehmen und eingehende Routen verarbeiten, sendete aber keine Updates. Er wartete auf den vorgeschlagenen Fünf-Minuten-Timer oder auf alle konfigurierten internen Sitzungen und Listen. Eine lebende Session war noch keine Freigabe zur Verteilung.

Wenn zwei Server dennoch sendeten, lag die letzte Eindämmung beim Client. Eine von einem anderen Cluster-Server empfangene Route mit vollständig identischen Attributen sollte die vorige Kopie ersetzen, ohne neue Ankündigung auszulösen. Das vermied doppelte Speicherung und unnötige Flaps. Gleicher Präfix bei abweichenden Attributen fiel nicht darunter; die Regel entschied auch nichts über Wahrheit oder Qualität.

Nach einem Ausfall begann die Bewerbung erneut

Verlor ein Server die Sitzung zu einem Clusterpartner, betrachtete er dessen frühere Clients. Er durfte nur übernehmen, wenn seine direkte Client-Sitzung bestand und keine aktive Liste den Client bereits nannte. Danach folgten derselbe DelayTimer und dieselbe zweite Prüfung.

Es wurde kein Eigentumszeichen vom ausgefallenen Server übergeben. Der Überlebende rekonstruierte Verantwortung aus dem verbliebenen Zustand. Die alte Liste wurde erst nach Abstimmung verworfen.

Maximaler DelayTimer plus Hold Time zwischen Servern sollte kleiner sein als zwei Drittel der kleinsten clientseitigen Hold Time. Das Beispiel mit drei Servern kombinierte 90 Sekunden am Client, 30 Sekunden intern und 15 Sekunden DelayGranularity. Diese Rechnung reservierte Zeit für die Übergabe; sie bewies weder aktuelle Routen noch fortlaufenden Verkehr.

Historic bedeutete hier: kein laufender Entwurf

Der RFC-Editor-Eintrag führt RFC 1863 heute als Historic. RFC 4223 erklärte 2005, Implementierungen des dort definierten Route Servers existierten nicht und die Technik werde nicht als Full-Mesh-Alternative benutzt.

Andere Bedeutungen von Route Server schloss der Text ausdrücklich aus. Er nannte Route Reflection, BGP Confederations und private AS-Nummern als bestehende Alternativen. RFC 2796 und RFC 4456 beschreiben Reflectors mit Bestwegwahl und anderen Schleifenattributen; RFC 3065 beschreibt Confederations. Sie waren keine verdeckten Implementierungen von RFC 1863.

Nichtimplementierung widerlegt nicht jede Idee. Sie belegt jedoch, dass diese Timer und Übergaben keine Betriebserfahrung sammelten. Die Spezifikation beschrieb einen gewünschten Ablauf; Running Code hätte erst zeigen können, wie er Verlust, Partition und Uhren übersteht.

Das ehrliche Ende der Beweiskette

Eine Session belegte Kontrollverbindung. LIST belegte eine gegenwärtige Zuständigkeitsbehauptung. Der kurze Timer erhöhte die Chance des ersten Handelns. Die zweite Prüfung verringerte alte Entscheidungen. Identischer Ersatz dämpfte Duplikate. Hold Time gab der Wiederherstellung Raum.

Nützliche Erreichbarkeit brauchte weiterhin aktuelle Routen, korrekte Politik, Auswahl, Installation, Next-Hop-Auflösung und Datenpfadbeobachtung. Der bleibende Wert von RFC 1863 liegt darin, einen wahrscheinlichen Gewinner nie mit einer vollendeten Übernahme gleichzusetzen.

Quellen