Nächtliche Reconnects (reloaded !!!) mit FB 6490

[SIGSEGV2]

Hallo,

@Claudia Vielleicht hätte ich den alten Beitrag noch nicht schließen sollen

nachdem das Problem aus diesem Beitrag durch einen Austausch der FB 6490 behoben war... und der Beitrag nach 2 Wochen Beobachtung am 20.06.2019 geschlossen wurde, tritt dasselbe Problem seit dem 21.06.2019 wieder auf

Bisher gab es seit dem 21.06. pro Nacht zwar nur 1-2 Reconnects, aber der Zeitraum ist wieder exakt derselbe (nachts zwischen 2:00 und 4:00 Uhr).

Anschluss ist derselbe wie im Beitrag oben, Vertrag Internet&Phone 500, Homebox 6490 (Leihgerät), bisher keine Störung über die Hotline gemeldet (das hatte im alten Beitrag auch nur zu mehreren erfolglosen Technikerterminen geführt).

Ich habe am Anschluss selbst seit dem 27.04.2019 nichts mehr verändert.

Am 30.05. und 31.05. gab es auch jeweils so einen Reconnect, was ich aber zunächst ignoriert habe, weil an diesem Tagen auch auf meinem anderen Anschluss Probleme aufgetreten sind.

Mit Ausnahme dieser 2 Tage (bzw. Nächte) lief die Box zwischen 13.04.2019 und 20.06.2019 stabil ohne Reconnects. Seit 21.06.2019 treten sie jetzt wieder regelmäßig auf... mindestens einer, manchmal zwei.

Änderungen an Konfiguration der FB 6490 gab es am 20.06.2019 kleinere Änderungen, allerdings kann ich mir nicht vorstellen, dass die so ein Problem auslösen:

1. Änderung des WLAN-Kanals für 5 GHz von Kanal 100 auf 36

2. Anmeldung zwei neuer WLAN-Geräte

Laut den Support-Daten der FB 6490 decken sich die Zeitpunkte der Reconnects wieder (!!!) exakt mit Änderungen, die über das TR069-Fernwartungsprotokoll in die Box eingebracht wurden.

Mehr Details aus den Logs kann ich bei Bedarf noch anhängen.

Ein wesentlicher erkennbarer Unterschied ist, dass in den Logs jetzt eine geänderte DOCSIS-Config im Downstream zu sehen ist.

Diese hatte sich seit dem 08.04.2019 (Inbetriebnahme der ausgetauschten FB 6490) bisher nicht geändert:

- alte Config: Laut Logs verwendet die Box 21 Downstream-Kanäle (im GUI werden nur 20 davon angezeigt)

- neue Config: Laut Logs verwendet die Box 24 Downstream-Kanäle (im GUI werden nur 20 davon angezeigt)

Jeweils ausgeblendet ist der Kanal auf 610 MHz, der von den Werten her gleich aussieht, aber bzgl. MSE-Wert der

schlechteste der 21 Kanäle ist (ca. 35-36 dB, während alle anderen 39-41 dB haben). Hier die relevanten Schnipsel aus den Logs zu den mittleren 8 von 24 Kanälen:

vom 27.04.2019 ohne Reconnect-Problem:

Receiver # : 9 10 11 12 13 14 15 16
Frequency(MHz) : 610.000 0.000 0.000 0.000 194.000 202.000 210.000 218.000
QAM Lock : YES NO NO NO YES YES YES YES
FEC Lock : YES NO NO NO YES YES YES YES
MPEG Lock : YES NO NO NO YES YES YES YES
CH Enabled : YES NO NO NO YES YES YES YES
MSE : -35.729 -inf -inf -inf -40.946 -40.366 -40.366 -40.366

von heute (seit 21.06. ähnlich) mit dem Problem:

Receiver # : 9 10 11 12 13 14 15 16
Frequency(MHz) : 610.000 0.000 0.000 0.000 194.000 202.000 210.000 218.000
QAM Lock : YES NO NO NO YES YES YES YES
FEC Lock : YES NO NO NO YES YES YES YES
MPEG Lock : YES NO NO NO YES YES YES YES
CH Enabled : YES YES YES YES YES YES YES YES
MSE : -35.729 -15.522 -15.530 -19.750 -40.946 -40.366 -40.366 -40.366

