Zusammenfassung

  • maximum-prefix begrenzt die Menge von Routingzustand; es bewertet nicht die Gültigkeit der Route, die den Grenzwert überschreitet. Bei Sitzungsabbau kann eine zusätzliche Route alle über denselben Nachbarn gelernten Routen mitreißen.
  • Eine belastbare Regel benennt Nachbar und Adressfamilie, definiert empfangene oder akzeptierte Zählung, plant legitimes Wachstum, wählt eine verhältnismäßige Aktion und belegt die Folgen bis zu RIB, FIB und Paketen.

Eine kleine Überschreitung mit großer Wirkung

Die Konfiguration wirkt zunächst unauffällig: eine Ganzzahl, ein Warnwert, vielleicht ein Neustartintervall. Doch die Zahl ist mit einer Zustandsänderung verknüpft. Bewegt eine eingehende Route den Zähler von N auf N+1, kann der Empfänger die BGP-Verbindung schließen. Die vorherigen N Routen waren nicht Gegenstand einer neuen Inhaltsprüfung, verlieren aber dennoch ihre Sitzung.

Das unterscheidet maximum-prefix von einem Filter. Ein Filter beurteilt Präfix, Ursprung, Pfad, Community, Next Hop oder Geschäftsbeziehung. Das Limit beurteilt eine aggregierte Menge. Die auslösende Route kann technisch korrekt und autorisiert sein. Entscheidend ist allein, dass der Empfänger einer lokalen Kapazitätsgrenze die Befugnis zum Abbau der Beziehung gegeben hat.

Diese Befugnis kann sinnvoll sein. Eine versehentlich exportierte Volltabelle oder starke Deaggregation kann Speicher, Update-Verarbeitung und Konvergenz belasten. Kein Router muss unbegrenzt Zustand von einer Quelle aufnehmen. Der Schutz ist aber nur dann verantwortbar, wenn klar ist, welche Ressource er schützt und welche Erreichbarkeit seine Aktion gefährdet.

Der Spielraum des Protokolls

RFC 4271 erlaubt einem BGP-Sprecher eine lokal konfigurierte Obergrenze für die Zahl der von einem Nachbarn akzeptierten Adresspräfixe. An der Grenze kann er neue Präfixe verwerfen und die Verbindung aufrechterhalten oder die BGP-Verbindung beenden. Erfolgt die Beendigung wegen der Überschreitung, sendet er eine Cease-Nachricht.

RFC 4486 bezeichnet den Grund mit Cease-Subcode 1, Maximum Number of Prefixes Reached. Optional können AFI, SAFI und die vier Oktett große Obergrenze enthalten sein. Damit lässt sich eine Mengenentscheidung von administrativer Abschaltung, Kollision oder allgemeinem Ressourcenfehler unterscheiden.

Die Standards bestimmen keine universelle Zahl. Ein Kunde mit wenigen Netzen, ein Peer mit Teilsicht und ein Transit mit Volltabelle haben unterschiedliche berechtigte Mengen. Auch Plattformkapazität, Ausweichpfade und abhängiger Verkehr sind lokal. Die Entscheidungsfreiheit macht eine dokumentierte lokale Herleitung notwendig.

Menge ist kein Urteil über Berechtigung

Eine Überschreitung beweist weder Leck noch Angriff. Neue Kunden, eine Migration, zulässige Deaggregation in einer Störung oder geänderte Aggregation können die Zahl legitimer Routen erhöhen. Umgekehrt kann eine kleine Menge falsche Ursprünge, unzulässige Pfade oder unsichere Next Hops enthalten.

Präfix- und AS_PATH-Filter, RPKI-Ursprungsvalidierung, Next-Hop-Regeln und Communities bewerten Routeneigenschaften und Beziehungen. maximum-prefix bewertet Volumen. Beide Ansätze ergänzen sich, weil auch korrekte Routen Ressourcen verbrauchen. Sie beantworten jedoch verschiedene Fragen.

Als Sicherheitskontrolle ist das Limit nur präzise, wenn die bedrohte Ressource genannt wird: Speicher des Routingprozesses, Konvergenzzeit, Update-Kapazität oder Stabilität des Gesamtsystems. Es authentifiziert keine Absicht, erklärt die letzte Route nicht für schädlich und bescheinigt dem Bestand unterhalb der Grenze keine Sicherheit.

Der Zählpunkt verändert die Grenze

Gleiche Zahlen können auf zwei Plattformen unterschiedliche Zustände erfassen.

Die BGP-Dokumentation von FRRouting beschreibt maximum-prefix standardmäßig als Zähler akzeptierter Präfixe. Mit force werden alle empfangenen Präfixe einschließlich der durch Eingangsrichtlinien verworfenen gezählt; dafür muss der relevante Eingangszustand gespeichert werden. FRRouting weist außerdem darauf hin, dass die Zerstörung einer Sitzung wesentlich destruktiver ist als die Ablehnung unerwünschter Routen.

Junos trennt die Absichten. prefix-limit bezieht sich auf empfangene Präfixe, accepted-prefix-limit auf durch Policy akzeptierte. Dokumentiert sind Sitzungsabbau, Verwerfen und Verbergen des Überschusses, jeweils mit anderen Restzuständen und Wiederherstellungswegen.

Vor der Policy zu zählen macht sichtbar, welche Last der Nachbar zu liefern versucht. So lässt sich eine Volltabelle erkennen, obwohl Filter fast alles ablehnen würden. Zugleich kann Zustand zur Schließung führen, der nie zur nutzbaren Route geworden wäre. Nach der Policy zu zählen entspricht eher dem zugelassenen Bestand, kann aber die rohe Eingangsbelastung verdecken.

Zusätzlich sind Präfix und Pfad nicht immer dieselbe Einheit. ADD-PATH, VPN-Familien und interne Datenstrukturen können mehrere Pfade für ein Ziel speichern. Die Semantik der tatsächlich eingesetzten Version muss deshalb Teil der Regel sein. Ein kopierter Zahlenwert ohne kopierte Definition ist keine portable Kontrolle.

Die Aktion bestimmt die Fehlerform

Warnen erhält Sitzung und Routen. Es schafft Reaktionszeit, begrenzt aber kein Wachstum. Ohne zuverlässige Zustellung, Eigentümer und ausreichende Restkapazität dokumentiert die Warnung nur die Annäherung an den Ausfall.

Überschuss verwerfen behält früher zugelassenen Zustand und die Sitzung. Das vermeidet den vollständigen Rückzug, erzeugt jedoch eine unvollständige Sicht, die von der Reihenfolge der Updates abhängen kann. Sinkt der Zähler später, kehren verworfene Routen möglicherweise erst nach Route Refresh oder neuer Auswertung zurück.

Überschuss verbergen hält Informationen von der normalen Auswahl fern. Das kann die Rückkehr erleichtern, verbraucht aber weiterhin Ressourcen. Sollte Speicher das Schutzziel sein, muss die reale Implementierung geprüft werden.

Sitzung abbauen stoppt die Quelle eindeutig. Gleichzeitig verschwinden alle Routen, deren einziger brauchbarer Pfad diese Sitzung war. Verkehr wechselt auf Alternativen, deren Kapazität geringer sein kann; andere Ziele verlieren jede Erreichbarkeit.

Herstellerbegriffe garantieren keinen identischen Endzustand. Cisco dokumentiert Warnprozentsatz, standardmäßigen Sitzungsabbau, Warnmodus und optionalen zeitgesteuerten Neustart. Arista EOS beschreibt die Deaktivierung des Peerings sowie eine Warnaktion, die die Sitzung erhalten und nachfolgende Routen verwerfen kann. Zu vergleichen ist der verbleibende Routingzustand, nicht die Bezeichnung.

