Connect box verbinding die weg valt of extreem zakt

Anne-Ziggo zei:

Ik begrijp goed dat je met zulke meldingen denkt dat er iets misgaat, maar dit is echter niet altijd het geval. Meerdere T3 meldingen achter elkaar kan wel op een probleem duiden, maar dat hoeft niet altijd. Maar als je merkt dat je verbinding niet in orde is, stuur mij gerust een PM, ik help je graag verder.

Klik om te vergroten...

hoi Anne,

bedankt voor je reactie, de verbinding is vooralsnog in orde, dus wat mij betreft als het zo blijft helemaal goed.

mvg,

ed

robin de bruin zei:

ik zie alleen dit is dat heel erg ?

Klik om te vergroten...

Eerst wat uitleg over wat er gelogd wordt waarbij ik de volgorde van de meldingen even omdraai.

Het modem haalt op 6 juli om rond 17:15 een nieuwe firmware versie op.

Om 17:19 is het modem bezig met een herinitialisatie waarbij o.a. de modem configuratie file is opgehaald en wordt verwerkt. Ook worden dan de DOCSIS upstreams en downstreams gekoppeld. Op zo'n moment wordt er geen IP verkeer van afgesloten apparatuur afgehandeld. In dit geval is dit het gevolg van het activeren van de nieuwe firmware versie.

Om 17:19, dus tijdens de herinitialisatie, vindt deze T3 time-out plaats. T3 time-outs horen niet, maar een modem zal beginnen met een laag zend vermogen op de upstreams waardoor afhankelijk van de verbindingskwaliteit mogelijk verzonden berichten naar de CMTS niet aankomen. Een T3 time-out wil zeggen dat het modem Ranging Requests heeft verzonden maar niet binnen de gestelde tijd een Ranging Response heeft ontvangen als reactie van de CMTS. Deze melding is critical omdat het modem nu in een modus gaat om wel verbinding te krijgen met de CMTS waarbij geen IP verkeer wordt afgehandeld.

Deze T3 timeout treedt op tijdens een volledige reset van het modem waardoor het modem ook niet meer weet hoe laat het is.

Om 17:35 volgt er als gevolg van voorgaande reset, die dus ook rond 17:35 plaatsvondt, weer een herinitialisatie van het modem inclusief het ophalen en verwerken van de configuratie file. Wederom is er op dat moment geen IP verkeer mogelijk.

om 21:56 kan het modem weer niet goed communiceren met de CMTS, dus zal het modem eerst de verbinding herstellen en is er even geen IP verkeer afhandeling mogelijk. Vandaar de critical aanduiding.

Terugkomend op je vraag of dit dit erg is. Dat hangt er vanaf of het modem T3 time-out meldingen blijft genereren in de log. T3 time-out meldingen tijdens de herinitialisatie van een modem zijn niet iets om je druk over te maken, maar T3 time-out meldingen moeten niet de oorzaak zijn van het herinitialiseren van een modem. Dus als het modem eenmaal up-and-running is en je zelf het modem niet reset, dan wil je die T3 time-out meldingen niet meer zien omdat het modem daarmee duidelijk maakt dat de verbinding tussen modem en CMTS niet goed functioneert. Een voorbeeld daarvan is die spontane T3 time-out op 6 juli om 21:56.

ed41 zei:

...de verbinding is vooralsnog in orde...

Klik om te vergroten...

Het modem laat juist via de T3 time-out meldingen weten dat de verbinding niet in orde is waardoor de communicatie tussen modem en CMTS niet lekker verloopt. Veelal een indicatie dat door het modem via de upstream(s) verzonden data naar de CMTS niet goed aankomt. In geval van verzonden Ranging Requests kan het modem dit detecteren omdat het dan geen antwoord krijgt van de CMTS in de vorm van een Ranging Response binnen de gestelde tijd.

Dank @ArChie voor uw heldere uitleg die zelfs ik begrijp.... (had vorig jaar ook met dit fenomeen te maken)
Wat ik echter niet begrijp, zijn de nogal laconieke reacties van Webcare op dit platform.
Ik krijg successievelijk de indruk dat Ziggo zelf niet weet waar de vinger op de zere plek te leggen

Hier ook enkele T3 time-outs per dag. (modem gewoon up-and-running)
09-07-2016 08:04:59 critical No Ranging Response received - T3 time-out;CM-MAC=dc:53:7c:b5:28:b5;CMTS-MAC=00:220:c6:b7:74;CM-QOS=1.1;CM-VER=3.0;
08-07-2016 14:59:50 critical No Ranging Response received - T3 time-out;CM-MAC=dc:53:7c:b5:28:b5;CMTS-MAC=00:220:c6:b7:74;CM-QOS=1.1;CM-VER=3.0;
08-07-2016 00:18:31 critical No Ranging Response received - T3 time-out;CM-MAC=dc:53:7c:b5:28:b5;CMTS-MAC=00:220:c6:b7:74;CM-QOS=1.1;CM-VER=3.0;
07-07-2016 08:46:09 critical No Ranging Response received - T3 time-out;CM-MAC=dc:53:7c:b5:28:b5;CMTS-MAC=00:220:c6:b7:74;CM-QOS=1.1;CM-VER=3.0;
07-07-2016 05:35:23 critical No Ranging Response received - T3 time-out;CM-MAC=dc:53:7c:b5:28:b5;CMTS-MAC=00:220:c6:b7:74;CM-QOS=1.1;CM-VER=3.0;
06-07-2016 21:42:19 critical No Ranging Response received - T3 time-out;CM-MAC=dc:53:7c:b5:28:b5;CMTS-MAC=00:220:c6:b7:74;CM-QOS=1.1;CM-VER=3.0;
06-07-2016 14:34:30 critical No Ranging Response received - T3 time-out;CM-MAC=dc:53:7c:b5:28:b5;CMTS-MAC=00:220:c6:b7:74;CM-QOS=1.1;CM-VER=3.0;
05-07-2016 15:56:31 critical No Ranging Response received - T3 time-out;CM-MAC=dc:53:7c:b5:28:b5;CMTS-MAC=00:220:c6:b7:74;CM-QOS=1.1;CM-VER=3.0;

