Control Plane Policing (CoPP): Baseline für Router- und Core-Schutz

Control Plane Policing (CoPP) ist eine der wirkungsvollsten Baselines, um Router und Core-Komponenten in Provider- und Telco-Netzen gegen Überlast, Angriffe und Fehlkonfigurationen zu schützen. Während Data-Plane-Designs oft auf hohe Bandbreite und Forwarding optimiert sind, ist die Control Plane (also die CPU und die Steuerlogik) ein deutlich knapperes Gut: Sie verarbeitet Routing-Protokolle, Managementzugriffe, ICMP/ND/ARP, BGP-Sessions, LDP/RSVP, Telemetrie, Protokoll-Fehlerbehandlung und viele weitere Signale. Genau deshalb sind Control-Plane-Störungen so gefährlich: Ein PPS-starker Flood, ein Scan, ein Fehlverhalten im Peering, ein ARP-Sturm oder eine ungefilterte Protokollnachbarschaft kann die CPU in kurzer Zeit auslasten und damit Routing-Konvergenz, BGP-Stabilität und letztlich die Verfügbarkeit ganzer Regionen beeinträchtigen. Eine praxistaugliche CoPP Baseline für Router- und Core-Schutz definiert nicht nur „ein paar Rate Limits“, sondern ein konsistentes Klassenmodell für erlaubten Control-Plane-Traffic, klar getrennte Schutzstufen für Edge- und Core-Router, saubere Monitoring-KPIs sowie sichere Rollout- und Review-Prozesse. Dieser Artikel zeigt, wie Sie CoPP so einführen, dass die Control Plane geschützt wird, ohne legitime Protokolle zu brechen oder die Entstörung unnötig zu erschweren.

Was ist die Control Plane und warum ist sie das schwächste Glied?

Ein Router besteht vereinfacht aus zwei Welten: Die Data Plane (Forwarding) transportiert Pakete im Idealfall hardwarebeschleunigt über ASICs, NPUs oder Linecards. Die Control Plane (Steuerung) besteht aus CPU, Routing-Stack, Management-Services und Protokoll-Engines. Viele Angriffe zielen nicht darauf ab, Links zu füllen, sondern die CPU zu erschöpfen: Wenn die Control Plane überlastet ist, reagieren Routing-Protokolle nicht mehr, BGP-Sessions flappen, LDP verliert Labels, ARP/ND bricht ein, und die Data Plane kann zwar theoretisch noch weiterleiten, aber das Netz wird instabil. CoPP setzt genau hier an: Es klassifiziert Control-Plane-Traffic und begrenzt ihn, sodass wichtige Protokolle weiterhin funktionieren, während Missbrauch gedrosselt oder verworfen wird.

• Control Plane ist CPU-begrenzt: PPS-starker Traffic kann schnell zu 100% CPU führen.
• Instabilität skaliert: ein einzelner überlasteter Core-Knoten kann großflächige Effekte verursachen.
• Fehlerbilder sind tückisch: „sporadische“ BGP-Flaps oder Timeouts wirken wie Routingprobleme, sind aber CP-Overload.
• Angriffsfläche ist breit: ICMP, BGP, SNMP, SSH, ND/ARP, Routing-Updates, TTL-expired, etc.

CoPP-Grundprinzip: Klassifizieren, priorisieren, begrenzen

CoPP ist kein einzelner „Schalter“. Es ist ein Policy-Ansatz: Sie definieren Klassen von Traffic, die zur Control Plane gelangen dürfen, und setzen pro Klasse Limits oder Prioritäten. Wichtig ist die Reihenfolge: Zuerst wird Traffic gematcht (z. B. BGP von definierten Peers), dann in Klassen einsortiert (z. B. Routing-Control), dann mit definierten Policern begrenzt. Eine Baseline sollte festlegen, dass CoPP immer ein Klassenmodell nutzt, statt viele Einzelregeln ohne Struktur.

• Allowlisting statt Blacklisting: nur erwarteter Control-Plane-Traffic wird explizit erlaubt.
• Klassenmodell: Routing, Management, ICMP/Diagnostics, „Essential Infrastructure“, „Default Drop“.
• Rate Limits pro Klasse: wichtige Protokolle bekommen garantierte Budgets, Noise wird gedrosselt.
• Scope-Bewusstsein: Edge-Router brauchen andere Limits als Core-Router.

