Auf dieser Seite
Das Wichtigste
- 100Gbps verändert das ProblemAuf diesem Niveau lautet die Frage nicht nur “kann ich filtern?”, sondern “hält meine Architektur?”.
- Gbps ist nicht allesEin Angriff kann über Bandbreite, Paketrate oder CPU-Kosten brechen.
- Upstream-Entlastung zähltSie dient der groben Reduktion, damit intelligentere Schichten stabil bleiben.
- Abnahmetest festlegenVereinbaren Sie Paketgrößen, Regeln, legitime Last, Verlust und Wiederanlauf; prüfen Sie die stärkste Queue und den verbleibenden Pfad nach Ausfall.
100 Gbit/s ist eine Verbindungsrate, kein Filterergebnis
Beginnen Sie mit dem ersten begrenzten Abschnitt und der Ebene der Messung. Beobachteter Angriff, physischer Port, Standortsumme und reservierte Kundenkapazität sind unterschiedliche Größen. Ein 100-Gbit/s-Port kann der Engpass sein, auch wenn der Anbieter anderswo erheblich mehr Kapazität nennt.
Die folgenden Werte sind theoretische Wire-Rate-Rechnungen für eine Richtung einer Ethernet-Verbindung. Die Framelänge enthält den FCS; hinzu kommen 8 Byte Präambel/SFD und 12 Byte Inter-Frame Gap. Mpps = Gbit/s × 1.000 ÷ [8 × (Framebytes + 20)]. Das sind keine Softwarebenchmarks und keine Aussage über die Paketverarbeitungsgrenze einer bestimmten Implementierung.
| Ethernet-Frame einschließlich FCS | Theoretische Rate bei 100 Gbit/s | Einordnung |
|---|---|---|
| 64 Byte | 148,81 Mpps | Kleine Frames verlangen viele Paketentscheidungen |
| 128 Byte | 84,46 Mpps | Gleiche Bitrate, andere Paketrate |
| 512 Byte | 23,50 Mpps | Zustände und Regeln können weiterhin dominieren |
| 1.518 Byte | 8,13 Mpps | Große Frames belegen keine Leistung mit kleinen Paketen |
Volumetrische und applikative Angriffe gehören nicht in dieselbe Schicht
Ein volumetrischer Angriff zielt zuerst auf Bandbreite, Buffer, PPS oder Flow-Verarbeitung. Ein applikativer Angriff zielt auf Service-Logik, Proxys oder App-Ressourcen. Beides kann zusammen auftreten, sollte aber nicht gleich behandelt werden.
Wenn wir über mehr als 100Gbps sprechen, lautet die erste Priorität fast immer: Volumen und PPS überleben. Fällt der Link vorher, hilft die beste L7-Logik nicht mehr.
- Volumetrischer Druck wird zuerst auf Absorptions-Ebene behandelt.
- Applikationsnahe Filterung kommt danach und braucht mehr Kontext.
- Wer beide Ebenen zu früh vermischt, erzeugt Kollateralschäden oder unnötige CPU-Kosten.
Link-Sättigung, PPS-Sättigung und CPU-Sättigung sind drei verschiedene Ausfälle
Ein DDoS bricht einen Dienst nicht nur auf eine Weise. Er kann den Link füllen, über Pakete pro Sekunde die Verarbeitung erdrücken oder die CPU der Mitigationslogik überlasten. Darum sagt eine Kapazitätszahl ohne Architektur sehr wenig aus.
Messen Sie neben Summen auch die Last jeder Queue und jedes Kerns. Ungleiche Flow-Verteilung kann eine Queue überlasten, während andere Kerne untätig sind. Zwei 100G-Ports können jeweils Ein- und Ausgang bilden; daraus wird kein 200-Gbit/s-Filterpfad in einer Richtung. Dokumentieren Sie Richtung, Zählebene und Rolle jedes Ports.
Link-Sättigung
Port oder Transit füllen sich vor tieferer Analyse.
PPS-Sättigung
Die Paketrate wird zum eigentlichen Killer.
CPU-Sättigung
Die Filter-Logik sieht den Traffic, verbrennt aber zu viele Zyklen.
Die Rolle der Upstream-Vorfilterung
Upstream-Vorfilterung ist für grobe Reduktion da. Sie soll nicht alleine jede Legitimitätsentscheidung treffen, sondern ausreichend offensichtliche Muster entfernen, damit massiver Lärm nicht die teuersten Stufen erreicht.
Das ist oft der beste Kosten-/Wirkungspunkt: weniger Rohrauschen für den Filterserver, mehr Luft auf den Links und mehr Stabilität für das, was wirklich Intelligenz braucht.
Die Rolle eines Filterservers
Nehmen Sie einen Filterserver mit reproduzierbarer Last ab, nicht allein anhand des CPU-Modells. Dokumentieren Sie Software- und Regelversionen, NIC und Treiber, Queue-Verteilung, NUMA-Zuordnung, Paketgrößen und aktive zustandsbehaftete Funktionen. Messen Sie empfangenen Verkehr, verworfene Angriffspakete, weitergeleiteten legitimen Verkehr, Verlust und Latenz unter denselben Bedingungen.
Nutzen Sie eine isolierte und autorisierte Testumgebung. RFC 2544 beschreibt eine Benchmarkmethode; RFC 6815 erläutert die Gefahren ihrer Anwendung im Produktionsnetz. Prüfen Sie Wiederanlauf und den verbleibenden Pfad bei geplanter Last separat. Ein gutes Laborergebnis belegt keine Kapazität einer ungetesteten Produktionstopologie.
Die Rolle von Tunneln und sauberer Traffic-Rückgabe
Mitigation alleine reicht nie. Sauberer Traffic muss an der richtigen Stelle wieder ankommen, ohne eine Vollmigration zu erzwingen. Genau dort werden GRE, IPIP, VXLAN, BGP over GRE oder Cross-Connect relevant.
Welches Modell passt, hängt vom Kontext ab: bestehender Dedicated Server, Backbone, Cluster, Proxy oder der Wunsch, öffentliche IPs zu behalten. Entscheidend ist nicht der Tunnelname, sondern ob der Handoff zur realen Topologie passt.
- Ein guter Handoff vermeidet eine erzwungene Komplettmigration.
- Der Tunnel ist Teil des Betriebsmodells, nicht nur des Transports.
- Saubere Rückgabe muss vor dem Angriff geplant werden.
Häufige Fehler
- 100Gbps nur als Bandbreiten-Thema zu sehen.
- Die gesamte Logik in eine einzige Schicht zu zwingen.
- Lesbares Design: Jede Regel, Schwelle und Rückgabe muss im Incident verständlich bleiben.
- Upstream zu aggressiv zu filtern, ohne echte Baseline des Normalverkehrs.
- Eine Mitigations-Zusage zu kaufen, ohne das Handoff-Modell zu verstehen.
FAQ
Bedeutet ein DDoS über 100Gbps automatisch Ausfall?
Nein, aber es erfordert eine vorbereitete Architektur. Ohne Absorption, grobe Reduktion und saubere Rückgabe steigt das Risiko schnell.
Kann ein einzelner Filterserver ausreichen?
Nicht immer. Er kann sehr wertvoll sein, aber ohne Upstream-Entlastung kann er der nächste Engpass werden.
Warum so viel Fokus auf saubere Traffic-Rückgabe?
Weil Mitigation nur Wert schafft, wenn der Kunde verwertbaren legitimen Traffic zurückbekommt.
Kann bestehende Infrastruktur erhalten bleiben?
Ja, sehr oft. Genau deshalb ist das Delivery-Modell so wichtig.
Was sollte man vor der 100Gbps-Diskussion zuerst messen?
Zuerst Link-Sättigung, Paketlast und CPU-Druck sauber trennen. Genau das verhindert falsche Dimensionierung.
