CoPP Advanced: Baseline, Exception Handling und False Positives vermeiden

Control Plane Policing (CoPP) schützt Cisco Router vor Angriffen und Fehlkonfigurationen, indem es Traffic zur Control Plane (CPU) klassifiziert und rate-limitiert. In der Praxis scheitern CoPP-Rollouts aber selten an Syntax, sondern an Betriebsrealität: fehlende Baseline-Messungen, zu harte Policers, nicht erfasste Ausnahmefälle (z. B. Routing-Protokolle, ICMPv6/ND, NTP, Telemetrie) und daraus resultierende False Positives. Ein „zu strenges“ CoPP wirkt wie ein zufälliger Router-Bug: OSPF-Nachbarn flappen, BGP-Sessions resetten, SSH hängt, IPv6 wird instabil. Dieser Advanced-Guide zeigt, wie du CoPP baselined, Exceptions sauber modellierst und False Positives vermeidest – mit praxisnahen Patterns für IOS XE.

Control Plane verstehen: Was CoPP wirklich schützt

CoPP wirkt nur auf Traffic, der in die CPU (Punt/Process-Switch) geht. Transit- und Hardware-forwarded Traffic wird meist nicht durch CoPP beeinflusst. Entscheidend ist daher, welche Pakete „punten“: Routing-Control, ARP/ND, TTL-Expired, Management, bestimmte Features.

• Control Plane: Routing-Protokolle, ARP/ND, Management, ICMP-Fehler
• Data Plane: regulärer Transitverkehr (CEF/ASIC)
• Punt Paths: Pakete, die die Fast Path verlassen (wichtig für Drops)

Merker

$\text{CoPP}\to \text{CPU-Schutz}, \text{nicht}\to \text{Transit-Firewall}$

Baseline zuerst: Ohne Messwerte ist CoPP nur Raten

Bevor du Policers setzt, brauchst du eine Baseline: Welche Control-Plane-Paketraten sind normal, welche Peaks treten bei Konvergenz auf (BGP/OSPF), wie viel ICMP/ND erzeugt dein Netz, wie viel Management-Traffic existiert? Ohne Baseline sind False Positives vorprogrammiert.

• Normalbetrieb: stabile pps-Raten pro Klasse
• Konvergenz/Events: kurzfristige Peaks (Rekeys, Link Flaps, SPF)
• Wartungsfenster: bewusst höhere Control-Plane-Last

Baseline-Checks (IOS XE Pattern)

show processes cpu sorted
show platform hardware qfp active statistics drop
show control-plane host open-ports
show ip traffic
show ipv6 traffic

CoPP-Designprinzip: Klassen nach „Betriebsnotwendigkeit“

Ein bewährtes Expertenmuster ist, Control-Plane-Traffic in wenige, semantische Klassen zu teilen: Routing, Management, ICMP/Fehler, Infrastruktur (ARP/ND), und „Scavenger“ (alles Unbekannte). Jede Klasse bekommt passende Policers – nicht alle gleich streng.

• CRITICAL: Routing-Protokolle (BGP/OSPF/IS-IS), ggf. BFD
• MGMT: SSH/SNMP/NETCONF/Telemetry (nur von Admin-Netzen)
• INFRA: ARP, DHCP Relay, IPv6 ND/RA (für Betrieb essenziell)
• ICMP: nötige Fehler/PMTUD/TTL Exceeded (sonst Blackholes)
• DEFAULT/SCAVENGER: unbekannt → stark limitieren

False Positives verstehen: Drei klassische Ursachen

False Positives sind meist nicht „CoPP kaputt“, sondern unvollständige Klassifizierung oder falsche Rate-Limits. Drei Muster sind besonders häufig und sollten im Design explizit berücksichtigt werden.

• Routing-Peaks nicht eingeplant (Konvergenz, Rekey, GR)
• IPv6 ICMP/ND zu hart limitiert (RA/NS/NA/Packet Too Big)
• Management-Traffic wird nicht nach Quelle eingeschränkt (Scan-Flood)

Baseline-Methodik: In 3 Schritten zu belastbaren Policers

Statt „hart deployen“ ist die bewährte Methodik: (1) Classify-only messen, (2) konservativ limitieren, (3) iterativ härten. So findest du legitime Peaks, bevor du produktive Protokolle kaputt machst.

• Schritt 1: Klassen definieren und Counter sammeln
• Schritt 2: Policers großzügig setzen, Drops beobachten
• Schritt 3: Grenzwerte reduzieren, bis sicher, ohne Flaps

Konfigurationspattern: Class-Maps für typische CoPP-Klassen

CoPP nutzt Class-Maps (match access-group/protocol) und Policy-Maps mit police. Das folgende Pattern ist bewusst modular: du kannst einzelne Klassen ergänzen, ohne alles zu zerlegen.

ACLs für Control-Plane Klassen (Pattern)

ip access-list extended ACL_COPP_ROUTING
 permit tcp any any eq 179
 permit ospf any any
 permit eigrp any any