Teilweise ist bei einem der drei Kanäle 10-12 auch noch der QAM Lock auf YES, aber nicht immer. Das scheint aber keinen Unterschied zu machen.

Da ich selbst auf die DOCSIS-Config keinen Einfluss habe und sie sich ausgerechnet zu der Zeit geändert hat, seit der das Problem wieder auftritt, kann der Fehler/Auslöser aus meiner Sicht nur auf VF-Seite liegen.

Könnt ihr bitte

1. mal den Anschluss prüfen?

2. bei den Backoffice-Kollegen nachfragen, ob bzgl. TR069 zwischen 20.06. und 21.06.2019 was geändert wurde?

http://axs.technik.kabel-deutschland.de:7547/live/CPEManager/CPEs/genericTR69/c80e14xxxxxx ?

Danke & Grüße,

 SIGSEGV2

[Tobias]

Hey,

ich geb den Auftrag noch mal an unseren Thirdlevel weiter, dann prüfen die mal ob sie was erkennen können 😉

LG

Tobias

[SIGSEGV2]

Hi Tobias,

das Ticket wurde heute geschlossen.

Konnten die Kollegen was finden bzw. wurde auf eurer Seite was angepasst?

Seit dem ersten (Wieder-)Auftreten am 21.06. gab es jetzt wieder täglich/nächtlich diese Reconnects, allerdings meistens nur einen, maximal waren es 3, also deutlich weniger als vorher bis zum Tausch der Box Anfang April.

Das Zeitfenster war aber wieder immer dasselbe (zwischen 2:45 und 3:45 Uhr) bis auf eine Ausnahme. Gestern gab es einen Reconnect um 13:44, nach dem um 13:41 der Sync verloren ging (MDD timeout). Evtl. war das durch die Kollegen ausgelöst?

Der bisher letzte Reconnect war heute um 3:05:27 Uhr... ob das Problem tatsächlich behoben ist, kann ich erst morgen sagen.

Die Vermutung mit TR069 aus meinem früheren Post trifft wohl eher nicht zu. Diese TR069-Logeinträge sind eher die Folge des Reconnects, nicht die Ursache, da sie zeitlich später auftreten.

Auslöser der nächtlichen Reconnects sind laut den Logs gehäuft auftretende T3-Timeouts, teilweise auch T4-Timeouts. Warum diese Timeouts damals wie jetzt täglich in diesem Zeitfenster auftreten, in den restlichen 23 Stunden aber nicht, ist weiter seltsam. Bei Bedarf kann ich die einzelnen Logausschnitte seit dem 21.06. mal zu einem großen zusammen bauen.

Unklar ist weiterhin auch, warum nach dem Austausch ursprünglich nur 20 Downstream-Kanäle "enabled" waren und jetzt 24, von denen bei 3 keine Frequenz angezeigt wird und die MSE zu schlecht ist.

Die DOCSIS-config selbst kommt aber nicht über TR069, sondern wird beim Ranging/Maintenance ausgehandelt, insofern muss sich da zwischen Austausch der Box im April und dem 21.06. irgendwas auf CMTS-Seite geändert haben.

Der im GUI nicht sichtbare Kanal bei 610 MHz ist eigentlich ein DVB-C-Kanal mit 64QAM, auf dem aber auch ein Pilotträger mitgesendet wird. Den seh ich aber auch an anderen Anschlüssen, der ist also kein Problem.

Falls über Nacht wieder Reconnects auftreten sollten, meld ich mich morgen nochmal dazu.

Viele Grüße,

SIGSEGV2

[Tobias]

Hey,

