Frage
Antwort
Lösung
18.12.2023 23:34 - bearbeitet 18.12.2023 23:41
Hallo,
ich dokumentiere hier mal ein Problem, das mich schon länger plagt aber das ich jetzt gerade erstmalig vernünftig nachgestellt bekomme. Diverse Versuche, dieses Thema in den letzten Monaten mit dem VF support zu "erörtern" waren leider ohne Erfolg.
Es gab immer das klassische Feedback/Anfragen: CPE tauschen - WiFi abschalten - FritzBox resetten - VF Station installieren... etc. etc.. alles ohne Erfolg.
Nachfolgend probiere ich nun einmal zu dokumentieren, warum ich glaube das Fehlerbild deutet sehr klar auf ein VF Netzproblem hin, und eben NICHT auf eines der Kabelverbindung oder gar meines internen Netztes oder meiner CPE.
Im Umkehrschluss müsste das bedeuten, diverse Nutzer sehen das Problem, ggf. auch welche deren Setup von meinem abweicht.
Unterschiede im Setup wäre besonders interessant.
Mein Setup
----------------
Kabel-Internet im Hamburger Norden
Vertrag: 250 down, 50 up ("Upload Option 50")
Echte IPv4 als Option ("Öffentliche IPv4 Adresse"), also kein CG NAT / kein DS Lite
CPE: Router ist eine FritzBox 6690
An der FritzBox ist via Gigabit Ethernet (wired) eine Synology angeschlossen.
Zum testen weiterhin via WiFi (2m entfernung) ein Laptop.
Aufder Synology ein "Statping" aufgesetzt, das verschiedene Dienste und IPs alle 10s anspricht (alle Tests via IPv4).
Weiterhin habe ich auf dem Laptop (per WiFi an der Fritzbox) ein ping gegen heise (IPv4 und IPv6) laufen lassen.
Das Fehlerbild
--------------------
Aufgefallen ist schon länger (Monate, wenn nicht Jahre): über den Tag verteilt immer mal wieder Phasen in denen Videokonferenzen (speziell MS Teams) "klemmen", Einzelne Websites nicht oder nur schlecht erreichbar sind (während andere gefühlt ohne Probleme gehen), Streamings abbrechen (Spotify war schlimm, Apple Music ist gefühlt besser), Alexa nicht reagiert (wohl keine Verbindung hat)... etc etc...
Das ganze war in der Vergangenheit quasi gar nicht reproduzierbar oder vorhersehbar, daher war debugging schwierig.
Teilweise waren die Probleme sehr kurz / einmalig, teilweise aber auch längere Phasen (>10s).
Die letzten Tage ist es aber gefühlt deutlich schlechter geworden, weswegen ich jetzt einmal etwas aufwand getrieben haben um ein Test-setup zu erzeugen. Siehe oben (statping syno).
Aktuell sieht statping so aus [1]. Es gibt diverse länger andauernde (>10s) Ausfälle bei IPv4 in den letzten Stunden.
Um ca. 22:00 sieht man sind alle Tests per Statping fehlgeschlagen, da hatte ich versuchsweise einmal die FritzBox neu gestartet. Fehlerbild bleibt aber auch nach Neustart der FritzBox erhalten.
Auch sieht man parallel, dass zwar die IPv4 Verbindungen (bzw. Pakete) regelmäßig Probleme haben, IPv6 aber nicht [2].
Diese einzelnen verlorenen Pakete gibt es sehr regelmäßig. Die längeren Ausfall-phasen hingegen sehr unregelmäßig.
Gleichzeitig ist die Kabelverbindung selbst immer dauerhaft aktiv - laut Statistik FritzBox. Konkret also auch in den verschiedenen Fehlerfällen, es gibt keinen neuen Aufbau der Kabel-Internet (DOCSIS) Verbindung!
Schlussfolgerung
-------------------------
Da das Problem nur bei IPv4 auf zu treten scheint, dort aber schon ab dem ersten Hop Vodafone (also der erste Router hinter meinem CPE / der FritzBox), ist das Problem mit ziemlicher Sicherheit
- keines der Kabelverbindung selbst
- keines von einzelnen clients
- speziell definitiv keines des internen WiFi netzes
Man darf wohl auch weitehrhin vermuten, dass es
- nichts mit der FritzBox zu tun hat (wobei das definitiv noch genauer untersucht werden muss)
- die einzelnen Packet-loss und die längeren Ausfallphasen ausdruck des gleichen Problems sind
Ich würde behaupten:
- VF hat ein allgemeines Problem in seinem IPv4 Netz!
Ich sehe hier im Forum diverse Fehlermeldungen die auf dieses Problem zurück zu führen sein könnten.
Anhänge
-------------
[1] Screnshot statping 23:00 am 18.12.2023 - läuft seit 1/2 Tag - Restart des Internet Routers/CPE (FritzBox 6690) um ca. 22:00
[2] Screenshot Ping (lief einige Minuten bis ca. 23:15, 18.12.2023) auf meinem Laptop (per WiFi)
Ausgeführt wurde: "ping -4 -t heise.de" und "ping -6 -t heise.de"
Massiv Packetloss bei IPv4 aber kein Packetloss bei IPv6
Gelöst! Gehe zu Lösung.
am 26.09.2024 16:56
Ich denke das Thema werden wir hier nicht gelöst bekommen.
Insofern kann man den Thread schließen - ich markiere diese mail hier mal als "Lösung".
am 18.12.2023 23:41
P.S.: Tobi hatte ich auch schon gefragt 😉
am 19.12.2023 01:02
Update 19.12.2023, 1:00Uhr
Der/Die Fehler scheint nicht mehr auf zu treten, ist seit gut einer Stunde nicht mehr reproduzierbar.
am 19.12.2023 20:33
Update 19.12.2023, 20:30Uhr
Heute scheinbar insg. so gut wie gar nicht reproduzierbar.
am 03.01.2024 11:37
Update 3.1.2024:
Nachdem die letzten Tage wenig Zeit zum debuggen war, ist es heute aber wieder so schlimm, dass ich ein Follow-up mache. Mein aufgesetztes Monitoring zeigt in den letzten 24h über 1000 (!) Einzelfehler.
Aktuell habe ich ca. 10 sensoren nach extern, die alle 10s abfragen (ping und DNS).
Nach zwei erfolglosen Anfragen erzeut erst die dritte gescheiterte Anfrage eine Benachrichtigung.
Ich habe in den letzten 24 Stunden 33 Benachrichtigungen über service-ausfälle bekommen.
Überblick über die Fehler in den letzten 24h, Stand 11:20 am 3.1.2023 [1]
Darin sieht man schön, das immer alles gleichzeitig "ausfällt" bzw. nicht erreichbar ist.
=> bedeutet also, es geht kein Traffic durch die Leitung.
Was irritiert ist, dass in so einem Fehlerfall auch die "externe" IP der Fritz nicht erreichbar ist, siehe [1]. Eigentlich würde ich das nicht erwarten und probiere einmal mit AVM zu klären was das bedeutet. Denn: was ich anders herum auch sehe, die DOCSIS Verbindung selbst scheint weiter "zu stehen". Also die Physik geht nicht down, ... aber es gehen keine Daten durch. Die FritzBox meldet bei mir "verbunden seit.." mehreren Tage.
Nächste Schritte.
Um ein FritzBox Problem weiter aus zu schließen: ich schalte die WiFi Calling priorisierung sowie DOCSIS und Paketprozessor Stromsparen in der FritzBox testweise aus [2]. Und habe um 11:11 einmal die Docsis verbindung manuell neu syncronisiert.
In der konsequenz sehen dann jetzt ich auch in der Fritzbox "verbunden seit 03.01.2024, 11:11 Uhr".
Sollte es weiterhin zu häufigen Fehlern kommen heute, würde ich die FritzBox einmal neu starten.
[1]
[2]
am 03.01.2024 16:19
Hey @poeggi,
wir schauen uns Dein Anliegen gern genauer an. Da wir dafür einen Blick in Dein Kundenkonto benötigen, meld Dich bitte über einen dieser Kontaktwege bei uns. Zusammen führen wir eine Fehleranalyse durch und nehmen ggf. ein entsprechendes Ticket für Dich auf. Gemeinsam bringen wir Deinen Anschluss in Schwung.
Viele Grüße
R4mona
am 14.01.2024 08:20
Ergänzende Dokumentation:
Nachdem ich am 03.01 die FB neu gestartet hatte (deaktivierte VoWiFi Prio + deaktivierte Energiesparmodi), sind über eine Woche keine gehäuften Fehler mehr aufgetreten.
Daraufhin hatte ich am 10.01 das VoWiFi wieder aktiviert (nicht aber die Energiesparmodi) und die FB nochmal neu gestartetmit - bis zum 12.01 weiterhin keine gehäuften Fehler.
Am 12.01 dann auch die Energiesparmodi aktiviert (FB aber _nicht_ neu gestartet). Seite gestern (13.01.) Abends dann wieder gehäufte Fehler.
Das ist nun noch kein Beweis, dass es mit der Einstellung zu tun hat, aber schon ein Indiz.
Wichtige Randnotiz, ich habe einen Zusätzlichen Test gemacht um das Phänomen, dass ich die externe IP der FritzBox selbst im Fehlerfall nicht erreiche zu verstehe. Dafür habe ich die externe IP der FB in einem zweiten Test hardcoded, und löse sie nicht per DNS auf. Dieser zweite Test schägt nie Fehl. Bedeutet - die externe IP der FritzBox ist immer erreichbar - der Fehler den ich im Monitoring gesehen hatte kan daher, dass ich generell keine IP adressen auflösen konnte -> internetverbindung nach erstem HOP gestört.
Wie das nun alles zusammenhängt oder ob das nur Zufall ist, aktuell noch etwas unklar.
Man könnte mutmaßen, dass in der Kopfstelle (CMTS) mit aktiviertem Energiesparmodus Fehler entstehen ...
Ich teste weiter. Als erstes habe ich heute 8:00 die DOCSIS verbindung neu syncronisiert. Schaue mal ob die Fehler weiterhin auftreten. Wenn ja - wird die FB neu gestartet. Wenn weiterhin Fehler, deaktiviere ich zuerst nur den Upstream Energiesparmodus (weil der vermeinlich am ehesten Einfluss auf die CMTS hat.
am 14.01.2024 10:48
poste alle Kanäle!
am 23.05.2024 22:03
Hallo Zurück in die Runde.
Ich hatte das Thema etwas aus den Augen verloren, weil die Fehlerrate auf jeden Fall runter gegangen und das ganze Thema deswegen weniger störend war. Ist aktuell auch selten, dass es zu Probelmen kommt und entsprechend schwierig zu testen bzw. nicht reproduzierbar.
Anyway - hier mal die aktuellen Werte. Mich würde sehr interessieren, ob daraus jemand was lesen kann:
(Log gezogen ca. 2.5h nachdem ich die DOCSIS verbindung neu initialisiert habe, um eine saubere baseline zu haben):
DOCSIS
--------------
showdocsisstate:status/
dump=
DEVICE
Modem firmware version: 7.3.1.0.65
Signal on cable: Detected
Number of Tuners: 1
Operational mode: DOCSIS 3.1
Frequency plan: Hybrid
Modem status: Operational
CM initialization stage: Operational
MAC init reason: Power On
Channel change status: No active channel change
eRouter enabled: YES
eRouter mode: IPv4+IPv6
Power save mode active: NO
DOCSIS 1.0 CoS Flag: NO
DOCSIS 2.0 mode enabled: YES
Frequency cache: 264000000,570000000,650000000,666000000,586000000,0
User scan frequency: Not set
Sync Time: 8617 s
Last locked frequency: 570 MHz
MDF support: Promiscuous
Max CPE: 10
Tx channel config: YES
Resets: 4
Invalid reg responses: 0
T1 timeouts: 0
CMTS MAC Address: dc:a2:45:05:00:00
CMTS Vendor: er
Modem MAC Address: 3c:37:12:9f:4e:a0
UPSTREAM
Service ID (SID): 228
Reg request SID: 228
Override SID: 0
PGA gain code: 55
PGA current: 0
Curr. PGA full scale: 0.000000
PLoadMinSet: 7.000000
Initial PLoadMinSet: -1.000000
Multiple upstreams: YES
Drop classifiers: YES
Frequency band: 5-85 MHz
Single-Carrier Channels: 8 (4 currently active)
ID | Active | Frequency | SymRate | ChWidth | Attenuation | Power | Power16 | P-High | P-Low | P-DRW-High | P-DRW-Low | DeltaPF | Mod | Mux
| | [MHz] | [MHz] | [kHz] | [dB] | [dBmV] | [dBmV] | [dBmV] | [dBmV] | [dBmV] | [dBmV] | [dB] | |
----+--------+-----------+---------+---------+-------------+--------+---------+----------+----------+------------+-----------+---------+---------+------
11 | YES | 37.201 | 5.120 | 6400 | 14.547 | 46.021 | 40.000 | 49.000 | 17.000 | 42.000 | 30.000 | 0.000 | 64QAM | ATDMA
12 | YES | 30.801 | 5.120 | 6400 | 14.547 | 46.021 | 40.000 | 49.000 | 17.000 | 42.000 | 30.000 | 0.000 | 16QAM | ATDMA
9 | YES | 51.001 | 5.120 | 6400 | 13.219 | 46.771 | 40.750 | 49.000 | 17.000 | 42.000 | 30.000 | 0.000 | 64QAM | ATDMA
10 | YES | 44.600 | 5.120 | 6400 | 13.930 | 46.271 | 40.250 | 49.000 | 17.000 | 42.000 | 30.000 | 0.000 | 64QAM | ATDMA
0 | NO | 9.961 | 0.000 | 0 | 0.000 | 0.000 | 0.000 | 0.000 | 0.000 | 0.000 | 0.000 | 0.000 | er | ATDMA
0 | NO | 9.961 | 0.000 | 0 | 0.000 | 0.000 | 0.000 | 0.000 | 0.000 | 0.000 | 0.000 | 0.000 | er | ATDMA
0 | NO | 9.961 | 0.000 | 0 | 0.000 | 0.000 | 0.000 | 0.000 | 0.000 | 0.000 | 0.000 | 0.000 | er | ATDMA
0 | NO | 9.961 | 0.000 | 0 | 0.000 | 0.000 | 0.000 | 0.000 | 0.000 | 0.000 | 0.000 | 0.000 | er | ATDMA
Multi-Carrier (OFDMA) Channels: 2 (1 currently active)
ID | Active | Frequency | Active Subcarriers | Max Mod | Gain | Power | FFT Size
| | [MHz] | | | [dB] | [dBmV] |
----+--------+---------------------+--------------------+---------+--------+--------+-----------
43 | YES | 29.775 - 64.775 | 640 | 64QAM | 0.209 | 41.750 | 2K
0 | NO | 0.000 - 0.000 | 0 | 0 | 0.000 | 0.000 | None
DOWNSTREAM
Frequency band: 108-1218 MHz
Latency: 0.320000 ms
MSE History: -38.441,-38.373,-38.386,-38.442,-38.533,-38.416,-38.351,-38.279,-37.764,0.000,0.000,0.000,0.000,0.000,0.000,0.000,0.000,0.000,0.000,0.000,0.000,0.000,0.000,0.000, Multiple downstreams: YES
Single-Carrier Receivers: 32 (32 currently active)
ID | Active | Frequency | Primary | Power | MSE | CorrWords | UncorrWords | QAMLock | FECLock | MPEGLock | Mod | Annex
| | [MHz] | Capable | [dBmV] | [dB] | | | | | | |
----+--------+-----------+---------+--------+---------+-----------+-------------+---------+---------+----------+---------+-------
3 | YES | 570.000 | ACTIVE | 2.90 | -40.366 | 163 | 0 | YES | YES | YES | 256QAM | A
4 | YES | 578.000 | YES | 2.70 | -40.366 | 181 | 0 | YES | YES | YES | 256QAM | A
5 | YES | 586.000 | YES | 2.20 | -40.946 | 160 | 0 | YES | YES | YES | 256QAM | A
6 | YES | 594.000 | YES | 1.80 | -40.366 | 188 | 0 | YES | YES | YES | 256QAM | A
7 | YES | 602.000 | YES | 2.00 | -40.366 | 138 | 0 | YES | YES | YES | 256QAM | A
8 | YES | 618.000 | YES | 2.20 | -40.366 | 108 | 0 | YES | YES | YES | 256QAM | A
9 | YES | 626.000 | YES | 2.70 | -40.366 | 90 | 0 | YES | YES | YES | 256QAM | A
10 | YES | 634.000 | YES | 2.10 | -40.366 | 86 | 0 | YES | YES | YES | 256QAM | A
11 | YES | 642.000 | YES | 2.70 | -40.946 | 69 | 0 | YES | YES | YES | 256QAM | A
12 | YES | 650.000 | YES | 2.90 | -40.366 | 53 | 0 | YES | YES | YES | 256QAM | A
13 | YES | 658.000 | YES | 2.50 | -40.366 | 25 | 0 | YES | YES | YES | 256QAM | A
14 | YES | 666.000 | YES | 3.20 | -40.366 | 18 | 0 | YES | YES | YES | 256QAM | A
15 | YES | 674.000 | YES | 3.20 | -40.366 | 20 | 14 | YES | YES | YES | 256QAM | A
16 | YES | 682.000 | YES | 2.70 | -40.366 | 5 | 0 | YES | YES | YES | 256QAM | A
17 | YES | 690.000 | YES | 2.90 | -40.946 | 5 | 0 | YES | YES | YES | 256QAM | A
1 | YES | 114.000 | NO | 7.50 | -40.946 | 216 | 0 | YES | YES | YES | 256QAM | A
2 | YES | 130.000 | NO | 7.00 | -40.946 | 168 | 0 | YES | YES | YES | 256QAM | A
65 | YES | 698.000 | NO | -3.80 | -36.335 | 10 | 0 | YES | YES | YES | 64QAM | A
66 | YES | 706.000 | NO | -4.00 | -36.335 | 90 | 0 | YES | YES | YES | 64QAM | A
67 | YES | 714.000 | NO | -3.50 | -36.558 | 3 | 0 | YES | YES | YES | 64QAM | A
68 | YES | 722.000 | NO | -4.80 | -35.729 | 1 | 0 | YES | YES | YES | 64QAM | A
69 | YES | 730.000 | NO | -3.80 | -36.335 | 15 | 0 | YES | YES | YES | 64QAM | A
70 | YES | 738.000 | NO | -3.60 | -36.335 | 2 | 0 | YES | YES | YES | 64QAM | A
71 | YES | 746.000 | NO | -5.00 | -36.558 | 1 | 0 | YES | YES | YES | 64QAM | A
72 | YES | 754.000 | NO | -4.00 | -36.335 | 4 | 0 | YES | YES | YES | 64QAM | A
73 | YES | 762.000 | NO | -4.60 | -36.335 | 0 | 0 | YES | YES | YES | 64QAM | A
74 | YES | 770.000 | NO | -5.60 | -35.729 | 0 | 0 | YES | YES | YES | 64QAM | A
75 | YES | 778.000 | NO | -5.40 | -36.558 | 0 | 0 | YES | YES | YES | 64QAM | A
76 | YES | 786.000 | NO | -6.60 | -35.544 | 2 | 0 | YES | YES | YES | 64QAM | A
77 | YES | 794.000 | NO | -7.20 | -35.032 | 2 | 0 | YES | YES | YES | 64QAM | A
78 | YES | 802.000 | NO | -6.40 | -35.729 | 4 | 0 | YES | YES | YES | 64QAM | A
79 | YES | 810.000 | NO | -6.30 | -35.729 | 0 | 0 | YES | YES | YES | 64QAM | A
Multi-Carrier (OFDM) Receivers: 2 (1 currently active)
ID | Active | Frequency | Primary | PLC Freq | Power | MER | CorrWords | UncorrWords | Max Mod | Rolloff Period | Cyclic Prefix | FFT Size
| | [MHz] | Capable | [MHz] | [dBmV] | [dB] | | | | | |
----+--------+---------------------+---------+----------+--------+------+-------------+-------------+---------+-----------------+-----------------+----------
0 | NO | 0.000 - 0.000 | NO | 0.000 | 0.00 | 0 | 0 | 0 | None | None | None | None
| EXCL | 0.000 - 0.000 |
193 | YES | 134.975 - 324.975 | YES | 264.000 | 4.20 | 43 | 166347530 | 36 | 4096QAM | 256 (1.25 us) | 512 (2.5 us) | 4K
DVBC enabled: NO
Was ich seltsam finde, ohne zu wissen ob es relevant ist:
- CorrWords auf dem Downstream DOCSIS 3.1 gehen extrem schnell hoch (fast 1mio / Minute?!)
- Ein Upstream DOCSIS 3.0 Kanal nur 16QAM
am 24.05.2024 07:58
Update:
Der Upstream Kanal (#12, 31MHz) der im Post der Test-Supportdaten auf 16QAM stand wechselt häufiger zwischen 16 und 64QAM.
Auch andere Upstream Kanäle wechseln hin und her (wenn auch nicht so häufig).
Der DOCSIS3.1 Upstream wechselt zwischen 32QAM, 64QAM und 128QAM.
Ansonsten, der einfachen Übersicht halber (und weil der Text teilweise schwer zu lesen ist) hier nochmal die Kanäle als grafisches Spektrum: