Zusammenfassung

  • Anycast-RPs können dieselbe Dienstadresse anbieten und über MSDP aktive Quellen austauschen. Jede SA muss dennoch eine individuelle RP-Adresse tragen, damit ihre Kontrollprovenienz für peer-RPF auflösbar bleibt.
  • Erreichbarkeit der Anycast-Adresse zeigt, dass ein RP antwortet. Sie zeigt nicht, ob alle RPs denselben SA-Cache besitzen, ein Failover alle Join-Zustände bewahrt oder Empfänger weiterhin Daten erhalten.

Die gemeinsame Adresse verbarg individuelle Erinnerung

Ein Monitoring-System prüft die Anycast-RP-Adresse und erhält ohne Unterbrechung eine Antwort. Gleichzeitig wechselt die unicastbasierte Auswahl von RP A zu RP B. A hatte soeben einen neuen (S,G)-Eintrag gelernt; B hat die zugehörige SA noch nicht im Cache. Die Oberfläche meldet Verfügbarkeit. Der nächste Empfänger trifft auf eine andere Quellenansicht.

RFC 3618 wurde im Oktober 2003 als Experimental veröffentlicht. Es beschreibt MSDP, das Informationen über aktive IPv4-Multicastquellen zwischen PIM-SM-Domänen verbreitet. Ein RP, der einen neuen Sender kennenlernt, bildet eine Source-Active-Nachricht aus Source-, Group- und RP-Adresse. Andere RPs können daraus bei lokalem Interesse einen (S,G)-Join ableiten.

RFC 3446 setzt diesen Mechanismus innerhalb einer Domäne für Anycast RP ein. Mehrere RPs tragen dieselbe Anycast-Adresse, verteilen Register-Last und verkürzen den Ausfall eines einzelnen Knotens. MSDP soll die Quellenkenntnis zwischen ihnen teilen.

Die gemeinsame Adresse ist ein Einstiegspunkt. Der Cache bleibt eine Sammlung individueller Beobachtungen.

Die SA brauchte eine einzelne Herkunft

Eine zentrale Anforderung von RFC 3446 wirkt zunächst paradox: Die Anycast-Adresse darf nicht als RP-Adresse in einer SA verwendet werden. Stattdessen braucht jeder RP eine eigene Adresse für MSDP und die Source-Active-Provenienz.

Der Grund ist peer-RPF. Ein Empfänger vergleicht die in der SA getragene RP-Adresse mit dem Peer, von dem die Nachricht kam, und mit der Route zum originierenden RP. Bei einer gemeinsamen Adresse könnte die Route zum nächstgelegenen Anycast-Knoten statt zum tatsächlichen Ursprung führen. Die Prüfung würde scheitern oder die Herkunft verwischen.

Der Dienstname darf also gemeinsam sein, der Kontrollzeuge nicht. Das ist eine allgemeine Evidenzregel: Hochverfügbarkeit kann die Adresse abstrahieren, doch jede Zustandsänderung braucht eine konkrete Instanz, Zeit und Sitzung.

Ein Bericht sollte deshalb nicht nur anycast-rp=up enthalten. Er muss zeigen, welcher RP die SA originierte, über welchen Peer sie kam, welche Route peer-RPF verwendete, wann jeder Cache sie übernahm und welche Instanz nach dem Failover Empfänger bediente.

Synchronisation war periodisch, nicht atomar

MSDP verlangt, SA-Nachrichten zu cachen. Originierende RPs senden aktive Quellen periodisch im 60-Sekunden-Rhythmus. Beim Aufbau einer Verbindung soll eine Implementierung gecachte SAs versenden. Diese Regeln fördern Konvergenz, definieren aber keine atomare Replikation.

Zwischen der lokalen Beobachtung bei A und der Übernahme bei B existiert ein Fenster. Eine Sitzung kann genau in diesem Fenster ausfallen. Filter, Zustandsgrenzen oder eine andere peer-RPF-Entscheidung können die Nachricht auf einer Instanz zulassen und auf einer anderen verwerfen. Der SA-State-Timer kann zu unterschiedlichen Zeiten erneuert werden.

Die Caches dürfen daher nicht allein anhand der Eintragszahl verglichen werden. Benötigt werden (S,G,R)-Mengen, Ursprung, erstes und letztes Beobachtungsereignis, Empfangszeit, Cache-Epoche und Ableitungen in PIM. Zwei RPs mit gleich vielen Einträgen können völlig andere Quellen kennen.

Auch ein nach dem Verbindungsaufbau empfangenes SA ist möglicherweise Cache-Replay und keine neue Source-Beobachtung. Ein frischer Empfangszeitstempel darf nicht die historische Provenienz überschreiben.

Failover erhielt die Adresse, nicht automatisch den Baum

Wenn ein DR Register an die Anycast-Adresse sendet, erreicht es den nach Routing nächstgelegenen RP. Ein anderer RP kann über MSDP vom Sender erfahren. Bei einem Wechsel muss der neue RP aber nicht nur den Namen kennen. Er braucht den passenden PIM-Kontext, muss lokale Empfängerinteressen berücksichtigen, (S,G)-Joins auslösen und einen Datenpfad aufbauen.

Die Folge kann ein kurzer oder langer Dienstbruch sein, obwohl die Anycast-Adresse stets erreichbar war. Umgekehrt kann ein Empfänger bereits auf einem Source Tree liegen, während der lokale SA-Cache gerade konvergiert. Kontrollzustand und Datenzustand bewegen sich nicht als eine Transaktion.

