ISP behauptet, es sei nichts falsch. Was kann ich machen?

837
Mike Pateras

Tagsüber sind die Dinge normalerweise in Ordnung, aber nachts ist alles, was Bandbreite erfordert (ich habe eine 30-Mbit / s-Glasfaser-Verbindung, obwohl ich nicht der Meinung bin, dass es eine durchgehende Glasfaser ist) oder eine konsistente Verbindung (alias Spielen) ist völlig unbrauchbar. Ich habe einige WinMTR-Spuren aufgenommen, und an mehreren Stellen passiert offensichtlich ein Paketverlust, sobald wir an meinem Modem vorbeikommen:

|------------------------------------------------------------------------------------------| | WinMTR statistics | | Host - % | Sent | Recv | Best | Avrg | Wrst | Last | |------------------------------------------------|------|------|------|------|------|------| | 192.168.1.1 - 0 | 886 | 886 | 0 | 0 | 21 | 0 | | 192.168.200.1 - 0 | 886 | 886 | 0 | 0 | 3 | 0 | | EV1-DSL-208-102-228-1.fuse.net - 88 | 185 | 23 | 0 | 3315 | 4530 | 4088 | | 172.17.74.18 - 2 | 827 | 812 | 27 | 30 | 34 | 30 | | EV-ZT-1.EVE1.core.fuse.net - 2 | 839 | 827 | 27 | 30 | 68 | 30 | |te0-0-2-2.nr11.b016343-1.cvg02.atlas.cogentco.com - 2 | 823 | 807 | 28 | 30 | 35 | 31 | |te0-0-1-1.rcr11.cvg02.atlas.cogentco.com - 4 | 791 | 767 | 28 | 31 | 36 | 31 | |te0-2-0-0.rcr21.ind01.atlas.cogentco.com - 3 | 819 | 802 | 30 | 33 | 37 | 34 | |te0-0-2-2.rcr11.sdf01.atlas.cogentco.com - 2 | 823 | 807 | 32 | 35 | 39 | 36 | |te0-0-2-2.rcr11.bna01.atlas.cogentco.com - 3 | 819 | 802 | 37 | 39 | 43 | 40 | |te0-18-0-34.ccr42.atl01.atlas.cogentco.com - 3 | 799 | 777 | 43 | 45 | 50 | 45 | | be2173.ccr22.iah01.atlas.cogentco.com - 3 | 819 | 802 | 63 | 66 | 70 | 66 | | be2066.ccr22.lax01.atlas.cogentco.com - 2 | 827 | 812 | 100 | 102 | 107 | 102 | | be2179.ccr23.lax05.atlas.cogentco.com - 2 | 823 | 807 | 99 | 103 | 109 | 104 | | att.lax05.atlas.cogentco.com - 3 | 815 | 797 | 101 | 105 | 122 | 105 | | cr1.la2ca.ip.att.net - 3 | 795 | 772 | 96 | 100 | 105 | 100 | | gar5.lsrca.ip.att.net - 3 | 799 | 777 | 96 | 115 | 402 | 110 | | 12-122-254-230.attens.net - 4 | 786 | 761 | 96 | 107 | 319 | 99 | | 206.16.68.42 - 2 | 823 | 807 | 95 | 106 | 328 | 98 | | No response from host - 100 | 177 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 177 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 177 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 177 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 177 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 177 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 177 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 177 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 177 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 177 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 177 | 0 | 0 | 0 | 0 | 0 | |________________________________________________|______|______|______|______|______|______| WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

Wie Sie sehen, bekomme ich 88% Paketverlust, sobald wir an meinem Modem (192.168.200.1) vorbeigekommen sind. Das wird nicht wirklich für mich funktionieren.

Das ist eine Spur zu einem Blizzard-Server, aber ich bekomme auch Verluste, wenn ich mit Google pinge.

Am aussagekräftigsten ist jedoch, dass in der obigen Spur der erste Sprung eine fuse.net-Adresse ist:

EV1-DSL-208-102-228-1.fuse.net - 88 | 185 | 23

ist offensichtlich mein ISP (fuse.net ist eine Cincinnati Bell Domain). Sie behaupten jedoch, dass das Problem nicht an ihrem Ende liegt und dass meine Verbindung in Ordnung ist (sie haben "Tests" durchgeführt). Wenn ich anrufe, fordere ich nur auf, mit dem technischen Support auf höherer Ebene zu sprechen (ich werde zu einem "Supervisor" geleitet, der höchsten Ebene des Kundensupports). Ich weigere mich, mit dem Support-Level des Eintrags (Neustart des Routers) zu sprechen, aber das tut es nicht Es scheint keine Ergebnisse zu geben.

