Paketverlust Fritz Box

Dambedei

Cadet 3rd Year
Registriert
Juli 2010
Beiträge
38
Hi,

habe seit längerem mit Paketverlusten im Internet zu kämpfen. Habe immer der Telekom die Schuld gegeben. Es hat sich aber herausgestellt, dass ich schon Paketverluste im lokalen Netzwerk habe. Wenn ich die Fritz Box anpinge, gehen schon die ersten Pakete verloren. Andere Geräte, die am selben switch hängen, haben keine Paketverluste. Ist das normal, dass die Fritz Box nicht auf alle pings antwortet? Ich weiß nicht ob es am neuesten Update liegt (7.50) oder am Kabel (Neues ist unterwegs).
Wäre natürlich toll wenn es das Kabel wäre, weil das ein easy fix ist. Habe die Fritz Box 7590.

Hat sonst noch jemand eine Idee was es sein könnte?
Danke und Gruß
 
Nachdem Du nichts angegeben hast.
Hier sind weder DLAN noch WLAN (Repeater) im Spiel, oder ?

Du hast ping-verluste auf einer reinen LAN-Strecke.
Nein, das ist nicht normal daß die Fritz!Box nicht auf alle pings antwortet.
 
  • Gefällt mir
Reaktionen: Dambedei
Könnte auch an einer defekten NIC liegen, aber erstmal das Kabel testen.

Wobei das natürlich nicht sein kann, wenn zw. dem gleichen PC und einem anderen PC dann keine Fehler auftreten.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Dambedei
bart0rn schrieb:
Nachdem Du nichts angegeben hast.
Hier sind weder DLAN noch WLAN (Repeater) im Spiel, oder ?

Du hast ping-verluste auf einer reinen LAN-Strecke.
Nein, das ist nicht normal daß die Fritz!Box nicht auf alle pings antwortet.

DLAN und WLAN benutze ich beides, die Verluste passieren aber bereits wenn verkabelte Rechner die Fritze anpingen.

Code:
ping 192.168.0.98

PING 192.168.0.98 (192.168.0.98) 56(84) Bytes an Daten.

64 Bytes von 192.168.0.98: icmp_seq=1 ttl=64 Zeit=0.772 ms

64 Bytes von 192.168.0.98: icmp_seq=2 ttl=64 Zeit=0.680 ms

64 Bytes von 192.168.0.98: icmp_seq=3 ttl=64 Zeit=44.5 ms

64 Bytes von 192.168.0.98: icmp_seq=4 ttl=64 Zeit=21.1 ms

64 Bytes von 192.168.0.98: icmp_seq=5 ttl=64 Zeit=0.466 ms

64 Bytes von 192.168.0.98: icmp_seq=6 ttl=64 Zeit=0.401 ms

64 Bytes von 192.168.0.98: icmp_seq=7 ttl=64 Zeit=0.535 ms

64 Bytes von 192.168.0.98: icmp_seq=8 ttl=64 Zeit=1.63 ms

64 Bytes von 192.168.0.98: icmp_seq=9 ttl=64 Zeit=0.528 ms

64 Bytes von 192.168.0.98: icmp_seq=10 ttl=64 Zeit=0.447 ms

64 Bytes von 192.168.0.98: icmp_seq=12 ttl=64 Zeit=1.47 ms

64 Bytes von 192.168.0.98: icmp_seq=13 ttl=64 Zeit=0.480 ms

64 Bytes von 192.168.0.98: icmp_seq=14 ttl=64 Zeit=0.435 ms

64 Bytes von 192.168.0.98: icmp_seq=15 ttl=64 Zeit=0.432 ms

64 Bytes von 192.168.0.98: icmp_seq=16 ttl=64 Zeit=0.852 ms

64 Bytes von 192.168.0.98: icmp_seq=17 ttl=64 Zeit=0.620 ms

64 Bytes von 192.168.0.98: icmp_seq=18 ttl=64 Zeit=1.21 ms

64 Bytes von 192.168.0.98: icmp_seq=19 ttl=64 Zeit=0.586 ms

64 Bytes von 192.168.0.98: icmp_seq=20 ttl=64 Zeit=88.7 ms

64 Bytes von 192.168.0.98: icmp_seq=21 ttl=64 Zeit=0.554 ms

