show platform hardware qfp active statistics drop: Drops analysieren wie ein Pro

Der Befehl show platform hardware qfp active statistics drop ist eines der stärksten Werkzeuge auf IOS XE Plattformen mit QFP (Quantum Flow Processor), um echte Data-Plane-Drops zu analysieren. Während show interfaces oft nur „Drops irgendwo“ zeigt, liefert QFP-Statistik die Drop-Gründe direkt aus der Forwarding-Pipeline. Wer die Ausgabe richtig liest und sauber mit Interface-, QoS- und Control-Plane-Signalen korreliert, findet die Ursache deutlich schneller – statt im Blindflug an ACLs, MTU oder Routing zu drehen.

Was QFP-Drops sind (und was nicht)

QFP-Drops stammen aus der Hardware-/Forwarding-Pipeline. Das sind nicht automatisch die gleichen Drops, die du im Interface-Output siehst. Viele Incidents sind „Hardware drop“, obwohl CPU/IOSd ruhig ist – oder umgekehrt.

• QFP-Drops: Drop-Gründe im Forwarding-Pfad (Data Plane)
• Interface-Drops: Queue-/Buffer-Drops am Interface (kann über/unter QFP liegen)
• Control-Plane-Drops: CoPP/CPU-Policer (separat prüfen)

Wann du genau diesen Befehl einsetzen solltest

Der Befehl ist besonders hilfreich, wenn Traffic „sporadisch“ verschwindet, Links nicht ausgelastet wirken oder Drops nur unter Last auftreten. In diesen Fällen liefert QFP meist die belastbarste Erklärung.

• Durchsatz bricht ein, obwohl Link nicht voll ist
• Nur bestimmte Flows/Protokolle funktionieren nicht
• VPN/Overlay „steht“, aber Anwendungen droppen
• Viele kleine Pakete (pps hoch), CPU moderat, trotzdem Loss

Grundworkflow: Drops analysieren in 5 Schritten

Unter Zeitdruck brauchst du ein wiederholbares Vorgehen. Ziel ist: erst messen und eingrenzen, dann erst an Konfigurationen ändern.

• Baseline bilden (Counter-Stand, Zeitraum, Last)
• Top-Drop-Reasons identifizieren (QFP)
• Richtung/Ort bestimmen (Ingress/Egress, Interface, Queue, Policy)
• Mit Interface/QoS/NAT/VPN/CoPP korrelieren
• Hypothese testen (kleiner Fix) und erneut messen

Step 1: Baseline und Messfenster sauber setzen

QFP-Counter sind kumulativ seit dem letzten Reset/Reload. Ohne Messfenster vergleichst du Äpfel mit Birnen. Arbeite mit zwei Messpunkten im Abstand von z. B. 60–120 Sekunden.

Minimaler Baseline-Snapshot

show clock
show platform hardware qfp active statistics drop
show interfaces | include drops|CRC|error|rate
show policy-map interface <wan-interface>
show policy-map control-plane

Differenz-Logik (als Denkmodell)

$\text{DropRate}\approx \frac{\text{Drops(t2)}–\text{Drops(t1)}}{\text{t2}–\text{t1}}$

Step 2: QFP-Drops auslesen und „Top 3“ auswählen

Die Ausgabe enthält typischerweise viele Zeilen. Unter Zeitdruck fokussierst du auf die Drop-Reasons, die im Messfenster am stärksten steigen. Alles andere ist Hintergrundrauschen.

Befehl

show platform hardware qfp active statistics drop

Interpretationsregel

• Nur steigende Counter im Messfenster sind relevant
• Ein einzelner sehr großer Counter kann historisch sein
• Mehrere kleine Counter können gemeinsam ein Symptom erklären (z. B. QoS + MTU)

Step 3: Drop-Reasons in Kategorien übersetzen

QFP-Drops wirken im ersten Moment wie „interne Codes“. In der Praxis lassen sie sich meist in wenige Kategorien einordnen. Damit findest du sofort den passenden nächsten Check.

• Queue/Buffer: Überlastung, Shaping/Policing, Microbursts
• Policy/Security: ACL/ZBF, uRPF, Anti-Spoofing, Rate-Limits
• Encapsulation/MTU: Fragmentierung, PMTUD, Overhead (VPN/PPPoE)
• Forwarding/Adjacency: ARP/ND unvollständig, Next-Hop nicht erreichbar
• Malformed/Exceptions: ungültige Header, Checksums, Pakete werden verworfen

Step 4: Korrelation mit den drei Pflichtquellen

QFP sagt dir „warum gedroppt“. Die anderen Befehle sagen dir „wo“ und „unter welchen Bedingungen“. Ohne Korrelation ist die Diagnose oft unvollständig.

Quelle A: Interface-Statistiken (physisch + Queue)

show interfaces <wan-interface>
show interfaces <wan-interface> | include drops|queue|error|CRC

Quelle B: QoS-Policy (wenn aktiv)

show policy-map interface <wan-interface>

Quelle C: Control-Plane/CPU (Punt- oder Flood-Symptome)

show policy-map control-plane
show processes cpu sorted

Die häufigsten Drop-Muster und ihre „Next Commands“

