Ein Multi-Upstream-DDoS-Design kombiniert mehrere Transitprovider, BGP-Policies und Mitigationsschichten, um Single Points of Failure zu reduzieren. Dieser Leitfaden erklärt Nutzen und Grenzen.
Das Thema braucht messbare technische Policies.
Ingress-Route und Rückweg von Clean Traffic prägen das Ergebnis.
Verfügbarkeit entsteht aus Regeln, Schwellen, Rollback und Sichtbarkeit.
Multi-Upstream-DDoS-Schutz: warum ein einzelner Transitprovider selten reicht ist eine Architekturfrage und kein reiner Kapazitätskauf. Das Problem ist, mehrere Transitprovider mit vollständiger DDoS-Mitigation zu verwechseln. Redundanz verbessert Verfügbarkeit, filtert aber keinen Flood automatisch. Für exponierte Netzwerke, Hoster, Gaming-Dienste und B2B-Plattformen muss das Design erklären, wo Traffic eintritt, welche Schicht entscheidet, wie Sättigung verhindert wird und wie legitimer Traffic zurückkommt. Dieser Artikel behandelt Multi-Upstream-DDoS-Schutz, verwandte Suchanfragen wie Multi-Upstream Anti-DDoS, mehrere Transitprovider DDoS, BGP Multihoming DDoS, Transit-Redundanz DDoS und die operative Umsetzung.
Peeryx setzt auf ein verständliches Design: Upstream-Kapazität, präzises Filtering, sauberer Handoff und erklärbarer Support im Incident.
Das Problem ist, mehrere Transitprovider mit vollständiger DDoS-Mitigation zu verwechseln. Redundanz verbessert Verfügbarkeit, filtert aber keinen Flood automatisch. Viele Teams erkennen das erst im ersten ernsten Incident, wenn Routen bereits unter Druck geändert werden.
Multi-Upstream-DDoS-Schutz zwingt dazu, den kompletten Pfad zu betrachten: BGP-Announcement, gewählter Upstream, echte Portkapazität, verfügbares Filtering, Clean-Traffic-Handoff und Verhalten des Dienstes. Bleibt ein Punkt undefiniert, kann die Mitigation theoretisch funktionieren und praktisch scheitern.
Auch die kommerzielle Sprache ist ein Problem. “Viel Kapazität” erklärt nicht, was mit legitimem UDP, etabliertem TCP, Latenz, BGP-Communities oder temporären Regeln geschieht. Technische Käufer brauchen Mechanik, nicht nur Zahlen.
Eine falsche Entscheidung wird sofort als Ausfall sichtbar. Endnutzer unterscheiden nicht zwischen Transit-Sättigung, schlechter BGP-Policy und zu aggressivem Filter; sie sehen Timeouts, Paketverlust oder Disconnects.
Auch Kosten sind betroffen. Angriffstraffic auf dem falschen Pfad kann 95th Percentile, Backbone-Nutzung und Supportaufwand erhöhen. Die Architektur muss den Angriff früh reduzieren, ohne legitimen Traffic zu opfern.
Für latenzsensitive Dienste wie FiveM, Minecraft, VoIP oder interaktive APIs muss Stabilität erhalten bleiben. Schutz, der den Dienst online hält, aber die Nutzung ruiniert, reicht nicht.
In der Praxis sollte jedes Design vor der Kundenmigration getestet werden: kontrollierte Traffic-Samples, klare Grenzwerte, definierte Rollback-Schritte und ein Ansprechpartner pro Carrier. Diese Vorbereitung wirkt weniger spektakulär als große Kapazitätszahlen, entscheidet aber oft darüber, ob eine Plattform während eines echten Angriffs stabil bleibt oder ob das Team im Notfall improvisieren muss.
Zuerst muss das Ingress-Modell dokumentiert sein: welche Präfixe, welches ASN, welche Upstreams und welche BGP-Policy. Ohne diese Basis kann Automation den Incident verschlimmern.
Zweitens braucht es proportionale Filterung. Blackhole, ACL, FlowSpec, Scrubbing und Rate-Limit haben unterschiedliche Auswirkungen. Jedes Werkzeug braucht Rolle und Ablaufzeit.
Drittens muss Clean-Traffic-Delivery vor dem Angriff feststehen. GRE, IPIP, VXLAN, Router-VM und Cross-Connect sind gültige Optionen, aber sie unterscheiden sich in Latenz, Kontrolle und Rollout.
Die Architektur muss festlegen, welcher Upstream Traffic anzieht, welcher filtert, welcher Backup bleibt und welche BGP-Communities im Incident genutzt werden.
Auch die wirtschaftliche Seite zählt. Mehrere Upstreams bedeuten nicht automatisch, dass jedes Port dauerhaft voll ausgelastet werden muss. Oft ist es sinnvoller, einen Teil der Kapazität als Reserve für Angriffsspitzen zu behalten, die Commitments sauber zu dimensionieren und die technischen Schutzfunktionen jedes Carriers in die Kostenbetrachtung einzubeziehen. Ein günstiger Transit ohne brauchbare DDoS-Werkzeuge kann im Angriff teurer werden als ein etwas teurerer Anbieter mit schneller Eskalation und präzisen Communities.
Peeryx betrachtet das zuerst als Netzwerkdesign: Traffic zu einer absorptionsfähigen Schicht ziehen, offensichtliches Angriffsvolumen reduzieren und sauberen Traffic zurückgeben, ohne die Topologie zu verschleiern.
Es geht nicht um permanente generische Regeln. FlowSpec oder Upstream-Filtering müssen präzise, zeitlich begrenzt und beobachtbar sein. Tunnel oder Cross-Connect müssen dokumentiert sein.
Kommerziell zählt eine Schutzlösung, die der Kunde versteht: Pfad, Grenzen, Schwellen, Support und Rollback statt unendlicher Mitigationsversprechen.
Eine Multi-Upstream-Strategie muss außerdem definieren, wann ein Pfad aktiv genutzt, wann er nur als Kapazitätsreserve gehalten und wann er während eines Angriffs bewusst entlastet wird. Das verhindert, dass alle Provider denselben schlechten Pfad bekommen oder dass Rücktraffic über einen anderen Carrier läuft als erwartet und dort neue Engpässe entstehen.
Peeryx setzt auf ein verständliches Design: Upstream-Kapazität, präzises Filtering, sauberer Handoff und erklärbarer Support im Incident.
Ein Operator mit zwei 100G-Ports lenkt das angegriffene Präfix auf den geschützten Pfad, hält den zweiten Upstream für gesunden Traffic aktiv und kehrt nach dem Angriff zurück.
Im Incident prüft das Team Volumen, PPS, Protokoll, Ports, aktive Routen und Latenz je ASN. Reduziert die Aktion den Angriff ohne legitimen Traffic zu beschädigen, bleibt sie aktiv; sonst wird sie enger gefasst oder entfernt.
Nach dem Incident werden Daten in das Runbook übernommen: welche Community, welches Präfix, welche Regel nicht wiederholen und welche Kapazität später nötig ist. So verbessert sich die Schutzlogik mit jedem Angriff.
Technisch wichtig sind saubere Communities, konsistente Präfixpolitik, dokumentierte Local-Preference-Werte und eine klare Eskalation pro Provider. Wenn ein Upstream FlowSpec unterstützt und ein anderer nur Blackhole oder manuellen Support anbietet, muss das Design diese Unterschiede berücksichtigen, statt alle Carrier als identische Kapazität zu behandeln.
Das Ziel ist ein Schutz, der reproduzierbar funktioniert, sauber dokumentiert ist und auch von einem anderen Engineer verstanden werden kann, wenn der Angriff außerhalb der üblichen Geschäftszeiten beginnt.
Volumen, PPS, Protokoll, Ports, BGP-Pfad und Kundenauswirkung erfassen.
Die kleinste wirksame Aktion anwenden: Route, Filter, Shift oder Handoff.
Regeln entfernen oder verengen, sobald der Druck sinkt.
Nein. Es zählt auch bei kleineren Angriffen, die Links sättigen, legitimes UDP stören oder einzelne Regionen verschlechtern.
Ja. Der Kunde kann BGP-Kontrolle behalten, während Peeryx geschützten Ingress, Filtering und Clean Delivery liefert.
Eine zu breite Regel oder ein schlecht dokumentierter Pfad, der das Netzwerk schützt, aber den Dienst beschädigt.
Vor dem Incident, um Präfixe, Upstreams, Routen, Latenz, Handoff und Mitigationspolicy festzulegen.
Multi-Upstream-DDoS-Schutz: warum ein einzelner Transitprovider selten reicht gehört in eine vollständige Architektur aus BGP, Upstreams, Filtering, Kapazität, Handoff und Support.
Der beste Schutz bleibt während des Angriffs verständlich. Wenn das Team weiß, welche Route sich änderte, welche Regel aktiv ist und wie Clean Traffic zurückkommt, bleibt der Dienst deutlich eher verfügbar.
Peeryx kann Präfixe, Upstreams, Latenzanforderungen und DDoS-Exposition prüfen und ein Modell für geschützten Transit oder sauberen Handoff passend zur echten Topologie vorschlagen.
