Anycast Scrubbing: Design, Routing-Policies und Risiken

Das Hauptkeyword „Anycast Scrubbing: Design, Routing-Policies und Risiken“ beschreibt eine DDoS-Schutzstrategie, die auf den ersten Blick elegant wirkt: Statt Traffic in ein einzelnes Scrubbing-Center zu ziehen, wird ein Scrubbing-Service über mehrere Standorte mit derselben Anycast-IP bzw. denselben Anycast-Präfixen angekündigt. Der Angriff verteilt sich dadurch automatisch auf mehrere PoPs, die Latenz für Nutzer sinkt, und die Plattform kann geografisch näher am Ursprung des Traffics reagieren. In der Praxis ist Anycast Scrubbing jedoch kein „Set-and-forget“-Konzept. Der Erfolg hängt an Details der BGP-Policy, an konsistenter Kapazität pro Standort, an sauberem Return-Path-Design und an Observability, die nicht nur Gbps, sondern auch pps, Session-Raten und Servicequalität misst. Risiken entstehen vor allem dann, wenn Anycast als rein routing-getriebene Lastverteilung verstanden wird: Das Internet entscheidet dynamisch, welcher PoP „am nächsten“ ist – und diese Entscheidung kann sich bei Routingschwankungen, Link-Ausfällen oder Policy-Änderungen kurzfristig ändern. Ein professionelles Anycast-Scrubbing-Design muss daher nicht nur schützen, sondern auch kontrollieren: Wo landet welcher Traffic, wie schnell kann man steuern, wie minimiert man Collateral Damage und wie verhindert man, dass ein einzelner Standort durch ungleiche Ingress-Verteilung kollabiert? Dieser Artikel erklärt die Bausteine eines robusten Anycast-Scrubbing-Setups, typische Routing-Policies sowie die häufigsten Failure Modes, damit Sie Anycast bewusst und betriebssicher einsetzen.

Was „Anycast Scrubbing“ konkret bedeutet

Anycast ist ein Routing-Prinzip, bei dem mehrere Standorte dieselbe IP-Adresse oder dasselbe Präfix announcen. Aus Sicht des Internets existiert nur ein Ziel, aber es gibt mehrere mögliche Pfade dorthin. Die Auswahl erfolgt über BGP-Entscheidungen entlang des Pfades (AS-Path, Local Preference, MED, Communities, Peering-Topologie). Im Kontext von Scrubbing bedeutet das: Der DDoS-Traffic wird an dem PoP „eingesammelt“, zu dem der Upstream-Pfad aktuell bevorzugt ist, dort bereinigt und anschließend als „clean traffic“ zum Origin bzw. zum geschützten Ziel zurückgeführt.

• Anycast Ingress: Angriffs- und Legit-Traffic landen automatisch verteilt auf mehreren Scrubbing-PoPs.
• Mitigation lokal: Filter- und Schutzlogik (L3/L4/L7) läuft in jedem PoP, idealerweise konsistent.
• Return zum Origin: Der bereinigte Traffic muss zuverlässig zum tatsächlichen Zielnetz (Data Center, Kundenstandort, Cloud-VPC) zurück.

Für die Grundlagen von BGP als Transport- und Policy-Protokoll ist RFC 4271 eine zentrale Referenz. Für einen praxisnahen Einstieg in DDoS-Konzepte und Begriffe kann eine Überblicksseite wie DDoS-Grundlagen und Angriffsarten helfen, Muster und Vektoren sauber zu benennen.

Anycast Scrubbing vs. On-Demand Scrubbing: Warum Operatoren wechseln

Klassisches On-Demand Scrubbing arbeitet oft mit More-Specific Announcements oder Umleitung per Tunnel nur im Angriff. Anycast Scrubbing kann dagegen als „always-on“ betrieben werden: Der Traffic läuft grundsätzlich über den Scrubbing-Service. Das reduziert Umschaltstress, verhindert „Warm-up“-Probleme und macht die Plattform planbarer – allerdings zum Preis höherer Dauerkomplexität (Policy, Kapazität, Konsistenz).

