SNMP Counter richtig lesen: Discards vs. Drops vs. Errors

SNMP Counter richtig lesen ist eine unterschätzte Kernkompetenz im Netzwerkbetrieb: Viele Incidents lassen sich binnen Minuten einordnen, wenn Sie Discards vs. Drops vs. Errors sauber unterscheiden und die richtigen Interface-Zähler im Kontext interpretieren. Gleichzeitig entstehen hier die meisten Fehlalarme: „Input errors steigen, also ist das Kabel kaputt“ – dabei sind es in Wirklichkeit Output drops durch Congestion. Oder „Discards auf dem Switch, also verlieren wir Pakete“ – obwohl der Zähler lediglich bewusst verworfene Frames wegen Policy, QoS oder fehlender Ressourcen zählt. Der Schlüssel ist, SNMP Counter nicht als isolierte Zahlen zu sehen, sondern als Spuren eines konkreten Datenpfads: Ingress (empfangen), Processing (Switching/Routing/ACL/QoS) und Egress (senden). Erst wenn Sie wissen, in welcher Pipeline-Stufe ein Zähler inkrementiert wird, können Sie daraus belastbare Hypothesen ableiten. In diesem Artikel lernen Sie, wie Sie SNMP Counter richtig lesen, welche MIBs und Felder relevant sind, was Discards, Drops und Errors in der Praxis bedeuten, und wie Sie typische Fehlerbilder wie Congestion, Duplex/Physical Issues, QoS-Policing und Control-Plane-Overload sauber auseinanderhalten.

Begriffe zuerst: Discards, Drops und Errors sind nicht synonym

In vielen Tools werden die Begriffe vermischt. Hersteller, NMS und Dashboards labeln unterschiedlich, und selbst innerhalb einer Plattform kann „drop“ mehrere Ursachen umfassen. Für Troubleshooting zählt daher eine pragmatische Definition, die mit SNMP-MIBs kompatibel bleibt:

• Errors: Zähler für fehlerhafte Frames/Pakete aufgrund physikalischer oder Protokollverletzungen (CRC, alignment, frame too long, FCS, symbol errors). Häufig Layer-1/2-nah.
• Discards: Pakete/Frames, die grundsätzlich „gültig“ waren, aber absichtlich verworfen wurden, weil Ressourcen fehlen oder eine Funktion sie verwirft (Queue voll, Buffer knapp, Policy/QoS, Filter, Unsupported). Discards sind nicht zwingend „Fehler“.
• Drops: Umgangssprachlicher Oberbegriff für verworfene Pakete. In SNMP-MIBs ist „drop“ oft nicht als eigener Standardcounter eindeutig definiert, sondern zeigt sich in Discards oder in vendor-spezifischen Drop-Countern (z. B. pro Queue, pro Policier, per ACL).

Wichtig: „Discards“ sind in vielen Standard-MIBs der korrekte SNMP-Begriff für Drops, die nicht als Errors klassifiziert sind. Wenn Ihr Tool also „Drops“ anzeigt, prüft zuerst, ob es in Wahrheit ifInDiscards/ifOutDiscards meint oder vendor-spezifische Queue-Drops aggregiert.

Die wichtigste Grundlage: IF-MIB und was sie wirklich misst

Für Interfaces sind die zentralen Standardzähler in der IF-MIB definiert. Historisch stammen viele Begriffe aus Zeiten, in denen Interface-Typen vielfältiger und Switching weniger komplex war. Trotzdem ist die IF-MIB bis heute der kleinste gemeinsame Nenner über Hersteller hinweg. Eine maßgebliche Referenz ist RFC 2863 (The Interfaces Group MIB).

Die Klassiker, die in praktisch jedem Monitoring vorkommen:

• ifInOctets / ifOutOctets: Bytes rein/raus (Traffic-Volumen).
• ifInUcastPkts / ifOutUcastPkts: Unicast-Pakete rein/raus (Paketvolumen).
• ifInErrors / ifOutErrors: Fehler beim Empfangen/Senden (breite Sammelzähler).
• ifInDiscards / ifOutDiscards: verworfene, ansonsten valide Pakete/Frames (Ressource/Policy/Implementation).

