February 21, 2026

Sicheres Rate Limiting im ISP: Legitimen Traffic nicht „abschießen“

Sicheres Rate Limiting im ISP ist eine der wichtigsten, aber auch riskantesten Disziplinen im Netzbetrieb: Richtig eingesetzt schützt Rate Limiting Ihre Infrastruktur vor DDoS, Fehlkonfigurationen, Broadcast-Stürmen, „Runaway Clients“ oder massiven Reconnect-Wellen (PPPoE/DHCP). Falsch eingesetzt schießt es legitimen Traffic ab, erzeugt schwer erklärbare Teilstörungen („einige Kunden sind betroffen“), verschlechtert Latenz und Jitter oder verhindert sogar die eigene Fehlersuche, weil Telemetrie und Control-Plane-Protokolle gedrosselt werden. Der entscheidende Unterschied zwischen gutem und schlechtem Rate Limiting ist nicht die Frage „Limit ja oder nein“, sondern wo, worauf und wie Sie limiten: auf Bits/s oder Packets/s, per Interface oder per Subscriber, global oder pro Zielprefix, stateless oder state-aware, mit Burst-Toleranz oder als harter Cut. In Provider-Netzen kommt hinzu, dass viele legitime Dienste „spiky“ sind (DNS, QUIC, Gaming, Video, PPPoE Discovery, RADIUS) und dass Traffic über ECMP/LAG verteilt ist, wodurch Limits selektiv zuschlagen können. Dieser Artikel zeigt praxisnah, wie Sie Rate Limiting im ISP so designen und betreiben, dass legitimer Traffic nicht unnötig leidet: typische Fehlerbilder, sichere Designprinzipien, Telemetrie- und Alarmierungsanforderungen sowie ein Runbook für Change- und Incident-Situationen.

Table of Contents

Was „Rate Limiting“ im ISP-Kontext wirklich bedeutet

Rate Limiting ist eine kontrollierte Drosselung von Traffic, die auf unterschiedlichen Ebenen stattfinden kann. In der Praxis werden im ISP-Betrieb vor allem diese Formen genutzt:

Policing (Hard Drop): Traffic über dem Limit wird verworfen (typisch: Token Bucket Policer). Sehr effektiv, aber riskant für TCP/VoIP, wenn das Limit falsch gewählt ist.
Shaping (Queueing): Traffic über dem Limit wird gepuffert und verzögert statt gedroppt. Schonender, aber kann Latenz/Jitter erhöhen und Bufferbloat erzeugen.
Control-Plane Policing (CoPP): Schutz der Router-CPU, indem bestimmte Protokolle/Packets zur CPU begrenzt werden.
Storm Control: spezielle Limits für Broadcast/Multicast/Unknown-Unicast in L2-Domänen.
Per-Subscriber Limits: z. B. am BNG/BRAS, CGNAT oder im Access (PPS/Session-Limits), oft zur Abuse- oder DoS-Prävention.

Wichtig: Die richtige Technik hängt vom Ziel ab. Infrastruktur-Schutz (CPU/Control Plane) braucht andere Limits als Kundenerlebnis-Schutz (Latenz/Jitter) oder Security-Mitigations (DDoS).

Warum schlechtes Rate Limiting „mysteriöse“ Outages erzeugt

Viele Rate-Limiting-Probleme werden nicht als solche erkannt, weil die Symptome indirekt sind. Typische Fehlinterpretationen:

„Routing ist kaputt“: in Wahrheit werden IGP/BGP Keepalives oder ICMP Antworten gedrosselt.
„DNS ist instabil“: in Wahrheit limitiert ein Policer UDP/53 oder UDP/443 (QUIC) in Peaks.
„Nur einige Kunden betroffen“: in Wahrheit trifft ein PPS-Limit nur bestimmte Hash-Buckets (ECMP/LAG) oder bestimmte Access-Segmente.
„DDoS-Mitigation wirkt nicht“: in Wahrheit limitiert man an der falschen Stelle (nach dem Engpass) oder ohne Burst-Toleranz.

Ein Kernprinzip lautet: Rate Limiting ist ein Eingriff in die Datenebene. Wenn Sie nicht exakt messen, was limitiert wird, wird Troubleshooting zum Rätselraten.

Designprinzip 1: Ziel und Schutzobjekt klar definieren

Bevor Sie einen Limiter konfigurieren, müssen Sie definieren, was Sie schützen und welches Risiko Sie akzeptieren. Ein „globales Limit“ ohne Zieldefinition ist fast immer gefährlich.

