Paketverlust im Vodafone Backend (145.254.2.0/23)
Phillip_
Netzwerkforscher
Netzwerkforscher

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:

 

  1. Im anderen Thread wurde eine Gutschrift diskutiert. Da bin ich auch dran interessiert.
  2. Vor allem möchte ich dieses Problem aber natürlich aus der Welt geschafft wissen. Der andere Thread versprach eine Lösung im März - der hat nur noch zwei Werktage. Ist das Datum noch aktuell?
  3. Drittens würde ich gerne Zugang zu einem technisch besser ausgebildeten Telefonischen Support bekommen. Jedes mal den Fragenkatalog nach Browserversion, LAN, etc. durchzurattern, auch wenn ich das Telefonat mit einer klaren Ansage eröffne, was schief läuft, ist schrecklich frustrierend. Da ich meinen Anschluss auch beruflich nutze frage ich mich, ob mir ein Wechsel in einen Geschäftskundentarif hier Vorteile bringen würde?

Vielen Dank!

1 Akzeptierte Lösung

Akzeptierte Lösungen
Claudia
Ex-Moderator:in
Ex-Moderator:in

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

Bewertet hilfreiche Beiträge mit Likes!

Lösung in ursprünglichem Beitrag anzeigen

9 Antworten 9
Manu
Ex-Moderator:in
Ex-Moderator:in

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

 

Bewertet hilfreiche Beiträge mit Likes und Sternen!
Phillip_
Netzwerkforscher
Netzwerkforscher

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 🙂

pRo-Marco
Ex-Moderator:in
Ex-Moderator:in

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 Smiley (zwinkernd)

 

Viele Grüße

Marco

Bewertet hilfreiche Beiträge mit Likes und Sternen!

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.

Claudia
Ex-Moderator:in
Ex-Moderator:in

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

Bewertet hilfreiche Beiträge mit Likes!

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
Claudia
Ex-Moderator:in
Ex-Moderator:in

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

Bewertet hilfreiche Beiträge mit Likes!

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.

Dann schließe ich den Thread.

 

Gruß Kurt

Bitte keine Anfragen über PN stellen!