8
Kann man speziell herausfinden woher eine Zeitüberschreitung kommt?
Also wo letztendlich der Knoten herkommt?
Gibt es hierfür spezielle Netzwerkdiagnose-Tools?
Vielen Dank.
Mfg
cramtroni
Gibt es hierfür spezielle Netzwerkdiagnose-Tools?
Vielen Dank.
Mfg
cramtroni
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 368780
Url: https://administrator.de/forum/kann-man-speziell-herausfinden-woher-eine-zeitueberschreitung-kommt-368780.html
Ausgedruckt am: 02.04.2025 um 05:04 Uhr
8 Kommentare
Neuester Kommentar
Moin,
jo, schaue dir dazu mal dieses Tool an.
Damit ist alles möglich
Gruß
em-pie
P.S.
Sorry für meinen unqualifizierenden Kommentar, aber mit solch einer dünnen AUsgangslage kann man nicht wirklich zielführend helfen
jo, schaue dir dazu mal dieses Tool an.
Damit ist alles möglich
Gruß
em-pie
P.S.
Sorry für meinen unqualifizierenden Kommentar, aber mit solch einer dünnen AUsgangslage kann man nicht wirklich zielführend helfen
Hallo Cramtroni,
gehen wir die Frage mal theoretisch an:
Wodurch kann eine Zeitüberschreitung alles kommen?
"Mit welchem Handwerkszeug kann man die einzelnen Fälle ermitteln" gibt dir dann die Antwort auf das wo
VG
PS: Kurzer knackiger Betreff wäre sinnvoller, obiges wäre eine Frage für Google.
gehen wir die Frage mal theoretisch an:
Wodurch kann eine Zeitüberschreitung alles kommen?
"Mit welchem Handwerkszeug kann man die einzelnen Fälle ermitteln" gibt dir dann die Antwort auf das wo
VG
PS: Kurzer knackiger Betreff wäre sinnvoller, obiges wäre eine Frage für Google.
Hallo,
Welche OSe sind beteiligt?
Welche Protokolle sind beteiligt (Nein, nicht TCP oder UDP, aber die auch)?
Wo sitzt du in der Verbindungskette?
Kann der (Ursprung) Knoten überhaupt Identifiziert werden?
Welche Gerätschaften wie z.B. Router sind involviert?
Also Strom kommt für dich eben aus einer Steckdose in der Wand und Wasser eben aus einen Wasserhahn
Gruß,
Peter
Welche OSe sind beteiligt?
Welche Protokolle sind beteiligt (Nein, nicht TCP oder UDP, aber die auch)?
Wo sitzt du in der Verbindungskette?
Kann der (Ursprung) Knoten überhaupt Identifiziert werden?
Welche Gerätschaften wie z.B. Router sind involviert?
Gibt es hierfür spezielle Netzwerkdiagnose-Tools?
Also ich will jetzt wissen welcher PC in China eine nicht beantwortete ICMP Anfrage gestellt hat? Und ich sitze am PC in Lichtenstein.Also Strom kommt für dich eben aus einer Steckdose in der Wand und Wasser eben aus einen Wasserhahn
Gruß,
Peter
Unter Linux ist mtr ganz nice, ist eine combi aus traceroute und ping
Anhand der Fragestellung kann man daraus schliessen:
Ich habe keine Ahnung aber ich habe ein Problem, ich weiß nur nicht welches.
@cramtoni: Entschuldige, Du lieferst KEINERLEI Informationen, hast aber eine Frage.
Wie Du eine Frage richtig stellst
Gruss Penny.
Ich habe keine Ahnung aber ich habe ein Problem, ich weiß nur nicht welches.
@cramtoni: Entschuldige, Du lieferst KEINERLEI Informationen, hast aber eine Frage.
Wie Du eine Frage richtig stellst
Gruss Penny.
Ja klar. Ein Time Out findet immer auf dem Client statt, der ihn anzeigt. ;)
ja am einfachsten mit tracert (ziel) oder transroute (ziel).
Jetzt nochmal ernsthaft:
Ein Time Out heißt nur, dass der Client nicht mehr auf die Antwort des Servers wartet. Es dauert dem Client zu lange. Also ist der Verursacher des Time Outs immer der Client. Warum es zu lange dauert, interessiert den Client nicht weiter.
Dass es zu lange dauert, kann hunderte von Ursachen haben. Ein Paket steckt irgendwo im Netz fest z. B. in einem Routing Loop. Oder der Server ist gerade ausgelastet und antwortet nicht schnell genug. Oder die Wartezeit ist auf dem Client zu kurz eingestellt. Oder wir haben gerade Sonnenwinde oder eine Wasserader hat starken Durchfluss ... ;)
90% aller dieser Ursachen sind kurzlebig. D. h., wenn Du hinterher versuchst, die Ursache dafür, warum es zu lange gedauert hat, herauszufinden, ist der "Fehler" gar nicht mehr da. Also kannst Du das auch nicht mehr feststellen. Wozu auch? Es geht ja wieder. Eine Ursachenforschung lohnt sich nur dann, wenn Time Outs bei bestimmten Vorgängen immer wieder vorkommen. Wie man das macht, hängt nun davon ab, auf welcher OSI-Ebene der Time Out stattfindet. Welche Software ist beteiligt? Welche Wege werden beschritten? usw. usf.
Ein Time Out heißt nur, dass der Client nicht mehr auf die Antwort des Servers wartet. Es dauert dem Client zu lange. Also ist der Verursacher des Time Outs immer der Client. Warum es zu lange dauert, interessiert den Client nicht weiter.
Dass es zu lange dauert, kann hunderte von Ursachen haben. Ein Paket steckt irgendwo im Netz fest z. B. in einem Routing Loop. Oder der Server ist gerade ausgelastet und antwortet nicht schnell genug. Oder die Wartezeit ist auf dem Client zu kurz eingestellt. Oder wir haben gerade Sonnenwinde oder eine Wasserader hat starken Durchfluss ... ;)
90% aller dieser Ursachen sind kurzlebig. D. h., wenn Du hinterher versuchst, die Ursache dafür, warum es zu lange gedauert hat, herauszufinden, ist der "Fehler" gar nicht mehr da. Also kannst Du das auch nicht mehr feststellen. Wozu auch? Es geht ja wieder. Eine Ursachenforschung lohnt sich nur dann, wenn Time Outs bei bestimmten Vorgängen immer wieder vorkommen. Wie man das macht, hängt nun davon ab, auf welcher OSI-Ebene der Time Out stattfindet. Welche Software ist beteiligt? Welche Wege werden beschritten? usw. usf.