Schutzobjekt: Router-CPU, Linkkapazität, Service (DNS), Kunde, NAT-State, Firewall-State.
Schutzziel: Verfügbarkeit (keine Sättigung), Stabilität (weniger Flaps), Qualität (Latenz/Jitter), Sicherheit (DDoS).
Akzeptabler Kollateralschaden: Was darf im Worst Case leiden? Best-Effort ja, aber nie Control Plane und nie Monitoring.

Designprinzip 2: Bits/s vs. Packets/s – die wichtigste technische Entscheidung

Viele Operatoren limitieren „in Mbps“, obwohl das Problem in „pps“ entsteht – oder umgekehrt. Das führt zu falscher Wirkung.

Bits/s sinnvoll bei: volumetrischen UDP-Angriffen, Link-Sättigung, Video/Download Peaks.
PPS sinnvoll bei: SYN Floods, kleine UDP-Pakete, Scans, Control-Plane-Schutz, Broadcast-Stürme.

Umrechnung: Bits/s aus PPS und Paketgröße (MathML)

$bps = pps \times avg_packet_bytes \times 8$

Praktischer Effekt: Ein PPS-Limit kann sehr viel legitimen Traffic zerstören, wenn Pakete klein sind (DNS, VoIP), während ein Bits/s-Limit bei kleinen Paketen kaum schützt (weil PPS trotzdem hoch bleibt und CPUs/ASICs belastet).

Designprinzip 3: Burst-Toleranz ist kein Luxus, sondern Pflicht

Legitimer Traffic ist oft „bursty“. Ohne Burst-Toleranz droppen Sie Peaks, die für Kunden völlig normal sind: DNS-Cache-Misses, TCP Slow Start, Video-Segmentwechsel, QUIC Handshakes, PPPoE Discovery bei Recovery. Daher sollten Sie Limiter als Token-Bucket mit sinnvoller Burst-Größe planen.

Token-Bucket Intuition (MathML)

$BurstTime \approx \frac{BurstBytes}{RateBytesPerSecond}$

Wenn Ihre BurstTime zu klein ist, wird selbst normaler Peak-Traffic gedroppt. Wenn sie zu groß ist, wirkt der Limiter bei Angriffen zu spät. Im ISP-Betrieb ist der richtige Wert stark serviceabhängig – aber „0 Burst“ ist fast immer falsch.

Designprinzip 4: Control Plane und Telemetrie nie „blind“ limitieren

Der häufigste operative Totalschaden entsteht, wenn Rate Limiting aus Versehen Routing- oder Monitoring-Traffic trifft. Dazu gehören:

IGP/BGP Control: IS-IS/OSPF/BGP Sessions, BFD, LDP/SR Control (je nach Netz).
Management/Telemetry: SNMP/gNMI/Streaming Telemetry, Syslog, NetFlow/IPFIX Export, NTP.
Diagnose-Traffic: ICMP (Ping/Traceroute), aber mit Bedacht (ICMP ist wichtig, darf aber begrenzt werden).

Sicherer Ansatz: CoPP-Klassen so designen, dass kritische Control-Plane-Protokolle priorisiert und ausreichend dimensioniert sind, während „Noise“ (z. B. ICMP Floods, unerwünschte Scans) gedrosselt wird.

Designprinzip 5: Rate Limiting so nah wie möglich an der Quelle – aber nicht an der falschen Stelle

Wenn ein Link bereits gesättigt ist, hilft ein Limiter dahinter nicht mehr. Umgekehrt kann ein Limiter zu nah am Kunden legitime Peaks zerstören, die man zentral besser erkennt. Ein guter Grundsatz:

Infrastrukturschutz: nahe am Eintrittspunkt (Edge/Peering) oder vor dem Engpass.
Subscriber-Abuse: nahe am Subscriber (BNG/BRAS/CGNAT), aber mit klaren Ausnahmen und fairer Verteilung.
Service-Schutz (z. B. DNS): an der Servicekante (Resolver/Anycast), aber kombiniert mit Anycast/Scrubbing statt globalem Drop.

Typische Rate-Limiting-Fallen im ISP und wie Sie sie vermeiden

Die folgenden Fehlerbilder sind wiederkehrend und sollten als Checkliste in Runbooks stehen.

Falle: Globales UDP-Limit „zur Sicherheit“

Risiko: QUIC/HTTP3 (UDP/443), VoIP, Gaming, DNS werden beeinträchtigt.
Sicherer Ansatz: port- und zielbezogen limitieren (z. B. nur Amplifier-Ports zu betroffenen Prefixen) und Whitelists für kritische Abhängigkeiten.

