Zusammenfassung

  • BGP behandelt die lokale ASN im AS_PATH gewöhnlich als Schleifenbeweis. allowas-in ändert das Urteil des Empfängers; as-override ändert den Pfad vor diesem Urteil.
  • Beide Verfahren können Standorte mit gemeinsamer ASN verbinden, authentisieren aber kein Präfix und beweisen kein Forwarding. Route Target, Site of Origin und Präfixberechtigung sind getrennte Kontrollen.
  • Eine belastbare Ausnahme bewahrt Pfade vor und nach der Mutation, begrenzt Nachbar, AFI/SAFI und Vorkommen, prüft Standort- und Präfixschutz und folgt der Route bis FIB, Paket und Rollback.

Die Ablehnung war richtig

Ein erklärendes Beispiel, kein gemeldeter Vorfall: Standort A und B nutzen hinter einem Provider dieselbe Kunden-ASN. A kündigt ein Präfix an. Der Provider transportiert es nach B, dessen Router die eigene ASN im AS_PATH erkennt und die Route ablehnt. Die Session steht, der PE kennt die Route, doch B verwendet sie nicht.

Das ist die normale Sicherheitsentscheidung. RFC 4271 schließt eine Route mit lokaler ASN aus dem Decision Process aus und stellt einen Betrieb, der die eigene ASN akzeptiert, ausdrücklich außerhalb der Spezifikation. Der Pfad warnt: Diese Information hat deine Routing-Domäne bereits durchlaufen. RFC 4271

Zwei Lösungen werden vorgeschlagen. Der Kunde toleriert am Empfang eine begrenzte Zahl eigener ASN-Vorkommen, allowas-in beziehungsweise allow-own-as. Oder der Provider ersetzt vor der Ankündigung an den Kunden dessen ASN-Vorkommen, as-override.

Sie sind nicht gleichwertig. Die erste Methode bewahrt den Pfad und ändert die Annahmeregel. Die zweite ändert den Beweis, sodass die Standardregel nicht mehr greift. Einmal liegt die Ausnahme beim Empfänger, einmal die Verwahrung des Pfadverlaufs beim Sender.

AS_PATH ist keine Signatur

AS_PATH hilft bei Schleifenerkennung und Auswahl, signiert aber keinen physischen Weg. RFC 4272 erklärt, dass ein Speaker vor allem die eigene ASN prüft, nicht jede behauptete Transition; falsche oder verkürzte Pfade können Auswahl und Schleifen beeinflussen. Der Beweis ist gerade deshalb wertvoll, weil er lokal interpretiert und verändert werden kann. RFC 4272

allowas-in verändert die Zulassung. Implementierungen können Vorkommenszahl, Nachbar, Gruppe, Adressfamilie, Origin-Bedingung oder Route-Map begrenzen. FRRouting dokumentiert mehrere Varianten. RFC 7938 beschreibt die verbreitete, aber nicht standardisierte Funktion für eine Rechenzentrums-Clos mit wiederverwendeten privaten ASNs. Diese Sicherheit ist topologiespezifisch und liefert keinen universellen Grenzwert. FRRouting-BGP-Dokumentation, RFC 7938

as-override verändert den Export. FRRouting und Junos dokumentieren den Ersatz aller zur Peer-ASN passenden Vorkommen durch die lokale Provider-ASN. Junos weist darauf hin, dass auch wiederholtes Kunden-Prepending ersetzt wird. Die Länge kann ähnlich bleiben, während die Identität hinter diesen Positionen verloren geht. FRRouting-BGP-Dokumentation, Junos as-override

Darum reicht ein Screenshot nach der Änderung nicht. Der Vorgang muss die ursprüngliche CE-Ankündigung, den PE-Empfang, den beabsichtigten Export vor der Mutation, den tatsächlichen Export und die angenommene Ansicht am entfernten CE aufbewahren. Sonst sind erlaubte Umschreibung und unbeabsichtigter Verlust nicht unterscheidbar.

Mitgliedschaft, Standortursprung und Berechtigung

In RFC 4364 entscheidet Route Target, welche VPN-Routen importfähig sind. Site of Origin kennzeichnet den Lernstandort und verhindert bei korrekter Anwendung die Rückgabe an einen CE dieses Standorts. Präfixberechtigung fragt separat, ob dieser Anschluss das Netz überhaupt annoncieren durfte. RFC 4364

Ein RT ersetzt keinen verlorenen Self-AS-Nachweis; es kann eine zirkulierende Route korrekt an alle vorgesehenen Mitglieder verteilen. SoO liegt näher am Standort-Loop, wirkt aber nur, wenn alle relevanten Anschlüsse es konsistent setzen und prüfen. Es authentisiert weder Kunde noch Präfix.

Die aktuelle IOS-XR-Dokumentation warnt im beschriebenen L3VPN-Ablauf, dass AS Override Informationen verliert und Schleifen verursachen kann, und setzt SoO als Ausgleich ein. Das ist ein Nachweis für dieses Design, keine automatische Garantie für jede Topologie. Cisco-IOS-XR-BGP-Dokumentation

RFC 9835 modelliert as-override, allow-own-as, dessen Maximum und Site of Origin ebenfalls getrennt. Ein YANG-Modell garantiert keine identische Produktsemantik, widerlegt aber die Vorstellung eines einzigen Schalters. RFC 9835

Die Route lückenlos verfolgen

Zuerst wird der strikte Zustand gesichert: Adj-RIB-Out von A, Adj-RIB-In des PE, Pfad am entfernten PE vor Export und die abgelehnte Ansicht samt Self-AS-Grund bei B. RD und RT eines VPN werden als Serviceattribute notiert, nicht als Ursprungsbeweis.

Bei der Empfängerausnahme zählt die effektive Policy nach Gruppenvererbung: genauer Nachbar, AFI/SAFI, erlaubte Zahl, mögliche Origin-Beschränkung und Präfix- oder Route-Map-Regel. Eine Kontrollroute außerhalb des Umfangs muss abgelehnt bleiben.

Bei der Senderumschreibung wird jedes AS_SEQUENCE-Element vor und nach Export verglichen. Wiederholtes Prepending kann vollständig ersetzt werden. Das Original gehört außerhalb des veränderlichen Routers archiviert, weil die neue Ankündigung die gelöschte Identität nicht wiederherstellt.

Danach werden Präfixberechtigung, RT, SoO und parallele Anschlüsse, Reflektoren oder Redistribution getrennt geprüft. RFC 6368 beschreibt Nachteile von ASN-Remapping und Accept-own-AS, wenn der Kunde BGP auch intern für weitere Zwecke nutzt; die Wirkung endet nicht zwingend an PE–CE. RFC 6368

Annahme ist noch keine Zustellung. Loc-RIB-Auswahl, Rekursion, FIB beziehungsweise Hardware und kontrollierter Verkehr in beide Richtungen werden geprüft. Ein sicherer Fehlerfall soll unerwarteten Wiedereintritt zeigen, ohne gefährliche Zirkulation zu erzeugen. RFC 7705 zeigt im Migrationskontext, dass Pfadmanipulation eine Route passieren lassen kann, die Self-AS sonst stoppt. Das spezifiziert nicht as-override, erklärt aber die unzureichende Erfolgsmeldung „Route sichtbar“. RFC 7705

Rollback muss den Schleifenschutz wiederherstellen. Der Self-AS-Canary wird dort erneut abgelehnt, wo es vorgesehen ist; erlaubte Erreichbarkeit, FIB und Pakete kehren zum Entwurf zurück. Nur eine Zeile zu löschen belegt keine wiedergewonnene Eigenschaft.