Ständige Paketverluste

[Zombernatural]

Moin,

da Vodafone leider ständig meine Störungstickets als "erledigt" markiert, ohne das Problem zu lösen, könnt ihr mir vielleicht weiterhelfen.

Ich habe seit ca. einem Monat über den Tag immer wieder Paketverluste. Mal geringer (aktuell so 1-4%), mal mehr (bis zu 40%). Getestet habe ich 4 verschiedene Dienste über Pingplotter. Meine Bandbreite scheint davon m.W.n. unberührt zu sein, meine Latenz meistens auch, manchmal aber auch erhöht (80ms, statt der regulären 20).
Das passiert auch weniger zu den klassischen Hotspot-Zeiten, aber feste Muster hat es auch nicht.

Hier mal alle Randdaten:

Vertrag: 100Mbit Kabel/Tel. Vodafone
Modem: Standard-Kabelrouter von Vodafone
OS: Win10
PC mit LAN verbunden


Pingplotter Messung:

Router Signalwerte:

Bin für jede Hilfe dankbar

 

[xxMuahdibxx]

easybox Local ... 90,5 % Paket loss ...

eigenes Netzwerk mal überprüfen ... der Restliche Loss kann schon dadurch entstehen.

 

[Zombernatural]

easybox Local ... 90,5 % Paket loss ...

eigenes Netzwerk mal überprüfen ... der Restliche Loss kann schon dadurch entstehen.

Wie geh ich da vor?

 

[xxMuahdibxx]

Andere LAN Kabel testen ... weil du sagts ja LAN ... oder versteckt sich da doch ein DLAN Adapter oder eine WLAN noch ?

 

[Zombernatural]

Nein, keine DLAN Adapter. WLAN ist aktiv für andere Geräte, aber der Rechner ist direkt über LAN verbunden, ja. Ich teste dann gleich mal ein anderes Kabel.

 

[cb_darkman]

Bei einem shared Medium wie Kabel sind Paketverluste normal. Dafür ist ja dann das TCP/IP Protokoll da.
Falls es interessieren sollte:
https://de.wikipedia.org/wiki/Transmission_Control_Protocol/Internet_Protocol

Darum macht Vodafone deine Anfragen wie Du schreibst "regelmäßig" zu.

 

[Zombernatural]

Bei einem shared Medium wie Kabel sind Paketverluste normal. Dafür ist ja dann das TCP/IP Protokoll da.
Falls es interessieren sollte:
https://de.wikipedia.org/wiki/Transmission_Control_Protocol/Internet_Protocol

Darum macht Vodafone deine Anfragen wie Du schreibst "regelmäßig" zu.

Bedeutet für mich im konkreten Fall, dass ich mit den Verlusten leben muss? Habe den Vertrag ja schon etwa ein Jahr, bis vor einem Monat auch ohne Probleme. Seitdem täglich.


Anderes Kabel getestet, selbes Ergebnis leider

 

[TheCadillacMan]

Du musst die Ausgabe vom Ziel aus, also von unten nach oben interpretieren.
Das Ziel hat 3,8% Packet Loss, die vier Hops davor jedoch nicht also muss in diesem Fall das Problem sehr wahrscheinlich direkt am Ziel liegen.
Sehen die Tests zu anderen Zielen genauso aus?

easybox Local ... 90,5 % Paket loss ...

Ping Plotter arbeitet mit Pings die manche Router wenn nötig einfach verwerfen (hier anscheinend Hops 1, 4, 6 und 7). Das heißt nicht, dass alles andere auch verloren geht.
Hätte der Router wirklich 90% Packet Loss würde sich das durch die Hops nach unten ziehen.

 

[Zombernatural]

Du musst die Ausgabe vom Ziel aus, also von unten nach oben interpretieren.
Das Ziel hat 3,8% Packet Loss, die vier Hops davor jedoch nicht also muss in diesem Fall das Problem sehr wahrscheinlich direkt am Ziel liegen.
Sehen die Tests zu anderen Zielen genauso aus?


Ping Plotter arbeitet mit Pings die manche Router wenn nötig einfach verwerfen (hier anscheinend Hops 1, 4, 6 und 7). Das heißt nicht, dass alles andere auch verloren geht.
Hätte der Router wirklich 90% Packet Loss würde sich das durch die Hops nach unten ziehen.

