Zusammenfassung

  • Aggregation erzeugt aus mehreren spezifischeren Routen eine neue weniger spezifische Route. Nach RFC 9774 ist AS_SET nicht mehr der normale Weg: ATOMIC_AGGREGATE meldet verlorene Pfadinformation, AGGREGATOR benennt den letzten erzeugenden Speaker.
  • Ein vorhandenes Aggregat, ein gültiges ROA und eine Established-Session beweisen nicht die Erreichbarkeit jedes überdeckten Ziels. Bei fehlendem Beitrag kann der korrekte Paketweg im lokalen Discard enden, ohne dass sich die globale Route ändert.
  • Führung darf den Informationsverlust nur mit bewusst festgelegtem Origin AS, beitragsspezifischen Filtern, einem Belegregister vor der Verdichtung, RIB/FIB- und Paketprüfungen sowie vollständigem Rollback genehmigen.

Um 02:13 Uhr erzeugt AS 64505 aus vier Kunden-/24 das Aggregat 203.0.112.0/22. Es soll Updates reduzieren und Upstreams eine stabile Route liefern. Ein ROA autorisiert 64505 für das /22; ATOMIC_AGGREGATE und AGGREGATOR begleiten das UPDATE.

Um 03:07 Uhr verschwindet 203.0.114.0/24 während einer Wartung. Drei Beiträge bleiben aktiv, deshalb hält die Plattform das /22. Öffentliche Collector sehen keinen Withdraw, RPKI-ROV bleibt Valid, die Session bleibt Established und die FIB enthält das Aggregat.

Ein Testpaket zum ausgefallenen /24 findet in AS 64505 keine längere Route und landet auf dem Discard des Aggregats. Das verhindert, dass es über eine andere weniger spezifische Route das AS verlässt und als Schleife zurückkehrt. Die Schutzfunktion arbeitet. Der Dienst für das Ziel arbeitet nicht. Ein grüner Aggregate-Status kann beides nicht unterscheiden.

Der Vorfall ist konstruiert, die Mechanik standardisiert. ATOMIC_AGGREGATE verspricht keine Lieferung. Das Attribut weist darauf hin, dass der sichtbare AS_PATH die Pfade, aus denen das Aggregat entstand, nicht vollständig wiedergeben kann.

Das Aggregat ist eine neue Behauptung

BGP verkürzt nicht bloß eine Anzeige. Mehrere more-specific NLRI werden zu einer less-specific NLRI mit eigenen Attributen, Aktivierungsbedingungen, Exportregeln und Forwardingfolgen. Das Ergebnis kann stabil bleiben, obwohl ein Bestandteil verschwindet.

RFC 4271 sah ursprünglich vor, die längste gemeinsame Anfangssequenz der beitragenden AS_PATHs zu behalten und die übrigen AS-Nummern in ein ungeordnetes AS_SET zu legen. Das Set bewahrte Beteiligung, aber keine Reihenfolge. Es machte zudem unklar, welcher AS rechts im Pfad als Ursprung gelten sollte.

RFC 6472 empfahl 2011, AS_SET und AS_CONFED_SET nicht mehr zu verwenden. RFC 9774 machte daraus im Mai 2025 eine Standardsanforderung. Ohne explizit konfigurierte Ausnahme, etwa für eine Übergangsphase, dürfen Speaker keine UPDATEs mit diesen Segmenten senden; empfangene Routen damit werden als withdrawn behandelt.

Aggregation bleibt möglich. Nun muss der Operator den Ursprung gezielt stabilisieren und den Informationsverlust offen kennzeichnen, statt ihn in einer mehrdeutigen Menge zu verwahren.

ATOMIC_AGGREGATE ist ein Eingeständnis

ATOMIC_AGGREGATE trägt den Typcode 6, ist well-known discretionary und hat die Wertlänge null. Es enthält weder die entfernten AS-Nummern noch Beitragsrouten, Hash, Zeitpunkt oder Signatur.

Werden beim Weglassen des AS_SET AS-Nummern entfernt, soll die Route das Attribut tragen. Ein Empfänger soll es bei der Weitergabe nicht löschen und darf aus der NLRI keine spezifischeren Anzeigen erzeugen. Er muss verstehen, dass der tatsächliche Weg ASes enthalten kann, die im AS_PATH fehlen.

Das Attribut beschreibt die Grenze des Wissens. Es zeigt, dass etwas fehlt, aber nicht was. Es authentifiziert keinen Akteur, autorisiert keinen Prefix und beweist keine Erreichbarkeit. Trägt schon ein Beitrag ATOMIC_AGGREGATE, muss das neue Aggregat es übernehmen. Eine weitere Zusammenfassung kann frühere Verluste nicht bereinigen.

Die minimale Aussage reduziert globale Koordination. Sie erhält dadurch keine Herrschaft über die ausgelassenen Tatsachen. Der Pfad ist kürzer, weil er weniger Belege enthält.

AGGREGATOR ist kein lückenloses Verwahrregister

AGGREGATOR, Typcode 7, ist optional transitive. Der aggregierende Speaker kann seine AS-Nummer und IP-Adresse, üblicherweise den BGP Identifier, eintragen. RFC 9774 verlangt es im consistent-brief-Modell zusammen mit ATOMIC_AGGREGATE.

Das eine Attribut meldet Verlust, das andere den letzten dargestellten Aggregationsakt. Keines listet Beiträge, Policy-Versionen, Genehmigungen oder alle früheren Aggregationen. AGGREGATOR-Werte der Ursprungsrouten werden nach RFC 4271 nicht einfach in das neue Aggregat kopiert.

