Zusammenfassung

  • AMS-IX betreibt in Amsterdam zwei Route-Server unter AS6777, rs1.ams-ix.net und rs2.ams-ix.net; teilzunehmen heißt, mit beiden zu sessionieren.
  • Die Norm verpflichtet zu genau einem Verhalten – NEXT_HOP unverändert weiterzureichen – und behandelt die Erhaltung von AS_PATH und MED als Empfehlungen mit ausdrücklich genanntem Grund.
  • Die einzige ausdrückliche Verantwortungszuweisung im veröffentlichten Material legt Prefixlisten-Konsistenz und Konfigurationskonformität auf den Teilnehmer.

Ein Netz, das dem Route-Server des Amsterdamer Austauschpunkts beitritt, baut nicht länger eine BGP-Session pro Peer, sondern eine einzige zu einer Maschine, die weiterverbreitet, was alle anderen ankündigen. AMS-IX veröffentlicht zwei davon: rs1.ams-ix.net auf 80.249.208.255 und 2001:7f8:1::a500:6777:1 sowie rs2.ams-ix.net auf 80.249.209.0 und 2001:7f8:1::a500:6777:2, beide unter AS6777. Die Bedingungen sind konkret – mit beiden verbinden, auf jeder Session gleiche Anzahl und Länge der Prefixe ankündigen, TCP-Port 179 öffnen –, und die Route-Server-Dokumentation von AMS-IX nennt sie ohne Umschweife.

Was diese Dokumentation nicht tut, ist den Betreiber auf einen symmetrischen Satz von Zusagen festzulegen. Sie beschreibt Verhalten. Die Pflichten, die sie ausbuchstabiert, sind die des Teilnehmers.

Das eine, worüber die Norm nicht verhandelt

RFC 7947 definiert den Route-Server eines Austauschpunkts, und seine härteste Anforderung betrifft eine Adresse: „the NEXT_HOP attribute MUST be passed unmodified“ (Abschnitt 2.2.1, September 2016). Dieser Satz erklärt, warum ein Route-Server in keiner Hinsicht, die für ein Paket zählt, ein Router ist. Der Next Hop, den ein Client sieht, ist die Adresse des ankündigenden Peers auf dem Switching Fabric; der Verkehr läuft Peer zu Peer über das Fabric und passiert nie die Maschine, die in seinem Namen BGP gesprochen hat. RFC 7948, das Betriebsdokument desselben Monats, zieht dieselbe Grenze: Erreichbarkeitsinformation zu verteilen ist kein Verkehrsweiterleitung.

Alles Übrige im Abschnitt zur Attributbehandlung ist weicher, und zwar mit Absicht. Der Route-Server „SHOULD NOT prepend its own AS number“ an das, was er weiterreicht (Abschnitt 2.2.2.1). Er propagiert MULTI_EXIT_DISC und „SHOULD NOT modify its value“ (Abschnitt 2.2.3). Abschnitt 2.2 setzt Attributtransparenz als Standard und erlaubt zugleich ausdrücklich Ausnahmen, wo lokale Konfiguration sie verlangt; Abschnitt 2.1 lässt Policy-Filterung rundheraus zu.

Der RFC nennt selbst den Grund, warum er bei AS_PATH auf SHOULD statt MUST stehen bleibt: Es gibt einen realen Bestand älterer Clients, die eine Session ablehnen, deren erstes AS unerwartet ist, und eine verbindliche Regel hätte sie zurückgelassen. Deshalb verlangt die Norm von Implementierungen, die Prüfung des ersten AS abschaltbar zu machen, möglichst pro Peer, statt die schwerere Garantie zu übernehmen. Das ist ein Ingenieurskompromiss im Gewand einer Anforderungsstufe, und er ist für jeden relevant, der annahm, der Austauschpunkt habe die absolute Pflicht übernommen, die Pfadattribute in Ruhe zu lassen.

Was der Betreiber zu Protokoll gibt

AMS-IX veröffentlicht seine Hälfte der Abmachung. Der Dienst fügt AS6777 nicht in die AS_PATHs der weitergeleiteten Routen ein, und Prüfungen des ersten AS müssen, wo einschlägig, abgeschaltet werden. Export-Peers werden über RPSL-Einträge und Communities gewählt: Community 0:6777 blockiert alle Exporte, 6777: schaltet einen ausgewählten Peer frei, und neue Sessions laufen standardmäßig durch kombinierte IRRDB- und RPKI-Filterung. Gelernte Routen dürfen dem Teilnehmer und seinen Downstream-Kunden dienen; die Weitergabe an Upstreams, externe Peers oder den Route-Server eines anderen Austauschpunkts ist untersagt.

