Die Kurzantwort:

Interface Drops und Queue Drops entstehen, wenn Netzwerkkomponenten Pakete verwerfen. Das kann passieren, wenn ein Interface, eine Warteschlange oder ein Puffer mehr Daten erhält, als verarbeitet oder weitergeleitet werden können. Drops führen zu Paketverlust und können dadurch Latenzspitzen, Jitter, TCP-Retransmissions, niedrigeren Durchsatz und schlechtere Anwendungsperformance verursachen. Besonders kritisch ist, dass Drops auch bei niedriger durchschnittlicher Auslastung auftreten können, zum Beispiel durch Microbursts oder kurzzeitige Lastspitzen.

Drops zeigen,dass Pakete verworfen wurden

In einem idealen Netzwerk werden Datenpakete von Gerät zu Gerät weitergeleitet, bis sie ihr Ziel erreichen. In der Praxis kann es jedoch passieren, dass Netzwerkkomponenten Pakete nicht weiterleiten können und sie deshalb verwerfen. Solche verworfenen Pakete werden häufig als Drops bezeichnet.

Drops sind ein wichtiges Warnsignal. Sie zeigen, dass Daten nicht erfolgreich über eine bestimmte Stelle im Netzwerk transportiert wurden. Für Anwendungen kann das erhebliche Auswirkungen haben, auch wenn die Verbindung grundsätzlich erreichbar ist.

Wenn Pakete verworfen werden, entsteht Paketverlust. Bei TCP-Verbindungen führt Paketverlust häufig zu Retransmissions. Bei Echtzeitkommunikation können verlorene Pakete zu Aussetzern, Jitter, schlechter Sprachqualität oder niedrigeren MOS-Werten führen.

Besonders tückisch ist: Drops können sehr kurz auftreten. Eine Verbindung kann im Durchschnitt unkritisch ausgelastet wirken und trotzdem in einzelnen Momenten Pakete verlieren.

Interface Drops und Queue Drops im Detail

Was sind Interface Drops?

Interface Drops sind verworfene Pakete an einer Netzwerkschnittstelle. Eine solche Schnittstelle kann zum Beispiel ein Port an einem Switch, Router, Firewall, Server, Access Point oder VPN-Gateway sein.

Ein Interface empfängt oder sendet Pakete. Wenn es Pakete nicht rechtzeitig verarbeiten, zwischenspeichern oder weiterleiten kann, können Pakete verworfen werden.

Interface Drops können in verschiedenen Situationen auftreten: beim Empfang von Paketen, beim Senden von Paketen, bei überlasteten Ports, bei vollen Puffern, bei zu vielen Paketen in kurzer Zeit, bei fehlerhaften oder instabilen Verbindungen, bei falsch konfigurierten Schnittstellen oder bei überlasteten Netzwerkkomponenten.

Nicht jeder Drop hat dieselbe Ursache. Deshalb ist es wichtig, Drops nicht nur als Zählerwert zu betrachten, sondern im Zusammenhang mit Auslastung, Fehlern, Paketverlust, Latenz, Jitter und Durchsatz zu analysieren.

Was sind Queue Drops?

Queue Drops entstehen, wenn Pakete in einer Warteschlange verworfen werden. Netzwerkgeräte verwenden Queues, um Pakete vorübergehend zwischenzuspeichern, bevor sie weitergeleitet werden.

Eine Queue funktioniert vereinfacht wie eine Warteschlange. Wenn mehr Pakete ankommen, als sofort verarbeitet oder gesendet werden können, werden sie kurz zwischengespeichert. Ist die Queue voll, können weitere Pakete nicht mehr aufgenommen werden. Diese Pakete werden verworfen.

Queue Drops entstehen häufig bei kurzfristiger Überlastung oder bei Verkehrsspitzen.

Typische Ursachen sind: Microbursts, überlastete Links, zu kleine Puffer, falsche QoS-Regeln, fehlende Priorisierung, plötzliche Datenmengen, parallele Dateiübertragungen, Backup- oder Replikationsprozesse, Cloud-Synchronisationen, Traffic-Shaping oder Policing sowie Firewall- oder VPN-Engpässe.

Queue Drops sind besonders relevant, weil sie häufig genau dann auftreten, wenn Durchschnittswerte im Monitoring noch unauffällig aussehen.

Unterschied zwischen Interface Drops und Queue Drops

Interface Drops und Queue Drops hängen eng zusammen, beschreiben aber nicht immer exakt dasselbe.

Interface Drops sind Drops, die an einer Schnittstelle sichtbar werden. Sie zeigen, dass Pakete an oder über dieses Interface verworfen wurden. Queue Drops sind Drops, die durch volle oder überlastete Warteschlangen entstehen. Sie beschreiben genauer den Mechanismus, warum Pakete verworfen wurden.

Vereinfacht gesagt: Interface Drops zeigen häufig, wo ein Problem sichtbar wird. Queue Drops erklären häufig, warum Pakete verworfen wurden.

In der Praxis können beide Werte zusammen auftreten. Ein Switch-Port kann zum Beispiel Output Drops zeigen, weil die Ausgangsqueue kurzfristig überläuft. Eine Firewall kann Drops zeigen, weil sie Datenverkehr unter Last nicht schnell genug verarbeiten kann. Ein WAN-Router kann Pakete verwerfen, weil eine langsamere Ausgangsstrecke kurzfristig überlastet ist.

Für eine belastbare Analyse ist deshalb entscheidend, die konkrete Komponente, Richtung und Ursache zu verstehen.

Warum werden Pakete im Netzwerk verworfen?

Pakete werden verworfen, wenn eine Netzwerkkomponente sie nicht mehr sinnvoll verarbeiten oder weiterleiten kann. Die Gründe dafür können sehr unterschiedlich sein. Häufige Ursachen sind:

  • kurzfristige Überlastung
  • dauerhaft zu hohe Auslastung
  • Microbursts
  • volle Warteschlangen
  • zu kleine Puffer
  • Bandbreitenengpässe
  • fehlerhafte QoS-Konfiguration
  • Traffic Policing
  • überlastete Firewalls
  • VPN-Gateway-Engpässe
  • Security Inspection
  • Paketfilter oder Policies
  • fehlerhafte Kabel
  • defekte Transceiver
  • Duplex- oder Geschwindigkeitsprobleme
  • WLAN-Störungen
  • Server- oder Treiberprobleme
  • Provider- oder Carrier-Probleme

Wichtig ist: Drops sind nicht immer ein reines Bandbreitenproblem. Auch Sicherheitskomponenten, falsch konfigurierte Priorisierung, physische Fehler oder sehr kurze Lastspitzen können Drops verursachen.

Wie wirken sich Drops auf die Performance-Kennzahlen aus?

Drops und Paketverlust

Drops führen häufig direkt zu Paketverlust. Wenn ein Paket an einem Interface oder in einer Queue verworfen wird, erreicht es sein Ziel nicht. Aus Sicht der Ende-zu-Ende-Kommunikation fehlt dieses Paket.

Der Zusammenhang lautet: Drops sind eine mögliche technische Ursache. Paketverlust ist die Wirkung auf der Kommunikationsstrecke.

Ein Paket kann an einem Switch, Router, einer Firewall, einem VPN-Gateway oder einem Providerübergang verworfen werden. Am Ziel kommt es dann nicht an. Die Anwendung sieht nur, dass Daten fehlen oder verzögert sind.

Bei TCP-Verbindungen versucht TCP, verlorene Daten erneut zu übertragen. Bei UDP-basierten Echtzeitanwendungen können verlorene Pakete dagegen direkt zu Aussetzern führen.

Deshalb sollten Drops immer im Zusammenhang mit Paketverlust betrachtet werden. Drops an einer Komponente sind ein lokaler Hinweis. Paketverlust in einer Ende-zu-Ende-Messung zeigt die tatsächliche Auswirkung auf die Kommunikationsstrecke.

Drops und TCP-Retransmissions

