T3 ODFMA errors, Sagemcom / Arris CMTS mismatch?

[Kermit]

Hallo Ziggo

Sinds de blackfriday actie ben ik klant geworden bij Ziggo, mijn verbinding is eigenlijk altijd error vrij, geen enkele uncorrectable zowel up als down. Om door een ringetje te halen...en dan uit het niets...klapt het ODFM-A kanaal eruit. Serkan heeft via de mail gekeken dat dit ook op 7 andere modems gelijktijdig gebeurt als het bij mij ook plaats vindt. Daarop is de groepsversterker ontvangen, echter kwam het probleem in de normale frequentie weer terug.

Als ik dan mijn oude topic bekijk, en die van @Marinus hier dan zie je dat het vaker voorkomt. Een veel gebruikt antwoord is: dat is mogelijk storing van buitenaf. Ik denk zelf aan een bug/mismatch tussen CM en CMTS.

Het is bij mij +/- om de 2 weken en maximaal 4 weken. Alles valt dan uit, VPN's en ook de NextMini en Videoland/NetFlix stoppen op dat moment. Erg vervelend als je het vergelijkt met mijn super stabiele glasvezelverbinding van vorig jaar.

Vraagstelling:

Ik Ziggo graag breder laten kijken of er een bug of mismatch is tussen de CMTS en het CM.  Hier lijken al wat stappen gezet in dit topic. Mijn verbinding is om door een ringetje te halen zei de monteur, waardes zijn goed zie mijn oude topic. Groepsversterker is vervangen, probleem is gebleven. Ik zou graag het expert team opschakelen omdat ik weet dat dit voor tenminste 3 klanten met een Arris CMTS + Sagemcom speelt waar van er 2 een topic hebben lopen/gehad.

Logs van gisterenavond.

Altijd 0 errors down

Altijd 0 errors down tot moment X waarbij ODFMA faalt, ik denk zelf aan een bug.

Storingen:
08-12-2023 +/- 21:00

02-01-2024 +/- 10:00

29-01-2024 +/- 01:30

21-02-2024 +/- 21:00

[tdk]

En zelfs alleen aan de kant van het CMTS. Want als er een downstream probleem zat zou je die frames (mits ze echt verstuurd zijn) terugzien als uncorrectable frame. En door versterking (één kant op) en optische mixing (ook alleen omhoog) is de ruis die het CMTS ziet anders dan wat jij ziet.

@Kermit heb jij een keer gekeken naar de tijden van de impact?

Waar zit te functionele/smokeping impact ten opzichte van de tijdstippen van de timeouts?

Ik vind het erg raar dat we eigenlijk geen loss zien (zelfs niet in een wireguard tunnel, waar QoS/firmware geen andere modulatie voor ICMP kan kiezen) tijdens normaal gebruik maar wel dat het T3-ranging proces - wat naar mijn interpretatie "coax plant die zijn niveaus calibreert" is - issues zien.

Een modem bug zou het ook verklaren…

@tobiastheebe het kanaal dat hoger zit geeft misschien _andere_ issues. Zeker bij klanten waar de thuisinstallatie het probleem is (bewust - "ach die verlengkabel kan prima" - dan wel onbewust).

Een open alpha (mogelijk niet mogelijk als er filters vervangen moeten zijn in de regio). en echt experiment op grote schaal (deel klanten in twee groepen in en kijk naar hoeveel issues je ziet) is interessant.

[tobiastheebe]

---

@Kermit  schreef:

---

@tobiastheebe  schreef:

De call is om 16:00.

---

Tobias in de verbeterplannen kan ook een subtiele verandering aan de modem configuratie onderzocht worden. Waarom neemt ATDMA het niet over van ODFMA op het moment dat dit kanaal uitvalt, je hebt wel eens eerder beschreven dat dit technisch mogelijk moet zijn. Als ik alle berichten lees dan is het door Ziggo niet geactiveerd? 

---

Helaas nog geen inhoudelijke toezeggingen, er was te weinig tijd over in de call om een goede toelichting te geven. Achteraf heb ik wel vrij uitgebreid beschreven welke instabiliteit/uitval er soms speelt en hoe deze herkend en eventueel gemitigeerd/opgelost kunnen worden. De configuratiewijziging die je noemt heb ik eerder in dit topic al naar voren gebracht en na de call ook bij de moderators aangekaart. ATDMA kan het inderdaad overnemen als OFDMA uitvalt, maar blijkbaar niet naadloos, tenminste niet met de huidige CMTS-configuratie. Wat bedoel je precies met 'niet geactiveerd'?