Baseline-Ziele für CoPP im Provider-/Telco-Netz

Eine Baseline muss messbare Ziele definieren, damit CoPP nicht als „magische Blackbox“ betrieben wird. Für Telco- und Provider-Netze sind insbesondere folgende Ziele sinnvoll: Stabilität der Routing-Protokolle unter Angriffslast, Schutz der Managementebene, Minimierung von Kollateralschäden und schnelle Entstörbarkeit.

• Routing-Stabilität: BGP/IGP/LDP/RSVP bleiben auch bei CP-Floods funktionsfähig.
• Management-Härtung: Admin-Zugriffe nur aus Managementzonen, nicht aus Peering/Customer.
• Diagnostics funktionsfähig: ICMP für PMTUD und Troubleshooting bleibt (kontrolliert) möglich.
• Schutz vor Table/Neighbor Storms: ARP/ND/MLD/IGMP werden begrenzt, bevor CPU kollabiert.
• Nachweisbarkeit: Policers, Drops und CPU-KPIs sind sichtbar und auditierbar.

Traffic-Klassen als Baseline: Welche Kategorien in CoPP gehören

Die konkrete Umsetzung ist vendorabhängig, aber die Logik ist universell. Eine gute Baseline arbeitet mit wenigen, klaren Klassen, die den Betrieb widerspiegeln. Jede Klasse bekommt ein Budget (Rate Limit), und „Default“ wird restriktiv behandelt. Besonders wichtig ist, dass kritische Protokolle nicht mit „Noise“ in derselben Klasse landen.

• Routing Control: BGP, IGP (OSPF/IS-IS), LDP/RSVP, ggf. BFD – nur von definierten Nachbarn.
• Management: SSH, NETCONF/gNMI, SNMPv3, API-Ports – nur aus Management-Netzen.
• Infrastructure Essentials: ARP/ND, DHCP-Relay (falls relevant), NTP-Client, ggf. VRRP/HSRP – strikt begrenzt.
• Diagnostics: ICMP (z. B. echo/ttl-exceeded/unreachable), traceroute-relevante Typen – rate-limited.
• Exception/Control: definierte Sonderfälle (z. B. DDoS-Mitigation-Signale, spezifische Monitoring-Probes) – nur wenn notwendig.
• Default/Unknown: alles Unbekannte wird gedroppt oder sehr hart limitiert.

Edge vs. Core: Baseline-Profile nach Routerrolle

Ein häufiger Fehler ist eine „one size fits all“-Policy. Edge-Router sehen mehr „Internet-Noise“ und potenziell mehr Scans, während Core-Router eher kontrollierte Nachbarschaften haben, aber besonders kritisch für die Netzstabilität sind. Eine Baseline sollte deshalb Rollenprofile definieren: Edge-CoPP, Peering-CoPP, Core-CoPP, Access-CoPP. So bleiben Policies verständlich und wartbar.

• Peering/Internet Edge: striktes Default-Drop, starke ICMP/UDP-Noise-Limits, BGP nur zu Peers.
• Core: sehr strikte Neighbor-Allowlisting, stabile Budgets für IGP/LDP/RSVP/BFD, minimaler Diagnostics-Traffic.
• Aggregation/Access: zusätzlicher Fokus auf ARP/ND/DHCP-Storms, ggf. viele Kundenanschlüsse.
• DC Edge: häufig viele BGP-Sessions und EVPN/Overlay-Signale – Budgets entsprechend planen.

Control Plane Protection ist mehr als CoPP: CoPP im Kontext von ACLs und Management-Isolation

CoPP wirkt innerhalb des Routers, aber es sollte nicht die einzige Schranke sein. Eine Baseline sollte festlegen, dass Managementpfade und Nachbarschaften bereits auf Interface- und VRF-Ebene sauber begrenzt werden. Das reduziert den Traffic, der überhaupt die CoPP-Policy erreicht, und verbessert die Sicherheit. CoPP ist dann die „letzte Schutzschicht“, nicht die einzige.

