Zusammenfassung

  • RFC 2443 ließ mehrere ATM-Multicast-Auflösungsserver den Zustand von Clients und Gruppen teilen, während jeder Client weiterhin nur bei einem Server registriert war.
  • Nach zwei ausgebliebenen Lebensmeldungen mussten die Peers alle von diesem Server gelernten Mitgliedschaften verwerfen. Der Client musste sich anschließend bei einem Ersatzserver anmelden und seinen Gruppen wieder beitreten.

Drei gleiche Einträge, eine stumme Quelle

Stellen wir uns drei MARS-Server vor, die dieselbe Zeile anzeigen: Ein Client gehört zu einer Multicast-Gruppe. Die gemeinsame Sicht wirkt intakt. Dann sendet der Server, der den Client zuerst registriert hat, keine regelmäßige Redirect-Aktualisierung mehr. Die beiden anderen besitzen weiterhin identische Einträge. RFC 2443 wertet diese Übereinstimmung jedoch nicht als Beleg dafür, dass die Quelle oder der an sie gebundene Client noch lebt. Bleiben zwei Aktualisierungen hintereinander aus, müssen die Peers die von diesem Server gelernten Mitgliedschaften löschen.

Genau diese Trennung prägte den Entwurf. RFC 2022 beschrieb MARS, den Multicast Address Resolution Server, als Dienst zur Verteilung von Layer-3-Multicast-Verbindungs- und Mitgliedschaftsinformationen über ATM. In einem verteilten MARS-System musste jeder Server eines Logical IP Subnet (LIS) Auskunft über jede Gruppe dieses LIS geben können. Die im November 1998 als Experimental RFC veröffentlichte RFC 2443 passte dafür das Server Cache Synchronization Protocol (SCSP) an.

Repliziert wurden Einträge, nicht die ursprüngliche Bindung

SCSP stellte den Rahmen bereit: Server bauen eine Beziehung auf, gleichen ihre Caches ab und verbreiten danach Änderungen. RFC 2443 setzte den Protokollbezeichner 0x0003 für MARS und definierte das LIS als Grenze der Servergruppe. Registrierte sich ein Client bei einem Server, verbreitete dieser die Registrierung und spätere Gruppenänderungen an seine Peers. Trotzdem registrierte sich jeder Client nur bei einem MARS-Server und hing über dessen Cluster Control Virtual Circuit oder Server Control Virtual Circuit an diesem Server. Die Kopien erweiterten die gemeinsame Sicht. Sie machten die ursprüngliche Kontrollbeziehung des Clients nicht zu mehreren unabhängigen Zuständigkeiten.

Auch die Vergabe eindeutiger Kennungen löste die Replikation nicht. Jeder MARS-Client brauchte im gesamten LIS eine eindeutige Cluster Member ID. RFC 2443 setzte dafür getrennte ID-Bereiche je Server voraus. Eine externe Vergabe war möglich, lag aber außerhalb des Dokuments. Datenbanken können eine kollidierende Vergabe konsistent kopieren; eine Instanz, die Einzigartigkeit garantiert, entsteht dadurch nicht.

Der Heartbeat machte veraltetes Wissen ungültig

Jeder Server musste seinen MARS Server Redirect Entry mindestens alle zwei Minuten erneuern; empfohlen war ein Abstand von einer Minute. Verpasste ein Peer zwei aufeinanderfolgende Aktualisierungen einer Quelle, musste er sämtliche von dort gelernten Client- und Gruppenmitgliedschaften löschen. Die Regel aktualisierte nicht bloß eine Liste von Ersatzservern. Sie band die Gültigkeit des Zustands an eine bestimmte Quelle und begrenzte die Löschung auf deren Herkunftsbereich.

Danach lag der nächste Schritt wieder beim Client. Erkannte er den Ausfall seines MARS-Servers, wählte er einen Ersatz und versuchte, sich dort zu registrieren. Erst nach erfolgreicher Registrierung trat er seinen früheren Gruppen erneut bei. Scheiterte der Versuch, probierte er den nächsten Server. Die Redirect Map nannte mögliche Ziele; sie bewies nicht, dass ein bestimmter Client umgezogen war, die Registrierung abgeschlossen, seine Mitgliedschaften zurückgewonnen oder den Multicast-Empfang wieder aufgenommen hatte.

Ein wiederhergestellter Mitgliedschaftseintrag belegte ebenso wenig, dass ein ATM-Punkt-zu-Mehrpunkt-Circuit aufgebaut war oder Pakete eine Anwendung erreichten. Das sind getrennte Betriebsschritte. In einem laufenden Netz ist ein replizierter Control-Plane-Eintrag eine Eingabe für eine Handlung, nicht deren Erfolgsquittung.

Authentifizierung begrenzte den Zugang, vergrößerte aber den Vertrauensradius

RFC 2443 verschlüsselte die MARS-spezifischen Felder des Cache-State-Datensatzes nicht. Stattdessen verwies sie auf Sicherheitsfunktionen im allgemeinen SCSP-Teil. Authentifizierung konnte nicht authentifizierte Pakete zurückweisen. Zugleich machte die RFC klar: Informationen eines ordnungsgemäß authentifizierten Servers wurden vertraut und in der Servergruppe weiterverbreitet. Wurde ein solcher Server kompromittiert, konnte er die gemeinsame Datenbank von seiner Quelle aus verfälschen. Authentifizierung schränkte ein, wer sprechen durfte; sie bewies weder die Wahrheit der Daten noch begrenzte sie den Schaden eines kompromittierten Peers.

RFC 3790 stellte 2004 fest, dass RFC 2443 IPv4-Standardwerte vorgab und mit passenden IANA-Definitionen auf IPv6 erweiterbar sei. Das dokumentiert eine Entwurfsabsicht, keinen Implementierungs- oder Einsatznachweis. RFCs belegen Anforderungen und Warnungen, nicht die Verbreitung eines Dienstes oder das Verhalten sämtlicher Implementierungen.

Die bleibende Lehre lautet daher nicht bloß: „Replikation erhöht Verfügbarkeit.“ Entscheidend ist, wer jeden Eintrag erzeugt hat, wann die Quelle zuletzt beobachtet wurde, welche Daten bei Ablauf dieses Nachweises ungültig werden und wer den nächsten Schritt ausführt. Registrierung, Wiederbeitritt zu Gruppen, Circuit-Aufbau, Paketweiterleitung und Anwendungsempfang müssen separat gemessen werden. Drei Caches können über die Vergangenheit übereinstimmen. Ob Multicast zurückgekehrt ist, zeigen nur ein aktiver Client und ein funktionierender Datenpfad.

Quellen