Ja, in diesem Fall ist das ein Gameserver. Tritt aber auch bei anderen Servern auf, auch im Teamspeak usw. Wie gesagt, mal geringer bei 3%, mal bei 20-30% und somit unspielbar.

 

[xxMuahdibxx]

ich würde trotzdem erst den eigenen HOP kontrollieren ... weil bei einer 2,5 Sekunden Taktung sollte dort kein PL auftreten ... vielleicht mal mit 10 Sekunden testen ob es immer noch so hoch ist ... ergo die Pings abgeblockt werden.

 

[snaxilian]

Vodafone ist nur für sein eigenes Netz verantwortlich. Deine Pakete gehen von deinem PC zum Router, ins Vodafone Netz. Ist der Zielserver ebenfalls im Netz von Vodafone gehen die Pakete direkt da hin. Ist der Zielserver nicht im Vodafone Netz dann gehen die Pakete zur "Grenze" und gehen dann in das Netz des nächsten Providers. Diese Verbindungen zwischen den Providern nennt man Peering. Ab dann endet die Zuständigkeit von Vodafone bzw. die Antwortpakete kommen im Peering wieder zu VF rein und werden zurück zu dir geschickt.

Jetzt müsstest du heraus finden ob die Hops 6 & 7 noch bei VF sind oder nicht. Wenn nicht ist klar warum VF deine Tickets schließt da nicht deren Baustelle.

Niemand garantiert dir paketverlustfreies surfen, das Internet wurde auch nicht dafür konzipiert. Es gibt nicht grundlos Redundanzen in der globalen Vernetzung und den Protokollen wie eben TCP.

Such dir ein paar Testsysteme innerhalb von VF z.B. deren Homepage, DNS-Server etc. Hast du dann weiterhin Verluste, gilt es für VF zu klären wo diese her kommen.

Oder anders gesagt: Ganz böse betrachtet könnte man problemlos einen Server aufsetzen der jedes dritte ICMP Paket (Ping) verwirft. Pinge ich gegen diesen Server sieht es aus als hätte ich einen Paketverlust von 33% obwohl die Leitung absolut in Ordnung ist. Ich könnte sogar einen Webserver auf dem Server betreiben und immer TCP-Connects gegen den Webserver machen und gleichzeitig Pings los schicken. Bei den TCP-Connects hätte ich 0 Probleme und weiterhin 33% Verluste bei den ICMPs.
Wie du siehst: Wirklich verlässlich ist somit eigentlich nur ein Test direkt gegen die Anwendung, Ping ist nur ein erstes Indiz.

 

[Zombernatural]

Jetzt gerade sieht es gut aus. Werde dann nochmal mehrere Tests machen, sobald ich wieder Probleme bekomme.

VF HP:

 

[Raijin]

Es ist durchaus nicht unüblich, dass große Router im www direkt an sie gerichtete Pings ignorieren oder zumindest mit einer niedrigeren Priorität beantworten. Das wird gemacht, um den "richtigen" Datenverkehr, der weitergeroutet werden muss, nicht zu beeinträchtigen. Der Hop antwortet also erst wenn er etwas Luft zum Antworten hat. Das kann sich in einem Trace in hohen Pings oder gar Timeouts bei den Hops niederschlagen und ist nicht ungewöhnlich und auch in keinster Weise negativ. Nur dann, wenn sich der hohe Ping eines Hops fortsetzt, also als Offset auf alle folgenden Hops aufgeschlagen wird, kann man davon ausgehen, dass dieser Hop ausgelastet ist und auch beim höher priorisierten Routing nicht mehr hinterherkommt.

Die wichtigsten Werte bei einem Trace (sei es via tracert oder via PingPlotter) sind daher immer die Werte beim Ziel, ungeachtet dessen was unterwegs passieren mag. Hat man am Ziel 0% Paketverlust und einen stabilen Ping, dann ist genau das der Fall.

Mach bitte mal Folgendes in der Eingabeaufforderung:

ping 192.168.0.1 -n 100
ping 8.8.8.8 -n 100
tracert -h 1 -d 8.8.8.8

