Site icon bintorosoft.com

Control Plane Policing (CoPP) auf Cisco-Routern: Wann ist es Pflicht?

Red Snapper

Control Plane Policing (CoPP) schützt die CPU und die Control Plane von Cisco-Routern vor Überlast durch Control-Plane-Traffic (z. B. Scans, DoS, fehlerhafte Broadcasts oder Routing-Stürme). Im Produktivbetrieb ist CoPP nicht „nice to have“, sondern in vielen Enterprise-Szenarien Pflicht, weil ein CPU-Overload sofort zu massiven Auswirkungen führt: Routing-Nachbarn flappen, VPN bricht, Management wird unzugänglich und der Router wird zum Single Point of Failure. Dieses Tutorial zeigt, wann CoPP als Mindeststandard gelten sollte, welche Traffic-Kategorien typischerweise geschützt werden und wie Sie CoPP so implementieren, dass Betrieb und Fehlersuche nicht leiden.

Was CoPP schützt: Control Plane vs. Data Plane

CoPP betrifft Pakete, die auf dem Router selbst terminiert werden (Control Plane): Routing-Protokolle, Management, ICMP an den Router, ARP/NDP (je Plattform) und weitere Steuerpakete. Datenverkehr, der nur durch den Router geroutet wird (Data Plane), ist nicht das Ziel von CoPP.

Wann CoPP Pflicht ist (Enterprise-Mindestkriterien)

CoPP wird zur Pflicht, wenn die Wahrscheinlichkeit von Control-Plane-Last hoch ist oder die Auswirkungen eines CPU-Overloads kritisch sind. Typische Pflicht-Szenarien sind Edge-Router, WAN-exponierte Geräte und Multi-Branch-Hubs.

Wann CoPP meist optional ist

In sehr kleinen, abgeschotteten Netzen kann CoPP optional sein – aber nur, wenn Management strikt isoliert ist und keine WAN-Exposition besteht. In Enterprise-Umgebungen ist „optional“ eher die Ausnahme.

CoPP-Designprinzip: Erlauben, priorisieren, begrenzen

CoPP ist kein „block everything“. Es ist ein Schutz, der notwendige Control-Plane-Protokolle zulässt, aber rate-limited. Wichtig ist, dass Sie kritische Protokolle priorisieren und Nicht-Notwendiges drosseln oder verwerfen.

Traffic-Kategorien für CoPP (Praxis-Katalog)

Teilen Sie Control-Plane-Traffic in wenige Klassen. Das reduziert Komplexität und macht Tuning möglich. Die exakten Details sind plattformspezifisch, das Modell bleibt stabil.

Implementierungsmuster: Class-Maps + Policy-Map auf Control Plane

Das Standardmuster ist eine MQC-Policy auf der Control Plane. Sie matchen Traffic per ACLs in Klassen und polizen pro Klasse. Werte (pps/bps) hängen von Plattform und Umgebung ab und sollten im Testfenster validiert werden.

CLI: CoPP-Gerüst (konzeptionell)

ip access-list extended ACL-COPP-MGMT
 permit tcp 10.10.10.0 0.0.0.255 any eq 22
 permit udp 10.10.10.50 0.0.0.0 any eq 161

ip access-list extended ACL-COPP-ROUTING

permit ospf any any

permit tcp any any eq 179


ip access-list extended ACL-COPP-ICMP

permit icmp any any echo

permit icmp any any echo-reply

permit icmp any any time-exceeded

permit icmp any any unreachable


class-map match-any CM-COPP-MGMT

match access-group name ACL-COPP-MGMT


class-map match-any CM-COPP-ROUTING

match access-group name ACL-COPP-ROUTING


class-map match-any CM-COPP-ICMP

match access-group name ACL-COPP-ICMP


policy-map PM-COPP

class CM-COPP-ROUTING

police 64000 conform-action transmit exceed-action transmit violate-action drop

class CM-COPP-MGMT

police 64000 conform-action transmit exceed-action transmit violate-action drop

class CM-COPP-ICMP

police 32000 conform-action transmit exceed-action drop violate-action drop

class class-default

police 16000 conform-action transmit exceed-action drop violate-action drop


control-plane

service-policy input PM-COPP

Wichtige Designhinweise: Was Sie nicht „kaputtpolicen“ dürfen

CoPP kann Routing und Betrieb stören, wenn Sie zu aggressiv sind. Schützen Sie deshalb kritische Protokolle mit ausreichend Headroom und testen Sie Konvergenz, VPN-Rekey und Managementzugriff unter Last.

Verifikation: Wie Sie CoPP korrekt prüfen

CoPP ist nur dann wirksam, wenn Zähler steigen und Drops nachvollziehbar sind. Prüfen Sie Policies, CPU und Logs. Zusätzlich sollten Sie einen Test für ICMP und Management durchführen.

CLI: CoPP-Checks (typisch)

show policy-map control-plane
show processes cpu sorted
show logging | last 50

UAT/Acceptance: Testszenarien für CoPP

Setzen Sie CoPP nicht „blind“ in Produktion. Testen Sie in einem Wartungsfenster: Managementzugriff, Routing-Stabilität, VPN-Stabilität und Diagnosefähigkeit. Dokumentieren Sie Evidence (Policy-Zähler).

Evidence-Set (Copy/Paste)

show policy-map control-plane
show processes cpu sorted
show ip ospf neighbor
show bgp summary
show crypto ikev2 sa
show logging | last 100

Betriebsmodell: Monitoring und Tuning von CoPP

CoPP ist keine „einmal konfigurieren“ Funktion. Sie muss überwacht und bei Änderungen (neue Protokolle, neue Hubs, mehr Branches) nachjustiert werden. Das NOC sollte CoPP-Drops als Signal sehen.

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

Sie erhalten

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.

Exit mobile version