Diese Muster sind praxiserprobt: Du erkennst sie an der Kombination aus QFP-Drops, Interface-Countern und QoS-Output. Die Kommandos sind so gewählt, dass du schnell eine Hypothese bestätigen oder verwerfen kannst.

Muster 1: Queue-/Buffer-Drops (Congestion / Microbursts)

Symptom: Drops steigen unter Last, besonders am WAN-Egress. Oft sieht man gleichzeitig Output Drops oder QoS-Drops in class-default.

• Check: Shaping aktiv? Provider-Rate korrekt?
• Check: Drops in QoS-Klassen? Voice clean, default dropt?

show policy-map interface <wan-interface>
show interfaces <wan-interface> | include output rate|output drops|queue

Typischer Fix-Pfad

• Shaper auf reale Upload-Rate setzen (Congestion im Router, nicht beim Provider)
• Prioritätsklassen begrenzen (LLQ nicht zu groß)
• Wenn Microbursts: Queue/Buffer-Strategie prüfen, ggf. Traffic glätten

Muster 2: Policing-Drops (hartes Rate-Limit)

Symptom: Drops korrelieren stark mit Policer-Zählern; Durchsatz wirkt „gedeckelt“, TCP leidet durch Retransmits.

show policy-map interface <interface>
show policy-map control-plane

• Check: Policer am richtigen Ort (in/out)?
• Check: Exceed-Action drop vs. remark?

Muster 3: MTU/Fragmentierung/PMTUD-Probleme

Symptom: „Webseiten laden nicht“, große Transfers brechen, kleine Pings gehen. Bei VPN/Overlays häufig durch Overhead. Drops können bei größeren Frames entstehen, ohne dass der Link voll ist.

show interfaces <outside-or-tunnel> | include MTU
ping <remote-ip> df-bit size 1400
ping <remote-ip> df-bit size 1472

• Fix: MSS-Clamping am Tunnel/WAN (TCP)
• Fix: IP MTU am Tunnel (auch für UDP), PMTUD nicht blocken

interface tunnel0
 ip tcp adjust-mss 1360

Muster 4: ACL/Zonenpolicy/uRPF-Drops (Policy-bedingt)

Symptom: Nur bestimmte Quellen/Ziele droppen, oft nach Changes. QFP-Drops steigen, während Interface-Errors niedrig bleiben. Häufig sind Hit-Counter in ACLs oder ZBF-Policies sichtbar.

show ip access-lists
show run | include access-group
show policy-map interface <zone-interface>

• Check: Richtung (in/out) und Reihenfolge (implicit deny)
• Check: uRPF auf Interfaces, asymmetrische Pfade

uRPF-Check (wenn genutzt)

show running-config interface <int> | include verify unicast
show ip route <source-ip>

Muster 5: Adjacency/Next-Hop-Probleme (Incomplete ARP/ND)

Symptom: Routing sieht korrekt aus, aber Traffic verschwindet. QFP-Drops können steigen, wenn Next-Hop nicht aufgelöst ist oder L2 nicht passt.

show ip cef <destination> detail
show adjacency detail | include Incomplete|incomplete
show arp | include <next-hop-ip>

• Check: VLAN/Subinterface dot1Q korrekt?
• Check: ARP wird irgendwo gefiltert?

Muster 6: Punt-/CPU-Pfad als versteckter Bottleneck

Symptom: pps hoch, CPU hoch, Drops steigen je nach CoPP/CPU-Limits. Das ist oft kein klassischer „QFP drop“, sondern ein CPU/Control-Plane-Limit, das indirekt Data-Plane beeinflusst.

show processes cpu sorted
show policy-map control-plane
show logging | include %PUNT|COPP|CPU

• Check: Flood/Scan? ICMP/SSH/SNMP-Spikes?
• Fix: CoPP-Tuning, Management abschotten, Rate-Limits sauber setzen

Profi-Tipps: Messung, Hygiene, Beweisführung

Die Qualität deiner Diagnose hängt stark von deiner Messdisziplin ab. Diese Punkte machen den Unterschied zwischen „gefunden“ und „vermutet“.

• Immer mit Messfenster arbeiten (t1/t2), nicht mit „großen Countern“ argumentieren
• Parallel belastbaren End-to-End Test fahren (Ping/Traceroute/iperf), damit du Korrelation hast
• Bei QoS: Counters pro Klasse sind oft aussagekräftiger als Interface-Drops
• Bei VPN: IPsec Counters (encaps/decaps) gegen QFP-Drops spiegeln

End-to-End Test (Beispiel)

ping <remote-host> source <source-ip>
traceroute <remote-host> source <source-ip>
show crypto ipsec sa

Quick-Runbook: Drops analysieren in 90 Sekunden

Dieses Minimal-Runbook ist für Incident-Triage gedacht. Es liefert dir: Drop-Reasons, Richtung, QoS- und CPU-Korrelation.

! t1
show clock
show platform hardware qfp active statistics drop
show interfaces <wan> | include rate|drops|error|CRC
show policy-map interface <wan>
show policy-map control-plane
show processes cpu sorted
! 60-120s warten unter reproduzierbarer Last
! t2

show platform hardware qfp active statistics drop

show interfaces  | include rate|drops|error|CRC

show policy-map interface 

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.