Zusammenfassung

  • 0.0.0.0/0 und ::/0 legen kein Zielbit fest, passen aber auf jede Adresse, die nach Longest Prefix Match übrig bleibt. Ihr tatsächlicher Geltungsbereich wächst und schrumpft mit allen spezifischeren Routen.
  • Erzeugung, Export, Empfang, Import, Auswahl, FIB-Programmierung und Paketzustellung sind getrennte Zustände. Eine Established Session beweist nur den Control Channel zum Nachbarn.
  • Die Vollmacht des letzten Auswegs braucht eine explizite Beziehung, eine service-nahe Bedingung, lokale Ablehnungsrechte, echte Default-Canaries und einen gemessenen Weg von Evidenzverlust über Withdrawal bis Rollback.

AS 64580 bezieht von AS 64520 ausgewählte regionale Präfixe und eine IPv4 Default Route. Eine Full Table würde mehr Hardware- und Policy-Aufwand verursachen, deshalb überlässt der Kunde dem Provider den Rest. Um 09:41 verliert AS 64520 den Transport zum wichtigsten Upstream. Kundenlink und EBGP Session bleiben intakt; einige regionale Routen funktionieren über einen zweiten Weg.

Die Default wurde ohne Bedingung erzeugt. AS 64520 sendet 0.0.0.0/0 weiter, AS 64580 hält denselben Next Hop als Best Path und das Hardware-FIB ändert sich nicht. Probes zum Provider-Loopback, einem regionalen Resolver und zwei durch More-Specifics abgedeckten Diensten bleiben erfolgreich. Andere Ziele folgen /0 und enden im Provider vor dem ausgefallenen Egress.

Das Beispiel ist synthetisch, die Mechanik nicht. Eine BGP Session verbindet zwei Speaker; sie testet nicht jedes Ziel hinter ihnen. Ein gültiges UPDATE belegt die Ankündigung. Es belegt nicht, dass die betriebliche Voraussetzung der Ankündigung fortbesteht.

Null Zielbits, veränderlicher Rest

RFC 1812 setzt die entscheidende Reihenfolge: Von allen passenden Routen bleibt zuerst die mit der längsten Präfixlänge. Ein /24 schlägt /0 für seinen Block. Erst wenn keine spezifischere Route zur Verfügung steht, wird die Default zum Kandidaten.

Weil die Präfixlänge null ist, passt 0.0.0.0/0 auf jede IPv4-Adresse; ::/0 erfüllt dieselbe Rolle für IPv6. Die tatsächlich übernommene Zielmenge steht aber nicht im Route Object. Erscheint 198.51.100.0/24, verlässt dieser Block den Default-Bereich. Wird das /24 withdrawn, fällt er sofort zurück.

Damit kann die operative Vollmacht von /0 wachsen, ohne dass sich ihr Hash, AS_PATH, NEXT_HOP oder Alter ändert. Ein Dashboard, das nur die Default selbst beobachtet, sieht nicht, welche Ziele durch Änderungen der übrigen Tabelle neu unter sie geraten.

RFC 4098 trennt Default Route, default-free table und full default-free table. Nur eine Default zu empfangen spart Zustand, konzentriert aber die externe Zielentscheidung beim Provider. Eine Full Table verschiebt mehr Information und Wahl zum Customer, kostet jedoch Speicher, CPU und Betrieb. Ausgewählte Specifics plus Default bilden einen dritten Vertrag. Diese Modelle liefern unterschiedliche Evidenz.

Explizite Konfiguration ist eine Zuständigkeitsgrenze

RFC 4632 verlangt, dass Implementierungen das degenerierte Präfix 0.0.0.0/0 akzeptieren. Zugleich soll seine inter-domain Ankündigung nur nach expliziter Konfiguration erfolgen, nie als nicht konfigurierte Default-Option. Die Gültigkeit der Route ist also keine automatische Erlaubnis zur Weitergabe.

RFC 7454 ergänzt die Beziehungslogik. Außerhalb bestimmter Customer/Provider-Konfigurationen sind IPv4- und IPv6-Defaults normalerweise weder zur Annahme noch zur Ankündigung vorgesehen; Filterung wird empfohlen. Ein Customer darf dagegen legitim nur eine Default statt der Full Table anfordern.

Die Erlaubnis ist nachbar-, familien- und instanzspezifisch. Ein Provider darf sie nicht durch Peer-Group-Vererbung an Peer, Upstream, Route Server oder fremden Tenant ausweiten. Zustimmung für IPv4 bedeutet nicht Zustimmung für IPv6. Eine VRF ist nicht die nächste.

Der Sender begrenzt Export auf die genehmigten Customers. Der Empfänger akzeptiert exact /0 nur vom autorisierten Rollenpartner. Beide Seiten behalten Kontrolle, sodass eine Fehlkonfiguration nicht sofort zur gemeinsamen Fehlentscheidung wird.

