Warum kann ein funktionierendes Netzwerk verschwinden, wenn sich Registry-Daten ändern?

Stellen Sie sich vor, Ihr Dienst funktioniert über eine Mobilfunkverbindung weiterhin, doch Kunden in einem anderen Netzwerk können ihn nicht mehr erreichen. Die Server laufen einwandfrei. Die Kabel sind angeschlossen. Eine mögliche Erklärung lautet: Nach der Änderung eines Eintrags nimmt ein anderes Netzwerk die Route zu Ihren Adressen nicht mehr an.

Das fehlende Bindeglied ist die Entscheidung zwischen dem Eintrag und dem Router. Eine Datenbankänderung kann die Erreichbarkeit beeinflussen, wenn ein System diese Änderung zum Erstellen eines Filters oder zur Bewertung einer Routenankündigung verwendet. Um die Störung zu verstehen, müssen Sie dieser Kette folgen. „Die Registry liegt falsch“ ist erst der Anfang der Diagnose.

Physische Verbindungen können intakt bleiben, während eine Änderung eines Eintrags die Annahme von Routen beeinflusst. Verfolgen Sie die Nachweise und die Regeln auf der empfangenden Seite.

Fragen Sie zuerst, welcher Eintrag sich geändert hat

Ein IP-Präfix ist ein Block von Adressen. Die Nummer eines autonomen Systems, kurz ASN, kennzeichnet ein Netzwerk, das Routen mit anderen Netzwerken austauscht. BGP ist das Protokoll, mit dem diese Netzwerke ankündigen, welche Ziele sie erreichen können.

Diesen Austausch begleiten verschiedene Arten von Einträgen. Sie beantworten unterschiedliche Fragen:

• Registrierungseinträge: Welche Organisation ist einem Adressblock zugeordnet, und wer ist der Ansprechpartner? Die Dokumentation der RIPE-Datenbank unterscheidet zwischen Ressourcenregistrierung, Routing-Informationen und Kontaktdaten, obwohl sie in derselben Datenbank liegen.
• Einträge in einer Internet Routing Registry (IRR): Informationen, mit denen Betreiber Listen der Routen erstellen können, die sie akzeptieren wollen. Ein Eintrag beschreibt das beabsichtigte Routing; er kündigt selbst keine Route an.
• Einträge der Resource Public Key Infrastructure (RPKI): Dazu gehören signierte Autorisierungen des Routenursprungs, sogenannte ROAs. Aus ihnen erzeugen Validatoren Daten, mit denen sich das Ursprungsnetzwerk und die zulässige Präfixlänge prüfen lassen.

Eine veraltete Kontakt-E-Mail-Adresse zieht nicht unmittelbar eine BGP-Route zurück. Fehlt eine Route dagegen im erzeugten Filter eines Providers, kann das dazu führen, dass dieser Provider sie nicht mehr annimmt. Beides als „ungültige Registry-Daten“ zu bezeichnen, verdeckt den entscheidenden Unterschied.

Wie aus einem Eintrag eine abgelehnte Route wird

Betrachten wir einen Provider, der seine Kundenfilter aus IRR-Daten erstellt. Ein möglicher Störungsablauf sieht so aus:

1. Ein Routeneintrag wird entfernt, oder die Routing-Menge des Kunden enthält ihn nicht mehr.
2. Bei der nächsten Erstellung des Filters lässt der Provider diese Route weg.
3. Der neue Filter wird auf die Router des Providers übertragen, die daraufhin die Routenankündigung des Kunden ablehnen.
4. Bleibt keine nutzbare Alternative, verlieren die Menschen den Zugriff, die auf diesen Pfad angewiesen sind.

Damit diese Kette entsteht, müssen die Daten tatsächlich in diesen Filter einfließen. Die veröffentlichte Routing-Registry-Richtlinie von NTT DATA liefert ein konkretes Beispiel für IRR-basierte Kundenfilter und automatische Aktualisierungen. Sie dokumentiert außerdem die Ablehnung von Routen mit dem RPKI-Status Invalid und die Unterdrückung widersprüchlicher IRR-Einträge. Das sind nachvollziehbare betriebliche Mechanismen, kein universeller Ausschalter der Registry.

Was der RPKI-Status „Invalid“ tatsächlich bedeutet

Bei der Ursprungsvalidierung wird die angekündigte Route mit validierten Autorisierungsdaten verglichen. RFC 6811 definiert drei Ergebnisse:

• Valid: Mindestens eine abdeckende Autorisierung stimmt mit der Ursprungs-ASN überein und erlaubt die angekündigte Präfixlänge.
• Invalid: Es gibt abdeckende Autorisierungsdaten, doch keine Autorisierung erfüllt beide Bedingungen.
• NotFound: Keine Autorisierungsdaten decken die Route ab.

Eine von Netzwerk A angekündigte Route kann beispielsweise den Status Invalid erhalten, wenn ihre passende Autorisierung verschwindet, während eine abdeckende Autorisierung für Netzwerk B bestehen bleibt. Bleibt keine abdeckende Autorisierung übrig, lautet das Ergebnis stattdessen NotFound. „Invalid“ ist hier ein Ergebnis der Routing-Validierung und kein Urteil über Eigentum oder institutionelle Legitimität. Die Ursprungsvalidierung authentifiziert außerdem nicht den gesamten Pfad, den eine Route nach eigenen Angaben durchlaufen hat.

Der nächste Schritt hängt von den konfigurierten Regeln des Betreibers ab. RFC 8481 trennt die Festlegung eines Validierungsstatus von der Reaktion darauf: Die Regeln müssen vom Betreiber konfiguriert werden. Ein Netzwerk, das Routen mit dem Status Invalid ablehnt, kann diese Ankündigung dann zurückweisen. Eine Änderung in der Registry und eine Ablehnung sind durch diesen Mechanismus miteinander verbunden; sie sind nicht dasselbe Ereignis.

Warum manche Menschen den Zugriff früher verlieren als andere

Netzwerke verwenden nicht alle dieselben Filter, Provider oder Daten zur selben Zeit. RFC 7115 erläutert, dass RPKI-Caches unterschiedliche Datenstände enthalten können und dass es kein einheitliches garantiertes Intervall gibt, innerhalb dessen Aktualisierungen die Router erreichen.

Im eingangs beschriebenen Beispiel hat ein Netzwerk möglicherweise bereits auf die geänderten Daten reagiert, während ein anderes noch über einen akzeptierten Pfad verfügt. Dadurch ist ein Teilausfall möglich. Das beweist nicht, dass eine Registry einen bestimmten Ausfall verursacht hat: Techniker müssen weiterhin die betroffene Route, die verwendeten Daten und die Entscheidung untersuchen, die zur Ablehnung geführt hat.

Finden Sie das fehlerhafte Glied der Kette, bevor Sie weitere Dinge ändern

Die hilfreiche Frage für die Wiederherstellung ist konkret: Welches System hat welche Ankündigung nicht mehr angenommen, und warum? Ein Betreiber kann diese Frage gemeinsam mit dem Provider Schritt für Schritt klären:

1. Die Ankündigung identifizieren. Halten Sie das betroffene Präfix und die Ursprungs-ASN fest und prüfen Sie, ob die erwartete Route weiterhin angekündigt wird.
2. Die Ablehnung lokalisieren. Vergleichen Sie den installierten Filter und das Validierungsergebnis des Providers mit der Route. Fragen Sie, welche Datenquelle und welche Aktualisierung zu dieser Entscheidung geführt haben.
3. Die Nachweise sichern. Bewahren Sie die relevanten Einträge, Beobachtungen und Zeitstempel auf, damit sich eine fehlerhafte Aktualisierung von einer nicht autorisierten Ankündigung unterscheiden lässt.
4. Den Fehler beheben und das Ergebnis prüfen. Stimmen Sie die genaue Korrektur des Eintrags oder der Konfiguration ab, bestätigen Sie, dass sie die nutzenden Systeme erreicht hat, und testen Sie den Zugriff aus den Netzwerken, in denen er ausgefallen war.

Die Validierung überall abzuschalten, würde auch den Schutz vor fehlerhaften Ankündigungen beseitigen. Die betriebliche Aufgabe besteht darin, korrekte Nachweise und das beabsichtigte Routing wiederherzustellen und anschließend das Ergebnis zu überprüfen. Eine erfolgreiche Datenbankänderung allein belegt noch nicht, dass Kunden sich wieder verbinden können.

Das tiefere Problem: Nützliche Nachweise können zu konzentrierter Macht werden

Hier trifft die technische Kette auf Lu Hengs Argumentation. Eine Verwaltungsstelle muss keine Datenpakete weiterleiten, um Einfluss auf die Erreichbarkeit auszuüben. Wenn andere Systeme von den Einträgen abhängen, die sie kontrolliert, können ihre Entscheidungen Betreibern und Kunden weit außerhalb ihres Büros Kosten auferlegen.

In Notiz 65, Vorrang funktionierenden Codes, argumentiert Lu Heng, dass die Koordination durch die Bedürfnisse laufender Netzwerke begrenzt sein muss. Aus einer Rolle bei der Pflege von Einträgen darf kein dauerhaftes politisches Mandat erwachsen. Dass ein Eintrag signiert ist, beantwortet eine technische Frage zur enthaltenen Aussage; es begründet kein Recht, über alle davon Betroffenen zu bestimmen.

Sein Vorschlag geht über ein besseres Beschwerdeverfahren hinaus. Die gemeinsamen Regeln sollen Eindeutigkeit, überprüfbare Kontrolle und Interoperabilität schützen, während die Teilnehmer den Zustand lokal validieren und entscheiden, welche kompatiblen Änderungen sie übernehmen. Ein neues Gremium mit unbegrenztem Vetorecht würde das Problem unter einem anderen Namen wiederholen.

Kontinuität braucht einen Ausweg, den andere Netzwerke nutzen können

Eine brauchbare Alternative muss vertrauenswürdige Einträge, Sicherheitsnachweise und funktionierende Beziehungen bewahren. Andere Netzwerke müssen diese Einträge überprüfen und nutzen können. Eine Datenbank einfach zu kopieren, bringt sie noch nicht dazu, einen Ersatz zu akzeptieren, und eine Unabhängigkeitserklärung repariert keine abgelehnte Route.

Notiz 72 benennt das angestrebte Ergebnis ausdrücklich: korrekte Einträge, betriebliche Kontinuität und eine echte Möglichkeit, eine versagende Koordinationsstelle zu verlassen. Die praktische Herausforderung besteht darin, diese Möglichkeit zu schaffen, ohne die gemeinsame Eindeutigkeit und Kompatibilität zu verlieren, die unabhängigen Netzwerken die Kommunikation ermöglichen.

Der Leitfaden zum Export des Registry-Zustands behandelt den Teil dieser Arbeit, bei dem Einträge in den Übergang mitgenommen werden. Das ist eine Komponente eines Übergangs, neben der Überprüfung, der Übernahme durch Betreiber und Kontinuitätstests.

Bereiten Sie sich vor, solange der Dienst noch funktioniert

Bitten Sie Ihr Team, einen wichtigen Adressblock von seinen Einträgen bis zu den Providern und Kunden zurückzuverfolgen, die davon abhängen. Wer kann den jeweiligen Eintrag ändern? Wer verwendet ihn? Wie ließe sich ein Fehler korrigieren, wenn die derzeitige Verwaltungsstelle nicht verfügbar oder umstritten wäre?

Diese Antworten organisationsübergreifend zu klären, braucht Zeit. Werden sie vor einem Ausfall gefunden, entsteht Handlungsspielraum; werden sie erst während einer Störung ermittelt, tragen die Kunden die Kosten. Dringlich ist es, praktische Unabhängigkeit aufzubauen, solange sich die Kontinuität noch schützen lässt.

Lesen Sie weiter in Notiz 65: Vorrang funktionierenden Codes, um Lu Hengs vollständiger Argumentation für eine Koordination zu folgen, die auf funktionierenden Netzwerken, lokaler Überprüfung und freiwilliger Übernahme beruht.