Für moderne Links sind außerdem die High-Capacity-Counter relevant (64-bit), z. B. ifHCInOctets/ifHCOutOctets, weil 32-bit Counter auf schnellen Links schnell überlaufen können. Dashboards, die auf 32-bit bleiben, erzeugen dann „Zacken“ oder negative Raten.

Ingress vs. Egress: Warum die Richtung entscheidend ist

Viele Fehlinterpretationen entstehen, weil Ingress- und Egress-Zähler durcheinandergeraten. Ein einfaches Denkmodell:

• Ingress (Input): Was kommt physisch am Interface an? Hier sehen Sie häufig L1/L2-Probleme (CRC, FCS, alignment), aber auch Drops durch fehlende Input-Buffer.
• Processing: Was passiert im Gerät? Hier wirken ACLs, QoS-Klassifizierung, Policers, Routing-Lookups, TCAM-Engpässe, Control-Plane-Protection.
• Egress (Output): Was verlässt das Gerät? Hier entstehen häufig Drops/Discards durch Queueing/Buffer, Shaping, Policing oder Congestion.

Praktisch bedeutet das: ifOutDiscards sind sehr oft ein Congestion-Signal (oder ein QoS/Policer-Signal), während ifInErrors häufiger auf physische Probleme hindeuten. Das ist keine absolute Regel, aber ein starkes Erstindikator-Muster.

Errors richtig lesen: Wann es wirklich „Kabel/Optik“ ist

ifInErrors/ifOutErrors sind Sammelzähler. Sie sagen nicht automatisch „CRC“. Viele Geräte addieren hier mehrere Fehlerklassen hinein. Trotzdem gibt es typische Muster:

Typische Ursachen für Input Errors

• CRC/FCS-Fehler: Bitfehler auf dem Medium, schlechte Optik, verschmutzte Stecker, defekte Patchkabel, falsche Optik, zu hohe Dämpfung.
• Alignment/Framing Errors: häufig bei Duplex-/Autoneg-Problemen oder PHY-Fehlkonfigurationen, seltener in modernen Full-Duplex-Ethernet-Links.
• Giant/Runts: Frames zu groß/zu klein; kann auf MTU-Mismatch, fehlerhafte NICs oder Encapsulation-Probleme hindeuten.
• Symbol Errors/FEC Events (vendor-spezifisch): besonders bei höheren Geschwindigkeiten (10/25/40/100G) wichtig, oft außerhalb der Standard-IF-MIB.

Wie Sie Errors verifizieren, statt zu raten

• Korrelation mit Layer-1-Telemetrie: Optik-DOM (Rx/Tx Power), FEC-Counter, Link-Flaps. Viele davon sind vendor-spezifisch und nicht in ifInErrors enthalten.
• Richtung beachten: CRC steigt meist auf der empfangenden Seite. Wenn nur eine Seite CRC sieht, ist das ein starker Hinweis auf physische Richtung/Optik.
• Zeitfenster: Stetig steigende CRC über Stunden ist ein anderes Problem als ein kurzer Burst nach einem Patchvorgang.

Discards richtig lesen: Der häufigste Counter-Missverständnis

ifInDiscards/ifOutDiscards zählen typischerweise Pakete/Frames, die nicht wegen „Error“ verworfen wurden, sondern weil das Gerät sie nicht weiterverarbeiten oder nicht senden konnte/wollte. Das ist oft hochrelevant – aber nur, wenn Sie den Grund eingrenzen.

Häufige Ursachen für Output Discards

• Congestion (Queue voll): Der Egress-Link ist Engpass, Pakete stauen sich, Buffer laufen voll, Tail Drop oder AQM greift.
• QoS/Policing: Ein Policier verwirft Traffic oberhalb eines CIR; das kann als Discard auftauchen oder in vendor-spezifischen Policier-Drops.
• Shaping/Queue-Limits: Shaper begrenzen Rate, Queue-Limits greifen, Drops entstehen in bestimmten Klassen.
• Microbursts: Sehr kurze Peaks füllen Buffers, die SNMP im 60s-Polling nur als Discard-Anstieg zeigt, ohne die Spikestuktur zu erklären.

Häufige Ursachen für Input Discards