• Geringere Umschaltzeit: keine spontane Route-Änderung pro Incident nötig, wenn always-on.
• Bessere Latenzverteilung: Nutzer landen häufiger in einem geografisch nahen PoP.
• Skalierung über Standorte: volumetrische Angriffe verteilen sich, statt einen einzelnen PoP zu sättigen.
• Höhere Betriebsanforderungen: Policies, Monitoring und Failover müssen dauerhaft korrekt funktionieren.

Design-Bausteine: Anycast-Scrubbing-Architektur in der Praxis

Ein robustes Anycast-Scrubbing-Design besteht nicht aus „ein paar BGP-Announcements“, sondern aus klaren Komponenten: Ingress-Konnektivität, Mitigation-Pipeline, Return-Path, Steuerung/Automation und Observability. Entscheidend ist, dass jeder PoP als eigenständige, funktionsfähige Einheit betrieben werden kann, ohne dass globale Abhängigkeiten im Störfall alles blockieren.

• PoP-Ingress: ausreichende Bandbreite und pps-Kapazität je Standort, inklusive DDoS-resistenter Peering- und Transit-Anbindungen.
• Mitigation-Pipeline: „coarse-to-fine“ Filter (L3/L4 zuerst, L7 nur wenn nötig), um Kosten und Kollateralrisiko zu reduzieren.
• Return-Mechanismus: Tunnel (GRE/IP-in-IP), private Backbone-Transports oder direkte Übergabe ins Zielnetz.
• Policy-Konsistenz: gleiche Regeln und Thresholds pro PoP, plus kontrollierte Abweichungen (regionaler Traffic, lokale Peers).
• Control Plane & Automation: standardisierte Rollouts, versionierte Policies, schnelle Rückrollpfade.

Für GRE als verbreitete Encapsulation ist RFC 2784 hilfreich, für IP-in-IP RFC 2003.

Routing-Policies: Wie Sie Anycast-Ingress steuerbar machen

Anycast wirkt wie „automatische Lastverteilung“, ist aber in Wahrheit ein Resultat aus Peering-Topologie und Policy. Sie können und sollten beeinflussen, wie Traffic zu Ihren PoPs fließt. Dabei gilt: Sie steuern nicht jeden einzelnen Clientpfad, aber Sie können starke Tendenzen erzeugen, indem Sie Signale im BGP-Ökosystem setzen.

Local Preference, Peering und Topologie als primäre Hebel

• Mehr Peering-Punkte: Je dichter Ihre Peering-Topologie, desto besser verteilt sich Anycast natürlicherweise.
• Transit-Mix: Unterschiedliche Transits liefern unterschiedliche „Pull“-Effekte; ein dominanter Transit kann Pfade einseitig ziehen.
• LocalPref intern: In Ihrem eigenen AS steuern Sie, wie egress/ingress bevorzugt werden (z. B. PoP-A vs. PoP-B).

AS-Path Prepending und Community-Policy

AS-Path Prepending ist ein klassischer Hebel, um ein Announcement „weniger attraktiv“ zu machen. Communities sind meist präziser, weil sie upstream-spezifische Aktionen auslösen können (z. B. no-export, regionales Prepend, Blackhole). Der Vorteil: Sie können PoPs entlasten, wenn sie heiß laufen oder wenn lokale Kapazität begrenzt ist.

• Prepend zur Entlastung: Wenn ein PoP überlastet ist, kann Prepend Traffic wegdrücken – allerdings nicht deterministisch.
• Communities für Feintuning: z. B. nur auf bestimmten Transits/Peers verändern, statt global.
• no-export/no-advertise: gezielt Reichweite reduzieren (mit Vorsicht, um keine Erreichbarkeitslücken zu erzeugen).

Per-PoP Health-Driven Announcements