---

@tdk  schreef:

@tobiastheebe het kanaal dat hoger zit geeft misschien _andere_ issues. Zeker bij klanten waar de thuisinstallatie het probleem is (bewust - "ach die verlengkabel kan prima" - dan wel onbewust).

Een open alpha (mogelijk niet mogelijk als er filters vervangen moeten zijn in de regio). en echt experiment op grote schaal (deel klanten in twee groepen in en kijk naar hoeveel issues je ziet) is interessant.

---

De bhi kan inderdaad ook een oorzaak zijn, vandaar dat de POA-254 nu de standaard door Ziggo geleverde en door monteurs geplaatste splitter is. Door het band-pass-filter (254~862 MHz) op de TV-uitgang wordt voorkomen dat ruis uit de bhi de retourband/upstream kan verstoren. Ook dit heb ik na de call in mijn verhaal naar de moderators gezet.

[Kermit]

---

@tobiastheebe  schreef:

---

@Kermit  schreef:

---

@tobiastheebe  schreef:

De call is om 16:00.

---

Tobias in de verbeterplannen kan ook een subtiele verandering aan de modem configuratie onderzocht worden. Waarom neemt ATDMA het niet over van ODFMA op het moment dat dit kanaal uitvalt, je hebt wel eens eerder beschreven dat dit technisch mogelijk moet zijn. Als ik alle berichten lees dan is het door Ziggo niet geactiveerd? 

---

Helaas nog geen inhoudelijke toezeggingen, er was te weinig tijd over in de call om een goede toelichting te geven. Achteraf heb ik wel vrij uitgebreid beschreven welke instabiliteit/uitval er soms speelt en hoe deze herkend en eventueel gemitigeerd/opgelost kunnen worden. De configuratiewijziging die je noemt heb ik eerder in dit topic al naar voren gebracht en na de call ook bij de moderators aangekaart. ATDMA kan het inderdaad overnemen als OFDMA uitvalt, maar blijkbaar niet naadloos, tenminste niet met de huidige CMTS-configuratie. Wat bedoel je precies met 'niet geactiveerd'?

---

Ik heb pas weer internet als ODFMA weer hersteld is in de logs, geen enkele ATDMA regel zie ik. Met de zeer beperkte kennis die ik bezit over dit onderwerp. Ben ik van mening dat wanneer je een Elite abonnement hebt met een D3.1 profiel je helemaal geen toegang hebt tot D3.0. Anders had ik wel een entry in de log verwacht "OFDMA dropped switching to ATDMA" en daarbij geen downtime van ruim 4 minuten maar een paar seconden.

[Kermit]

---

@tdk  schreef:

@Kermit heb jij een keer gekeken naar de tijden van de impact?

Waar zit te functionele/smokeping impact ten opzichte van de tijdstippen van de timeouts?

Bedoel je of ze verschoven zijn tov elkaar? Dat is lastig te bepalen omdat mijn smokeping meerdere processen heeft, je weet niet welk proces er in timesync ping met je outage.

Als je benieuwd bent hoe lang het internet uitvalt bij "16 constructive T3 errors seen" meldingen in de logfile? Dat is 4 minuten, genoeg om alle video streams in huis te laten stoppen, de buffering compenseert dit niet.

Storingen:
08-12-2023 +/- 21:00

02-01-2024 +/- 10:00

29-01-2024 +/- 01:30

21-02-2024 +/- 21:00

[tobiastheebe]

Wat ik zelf ervaar bij uitval van OFDMA (16 consecutive T3 timeouts c.q. ranging retries exhausted) is 1~2 minuten packet loss (niet 100%) en geen algehele uitval. Enkele voorbeelden:

Als jij geen ATDMA ziet bij uitval, dan speelt bij jou een ander probleem. Het abonnement staat los van de signaal-/kanaalconfiguratie, deze bepaalt alleen welke service flows het modem toegewezen krijgt in de boot file.

[Kermit]

---

@tobiastheebe  schreef:

