Monitoring Ubee UBC1318ZG

[tobiastheebe]

Dit is de voortzetting van een vorig door mij gestart topic over monitoring van de Compal CH7465LG-ZG.

Ik heb vandaag een Ubee UBC1318ZG in gebruik genomen. Dit modem staat net zoals de Compal CB in bridge mode en is aangesloten via een POA-01-B op de btv 1 IEC-NL. In tegenstelling tot de Compal CB heb ik voor de Ubee een attenuator (3 dB) geplaatst omdat de downstream altijd aan de sterke kant was. Ook voor de Ubee ben ik van plan om een monitoring script te schrijven en over de ontwikkeling daarvan wil ik updates gaan plaatsen in dit topic.

Eerst echter het volgende: sinds omstreeks maart/april had de Compal CB veel last van lage MER-waarden en hoge correctable + uncorrectable codewords op de hogere kanalen. Na het aansluiten van de Ubee leken deze problemen even totaal verdwenen, op alle kanalen 42~43 dB MER en op enkele kanalen 1 correctable error na ~30 minuten uptime. Nu na ~3 uur is de ruis helaas weer volop terug, het gaat duidelijk om instraling van 4G/5G:

Nu mijn vraag: zou een Ziggo-moderator (bijvoorbeeld @Alex) nogmaals naar de DS CER in de wijk willen kijken? Mijn vermoeden is dat een of meerdere van onze buren hun binnenhuisinstallatie niet op orde hebben. Ik denk dat het langzamerhand tijd wordt dat een netwerkmonteur komt meten op de EV.

[tobiastheebe]

Om te kunnen blijven concurreren met glasvezel (XGS-PON) zal dat wel moeten.

Er zijn nog flink wat obstakels voor een grootschalige uitrol van DOCSIS 4.0. Om te beginnen moeten CMTS's en EuroDOCSIS 3.0-modems worden vervangen. Hoewel de passieve onderdelen in de binnenhuisinstallaties en wijknetten inmiddels tot 2 of 3 GHz doorgeven, gaan de actieve onderdelen zoals versterkers tot 1,2 GHz. Voor DOCSIS 4.0 (met overlappende downstream en upstream) is een vrij spectrum van 1,8 GHz nodig. Daarnaast zie ik met regelmaat dat de doorgave al vanaf 700~800 MHz onbetrouwbaar wordt door instraling en verouderde/beschadigde buitenkabels die teveel demping opleveren. Het verplaatsen van de nodes van wijkcentrum naar meterkast zou ook significant uitgebreid moeten worden, dit is nu nog beperkt tot enkele nieuwbouwprojecten en plaatsen met een eigen glasvezelnet.

[Eric206]

Als ik dat allemaal lees denk ik dat we al blij moeten zijn met DOCSIS 3.1😅

[Metenisweten]

@tobiastheebe : recent is er een upgrade geweest in onze wijk. Het OFDM kanaal en dat andere kanaal zijn toch alleen zichtbaar in de Ubee en de Connectbox Gigia toch? Zelf heb ik een Compal Connectbox en die (begreep ik eerder van jou) kan alleen op Docsis 3.0 toch?

[tobiastheebe]

Het SmartWifi modem 'non-Giga' is een EuroDOCSIS 3.0-modem en kan alleen SC-QAM-kanalen koppelen, 24 van 32 beschikbare DS-kanalen plus 4 (fZiggo) of 6 (fUPC) ATDMA/US-kanalen. Het OFDM- en OFDMA-kanaal kunnen alleen door DOCSIS 3.1-modems (zoals het SmartWifi modem Giga en de UBC1318ZG) worden gekoppeld.

[Eddie the Eagle]

Een week geleden dus die firmware update gehad en vanochtend deze. Iemand die me in Jip & Janneke taal kan uitleggen wat er dan gebeurt ?

Time Priority Description

2022-05-15 06:46:37	notice	DS profile assignment change. DS Chan ID: 32; Previous Profile: ; New Profile: 1 2 3.;CM-MAC=
2022-05-15 06:46:31	notice	TLV-11 - unrecognized OID;CM-MAC=
1970-01-01 00:00:37	warning	DHCP WARNING - Non-critical field invalid in response ;CM-MAC=
1970-01-01 00:00:34	notice	Honoring MDD; IP provisioning mode = IPv4
1970-01-01 00:00:22	critical	SYNC Timing Synchronization failure - Failed to acquire QAM/QPSK symbol timing;;CM-MAC=
2022-05-15 06:45:17	critical	Resetting the cable modem due to docsDevResetNow

[MR_CHIP]

Resetting the cable modem due to docsDevResetNow = modem reset gedaan door ziggo hardware vanwege een eventuele wijziging in het netwerk/software e.d of vanwege onderhoud

SYNC Timing Synchronization failure - Failed to acquire QAM/QPSK symbol timing;;CM-MAC=

die mag iemand ander beantwoorden

Honoring MDD; IP provisioning mode = IPv4 = er is waarschijnelijk een ipv4 only profiel op je modem tbv port forwarding dit is een signaal/melding dat hij geen ipv6 vraagt/instelt

DHCP WARNING - Non-critical field invalid in response ;CM-MAC= er is een dhcp request richting de cmts(hoofd modem van ziggo ) verstuurd met daarop een niet kritische foute beantwoording een klein stukje waar het ziggo ubee modem niks mee kan omdat dit ofwel bedoeld is voor andere type modems of niet gebruikt wordt