• Interface ACLs: BGP/IGP nur zu definierten Nachbarn, ICMP bewusst zulassen, Rest blocken.
• Management VRF/OOB: Management ausschließlich über isolierte Pfade, nie über Peering/Customer Interfaces.
• uRPF/Anti-Spoofing: reduziert Spoofed Traffic, der sonst die Control Plane stressen könnte.
• Service Minimization: unnötige Services/Daemons deaktivieren, damit CoPP weniger schützen muss.

Rate Limits richtig dimensionieren: Baseline ohne Betriebsausfälle

Der größte CoPP-Schmerz ist nicht das Aktivieren, sondern das richtige Dimensionieren. Zu hohe Limits schützen nicht, zu niedrige Limits brechen Protokolle und erschweren Entstörung. Eine Baseline sollte daher einen systematischen Ansatz definieren: erst messen, dann konservativ limitieren, dann iterativ anpassen. Wichtig ist außerdem, dass Limits nicht nur in PPS, sondern je nach Plattform auch in bps oder „policer units“ gedacht werden müssen.

• Baseline-Messung: Normalwerte für BGP/IGP/ARP/ICMP in Ruhe und bei Events (Maintenance, Failover).
• Event-Budgets: höhere Budgets für Wartungs-/Failover-Phasen einkalkulieren, nicht nur „steady state“.
• Separate Budgets: Routing-Control getrennt von Diagnostics und Management, um Priorität sicherzustellen.
• Bursts erlauben: kurze Bursts zulassen, aber sustained floods drosseln.
• Rollback-Plan: klare Rückbauoptionen, falls Limits unerwartet Auswirkungen haben.

ICMP-Strategie: Troubleshooting ermöglichen, aber kontrollieren

Ein verbreitetes Anti-Pattern ist „ICMP komplett blocken“. Das bricht Path MTU Discovery, erschwert Traceroute und macht Incident-Diagnose langsamer. Eine CoPP-Baseline sollte ICMP bewusst behandeln: notwendige Typen zulassen, aber rate-limited. Gerade im Core ist das wichtig, weil Fehlersuche sonst über externe Tools kaum möglich ist.

• PMTUD ermöglichen: „Fragmentation Needed“/Unreachables (wo relevant) nicht pauschal droppen.
• Traceroute kontrolliert: TTL-exceeded erlaubt, aber begrenzt.
• Echo Requests begrenzen: Ping erlaubt, aber nicht unlimitiert.
• ICMP zu Infrastructure IPs: nur für notwendige Zwecke, sonst restriktiv.

Schutz vor ARP/ND-Stürmen: Baseline für L2-nahe Control-Plane-Risiken

In Aggregation und Access sind ARP- und ND-Stürme (IPv6 Neighbor Discovery) häufige Ursachen für CPU-Probleme. Gründe sind Fehlkonfigurationen, Loops, Host-Anomalien oder L2VPN-Designs mit BUM-Flooding. Eine Baseline sollte ARP/ND in CoPP als eigene Klasse führen und zusätzlich L2-Limits (Storm-Control, Max-MAC, ARP-Inspection-ähnliche Mechanismen, wo vorhanden) einfordern.

• ARP/ND Rate Limits: begrenzen, bevor CPU erschöpft.
• Max-MAC/Storm-Control: auf L2-Kanten, um Broadcast/Unknown-Unicast zu reduzieren.
• IPv6 nicht vergessen: ND/RA/RS/NA-Muster separat beobachten und limitieren.
• Detect & Quarantine: Top-Offenders identifizieren und gezielt drosseln/isolieren.

Observability: CoPP ist nur gut, wenn man es messen kann

CoPP ohne Telemetrie wird zur Blackbox. Eine Baseline sollte deshalb verpflichtende KPIs definieren: CPU, drops per class, policer hits, BGP/IGP Stability, Control-Plane-Queueing, sowie Alarme für ungewöhnliche Drop-Spikes. Wichtig ist, dass Sie nicht nur „Drops passieren“, sondern wissen, welche Klasse dropped und welche Auswirkungen das hat.