Der erste Ping prüft ausschließlich die Verbindung zu deinem Router.
Der zweite Ping prüft die Verbindung zum google-public-dns (nur exemplarisch)
Tracert macht zwar einen Trace auf 8.8.8.8, ist aber auf 1 Hop limitiert, wird also nur bis zu deinem Router gehen und nicht weiter.

Hintergrund der Tests ist, dass ich bereits in einem anderen Thread einen ähnlichen Fall hatte, bei dem ein Consumer-Router komischerweise auf direkte Pings zu 100% reagiert hat, bei einem Trace jedoch hohen Paketverlust gezeigt hat. Ein Trace funktioniert zwar auch mit Pings, aber während ein direkter Ping beim Router als "Ziel" endet, endet er bei einem Trace als "Ping abgelaufen", ungültig sozusagen. Das ist für einen Consumer-Router ein ungewöhnliches Verhalten, ich finde aber leider den Thread nicht mehr und kann mich auch nicht mehr daran erinnern ob es auch eine easybox war wie bei dir.

 

[Zombernatural]

Es ist durchaus nicht unüblich, dass große Router im www direkt an sie gerichtete Pings ignorieren oder zumindest mit einer niedrigeren Priorität beantworten. Das wird gemacht, um den "richtigen" Datenverkehr, der weitergeroutet werden muss, nicht zu beeinträchtigen. Der Hop antwortet also erst wenn er etwas Luft zum Antworten hat. Das kann sich in einem Trace in hohen Pings oder gar Timeouts bei den Hops niederschlagen und ist nicht ungewöhnlich und auch in keinster Weise negativ. Nur dann, wenn sich der hohe Ping eines Hops fortsetzt, also als Offset auf alle folgenden Hops aufgeschlagen wird, kann man davon ausgehen, dass dieser Hop ausgelastet ist und auch beim höher priorisierten Routing nicht mehr hinterherkommt.

Die wichtigsten Werte bei einem Trace (sei es via tracert oder via PingPlotter) sind daher immer die Werte beim Ziel, ungeachtet dessen was unterwegs passieren mag. Hat man am Ziel 0% Paketverlust und einen stabilen Ping, dann ist genau das der Fall.

Mach bitte mal Folgendes in der Eingabeaufforderung:

ping 192.168.0.1 -n 100
ping 8.8.8.8 -n 100
tracert -h 1 -d 8.8.8.8

Der erste Ping prüft ausschließlich die Verbindung zu deinem Router.
Der zweite Ping prüft die Verbindung zum google-public-dns (nur exemplarisch)
Tracert macht zwar einen Trace auf 8.8.8.8, ist aber auf 1 Hop limitiert, wird also nur bis zu deinem Router gehen und nicht weiter.

Hintergrund der Tests ist, dass ich bereits in einem anderen Thread einen ähnlichen Fall hatte, bei dem ein Consumer-Router komischerweise auf direkte Pings zu 100% reagiert hat, bei einem Trace jedoch hohen Paketverlust gezeigt hat. Ein Trace funktioniert zwar auch mit Pings, aber während ein direkter Ping beim Router als "Ziel" endet, endet er bei einem Trace als "Ping abgelaufen", ungültig sozusagen. Das ist für einen Consumer-Router ein ungewöhnliches Verhalten, ich finde aber leider den Thread nicht mehr und kann mich auch nicht mehr daran erinnern ob es auch eine easybox war wie bei dir.

 

[Raijin]

Ok, das sieht eigentlich ok aus, zumindest in der Momentaufnahme. Das Maximum beim Ping auf 8.8.8.8 ist mit 434ms ziemlich hoch, dürfte aber ein Ausreißer sein, weil der Mittelwert mit 23ms vollkommen ok ist. Paketverlust gibt es in diesem Fall gar keinen.

Hast du evtl. mal mit Tools wie TCP-Optimizer experimentiert? Das sind Programme, die an erweiterten Netzwerkeinstellungen rumbasteln, um angeblich irgendwas zu optimieren - das Gegenteil ist in der Regel der Fall. Wenn TCP-Optimizer genutzt hast, starte es erneut und stelle alles auf Windows Standard zurück. Zwar sollten sich Probleme mit diesem Tool - es geht hierbei insbesondere um die MTU, die maximale Paketgröße - anders bzw. massiver zeigen, aber man weiß ja nie.

