Frage
Antwort
Lösung
am 22.02.2021 11:52
Hallo
Welcher Fehler tritt auf? Über den gesammten Tag: Packetloss so bis 10%. Wenn 50% übersteigt, wird die Verbindung von meinem Router als Tot deklariert. Unter 20% loggt er glaub ich nichts, es sei denn er war vorher drüber und loggt das "verlassen" aus dem Fehler. Das sieht dann so aus für den Februar:
Feb 22 07:59:22
send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 188.192.214.254 bind_addr 188.192.214.181 identifier "WAN_CABLE_DHCP "
Feb 22 06:24:48
WAN_CABLE_DHCP 188.192.214.254: Clear latency 19523us stddev 54393us loss 5%
Feb 22 06:21:52
WAN_CABLE_DHCP 188.192.214.254: Alarm latency 0us stddev 0us loss 100%
Feb 22 06:21:50
send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 188.192.214.254 bind_addr 188.192.214.181 identifier "WAN_CABLE_DHCP "
Feb 22 06:20:25
WAN_CABLE_DHCP 188.192.214.254: Alarm latency 0us stddev 0us loss 100%
Feb 22 06:20:23
send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 188.192.214.254 bind_addr 188.192.214.181 identifier "WAN_CABLE_DHCP "
Feb 22 06:17:57
WAN_CABLE_DHCP 188.192.214.254: Alarm latency 13501us stddev 6445us loss 21%
Feb 21 18:24:59
WAN_CABLE_DHCP 188.192.214.254: Clear latency 25812us stddev 59460us loss 5%
Feb 21 18:18:06
WAN_CABLE_DHCP 188.192.214.254: Alarm latency 25654us stddev 78172us loss 22%
Feb 21 15:24:41
WAN_CABLE_DHCP 188.192.214.254: Clear latency 15845us stddev 16396us loss 6%
Feb 21 15:17:58
WAN_CABLE_DHCP 188.192.214.254: Alarm latency 19108us stddev 35946us loss 22%
Feb 20 18:24:42
WAN_CABLE_DHCP 188.192.214.254: Clear latency 13043us stddev 17515us loss 5%
Feb 20 18:22:53
WAN_CABLE_DHCP 188.192.214.254: Alarm latency 0us stddev 0us loss 100%
Feb 20 18:22:51
send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 188.192.214.254 bind_addr 188.192.214.181 identifier "WAN_CABLE_DHCP "
Feb 20 18:18:03
WAN_CABLE_DHCP 188.192.214.254: Alarm latency 12758us stddev 14536us loss 21%
Feb 17 20:38:26
WAN_CABLE_DHCP 188.192.214.254: Clear latency 194580us stddev 615239us loss 11%
Feb 17 20:37:52
WAN_CABLE_DHCP 188.192.214.254: Alarm latency 44317us stddev 101633us loss 21%
Feb 17 18:25:36
WAN_CABLE_DHCP 188.192.214.254: Clear latency 34309us stddev 152703us loss 5%
Feb 17 18:18:54
WAN_CABLE_DHCP 188.192.214.254: Alarm latency 11069us stddev 6037us loss 22%
Feb 16 15:24:53
WAN_CABLE_DHCP 188.192.214.254: Clear latency 21886us stddev 64629us loss 5%
Feb 16 15:18:19
WAN_CABLE_DHCP 188.192.214.254: Alarm latency 12578us stddev 9951us loss 21%
Feb 13 21:23:36
send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 188.192.214.254 bind_addr 188.192.214.181 identifier "WAN_CABLE_DHCP "
Feb 13 21:21:55
WAN_CABLE_DHCP 188.192.214.254: Alarm latency 0us stddev 0us loss 100%
Feb 13 21:21:53
send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 188.192.214.254 bind_addr 188.192.214.181 identifier "WAN_CABLE_DHCP "
Feb 13 21:17:38
WAN_CABLE_DHCP 188.192.214.254: Alarm latency 13580us stddev 21533us loss 21%
Feb 13 09:10:46
WAN_CABLE_DHCP 188.192.214.254: Clear latency 59007us stddev 218117us loss 14%
Feb 13 09:09:41
WAN_CABLE_DHCP 188.192.214.254: Alarm latency 62401us stddev 162218us loss 21%
Feb 10 21:20:51
WAN_CABLE_DHCP 188.192.214.254: Clear latency 43967us stddev 91837us loss 15%
Feb 10 21:20:34
WAN_CABLE_DHCP 188.192.214.254: Alarm latency 82518us stddev 154982us loss 21%
Feb 9 21:24:13
WAN_CABLE_DHCP 188.192.214.254: Clear latency 56148us stddev 232804us loss 14%
Feb 9 21:23:38
WAN_CABLE_DHCP 188.192.214.254: Alarm latency 0us stddev 0us loss 100%
Feb 9 21:23:36
send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 188.192.214.254 bind_addr 188.192.214.181 identifier "WAN_CABLE_DHCP "
Feb 9 21:18:01
WAN_CABLE_DHCP 188.192.214.254: Alarm latency 11922us stddev 12599us loss 21%
Feb 8 12:26:32
WAN_CABLE_DHCP 188.192.214.254: Clear latency 45369us stddev 107548us loss 5%
Feb 8 12:24:50
WAN_CABLE_DHCP 188.192.214.254: Alarm latency 0us stddev 0us loss 100%
Feb 8 12:24:48
send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 188.192.214.254 bind_addr 188.192.214.181 identifier "WAN_CABLE_DHCP "
Feb 8 12:19:49
WAN_CABLE_DHCP 188.192.214.254: Alarm latency 25449us stddev 80021us loss 22%
Feb 7 21:24:20
WAN_CABLE_DHCP 188.192.214.254: Clear latency 41639us stddev 117567us loss 5%
Feb 7 21:17:34
WAN_CABLE_DHCP 188.192.214.254: Alarm latency 12298us stddev 8518us loss 22%
Feb 6 12:22:54
WAN_CABLE_DHCP 188.192.214.254: Clear latency 55366us stddev 198071us loss 14%
Feb 6 12:22:21
WAN_CABLE_DHCP 188.192.214.254: Alarm latency 25558us stddev 36723us loss 21%
Feb 6 12:04:45
WAN_CABLE_DHCP 188.192.214.254: Clear latency 108977us stddev 413348us loss 0%
Feb 6 12:04:07
WAN_CABLE_DHCP 188.192.214.254: Alarm latency 505022us stddev 1473536us loss 0%
Feb 6 12:04:05
WAN_CABLE_DHCP 188.192.214.254: Clear latency 492680us stddev 1457040us loss 0%
Feb 6 12:03:33
WAN_CABLE_DHCP 188.192.214.254: Alarm latency 539976us stddev 1497828us loss 7%
Feb 3 14:57:41
send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 188.192.214.254 bind_addr 188.192.214.181 identifier "WAN_CABLE_DHCP "
PING 188.192.214.254 (188.192.214.254): 56 data bytes 64 bytes from 188.192.214.254: icmp_seq=0 ttl=64 time=13.016 ms 64 bytes from 188.192.214.254: icmp_seq=1 ttl=64 time=10.521 ms 64 bytes from 188.192.214.254: icmp_seq=2 ttl=64 time=10.724 ms 64 bytes from 188.192.214.254: icmp_seq=3 ttl=64 time=10.138 ms 64 bytes from 188.192.214.254: icmp_seq=4 ttl=64 time=10.756 ms 64 bytes from 188.192.214.254: icmp_seq=5 ttl=64 time=10.732 ms 64 bytes from 188.192.214.254: icmp_seq=6 ttl=64 time=9.414 ms 64 bytes from 188.192.214.254: icmp_seq=7 ttl=64 time=11.315 ms 64 bytes from 188.192.214.254: icmp_seq=9 ttl=64 time=9.682 ms --- 188.192.214.254 ping statistics --- 10 packets transmitted, 9 packets received, 10.0% packet loss round-trip min/avg/max/stddev = 9.414/10.700/13.016/0.988 ms
Für Vodavon ist das vermutlich kein Problem solange innerhalb von 10 Sekunden ein zwei Pakete durchkommen, damit der Anschluss vermutlich als Online gekennzeichent wird (TCP wirds schon richten). Für Online-Konferenzen und VPN ist das ganze Gift, bis zur Arbeitsunfähig.
- Die Frage ist, wie möchte das Vodavon von mir bewiesen/dokumentiert haben? (Damit eine echte Störungsbeseitigung initiert werden kann)
- Ist überhaupt Abhilfe in aussicht bei solch einem "Fehler"? (Oder ist das ein erwartetes von Vodafon toleriertes Verhalten?)
Gruß Frank
Gelöst! Gehe zu Lösung.
am 03.03.2021 10:21
Aha, 009-0304205/21 wurde geschlossen. Es war kein Techniker hier. Das einzige was passiert ist, das ich telefonisch einem Vorort-Termin zugesagt habe.
Und genau das ist der einzige dokumentierte Bestandteil des erfolgreich geschlossenen Vorgangs.
Ich hab immer noch Packagedrop.
Heute 10:22:
PING 188.192.214.254 (188.192.214.254): 56 data bytes 64 bytes from 188.192.214.254: icmp_seq=0 ttl=64 time=11.333 ms 64 bytes from 188.192.214.254: icmp_seq=1 ttl=64 time=46.578 ms 64 bytes from 188.192.214.254: icmp_seq=2 ttl=64 time=9.114 ms 64 bytes from 188.192.214.254: icmp_seq=3 ttl=64 time=60.596 ms 64 bytes from 188.192.214.254: icmp_seq=4 ttl=64 time=7.864 ms 64 bytes from 188.192.214.254: icmp_seq=5 ttl=64 time=10.659 ms 64 bytes from 188.192.214.254: icmp_seq=6 ttl=64 time=6.997 ms 64 bytes from 188.192.214.254: icmp_seq=7 ttl=64 time=12.498 ms 64 bytes from 188.192.214.254: icmp_seq=9 ttl=64 time=13.961 ms --- 188.192.214.254 ping statistics --- 10 packets transmitted, 9 packets received, 10.0% packet loss round-trip min/avg/max/stddev = 6.997/19.956/60.596/18.392 ms
am 03.03.2021 12:30
OK, Techniker war gerade da. Hat Dämpfung auf den oberen Frequenzen festgestellt (direkt am Übergabepunkt). Hausanlage wurde inspiziert. Es erfolgt eine Übergabe an einen Level3 Techniker (Fehler liegt vor dem Hausanschluss). So wurde es mit erklärt.
Leider ist jetzt Ende Gelände mit Nachvollziehbarkeit. Kein SR oder sonst was, ich soll 2 Wochen warten. Wenn nix passier erneut Vodafon kontaktieren. Naja...
am 04.03.2021 11:39
Hallo stei-f,
der Aufrag ist noch offen und der Unterpegel am Übergabepunkt korrekt weitergeleitet. Die Kollegen vom Außendienst kümmern sich um das Problem. Dies dauert sicher ein paar Tage.
Gruß Fred
am 10.03.2021 11:43
Interessanter Verlauf. Überraschend war die Tage eine Techniker da zum Messen am Hausanschluss. Bestätigte mir mein Stichkabel ist es nicht, das Problem ist in ~20m entfernt.
Heute Bautrupp da und reist Gehweg genau vor dem Haus auf um Abgang in das Haus zu erneuern.
Ich versuche vergeblich mit dem Bautrupp zu kommunizieren, das wenn die Muffe eh raus muss, doch verifiziert werden kann, ob meine Stichleitung fehlerfrei ist. Allerdings finde ich keine gemeinsame Sprache um meinen Punkt an zu bringen.
Naja, Abgang wurde getauscht danach Protokollmessungen am Hausanschluss gemacht. Vodafon-Techniker soll in 2h kommen und verifizieren ob die Aktion erfolgreich war. Je nach Ergebnis sollen noch 2-3 weitere Bauteile im Stang getauscht werden.
Für mich mit meiner eingeschränkten Sicht auf die Dinge ist das nur schwer nachvollziehbar. Problem ist, derzeit finden Bauarbeiten auf meinem Grundstück statt, und es wäre mir wurscht wenn das Kabel ausgebuddelt wird (ist eh alles hinüber). Allerdings ist ein überpflastern und final aufhübschen schon in der Beauftragung. In Zukunft wäre das also viel schwieriger und mit mehr Kosten verbunden. Aber mit mir spricht ja keiner und Vodafon zieht sein Ding durch.
Stand jetzt, volle Geschwindigkeit, allerdings Package drop (Muss aber nicht das alte Problem sein, Vodafon ist ja noch nicht fertig.):
PING 188.192.214.254 (188.192.214.254): 56 data bytes 64 bytes from 188.192.214.254: icmp_seq=0 ttl=64 time=10.001 ms 64 bytes from 188.192.214.254: icmp_seq=1 ttl=64 time=8.721 ms 64 bytes from 188.192.214.254: icmp_seq=2 ttl=64 time=7.972 ms 64 bytes from 188.192.214.254: icmp_seq=4 ttl=64 time=8.282 ms 64 bytes from 188.192.214.254: icmp_seq=5 ttl=64 time=7.391 ms 64 bytes from 188.192.214.254: icmp_seq=6 ttl=64 time=11.926 ms 64 bytes from 188.192.214.254: icmp_seq=7 ttl=64 time=8.082 ms 64 bytes from 188.192.214.254: icmp_seq=8 ttl=64 time=15.131 ms 64 bytes from 188.192.214.254: icmp_seq=9 ttl=64 time=8.620 ms --- 188.192.214.254 ping statistics --- 10 packets transmitted, 9 packets received, 10.0% packet loss round-trip min/avg/max/stddev = 7.391/9.570/15.131/2.344 ms
am 11.03.2021 11:07
Hallo stei-f,
interessanter Verlauf. Wie schaut es dann aktuell aus? Der Auftrag zum Tiefbau wurde nun geschlossen. Hat sich nochmal wer angekündigt?
Gruß Fred
am 12.03.2021 08:41
Es war bis Dato keiner mehr da (weder im Haus, noch das ich den Tiefbau gesehen hätte). Hat sich auch keiner gemeldet.
Es sieht tatsächlich so aus als hätte sich was getan auf der Leitung. Ich muss derzeit länger schauen um Paket drop zu finden (wo ich früher eigentlich fast ständig um die 4% und höher hatte). Bewerten kann man das aber erst über einen längeren Zeitraum.
Ich messe mal einen Arbeitstag mit, denke ich...
am 15.03.2021 10:57
Ich hab jetzt mal 3 Tage mitgemessen. Maximaler Impact: Innerhalb eines 60sek Intervalls gehen 2 Pakete verloren dies hatte ich in ~18 einzelnen Minuten der ca. 3 Tage (210Minuten mit 1 Paket verlustig.).
Ich wundere mich natürlich wie Pakete auf dem kurzen Weg überhaupt verloren gehen können, aber wenn ich hier lese was andere Leute für Probleme haben, ist das jammern auf hohen Nivau, denke ich.
Sprich, um keine weiteren Ressource zu belegen, kann der Vorgang hier geschlossen werden. Ich denke die Tiefbauarbeiten waren erfolgreich.
Danke an das Team.
Fun fact: Ein Techniker hat mir mitgeteilt das die verbauten Bauteile in meinem Strang (die Abgänge in die Stichleitungen) noch aus "Post-Zeiten" sind und (so wie ich es verstanden habe) außerhalb der technischen Spezifikationen betrieben werden. Ich denke Vodafon sollte aufhören, zugunsten geschönter Geschwindigkeitswerte hier ein Risiko ein zu gehen.
(Ich denke aber das hier niemand mitliest der so etwas entscheiden/beeinflussen kann.)
am 15.03.2021 12:24
Hallo @stei-f,
danke für das Feedback 😉 Ich mach dann hier einen Haken an das Thema, wenn noch mal was ist, melde Dich gern im Forum.
LG
Tobias