ich hab mal geschaut. Die Kollegen gehen fast davon aus, dass das CMTS-Seitig ist, da hier die Loadbalancer quasi ihre Arbeit verrichten (die sind dafür da, die Last zwischen den Downstreams zu "verschieben", bzw zu balancieren. Da kann es sein, dass manches Modem die Verbindung verliert. Könnte also wirklich passen, evtl. gibts ja wirklich mehr Traffic seit dem Datum welches dann mehr hin und her geschoben werden muss.. 😕 Ich fürchte fast, ich kann Dir dahingehend keine wirkliche Hilfe anbieten.

LG

Tobias

[SIGSEGV2]

Hi Tobias,

hast du mal (auf der Landkarte) geschaut, wo der Anschluss liegt?

Da werden abends die Gehsteige hochgeklappt... 😉

Sorry... bin "leider" Dipl.-Inf. mit Nebenfach Nachrichtentechnik... "Loadbalancing" würde greifen, wenn es eine echte ÜBERlast gibt... aber die gibt es "da in der Pampa" ja nicht mal zur "Prime Time" abends...

...wieso sollte dann AUSGERECHNET zwischen 2:45-3:45 Uhr so so eine Überlast auftreten???

==> Da glaub ich NEVER EVER dran...

Völlig unklar ist ja auch weiterhin, warum der Austausch der FB 6490 im April das Problem "für über 9 Wochen" behoben hat, nachdem es seit 12/2018 aufgetreten ist... damals hab ich einen Zusammenhang zur Analogabschaltung/Frequenzumbelegung vermutet... da das Problem jetzt seit 21.06. wieder neu auftritt, war das aber wohl nicht die Ursache.

"ultima ratio" war im April dann "FRITZBox tauschen"... seitdem 9 Wochen lang KEINE Problem mehr...

... (auch wenn ich's NIE verstanden hab) hat es damals geholfen

Von mir aus können wir die Box auch NOCHMAL tauschen... "trial&error"... andere Optionen seht ihr bei euch ja anscheinend nicht, richtig?

VG,

SIGSEGV2

[Tobias]

Hey,

naja, ich kann auch nur mit den Antworten der Kollegen arbeiten, und, es hat nichts damit zu tun ob bei Dir im Dorf nix los ist, Du hängst an nem größeren Netz dran, und die Loadbalancer arbeiten auch wenn es kaum Auslastung gibt. Die Switchen ja u.a. auch die Modems einfach auf andere Frequenzen wenn irgendwas ist. Was die Tauschgeschichte damit zu tun hat, gute Frage - im Endeffekt ist es fraglich ob es wirklich der Loadbalancer ist / also die CMTS, oder was anderes. Im Endeffekt wurde das durch den 3rdlvl geprüft, weiter eskalieren kann ich es nicht.

Und ja, Du hast prinzipiell recht, einen LB anzustoßen obwohl keine Last da ist macht keinen Sinn.. , wenn Du willst können wir gern noch einen Tausch probieren, ob das was bringt kann ich Dir nicht sagen - wenns ne Netzseitige Sache ist siehts mit nem Tausch schlecht aus 😞

LG

Tobias

[SIGSEGV2]

Hi Tobias,

ich hatte zu dem Problem bisher ja noch nichts weiter ausprobiert, weil das beim ersten Auftreten von 12/2018-04/2019 auch alles nichts geholfen hat.

Was ich theoretisch mal machen könnte:

1. PowerOn-Reset... und schauen, ob sich über Nacht was ändert

2. Reset auf Werkseinstellungen... und schauen, ob sich über Nacht was ändert

3. andere Austausch-Box testen, falls eure internen Prozesse das hergeben

Ich hab aus einem Problem mit meinem anderen Anschluss ja heute eine Tausch-Box erhalten. An diesem Anschluss gab es zwar über Nacht noch mehrfach Ausfälle, aber seit ca. 6:50 Uhr bisher nicht mehr.

Die Frage ist, ob ich dort die Box überhaupt noch tauschen muss... damit würde ich erst mal mindestens bis zum Wochenende abwarten, ob die Probleme wieder auftreten.

Wäre es rein theoretisch möglich, diese Box für den hier betroffenen Anschluss "umzuprovisionieren", wenn ich dir die andere Ticketnummer und die CM-MAC der Austausch-Box schicke? Oder kann sowas intern nicht "umgebucht" werden... also für den Fall hier müsste zwingend eine andere Austausch-Box verschickt werden?

Grüße,

SIGSEGV2

[SIGSEGV2]

Hi Tobias,

kleines Update... der PowerOn-Reset wurde DOCH schon ausprobiert, das war mir nur bisher nicht bewusst.

Der Reconnect am 01.07. um 13:44, der nicht "ins übliche Zeitraster" gepasst hat, war (wie mir heute so nebenbei mitgeteilt wurde) ein ausgelöster FI, der mal kurz im ganzen Haus den Strom abgeschaltet hatte.

Seitdem hatte sich aber ja nichts geändert... auch am 02-04.07. gab es wieder die nächtlichen Reconnects.

Bleiben also nur noch die Alternativen 2. (Werksreset) oder 3. (Austausch)...

Den Werksreset könnte ich am Wochenende mal testen, erhoffe mir aber nicht viel davon.

Bzgl. Austausch siehe Frage weiter oben... ich hab ja eine Austausch-Box hier, aber "anders" provisioniert für meinen anderen Anschluss (der immer noch keine Probleme mehr hat).

Viele Grüße,

SIGSEGV2

[Tobias]

Hey,

theoretisch könnte ich hin und her Provisionieren, macht aber keinen Sinn denke ich, machen wir mal wie Du geschrieben hast -> WR und dann Tausch, wenns nicht hilft ... , muss ichs wohl wieder weiter geben und die Kollegen müssen sich Gedanken machen wie man es lösen kann. 😕

LG

Tobias

[SIGSEGV2]

Hi Tobias,

haben die Kollegen doch noch was gefunden... oder ist da einfach nur *MAGIC* passiert?

Der letzte Reconnect war am 09.07.2019 um 3:16 Uhr... seitdem läuft der Anschluss wieder stabil (keine Reconnects, noch nicht mal vereinzelte/sporadische T3-Timeouts sind aktuell im Log zu sehen).

Ich hatte bisher noch nichts weiter verändert oder ausprobiert, also auch noch keinen Werksreset.

Hier der Auszug aus dem Log von heute mit den letzten Reconnects von 06.-09.07., außer dem DHCP warning am 11.07. bisher nichts mehr:

##### BEGIN SECTION cmlog Cablemodem eventlog

DOCSIS CM Eventlog:
16: 2019-07-06 03:26:23 82000200 critical No Ranging Response received - T3 time-out
17: 2019-07-07 03:09:24 68000301 critical DHCP FAILED - Critical field invalid in response
18: 2019-07-07 03:09:24 68010700 error Primary lease failed, IPv4 fallback initiated
19: 2019-07-07 03:09:26 90000000 warning MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1
20: 2019-07-07 03:09:27 82000200 critical No Ranging Response received - T3 time-out
- 1970-01-01 01:01:19 2 times
21: 1970-01-01 01:01:28 68000301 critical DHCP FAILED - Critical field invalid in response
22: 1970-01-01 01:01:29 68010700 error Primary lease failed, IPv4 fallback initiated
23: 2019-07-07 16:16:32 90000000 warning MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1
24: 2019-07-07 16:16:33 82000200 critical No Ranging Response received - T3 time-out
25: 2019-07-08 03:15:59 82000400 critical Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out
26: 2019-07-08 03:16:08 82000200 critical No Ranging Response received - T3 time-out
27: 2019-07-08 03:16:13 68000301 critical DHCP FAILED - Critical field invalid in response
28: 2019-07-08 03:16:14 68010700 error Primary lease failed, IPv4 fallback initiated
29: 2019-07-08 03:16:16 90000000 warning MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1
30: 2019-07-09 03:15:46 82000400 critical Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out
31: 2019-07-09 03:16:02 68000301 critical DHCP FAILED - Critical field invalid in response
32: 2019-07-09 03:16:02 68010700 error Primary lease failed, IPv4 fallback initiated
33: 2019-07-09 03:16:06 90000000 warning MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1
34: 2019-07-09 03:16:07 82000200 critical No Ranging Response received - T3 time-out
35: 2019-07-11 03:21:13 68010300 error DHCP RENEW WARNING - Field invalid in response v4 option
##### END SECTION cmlog

Am 07.07.2019 hatte ich nachmittags selbst einen Reboot ausgelöst, um die VPN-Verbindung mit der neuen Gegenstelle (an meinem anderen Anschluss wurde ja die Box getauscht) wiederherzustellen, ansonsten ist alles wie vorher.

Danach gab es noch 2 Reconnects am 08. und 09.07., seitdem bisher keine Probleme mehr

Ich hoff mal, dass das jetzt wieder dauerhaft so bleibt... aber bitte den Thread hier erst mal noch nicht schließen.

Grüße,

SIGSEGV2