ip access-list extended ACL_COPP_MGMT

permit tcp 10.99.0.0 0.0.0.255 any eq 22

permit udp 10.99.0.0 0.0.0.255 any eq 161

permit tcp 10.99.0.0 0.0.0.255 any eq 830
ip access-list extended ACL_COPP_ICMP

permit icmp any any time-exceeded

permit icmp any any unreachable

permit icmp any any packet-too-big

Class-Maps

class-map match-any CM_COPP_ROUTING
 match access-group name ACL_COPP_ROUTING
class-map match-any CM_COPP_MGMT

match access-group name ACL_COPP_MGMT
class-map match-any CM_COPP_ICMP

match access-group name ACL_COPP_ICMP

Policy-Design: Policer-Werte konservativ starten

Die konkreten pps/bps-Werte sind netzabhängig. Eine robuste Strategie ist: Routing eher großzügig, ICMP/ND so, dass PMTUD/Fehler stabil bleiben, Management streng nach Source beschränkt, Scavenger sehr hart. Wichtig: Burst zulassen, um kurze Peaks abzufangen.

Policy-Map (Pattern)

policy-map PM_COPP
 class CM_COPP_ROUTING
  police 2000000 40000 conform-action transmit exceed-action drop
 class CM_COPP_MGMT
  police 500000 20000 conform-action transmit exceed-action drop
 class CM_COPP_ICMP
  police 500000 20000 conform-action transmit exceed-action drop
 class class-default
  police 200000 10000 conform-action transmit exceed-action drop

Control Plane Service-Policy binden

control-plane
 service-policy input PM_COPP

Exception Handling: Was du fast immer explizit erlauben musst

Viele CoPP-Policies brechen im Betrieb, weil „Kleinkram“ fehlt, der aber essenziell ist. Experten-Policies behandeln diese Ausnahmefälle explizit, statt sie in class-default zu verstecken.

• ARP (IPv4) und IPv6 ND (NS/NA, DAD)
• ICMP für PMTUD (IPv4 Frag Needed, IPv6 Packet Too Big)
• TTL Exceeded (Traceroute, Troubleshooting)
• NTP (Zeitbasis für Logs, PKI, Auth)
• DHCP Relay/Helper (wenn Router Relay spielt)

IPv6 ND/ICMPv6 Hinweise

Wenn du IPv6 betreibst, ist ICMPv6 kein „nice to have“. ND und PMTUD sind zwingend. ICMPv6 zu hart zu limitieren erzeugt schwer reproduzierbare Störungen.

False Positives vermeiden: Guardrails auf zwei Ebenen

CoPP ist nur ein Teil. Viele False Positives entstehen, weil du unautorisierten Management-Traffic überhaupt erst zur CPU lässt. Best Practice ist: Management-Zugriff schon vor CoPP auf Quellen einschränken (VTY ACL, VRF, OOB), dann CoPP als zweite Schutzschicht.

• VTY ACL: SSH nur von Admin-Netzen
• MGMT VRF/OOB: Management getrennt vom Transit
• CoPP: schützt zusätzlich gegen Floods/Fehlkonfig

Monitoring und Iteration: CoPP ist kein „Set and Forget“

Nach dem Rollout brauchst du Sichtbarkeit: Wo dropt CoPP? Sind Drops legitim (Angriff/Scan) oder False Positives (Routing flaps)? Ohne Monitoring ist CoPP ein Risiko.

CoPP Counter prüfen

show policy-map control-plane
show policy-map control-plane interface

Konvergenz-Events korrelieren

show logging | include BGP|OSPF|IS-IS|COPP|drop
show processes cpu sorted

Typische Edge-Cases: Konvergenz, Rekey, Telemetry

Diese Edge-Cases erzeugen legitime Control-Plane-Peaks. Wenn du sie nicht einplanst, werden sie zu False Positives.

• IGP/BGP Konvergenz nach Link Flap
• IPsec Rekey/DPD Events bei vielen Tunneln
• Telemetry/NETCONF Polling-Spikes (Management plane)
• IPv6 ND Storms (DAD/Neighbor churn)

Operational Best Practices: CoPP „expertenfest“ machen

Diese Prinzipien machen CoPP robust und auditierbar, ohne produktive Protokolle zu gefährden.

• Baseline messen, dann iterativ härten
• Routing/ND/PMTUD als „critical“ behandeln
• Management streng nach Source begrenzen, nicht nur rate-limitieren
• Burst zulassen, um legitime Peaks abzufangen
• Runbooks: Pre/Post Checks und Alarmierung auf CoPP Drops

Quick-Runbook: CoPP False Positives unter Zeitdruck

Diese Checkliste hilft, schnell zu klären, ob CoPP legitimen Traffic droppt und welche Klasse betroffen ist.

show policy-map control-plane
show policy-map control-plane | include drop|exceed
show processes cpu sorted
show ip traffic
show ipv6 traffic
show logging | include COPP|drop|BGP|OSPF|ND

Konfiguration speichern

Router# copy running-config startup-config

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.