64 Bytes von 192.168.0.98: icmp_seq=22 ttl=64 Zeit=0.380 ms

64 Bytes von 192.168.0.98: icmp_seq=23 ttl=64 Zeit=0.459 ms

64 Bytes von 192.168.0.98: icmp_seq=24 ttl=64 Zeit=0.352 ms

64 Bytes von 192.168.0.98: icmp_seq=25 ttl=64 Zeit=0.823 ms

64 Bytes von 192.168.0.98: icmp_seq=26 ttl=64 Zeit=3.91 ms

64 Bytes von 192.168.0.98: icmp_seq=27 ttl=64 Zeit=0.397 ms

64 Bytes von 192.168.0.98: icmp_seq=29 ttl=64 Zeit=48.2 ms

64 Bytes von 192.168.0.98: icmp_seq=30 ttl=64 Zeit=1.27 ms

64 Bytes von 192.168.0.98: icmp_seq=31 ttl=64 Zeit=0.570 ms

64 Bytes von 192.168.0.98: icmp_seq=32 ttl=64 Zeit=2.21 ms

64 Bytes von 192.168.0.98: icmp_seq=33 ttl=64 Zeit=0.814 ms

64 Bytes von 192.168.0.98: icmp_seq=35 ttl=64 Zeit=0.573 ms

64 Bytes von 192.168.0.98: icmp_seq=36 ttl=64 Zeit=2.56 ms

64 Bytes von 192.168.0.98: icmp_seq=37 ttl=64 Zeit=0.464 ms

64 Bytes von 192.168.0.98: icmp_seq=38 ttl=64 Zeit=0.466 ms

64 Bytes von 192.168.0.98: icmp_seq=39 ttl=64 Zeit=1.35 ms

64 Bytes von 192.168.0.98: icmp_seq=40 ttl=64 Zeit=2.59 ms

64 Bytes von 192.168.0.98: icmp_seq=41 ttl=64 Zeit=0.776 ms

64 Bytes von 192.168.0.98: icmp_seq=42 ttl=64 Zeit=13.5 ms

64 Bytes von 192.168.0.98: icmp_seq=44 ttl=64 Zeit=36.7 ms

64 Bytes von 192.168.0.98: icmp_seq=45 ttl=64 Zeit=0.715 ms

64 Bytes von 192.168.0.98: icmp_seq=46 ttl=64 Zeit=0.502 ms

64 Bytes von 192.168.0.98: icmp_seq=47 ttl=64 Zeit=0.607 ms

64 Bytes von 192.168.0.98: icmp_seq=48 ttl=64 Zeit=0.400 ms

64 Bytes von 192.168.0.98: icmp_seq=49 ttl=64 Zeit=0.575 ms

64 Bytes von 192.168.0.98: icmp_seq=50 ttl=64 Zeit=0.411 ms

64 Bytes von 192.168.0.98: icmp_seq=51 ttl=64 Zeit=0.388 ms

64 Bytes von 192.168.0.98: icmp_seq=52 ttl=64 Zeit=1.36 ms

64 Bytes von 192.168.0.98: icmp_seq=53 ttl=64 Zeit=0.695 ms

64 Bytes von 192.168.0.98: icmp_seq=54 ttl=64 Zeit=0.564 ms

64 Bytes von 192.168.0.98: icmp_seq=55 ttl=64 Zeit=0.374 ms

64 Bytes von 192.168.0.98: icmp_seq=56 ttl=64 Zeit=0.488 ms

64 Bytes von 192.168.0.98: icmp_seq=57 ttl=64 Zeit=0.319 ms

64 Bytes von 192.168.0.98: icmp_seq=59 ttl=64 Zeit=26.3 ms

64 Bytes von 192.168.0.98: icmp_seq=60 ttl=64 Zeit=2.61 ms

64 Bytes von 192.168.0.98: icmp_seq=61 ttl=64 Zeit=0.648 ms

64 Bytes von 192.168.0.98: icmp_seq=63 ttl=64 Zeit=11.8 ms

64 Bytes von 192.168.0.98: icmp_seq=64 ttl=64 Zeit=0.530 ms

64 Bytes von 192.168.0.98: icmp_seq=65 ttl=64 Zeit=0.381 ms

64 Bytes von 192.168.0.98: icmp_seq=66 ttl=64 Zeit=1.03 ms

64 Bytes von 192.168.0.98: icmp_seq=67 ttl=64 Zeit=0.528 ms

64 Bytes von 192.168.0.98: icmp_seq=68 ttl=64 Zeit=0.486 ms

64 Bytes von 192.168.0.98: icmp_seq=69 ttl=64 Zeit=24.7 ms

64 Bytes von 192.168.0.98: icmp_seq=71 ttl=64 Zeit=34.1 ms

64 Bytes von 192.168.0.98: icmp_seq=72 ttl=64 Zeit=7.86 ms

64 Bytes von 192.168.0.98: icmp_seq=73 ttl=64 Zeit=70.8 ms

64 Bytes von 192.168.0.98: icmp_seq=74 ttl=64 Zeit=1.52 ms

^C

--- 192.168.0.98 ping-Statistik ---

74 Pakete übertragen, 67 empfangen, 9.45946% packet loss, time 73821ms

rtt min/avg/max/mdev = 0.319/7.097/88.691/16.628 ms

sieht nicht gut aus 🙈
 
Pingplotter und man sieht die Ergebnisse schöner und einfacher
 
  • Gefällt mir
Reaktionen: Dambedei
Dambedei schrieb:
DLAN und WLAN benutze ich beides, die Verluste passieren aber bereits wenn verkabelte Rechner die Fritze anpingen.
Und die Rechner sind alle direkt mit der Fritzbox verbunden?

Cu
redjack
 
  • Gefällt mir
Reaktionen: Dambedei
Dir ist bewusst, dass (s)vdsl und dlan (bei älteren Adapter) die Frequenzen teilen und deswegen massive Stotterer/pingspikes/lag verursachen an der Fritz selber ?
Lass mich raten, der pc ist über dlan verbunden
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Dambedei und aragorn92
Der PC ist per Kabel mit einem switch verbunden, an diesem switch hängt auch die Fritz Box.

PC <- switch -> Fritz = Paketverlust.
PC <- switch -> anderer PC = KEIN Paketverlust
 
Dambedei schrieb:
DLAN [...] benutze ich
Dambedei schrieb:
die Verluste passieren aber bereits wenn verkabelte Rechner die Fritze anpingen.
Bei verkabelt reden wir also von einer direkten LAN Verkabelung vom Client zur Fritzbox?
Oder ist DLAN für dich verkabelt?
Ergänzung ()

Dambedei schrieb:
Der PC ist per Kabel mit einem switch verbunden
aha, dann einfach mit neuem Kabel direkt an die FB und testen.
Dann schrittweise auf den vorherigen Zustand zurückbauen und testen
 
  • Gefällt mir
Reaktionen: Dambedei
Mindestens cat6 Kabel nehmen wäre noch hinzuzufügen beim Testen bin mir sicher die Kabel sind die Ursache für den Fehler.
 
  • Gefällt mir
Reaktionen: Dambedei
Habe mir ein richtig hochwertiges Kabel (cat8) gegönnt und werde berichten ob es das war :)
Ergänzung ()

Update: Habe gerade überhaupt kein packetloss mehr. Nichts verändert, selbes Kabel. Das Problem tritt also nur sporadisch auf.
 
Zuletzt bearbeitet:
Dambedei schrieb:
Habe mir ein richtig hochwertiges Kabel (cat8) gegönnt und werde berichten ob es das war :)
Ergänzung ()

Update: Habe gerade überhaupt kein packetloss mehr. Nichts verändert, selbes Kabel. Das Problem tritt also nur sporadisch auf.
Ich habe offensichtlich ein ähnliches Problem, wenn ich Pingplotter richtig lese.

Welche Kabel hast du genau getauscht? LAN-Kabel von der Box zum PC oder auch Splitter-Kabel etc.?

https://share.pingplotter.com/gzWXuQW5WHS hier mal die Pingplotter Ergebnisse.
 
NiicLas schrieb:
Welche Kabel hast du genau getauscht? LAN-Kabel von der Box zum PC oder auch Splitter-Kabel etc.?

gar keines getauscht zumindest nach der Beschreibung das es auf einmal keine Probleme mehr gab ..

aber in der aktuellen Zeit noch Splitter ? ... lass den doch mal bitte weg
 