Um generell Windows, Treiber oder etwaige sonstige Software auszuschließen, kannst du auch mal ein Live-Linux auf einen USB-Stick laden und den PC damit starten. Sollte Linux ebenfalls Probleme haben, kann man Windows zumindest schon mal freisprechen. Hat Linux hingegen keine Probleme, läuft irgendwas bei Windows, Treibern oder eben sonstigen Tools bzw. Einstellungen schief - im schlimmsten Fall hieße das eine Neuinstallation.

 

[Steffen02502]

Bei einem shared Medium wie Kabel sind Paketverluste normal. Dafür ist ja dann das TCP/IP Protokoll da.
Falls es interessieren sollte:
https://de.wikipedia.org/wiki/Transmission_Control_Protocol/Internet_Protocol

Darum macht Vodafone deine Anfragen wie Du schreibst "regelmäßig" zu.

Ich hatte genau das gleiche Problem. Wochenlang random Verbindungseinbrüche, meistens vormittags/mittags...
Dutzende Hotline-Calls, Router-Tausch usw...
Die "Technik" schließt die Tickets kommentarlos, oder machen eine 24-Stunden messung und schließen es dann. ("Verbindung ist beständig"... ja ein beständiger müllhaufen ...)

Je nachdem wen man bei der Hotline dranbekommt, kann die Ehrlichkeit und Motivation der Mitarbeiter abweichen. Das Problem haben wohl mehere "Kunden".
Meiner Meinung nach: Leider weiter Hotline "errorsieren", Router tauschen lassen usw...
hartnäckig bleiben oder Sonderkündigungsrecht wahrnehmen (wurde mir ebenfalls bei der Hotline empfohlen, "unter der hand" sozusagen, mit richtig schlecht-lustigen Andeutungen )

Klar kann OP auch erstmal auch das Probieren:

Ok, das sieht eigentlich ok aus, zumindest in der Momentaufnahme. Das Maximum beim Ping auf 8.8.8.8 ist mit 434ms ziemlich hoch, dürfte aber ein Ausreißer sein, weil der Mittelwert mit 23ms vollkommen ok ist. Paketverlust gibt es in diesem Fall gar keinen.

Hast du evtl. mal mit Tools wie TCP-Optimizer experimentiert? Das sind Programme, die an erweiterten Netzwerkeinstellungen rumbasteln, um angeblich irgendwas zu optimieren - das Gegenteil ist in der Regel der Fall. Wenn TCP-Optimizer genutzt hast, starte es erneut und stelle alles auf Windows Standard zurück. Zwar sollten sich Probleme mit diesem Tool - es geht hierbei insbesondere um die MTU, die maximale Paketgröße - anders bzw. massiver zeigen, aber man weiß ja nie.

Um generell Windows, Treiber oder etwaige sonstige Software auszuschließen, kannst du auch mal ein Live-Linux auf einen USB-Stick laden und den PC damit starten. Sollte Linux ebenfalls Probleme haben, kann man Windows zumindest schon mal freisprechen. Hat Linux hingegen keine Probleme, läuft irgendwas bei Windows, Treibern oder eben sonstigen Tools bzw. Einstellungen schief - im schlimmsten Fall hieße das eine Neuinstallation.

Aber Ich hatte WLAN vs .LAN/Laptop vs. PC vs. Handy/RouterTausch alles durch. Nicht mal deren eigene Speedtest seite hat geladen, für Stunden manchmal, tolle Vorraussetzungen für Homeoffice. (Der Zeitraum war meistens vormittags u. frühnachmittags ...deshalb vermutlich lange nicht aufgefallen weil da niemand zuhause ist normalerweise)

Die Aussage von Vodafone war ganz klar: Nein Leitung in Ordnung, kein Problem. Wir können nix tun.
(Wie gesagt, nicht mal deren SpeedCheck-Page hat geladen, der Router hat konsequent 103.000 down verbindung angezeigt, kein Traffic im Router)