Maar goed, schijnt niet erg te zijn volgens Ziggo.
Maar er staat wel critical bij!

Vraag me af of Ziggo het ook niet erg vind als ik zo af en toe mijn factuur niet betaal.
Dan zeg ik ook gewoon: Zo af en toe is toch niet erg. Pas als het aan blijft houden dan wordt het pas een probleem!

Dat is een erg oneerlijk statement Rob.
Ondanks de omschrijving van sommige fouten zijn deze in de ICT zeer normaal.
Je moet een product of dienst dan ook niet beoordelen op de foutcodes in de logs maar op de kwaliteit van de dienst die je af neemt. Zo heb ik deze fouten ook in het log staan, allemaal te herleiden aan de tijdstippen dat ik het device heb herstart.

Je kunt dus aannemen dat deze fout als normaal kan worden beschouwd en vanzelf door het device wordt opgelost tijdens het opstart process. Het is een manier om aan te geven dat iets niet is gelukt, waarop het device het op een andere manier probeert en vervolgens verder gaat.

Waar ik mijzelf meer zorgen om maak is het zeer grote aantal PreRS errors. Hoewel ik hier graag een oplossing voor zie vind ik hierdoor niet dat mijn dienst die ik afneem bij Ziggo hierdoor in kwaliteit afneemt. Het internet laad nog steeds snel en de stabiliteit is goed en is sinds de laatste update ook zo gebleven.

Moraal van het verhaal is dat ondanks dat je misschien kan verwachten dat er geen fouten optreden op het modem dit niet altijd realistisch is om te verwachten. Zolang het internet zelf stabiel en snel werkt valt ziggo niets te verwijten. Dit in tegenstelling tot het niet betalen van een dienst dat in deze vergelijking gelijk zou staan aan het niet werken van het internet.

Wat dat betreft kunnen ze beter de log uitschakelen voor particulieren, denk dat ze hier alleen maar vragen/klachten over krijgen terwijl de meeste het niet merken of er invloed is met de verbinding.

Voor de ITers onder ons is het wel handige informatie.
De meeste gebruikers zullen deze informatie niet zien, het gaat fout als mensen deze toch openen en hierdoor verkeerde conclusies trekken. De gebruikers groep die dat zal doen lijkt mij klein.

dit is het enigste van vandaag
09-07-2016 16:14:49 critical No Ranging Response received - T3 time-out;CM-MAC=547:51:16:f5:aa;CMTS-MAC=00:19:2f:e66:74;CM-QOS=1.1;CM-VER=3.0;

bridge modus staat aan weet niet of dit verschil maakt

roymarja zei:

Wat ik echter niet begrijp, zijn de nogal laconieke reacties van Webcare op dit platform.
Ik krijg successievelijk de indruk dat Ziggo zelf niet weet waar de vinger op de zere plek te leggen

Klik om te vergroten...

Dat komt omdat ze werkelijk geen idee hebben hoe DOCSIS werkt. Over het algemeen blijft de kennis van Ziggo/UPC steken bij de analoge benadering van de techniek en als hun metertjes en/of de modem waarden dan binnen een bepaalde aangeleerde boven- en ondergrens dan zal het wel goed zijn. Zonder technische kennis, kunde en inzicht in de DOCSIS techniek begrijpen ze niet wat het modem op welke momenten logt en hoe je die log meldingen moet interpreteren, dus zien ze alles als een "notice" melding die je ter kennis geving kan aannemen en vergeten "want de gebruiker heeft toch internet" of "het modem herstelt zich toch vanzelf"? Dat er achter de schermen meer fout gaat voordat het modem in de critical toestand terechtkomt en dat logt wordt dan niet begrepen. Als het T3 time-out fouten bijvoorbeeld veroorzaakt worden door problemen in de upstream, dan zal dat niet alleen gevolgen hebben voor de DOCSIS Ranging Request management berichten maar voor alle data die het modem naar de CMTS moet verzenden. Dus ook op IP niveau zal er sprake zijn van resends omdat op de DOCSIS level verzonden data packets als corrupte packets worden ontvangen door de CMTS. Ofwel onnodige extra belasting van het coaxsegment.

Je ziet daarom ook keer op keer dat Ziggo/UPC slecht geteste hardware introduceert waarna eerst de pleuris moet uitbreken op forums en eventueel in de media wil Ziggo/UPC eindelijk iets gaan doen om met een soort van trial-and-error traject te trachten die problemen op te lossen. Met voldoende kennis, kunde en inzicht in de toegepaste techniek laat je het echter niet zover komen en pak je de problemen aan voordat er iets bij de klanten geïntroduceerd wordt. Maar ja, de praktijk leert ondertussen dat ze bij Ziggo/UPC blijven steken op het "stekkertje erin steken en kijken of ie iets doet en zo ja dan zal het wel goed zijn" niveau en het dan vreemd vinden dat ze klachten krijgen van de klanten.