Wat ik zelf ervaar bij uitval van OFDMA (16 consecutive T3 timeouts c.q. ranging retries exhausted) is 1~2 minuten packet loss (niet 100%) en geen algehele uitval. Ik zal nog even een paar voorbeelden verzamelen uit mijn event log en monitoring. Als jij geen ATDMA ziet bij uitval, dan speelt bij jou een ander probleem. Het abonnement staat los van de signaal-/kanaalconfiguratie, deze bepaalt alleen welke service flows het modem toegewezen krijgt in de boot file.

---

Ja dat zou helpen als ik focus woorden kan ctrl-f'en gedurende het probleem. In de topicstart van dit topic zit ook een aantal screenshots. Er zijn geen ATDMA T3's gedurende de ODFMA issues, de ATDMA counters blijven op 0 en deze kanalen blijven up. Waardoor ik failover technisch mogelijk acht, alleen deze lijkt niet toegestaan.

[tobiastheebe]

Ik heb mijn vorige reactie inmiddels bijgewerkt.

[Kermit]

---

@tobiastheebe  schreef:

Wat ik zelf ervaar bij uitval van OFDMA (16 consecutive T3 timeouts c.q. ranging retries exhausted) is 1~2 minuten packet loss (niet 100%) en geen algehele uitval. Enkele voorbeelden:

Als jij geen ATDMA ziet bij uitval, dan speelt bij jou een ander probleem. Het abonnement staat los van de signaal-/kanaalconfiguratie, deze bepaalt alleen welke service flows het modem toegewezen krijgt in de boot file.

---

Dat is inderdaad een minuut, blijft je next mini doorspelen?

Het abonnement bevat de serviceflows met de toegestane snelheden, jouw theorie is dat een modem dan alle beschikbare kanalen zou mogen gebruiken zolang ze zichtbaar zijn in de coax-plant, zowel D3.0 en D3.1? Dat kan ik nog niet rijmen met hoe ze dan Elite klanten forceren naar D3.1? Mijn gevoel is dat dit in de Sagemcom een harde setting is waardoor ik op ATDMA geen data mag versturen, immers mijn Elite abonnement dwingt mij naar D3.1 kanalen.

[tobiastheebe]

Ik heb een Mediabox Next, helaas geen informatie meer of deze in gebruik was op 12-12 tussen 16:32 en 16:36. Mijn monitoring zag i.i.g. geen uitval naar 7 stuks WAN hosts.

Ieder DOCSIS 3.1-modem koppelt alle beschikbare kanalen, zowel ED3.0 als D3.1. In de downstream wordt in principe altijd OFDM actief gebruikt, in de upstream worden ATDMA en OFDMA gelijktijdig gebruikt. Deze werking is niet afhankelijk van het abonnement.

Ik had je voorlaatste reactie trouwens verkeerd begrepen, ik dacht dat je tijdens uitval van OFDMA ook geen ATDMA meer zag, maar je bedoelt dat ATDMA juist geen problemen geeft. Dat is ook mijn observatie.

[tdk]

Jammer. Het is lastig om de tijdlijnen precies naast elkaar te leggen. Dus de volgorde van de events (signaal-storing -> loss -> t3 timeout) of (t3 timeout door bug -> loss) kunnen we niet afleiden.

–––

Ik weet niet hoe er bij DOCSIS bepaald wordt welke upload kanalen (en tijd-slots) een modem gebruikt. In mijn mentale model van hoe het werkt ging ik uit van iets dat op WiFi lijkt. Wikipedia bevestigd dit ook,

> DOCSIS employs a mixture of deterministic access methods for upstream transmissions, specifically time-division multiple access (TDMA) for DOCSIS 1.0/1.1 and both TDMA and S-CDMA for DOCSIS 2.0 and 3.0, with a limited use of contention for bandwidth reservation requests. In TDMA, a cable modem requests a time to transmit and the CMTS grants it an available time slot.

Alleen hoe weet het CMTS welke kanalen een modem heeft? In het begin is dat simpel (er is vast een handshake). Maar hoe werk je dit bij tijdens uitval?

[tobiastheebe]

Het CMTS wijst kanalen + bijbehorende configuratie toe in de UCD-, MAP- en MDD-berichten. Het CM stuurt op elk upstream-kanaal RNG-REQ-berichten terug naar het CMTS, welke het CMTS op diens beurt beantwoordt met RNG-RSP, dit is de handshake waar jij op doelt. De T3 timeouts treden op bij deze RNG-REQ's.

[MR_CHIP]

---

@Samplex  schreef:

