Summary

  • Sebastian Becker erklärte auf RIPE 92, dass ein AS-SET für den Filter des Kundenkegels die eigene AS und nachgelagerte Kunden enthalten soll. Peers und Upstreams brauchen getrennte, klar bezeichnete Sammlungen.
  • Vor der Aktivierung vergleicht sein Team angekündigte Präfixe mit der Breite des generierten Filters. Die Gegenüberstellung von 100 erwarteten und 10.000 aufgelösten Präfixen war ein erklärendes Beispiel, kein berichteter Ausfall.

In einer Registry beschreibt ein AS-SET Beziehungen. In einer BGP-Konfiguration entscheidet es mit, welche Präfixe ein Netz akzeptiert. Sebastian Becker, Peering-Manager von AS3320 bei Deutsche Telekom, machte auf RIPE 92 aus diesem Übergang seinen eigentlichen Betriebspunkt: Bevor ein Datensatz zur Filterregel wird, muss sein Zweck feststehen.

Für den Kundenkegel sollen die eigene AS und die nachgelagerten ASNs oder AS-SETs stehen. Peer- und Upstream-Beziehungen können ebenfalls dokumentiert werden, aber mit eigener Kennzeichnung in anderen Sets. Wer alle Rollen in eine Sammlung wirft, lässt die rekursive Auflösung möglicherweise viel mehr Routen einschließen als ein Kunde je ankündigen sollte. Ein schlecht gepflegtes Verzeichnis wird so zur großzügigen Zugangsregel.

Auch die Herkunft des Sets zählt. Becker beschrieb gleiche AS-SET-Namen in mehreren IRR-Datenbanken, von denen nur eine Kopie aktiv gepflegt wird. Alte Referenzen verschwinden durch das bloße Kopieren nicht. Wer verschiedene Quellen zusammenzieht, muss wissen, welche gepflegt wird und ob die erzeugten Einträge zur gegenwärtigen Kundenbeziehung passen.

Beckers Test beginnt vor der ersten Sitzung: Der Kunde nennt 100 erwartete Präfixe, die Auflösung ergibt 10.000. Seine Mannschaft probiert die Filtergenerierung aus, bevor sie BGP einschaltet oder den Filter annimmt, und meldet den Unterschied zurück. Dokumentation kann schon beim geplanten Anschluss stehen, damit berechtigte Routen beim Start ohne Wartezeit passen. Die offizielle Vortragsseite führt Fedor Vompe als Mitredner; dessen spätere Zahlen über AS-SET-Schleifen sind ein anderer Vortragsteil.

In einer eigenen Ankündigung von 2024 erklärte Becker den Plan, bei AS3320 RPKI-ungültige Ursprünge abzulehnen und unbekannte weiter anzunehmen. Ursprungsvalidierung prüft etwas anderes als die dokumentierte Kundenbeziehung. Datierte Filterdifferenzen, tatsächlich empfangene Routen und Korrekturen würden zeigen, wie oft die Vorprüfung einen Fehler auffängt.

Die kleine Entscheidung vor dem Einschalten verhindert eine große, schnelle Wirkung danach. Ein korrektes Set lässt sich automatisieren. Ein vermischtes Set automatisiert nur den Irrtum.

Quellen: RIPE-92-Originalprotokoll · offizielle Vortragsseite · RIPE-NCC-Biografie · Beckers Originalankündigung.