NiicLas schrieb:
Ich habe offensichtlich ein ähnliches Problem, wenn ich Pingplotter richtig lese.
Tust du ehrlich gesagt nicht ;)

Bei Traceroute - und nichts anderes tut PingPlotter, nur eben mehrfach über einen Zeitraum - geht der allererste Blick auf die letzte Zeile, beim Ziel. Ist hier alles ok, kann A L L E S darüber ignoriert werden.

Die Zwischenstationen auf einer Route von dir zum Ziel - auch Hops genannt - sind spezialisierte Systeme, deren Hauptaufgabe das Weiterleiten von Paketen ist. Um diese Funktion nicht zu stören, reagieren einige davon verzögert oder gar nicht, wenn man sie direkt anspricht. Ungefähr so wie ein Paketbote, der nur schnell das Paket abgibt und nicht mal Zeit für ein "Hallo" geschweige denn einen Plausch hat. Würde der Paketbote auf jedes Gespräch eingehen, könnte er seinen Job nicht mehr erledigen.

Das entscheidende Kriterium ist daher immer ob das Paket rechtzeitig ankommt, also ob die letzte Zeile im Trace/PingPlotter frei von PingSpikes und Paketverlusten ist. Erst wenn hier Probleme erkennbar sind, geht man auf die Suche bei den Zwischenstationen. Wenn dein Paket also 10 Tage braucht statt 3, kannst du sinngemäß den Absender, dessen Paketboten, den Typen an der dortigen Sortieranlage, den LKW-Fahrer, den Typen an der hiesigen Sortieranlage und zu guter Letzt deinen Paketboten fragen und dabei kommt womöglich heraus, dass der LKW-Fahrer zu lange braucht, weil er auf der Autobahn nur 30 km/h fährt und dadurch alles nach ihm verzögert wird - und das ist das Stichwort, alles nach ihm inkl. Ziel.


Dies ist beispielsweise ein vollkommen "ok-er" Trace:

1 - timeout <-- Verkäufer reagiert nicht auf deine Anrufe, hat das Paket aber abgegeben
2 - timeout <-- Paketbote1 hat kein Telefon, aber hat das Paket abgeholt
3 - timeout <-- Sortiertyp1 telefoniert nicht gern, sortiert aber eifrig
4 - timeout <-- LKW-Fahrer hat keinen Empfang, aber fährt unermüdlich LKW
5 - timeout <-- Sortiertyp2 telefoniert auch nicht gern, sortiert aber noch eifriger
5 - timeout <-- Paketbote2 hat sein Handy vergessen, aber liefert fleißig aus
Ziel: 10ms <-- Du, dein Paket kommt püntklich an

Schlechter Trace:

1 - 1ms <-- Verkäufer hat das Paket korrekt abgegeben
2 - 10ms <-- Paketbote1 hat das Paket abgeholt
3 - 11ms <-- Sortiertyp1 sortiert das Paket
4 - 800ms <-- LKW-Fahrer gurkt nur mit 30 km/h über die Autobahn
5 - 801ms <-- Sortiertyp2 wartet auf den LKW-Fahrer und kann erst dann sortieren
5 - 802ms <-- Paketbote2 wartet auf den Sortiertyp2, der auf den LKW-Fahrer warten musste und fährt los
Ziel: 802ms <-- Du, dein Paket kommt verspätet an, weil der LKW-Fahrer zu lahm war...

Erst dann, wenn am Ziel Pingspikes und/oder Paketverluste angezeigt werden, schaut man sich die Zwischenstationen an und findet womöglich den Verursacher, der auch beim Weiterleiten verzögert reagiert und somit die Pingspikes bzw. Paketverluste ebenfalls durchreicht.
 
  • Gefällt mir
Reaktionen: Der Lord, xexex und bart0rn
Raijin schrieb:
Erst dann, wenn am Ziel Pingspikes und/oder Paketverluste angezeigt werden, schaut man sich die Zwischenstationen an und findet womöglich den Verursacher, der auch beim Weiterleiten verzögert reagiert und somit die Pingspikes bzw. Paketverluste ebenfalls durchreicht.
Den Post habe ich mir direkt mal in der Merkliste gespeichert, besser kann man es schlichtweg nicht erklären!
 
  • Gefällt mir
Reaktionen: bart0rn und Raijin
Zurück
Oben