Bei TCP-Verbindungen führen verworfene Pakete häufig zu TCP-Retransmissions. Wenn ein TCP-Segment verworfen wird, kann der Empfänger es nicht bestätigen. Der Sender erkennt die Lücke und überträgt die Daten erneut.

Dadurch entstehen zusätzliche Verzögerungen und zusätzlicher Datenverkehr. Gleichzeitig kann TCP seine Übertragungsgeschwindigkeit reduzieren. Der reale Durchsatz sinkt.

Das bedeutet: Ein einzelner Drop kann mehr bewirken als nur ein verlorenes Paket. Er kann eine Kette auslösen:

  1. Paket wird verworfen.
  2. Paketverlust entsteht.
  3. TCP erkennt fehlende Daten.
  4. TCP überträgt erneut.
  5. RTT und Antwortzeit steigen.
  6. Durchsatz sinkt.
  7. Anwendung wirkt langsam.

Besonders bei WAN-, VPN- und Cloud-Strecken können Drops starke Auswirkungen haben, weil die Laufzeiten höher sind und Retransmissions entsprechend länger dauern.

Drops und Latenz

Drops können auch mit Latenzproblemen zusammenhängen. Bevor Pakete verworfen werden, entstehen oft Warteschlangen. Pakete müssen warten, bis sie weitergeleitet werden können. Diese Wartezeit erhöht die Latenz.

Wenn die Warteschlange voll wird, werden Pakete verworfen. Dann entsteht zusätzlich Paketverlust.

Damit können in kurzer Zeit zwei Effekte auftreten: Die Latenz steigt durch Queueing, und Pakete gehen verloren, wenn die Queue überläuft.

Für Anwendungen kann das besonders problematisch sein. Sie erleben nicht nur Verzögerung, sondern zusätzlich fehlende Daten oder Wiederholungen.

In Messdaten zeigt sich das häufig durch Latenzspitzen, Jitter, Paketverlust und TCP-Retransmissions im gleichen Zeitraum.

Drops und Jitter

Jitter beschreibt Schwankungen in der Paketlaufzeit. Drops und Queueing können Jitter verursachen oder verstärken.

Wenn einige Pakete sofort weitergeleitet werden und andere in Warteschlangen warten müssen, kommen Pakete ungleichmäßig an. Dadurch steigt der Jitter.

Bei Echtzeitkommunikation ist das besonders kritisch. Sprache, Audio oder andere zeitkritische Datenströme benötigen eine möglichst gleichmäßige Übertragung. Wenn Pakete verspätet oder gar nicht ankommen, entstehen hörbare oder spürbare Qualitätsprobleme.

Queue Drops können deshalb indirekt auch MOS-Werte verschlechtern, weil sie Paketverlust, Jitter und Latenzspitzen verursachen.

Drops und Durchsatz

Drops wirken sich häufig negativ auf den Durchsatz aus. Besonders bei TCP-Verbindungen führen verworfene Pakete zu Retransmissions. Dadurch müssen Daten erneut übertragen werden, und TCP kann seine Senderate reduzieren.

Das Ergebnis: Die tatsächlich nutzbare Datenrate sinkt.

Eine Verbindung kann also ausreichend Bandbreite haben, aber trotzdem niedrigen Durchsatz liefern, wenn Pakete unterwegs verworfen werden.

Das ist besonders relevant bei: Dateiübertragungen, Backups, Replikationen, Cloud-Migrationen, Storage-Zugriffen, Datenbankverbindungen, Softwareverteilung, großen Downloads oder Uploads und zentralen Fachanwendungen.

Drops sind deshalb eine wichtige Kennzahl, wenn der reale Durchsatz deutlich unter der erwarteten Bandbreite liegt.

Drops und MOS-Wert

Der MOS-Wert bewertet die wahrgenommene Qualität von Sprach- oder Kommunikationsverbindungen. Drops können den MOS-Wert verschlechtern, weil sie Paketverlust, Jitter und Verzögerungen verursachen.

Bei Sprache und Echtzeitkommunikation können verlorene Pakete oft nicht rechtzeitig erneut übertragen werden. Die Folge sind Aussetzer, Verzerrungen oder abgehackte Sprache.

Auch wenn der durchschnittliche Paketverlust niedrig wirkt, können kurze Phasen mit gebündelten Drops hörbar sein. Besonders kritisch sind Drops während eines laufenden Gesprächs oder einer Echtzeitsitzung.

Deshalb sollten MOS-Einbrüche immer gemeinsam mit Drops, Paketverlust, Jitter und One-Way Delay betrachtet werden.

Drops trotz niedriger Durchschnittsauslastung

Viele Unternehmen bewerten Netzwerke stark über durchschnittliche Auslastungswerte. Das ist für Kapazitätsplanung hilfreich, reicht aber für Performance-Analyse nicht aus.

Eine Verbindung kann im Durchschnitt niedrig ausgelastet sein und trotzdem Drops zeigen. Das passiert vor allem dann, wenn der Verkehr ungleichmäßig auftritt.

Microbursts sind eine häufige Ursache für Drops. Sie entstehen, wenn innerhalb eines sehr kurzen Zeitfensters mehr Daten ankommen, als eine Verbindung oder Netzwerkkomponente verarbeiten kann. Das Problem: Microbursts können so kurz sein, dass sie in klassischen Durchschnittswerten kaum sichtbar sind.

Ein Beispiel: Eine WAN-Verbindung hat 1 Gbit/s Bandbreite. Über fünf Minuten betrachtet liegt die durchschnittliche Auslastung bei 35 Prozent. Das sieht unkritisch aus. Innerhalb dieses Zeitraums treten jedoch kurze Spitzen auf, bei denen kurzfristig mehr als 1 Gbit/s verarbeitet werden müsste. Die Queue läuft voll, Pakete werden verworfen, und es entstehen Drops.

Im Monitoring sieht man vielleicht nur eine moderate Durchschnittsauslastung. Die Anwendung erlebt jedoch Paketverlust, TCP-Retransmissions und sinkenden Durchsatz. Deshalb sind Drops ein wichtiger Hinweis darauf, dass Durchschnittswerte allein nicht ausreichen.

Typische Situationen sind:

  • viele gleichzeitige Benutzeraktionen
  • parallele Downloads
  • Backup-Start zu festen Zeiten
  • Replikationen
  • Softwareverteilung
  • Cloud-Synchronisationen
  • Burst-Verhalten von Anwendungen
  • Datenbankantworten mit großem Rückvolumen
  • Storage-Zugriffe
  • Logging- oder Telemetriedaten
  • virtuelle Desktop-Umgebungen

Für die Anwendung zählt nicht der Durchschnitt über fünf Minuten. Entscheidend ist, ob im konkreten Moment genug Kapazität und Puffer vorhanden sind, um die Pakete ohne Verlust weiterzuleiten.

Welche Arten von Drops gibt es?

Je nach Gerät und Hersteller können Drops unterschiedlich bezeichnet werden.

Diese Begriffe bedeuten nicht immer dasselbe. Ein Policy Drop kann zum Beispiel absichtlich durch eine Regel entstehen. Ein Queue Drop entsteht eher durch Überlastung oder volle Warteschlangen. Ein Error Drop kann auf physische Fehler oder fehlerhafte Frames hinweisen.

Deshalb ist es wichtig, die jeweilige Gerätedokumentation und den konkreten Zähler zu verstehen. Nicht jeder Drop-Zähler ist automatisch ein Performance-Problem. Entscheidend ist der Zusammenhang mit Anwendung, Zeitverlauf und anderen Messwerten.

Typische Begriffe sind:

  • Input Drops
  • Output Drops
  • Discards
  • Queue Drops
  • Tail Drops
  • Buffer Drops
  • Policy Drops
  • QoS Drops
  • Congestion Drops
  • Firewall Drops
  • ACL Drops
  • Policer Drops
  • Error Drops

Drops sind nicht dasselbe wie CRC-Fehler

Drops und CRC-Fehler werden manchmal gemeinsam betrachtet, sind aber nicht dasselbe.

CRC-Fehler weisen häufig auf beschädigte Frames oder physische Übertragungsprobleme hin. Ursachen können zum Beispiel defekte Kabel, schlechte Steckverbindungen, Transceiver-Probleme, elektromagnetische Störungen oder Hardwarefehler sein.

Drops bedeuten dagegen zunächst nur, dass Pakete oder Frames verworfen wurden. Das kann durch Überlastung, volle Queues, Policies, QoS, Filterregeln oder andere Ursachen passieren.

Beides kann zu Paketverlust führen, aber die Ursachenanalyse ist unterschiedlich.

Wenn Drops zusammen mit CRC-Fehlern oder anderen Interface-Fehlern auftreten, sollte die physische Verbindung geprüft werden. Wenn Drops ohne physische Fehler auftreten, sind eher Überlastung, Queues, Puffer, Policies oder Verarbeitungskapazität zu untersuchen.

Wie erkennt man Interface Drops und Queue Drops?

Interface Drops und Queue Drops lassen sich auf verschiedenen Ebenen erkennen.

Geräte-Statistiken

Switches, Router, Firewalls, Access Points und VPN-Gateways liefern häufig Zähler für Drops, Discards, Errors oder Queue-Verluste. Diese Werte sind ein wichtiger Ausgangspunkt.

Wichtig ist dabei, nicht nur den absoluten Zähler zu betrachten. Viele Zähler steigen über lange Zeiträume an. Aussagekräftig ist vor allem, ob Drops in einem konkreten Zeitraum zunehmen und ob das mit Anwenderproblemen zusammenfällt.

Monitoring-Systeme

Netzwerk-Monitoring kann Drop-Zähler über Zeit erfassen. Dadurch lassen sich Muster erkennen: Tritt der Drop immer zur gleichen Tageszeit auf? Betrifft er nur bestimmte Interfaces? Steigt der Wert während Backups oder Replikationen?

Durchsatz- und Latenzmessung

Wenn Drops auftreten, können gleichzeitig Durchsatz sinken, RTT steigen oder Jitter zunehmen. Die Kombination dieser Werte hilft bei der Ursachenanalyse.

Paketmitschnitte

Paketmitschnitte können helfen, Auswirkungen wie TCP-Retransmissions, fehlende Sequenzen oder Paketverluste sichtbar zu machen. Sie sind besonders hilfreich, wenn gezielt untersucht werden soll, wie TCP oder eine Anwendung auf Verluste reagiert.

Paketverlustmessung

Eine Ende-zu-Ende-Messung zeigt, ob Drops auf der Strecke tatsächlich als Paketverlust sichtbar werden. Das ist wichtig, weil lokale Drop-Zähler allein noch nicht zeigen, wie stark eine Anwendung betroffen ist.

Warum der Zeitbezug entscheidend ist

Bei Drops ist der Zeitbezug besonders wichtig. Ein Drop-Zähler allein sagt wenig aus, wenn nicht klar ist, wann die Drops entstanden sind.

Ein Interface kann über Monate hinweg viele Drops gezählt haben, ohne dass aktuell ein Problem besteht. Umgekehrt können wenige Drops innerhalb eines kritischen Zeitfensters eine konkrete Anwendung spürbar beeinträchtigen.

Wichtige Fragen sind: Wann steigen die Drop-Zähler? Wie stark steigen sie pro Minute oder pro Messintervall? Welche Anwendung war zu diesem Zeitpunkt aktiv? Gab es Anwenderbeschwerden? Tritt gleichzeitig Paketverlust auf? Steigt die RTT oder das One-Way Delay? Gibt es Jitter? Sinkt der Durchsatz? Gibt es TCP-Retransmissions? Fällt der MOS-Wert ab? Betreffen die Drops eine kritische Kommunikationsstrecke?

Ohne Zeitbezug bleiben Drops schwer interpretierbar.

Warum Ende-zu-Ende-Messung wichtig ist

Drops entstehen lokal an einer Komponente. Anwendungen erleben jedoch die Qualität der gesamten Kommunikationsstrecke.

Eine Ende-zu-Ende-Messung hilft, lokale Drop-Hinweise mit der tatsächlichen Auswirkung zu verbinden.

Sie beantwortet Fragen wie: Kommen Pakete zwischen Standort und Rechenzentrum zuverlässig an? Gibt es Paketverlust auf der Strecke? Treten Latenzspitzen gleichzeitig mit Drops auf? Sinkt der Durchsatz während Drop-Ereignissen? Sind nur bestimmte Standorte betroffen? Gibt es Unterschiede je Richtung? Fallen Drops mit Microbursts oder Lastspitzen zusammen? Sind WAN, VPN, Firewall, Cloud oder LAN betroffen?

So wird aus einem lokalen Zählerwert eine belastbare Performance-Bewertung.

Praxisbeispiel

Output Drops trotz unkritischer Auslastung

Ein Unternehmen betreibt mehrere Standorte, die über WAN-Strecken auf zentrale Anwendungen zugreifen. Die Anwender melden zu bestimmten Tageszeiten langsame Reaktionen und gelegentliche Verbindungsabbrüche. Die durchschnittliche Auslastung der WAN-Verbindungen liegt im Monitoring meist unter 50 Prozent.

Zunächst wirkt die Situation unklar. Die Bandbreite scheint ausreichend. Einzelne Ping-Tests zeigen keine dauerhaften Auffälligkeiten.

Eine genauere Analyse zeigt jedoch, dass auf einem Router-Interface zu bestimmten Zeiten Output Drops auftreten. Gleichzeitig misst die Ende-zu-Ende-Überwachung Paketverlust, RTT-Spitzen und TCP-Retransmissions auf der Strecke zwischen Standort und Rechenzentrum.

Die Ereignisse fallen mit parallelen Dateiübertragungen und Synchronisationsprozessen zusammen. Die Ursache sind kurze Lastspitzen, die die Ausgangsqueue des Routers überlasten. Dadurch werden Pakete verworfen.

Nach einer Anpassung der Priorisierung, einer zeitlichen Entzerrung großer Datenübertragungen und einer Prüfung der Queue-Konfiguration sinken die Drops deutlich. Paketverlust und TCP-Retransmissions gehen zurück. Die Anwendungen reagieren stabiler.

Das Beispiel zeigt: Drops können trotz unkritischer Durchschnittsauslastung auftreten und konkrete Auswirkungen auf Anwendungen haben.

Best Practicesim Umgang mit Interface Drops und Queue Drops

Besonders wichtig ist, Drops nicht vorschnell zu interpretieren. Ein Drop-Zähler ist ein Hinweis, aber erst der Zusammenhang mit weiteren Messwerten zeigt, ob und wie stark die Anwendung betroffen ist.

Für eine sinnvolle Bewertung von Drops haben sich folgende Maßnahmen bewährt:

  • Drops nicht isoliert betrachten
  • Input Drops und Output Drops getrennt auswerten
  • Queue Drops und Policy Drops unterscheiden
  • Drop-Zähler immer im Zeitverlauf analysieren
  • Zähleranstiege mit Anwenderproblemen abgleichen
  • Paketverlust, RTT, One-Way Delay, Jitter und Durchsatz gemeinsam bewerten
  • TCP-Retransmissions als Folge prüfen
  • Microbursts als mögliche Ursache berücksichtigen
  • Durchschnittsauslastung kritisch hinterfragen
  • QoS- und Priorisierungsregeln prüfen
  • WAN-, VPN-, Firewall- und Cloud-Strecken getrennt bewerten
  • physische Fehler wie CRC-Errors separat prüfen
  • Paketmitschnitte gezielt einsetzen
  • historische Messdaten speichern
  • kritische Kommunikationsstrecken kontinuierlich überwachen
  • nach Änderungen an Provider, Firewall, VPN oder QoS gezielt kontrollieren

Zusammengefasst

Interface Drops und Queue Drops sind wichtige Hinweise auf verworfene Pakete im Netzwerk. Sie können durch Überlastung, Microbursts, volle Warteschlangen, fehlerhafte Priorisierung, Sicherheitskomponenten, WAN-Engpässe, physische Fehler oder Policy-Regeln entstehen.

Für die Netzwerk-Performance sind Drops besonders relevant, weil sie Paketverlust verursachen können. Daraus können TCP-Retransmissions, niedriger Durchsatz, Latenzspitzen, Jitter, MOS-Einbrüche und spürbare Anwendungsprobleme entstehen.

Besonders kritisch ist, dass Drops auch bei niedriger durchschnittlicher Auslastung auftreten können. Kurze Lastspitzen reichen aus, um Queues zu füllen und Pakete zu verwerfen. Klassische Durchschnittswerte erkennen solche Ereignisse oft nicht zuverlässig.

Eine belastbare Analyse betrachtet Drops deshalb nie isoliert. Entscheidend ist der Zusammenhang mit Paketverlust, RTT, One-Way Delay, Jitter, Durchsatz, TCP-Retransmissions, MOS-Wert und zeitlichen Lastmustern. Eine kontinuierliche Ende-zu-Ende-Messung hilft, lokale Drop-Ereignisse mit der tatsächlichen Wirkung auf Anwendungen zu verbinden.

Häufig gestellte Fragen zu Interface Drops und Queue Drops

Interface Drops sind Pakete, die an einer Netzwerkschnittstelle verworfen werden, weil sie nicht verarbeitet, gespeichert oder weitergeleitet werden konnten.

Queue Drops entstehen, wenn eine Warteschlange in einer Netzwerkkomponente voll ist und weitere Pakete verworfen werden müssen.

Nicht jeder einzelne Drop ist kritisch. Wiederkehrende oder gebündelte Drops können jedoch auf Überlastung, Microbursts, falsche Priorisierung oder andere Performance-Probleme hinweisen.

Weil Durchschnittswerte kurze Lastspitzen verdecken können. Microbursts können Queues überlasten, obwohl die Verbindung im Durchschnitt unkritisch aussieht.

Drops beschreiben lokal verworfene Pakete an einer Komponente. Paketverlust beschreibt, dass Pakete Ende-zu-Ende nicht beim Ziel angekommen sind.

Wenn TCP-Pakete verworfen werden, muss TCP die fehlenden Daten häufig erneut übertragen. Dadurch entstehen TCP-Retransmissions und der Durchsatz kann sinken.

Tipp von NETCOR

Bewerten Sie Interface Drops und Queue Drops immer im zeitlichen Zusammenhang mit anderen Messwerten. Entscheidend ist nicht nur, dass ein Drop-Zähler steigt, sondern wann, auf welcher Strecke und mit welcher Auswirkung. Wenn Drops gleichzeitig mit Paketverlust, RTT-Spitzen, Jitter, TCP-Retransmissions oder sinkendem Durchsatz auftreten, entsteht ein belastbarer Hinweis auf ein echtes Performance-Problem. Eine kontinuierliche 24/7-Ende-zu-Ende-Messung hilft, lokale Drop-Ereignisse mit der tatsächlichen Anwender- und Anwendungsqualität zu verbinden.

Live erleben

GeNiEnd2End Kennenlernen

Drops sichtbar machen, statt Symptome zu raten: In unserer Live-Demo zeigen wir Ihnen, wie GeNiEnd2End Paketverlust, Latenzspitzen und die Auswirkungen von Drops auf Ihren Kommunikationsstrecken kontinuierlich erfasst und nachvollziehbar macht.

Demo buchen

Weitere Grundlagen-Artikel

Was ist Paketverlust?

Bedeutung, Ursachen und Messung von Paketverlust – warum schon geringe Verluste stören können.

Zum Artikel

Was sind TCP-Retransmissions?

Warum TCP Daten erneut überträgt – und wie Retransmissions den Durchsatz beeinflussen.

Zum Artikel

Was sind Microbursts?

Warum kurze Lastspitzen große Wirkung haben – und in Durchschnittswerten verborgen bleiben.

Zum Artikel