Ein professioneller Ansatz ist „health-based anycast“: Ein PoP announct nur dann das Anycast-Präfix, wenn die lokale Plattform gesund ist (Kapazität, Mitigation-Engine, Return-Path). Das reduziert Risiko, dass Traffic in einen halbtoten PoP gezogen wird.

• Health Gates: CPU/ASIC drops, state table utilization, tunnel health, latency/jitter Schwellenwerte.
• Graceful Withdrawal: kontrolliertes Withdraw, bevor harte Drops entstehen.
• Warm Standby: PoP bleibt technisch bereit, announct aber nur bei Bedarf oder im Normalbetrieb mit reduziertem Gewicht.

Return-Path-Design: Der häufigste Grund, warum Anycast Scrubbing scheitert

Die Anycast-Idee löst Ingress, aber nicht automatisch den Rückweg. Nach dem Scrubbing muss der legitime Verkehr zum Origin. Dabei entstehen typische Fallen: falsche MTU wegen Encapsulation, asymmetrische Pfade (stateful Systeme sehen nur eine Richtung), falsche Source-Adressen, die am Origin gefiltert werden, oder unerwartete ECMP-Verteilungen, die Session-Hashing kaputt machen.

• Tunnel-MTU: Wenn GRE/IP-in-IP genutzt wird, muss der End-to-End-Pfad die reduzierte effektive MTU berücksichtigen, sonst drohen Fragmentierung und Performance-Einbrüche.
• Stateful Geräte am Origin: Firewalls/Load Balancer erwarten konsistente Pfade; Return muss zu deren Design passen.
• Source-IP-Strategie: Bleibt die Source-IP des Clients erhalten (transparent), oder wird SNAT verwendet? Beides hat operative Konsequenzen.
• Routen-Symmetrie: Selbst wenn Ingress Anycast ist, sollte der Return möglichst deterministisch sein, um Debugging und SLOs zu stabilisieren.

Wenn Sie transparente Rückführung möchten, ist eine klare Policy am Origin nötig, um den bereinigten Traffic aus Scrubbing-Netzen anzunehmen und korrekt zu routen. Für Traffic-Engineering in großen Netzen kann Segmentierung über VRFs und klare Interconnect-Regeln entscheidend sein, damit „clean traffic“ nicht versehentlich wieder in die Mitigation-Pipeline zurückläuft.

Mitigation-Strategie: Coarse-to-Fine, um Kollateralschäden zu minimieren

Anycast Scrubbing erhöht die Skalierung, kann aber auch Kollateralschäden multiplizieren, wenn Regeln schlecht sind: Dann wirken sie an allen PoPs gleichzeitig. Deshalb ist ein gestuftes Filterdesign essenziell. Ziel ist, zuerst billige, robuste Maßnahmen zu nutzen und erst später teure oder riskante L7-Logik.

• L3/Stateless Filtering: offensichtlicher Spoofing-Müll, ungültige Paketkombinationen, klare Anomalien.
• L4 Schutz: SYN-Protection, new-flow-limits, UDP rate controls, State-Engine-Entlastung.
• L7 Regeln: nur wenn notwendig, mit klaren False-Positive-Mechanismen und schnellem Rollback.

Für Serviceklassen und priorisierte Behandlung ist DiffServ als Rahmen hilfreich (RFC 2475). Für TLS als häufigen Kontext bei L7-Angriffen ist RFC 8446 eine solide Referenz.

Risikoprofil: Was bei Anycast Scrubbing typischerweise schiefgeht

Die Risiken von Anycast Scrubbing sind selten „Anycast ist schlecht“, sondern fast immer ein Ergebnis aus unzureichender Steuerbarkeit, ungleichmäßiger Kapazität oder fehlender Observability. Die wichtigsten Failure Modes lassen sich in Routing-Risiken, Kapazitätsrisiken und Policy-/Regelrisiken gliedern.

Routing-Risiken

