BGP Full Table oder Default Route: Was braucht mein Router?
Default, vollständige Tabellen oder Teilrouten plus Default: So wählen Sie den passenden Routenempfang für Single-Homing und mehrere Upstreams.
Eine Default-Route genügt oft, wenn ein Netz nur einen Upstream nutzt oder bei zwei Upstreams lediglich einen allgemeinen Haupt- und Ersatzweg braucht. Vollständige BGP-Tabellen werden sinnvoll, wenn der eigene Router für viele einzelne Zielpräfixe zwischen mehreren Ausgängen wählen soll. Dazwischen liegt ein häufig brauchbares Modell: ausgewählte Routen für gezielte Entscheidungen plus Default-Route für den Rest. Die richtige Wahl folgt aus der gewünschten Routing-Policy – nicht aus der Portgeschwindigkeit.
Die drei Modelle auf einen Blick
| Modell | Der Router erhält | Typischer Nutzen | Grenze |
|---|---|---|---|
| Nur Default | 0.0.0.0/0 und/oder ::/0 | Einfacher Standardweg oder Primary/Backup | Keine eigene Pfadwahl je Internet-Ziel |
| Ausgewählte Routen + Default | Definierte Präfixgruppen und einen Standardweg | Gezielte Entscheidungen mit begrenztem Tabellenumfang | Nur für gelieferte Detailrouten ist eine differenzierte Wahl möglich |
| Vollständige Tabellen | Die vom Upstream gelieferte globale IPv4- und/oder IPv6-Sicht | Pfadwahl je Zielpräfix bei mehreren Upstreams | Mehr Anforderungen an Hardware, Filter, Betrieb und Tests |
RFC 7454 beschreibt sowohl den einfachen Fall, in dem ein Kunde nur die Default-Route erhält, als auch vollständige Tabellen und die Kombination aus Full Table plus Default. Daraus folgt keine universelle Empfehlung: Der vereinbarte Feed und die Importfilter müssen zum tatsächlichen Zweck passen.
RFC 7454: Default-, Full-Table- und Filtermodelle
Was eine Default-Route tatsächlich macht
Die IPv4-Default-Route 0.0.0.0/0 beziehungsweise die IPv6-Default-Route ::/0 passt auf jedes Ziel, für das keine spezifischere Route vorhanden ist. RFC 4098 grenzt sie von einer vollständigen Default-Free-Tabelle ab. Die normale Longest-Prefix-Match-Weiterleitung bleibt erhalten: Eine vorhandene spezifischere Route gewinnt vor dem Default.
RFC 4098: Begriffe Default Route und Full Default-Free Table
Mit je einer BGP-Default-Route von zwei Upstreams kann die eigene Policy einen bevorzugten und einen nachrangigen Ausgang festlegen. Solange beide Wege verfügbar sind, folgt jedoch grundsätzlich der gesamte Verkehr ohne spezifischere Route derselben allgemeinen Entscheidung. Ein Betreiber kann damit gut Primary/Backup abbilden, aber nicht allein anhand der Internet-Zielpräfixe Last oder Qualität differenzieren.
BGP-Default ist nicht dasselbe wie statischer Default
Schließt eine BGP-Session, entfernt BGP gemäß RFC 4271 die darüber gelernten Routen – also auch einen dynamisch gelernten Default. Eine unabhängig konfigurierte statische Default-Route folgt anderen Bedingungen. In beiden Fällen muss ein Test prüfen, ob der verbleibende Next Hop nicht nur im Router vorhanden, sondern der gewünschte Dienst darüber tatsächlich erreichbar ist.
Was eine Full Table zusätzlich ermöglicht
Mit vollständigen Tabellen sieht der Router für viele Zielpräfixe die über jeden Upstream angebotenen Wege und deren BGP-Attribute. Die lokale Import-Policy bewertet diese Kandidaten; der BGP-Entscheidungsprozess wählt anschließend einen Pfad für die lokale Routingtabelle. Damit lassen sich ausgehende Wege je Präfix oder Präfixgruppe unterschiedlich behandeln, statt nur einen Standardausgang für fast alles festzulegen.
RFC 4271: BGP-Updates, RIBs und Entscheidungsprozess
Der Empfang einer Full Table steuert nicht automatisch den eingehenden Verkehr. Fremde Netze entscheiden ihren Weg zu Ihren Präfixen anhand ihrer eigenen Sicht und Policy. Dafür sind Ihre Ankündigungen, deren Attribute und die Möglichkeiten der Upstreams relevant. Ebenso macht eine große Tabelle einen Anschluss nicht schneller und ersetzt weder physische Redundanz noch DDoS-Schutz.
Illustratives Beispiel mit zwei Upstreams
Das folgende Szenario verwendet ausschließlich Dokumentationswerte: Das Kundennetz AS64496 ist mit Upstream A (AS64497) und Upstream B (AS64498) verbunden. 203.0.113.0/24 steht nur beispielhaft für ein Internet-Ziel. Es handelt sich weder um eine reale Route noch um eine AS51202-Policy.
| Feed | Allgemeine Policy | Ergebnis für 203.0.113.0/24 |
|---|---|---|
| Zwei Default-Routen | A wird bevorzugt, B ist Backup | Das Beispielziel folgt wie fast alle Ziele dem Default über A |
| Ausgewählte Route + Default | A bleibt Default; die Detailroute wird über B bevorzugt | Nur das gelieferte Beispielpräfix kann gezielt über B gehen |
| Zwei Full Tables | Allgemein A; für definierte Zielgruppen B bevorzugen | Der Router kann die Kandidaten beider Upstreams vergleichen und die lokale Policy anwenden |
Dieses Beispiel zeigt nur die ausgehende Wahl. Es sagt nichts darüber aus, über welchen Upstream Antworten eintreffen. Stateful Firewalls, NAT, DDoS-Mitigation und Kapazitätsplanung müssen deshalb auch asymmetrische Hin- und Rückwege berücksichtigen.
IPv4 und IPv6 getrennt entscheiden
Multiprotocol BGP kennzeichnet Routinginformationen durch Adressfamilie und Subsequent Address Family. RFC 4760 ermöglicht so unter anderem den Austausch von IPv6-Routen. In der Praxis ist daher für jede aktivierte Adressfamilie festzulegen, ob Default, ausgewählte Routen oder vollständige Tabellen gewünscht sind. Ein vollständiger IPv4-Feed sagt nichts über den IPv6-Routenempfang aus; auch Präfixlimit, Filter und Abnahme müssen je Familie passen.
RFC 4760: Multiprotocol BGP und Adressfamilien
Routerkapazität bedeutet mehr als eine Zahl im Datenblatt
- RIB und FIB: Der Router muss empfangene Kandidaten, den gewählten Pfad und die tatsächlich programmierte Weiterleitung in den relevanten Tabellen verarbeiten können.
- Mehrere Feeds: Zwei Upstreams liefern mehrere Wege zu denselben Zielen. Der Speicherbedarf ist deshalb nicht allein aus der Anzahl eindeutiger Präfixe abzuleiten.
- Adressfamilien: IPv4 und IPv6 benötigen jeweils Kapazität; zusätzliche Dienste oder Tabellen können dieselben Hardware-Ressourcen beanspruchen.
- Updates und Konvergenz: Nicht nur der stabile Zustand zählt. Neustart, Route Refresh, viele Änderungen und das Umschalten nach einem Ausfall müssen innerhalb akzeptabler Betriebsgrenzen funktionieren.
- Präfixlimit: Ein Max-Prefix-Limit schützt vor unerwartet großen Feeds, braucht aber ausreichend Reserve für Wachstum und darf den Anschluss nicht durch einen zu engen Grenzwert selbst abschalten.
- Beobachtung: Speicher, CPU, FIB-Auslastung, verworfene Updates, Sessionzustand und Präfixanzahl müssen vor und nach Änderungen sichtbar sein.
RFC 4098 weist darauf hin, dass die Zusammensetzung einer vollständigen Tabelle je nach Ort und Zeitpunkt variiert. Eine starre Marketingangabe wie „unterstützt eine Million Routen“ genügt daher nicht. Fragen Sie nach den Grenzen der konkreten Plattform mit Ihrer Softwareversion, den aktivierten Funktionen, beiden Adressfamilien und der vorgesehenen Zahl paralleler Feeds.
Filter und Ausfallverhalten gehören zum Feed
- Nur den vereinbarten Feed akzeptieren: Ein Default-only-Anschluss sollte nicht stillschweigend beliebige Detailrouten übernehmen.
- Nicht global nutzbare, unzulässig spezifische oder eigene Präfixe nach der abgestimmten Policy behandeln und unerwartete Ankündigungen protokollieren.
- Import- und Exportfilter getrennt pflegen: Der gewünschte Routenempfang erlaubt nicht, fremde Routen an einen Upstream weiterzugeben.
- Präfixlimits und Warnschwellen mit dokumentierter Reserve festlegen und Änderungen des Upstreams geplant nachvollziehen.
- RPKI-Validierung und weitere Sicherheitsregeln in der Reihenfolge der eigenen Policy testen; ein Full Feed ist kein Grund, ungeprüft jede Route zu installieren.
Abnahme in fünf Schritten
- 1Für IPv4 und IPv6 festhalten, welcher Feed von welchem Nachbarn erwartet wird und wie viele Präfixe innerhalb der vereinbarten Größenordnung ankommen.
- 2Stichproben prüfen: Default, ausgewählte Zielpräfixe, Next Hop, Attribute und die daraus installierte Weiterleitung müssen zur Policy passen.
- 3Je Upstream einen kontrollierten Sessionausfall testen und beobachten, welche Routen verschwinden, welcher Ersatzpfad installiert wird und ob Anwendungen erreichbar bleiben.
- 4Den Fall eines erreichbaren BGP-Nachbarn bei gestörter Weiterleitung hinter dem Nachbarn separat betrachten; eine bestehende Session ist kein Ende-zu-Ende-Nachweis.
- 5Ergebnis, Konvergenz, Alarme und Rückbau dokumentieren und die Prüfung nach wesentlichen Policy-, Software- oder Hardwareänderungen wiederholen.
Welche Angaben in eine Transit-Anfrage gehören
Nennen Sie ASN, IPv4-/IPv6-Präfixe, Zahl und Art der Upstreams, gewünschtes Betriebsmodell sowie Routerplattform und Softwarestand. Beschreiben Sie getrennt je Adressfamilie, ob Default, ausgewählte Routen oder Full Table benötigt werden und welche Präfixlimits vorgesehen sind. Für eine AS51202-Anfrage kommen Standort, Port, Commit, Redundanzziel und DDoS-Anforderungen hinzu. Daraus lässt sich der Routenempfang konkret abstimmen, ohne eine Full Table pauschal als Qualitätsmerkmal zu behandeln.