Wie BGP funktioniert: Präfixe, AS-Pfade, Routing-Entscheidungen und DDoS-Auswirkung

Das Problem definieren

BGP ist ein Ankündigungssystem zwischen autonomen Systemen.

Verschiedene Provider können andere Pfade wählen; Communities, spezifischere Routen und Policy ändern das Ergebnis.

BGP-Attribute sind keine universellen Befehle. Local Preference ist meist intern, AS-Path Prepending wirkt nicht überall, und MED wird oft zwischen Providern ignoriert. Tests mit echten Upstreams sind nötig.

Zur Bewertung von BGP als Internet-Control-Plane müssen drei Ebenen getrennt werden: BGP-Signal, realer Traffic und Nutzererlebnis. Werden sie vermischt, wirkt die Session stabil, obwohl nützlicher Traffic einen anderen Pfad nimmt oder in einem zu breiten Filter verloren geht.

Technische Käufer merken schnell, ob ein Anbieter nur Marketingbegriffe nutzt oder die Grenzen der eigenen Architektur kennt. Gerade bei DDoS ist Ehrlichkeit über Grenzen ein Vertrauenssignal.

Warum es wichtig ist

BGP bestimmt, wo Traffic vor der Filterung ankommt.

Saubere Zustellung nach Mitigation muss definiert sein, sonst entstehen Asymmetrie und Routenkonflikte.

Bei DDoS-Mitigation gewinnt oft die akzeptierte spezifischste Route. Ein IPv4-/24 kann Traffic aus einem größeren Aggregat ziehen. Das ist nützlich, aber ohne RPKI, IRR und Filter gefährlich.

Der finanzielle Schaden entsteht nicht nur beim Totalausfall. Teilstörungen sind oft teurer zu diagnostizieren: einige Provider erreichen den Dienst, andere nicht; bestimmte Länder sehen höhere Latenz; Spielsessions brechen ab; Support bekommt schwer reproduzierbare Meldungen.

Für SEO und Vertrieb hilft diese Erklärung, bessere Leads anzuziehen. Ein ernsthafter Kunde sucht nicht nur eine Tbps-Zahl, sondern will wissen, ob Routing, Handoff-Limits, False Positives und Service-Kontinuität verstanden werden.

Für deutschsprachige technische Käufer zählen konkrete Grenzen, nicht nur Leistungszahlen. Ein Artikel sollte zeigen, wie Entscheidungen getroffen werden, welche Annahmen geprüft werden und wie der Dienst im Fehlerfall wieder in einen sicheren Zustand zurückkehrt.

Dieser zusätzliche Aufwand lohnt sich, weil er spätere Ausfälle kürzer macht und dem Kunden zeigt, dass Schutz nicht nur aus Marketingzahlen besteht.

Mögliche Lösungen

Kunden-eBGP gibt viel Kontrolle.

Provider-gesteuerte Ankündigung ist einfacher, muss aber transparent bleiben.

Protected Transit zieht Traffic zur Mitigation und liefert sauber per Tunnel oder Cross-Connect zurück.

Default Route reicht vielen geschützten Kunden, weil inbound Traffic die Hauptgefahr ist. Full Table ist sinnvoll bei detaillierter Egress-Steuerung oder mehreren Transitbeziehungen.

Eine technische Maßnahme braucht ein Verfahren: auslösende Metrik, erforderlicher Nachweis, autorisiertes System oder Person, maximale Dauer und Bedingung für Rücknahme. Ohne Grenzen wird ein nützliches Werkzeug selbst zum Betriebsrisiko.

Außerdem muss Notfall von Dauerdesign getrennt werden. Eine aggressive Aktion kann zehn Minuten lang akzeptabel sein, um Kapazität zu retten, darf aber ohne Review nicht zur festen Konfiguration werden. Normaler Traffic ändert sich nach Uhrzeit, Land, Spiel und Client-Version.

Das Design braucht Abnahmekriterien: erwartete Latenz, maximal tolerierter Paketverlust während Mitigation, Handoff-Kapazität, Eskalationskontakte und Bedingungen für disruptive Maßnahmen.

Zusätzlich sollte jedes Design einen einfachen Testplan besitzen: Route von außen prüfen, Handoff-Bandbreite messen, Latenz vergleichen, Eskalation testen und dokumentieren, welche Änderung im Notfall zuerst zurückgenommen wird.

BGP-Entscheidungen in planbares geschütztes Routing übersetzen

Peeryx definiert, wer ankündigt, mit welchem AS, welchen Limits und welchem Rückweg.

BGP zieht Traffic zur Kapazität; die Anti-DDoS-Schicht filtert; danach kommt die saubere Zustellung.

Für Gaming und Hosting verhindert das Latenz- und Session-Überraschungen.

Peeryx unterscheidet diese Fälle im Scope. Manche Kunden brauchen volle Kontrolle; andere brauchen nur geschützte Präfixe und saubere Zustellung. Das Design muss betreibbar bleiben.

Der Wert eines spezialisierten Providers liegt darin, Entscheidungen mit dem realen Transport zu verbinden: BGP, Tunnel, Cross-Connect, Präfixe, Session-Limits und Kapazität. Mitigation darf nicht vom Paketpfad vor und nach der Filterung getrennt sein.

Bei Peeryx soll der Kunde seine Architektur einfach erklären können: wo Traffic eintritt, welche Schicht säubert, was upstream gefiltert wird, was lokal entschieden wird und wie legitimer Traffic zurückkommt. Ist das nicht klar, ist das Design nicht fertig.

In der Praxis übersetzt Peeryx diese Themen in einfache Entscheidungen: welches Präfix geschützt wird, welcher Traffic normal ist, welches Muster als Angriff gilt und welche Aktion bei welchem Schwellenwert erfolgt.

So entsteht ein Verkaufsargument, das technisch belastbar ist: nicht nur eine große Abwehrkapazität, sondern ein nachvollziehbarer Pfad für legitimen Traffic, ein begrenzter Eingriff während der Attacke und eine klare Rückkehr in den Normalbetrieb.

Konkretes Beispiel

Ein Hoster mit /24 kündigt über Peeryx an und erhält sauberen Traffic zurück.

Ein Kunde ohne ASN kann geschützte IPs nutzen, während Peeryx BGP verwaltet.

Vor Produktion sollte die Route von externen Blickpunkten getestet werden. Eine BGP-Session up beweist nicht, dass das Internet Origin und Pfad korrekt sieht.

Vor Produktion sollten kontrollierte Tests stattfinden: Route zurückziehen, Tunnel wechseln, Latenz über mehrere Provider messen und prüfen, ob Logs beim Pfadwechsel sichtbar werden. Diese Vorbereitung spart im echten Angriff Minuten.

Diese Details erleichtern auch Provider-Vergleiche. Zwei Angebote können preislich ähnlich wirken, aber nur eines enthält klare BGP-Integration, dokumentierte Regeln und ausreichenden Handoff.

Häufige Fehler

BGP-Fehler erscheinen oft erst unter Last.

BGP-Änderungen sind keine harmlosen Edits. Propagation, Filter und Caches können Rollback langsamer machen als erwartet.

Optimierung nur für den Installationstag reicht nicht. Das Design muss auch Monate später verständlich bleiben, wenn Kunden, Präfixe, ein zweiter Transit oder ein neuer PoP hinzukommen. Operative Dokumentation ist Teil des Schutzes.

Ein häufiger Fehler ist, nach der ersten erfolgreichen Installation nicht erneut zu testen. Jede neue Route, jeder neue Tunnel und jeder neue Kunde kann Annahmen ändern.

Wer diese Punkte nicht vorab beschreibt, muss sie im Stress eines Angriffs erfinden. Genau dort passieren die teuersten Fehler.

• BGP als Firewall sehen.
• Keinen sauberen Rückweg definieren.
• Präfixlimits ignorieren.
• RPKI/ROA auslassen.

FAQ