Site icon bintorosoft.com

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

Red Snapper

Retro computer with monitor mouse and keyboard. Business concept. 3d render illustration.

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.

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.

Grundworkflow: Drops analysieren in 5 Schritten

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

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)

DropRate ≈ Drops(t2) – Drops(t1) t2 – 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

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.

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.

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

Typischer Fix-Pfad

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

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
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>

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>

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

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“.

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

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