T3 timeouts op OFDMA

[Marinus]

Ik had gisteren ineens even (seconden a minuut) geen connectie met het internet.

Dit kwam overeen met een critical in de netwerk historie. Er is ook al een eerdere critical geweest die niet door mij is opgemerkt. Tezamen leidt dit tot T3 errors in het upstream overzicht.

Vragen aan het die hier meer van weten dan ik:

- is dit "normaal"?

- wat kan hiervan de oorzaak zijn? 

- hoe los ik / lost Ziggo dit op?

Hieronder het netwerklog en de upstream waarden.

 

 

[Marinus]

@Vincent @tobiastheebe @MR_CHIP @Kermit 

En weer T3 errors op het OFDMA kanaal.

Nu echter lag na deze errors de hele verbinding van het modem het Ziggo netwerk op plat.

Dit heb ik nog niet eerder gezien en is eigenlijk onacceptabel.

Na een herstart van de Sagemcom werkt alles weer.

Toch een half uur zonder internet gezeten.

De screenshots:

alles lijkt te werken echter:

 

Gisteren kreeg ik nog een mail van Ziggo. Het resultaat van mijn servicescan was dat mijn verbinding helemaal in orde was. Niets is dus minder waar.

Mijn reactie moet dus zijn:

Ik ben ONtevreden.

Maar die stond er niet bij.

 

 

 

[Marinus]

Opvallend in het netwerklog is dat ik de critical errors van ca 20:30 uur niet terug zie.

Wel errors op 21:01 uur.

Ok inloggen op de Sagemcom gaat nu sneller.

 

[tobiastheebe]

De uitval (16 consecutive T3 timeouts) vond plaats op het 'lage' OFDMA-kanaal. Ik kan niet verklaren waarom de events van 20:28 t/m 20:30 die deze uitval aanduiden niet meer zichtbaar zijn na de reset, deze zouden als events met severity: critical inderdaad nog steeds zichtbaar moeten zijn. Bijzonder dat een reset van het modem noodzakelijk was om internet connectivity te herstellen. De events van 21:01 (SYNC timing failure, T3 timeout) duiden niet op een probleem direct na een reset, de DHCP failure is wel ongebruikelijk.

[Kermit]

---

@tobiastheebe  schreef:

De uitval (16 consecutive T3 timeouts) vond plaats op het 'lage' OFDMA-kanaal. Ik kan niet verklaren waarom de events van 20:28 t/m 20:30 die deze uitval aanduiden niet meer zichtbaar zijn naar de reset, deze zouden als events met severity: critical inderdaad nog steeds zichtbaar moeten zijn. Bijzonder dat een reset van het modem noodzakelijk was om internet connectivity te herstellen. De events van 21:01 (SYNC timing failure, T3 timeout) duiden niet op een probleem direct na een reset, de DHCP failure is wel ongebruikelijk.

---

Ik heb recent mijn modem gereboot en toen kreeg ik geen WAN IP. Na het loshalen en terugsteken van de UTP, wat een DHCP verzoek afdwingt, werkte alles weer. Dit gedrag heb ik met eerdere modem reboots niet gezien, misschien is er iets gewijzigd in de Sagemcom modem configuratie? Kan Ziggo modem instellingen wijzigen zonder dat je reboot, staat de provisioning los van de boot file?

[Marinus]

@tobiastheebe 

En ik heb ook weer een nieuwe IPv6 prefix.

Kan ik weer van alles gaan aanpassen…..

Ipv4 lijkt gewoon hetzelfde gebleven.

De upstream geeft de errors van 21:01 niet weer, alles staat op 0.

[Kermit]

@Marinus mijn advies is om de volgende keer eerst even alle logs te verzamelen en dan te rebooten. Het modem bewaart niet alles na een reboot, alleen de alarmen met de hoogste prioriteit.

[Marinus]

@Kermit 

Zie eerdere post van vanavond met alle relevante logs.

Ik hoefde geen kabels los te trekken of Sagemcom van de stroom te halen.

Herstart via menu was genoeg. 

[tobiastheebe]

---

@Kermit  schreef:

---

@tobiastheebe  schreef:

[...]

---

Ik heb recent mijn modem gereboot en toen kreeg ik geen WAN IP. Na het loshalen en terugsteken van de UTP, wat een DHCP verzoek afdwingt, werkte alles weer. Dit gedrag heb ik met eerdere modem reboots niet gezien, misschien is er iets gewijzigd in de Sagemcom modem configuratie? Kan Ziggo modem instellingen wijzigen zonder dat je reboot, staat de provisioning los van de boot file?

---

Jouw modem is toch in bridge mode geconfigureerd? Is de eigen router als enige en direct aangesloten op het modem?