• Policer Hits pro Klasse: wie oft greift CoPP, in welchem Umfang?
• CPU/Control-Plane Health: CPU, Interrupts, Queue Drops, Prozess-Health.
• Routing Stability: BGP/IGP Flaps, Update-Spikes, Timer-bedingte Retransmissions.
• Incident Alarme: plötzliche Increase in Unknown/Default Drops, ARP/ND-Spikes, ICMP-Flood-Indikatoren.
• Change Telemetry: CoPP-Policy-Änderungen sind nachvollziehbar und alarmierbar.

Rollout- und Governance-Baseline: CoPP sicher einführen und stabil halten

CoPP ist eine sicherheitskritische Änderung, weil falsche Limits Routing und Management beeinträchtigen können. Eine Baseline sollte daher einen sicheren Rollout-Prozess definieren: zuerst in Monitor-/Permissive-Mode (wo möglich), dann canary auf Teilknoten, dann breiter Rollout. Ausnahmen müssen TTL bekommen, sonst verwässert die Policy. Zusätzlich sollten Policies versioniert sein (Policy as Code) und regelmäßig rezertifiziert werden.

• Canary Rollout: zuerst wenige Router pro Rolle/Region, Auswirkungen messen.
• Stufenmodell: permissive → balanced → strict, je nach Stabilität und Erkenntnissen.
• TTL für Ausnahmen: temporäre Erhöhungen laufen ab und müssen aktiv verlängert werden.
• Rezertifizierung: regelmäßige Reviews je Routerrolle (Edge häufiger als Core, je nach Risiko).
• Rollback-Runbook: klarer Plan, wie Policy bei Problemen zurückgenommen oder gelockert wird.

Typische Anti-Patterns: Was eine CoPP-Baseline verhindern sollte

• One-Policy-Fits-All: gleiche Limits für Edge und Core führen entweder zu Lücken oder zu Outages.
• Alles in einer Klasse: Routing und Diagnostics teilen sich Budgets und verdrängen sich gegenseitig.
• ICMP komplett blocken: PMTUD und Troubleshooting brechen, Incidents dauern länger.
• Keine Telemetrie: Drops werden nicht bemerkt oder falsch interpretiert, Tuning ist blind.
• Ausnahmen ohne Ablauf: Policy driftet, Schutzwirkung sinkt, Audits werden schwierig.

Baseline-Checkliste: Control Plane Policing (CoPP) für Router- und Core-Schutz

• Klassenmodell definiert: Routing, Management, Infrastructure (ARP/ND), Diagnostics (ICMP), Default/Unknown.
• Rollenprofile: Edge/Peering/Core/Aggregation mit unterschiedlichen Limits und Allowlists.
• Neighbor-Allowlisting: BGP/IGP/LDP/RSVP nur zu definierten Nachbarn, Interface-ACLs ergänzen CoPP.
• Management-Isolation: Admin-Zugriffe nur aus Managementzonen, nie über Peering/Customer.
• Dimensionierung methodisch: Baseline-Messung, Event-Budgets, Bursts, iterative Anpassung.
• ICMP bewusst: notwendige Typen zulassen, aber rate-limited; PMTUD und Traceroute berücksichtigen.
• ARP/ND-Storm-Schutz: eigene Limits, L2-Storm-Control/Max-MAC ergänzend.
• Observability: policer hits, drops pro Klasse, CPU/CP health, Routing-Stability und Alarme.
• Governance: Canary Rollout, Stufenmodell, TTL für Ausnahmen, Rezertifizierung und Rollback-Runbooks.

Mit einer solchen CoPP-Baseline wird die Control Plane im Telco- und Provider-Core zu einem kontrollierten, resilienten Bestandteil der Architektur: Routing bleibt stabil, Management bleibt geschützt, Diagnostics bleiben möglich und Floods – ob durch Angriffe oder Fehlkonfigurationen – führen nicht mehr automatisch zu großflächigen Netzproblemen. Genau diese Stabilität ist die Grundlage für sichere, skalierbare Netze, in denen Security nicht als Zusatz, sondern als betriebliches Grundprinzip verankert ist.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.