RFC 8212 verhindert, dass fehlende EBGP Import/Export Policy stillschweigend zu Erlaubnis wird. Eine vorhandene Policy kann trotzdem falsch sein. Sie kann den falschen Peer einschließen oder eine belanglose Health-Bedingung akzeptieren. Explizit ist nicht automatisch richtig.

Hinter „Default vorhanden“ liegen sieben Zustände

Zuerst erzeugt der Advertiser einen Kandidaten: synthetisch pro Neighbor, static, generated oder BGP-gelernt. Danach entscheidet Outbound Policy über den Export. Der Receiver erhält das UPDATE, wendet Import Policy an, vergleicht Alternativen, wählt eine Route in der RIB und programmiert den Next Hop in die FIB. Erst danach versucht ein Paket die Zustellung.

Jeder Übergang kann separat scheitern. Der Kandidat existiert und wird gefiltert. Das UPDATE kommt an und wird verworfen. Die Route wird akzeptiert und verliert gegen eine bevorzugte Default. Die RIB ändert sich, das Hardware-FIB folgt verspätet. Die FIB zeigt korrekt auf einen aktiven Link, doch der Nachbar hat keinen weiteren Weg.

AS_PATH beschreibt den Weg der /0-Ankündigung, nicht die realen AS-Wege zu allen Restzielen. NEXT_HOP beweist lokale Rekursion, nicht Zustellung hinter dem Nachbarn. LOCAL_PREF drückt eine lokale Entscheidung aus, keine Live-Messung der Provider-Gesundheit.

RFC 4271 erlaubt den Withdrawal von /0 innerhalb der bestehenden Session. Wenn nur die Last-Resort-Zusage ausfällt, muss nicht der gesamte Peer gecleart werden. Ein Session Reset vergrößert den Ausfall und beseitigt Beweise über andere Routen.

Vendor-Verhalten ist Teil des Vertrags

Aktuelle Cisco-IOS-Dokumentation beschreibt neighbor ... default-originate pro Neighbor und verlangt keine lokale 0.0.0.0-Route. Bei Nexus kann die künstliche Default ohne Eintrag in der Routing Table und ohne eigenes Objekt im lokalen BGP RIB gesendet werden. Eine optionale Route Map kann die Erzeugung an eine passende installierte Route binden.

FRRouting kündigt 0.0.0.0/0 standardmäßig auch dann nicht an, wenn die Route in der Tabelle steht. Der Operator aktiviert neighbor ... default-originate ausdrücklich und kann eine Route Map ergänzen.

Junos nutzt Active Route und Routing Policy. Static, Aggregate und Generated Routes gelangen durch explizite Export Policy in BGP. Bedingte Beispiele verbinden den Aktivzustand der Route mit der Exportentscheidung.

Diese Unterschiede bestimmen das Failure-Verhalten. Das Löschen einer lokalen Static /0 kann eine unbedingte synthetische Ankündigung unberührt lassen. In einem anderen Design ist der Verlust der aktiven Generated Route genau der Withdrawal-Trigger. Runbooks lassen sich nicht anhand ähnlicher Command-Namen portieren.

Die laufende Release muss getestet werden: Local RIB, BGP RIB, Advertised Routes und Receiver View erfassen. Den echten Support entfernen, während die Customer Session bleibt. Reevaluation, Withdrawal, alternative Auswahl, FIB und Pakete getrennt messen. Nach Wiederherstellung denselben Pfad rückwärts belegen.

Eine Bedingung beweist nur ihren Gegenstand

Conditional Origination ist nur dann sicherer, wenn das Predicate dem versprochenen Service nahekommt.

Ein erreichbarer Provider-Loopback beweist diesen Loopback. Interface Up beweist den lokalen Carrier. Eine aktive Static Route kann bloß Konfiguration oder Rekursion beweisen. Ein Table Count misst Menge, nicht den gewählten Egress. BFD belegt Kontinuität zu einem bestimmten Peer. Kein Einzelsignal deckt die dynamische Restmenge von /0 ab.

Darum beginnt das Design mit der Service-Definition. Bedeutet die Default breiten öffentlichen Transit, müssen Canaries denselben Egress wie Customer Traffic verwenden und unabhängige Netze sowie mehrere Abhängigkeiten abdecken. Bedeutet sie nur einen privaten WAN-Ausgang, bleibt der Test in diesem Scope.

Auch mehrere Signale lösen nicht jede Unsicherheit. „Alle müssen funktionieren“ kann den letzten brauchbaren Weg wegen eines einzelnen Probe-Ziels entfernen. „Eines genügt“ kann einen großflächigen Blackhole erhalten, solange eine kleine Insel erreichbar bleibt. Quorum, Hysterese, Hold-down und Recovery Threshold verteilen Kosten zwischen frühem und spätem Withdrawal.