TLV-11 - unrecognized OID;CM-MAC= beetje de error zoals hierboven alleen gaat dit om specifieke info in de bootfile die eigenlijk bedoeld is voor een ander merk modem gebruikt wordt

DS profile assignment change. DS Chan ID: 32; Previous Profile: ; New Profile: 1 2 3.;CM-MAC=

volgens mij betekent dit dat het modulatie profiel van het OFDM kanaal op 4096 wordt gezet de maximale profiel indeling/modulatie 

[Eddie the Eagle]

Dank voor je uitgebreide antwoord; is helder. De Ubee staat in bridge mode; ik heb idd (gelukkig) een IPv4 maar heb daar nooit speciaal om gevraagd. Ik doe verder dus niks met port forwards in de Ubee zelf; wel in de achterliggende router.

[MR_CHIP]

woon je in oud upc gebied daar was het nodig om een ipv4 only bootfile te sturen naar het modem zodat je de ubee modem zelf in bridge mode kon zetten in de oude situatie 

[Eddie the Eagle]

Nee, Oud Ziggo hier; ik heb lang geleden de Compal connect box in bridge mode laten zetten, dat kon ik niet zelf. Die staat nog hier als relikwie 😂 die hoefde niet terug. Begin van het jaar de overstap gemaakt naar Giga en dus de Arris Giga connect box gekregen maar dat was geen succes met performance, veel lag. Die is vervangen door de Ubee en de problemen waren opgelost. Beide modems gingen automatisch naar bridge mode zoals in het profiel vastgelegd. Waarom ik dan nu naar een IPv4 only profiel ben gezet weet ik eerlijk gezegd ook niet; ik heb daar niet om gevraagd maar is een welkome aanpassing. Ik heb geen nog geen enkele behoefte aan IPv6, niet aan de WAN en niet aan de LAN zijde.

[MR_CHIP]

lol ik heb nog een mediabox next arris model hier en de connectbox v1 compal nooit geen brief over gehad dat die terug moeten en ik kreeg ook geen factuur dat ze in rekening zijn/werden gebracht

[Eddie the Eagle]

De Arris Giga Connectbox werd wel specifiek om gevraagd om die terug te sturen en ook een retourdoos voor gekregen. Ik denk omdat dat nog een recent model is dat weer gemakkelijk ingezet kan worden. Die Compal was 10 jaar oud of zo; ik denk niet dat daar ook maar iemand nog iets aan heeft.

[Eddie the Eagle]

@tobiastheebe Om het andere topic niet te vervuilen 😉. Hoe haal je die log zo mooi op ? Toch een manier gevonden voor remote syslog ? Hier is het nog een verschrikkelijk geklooi via de GUI v/d Ubee.

[tobiastheebe]

Remote syslog zou naast SNMP aan LAN-zijde enorm handig zijn, helaas lijken beide niet beschikbaar te zijn.

Ik gebruik voor het ophalen van de event log ook een PHP-script. Dit script is bijna gelijk aan het reguliere monitoring script, de gegevens worden echter niet opgemaakt na omzetting van JSON naar PHP object, maar simpelweg direct getoond in de console. Ik voer het script direct op mijn Windows PC uit, niet op de Nagios-server.

[Eddie the Eagle]

Oeps, na maandenlang perfect werk is Nagios gisteren opgehouden met meten van m`n Ubee waardes. 

@tobiastheebe wat kan ik het best doen om `m weer in de lucht te krijgen; ik kan Nagios zelf wel nog gewoon bereiken.

[tobiastheebe]

Het script geeft waarschijnlijk 'no data available' terug? In dat geval moet het modem even opnieuw opgestart worden.

[Eddie the Eagle]

Ik ben er al achter, m`n Proxmox server gaf problemen; alle VM`s lagen er uit, althans sommige, zoals Nagios, waren wel bereikbaar maar konden niks wegschrijven. Na reboot werkt alles weer, excuus voor onnodig lastig vallen, hier had ik eerst naar moeten kijken.

[tobiastheebe]

Fijn om te lezen dat het weer werkt.

[Eddie the Eagle]

Altijd leuk ter lering en vermaak, een duidelijke afvlakking in de stijging van het aantal uncorrectables op het OFDM kanaal de laatste paar weken. De drop in week 23 was een reboot en het gaatje in week 26 een korte uitval van de VM waar de server op draait.

[tobiastheebe]

Ik heb een kleine update voor het monitoring script klaarstaan. In deze update worden de frequenties voor de downstream-kanalen niet meer afgerond, zodat dit consistent is met de upstream-kanalen. Verder worden voor het OFDMA-kanaal de beschikbare IUC's (Interval Usage Codes) getoond. Tenslotte heb ik de threshold-waarden voor het vermogen bijgewerkt voor zowel DS (-13 tot 17 dBmV, bron: Excentis) als US (ATDMA: 36 tot 51 dBmV, OFDMA: 30 tot 45 dBmV, bron: blauwdruk Ziggo), deze gegevens worden als performance data verwerkt door Nagios en doorgestuurd naar nagiosgraph. Zodra GitLab klaar is met hun scheduled maintenance kan ik een commit en push doen.

[tobiastheebe]

Commit staat inmiddels live.