Die Beziehung liefert den Maßstab

RFC 7454 empfiehlt beziehungsspezifische Grenzen. Bei einem Peer mit begrenztem erwarteten Bestand kann eine Zahl unterhalb der Internet-Volltabelle deren versehentlichen Export erkennen. Ein Upstream, der bewusst Vollrouting liefert, benötigt eine Grenze oberhalb der erwarteten Tabelle, aber innerhalb der sicheren Empfängerkapazität.

Die Herleitung beginnt mit dem legitimen Routensatz der Beziehung. Hinzu kommen beobachtete Schwankung, belastbares Wachstum, neue Kunden, zulässige Deaggregation und Migrationen. Diese Prognose wird gegen Plattformkapazität und Kosten der gewählten Aktion geprüft. Der Wert erhält einen Eigentümer, ein Prüfdatum und einen Weg für dringende Änderungen.

RFC 4778 empfiehlt die Abstimmung der erwarteten Präfixzahl und Puffer für legitime Ausschläge. Eine einseitig unbekannte Grenze kann genehmigtes Wachstum in eine Unterbrechung verwandeln. RFC 7454 verlangt regelmäßige Prüfung, weil Routenpopulationen nicht statisch sind.

Reserve lässt sich besser als Zeit und Varianz ausdrücken als durch einen fremden Prozentsatz. Derselbe Anteil kann bei einer stabilen Beziehung Jahre, bei einer Integration Wochen bedeuten. Zu wenig Reserve macht den Schutz spröde; zu viel macht ihn wirkungslos. Ziel ist ausreichende Entscheidungszeit innerhalb realer Kapazität.

Wiederanlauf braucht eine geänderte Bedingung

Ein automatisches Neustartintervall verkürzt die Störung, wenn der Überschuss bereits beseitigt wurde. Bleibt das gesendete Set gleich, automatisiert es eine Schleife: Aufbau, Überschreitung, Abbau, Warten, erneuter Aufbau.

Verstrichene Zeit ist kein Korrekturbeleg. Ein begründeter Wiederanlauf stützt sich auf bestätigten Rückzug, reparierte Exportpolicy, genehmigte Grenzerhöhung oder neue Kapazität. Ein manueller Clear ohne diese Änderung ersetzt nur den Timer durch einen Menschen.

RFC 8538 schlägt vor, maximum-prefix Cease im Kontext von Graceful Restart als Hard Reset zu behandeln. Eine bewusst ausgeführte Mengenregel sollte nicht durch stilles Beibehalten veralteter Routen wie ein gewöhnlicher Neustart erscheinen.

Vom Zähler bis zum Paket

Der Nachweis beginnt mit effektiver Konfiguration je Nachbar und AFI/SAFI, einschließlich Vererbung, Warnstufe und Aktion. Hinzu kommen Softwareversion und verbindliche Definition von empfangen gegenüber akzeptiert sowie Präfix gegenüber Pfad.

Während der Ausführung werden letztes zugelassenes Update, Zählerübergang, Cease-Code und -Subcode, AFI/SAFI/Grenzwert, Sitzungszustand, Timer und möglicherweise gedrosselte Logs festgehalten. Zurückgezogene, verworfene, verborgene und erhaltene Routen sind getrennt zu erfassen.

Danach folgt die Erreichbarkeit. Welche Ziele wechselten ihren besten Pfad? Waren Alternativen in der RIB und wurden sie in die FIB eingebaut? Reichte die Kapazität der übernehmenden Verbindungen? Erreichen Paketproben kritische Zielklassen? Gleiche Gesamtzahlen vor und nach der Erholung beweisen keine identischen Präfixe, Attribute oder Next Hops.

Das Limit erfüllt seinen Zweck erst, wenn die benannte Ressource im sicheren Ziel bleibt und der resultierende Dienstzustand dem genehmigten Kompromiss entspricht. Der Zähler allein beweist beides nicht.

Quellen