• Route Flaps und Pfadinstabilität: kleine BGP-Änderungen können Traffic plötzlich in einen anderen PoP ziehen.
• Hot Potato Effekte: Upstreams geben Traffic früh ab; Ihr PoP-Mix entscheidet, wo Last landet.
• Policy-Drift: unterschiedliche Community-Interpretationen pro Transit führen zu unerwarteter Ingress-Verteilung.
• Hijack/Leak-Exposure: Anycast-Präfixe sind attraktiv; harte Filtering- und RPKI-Disziplin reduzieren Risiko.

Kapazitäts- und Plattformrisiken

• PoP-Imbalance: Ein Standort bekommt überproportional viel Traffic (z. B. wegen großer Peerings), läuft heiß und dropt.
• pps statt Gbps: Eine Plattform kann Bandbreite haben, aber bei kleinen Paketen (hohe pps) kollabieren.
• State Exhaustion: new sessions/s überlasten conntrack- oder proxybasierte Komponenten.

Policy-/Regelrisiken

• Globale False Positives: eine zu aggressive L7-Regel blockiert echte Nutzer weltweit.
• Uneinheitliche Rulesets: wenn PoPs nicht identisch sind, erleben Kunden je nach Standort unterschiedliche Wirkung.
• Unklare Eskalationslogik: „Alles drosseln“ ist schnell, aber zerstört oft die eigentliche Servicequalität.

Messbarkeit: Welche Telemetrie Anycast Scrubbing zwingend braucht

Anycast ist nur dann betriebssicher, wenn Sie nicht nur die Gesamtlast sehen, sondern die Verteilung pro PoP und pro Angriffsvektor. Entscheidend ist außerdem, zwischen Angriffs- und Legit-Verkehr unterscheiden zu können und SLOs für „clean traffic“ zu messen.

• Ingress pro PoP: Gbps, pps, durchschnittliche Paketgröße, Top Quell-ASNs, Top Ports/Protokolle.
• Mitigation-Wirkung: Drops nach Grund/Klasse, Rate-Limit-Hits, Signatur-Treffer, False-Positive-Indikatoren.
• Return-Health: Tunnel up/down, MTU/Fragmentation-Signale, Latenz/Jitter, Packet Loss.
• Service KPIs: TCP/TLS Handshake Success, HTTP Status Codes, DNS Success Rate (je nach Schutzobjekt).

Für Flow-Daten als schnelles Analysewerkzeug ist IPFIX ein Standardrahmen (RFC 7011). In Anycast-Scrubbing-Setups sind Flow-Sichten pro PoP besonders wertvoll, weil sie Ingress-Shift („Traffic wandert“) sichtbar machen, bevor Kunden es melden.

Policy-Patterns: Bewährte Vorgehensweisen für Routing-Steuerung

Im Feld haben sich einige Muster etabliert, die Steuerbarkeit erhöhen, ohne die Grundidee von Anycast zu zerstören. Sie sind nicht universell, aber sie liefern robuste Leitplanken.

• PoP-Tiers: große PoPs announcen „voll“, kleine PoPs announcen mit Prepend oder nur in bestimmten Regionen.
• Regional Communities: Traffic in Regionen halten, um Transkontinental-Backhaul zu vermeiden.
• Health-Weighted Announcements: PoP reduziert Reichweite, wenn pps/State-Watermarks überschritten werden.
• Separate Anycast-Präfixe nach Service: z. B. unterschiedliche Präfixe für L3/L4-Scrubbing vs. L7/WAF, um Risiko zu trennen.

Wichtig ist, dass jede Policy-Änderung als Change mit klaren Messpunkten behandelt wird. Anycast reagiert oft nicht linear: Eine kleine Änderung kann große Traffic-Shifts verursachen, weil sich Pfadentscheidungen im Internet kaskadieren.

Risiko „Asymmetrie“: Wenn Statefulness und Anycast kollidieren

Anycast ist per Natur „best effort“ hinsichtlich Pfadkonsistenz. Viele Schutzkomponenten arbeiten jedoch stateful (SYN-Proxy, Session-Tracking, NAT, WAF mit Session-Cookies). Wenn ein Client in kurzer Zeit zu einem anderen PoP gezogen wird, können Sessions reißen oder unerwartete Challenges auftreten. Das betrifft besonders mobile Nutzer und Netze mit instabilen Upstreams.

