Frage
Antwort
Lösung
am 27.03.2019 19:08
Im wesentlichen wird der folgende Thread ein Duplikat dieses alten von jemand anderem. Dort habe ich leider keine Antwort auf meinen Post erhalten, vermutlich, da der Thread als "gelöst" markiert ist. Daher hier mein eigener:
Ich sehe seit längerem hohe Paketverluste innerhalb des 145.254.2.0/23 Subnetzes im Vodafone Backbone. Laut Traceroute werden zwischen 10-50% der Pakete gedroppt, z.B. von den Hosts 145.254.2.207, 145.254.2.217 und 145.254.2.195. Das ist so viel, dass es sehr deutlich spürbare Auswirkungen auf die Internetverfügbarkeit gibt.
Ich habe mal exemplarisch einen Screencast von der Seite speedtest.net erstellt, der das verdeutlicht: http://storage.pberndt.com/speedtest_vodafone.mp4
Diese Seite wähle ich nicht zufällig: Meine ersten Versuche, diesbezüglich mit dem Kundendienst in Kontakt zu treten, machte ich telefonisch. Meine Ansage, dass es Paketverluste gebe, wurde mit der Bitte gekontert, doch mal dort einen Speedtest durchzuführen - mit demselben Ergebnis wie im Video. Das führte dazu, dass mir ein Techniker vorbeigeschickt wurde, dem "Komplettausfall Internet" auf den Zettel geschrieben wurde. Meine Beteuerungen, dass Paketverluste im Backbone doch vermutlich eher nichts mit der letzten Meile zu tun hätten, zumal die Leitungswerte gut sind, half da auch nicht. Eine andere Auswirkung ist, dass Streamingdienste wie Netflix, Amazon Video und YouTube abends kaum bis gar nicht nutzbar sind. Webseiten sind ebenfalls kaum benutzbar. Die SSH Verbindung, mit der ich das Video gerade hochgeladen habe, hat sekundenlange aussetzer.
Konkrete Fragen:
Vielen Dank!
Gelöst! Gehe zu Lösung.
am 18.04.2019 12:31
Hallo Phillip_ ,
das Feedback des Fachbereichs lautet, dass der Zielhop mit sehr geringem Packetloss ohne Probleme erreichbar ist und die Verluste bei Hops in der Mitte der Route irrelevant sind. Das ist beim aktuellen Beispiel ja ebenfalls der Fall.
Viele Grüße,
Claudia
am 29.03.2019 13:55
Hallo Phillip_,
ich habe mir Deinen Anschluss angesehen und kann da nichts feststellen. Keine Fehlerraten, keine Abbrüche, am CMTS alles in Ordnung.
Kannst Du bitte einen pingplotter laufen lassen, damit wir sehen können, wo der PL auftritt?
Viele Grüße, Manu
am 29.03.2019 21:35
Wie im Titel geschrieben, die Paketverluste treten im 145.254.2.0/23 Netz auf, vor allem an den IPs
145.254.2.207,
145.254.2.217 und
145.254.2.195.
Heute Abend nicht so stark, da sehe ich z.B. in der Route zu youtube.de 3% Paketverlust am Hop 145.254.2.217. Aber die hohen Verlustraten treten seit Monaten sehr regelmäßig auf, also bitte nicht als "na dann ist das ja offensichtlich gelöst" abtun 🙂
am 01.04.2019 14:30
Hi Phillip_,
wir brauchen dennoch mal einen Screenshot vom Plotter. Somit haben wir etwas anschauliches Bildmaterial für die Fachabteilung, damit sie den Fehler ausfindig machen können
Viele Grüße
Marco
03.04.2019 20:42 - bearbeitet 03.04.2019 20:45
Ich hatte die Tabelle aus dem Programm abgeschrieben statt einen Screenshot zu machen. Das sollte ja genauso reichen:
Hop Count IP Name Avg Min Cur PL% 1. 860 192.168.0.1 _gateway 0.2 0.2 0.3 0.0 2. 860 192.168.100.1 192.168.100.1 2.0 1.2 1.8 0.1 3. 860 83.169.183.95 83-169-183-95-isp.superkabel.de 20.9 9.1 10.1 0.2 4. 860 88.134.234.71 ip5886ea47.static.kabel-deutschland.de 17.8 9.4 14.4 0.1 5. 860 145.254.3.70 145.254.3.70 20.8 12.5 13.5 0.1 6. 860 145.254.2.207 145.254.2.207 28.0 20.2 24.7 29.0 7. 860 145.254.2.207 145.254.2.207 27.4 20.4 24.5 32.4 8. 860 80.81.192.239 et-7-0-0-u100.cr-polaris.fra1.core.heg.com 28.6 19.4 20.9 0.1 9. 859 87.230.114.9 ae1.cr-vega.sxb1.core.heg.com 32.1 22.3 25.0 0.1 10. 859 - ae0-v100.sr-helios.sxb1.mass.systems 32.1 23.1 26.1 0.2
Ansonsten siehe auch hier. Der ist nicht von mir, aber exakt entlang dieses Pfades hatte ich selbst auch Paketverluste an diesem Hop gesehen.
am 05.04.2019 08:47
Hallo Phillip_,
ein Screenshot eines anderen Kunden nützt natürlich nichts und ein Bild wäre besser gewesen. Ich habe den Tracert trotzdem zur Prüfung an den Folgebereich weitergegeben.
Viele Grüße,
Claudia
am 16.04.2019 16:58
Gibt's schon was neues?
Habe gerade den nächsten Fall, dieses mal ist 145.254.2.179 betroffen. Verbindungen in die Google und Amazon Cloud sind besonders betroffen. Dieses mal ist das vor Allem ärgerlich, da ich die Verbindung beruflich benötige.
Traceroute:
Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. _gateway 25.9% 59 0.3 0.3 0.2 0.4 0.0 2. ip5f5aa0fe.dynamic.kabel-deutschland.de 1.7% 59 13.3 11.5 7.4 19.6 3.0 3. ip5886d7b6.static.kabel-deutschland.de 0.0% 59 10.1 11.2 8.1 22.8 3.0 4. ip5886c324.static.kabel-deutschland.de 0.0% 59 9.9 11.2 7.3 24.8 2.9 5. 145.254.3.70 0.0% 59 11.1 13.7 10.1 27.4 2.8 6. 145.254.2.179 22.0% 59 25.8 21.2 18.1 29.2 2.2 7. 145.254.2.179 27.1% 59 22.2 21.9 17.7 34.2 3.7 8. 52.95.219.132 0.0% 59 20.5 20.8 17.3 27.3 2.5 9. 54.239.106.226 0.0% 59 29.6 23.0 18.1 35.2 3.8 10. 54.239.106.89 0.0% 59 19.4 23.0 17.1 36.6 3.7 11. 54.239.5.54 0.0% 59 20.2 22.1 18.1 27.8 2.4 12. 54.239.107.154 0.0% 59 20.0 22.7 18.4 40.0 3.6 13. 54.239.4.87 0.0% 59 24.9 22.8 17.8 39.7 4.3
am 18.04.2019 12:31
Hallo Phillip_ ,
das Feedback des Fachbereichs lautet, dass der Zielhop mit sehr geringem Packetloss ohne Probleme erreichbar ist und die Verluste bei Hops in der Mitte der Route irrelevant sind. Das ist beim aktuellen Beispiel ja ebenfalls der Fall.
Viele Grüße,
Claudia
am 18.04.2019 22:21
Danke! Da habe ich dann scheinbar mit meiner Beschreibung ein XY Problem erzeugt: Gefragt nach Y, dabei ist mein eigentliches Problem X 🙂 Dass es ein ICMP Rate Limiting geben könnte hatte ich nicht bedacht, Entschuldigung für die Verwirrung.
Ich gehe dann stark davon aus, dass die Probleme aus dem 1. Post doch mit den allgemeinen Verbindungsproblemen zusammenhängen - dafür gibt's schon länger einen anderen Thread, insofern kann der hier zu.
18.04.2019 22:23 - bearbeitet 18.04.2019 22:24
Dann schließe ich den Thread.
Gruß Kurt