Die State Machine braucht Historie: Eingaben, kombinierte Entscheidung, Predicate Failure, UPDATE Withdrawal, Best-Path-Wechsel, FIB-Programmierung und Packet Recovery. Ein gesunder Snapshot nach dem Vorfall kann diese Sequenz nicht ersetzen.

More-Specifics erzeugen Blindheit in beide Richtungen

Im Eröffnungsszenario bestehen mehrere Tests, weil ihre Ziele über More-Specifics laufen. Sie berühren die defekte Default nicht. Ein Monitoring-Set, das sich auf regionale Dienste oder populäre spezifische Präfixe konzentriert, kann eine kleine erreichbare Insel als Gesamtgesundheit melden.

Umgekehrt rettet eine gesunde Default kein Ziel hinter einem kaputten /24. Longest Prefix Match wählt das Specific zuerst. Stale Route, falscher Next Hop oder Leak kann einen Dienst isoliert zerstören, während der Rest über /0 funktioniert.

Jede Canary-Beobachtung muss Winning Prefix, RIB Entry, FIB Next Hop und Egress speichern. Ohne diese Zuordnung beweist eine erfolgreiche Anwendung nur sich selbst. Wenn ein Specific erscheint oder verschwindet, wechselt die Testklasse, obwohl die Default unverändert bleibt.

Zwei Defaults beweisen auch keine unabhängigen Schicksale. Verschiedene Router können Metrofaser, höheren Transit, Controller oder Health-Ziel teilen. Das Abschalten einer Session testet Session-Redundanz, nicht den Fall eines ausgefallenen Upstreams bei weiterlaufender Customer Session.

Ein Leak delegiert den unbekannten Rest ungefragt

Eine Default vom falschen Relationship übergibt diesem Neighbor jede lokal nicht präziser bekannte Adresse. Bei einer Full Table kann der Rest klein sein. Bei einem Stub Customer kann fast der gesamte externe Traffic betroffen sein.

Export Filter nennen nur berechtigte Customers und sperren Peers, Providers, Route Servers und andere Tenants. Import Filter akzeptieren exact zero-length Prefix ausschließlich vom richtigen Neighbor in der richtigen AFI/SAFI und Routing Instance. Peer-Group-Vererbung und Dual-Stack-Automation werden am Ergebnis geprüft.

Configuration zeigt Intention. Adj-RIB-Out zeigt, was der Speaker tatsächlich versendet. Pre-Policy und Accepted View des Receivers trennen Empfang und Annahme. Public Collectors können spätere Ausbreitung entdecken, beobachten aber nicht jede Kante. Keine Sichtung ist kein globaler Negativbeweis.

Die Evidenzkette beginnt bei der Zusage und endet beim Paket

Für jede Default-Beziehung wird zunächst der Service benannt: öffentlicher Internet-Transit, ausgewählte externe Dienste, privater WAN-Ausgang oder temporärer Fallback. Advertiser, Receiver, Role, Familie, VRF, Approval Owner und Withdrawal Owner werden festgehalten.

Danach Generation Model, Predicate, Inputs, Quorum, Timer, Hysterese und Failure Action. Im Runtime-Ledger stehen Candidate, Post-Policy Advertisement, Pre-Policy Receipt, Accepted Route, Selection Reason, Rekursion, Hardware-FIB und Alternativen mit Timestamp.

Canaries starten beim Receiver, wo Vertrauen zu Forwarding wird. Einige Ziele dürfen nur über /0 erreichbar sein; andere werden bewusst von Specifics abgedeckt. Zielnetze müssen echte Unabhängigkeit bieten, und der beobachtete Egress gehört zum Ergebnis.

Der Failure Drill lässt die Customer Session stehen und entfernt den Upstream, der die Zusage trägt. Predicate Failure, Withdrawal, alternative RIB, FIB und Recovery werden getrennt gemessen. Ohne Alternative muss der Receiver aufhören, Pakete in den toten Providerweg zu senden.

Rollback umfasst Generation, Condition, Timer, Neighbor Scope, Attribute, Import Preference und Monitoring. Er endet erst, wenn beobachteter Zustand und Pakete dem vorherigen Vertrag entsprechen.

Dünne Koordination braucht ein starkes lokales Ende

Eine Default Route kann ausgezeichnete minimale Koordination sein. Der Provider teilt keine vollständige Zielkarte; der Customer entscheidet lokal über den Fallback. Beide Netze behalten ihre eigene Policy, ohne zentrale Instanz.

Die geringe Informationsmenge verbietet gerade eine übergroße Interpretation. Die Bezeichnung Provider ist kein Data-Plane-Zertifikat. Ein UPDATE ist kein SLA. Frühere Annahme beseitigt nicht das spätere Ablehnungsrecht.

Running-Code Primacy ordnet die Beweise: Vertrag beschreibt Erwartung, Konfiguration Absicht, UPDATE Versand, RIB/FIB lokale Handlung und Paket das laufende Ergebnis. Jede Ebene ist notwendig; keine darf die nächste vortäuschen.