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 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 24.02.2021 09:56
zu den Signalwerten. Ich hab jetzt einen Client in das Netzsegment zwischen Router und Fast5460 geklemmt. Im tcpdump sehe ich auch schön die ARP-Anfrage vom Router und Internet durchfliegen. Aber ich kann unter der 192.168.100.1 niemanden erreichen.
Laut den Informationen hier im Forum sollte die Fast5460 im BridgeModus auf diese IP reagieren. Oder hat sich das mit einer neueren Firmware inzwischen geändert?
am 24.02.2021 12:49
Hallo stei-f,
gerne kann ich mir die Leitung mal anschauen. Schick mir dazu bitte eine PN mit Deinen Kundendaten (Name, Adresse, Kundennummer und Geburtsdatum).
Melde Dich dann bitte nochmal hier, wenn Du mir die Daten geschickt hast.
Liebe Grüße
Moni
am 24.02.2021 13:49
Hallo,
PN ist raus.
Gruß Frank
26.02.2021 10:05 - bearbeitet 26.02.2021 10:23
In der Zwischenzeit hatte ich schon wieder 4 Totalausfälle. Der letzte 15min lang 2021-02-26 ~9:15 bis 9:33. Alles tot. Telefon, Internet, Modem blinkt mit @,
Hier mal die Totalausfälle der letzten 30 Tage:
am 26.02.2021 10:15
Und weil ich es eh gerade offen hatte, hier mal Fälle pro Monat mit einem package loss von >10%:
2020-04 16
2020-05 24
2020-06 14
2020-07 30
2020-08 12
2020-09 68
2020-10 49
2020-11 56
2020-12 3
2021-01 7
2021-02 41
Die zahlen sind natürlich nicht ganz representativ, denn ein log wir immer nur geschrieben wenn ein Schwellwert überschritten oder unterschritten wird (20% oder 50%). Und der Wert ist ein Durchschnitt über 60 Sekunden.
(Wie immer, ping router -> gateway)
am 26.02.2021 10:18
Erschwerend kommt hinzu das der Fast5460 im Bridge Mode mir manchmal nachdem der gebootet hat (nach einem Ausfall) eine 168.192.0.X Adresse zuweist. Das bringt meinem Internetanschluss natürlich auch nicht zurück. Sprich ich muss händisch eingreifen damit alles wieder läuft.
am 26.02.2021 10:27
Hey,
an Deinem Anschluss gibt´s auf den Downstreams massiv Pegelschwankungen, Frequenzwechsel und Timeouts. Bist Du mit einem Technikereinsatz einverstanden und kannst Du für den Zugang zur Hausanlage sorgen? Unter welcher Rufnummer bist Du am Besten für die Terminvereinbarung erreichbar?
Zu COVID-19: befindest Du dich in Quarantäne oder gibt´s es in Deinem Haushalt Symptome die auf COVID-19 hinweisen?
VG Wallace
am 26.02.2021 11:12
Hallo,
PN mit den Daten ist raus. Techniker Termin und Zugang ist kein Problem.
Gruß Frank
am 02.03.2021 08:10
Hallo stei-f,
ich habe den Auftrag zur Terminierung an das Technikerunternehmen gegeben, Du wirst von dort angerufen.
Viele Grüße,
Claudia