[Kermit]

---

@Marinus  schreef:

@Kermit 

Zie eerdere post van vanavond met alle relevante logs.

Ik hoefde geen kabels los te trekken of Sagemcom van de stroom te halen.

Herstart via menu was genoeg. 

---

De modem boot tijd van een sagemcom is zo ontzettend lang dat ik het loshalen van de UTP als snelle herstel actie uitvoer, zonder reboot.

[Kermit]

---

@tobiastheebe  schreef:

---

@Kermit  schreef:

---

@tobiastheebe  schreef:

[...]

---

Ik heb recent mijn modem gereboot en toen kreeg ik geen WAN IP. Na het loshalen en terugsteken van de UTP, wat een DHCP verzoek afdwingt, werkte alles weer. Dit gedrag heb ik met eerdere modem reboots niet gezien, misschien is er iets gewijzigd in de Sagemcom modem configuratie? Kan Ziggo modem instellingen wijzigen zonder dat je reboot, staat de provisioning los van de boot file?

---

Jouw modem is toch in bridge mode geconfigureerd? Is de eigen router als enige en direct aangesloten op het modem?

---

Jazeker in bridge, en als enige device mijn eigen router. Ik dacht die van Marinus ook, uit jouw bericht begrijp ik van niet.

Krijgt een modem in routermodus een nieuwe IPv6 reeks na een reboot?

[tobiastheebe]

---

@Kermit  schreef:

---

@tobiastheebe  schreef:

---

@Kermit  schreef:

---

@tobiastheebe  schreef:

[...]

---

Ik heb recent mijn modem gereboot en toen kreeg ik geen WAN IP. Na het loshalen en terugsteken van de UTP, wat een DHCP verzoek afdwingt, werkte alles weer. Dit gedrag heb ik met eerdere modem reboots niet gezien, misschien is er iets gewijzigd in de Sagemcom modem configuratie? Kan Ziggo modem instellingen wijzigen zonder dat je reboot, staat de provisioning los van de boot file?

---

Jouw modem is toch in bridge mode geconfigureerd? Is de eigen router als enige en direct aangesloten op het modem?

---

Jazeker in bridge, en als enige device mijn eigen router. Ik dacht die van Marinus ook, uit jouw bericht begrijp ik van niet.

Krijgt een modem in routermodus een nieuwe IPv6 reeks na een reboot?

---

Ik durf niet direct te zeggen waarom jouw router geen DHCP-lease ontving. Mogelijk kun je met tcpdump de oorzaak hiervan achterhalen in het vervolg.

De Sagemcom F3896 van Marinus is inderdaad in router mode geconfigureerd. De IPv6-prefix zou eigenlijk nooit moeten veranderen, maar dit is wel een gevolg van een veranderende DHCPv6 client DUID.

[Marinus]

@Kermit 

Mijn Sagemcom staat niet in bridge.

Het vreemde is dat ik niet altijd een nieuwe IPv6 prefix krijg na een reboot.

Maar wel meestal na een reboot na problemen. DHCP?

Nu al de 4e of 5e keer. Waardeloos!

IPv4 blijft wel hetzelfde.

[Marinus]

@tobiastheebe @Vincent 

Kan een moderator mij aangeven waarom het IPv6 prefix steeds verandert?

Is dit normaal, te verwachten gedrag of is dit afwijkend van wat te verwachten is?

[tobiastheebe]

Wat mij betreft is een veranderende IPv6-prefix na een reboot zeer onwenselijk. De oorzaak kan zowel bij de DHCPv6 server als client liggen. Als de client DUID-LL of DUID-UUID gebruikt, dan zou de prefix hoogstens bij groot onderhoud op het CMTS moeten/kunnen veranderen. DUID-LLT is in principe ook statisch, maar kan op elk gewenst moment opnieuw gegenereerd worden. Met een eigen router en het modem in bridge mode is dit goed te analyseren met tcpdump, maar met een modem in router mode is dit voor klanten vrijwel onmogelijk.

[Marinus]

@tobiastheebe 

Het is inderdaad zeer onwenselijk. Ik snap dat IPv4/IPv6 adressen bij ziggo niet 100% statisch zijn, maar een nieuwe IPv6 prefix bij vrijwel iedere modem reboot is wel bijna het andere uiterste.

Even voor de goede orde. Als je met client het Sagemcom modem bedoeld, dan ben ik het met je eens.

Ik gebruik SLAAC in de instellingen op de Sagemcom.

[tobiastheebe]