Zwei Sätze in diesem Material verdienen einen zweiten Blick. Der erste warnt, IRRDB- und RPKI-Daten böten keine Gültigkeitsgarantie und sollten nicht allein herangezogen werden – die Beschreibung des Betreibers für die Filterung, die er standardmäßig anwendet. Der zweite ist die Verantwortungsklausel: „Participants are responsible for ensuring that their routing configuration complies with this policy.“

RFC 7948 war längst bei derselben Verteilung angekommen. Er beschreibt die Pflicht des Clients, dafür zu sorgen, dass seine angekündigte Prefixliste mit dem übereinstimmt, was er tatsächlich annonciert (Abschnitt 4.3), empfiehlt Leak-Minderung auf Betreiberseite und verlangt den automatisierten Abgleich empfangener Routen gegen konfigurierte Prefixlisten, wo immer eingehende Filterung pro Client existiert.

Die Rolle, die die Dokumente zuschneiden, ist eher verwaltend als treuhänderisch: Der Route-Server filtert, wählt aus und kündigt erneut an, der Betreiber veröffentlicht, was er tut, und niemand übernimmt eine aufzählbare Prüfpflicht gegenüber jedem einzelnen Teilnehmer.

Was ich suchte und was im Text steht

Ich suchte einen dokumentierten Handel: eine Session zu jedem Mitglied gegen eine veröffentlichte Liste dessen, was der Austauschpunkt dir dafür schuldet. Die Dokumente stützen nur die erste Hälfte. Der Handel ist real – die Zahl der Sessions bricht tatsächlich zusammen –, aber er wird in Exposition bezahlt, nicht in Servicegraden. Ein kategorisches MUST hält die Pakete aus dem geteilten Sprecher heraus. Zwei SHOULD, ein Kompatibilitätsargument und eine offene Tür für lokale Konfiguration halten dem Betreiber bei Pfadwahl und MED die Hände frei.

Die nützliche Lesart ist also nicht, der Route-Server von AMS-IX sei nachlässig. Sie lautet, dass die Sache als Verwalter mit begrenztem Mandat konstruiert ist: befugt zu Entscheidungen auf der Steuerungsebene, unfähig, ein einziges Paket weiterzuleiten, und rechenschaftspflichtig vor allem durch veröffentlichten Text. Diese Deutung ist meine, nicht die der IETF und nicht die des Austauschpunkts; keine formale Position formuliert sie.

Was ein Teilnehmer tatsächlich prüfen kann

Der Verzeichniseintrag zu diesem Route-Server sammelt dieselben veröffentlichten Fakten an einer Stelle, und das Prüfproblem steckt genau in dem, was sie offenlassen. Ein Teilnehmer kann die interne Konformität des geteilten Sprechers nicht auditieren, indem er eine Policy-Seite liest. Er kann die Routen lesen, die er empfängt, und bestätigen, dass der sichtbare Next Hop der Peer ist und nicht der Route-Server. Er kann beobachten, ob 0:6777 und 6777: das beschriebene Exportverhalten erzeugen. Und er kann beide Sessions aufrechterhalten und vergleichen, was jeder Server schickt, damit eine Abweichung als Abweichung erscheint und nicht als Rätsel.

Die Dokumentation ist in der veröffentlichten Fassung undatiert, wurde am 12. November 2026 abgerufen, und ihre Gültigkeit zum Publikationsdatum ist unbestätigt. Live-Verhalten wurde hier nicht getestet, und ob Filterungsvorgaben und Community-Exportsteuerung auf rs1 und rs2 gleich funktionieren, ist der geprüften Seite nicht zu entnehmen. Gefunden wurde genau eine ausdrückliche Verantwortungsaussage, zur Prefixlisten-Konsistenz; das Fehlen einer breiteren Betreibergarantie auf jener Seite ist eine Beobachtung über jene Seite, kein Beweis, dass es solchen Text anderswo nicht gibt.

Die ehrliche Zusammenfassung des Handels

Ein Route-Server spricht und befördert nicht, und das Papier hat dieselbe Form: ein bedingungsloses Versprechen, das den Verkehr aus der Kiste heraushält, und zwei bedingte, die dem Austauschpunkt die Hände frei lassen bei den Attributen, die ihn lenken. Ein Netz, das mehr Absicherung braucht, findet sie nicht im Policy-Text. Es findet sie, oder eben nicht, in seinen eigenen empfangenen Routen – genau dort, wo die Dokumente die Verantwortung bereits verorten.