• Stateless first: möglichst früh stateless filtern, um stateful Komponenten zu entlasten.
• Session Affinity bewusst gestalten: z. B. per L7-Cookie/Token, wenn technisch und rechtlich passend.
• Keepalive- und Timeout-Profile: so wählen, dass kurze Pfadwechsel nicht sofort Session-Abbrüche erzeugen.
• PoP-Konsistenz: identische Rulesets und ähnliche Kapazitäten reduzieren „PoP-Lotterie“.

Kapazitätsplanung: Anycast verteilt Last, aber nicht garantiert gleichmäßig

Ein häufiger Denkfehler lautet: „Wir haben zehn PoPs, also teilen wir die Last durch zehn.“ In Wirklichkeit ist die Verteilung selten gleich. Große Peerings, regionale Topologien und Transitbeziehungen können dazu führen, dass ein oder zwei PoPs den Großteil der Last sehen. Planung sollte daher immer mit Worst-Case-Verteilung rechnen: Ein einzelner PoP muss einen großen Anteil tragen können, oder Sie benötigen Mechanismen, um Traffic aktiv wegzudrücken.

Eine hilfreiche Einordnung von pps vs. bps liefert die durchschnittliche Paketgröße:

$\mathrm{AvgPacketSize}=\frac{\mathrm{BitsPerSecond}}{\mathrm{PacketsPerSecond}}$

Für stateful Engpässe ist die grobe Beziehung zwischen neuen Flows und Timeout relevant:

$\mathrm{Entries}\_\mathrm{avg}\approx \mathrm{NewFlowsPerSecond}\times \mathrm{Timeout}\_\mathrm{avg}$

Beide Formeln sind keine vollständige Modellierung, aber sie verhindern Fehlentscheidungen, wenn Angriffe nicht „Bandbreitenprobleme“, sondern pps- oder State-Probleme sind.

Betrieb und Incident-Response: Anycast-spezifische Playbook-Schritte

Im Incident unterscheidet sich Anycast Scrubbing deutlich von Single-PoP-Scrubbing: Sie müssen nicht nur „Mitigation aktivieren“, sondern auch die Ingress-Verteilung stabilisieren und kontrollieren, damit keine PoP-Kaskade entsteht. Ein pragmatisches Playbook umfasst daher immer Verteilungsanalyse, PoP-Health und Return-Validation.

• Ingress-Shift prüfen: Wandert Traffic zwischen PoPs? Gibt es Route Flaps oder Transit-Probleme?
• PoP-Watermarks: pps, drops, state utilization, CPU/ASIC counters pro Standort überwachen.
• Gezielte Policy-Änderungen: Prepend/Community nur dort, wo Entlastung notwendig ist, und mit messbaren Erfolgskriterien.
• Return-Checks: MTU/Fragmentation, Tunnel Health, End-to-End Handshake Success messen.
• Regeländerungen stufenweise: erst coarse, dann fine; globales L7-Tuning nur mit hoher Evidenz.

Outbound-Links für Standards und vertiefende Informationsquellen

• BGP (RFC 4271) als Basis für Anycast-Announcements und Routing-Policy
• IPFIX (RFC 7011) für Flow-Telemetrie zur PoP-Verteilungsanalyse und Mustererkennung
• GRE (RFC 2784) für Clean-Traffic-Return über Tunnel in Scrubbing-Architekturen
• IP-in-IP (RFC 2003) als Alternative für Return-Encapsulation und Transport
• DiffServ (RFC 2475) für Serviceklassen und Priorisierung, um Kollateralschäden zu reduzieren
• TLS 1.3 (RFC 8446) für Handshake-Grundlagen bei verschlüsseltem L7-Traffic
• DDoS-Grundlagen und Angriffsarten als Kontext für Anycast-Scrubbing-Designentscheidungen

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.