Mijn IPv4-adres is circa 1,5 jaar geleden voor het laatst veranderd, daarvoor was het 3 jaar eerder veranderd. Omdat ik nogal gehecht was aan mijn vorige adres had ik MAC spoofing gebruikt bij een router swap, maar dat kon ik later dus weer ongedaan maken. Ik maak sinds begin januari gebruik van IPv6 en de prefix is nog hetzelfde. Mijn huidige ER-4 maakt gebruik van DUID-LL.

Ik bedoelde met 'client' inderdaad de eRouter van de Sagemcom F3896. De instelling stateless/stateful heeft betrekking op de DHCPv6 server aan LAN-zijde en bepaalt of de server naast IPv6 DNS-servers ook IPv6-adressen verspreidt, waar deze anders door clients zelf opgebouwd worden met SLAAC. De instelling stateless is aanbevolen. Aan WAN-zijde kun je als klant geen instellingen aanpassen, zowel de /56 of /57 prefix (IA_PD) als de /128 GUA (IA_NA) worden hier door de DHCPv6 server op het CMTS toegewezen.

[Marinus]

@tobiastheebe 

Wat ik merk is dat de webinterface van de Sagemcom nu, na de reboot, weer "snel" (minder traag) is dan daarvoor.

Mijn vermoeden is dat er in de firmware van de sagemcom een "fout" zit waardoor het interne geheugen volloopt en er fouten kunnen optreden. In ieder geval word de webinterface er merkbaar trager van.

[Paul]

@Marinus Goede vraag die je hier stelt m.b.t. de IPv6 Prefix! Het is niet ongebruikelijk dat de IPv6 van tijd tot tijd wisselt. Dit mag verder niet van invloed zijn op de werking van de internetverbinding. Alleen wanneer het veel te vaak en onverwacht verandert kan dit iets zijn waar verder onderzoek naar verricht moet worden. Ik heb jouw vraag nu in ieder geval ook nog even voorgelegd aan onze engineers voor een extra controle. 

Als ik je goed  begrijp, heb je los van het feit dat de webinterface van het Sagemcom modem soms traag is, dus verder geen problemen met de verbinding op het moment dat je deze gebruikt, correct? Aa netwerkzijde zijn namelijk ook geen ongeregeldheden terug te zien. 

[Marinus]

@Paul 

Behalve onderstaande post van afgelopen zaterdag ben ik best tevreden.........

Mijn verbinding is OK, maar er gaat volgens mij iets structureel niet goed bij mijn verbinding en de verbinding van andere posters in o.a. dit topic.

Of het nu aan het CTMS, de Sagemcom hardware, de Sagemcom firmware of een combinatie van voornoemde factoren ligt, er gaat iets duidelijk niet goed.

Bij problemen los ik het wel op (herstarten), maar mensen met minder kennis kunnen hier niets mee.

De web interface wordt traag, als in minder responsief. Dit is soms een voorbode van "problemen", maar zoals onder beschreven heb ik nog niet eerder meegemaakt.

Ook iedere keer dat ik de Sagemcom na problemen moet herstarten verandert het prefix van het IPv6 adres. Het IPv4 adres blijft gewoon gelijk.

Ik probeer wat te hobbyen met IPv6 en domeinnamen en websites. Iedere keer dat het IPv6 verandert moet ik op meerdere plaatsen deze verandering weer doorvoeren.

---

@Marinus  schreef:

@Vincent @tobiastheebe @MR_CHIP @Kermit 

En weer T3 errors op het OFDMA kanaal.

Nu echter lag na deze errors de hele verbinding van het modem het Ziggo netwerk op plat.

Dit heb ik nog niet eerder gezien en is eigenlijk onacceptabel.

Na een herstart van de Sagemcom werkt alles weer.

Toch een half uur zonder internet gezeten.

De screenshots:

alles lijkt te werken echter:

 

Gisteren kreeg ik nog een mail van Ziggo. Het resultaat van mijn servicescan was dat mijn verbinding helemaal in orde was. Niets is dus minder waar.

Mijn reactie moet dus zijn:

Ik ben ONtevreden.

Maar die stond er niet bij.

 

 

 

---

[Paul]

@Marinus Inmiddels heb ik terugkoppeling van een van onze internet engineers. Het wijzigen van de IPv6 prefix heeft verder geen invloed op de snelheid waarop de modem/router GUI reageert. De engineer kon wel bevestigen dat de IPv6 gewijzigd is op 9 maart 2024 volgens hun controle. Mij is nu alleen niet helemaal duidelijk of je op dit moment nou wel of niet naar tevredenheid werkt. Indien het niet naar wens werkt dan horen wij graag wat dan de precieze storingsklachten zijn. Zo op het oog zien wij namelijk qua signaal geen ongeregeldheden terug.