Was kann ich machen? Wenn sie behaupten, dass es kein Problem gibt und mich nicht helfen wollen, was kann ich sonst tun?

Hat jemand irgendwelche Vorschläge?

0

2 Antworten auf die Frage

1
Jay

Versuchen Sie zunächst, Ihren lokalen Router zu pingen. Wenn Sie dann Pakete verlieren. Sie wissen, dass das Problem zwischen Ihrem PC und Ihrem Router liegt und nichts mit Ihrem ISP zu tun hat.

Wenn alles in Ordnung ist und Sie alle Ihre Pakete erhalten, können Sie zum nächsten Teil Ihres Netzwerks wechseln. das ist zwischen dem Router und Ihrem Schrank. Wenn dies der Fall ist, gibt es ihren Beweis. Sagen Sie "Sehen Sie, ich kann meinen Router von meinem PC aus pingen (Beweismittel). Die einzige logische Erklärung ist, dass es sich nicht um ein lokales Netzwerk in meinem unmittelbaren Netzwerk handelt."

Ihre Aufgabe ist es, Ihnen zu helfen - ich weiß, es ist frustrierend, aber helfen Sie ihnen, Ihnen zu helfen. Wenn Sie ihnen einen logischen Gedankengang mit Beweisen geben. Sie können es nicht wirklich leugnen.

Viel Glück.

Zeigen die ersten beiden Hops (192.168.1.1 und 192.168.200.1, mein Router bzw. mein Modem) nicht bereits, dass alles in Ordnung ist, bis das Signal mein Haus verlässt? Mike Pateras vor 9 Jahren 0
0
matteo

Im Allgemeinen sollten Sie sich bei MTR (oder WinMTR) nicht zu sehr auf den Paketverlust von Zwischensprüngen konzentrieren, da dies normalerweise durch Schwellenwerte für den ICMP-Datenverkehr verursacht wird, die für sich selbst bestimmt sind (da diese Art von Datenverkehr normalerweise zusätzliche Ressourcen erfordert). Wenn Sie einen gewissen Paketverlust in einem Hop sehen, gefolgt von einem Paketverlust von 0% im nächsten Hop, können Sie ziemlich sicher sein, dass es sich nicht um einen Verlust handelt, der sich tatsächlich auf Ihren Datenverkehr auswirkt (mit anderen Worten, ein echter Verlust in einem bestimmten Bereich) Hop zeigt den gleichen oder mehr Paketverlust in ALLEN nächsten Hops bis zum Ziel. Schauen Sie sich auch die durchschnittliche Latenzzeit an, um die Leistung zu verstehen, und behalten Sie die Standardabweichung im Auge (wenn diese zu hoch ist, macht die durchschnittliche Latenzzeit keinen Sinn, aber ich bin nicht sicher, ob WinMTR sie übrigens anzeigen kann).

Wenn Sie Ihre Ausgabe trotzdem betrachten, sehe ich etwa 2% Verlust und eine Latenzzeit von etwa 160 ms bis zum letzten verfolgten Sprung, nichts, was auf ein unbrauchbares Netzwerk hinweist.

Leider zeigt Ihre MTR nicht den vollständigen Pfad an, aber wenn Sie dasselbe Problem mit anderen Internetdiensten haben, können Sie IP-Adressen verfolgen, die wie 8.8.8.8 antworten.

Beachten Sie jedoch, dass MTR nicht den gleichen Fluss darstellt, den Sie für Ihren Service verwenden. Um diese Konnektivität besser testen zu können, sollten Sie einen "iperf" -Test einrichten, der die gleichen Sockets von Ihnen verwendet. Dies ist jedoch nicht möglich, wenn Sie keinen Zugriff auf das Remote-Netzwerk haben. Wenn nur die MTR verwendet wird, werden Bandbreiteninformationen übersehen. Der Datenverkehr kann auf dem Pfad anders gestaltet werden als bei der MTR-Datenübertragung usw.

Wenn sich Ihre Probleme nicht nur auf diesen bestimmten Dienst beziehen, sondern auf das gesamte Surfen im Internet, könnten Tests wie www.speedtest.net/ Ihnen große Einblicke geben.

Verwandte Probleme