Nach vielen vielen Hotline-Anrufen und Tickets, hatte ich eines Tages nach knapp 3 Wochen (Anfang November '19) nachdem mittlerweile allmorgendlichen Router-neustart, nur noch 90.000 down statt 100.000 und das Problem war mysteriöse Weise gebannt.

 

[Zombernatural]

Es ist durchaus nicht unüblich, dass große Router im www direkt an sie gerichtete Pings ignorieren oder zumindest mit einer niedrigeren Priorität beantworten. Das wird gemacht, um den "richtigen" Datenverkehr, der weitergeroutet werden muss, nicht zu beeinträchtigen. Der Hop antwortet also erst wenn er etwas Luft zum Antworten hat. Das kann sich in einem Trace in hohen Pings oder gar Timeouts bei den Hops niederschlagen und ist nicht ungewöhnlich und auch in keinster Weise negativ. Nur dann, wenn sich der hohe Ping eines Hops fortsetzt, also als Offset auf alle folgenden Hops aufgeschlagen wird, kann man davon ausgehen, dass dieser Hop ausgelastet ist und auch beim höher priorisierten Routing nicht mehr hinterherkommt.

Die wichtigsten Werte bei einem Trace (sei es via tracert oder via PingPlotter) sind daher immer die Werte beim Ziel, ungeachtet dessen was unterwegs passieren mag. Hat man am Ziel 0% Paketverlust und einen stabilen Ping, dann ist genau das der Fall.

Mach bitte mal Folgendes in der Eingabeaufforderung:

ping 192.168.0.1 -n 100
ping 8.8.8.8 -n 100
tracert -h 1 -d 8.8.8.8

Der erste Ping prüft ausschließlich die Verbindung zu deinem Router.
Der zweite Ping prüft die Verbindung zum google-public-dns (nur exemplarisch)
Tracert macht zwar einen Trace auf 8.8.8.8, ist aber auf 1 Hop limitiert, wird also nur bis zu deinem Router gehen und nicht weiter.

Hintergrund der Tests ist, dass ich bereits in einem anderen Thread einen ähnlichen Fall hatte, bei dem ein Consumer-Router komischerweise auf direkte Pings zu 100% reagiert hat, bei einem Trace jedoch hohen Paketverlust gezeigt hat. Ein Trace funktioniert zwar auch mit Pings, aber während ein direkter Ping beim Router als "Ziel" endet, endet er bei einem Trace als "Ping abgelaufen", ungültig sozusagen. Das ist für einen Consumer-Router ein ungewöhnliches Verhalten, ich finde aber leider den Thread nicht mehr und kann mich auch nicht mehr daran erinnern ob es auch eine easybox war wie bei dir.

Heya, also gerade verzeichne ich mal wieder 10-15% Paketverluste an alle Dienste und habe diese Commands nochmal durchgeführt und die sehen nun auch anders aus. Bei "ping 192.168.0.1 -n 100" war ca. jeder 9. Ping ein TImeout

Ähnlich auch bei dem 8.8.8.8 ping

Trace:

Auszug aus WinMTR:

 

[snaxilian]

In deinen gesamten Betrachtungen sehe ich immer nur IPv4. Die Kabelprovider und auch manch andere sind dafür bekannt CGN einzusetzen. Gut möglich, dass die jeweiligen Kisten, die das CGN machen, am Limit laufen. Ein Wechsel bzw. parallele Test mit IPv6 wäre hier interessant ob es da auch zu Problemen kommt oder ob diese "Verluste" sich auf das legacy IPv4 beschränken.

 

[Mr. Robot]

Wenn man doch schon Verluste zum Router hat, kann es nicht am Provider liegen. Bunkt!

 

[Zombernatural]

Wenn man doch schon Verluste zum Router hat, kann es nicht am Provider liegen. Bunkt!

Und woran kann es dann liegen?

In deinen gesamten Betrachtungen sehe ich immer nur IPv4. Die Kabelprovider und auch manch andere sind dafür bekannt CGN einzusetzen. Gut möglich, dass die jeweiligen Kisten, die das CGN machen, am Limit laufen. Ein Wechsel bzw. parallele Test mit IPv6 wäre hier interessant ob es da auch zu Problemen kommt oder ob diese "Verluste" sich auf das legacy IPv4 beschränken.

In anderen Foren war der erste Ratschlag immer, dass ich, falls ich auf IPv6 bin, mal nur auf IPv4 soll Ich werde das gleich mal ausprobieren und berichten




edit: IPv6 war aktuell aktiviert, aber deaktivieren hat auch nichts gebracht. Mit VPN habe ich übrigens 0% Paketverlust, ohne 5-10%

VPN: