Zusammenfassung

  • Ein IXP Route Server vermittelt Erreichbarkeit im Kontrollpfad, ist aber kein Transitrouter. RFC 7947 empfiehlt deshalb, seine eigene AS-Nummer nicht in den AS_PATH einzufügen, und verlangt, den NEXT_HOP des ankündigenden Teilnehmers unverändert weiterzugeben.
  • Beim Client können Sitzungsnachbar, linkes AS im Pfad und tatsächlicher Weiterleitungsnachbar drei verschiedene Systeme sein. Die notwendige Ausnahme von der First-AS-Prüfung muss auf verifizierte Route-Server-Nachbarn begrenzt bleiben; lokale Import- und Schleifenregeln gelten weiter.
  • Gleichwertigkeit wird für jede Route bewiesen: Eingang, Validierung, clientbezogene Auswahl, Adj-RIB-Out, Empfang, FIB, Nachbarauflösung und Pakete. Zwei grüne Sitzungen oder gleiche Präfixsummen reichen nicht.

Gleich konfiguriert war nicht gleich ausgeliefert

In einem synthetischen Labor mit Dokumentationsadressen kündigt Teilnehmer A ein Testpräfix an zwei Route Server an. Teilnehmer B unterhält zu beiden eine eBGP-Sitzung. Der erste Server sendet einen Pfad, dessen linkes AS A gehört und dessen NEXT_HOP auf As Router im gemeinsamen LAN zeigt. Die AS-Nummer des Route Servers taucht nicht im Pfad auf.

Der zweite Server liefert für dasselbe Präfix einen anderen zulässigen Kandidaten. Beide Instanzen tragen dieselbe deklarierte Policy-Generation, haben aber unterschiedliche Registry-Snapshots und haben ihre clientbezogenen Sichten zu verschiedenen Zeitpunkten neu berechnet. Ein Vergleich der Gesamtzahlen bemerkt den Unterschied nicht.

B übernimmt zunächst eine generische eBGP-Vorlage. Sie erwartet, dass das linke AS mit dem Sitzungsnachbarn übereinstimmt, und verwirft beide Routen. Erst eine auf die amtlich bestätigten Route-Server-Adressen beschränkte Ausnahme lässt die Pfade zu. Danach zeigt die FIB direkt auf den jeweiligen Teilnehmer; Pakete durchlaufen keinen der beiden Route Server.

Bei einem der Kandidaten scheitert jedoch die ARP- beziehungsweise NDP-Auflösung. Der Kontrollpfad ist intakt, der Datenpfad nicht. Das Beispiel ist kein realer Vorfall. Es zeigt, warum Hostverfügbarkeit, Policy-Identität, Routeninhalt und Paketlieferung getrennte Beweise brauchen.

Ein Vermittler ist weder Sammler noch Transit

An einem Internet Exchange teilen sich viele autonome Systeme eine Layer-2-Infrastruktur. Vollständige bilaterale Vermaschung erzeugt mit jedem neuen Teilnehmer zahlreiche zusätzliche BGP-Sitzungen und Betriebsabsprachen. Ein Route Server bündelt diese Austauschbeziehungen: Jeder Client kündigt Erreichbarkeit an wenige Vermittler an und erhält darüber Routen vieler anderer Teilnehmer.

Diese Funktion unterscheidet sich von einem Route Collector. Ein Collector nimmt Feeds für Beobachtung und Analyse entgegen. Der IXP Route Server wirkt an der produktiven Verteilung mit, prüft Eingaben, wählt Kandidaten und erzeugt je nach Client unterschiedliche Ausgaben.

Er ist dennoch kein Weiterleitungsrouter. Er spricht BGP und hält RIBs, soll aber die zugehörigen Nutzpakete nicht transportieren. Der Datenverkehr läuft direkt zwischen den Teilnehmern über das Exchange-Fabric.

Damit wird klar, was AS_PATH abbilden soll. Das Attribut trägt die für Schleifenerkennung, Auswahl und Richtlinien relevante AS-Folge. Es ist keine Liste aller Prozesse, die ein UPDATE bearbeitet haben. Würde der Vermittler seine AS-Nummer nur wegen der Sitzung einfügen, entstünde ein nicht existierender Transithop, der Entscheidungen des Empfängers verändern könnte.

Der Route Server ist also nicht unsichtbar. Seine Sitzung, RIBs, Prüfungen und Policies sind sichtbar und müssen protokolliert werden. Nur seine Kontrolle darf nicht als Weiterleitungsgeschichte ausgegeben werden.

Transparenz ist eine begrenzende Handlung

Das gewöhnliche eBGP-Verfahren aus RFC 4271 sieht beim externen Weiterankündigen das Voranstellen der eigenen AS-Nummer vor. RFC 7947 empfiehlt Route Servern, davon standardmäßig abzuweichen und AS_PATH ohne ausdrückliche Konfiguration nicht zu verändern. Eine zusätzliche AS-Nummer kann Pfadlänge, Filter oder Präferenz beeinflussen.

Für NEXT_HOP ist die Vorgabe zwingender. Weil der Server keine Pakete weiterleitet, muss der Wert unverändert zum Client gelangen. Stammt die Route von A, soll B direkt an As Peering-Adresse senden. Eine Umschreibung auf den Server würde Verkehr zu einer Komponente ziehen, die dafür nicht gebaut ist.

Auch weitere bekannte und optionale Attribute sollen grundsätzlich erhalten bleiben, sofern eine veröffentlichte lokale IXP-Regel keine Verarbeitung verlangt. Diese Transparenz schützt die Teilnehmer davor, dass der Broker ihre Entscheidungsgrundlage still verändert.

Passiv ist der Server deshalb nicht. Er kann ungültige Präfixe zurückweisen, Herkunftsdaten prüfen, Communities als Verteilungsanweisung auswerten und eine clientbezogene Sicht berechnen. Sein Einfluss fehlt im AS_PATH, bleibt aber für Erreichbarkeit entscheidend.

Eine vollständige Akte führt deshalb zwei Register zusammen: Die Attribute beschreiben den angebotenen Weiterleitungspfad. Die Betriebsdaten des Servers beschreiben Eingang, Prüfung, Auswahl und Ausgabe der Vermittlung.

Die First-AS-Ausnahme darf nicht zur Standardlücke werden

Viele eBGP-Implementierungen prüfen, ob die AS-Nummer am linken Rand des Pfades dem Nachbarn entspricht. Bei Transit und bilateralem Peering ist das ein nützliches Konsistenzsignal. Ein transparenter Route Server bricht diese Gleichheit absichtlich: Das UPDATE kommt vom Server, der Pfad beginnt beim ursprünglichen Ankündiger.

RFC 7947 verlangt, dass Clients diese Prüfung abschalten können, und empfiehlt eine Einstellung pro Peer. Die Reichweite ist der Sicherheitsmechanismus. ASN, Adressen und Adressfamilien des Servers müssen aus der maßgeblichen IXP-Dokumentation stammen; nur diese Nachbarobjekte erhalten die Ausnahme.

Bleibt die Prüfung aktiv, kann eine gesunde Sitzung sämtliche brauchbaren Routen verwerfen. Wird sie in einer globalen Außennachbar-Vorlage deaktiviert, verlieren Transit- und Peer-Beziehungen eine Prüfung, die sie weiterhin benötigen. Beides macht aus einer lokal nötigen Anpassung einen strukturellen Fehler.

Die Ausnahme ersetzt keine Importpolitik. B prüft weiterhin das eigene ASN im Pfad, Präfixe und Origins, Mengenlimits sowie die eigenen IRR- oder RPKI-Anforderungen. Der Route Server erstellt eine Kandidatenmenge; B entscheidet, was in Loc-RIB und FIB gelangt.

Eine gemeinsame beste Route kann einen erlaubten Ersatz verdecken

Teilnehmer wollen ein Präfix allen, nur ausgewählten oder gar keinen anderen Clients zeigen. RFC 7948 nennt Communities, Routing-Register und clientzugängliche Datenbanken als mögliche Eingaben. Aktuelle Unterlagen von IXP Manager, AMS-IX und LINX dokumentieren konkrete Verträge mit Standard und Large Communities.

Der Tag allein ist kein globaler Befehl. Seine Bedeutung entsteht im veröffentlichten Vertrag des jeweiligen IXP. Erst das clientbezogene Adj-RIB-Out belegt, dass die gewünschte Verteilung ausgeführt wurde.

Path Hiding entsteht durch die Reihenfolge. Der Server kennt zwei Wege, wählt in einer gemeinsamen Sicht A und wendet danach Bs Exportregel an, die A ausschließt. Entfernt er nur den bereits ausgewählten Pfad, erhält B nichts, obwohl der zweite Kandidat zulässig wäre.

Jede Einzelentscheidung kann korrekt wirken: A war global bevorzugt, Bs Ausschluss war gültig, und die leere Ausgabe folgt dem Filter. Falsch war die Annahme, eine gemeinsame Perspektive könne Bs individuelle beste Route bestimmen.

RFC 7947 beschreibt eine Loc-RIB pro Client als portable Abhilfe: Erst die clientbezogenen Regeln anwenden, danach unter den verbleibenden Kandidaten auswählen. Gemeinsamer Zustand kann optimiert und nur als Differenz gespeichert werden. Mehrwegeverfahren wie Diverse Paths oder ADD-PATH sind ebenfalls möglich. Bei ADD-PATH soll der Route Server gegenüber Clients send-only verhandeln, damit inaktive Clientpfade nicht als ungeeignete neue Eingaben zurückfließen.

FRRouting dokumentiert gegenwärtig eine eigene Loc-RIB für RS-Clients; AMS-IX nennt BIRDs secondary als Schutz gegen Path Hiding. Konfigurationsnamen sind jedoch kein Laufzeitbeweis. Ein Test muss zwei Kandidaten erzeugen, den gemeinsamen Favoriten für B sperren und die tatsächliche Ankunft der erlaubten Alternative nachweisen.

Ein unveränderter NEXT_HOP erfordert strenge Eingangszuordnung

Der direkte Next Hop hält Pakete vom Server fern, eröffnet aber Missbrauch. A könnte sein eigenes Präfix mit der Peering-Adresse von C als NEXT_HOP ankündigen. Verteilt der Server diese Route, senden viele Clients möglicherweise Verkehr an C.

RFC 7948 empfiehlt daher, den empfangenen NEXT_HOP mit der Schnittstellenadresse des ankündigenden Clients abzugleichen und eine AS-übergreifende Abweichung zu verwerfen. Für mehrere Anschlüsse desselben AS kann eine kontrollierte Ausnahme bestehen. IXP Manager dokumentiert eine entsprechende Prüfung neben AS-Pfad-, Präfix-, IRR- und RPKI-Regeln.

Am Route Server ist die Eingangsidentität noch bekannt. Nach der Aggregation vieler Quellen über eine Sitzung kann B kaum rekonstruieren, welcher Teilnehmer welche Adresse benennen durfte. Der Broker trägt daher eine konzentrierte Zuordnungspflicht.

Autorisierung beweist jedoch keine momentane Erreichbarkeit. Ein nichttransitiver Fabric-Fehler kann B zu beiden Route Servern verbinden, während A von B aus nicht erreichbar ist. BGP bleibt Established, ARP oder NDP scheitert. Ein Ping zum Broker testet in diesem Fall gerade nicht den Datenpfad.

Redundanz wird an der Dienstgrenze gemessen

RFC 7948 empfiehlt mehrere Route Server auf demselben gemeinsamen Segment. Unterschiedliche Implementierungen und Betriebssysteme können einen gemeinsamen Softwarefehler vermeiden.

Zwei Prozesse garantieren aber keine identischen Sichten. Policy-Generationen, IRR-Daten, RPKI-Zustände, Konvergenzzeitpunkte und clientbezogene Auswahl können auseinanderlaufen. Gleiche Präfixzahlen überdecken abweichende AS_PATH-, NEXT_HOP-, MED- oder Community-Werte.

Der Vergleich muss pro Client, AFI/SAFI und NLRI erfolgen. Relevante Attribute werden normalisiert und als Fingerprint verglichen. Jede erwartete Abweichung benötigt einen Grund. Die laufende Instanz muss ihre konkrete Konfigurations- und Datengeneration ausweisen.

Implementierungsvielfalt ohne beobachtbare Funktionsgleichheit liefert Unvorhersagbarkeit. Zwei identische, undurchsichtige Instanzen können denselben Fehler verdoppeln. Belastbare Redundanz braucht sowohl unabhängige Fehlerdomänen als auch prüfbare Gleichwertigkeit.

Acht Belege verbinden Ankündigung und Paket

Die Kette verläuft in Verarbeitungsreihenfolge:

  1. As Adj-RIB-Out oder ein Mitschnitt zeigt die ursprüngliche Ankündigung.
  2. Das Adj-RIB-In des Servers zeigt den tatsächlichen Eingang.
  3. Validierungsprotokolle erklären Präfix-, Origin-, First-AS- und NEXT_HOP-Prüfung.
  4. Bs clientbezogene Sicht samt Policy-Generation erklärt die Auswahl.
  5. Das Adj-RIB-Out zu B zeigt die angebotenen Attribute.
  6. Bs Adj-RIB-In beweist, was die Sitzung überquerte.
  7. Ausgewählte RIB, FIB und Nachbartabelle zeigen den programmierten direkten Next Hop.
  8. Zähler, Sonden oder Paketmitschnitte belegen die Lieferung an A.

Eine Master-RIB ist nicht Bs Sicht. Ein Looking Glass zeigt oft nicht alle verworfenen Kandidaten. Eine Soll-Konfiguration beweist nicht die laufende Generation. Zeitstempel und Identitäten machen aus Einzelbildern erst eine kausale Akte.

Auch Verantwortung bleibt getrennt: A verantwortet die Ankündigung, der Serverbetreiber Prüfung und clientgerechte Verteilung, B Import und lokale Auswahl, der IXP-Betreiber die direkte Layer-2-Lieferung. Kein Beteiligter kann seine Stufe mit der grünen Anzeige eines anderen abschließen.

Eine Migration, die gerade die Ausnahmen prüft

Zuerst werden aus der autoritativen IXP-Quelle ASN, Adressen, Adressfamilien, Fähigkeiten und Community-Vertrag beider Server festgehalten. Die First-AS-Ausnahme wird ausschließlich an diese Nachbarn gebunden.

Ein Testpräfix wird an beide Server gesendet. Eingang, Validierung, Bs Sicht, Serverausgang, Bs Empfang, FIB, MAC-Auflösung und Paketpfad werden nacheinander erfasst. Erwartet wird kein künstlich gewöhnliches eBGP-Bild: Das linke AS bleibt A, NEXT_HOP bleibt As Adresse, und die Server-ASN wird nicht als Scheinhop eingefügt.

Danach folgen Negativfälle: Nur B erlauben, C sperren und umgekehrt; zwei Wege anbieten und den bevorzugten für B ausschließen; einen NEXT_HOP eines anderen AS nennen und Ablehnung verlangen; IPv4 und IPv6 getrennt prüfen. Die beiden Serverausgaben werden attributgenau verglichen.

Für den Rollback bleiben frühere Client- und Server-Policy-Generationen erhalten. Eine zurückgesetzte Zeile entfernt nicht zwingend bereits gelernte Routen. Route Refresh, Policy-Neubewertung oder eine kontrollierte Sitzungsaktion können erforderlich sein, ohne unbeteiligte Dienste neu zu starten.

Quellen und Grenzen

Grundlage ist RFC 7947, gelesen gegen das BGP-Basisverhalten in RFC 4271. RFC 7948 behandelt Redundanz, Leaks, Layer 2 und NEXT_HOP-Hijacking. RFC 7911 und RFC 6774 begründen die genannten Mehrwegeverfahren.

Aktuelle Implementierungsbeispiele stammen aus FRRouting, BIRD und IXP Manager. Die offiziellen Seiten von AMS-IX und LINX zeigen veröffentlichte Betriebspraxis, beweisen aber nicht den Laufzeitzustand eines ungenannten IXP. Der Einstiegsfall ist synthetisch.