• Input Buffer Pressure: Das Gerät kann Burst-Eingang nicht puffern (z. B. bei oversubscribed ASIC/linecard).
• Control-Plane/Software-Path Limit: Pakete, die zur CPU müssen (ARP, BGP, ICMP, TTL-expired) werden gedroppt, wenn CoPP/Rate-Limits greifen.
• ACL/Policy Implementation: Je nach Plattform zählen „dropped by policy“ nicht als Errors, sondern als Discards oder in separaten ACL-Countern.

„Drops“ in der Praxis: Wo Sie echte Drop-Ursachen finden

Wenn Ihr Monitoring „Drops“ zeigt, ist der nächste Schritt: herausfinden, welche Art von Drop es ist. Standard-IF-MIB reicht dafür oft nicht. Experten nutzen deshalb ergänzende Counter:

• Queue-spezifische Drops: Drops pro QoS-Klasse/Queue (Tail Drop, WRED/RED, ECN Marks). Diese sind häufig vendor-spezifisch, liefern aber den höchsten Troubleshooting-Wert.
• Policer Drops: Drops pro Policier (CIR/EIR), ebenfalls oft vendor-spezifisch.
• ACL/Firewall Counters: Hits und Drops pro Regel (zeigt sofort, ob „Policy blockt“).
• NAT/Session Limits: Port Exhaustion oder Session-Table Pressure äußert sich manchmal als Drops/Discards, aber die eigentlichen Indikatoren sind NAT/Session-Counter.

Die zentrale Idee: ifOutDiscards sagt Ihnen „irgendwas wurde verworfen“, aber Queue-/Policy-Counter sagen Ihnen „warum“. Ohne „warum“ ist jeder Fix ein Ratespiel.

Das häufigste Fehlerbild: Discards steigen, aber Users merken es nur manchmal

Discards sind oft burstig und treffen nicht alle Flows gleich. Einige Anwendungen (VoIP/Video) reagieren extrem empfindlich auf wenige Prozent Loss, während Bulk-Traffic es „wegsteckt“. Deshalb kann ein geringer Discard-Anstieg bereits ein großes User-Problem sein, insbesondere bei Echtzeitverkehr.

• Indiz: ifOutDiscards steigen, aber ifOutOctets sind „normal“; User melden Jitter/Audioaussetzer.
• Hypothese: Queueing/Buffering trifft Realtime-Klasse oder Best-Effort ohne QoS.
• Nächster Schritt: Queue-Counter (Drops pro Klasse), DSCP-Verteilung, ggf. Packet Capture oder High-Frequency Telemetry.

Errors vs. Discards im Vergleich: schnelle Entscheidungslogik

Eine praxistaugliche Entscheidungslogik für On-Call:

• ifInErrors steigt: zuerst Layer 1/2 prüfen (Optik, Kabel, DOM, CRC, Duplex). Wenn gleichzeitig Link-Flaps, ist L1 sehr wahrscheinlich.
• ifOutDiscards steigt: zuerst Congestion/QoS prüfen (Egress Engpass, Queue-Drops, Policer, Shaper).
• ifInDiscards steigt: CPU/CoPP/Control-Plane-Pfade, Input-Buffer, Oversubscription oder Filter/Policy prüfen.
• ifOutErrors steigt: seltener, aber kann auf egress-seitige Hardware-/PHY-Probleme oder Treiber/ASIC-Themen hindeuten; vendor-spezifische Detailcounter sind hier besonders wichtig.

SNMP Counter sind Zähler – keine Raten: So vermeiden Sie typische Monitoring-Fehler

SNMP liefert meist monotone Counter. Ihre Monitoring-Software berechnet daraus Raten (Delta/Intervall). Daraus ergeben sich typische Fallstricke:

• Counter Wrap: 32-bit Counter laufen bei hohen Raten schnell über. Nutzen Sie 64-bit (HC) Counter, sonst entstehen falsche Peaks.
• Polling-Intervall: Mit 5-Minuten-Polls glätten Sie Microbursts. Für Drops/Queueing sind kürzere Intervalle oder Streaming Telemetry besser.
• Reset durch Interface-Flap: Counter können bei Link-Down oder Linecard-Reset zurückgesetzt werden; Monitoring muss das erkennen.
• Aggregation im NMS: Manche Tools summieren Discards und Errors in einen „Drops“-Graphen. Das ist bequem, aber diagnostisch gefährlich.

