Site icon bintorosoft.com

CoPP Advanced: Baseline, Exception Handling und False Positives vermeiden

Red Snapper

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.

Merker

CoPP → CPU-Schutz ,   nicht → 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.

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.

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.

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.

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.

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.

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.

Operational Best Practices: CoPP „expertenfest“ machen

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

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

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