Ein belastbarer Failover-Test beobachtet daher Register oder erste Daten beim Quell-RP, SA-Ausbreitung, Cache-Übernahme, Join-Erzeugung, installierte Zweige, Paketfolge am Blatt und Applikation. Der Test muss auch den Rückweg prüfen: Werden alte Einträge und Zweige nach Ende der Quelle zuverlässig entfernt?

Optional in einer SA gekapselte Daten können eine kurze Lücke überbrücken. Ein solcher erster Burst ist kein Nachweis, dass der normale Baum dauerhaft folgte.

Das Mesh setzte vollständige Verbindungen voraus

Anycast-RPs werden häufig in einem MSDP mesh-group verbunden. Innerhalb der Gruppe wird eine SA nicht an andere Mitglieder weitergereicht, wenn sie von einem Mitglied kam; der Originator soll bereits an alle gesendet haben. Das spart Redundanz, verlangt aber einen vollständigen Mesh.

Fehlt eine Kante, kann B den Eintrag von A besitzen, während C ihn nicht kennt. B hält sich korrekt an die Unterdrückungsregel und repariert die Lücke nicht. Die gemeinsame Anycast-Adresse macht diese Asymmetrie von außen besonders schwer sichtbar.

Die Kontrollprüfung muss daher jede erwartete Peer-Kante, beide Konfigurationsseiten, Quelladressen, Authentifizierung und Cache-Differenzen erfassen. Der Name der mesh-group ist keine Topologieprüfung.

Ändert sich die Mitgliedschaft, sollte eine neue Epoche beginnen. So lässt sich unterscheiden, ob ein Cache-Eintrag unter dem alten oder neuen vollständigen Mesh empfangen wurde. Ohne Epoche kann ein alter Eintrag wie Beweis für eine neue Redundanzkonfiguration aussehen.

Authentische Replikation konnte authentisch falsch sein

RFC 3618 verlangt Unterstützung für TCP MD5 zum Schutz der Kontrollverbindung. Eine authentifizierte Sitzung macht die Peer-Beziehung belastbarer gegen fremde Einspeisung. Sie beweist aber nicht, dass der sendende RP eine Quelle richtig beobachtet, der Source-Adresse vertraut werden darf oder die Werbung autorisiert ist.

Im Anycast-Verbund ist gerade die authentische Fehlkonfiguration gefährlich: Alle RPs können dieselbe zu breite Policy übernehmen und konsistent falschen Zustand verteilen. Vollständige Synchronität ist kein Qualitätsurteil über den synchronisierten Inhalt.

SA-Filter und Limits begrenzen Quellen, Gruppen und Zustandswachstum. Unterschiedliche Versionen dieser Policy erzeugen jedoch gewollte oder ungewollte Cache-Abweichungen. Eine Instanz kann sich schützen, während eine andere den Dienst trägt. Änderungen müssen deshalb als kontrollierte Rollouts mit Vergleich und Rücknahme behandelt werden.

RFC 8916 stellt dafür Konfigurations- und Operationsknoten bereit. Automatisierung darf die Differenzen sichtbar machen, nicht durch ein globales Boolean verdecken.

Ein Experimental-Protokoll konnte reale Abhängigkeit tragen

RFC 4611 bezeichnet MSDP als weit verbreitetes Experimental-Protokoll, das nicht zum Proposed Standard weiterentwickelt werden sollte. RFC 4624 hält fest, dass MSDP IPv4-only blieb; eine IPv6-Version wurde bewusst nicht geschaffen. RFC 5110 beschreibt es als Stop-gap und nennt Alternativen für bestimmte Redundanzaufgaben.

Diese Statusgeschichte ist weder ein Grund, vorhandene Abhängigkeit zu leugnen, noch eine Lizenz, sie als zeitlose Architektur anzusehen. Ein Betreiber muss die tatsächlich laufende Kontrolle messen und zugleich wissen, welche Funktionen an einem historisch begrenzten Mechanismus hängen.

Heng Lus Betonung von running code und lokaler Entscheidung vermeidet beide Symbolfehler. Ein Experimental-Etikett beweist keine Nichtnutzung. Ein erreichbares Anycast-System beweist keine vollständige Wirkung. Maßgeblich sind beobachtete Zustandsübernahme und Empfängerergebnis.

Redundanz braucht einen Beleg für Gleichheit und einen für Wirkung

Für jede Anycast-RP-Instanz sollte ein exportierbarer Beleg zeigen: lokale Source-Beobachtung, originierte SA, empfangene SA, peer-RPF-Regel, Filter, Cache-Epoche, lokale Empfängerinteressen, Joins und Daten. Ein weiterer Beleg sollte den Failover-Zeitpunkt mit Paket- und Applikationsergebnis verbinden.

Das Risiko zweiter Ordnung ist korrelierte Replikation eines falschen oder alten Zustands. Das Risiko dritter Ordnung ist ein scheinbar gesunder gemeinsamer Endpunkt, hinter dem Instanzen unterschiedliche Realität besitzen. Der irreversible Schritt ist eine Änderung an Mesh, Policy oder Adressierung, die Provenienz zerstört und eine saubere Rücknahme verhindert.

RFC 3618 machte Quellenkenntnis transportierbar. RFC 3446 machte einen RP-Dienst teilbar. Keines machte eine gemeinsame Adresse zum Zeugen dafür, dass alle Erinnerungen und alle Empfänger gleich waren.

Sources