Falle: PPS-Limit auf einem LAG ohne per-member Sicht

Risiko: ein Member degradiert, Hashing führt zu selektivem Impact; Limiter verschleiert das Problem.
Sicherer Ansatz: per-member Telemetrie, Limits pro Member oder vor LAG-Aggregation, und klare Alarmierung auf Member-Errors.

Falle: CoPP so eng, dass Incident-Diagnose unmöglich wird

Risiko: Ping/Traceroute/Telemetry „verschwinden“, während Routing noch gerade so läuft; MTTR steigt massiv.
Sicherer Ansatz: Diagnose-Klassen definieren: begrenzt, aber nicht „0“; separate Managementpfade.

Falle: Rate Limiting ohne Baseline und ohne Erfolgsmessung

Risiko: man sieht nicht, ob man Angriffs- oder legitimen Traffic drosselt; Kollateralschaden bleibt unbemerkt.
Sicherer Ansatz: vorab Baselines (p95/p99) pro Port/Service, danach Live-Korrelation mit Service-SLIs.

Telemetrie: Was Sie überwachen müssen, damit Rate Limiting sicher ist

Ohne Telemetrie ist Rate Limiting ein Blindflug. Diese Metriken sollten als Mindeststandard gelten:

Limiter Counters: matched packets/bytes, dropped packets/bytes, policer/shaper queue depth.
Interface Counters: PPS/BPS, drops/discards, queue drops, error counters.
Service SLIs: DNS success rate, TCP connect success, TLS handshake time, HTTP success rate – getrennt nach Region und v4/v6.
Control Plane Health: CPU, CoPP drops pro Klasse, Routing session stability.
Flow-Daten: Top ports, top targets, source diversity, um legitime vs. bösartige Muster zu unterscheiden.

Runbook für sicheres Rate Limiting im Incident

Wenn ein Incident läuft, müssen Entscheidungen schnell sein. Dieses Runbook priorisiert Stabilisierung und minimiert das Risiko, legitimen Traffic abzuschießen.

Schritt: Problemtyp bestimmen

Volumetrisch (BPS): Link-Sättigung, Amplification – eher Bits/s-Limits oder Scrubbing/Upstream.
PPS-lastig: SYN/Small UDP – eher PPS-Limits, CoPP, stateful Mitigation.
Subscriber-getrieben: wenige Heavy-Users – per-subscriber Limits statt global.

Schritt: Scope eng setzen

Zielprefix/VRF: nur betroffene Kunden/Services.
Port/Protokoll: nur die Signatur, die in Flows dominiert.
Region/PoP: wenn regional, nicht global begrenzen.

Schritt: Burst-tolerantes Limit wählen

Start konservativ: erst moderat drosseln, Wirkung messen, dann schärfen.
Stop-Kriterium definieren: wenn SLIs fallen oder Drops legitimer Klassen steigen, zurückrollen.

Schritt: Wirkung messen und nachjustieren

Wirkt es gegen den Angriff? BPS/PPS, Flow-Muster und Drops im Limiter prüfen.
Schadet es legitimen Nutzern? Service SLIs und Kundenregionen beobachten.
Control Plane stabil? CoPP/CPU darf nicht kippen, sonst ist das Netz nicht mehr steuerbar.

Schritt: Rückbau kontrolliert (Second Outage vermeiden)

Stabilitätsfenster: erst zurückbauen, wenn der Angriff nachweislich weg ist und SLIs stabil sind.
Schrittweise: Limits graduell erhöhen, nicht „alles aus“.
Peakzeiten vermeiden: kein Rollback kurz vor erwarteten Trafficpeaks.

Best Practices für dauerhafte, sichere Rate-Limits

Profiles statt Ad-hoc: vordefinierte Rate-Limit-Profile pro Angriffsklasse, pro Service, pro Kundentyp.
Canary-Deployment: Änderungen erst in einer Region/auf einer Plattform testen.
Dokumentierte Ausnahmen: Whitelists für Abhängigkeiten (DNS, Auth, Monitoring), damit Limits nicht „Blindheit“ erzeugen.
Kapazitätsmodelle: Rate Limiting ist kein Ersatz für Headroom; N-1 und Peak-Planung bleiben Pflicht.
Anti-Spoofing als Prävention: reduziert Reflection-Angriffe; Best Practices in RFC 2827 und RFC 3704.

Outbound-Ressourcen

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.