Ik heb hier ook last van, verbinding even weg. Ook blijf ik maar t4 meldingen houden. Alles is al nagekeken, Sagecom zelfs vervangen voor een andere maar lost het probleem niet op. Verbonden op Casa cmts.

Veel T3 meldingen in de log ook:

27-02-2024 03:54:26	critical	Started Unicast Maintenance Ranging - No Response received - T3 time-out;CM-MAC=94:98:8f:91:a5:b1;CMTS-MAC=00:17:10:91:c6:8d;CM-QOS=1.1;CM-VER=3.1;
27-02-2024 03:49:05	error	DHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=94:98:8f:91:a5:b1;CMTS-MAC=00:17:10:91:c6:8d;CM-QOS=1.1;CM-VER=3.1;

---

[Marinus]

Daar gaat wel meer mis dan alleen OFDMA T3 errors……. 

[Kermit]

@Samplex ik denk dat een eigen topic voor jou verstandig is, daar lijkt meer mis te zijn.

@tobiastheebe om nog even het beeld te sterken na 21 dagen uptime, letterlijk geen vuiltje (error) aan de lucht. De lijn is brand en brandschoon, totdat ODFMA uitvalt. Kan ik op een of andere manier bijdragen aan de urgentie van dit onderwerp, ik zou heel graag zien dat een moderator ook meeleest en acties uitzet. 

Screenshots bevatten 1x uitval OFDMA.

alle tussenliggende downstream kanalen hebben ook 0 errors.

En dan ineens uit het niets klapt OFDMA eruit, misschien heb ik er toch baat bij als er weer eens een langdurige meting wordt gestart met detail informatie.

[tobiastheebe]

Zoals eerder aangegeven is voor ons niet te zien of de 'lijn schoon is' qua upstream (MER + CER).

[Kermit]

---

@tobiastheebe  schreef:

Zoals eerder aangegeven is voor ons niet te zien of de 'lijn schoon is' qua upstream (MER + CER).

---

Sorry ik begreep hem toen niet en nu weer niet 😉 "ons" is in deze zin Ziggo? Ziggo kan een langdurige detail meting starten waarin we de tijdstippen kunnen weerleggen naast mijn outages?

[tobiastheebe]

Met 'ons' bedoel ik klanten. Een meerdaagse meting is uiteraard mogelijk.

[Paul]

Goedemiddag @Kermit,

Goed dat je door middel van dit topic even opnieuw aan de bel trekt! We hebben even een meting gestart om de komende dagen het signaal nauwkeurig te monitoren (SC-QAM + OFDM/A) daarnaast loopt er ook een ICMP meting. Zie jij kans de komende dagen bij te houden wat jouw bevindingen zijn op het moment dat jouw internetverbinding gebruikt wordt (surfen, downloaden, streamen etc.).

Op het moment dat je merkt dat er problemen zijn is ons verzoek om dan de datum en het tijdstip te noteren waarop je een probleem constateert. We kunnen dit dan 1 op 1 vergelijken met onze monitoren en aan de hand daarvan bekijken wat hier de eventuele vervolgstappen zijn. 

[Kermit]

Goedemorgen @Paul dank voor de meting. Als je kijkt naar de historie in mijn post dan denk ik dat we meerdere langdurige metingen moeten nemen om het probleem vast te leggen.

Zou je voor mij intern na kunnen vragen waarom ik totale outage ervaar als "slechts" ODFMA wegvalt, zouden ze dit in het testlab eens kunnen reproduceren? Misschien komt er een simpele modem aanpassing uit waardoor alle klanten minder impact ervaren.

[Paul]

@Kermit Er loopt nu een meerdaagse nauwkeurige meting op jouw verbinding samen met een ICMP meting. Wil je het modem trouwens nog wel eenmaal herstarten en de datum en tijdstip waarop je dit gedaan hebt doorgeven. De logging in het modem is dan weer "schoon" Ik zie nu namelijk nog een aantal oude T3's terug in het log v. een eerder moment (21 februari 2024). We gaan daarnaast testen of het te reproduceren valt op onze test opstelling. 

Noteer verder de komende dagen de data + tijdstippen indien je problemen ervaart (zoals uitval/packetloss/trage verbinding etc.)  met de verbinding op het moment dat je deze gebruikt (surfen/gamen/streamen/down- en uploaden). Hopelijk krijgen we dan beter in kaart wat er precies aan de hand is.