Eine kryptografische Authentisierung ist es ebenfalls nicht. Der sichtbare Wert beweist weder Kontrolle über den Adressraum noch die richtige Policy. Bei vier Oktett langen ASNs schützt RFC 6793 die Nummerndarstellung: moderne Speaker verwenden ein acht Oktett langes AGGREGATOR; über alte Speaker können AS_TRANS und AS4_AGGREGATOR die nicht abbildbare Nummer erhalten. Glaubwürdigkeit entsteht daraus nicht.

RFC 7606 verwirft ein fehlerhaftes ATOMIC_AGGREGATE oder AGGREGATOR als Attribut, statt die gesamte Session zurückzusetzen. Das begrenzt Ausfälle, lässt aber Routen ohne Warnung oder Zuschreibung weiterleben. Der Fehler muss unabhängig vom grünen Sessionstatus protokolliert werden.

Der Ursprung darf kein Nebenprodukt der Verfügbarkeit sein

Brief aggregation behält nur die längste gemeinsame Anfangssequenz. Ändern sich die Beiträge, ändert sich diese Sequenz. Zwei disjunkte Pfade können ein leeres Ergebnis liefern; fällt einer aus, kann der AS des verbleibenden Pfades plötzlich als Ursprung erscheinen.

Dann entscheidet der Zufall einer Session über sichtbare Verantwortung. Für RPKI-ROV müssten zudem alle möglichen, schwankenden Ursprünge autorisiert werden.

Consistent brief aggregation schneidet den AS_PATH nach dem am weitesten rechts stehenden Vorkommen eines bewusst gewählten Origin AS ab. Das kann der aggregierende AS selbst sein. Das ROA des Aggregat-Prefix muss diesen AS autorisieren. Die Herkunft wird Policy statt Nebenwirkung.

Origin AS und das BGP-Attribut ORIGIN sind zu trennen. Ersterer wird aus dem rechten Ende des AS_PATH abgeleitet; ORIGIN beschreibt IGP, EGP oder INCOMPLETE und übernimmt bei der Aggregation den ungünstigsten Beitragswert. Ein Valid-Ergebnis bleibt ebenso begrenzt: Ein ROA autorisiert AS und Prefix, nicht ausgelassene Pfade, AGGREGATOR, NEXT_HOP, FIB oder Pakete.

Ohne AS_SET wandert die Schleifenkontrolle in die Policy

Ein beitragender AS konnte seine Nummer im AS_SET erkennen und ein zurückkehrendes Aggregat ablehnen. Nach Entfernung des Sets fehlt dieses automatische Gedächtnis.

RFC 9774 empfiehlt deshalb, das Aggregat nicht an beitragende ASes zu senden. Jeder Beitragende erhält stattdessen die anderen passenden more-specifics, wobei die von ihm selbst gelernte Route ausgeschlossen wird. Das ist eine nach Neighbor und Richtung differenzierte Policy.

Im Datenpfad gilt eine zweite Sicherung. RFC 4632 verlangt, dass der Erzeuger Pakete verwirft, die zum Aggregat, aber zu keiner erreichbaren spezifischeren Route passen. Üblicherweise dient eine Null- oder Discard-Route. Ohne sie könnte das Paket über Default oder Peer zurücklaufen und eine Schleife bilden.

Discard beweist Eindämmung, nicht Service. Ein dort endendes Paket zeigt zugleich, dass der Loop-Schutz funktioniert und das Ziel nicht erreichbar ist. Aggregate-Präsenz darf beide Aussagen nicht zu einer Verfügbarkeitszahl verschmelzen.

Die Belege müssen vor der Verdichtung entstehen

Ein öffentlicher Collector sieht nur die fertige Aussage. Er kennt keine vor der Policy abgelehnten Beiträge und kann die ausgelassenen ASes nicht aus dem leeren Attribut rekonstruieren.

Das lokale Register muss für jedes Aggregat Prefix, erforderliche und optionale Beiträge, Peer, pre-policy und accepted AS_PATH, berechnete gemeinsame Sequenz, gewählten Ursprung, ROA-Status, Policy-Version und ausführenden Speaker enthalten. Danach folgen Loc-RIB, Adj-RIB-Out vor und nach Policy, Attribute, NEXT_HOP, ORIGIN und die Unterdrückung der more-specifics.

RIB, Hardware-FIB und Paketproben schließen die Kette. Ein Ziel in jedem aktiven Beitrag muss funktionieren; ein Ziel in einer absichtlich fehlenden Komponente muss lokal verworfen werden. Vier Zustände brauchen getrennte Alarme: Beitrag vorhanden; Beitrag fehlt bei legitimem Aggregat; Aggregat fehlt; Aggregat vorhanden ohne Discard. Der letzte sieht öffentlich gesund aus und hat die Schleifensicherung verloren.

Canary und Rollback betreffen den gesamten Vertrag

Eine Änderung erfasst NLRI, Beiträge, Aktivierung, Ursprung, ROA, Verlustwarnung, Zuschreibung, Export, Suppression und Discard. Der Canary muss einen positiven und negativen Fall enthalten. Ein aktives Ziel wird geliefert; nach kontrolliertem Withdraw eines Testbeitrags endet dessen Ziel lokal und verlässt den aggregierenden AS nicht.

Gleichzeitig werden AS_PATH, ATOMIC_AGGREGATE, AGGREGATOR, ROV und more-specific-Anzeigen erfasst. Bei alten Speakergrenzen wird die AS4_AGGREGATOR-Rekonstruktion geprüft.

Rollback stellt Import, Suppression, Erzeugung, Ursprung, ROA, Filter und Null-Route gemeinsam wieder her. Nur die Konfigurationszeile zurückzustellen, ohne die notwendigen spezifischen Routen zurückzubringen, ist kein Rückweg zum alten Dienstzustand.