Konkrete Interpretationsbeispiele: Was Sie aus typischen Zählerkombinationen ableiten können

Beispiel: Hohe ifOutDiscards, aber keine ifInErrors

• Wahrscheinlich: Congestion am Egress oder QoS/Policing.
• Prüfen: Queue-Drops, Interface-Auslastung, Shaper/Policer, Microbursts-Indizien, DSCP-Markings.

Beispiel: ifInErrors steigen auf einer Seite, Gegenstelle sieht kaum Errors

• Wahrscheinlich: physisches Problem in Empfangsrichtung (Rx) oder Optik/Kabel zwischen den Geräten.
• Prüfen: DOM Rx-Power, FEC, CRC detail counters, Stecker reinigen, Patchkabel tauschen, Optik tauschen.

Beispiel: ifInDiscards steigen, CPU ist hoch

• Wahrscheinlich: Control-Plane-Protection oder CPU-Path Drops (ARP/ND Storm, Routing-Events, ICMP Flood, punted traffic).
• Prüfen: CoPP/Control-Plane Counters, ARP/ND Rate, Routing-Protokoll-Logs, ACLs für punted traffic.

Beispiel: Keine Discards/Errors, aber User melden Latenz

• Wahrscheinlich: Bufferbloat/Queueing ohne Drops, asymmetrische Pfade, DNS/Proxy/TLS-Probleme oder Applikationslatenz.
• Prüfen: RTT unter Last, Queue occupancy (nicht nur drops), Flow Telemetry, Packet Captures an mehreren Punkten.

SNMP und IF-MIB im Kontext moderner Ethernet-Realität

Ein wichtiger E-E-A-T-Punkt: IF-MIB ist bewusst generisch. Moderne Ethernet-Fehlerbilder (FEC-Korrekturen, PCS-Layer Events, SerDes-Errors) tauchen häufig nicht präzise in ifInErrors auf, sondern in erweiterten MIBs oder Telemetrie-Modellen. Trotzdem bleibt IF-MIB nützlich, weil sie eine stabile Baseline liefert: Wenn ifInErrors plötzlich steigt, ist das ein starkes Signal – aber für RCA benötigen Sie oft Detailcounter.

Wenn Sie Interface-Typen und ihre Bedeutung in SNMP nachvollziehen möchten, ist die IANA ifType Registry eine hilfreiche Referenz.

Praktisches Troubleshooting-Runbook: SNMP Counter in 15 Minuten sinnvoll nutzen

• Minute 0–3: Betroffenes Interface und Zeitfenster definieren. Nutzen Sie 64-bit Counter (HC). Prüfen: steigen Discards, Errors oder beides?
• Minute 3–6: Richtung trennen: Input vs. Output. ifInErrors → L1/L2-Hypothese, ifOutDiscards → Congestion/QoS-Hypothese, ifInDiscards → CPU/Policy/Buffer-Hypothese.
• Minute 6–9: Korrelation: Interface-Auslastung, Queue-/Policy-Counter, Link-Flaps, CPU-Spikes, Routing-Events.
• Minute 9–12: Gegenstelle prüfen: Sieht das Peer-Interface ähnliche Muster? Asymmetrien (nur eine Seite) sind oft entscheidend.
• Minute 12–15: Beweis vertiefen: gezielter Packet Capture (tcpdump/Wireshark) oder High-Frequency Telemetry für Queueing/Microbursts. Maßnahmen ableiten (QoS, Shaping, Optik/Kabel, CoPP).

Weiterführende Quellen

• RFC 2863 für IF-MIB (Discards, Errors, Octets, High-Capacity Counters)
• RFC 3416 für SNMPv2 Operations (Grundlagen zum Umgang mit SNMP-Daten)
• IANA ifType Registry zur Interpretation von Interface-Typen
• Wireshark Dokumentation für die Verifikation von Drop-/Error-Hypothesen per Packet Capture
• tcpdump Manpage für schnelle Captures und Beweisführung, wenn SNMP Counter nicht ausreichen

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.