[Glasnet.nl] Ervaringen & Discussie - Deel 1

[WallyPower]

smnk schreef op woensdag 22 april 2026 @ 21:00:
[...]


Jep.

Lees hier dat ze al de hele dag druk zijn met kabelschade in Gennep. Geen idee of het gerelateerd is maar je zou zeggen… te toevallig. https://glasnet.nl/meldingen

Hier in Grave heeft het de hele dag gewerkt. Als ik de berichten hierboven lees lijkt het bij het inschakelen van Gennep down te zijn gegaan.

[Twazerty]

Paar minuten geleden in Oss ook plat.

[sander817]

Inmiddels weer weg in Gennep

[bundit]

Regio Boekel heeft het de hele dag gewerkt maar ook sinds 21:00 down.

[smerz]

+1 Oss offline

[smnk]

Hier in Grave heeft het de hele dag gedaan. Als ik de berichten hierboven lees lijkt het bij het inschakelen van Gennep down te zijn gegaan.

Hier in Beers ook hele dag geen problemen. Maar het lijkt er inderdaad op dat ze het probleem verplaatst hebben haha.

[MMaster23]

Regio Rosmalen/Oss: down

[FearMe]

Ook hier (regio Bergen) zojuist kort internet gehad, blijkbaar ten koste van anderen!

[mr-schultzz]

Heesch ook plat

[RobbyTown]

Reek down
edit
En weer up na Downtime: 16 m 59 s

[ Voor 79% gewijzigd door RobbyTown op 22-04-2026 21:23 ]

[WallyPower]

Dus heel Noord-Oost Brabant is op zn gat gegaan. Lekker dan

[JanW]

Schaijk idem. Ik zat hier al de boel te herstarten. Tip aan mezelf voor de volgende keer, eerst hier kijken

[ Voor 4% gewijzigd door JanW op 22-04-2026 21:14 ]

[bundit]

bundit schreef op woensdag 22 april 2026 @ 21:07:
Regio Boekel heeft het de hele dag gewerkt maar ook sinds 21:00 down.

En weer online, PPPoE sessie is nu weer terug

[smnk]

Hier weer terug (Beers) na 25 min downtime volgens Unifi.

[MMaster23]

Regio Rosmalen/Oss: Up

[WallyPower]

Grave ook weer up

[tismij]

Yup 20 min en up in Oss
12min 23 sec volgens unifi

[ Voor 37% gewijzigd door tismij op 22-04-2026 21:21 ]

[KraveN]

In Gennep nog steeds down. Begreep dat de schade is gekomen door een boer die met diep ploegen wat kabels heeft geraakt in Beugen. Daarvoor zouden ze 15 meter vrij hebben moeten graven alvorens ze konden lassen.

En weer up!

[ Voor 3% gewijzigd door KraveN op 22-04-2026 21:26 ]

[Tweak_]

Was hier ook down ja, (regio Mill) ben wel benieuwd of het met elkaar te maken had. In mijn router zag ik PPPoE down heb ik ook doorgegeven. Misschien als er ineens weer veel aanvragen komen dat het crasht ofzo?

[Twazerty]

Weer plat in Oss

[MMaster23]

Regio Rosmalen/Oss: down d-d-down

23:34 Regio Rosmalen/Oss: Up

[ Voor 34% gewijzigd door MMaster23 op 22-04-2026 23:34 ]

[tismij]

Wel irritant zo idd weer plat

[tismij]

Waarom updaten ze de site ook niet ff om aan te geven, best tevreden over glasnet maar informeer ons ff tussendoor.

[Tweak_]

Inderdaad, hier was het ook weer down maar wel een stuk later dan @Twazerty aangaf. Nu dus weer werkend.

[tismij]

Oss nog down, half uurtje nu
Edit: amper klaar met typen en weer up.
Nou hopen dat het up blijft.

[ Voor 55% gewijzigd door tismij op 22-04-2026 23:50 ]

[Tweak_]

tismij schreef op woensdag 22 april 2026 @ 23:20:
Wel irritant zo idd weer plat

Ze hebben je post gelezen denk ik

22-04-2026, 23:50

Sorry, De storing glasvezel bruik is opgelost. We hebben nu problemen met onze switch stack die niet meer stabiel wil worden. Er word aan gewerkt.

[Mari_eu]

Je zou verwachten dat het glasvezel netwerk van ODF redundant is. Alles dubbel gevoed zodat het verkeer automatisch omgeleid wordt bij een breuk. Blijkt dus niet zo te zijn. Kan iemand hier iets zinnigs over zeggen?

[JanW]

Ik loop nu met deze storing wel tegen een bijzonder probleem aan. Ik las hier dat de verbinding weer terug is, maar hier geeft mijn Fritzbox (FRITZ!Box 5530 Fiber) nog aan dat er geen glasvezel verbinding actief is en dat de SFP module (FS BiDi LX SFP-GE-BX) niet wordt ondersteund. Ik moet dan de router herstarten en dan komt de verbinding weer op. Herkennen mensen dit probleem?

[smerz]

@JanW Ja ik had dat met de glasnet SFP/optic ook. Is meerdere keren gebeurt en heel irritant omdat je dus zelf handmatig moet ingripen voor herstel. Dit gebeurde ook gewoon random naar een tijdje bij mij.

Ik had nog de optic van Tweak destijds hier liggen en gebruik die nu. Die werkt zonder problemen.
Ik dacht dat het misschien aan mijn exemplaar ligt, maar zogezien niet. Dat is denk ik zeker een verbeterpuntje.

[RobertMe]

Mari_eu schreef op donderdag 23 april 2026 @ 09:20:
Je zou verwachten dat het glasvezel netwerk van ODF redundant is. Alles dubbel gevoed zodat het verkeer automatisch omgeleid wordt bij een breuk. Blijkt dus niet zo te zijn. Kan iemand hier iets zinnigs over zeggen?

Ik kan hier (specifiek) niks over zeggen. Maar een artikel hier op de frontpagen en/of verslag in een forum post van een "bezoeker" beschrijft dat Delta Fiber bij aanleg redundantie heeft door POPs onderling aan te sluiten. Elke POP heeft een eigen uplink "naar het internet" en de POPs zijn onderling ook verbonden waardoor een wegvallende verbinding naar het internet (gedeeltelijk) opgevangen kan worden door de link die de POPs onderling hebben. (En mogelijk dat ze "onderbezetting" van de ene POP kunnen gebruiken als extra capaciteit voor een ander. Ging volgens mij om 100Gbit/s links. Als één POP dan maar 50Gbit/s richting internet verstouwd en een ander POP al 100Gbit/s dicht trekt en bv 125Gbit/s nodig heeft dat ze die extra 25Gbit/s over het gelinkte POP sturen).

En anderzijds is er volgens mij ook nog wel eens onduidelijkheid bij de infra-boeren waar kabels liggen. Een ODF (of KPN/Glaspoort of DFN) zal mogelijk ook weer dark-fibers van iemand anders afnemen. Waarbij of helemaal niet duidelijk is waar die dark-fibers liggen of er beloften worden gedaan die ze niet waar maken. Was er bv ergens in de afgelopen 2? jaar niet ergens met werkzaamheden aan een brug een hele bundel kabels gesneuveld waaronder meerdere "redundant" kabels van één dark-fiber leverancier waardoor ik meen "KPN" er in een groter gebied er uit lag? Waarbij KPN dus dacht een redundant verbinding af te nemen, maar in werkelijkheid liepen de vezels, in ieder geval bij die brug, dus wél naast elkaar. Dan kun je dus wel vezels "in het veld" echt volledig gescheiden leggen met bv honderden meters ertussen of echt een geheel ander traject. Maar soms loop je dan alsnog tegen barrières aan (rivier / kanaal) waarbij het gevolg van "de makkelijke route" is dat de kabels alsnog bij elkaar liggen. (I.p.v. dus twee aparte bruggen gebruiken bv).

Edit:
Het Delta bezoek verslag: ernstoud in "[Delta XGS-PON Glas] Eigen ONT/modem/router installeren - 2"
Delta deed dus 4x 10Gbit/s naa de POPs maar ten tijde van dat bezoek nieuwe aanleg al 2x 100Gbit/s. En "grote POPs" zijn onderling verbonden. Geen idee wat dat betekent, maar het zijn vast niet "alle POPs" (zoals ik het schreef).

De beschadigde kabel(s) ging waarschijnlijk om: nieuws: Internetstoring door beschadigde glasvezelkabel treft huishoudens bij... geen brug maar tunnel dus.

[ Voor 14% gewijzigd door RobertMe op 23-04-2026 10:48 ]

[Jef61]

Mari_eu schreef op donderdag 23 april 2026 @ 09:20:
Je zou verwachten dat het glasvezel netwerk van ODF redundant is. Alles dubbel gevoed zodat het verkeer automatisch omgeleid wordt bij een breuk. Blijkt dus niet zo te zijn. Kan iemand hier iets zinnigs over zeggen?

Ik vraag me af of dit een ODF of provider probleem is. Het lijkt me dat er voldoende glas ligt om redundantie te realiseren, maar misschien voert een provider dit vanwege kosten niet (overal) uit?

Gisterenmiddag lag hier in Cuijk Netrebel eruit, maar ik begrijp dat Glasnet dankzij redundantie wel bleef werken.

In de regio Gennep had Glasnet wel problemen, dus daar geen redundantie?

[JohDB]

Jef61 schreef op donderdag 23 april 2026 @ 11:21:
[...]

Ik vraag me af of dit een ODF of provider probleem is. Het lijkt me dat er voldoende glas ligt om redundantie te realiseren, maar misschien voert een provider dit vanwege kosten niet (overal) uit?

Gisterenmiddag lag hier in Cuijk Netrebel eruit, maar ik begrijp dat Glasnet dankzij redundantie wel bleef werken.

In de regio Gennep had Glasnet wel problemen, dus daar geen redundantie?

De genoemde netwerken hebben zeker een mogelijkheid voor redundantie op de backhaulroutes. De operator moet dan wel zelf daarvoor de juiste backhaulroutes huren, deze worden door ODF niet kosteloos ter beschikking gesteld.

[Mari_eu]

JohDB schreef op donderdag 23 april 2026 @ 11:58:
[...]


De genoemde netwerken hebben zeker een mogelijkheid voor redundantie op de backhaulroutes. De operator moet dan wel zelf daarvoor de juiste backhaulroutes huren, deze worden door ODF niet kosteloos ter beschikking gesteld.

Met operator bedoel je providers? Zo ja dan mogen we dus aannemen dat Glasnet en Netrebel in dit geval hier geen gebruik van maken.

[EWS99]

Consumentenlijnen hebben vaak geen SLA en maar een minimale vergoeding bij storingen.
Rekenvoorbeeld: Als 2500 klanten er een dag uit liggen en de vergoeding is 2 euro per dag, dan kost een verstoring 5000,- per dag. Denk niet dat je voor dat bedrag een extra redundante vezel aan kunt leggen…

[JohDB]

Mari_eu schreef op donderdag 23 april 2026 @ 12:45:
[...]

Met operator bedoel je providers? Zo ja dan mogen we dus aannemen dat Glasnet en Netrebel in dit geval hier geen gebruik van maken.

Een provider maakt gebruik van een operator welke de apparatuur in de POP heeft hangen. Een provider kan ook een operator zijn, maar dit hoeft niet.

Glasnet en Netrebel zijn beide ook operator. Er zijn ook operators welke voor meerdere providers het netwerk faciliteren.

[iMode]

JanW schreef op donderdag 23 april 2026 @ 10:10:
Ik loop nu met deze storing wel tegen een bijzonder probleem aan. Ik las hier dat de verbinding weer terug is, maar hier geeft mijn Fritzbox (FRITZ!Box 5530 Fiber) nog aan dat er geen glasvezel verbinding actief is en dat de SPF module (FS BiDi LX SFP-GE-BX) niet wordt ondersteund. Ik moet dan de router herstarten en dan komt de verbinding weer op. Herkennen mensen dit probleem?

Heb ik ook, heel irritant.. soms moet de stekker er wel 2x in en uit.

[XallaX]

JanW schreef op donderdag 23 april 2026 @ 10:10:
Ik loop nu met deze storing wel tegen een bijzonder probleem aan. Ik las hier dat de verbinding weer terug is, maar hier geeft mijn Fritzbox (FRITZ!Box 5530 Fiber) nog aan dat er geen glasvezel verbinding actief is en dat de SFP module (FS BiDi LX SFP-GE-BX) niet wordt ondersteund. Ik moet dan de router herstarten en dan komt de verbinding weer op. Herkennen mensen dit probleem?

Heeft je Fritz auto update aan staan? Uitzetten!

Fritzboxen 5530 en 5590 herkennen na een (auto)update de SFP module meestal niet.
Dan blijft de box offline tot een 2e herstart of soms is zelfs een power cycle nodig.
(Probleem is gemeld bij AVM begin vorig jaar.)

opm: laatste Fritz 5590 Lab 8.24-131382 BETA is het nog niet in opgelost.

[ Voor 4% gewijzigd door XallaX op 24-04-2026 16:14 ]

[__Dennis__]

De kabelbreuk van afgelopen woensdag was in Beugen. Ik verbaas me wel over hoe ondiep de kabels daar liggen en zo dicht op een landbouw erf. Beetje diep ploegen en....

[Spekkie99]

Zeker, en vind de juiste plek dan ook maar eens....

[ardvark99]

Dat kunnen ze redelijk meten. Maar ik vermoed dat de uitvoerder lui is geweest (kosten), en niet dieper heeft gegraven dan is afgesproken. Ik heb dat wel vaker gehoord...

[Mari_eu]

Zou me niet verbazen dat de aannemer die het aangelegd heeft dezelfde is als degene die het nu hersteld heeft, SPIE.

[sigio]

Tja, hoe vaker je 't moet repareren, hoe vaker je kan factureren....

Raar dat de fiber daar tussen fietspad en akker ligt, en niet tussen fietspad en straat (lijkt me 'veiliger')

[ Voor 45% gewijzigd door sigio op 24-04-2026 12:23 ]

[ardvark99]

Spie is misschien de hoofdaannemer, en voor aanleg wss een andere partij geregeld, onderhoud doen ze daarna zelf.
En je zou idd verwachten dat ze de kabels naast het fietspad leggen, in (onder) het gras, en niet in een akker. Maar ik weet niet wat er verder in de grond ligt.
Maar ben benieuwd, nou is het gerepareerd en volgend jaar wordt het akker weer omgeploegd...

[iMode]

Spekkie99 schreef op vrijdag 24 april 2026 @ 11:43:
Zeker, en vind de juiste plek dan ook maar eens....

Is op de meter nauwkeurig te zeggen met de OTDR, ik was vroeger meettechnicus, 1e glasvezel monteur, later uitvoerder en projectleider.

[iMode]

sigio schreef op vrijdag 24 april 2026 @ 12:22:
Tja, hoe vaker je 't moet repareren, hoe vaker je kan factureren....

Raar dat de fiber daar tussen fietspad en akker ligt, en niet tussen fietspad en straat (lijkt me 'veiliger')

Ja idd, normaal ligt het daar niet.. en ook veel te ondiep..

[iMode]

XallaX schreef op vrijdag 24 april 2026 @ 09:54:
[...]

Heeft je Fritz auto update aan staan? Uitzetten!

Fritzboxen 5530 en 5590 herkennen na een (auto)update de SFP module meestal niet.
Dan blijft de box offline tot een 2e herstart of soms is zelfs een power cycle nodig.
(Probleem is gemeld bij AVM begin vorig jaar.)

Thnx! Ga ik eens naar kijken, idd vorige keer ook een update geweest en vervolgens geen internet meer..

[bundit]

Is er hier toevallig iemand die gebruik maakt van een mikrotik (RouterOS 7.x) I.c.m. TV via Glasnet?

Mijn ouders hebben momenteel een fritzbox 5530 in gebruik, maar ervaren regelmatig problemen met TV, denk aan blokjes en stotterend beeld. Ik vermoed dat multicast/IGMP snooping op de Fritzbox ergens niet lekker werkt. Thuis heb ik Glasnet internet only via een Mikrotik. Gezien ik nog één mikrotik heb liggen wil ik eens proberen of het hiermee wel lukt om het tv signaal soepel te laten werken. Naast de fritzbox zijn er geen andere apparaten die iets met igmp snooping doen, of andere switches. De TV decoder zit rechtstreeks op de fritzbox aangesloten.

Op de website van Glasnet heb ik de volgende informatie gevonden, welke waarschijnlijk geschreven lijkt voor een Draytek.

quote: https://glasnet.nl/netwer...llatieschema#instellingen

Televisie:

• - Ga naar je WAN instellingen en activeer Channel 5 op de Multi VLAN
• - Gebruik VLAN tag: 37
• - Zet de WAN open voor IPTV
• - WAN IP Netwerk instellingen: Obtain automatically by DHCP
• - Maak het volgende IP object aan:
• - Interface: any
• - Address Type: Single address
• - Start IP address: 185.24.175.211, Voeg deze samen tot een IP groep
• - Maak een nieuwe route policy aan:
• - Verwijs hier naar de IP group die je net hebt aangemaakt
• - Verwijs naar de WAN (channel 5)
• - Gebruik default gateway
• - Force NAT
• - Activeer ALG (onder NAT)
• - RTSP op poort 554 (TCP & UDP geactiveerd)
• IGMP instellingen
• - Activeer IGMP Proxy & IGMP Snooping

Als ik dit zo lees dien ik een extra vlan op de wan interface te maken, vlan37. Vervolgens hier met dhcp client een lease aan te vragen en de default route wegschrijven in een custom routing table. Dan een routing mark (policy route) maken voor het specifieke subnet zodat deze via vlan37 naar Glasnet verloopt. Vervolgens uitgaand nat met het IP van vlan37. Al het andere verkeer van de decoder moet beschouwd worden als regulier internet verkeer. Tot slot nog een igmp proxy toevoegen en dan zou het moeten werken. De tv decoder komt dan op een bridge waar igmp snooping op ingeschakeld staat.

Ik heb alleen geen idee wat er bedoeld wordt met:

Ga naar je WAN instellingen en activeer Channel 5 op de Multi VLAN

Het resultaat zal ik hier uiteraard delen als het gelukt is. Mocht iemand de magische fix weten voor een fritzbox dan is die uiteraard ook welkom. Ik heb hierbij al geprobeerd de interface op 100 Mb/s terug te zetten en de decoder als high priority device aan te markeren. Dit heeft uiteindelijk nog niet geholpen.

[FearMe]

@bundit Mijn ouders hadden hetzelfde probleem bij de overstap naar Tweak, en zijn sindsdien overgestapt naar NLZiet. Ik heb het lang proberen te troubleshooten (ook in opnsense) maar ben nooit echt verder gekomen.

Wellicht interessant: de mediabox van Tweak(Amino Aria 700, ook CANAL+) werkte foutloos op de KPN VDSL verbinding die een tijdje overlap had met de Tweak glasvezel verbinding. Ik kan me niet herinneren of ik hiervoor enkel de FRITZ!Box van KPN gebruikte, of ook de 5530 van Tweak, met de KPN-router as modem.
Geen flauw idee hoe dat ooit kon werken, aangezien het normaal een boel speciale instellingen vergt.

Mocht je overigens iets vinden ben ik ook geïnteresseerd. Als ik zie hoe mijn vader die app 'bedient' denk ik dat ze het niet erg vinden om terug te gaan naar een afstandsbediening.

[aartvg]

Bij Mikrotik is het best eenvoudig om IPTV werkend te krijgen via multicast.

Maak VLAN 37 aan op de WAN-interface (meestal sfp1 of andere interface):

code:

/interface vlan
add interface=sfp1 name=vlan37-iptv vlan-id=37

Voeg een DHCP-client toe zonder default route en DNS:

code:

/ip dhcp-client
add interface=vlan37-iptv add-default-route=no use-peer-dns=no

Configureer IGMP Proxy:

code:

/routing igmp-proxy
set quick-leave=yes

/routing igmp-proxy interface
add interface=vlan37-iptv upstream=yes
add interface=bridge

Sta IGMP-verkeer toe in de firewall:

code:

/ip firewall filter
add chain=input protocol=igmp action=accept
add chain=forward protocol=igmp action=accept

Na deze configuratie zijn multicast IPTV-streams beschikbaar op het LAN.

Eventueel zet op je bridge igmp snooping aan en enable versie 2.

De verdere data mag gewoon lopen over je internet vlan.

[MMaster23]

Geen verbinding regio Den Bosch <> Oss

16:23: Weer online

[ Voor 22% gewijzigd door MMaster23 op 02-06-2026 16:24 ]

[lolgast]

Ik zit in Oss, hier is alles nog online

[KraveN]

Regio 6596 lijkt down, storing lijkt groter aldus het bandje van Glasnet. Kreeg ook niemand te pakken (waarschijnlijk ivm drukte).

Staat nu ook op de website :

https://glasnet.nl/meldingen

02-06-2026, 12:00

We zien dat er storing is in regio Noord-Brabant en Limburg. We zijn het aan het onderzoeken en hopen u snel van updates te kunnen voorzien.

[ Voor 57% gewijzigd door KraveN op 02-06-2026 16:19 ]

[jasjenl]

Hier ook geen verbinding postcode 5846…

[WallyPower]

Grave, 5361, ook geen internet

[bvh_]

Hier ook geen verbinding, glasnet website lijkt ook down?

[aapjuh99]

Jongens, wie heeft er nu weer een schep in de grond gezet? (Cuijk, 5431)

[jasjenl]

Hier doet ie het inmiddels weer, maar wel nog af en toe wat haperend zo lijkt...

[aapjuh99]

jasjenl schreef op dinsdag 2 juni 2026 @ 16:23:
Hier doet ie het inmiddels weer, maar wel nog af en toe wat haperend zo lijkt...

Hier ook!

[Sjaak_Afhaak]

Om heel eerlijk te zijn, gebeurt het de laatste maanden best wel vaak. Hier veel thuiswerk, dus het begint op te vallen. Kan ik zoiets loggen met m'n unifi netwerk?

[mr-schultzz]

Hier in Heesch ligt nog alles plat..

Na interventie van AartvG alles weer stabiel online

[ Voor 43% gewijzigd door mr-schultzz op 02-06-2026 18:59 ]

[bundit]

aartvg schreef op dinsdag 2 juni 2026 @ 09:27:
Bij Mikrotik is het best eenvoudig om IPTV werkend te krijgen via multicast.

Maak VLAN 37 aan op de WAN-interface (meestal sfp1 of andere interface):

code:

/interface vlan
add interface=sfp1 name=vlan37-iptv vlan-id=37

Voeg een DHCP-client toe zonder default route en DNS:

code:

/ip dhcp-client
add interface=vlan37-iptv add-default-route=no use-peer-dns=no

Configureer IGMP Proxy:

code:

/routing igmp-proxy
set quick-leave=yes

/routing igmp-proxy interface
add interface=vlan37-iptv upstream=yes
add interface=bridge

Sta IGMP-verkeer toe in de firewall:

code:

/ip firewall filter
add chain=input protocol=igmp action=accept
add chain=forward protocol=igmp action=accept

Na deze configuratie zijn multicast IPTV-streams beschikbaar op het LAN.

Eventueel zet op je bridge igmp snooping aan en enable versie 2.

De verdere data mag gewoon lopen over je internet vlan.

Ik ben nog bezig met de configuratie, al lijkt de basis nu wel te werken. Er zijn al veel minder haperingen c.q. stilstaande beelden. Maar toch komt er elke 5 minuten heel even een stilstaand beeld voor, soms meerdere tegelijk. Audio loopt tot op heden wel altijd door.

Ik heb naast bovenstaande configuratie nog een paar extra configuraties moeten maken, vlan139 is mijn interne vlan waar de tv decoder (Amino) op aangesloten zit (rechtstreeks op de Mikrotik).

alternative-subnets=0.0.0.0/0 moest ik toevoegen aan de igmp upstream. Zonder de alternative-subnet mee te geven ging de TV niet werken.

code:

/routing igmp-proxy interface
add alternative-subnets=0.0.0.0/0 interface=vlan37-iptv upstream=yes
add interface=vlan139-tv

De IGMP input regel hit sporadisch een pakketje, maar de forward totaal niet. Deze 2 regels heb ik nog toegevoegd. De input vlan37-iptv hit volgens de counters z'n beetje elk tv pakketje.

code:

/routing igmp-proxy interface
add action=accept chain=input in-interface=vlan37-iptv
add action=accept chain=input in-interface=vlan139-tv

IGMP snooping op de bridge staat niet geactiveerd gezien dan hardware offload van de gehele bridge dan niet meer werkt. Echter lijken de streams wel netjes te stoppen bij het zappen, al kan dat ook komen doordat het niet echt multicast lijkt te zijn i.v.m. ontbreken IGMP forward verkeer. Het vreemde is wel dat de IGMP proxy wel een heleboel packets laat zien. Ik heb het idee dat de Mikrotik het IGMP verkeer wat binnenkomt als UDP behandeld omdat het dit als proxy door moet zetten. Echter is dat tegenstrijdig met de configuratie van aartvg. Zie ik iets over het hoofd, of is dit wellicht per netwerk nog verschillend? Hier gaat het via ODF.

Ik zie geen interface errors voor de Amino, vlan37 en sfp interface. Kan het zijn dat er zo af en toe een paar pakketjes missen vanuit Glasnet/Canal Digitaal? Of dien ik nog verder te troubleshooten?

[ Voor 0% gewijzigd door bundit op 05-06-2026 21:53 . Reden: Amino i.p.v. Animo ]

[FearMe]

Wat ik me ook kan herinneren is dat de streams/amino boxes een absurd lage buffer hebben, en dat problemen met haperen opgelost zijn als je een paar seconden pauzeert en daarna normaal verder kijkt.

[Flappie]

Delta Fiber glasvezel gebruiker hier :)
Mijn contract loopt eind dit jaar af en ben al een beetje aan het rondkijken. Verlengingsaanbod van Delta is niet echt overtuigend. Vind de klantenservice ook erg slecht en heb steeds foute facturen.

Glasnet levert dus hier via het Delta netwerk. Maar ik vraag mij af hoe dat precies werkt? Is er ergens een punt in het Delta netwerk waar Glasnet aankoppelt? Want volgens mjj gaat het grootendeels over de Delta infrastructuur?

Iemand die eens kan vertellen hoe dit precies zit en tot waar ik via het Delta netwerk ga en het doorgeeft punt is naar Glasnet?

Woon in Oldenzaal trouwens.

[aartvg]

Flappie schreef op woensdag 10 juni 2026 @ 21:50:

Iemand die eens kan vertellen hoe dit precies zit en tot waar ik via het Delta netwerk ga en het doorgeeft punt is naar Glasnet?

Ik kan je hier alles over vertellen wij hebben 2 koppelingen met het Delta netwerk in Amsterdam (Equinix AM3 en Digital Realty AMS9)

Vanaf Oldenzaal maak je dus gebruik van het Delta netwerk tot Amsterdam. Vanaf de koppeling maak je volledig gebruik van ons netwerk. Zit je al op het xgspon netwerk van Delta?

Wil je meer weten laat het gerust weten!

[Flappie]

aartvg schreef op woensdag 10 juni 2026 @ 22:58:
[...]

Ik kan je hier alles over vertellen wij hebben 2 koppelingen met het Delta netwerk in Amsterdam (Equinix AM3 en Digital Realty AMS9)

Vanaf Oldenzaal maak je dus gebruik van het Delta netwerk tot Amsterdam. Vanaf de koppeling maak je volledig gebruik van ons netwerk. Zit je al op het xgspon netwerk van Delta?

Wil je meer weten laat het gerust weten!

Sinds vorig jaar op XGS-PON. Dat heeft Delta toen behoorlijk verkloot waarna ik meer dan een week zonder internet heb gezeten. Dat was rond kerst en blijkbaar was er niemand van Cogas (die hier blijkbaar glasvezel beheerd) beschikbaar om het op te lossen.
Uiteindelijk bleek dat ze me hadden "omgeprik" en daarbij de connector hebben afgebroken in de centrale. Nu steeds die foutieve facturen waar de verrekening van de korting niet klopt. En het meegeleverde modem wat niet eens in bridge mode kan en dan ook nog eens standaard CGNAT (ja dat kan uit, dat weet ik).

Moet het nog even uitzitten tot eind dit jaar en dan kom ik naar Glasnet
Lekker vast IPv4 en IPv6 adres en een partij die open is over zaken. Ik maakt tegenwoordig meer bewuste keuzes dan met de massa mee te gaan

[ Voor 6% gewijzigd door Flappie op 11-06-2026 09:19 ]

[bundit]

bundit schreef op vrijdag 5 juni 2026 @ 21:52:
[...]

Ik ben nog bezig met de configuratie, al lijkt de basis nu wel te werken. Er zijn al veel minder haperingen c.q. stilstaande beelden. Maar toch komt er elke 5 minuten heel even een stilstaand beeld voor, soms meerdere tegelijk. Audio loopt tot op heden wel altijd door.

Ik heb naast bovenstaande configuratie nog een paar extra configuraties moeten maken, vlan139 is mijn interne vlan waar de tv decoder (Amino) op aangesloten zit (rechtstreeks op de Mikrotik).

alternative-subnets=0.0.0.0/0 moest ik toevoegen aan de igmp upstream. Zonder de alternative-subnet mee te geven ging de TV niet werken.

code:

/routing igmp-proxy interface
add alternative-subnets=0.0.0.0/0 interface=vlan37-iptv upstream=yes
add interface=vlan139-tv

De IGMP input regel hit sporadisch een pakketje, maar de forward totaal niet. Deze 2 regels heb ik nog toegevoegd. De input vlan37-iptv hit volgens de counters z'n beetje elk tv pakketje.

code:

/routing igmp-proxy interface
add action=accept chain=input in-interface=vlan37-iptv
add action=accept chain=input in-interface=vlan139-tv

IGMP snooping op de bridge staat niet geactiveerd gezien dan hardware offload van de gehele bridge dan niet meer werkt. Echter lijken de streams wel netjes te stoppen bij het zappen, al kan dat ook komen doordat het niet echt multicast lijkt te zijn i.v.m. ontbreken IGMP forward verkeer. Het vreemde is wel dat de IGMP proxy wel een heleboel packets laat zien. Ik heb het idee dat de Mikrotik het IGMP verkeer wat binnenkomt als UDP behandeld omdat het dit als proxy door moet zetten. Echter is dat tegenstrijdig met de configuratie van aartvg. Zie ik iets over het hoofd, of is dit wellicht per netwerk nog verschillend? Hier gaat het via ODF.

Ik zie geen interface errors voor de Amino, vlan37 en sfp interface. Kan het zijn dat er zo af en toe een paar pakketjes missen vanuit Glasnet/Canal Digitaal? Of dien ik nog verder te troubleshooten?

@aartvg Ik zie in de IGMP proxy ook source IP-adressen die buiten mijn lokale subnet vallen. Ik verwacht dat deze van andere klanten zijn die zelf IGMP querier o.i.d. geactiveerd hebben en problemen met de IGMP stream bij mij veroorzaken. Bijvoorbeeld 192.168.178.1 is source address van 224.0.0.1, evenals verschillende 10.15.0.0/16 adressen. De IGMP 192.168.178.1 pakketten komen untagged binnen op de SFP interface. Dus maken geen deel uit van de PPPoE sessie of vlan37.

Wat zijn de IP-adressen/subnets waarvan Glasnet/Canaal Digitaal de IGMP streams verstuurd? Dan kan ik de incorrecte IP-adressen blokkeren en voorkom ik hopelijk dat de TV weer normaal gaat werken. Het lijkt overdag beter te gaan, maar de avonden kun je de TV net zo goed uitlaten. De Canaal digitaal IP adressen/subnets wil ik dan op de Mikrotik toevoegen bij alternative subnets voor de IGMP proxy.


Update 16:10
Ik heb na wat debugen van packet captures 2 firewall regels toegevoegd aan de mikrotik:

code:

/ip firewall raw
add action=drop chain=prerouting in-interface=sfp-sfpplus1

/ipv6 firewall raw
add action=drop chain=prerouting in-interface=sfp-sfpplus1

Hierna heb ik de Mikrotik herstart zodat ik zeker weet dat er geen oude IGMP data in de cache zit. De TV werkt nu weer stabiel, zonder haperingen en blokjes. Het is nog even afwachten wat het doet op langere termijn, maar voorheen was niet mogelijk om langer dan 5 minuten te kijken zonder blokjes of haperingen.

Misschien is het een idee dat Glasnet een input ACL op alle klantpoorten configureerd zodat al het untagged IPv4/IPv6 verkeer vanuit een klant altijd gedropt wordt. PPPoE valt niet onder IP verkeer dus deze gaat door. Met de FritzBox had ik namelijk ook spontaan haperingen en blokjes bij TV, echter heb ik hier niet de optie om al het untagged verkeer te droppen.

De volgende vraag is nu alleen hoe lang het gaat duren voordat er op vlan37 ook ruis van andere klanten binnenkomt en het multicast signaal alsnog verstoord wordt...

[ Voor 17% gewijzigd door bundit op 12-06-2026 16:35 . Reden: Toevoeging source interface van IGMP tbv 192.168.178.1 ]

[Escrimador]

goedemorgen op deze zonnige zondag

Ik loop al een tijdje tegen iets aan en ben benieuwd of dit herkenbaar is of al eerder voorbij is gekomen.

Ik zit op GlasNet (Hoeksche Waard) met PPPoE, gebruik OPNsense (business licentie) als router en heb intermittente verbindingsproblemen, specifiek met diensten die een langdurige HTTPS/WebSocket verbinding openhouden. YouTube en gewoon browsen werken prima — dat buffert genoeg om het niet op te merken? - maar diensten die een persistente verbinding openhouden verbreken regelmatig de sessie. Onlangs weer heel veel problemen bij het versturen van Claude prompts, zowel tekst als plaatjes.

Na flink wat uitzoekwerk heb ik denk ik lokale oorzaken kunnen uitsluiten:

• Ping naar lokale gateway: stabiel, 0% loss
• PPPoE sessie: al 10+ dagen ononderbroken uptime
• Ping naar 8.8.8.8: stabiel, 0% loss, ~4ms

Maar zodra ik naar een Cloudflare-adres ping, zie ik 0,4% pakketverlies. En de traceroute laat zien waar dat zit:

code:

1  [lokale gateway]       ~1ms
2  * * *                  
3  100.65.1.14            ~4-5ms   
4  80.249.210.118         wisselend pakketverlies?
5  141.101.65.28          wisselend idem?
6  141.101.65.139         ~5-6ms   Cloudflare 
7  [bestemming]           ~4ms

Het verlies zit dus specifiek op het pad tussen het GlasNet backbone en het Cloudflare netwerk via IPv4. Ik zie dat @evharten in maart een vergelijkbaar routeringsprobleem heeft opgelost (hogere latency via de redundante crossconnect) en in dezelfde maand ook IPv6 routeringsproblemen richting Cloudflare heeft gecorrigeerd. Dit voelt als iets soortgelijks maar dan voor IPv4 pakketverlies.

Herkent iemand dit?

[stormfly]

Escrimador schreef op zondag 14 juni 2026 @ 11:50:
goedemorgen op deze zonnige zondag

Ik loop al een tijdje tegen iets aan en ben benieuwd of dit herkenbaar is of al eerder voorbij is gekomen.

Ik zit op GlasNet (Hoeksche Waard) met PPPoE, gebruik OPNsense (business licentie) als router en heb intermittente verbindingsproblemen, specifiek met diensten die een langdurige HTTPS/WebSocket verbinding openhouden. YouTube en gewoon browsen werken prima — dat buffert genoeg om het niet op te merken? - maar diensten die een persistente verbinding openhouden verbreken regelmatig de sessie. Onlangs weer heel veel problemen bij het versturen van Claude prompts, zowel tekst als plaatjes.

Na flink wat uitzoekwerk heb ik denk ik lokale oorzaken kunnen uitsluiten:

• Ping naar lokale gateway: stabiel, 0% loss
• PPPoE sessie: al 10+ dagen ononderbroken uptime
• Ping naar 8.8.8.8: stabiel, 0% loss, ~4ms

Maar zodra ik naar een Cloudflare-adres ping, zie ik 0,4% pakketverlies. En de traceroute laat zien waar dat zit:

code:

1  [lokale gateway]       ~1ms
2  * * *                  
3  100.65.1.14            ~4-5ms   
4  80.249.210.118         wisselend pakketverlies?
5  141.101.65.28          wisselend idem?
6  141.101.65.139         ~5-6ms   Cloudflare 
7  [bestemming]           ~4ms

Het verlies zit dus specifiek op het pad tussen het GlasNet backbone en het Cloudflare netwerk via IPv4. Ik zie dat @evharten in maart een vergelijkbaar routeringsprobleem heeft opgelost (hogere latency via de redundante crossconnect) en in dezelfde maand ook IPv6 routeringsproblemen richting Cloudflare heeft gecorrigeerd. Dit voelt als iets soortgelijks maar dan voor IPv4 pakketverlies.

Herkent iemand dit?

https://globalping.io kan je ook nog gebruiken als je even je AS nummer opzoekt op bgp.he.net kan je die als bron gebruiken en kan je kijken of het breder gedragen is binnen het glasnet netwerk. Ik weet niet of je tag naar @evharten helemaal door kwam in de opmaak.

[Escrimador]

dank je, heb ik gedaan.

stapte tijdens de lunch even over naar m'n laptop en had geen enkele onderbreking terwijl op mijn MacStudio echt 1-2x per 10 prompts. Ben toch bang dat het aan mijn kant zit inmiddels...


https://globalping.io?measurement=2CfWH9XVuTrz5BUEi00020ZtV

https://globalping.io?measurement=2aoxJ3fIF6XwydEKq00020ZtW

ik verdenk mijn browser nu eigenlijk (Safari vs Edge)

[ Voor 5% gewijzigd door Escrimador op 14-06-2026 15:01 ]

[aartvg]

bundit schreef op vrijdag 12 juni 2026 @ 11:36:
[...]

@aartvg

Je bent lekker aan het onderzoeken geweest. IGMP / Multikas is een lastig ding kan ik je vertellen.

We hebben wat issues met multicast, We denken dat het aan Canal+ ligt maar hun denken van niet

Via vipe code heb ik een IGMP monitoring tootle gemaakt wat kan draaien op docker of een mikrotik met docker enabled.

aartvg/IGMP-RTP-monitoring

Wie heeft er iets van docker draaien of een Mikrotik en wil mij helpen met statistieken?

Voor op docker waarbij je netwerk interface ens35 heet, check dit via ip add:

wget https://github.com/aartvg/IGMP-RTP-monitoring/raw/refs/heads/main/igmp-rtp-monitor-amd64.tar
docker load -i igmp-rtp-monitor-amd64.tar
docker run --rm --network host -e CONFIG_URL="https://aart.blackgate.nl/rtp/igmp-monitor-config.json" -e IGMP_VERSION="2" -e INTERFACE="ens35" igmp-rtp-monitor:amd64

voor op mikrotik (Als je container support aan heb staan of aan kan zetten.):

download https://github.com/aartvg/IGMP-RTP-monitoring/raw/refs/heads/main/igmp-rtp-monitor-armv7-mikrotik.tar en upload deze naar je mikrotik

/interface veth
add address=192.168.77.2/24 container-mac-address=6C:42:1F:A8:CD:9F dhcp=no     gateway=192.168.77.1 gateway6="" mac-address=6C:42:1F:A8:CD:9F name=igmp-monitor

/container
add dns=1.1.1.1 envlists=ENV_IGMP_MONITOR file=igmp-rtp-monitor-armv7-mikrotik.tar interface=igmp-monitor layer-dir=""name=igmp-rtp-monitor root-dir=/igmp-rtp-monitor start-on-boot=yes workdir=/ 
/container envs
add key=CHANNELS list=ENV_IGMP_MONITOR value=NPO1,NPO2
add key=CONFIG_URL list=ENV_IGMP_MONITOR value=    https://aart.blackgate.nl/rtp/igmp-monitor-config.json
add key=IGMP_VERSION list=ENV_IGMP_MONITOR value=2

Je hebt uiteraard een IGMP proxy nodig deze is standaard actief bij de Glasnet configs in Fritzboxen of Drayteks. Helaas kan ik niet bij elke klant helpen deze werkend te krijgen.

je kan als de monitoring tool draait naar het ip van de docker desktop op port 80 draait een eenvoudige webserver met grafiekjes.

[ Voor 3% gewijzigd door aartvg op 15-06-2026 10:18 ]

[bundit]

Helaas heeft mijn mikrotik (RB4011) geen usb poort. Hier wil ik dus ook geen docker op draaien omdat de interne storage hier niet voor bedoelt is qua schrijf operaties.

Welke data wil je hebben? Wellicht kan ik iets via syslog naar een vm sturen om toch de juiste data voor je te verzamelen….

Even uit mijn hoofd had ik een 0,2s follow lopen met

code:

/routing igmp-proxy mfc print

, op het moment van een hapering of blokjes zag ik dan een extra/meerdere source IPs die verkeer naar hetzelfde multicast adres versturen. Ik had dus het vermoeden dat Canal+ dezelfde multicast stream vanaf een andere server verstuurd vanwege load balancing o.i.d. en hier een klein verschil in stream data zit wat de blokjes veroorzaakt.

Echter ben ik hier nog mee aan het debuggen om dit beter te begrijpen. De ene avond gaat het storingsvrij, de andere heb je iets meer last van blokjes. Al is het grootste verschil in kwaliteit opgelost door untagged IP verkeer te blokkeren vanaf Glasnet. Waarschijnlijk zijn er klanten waarbij multicast verkeer untagged terug loopt richting Glasnet en die vervolgens de IGMP stream in de war schopt met beeld van een paar seconden geleden. Echter blijft dit voor mij nog een gedachtespinsel gezien ik nog geen volledige capture heb gemaakt om te vergelijken.

[DrNizeGuy]

@aartvg ik wil best je docker op m'n server alhier draaien maar ik kijk canal+ via de app op de teevee, daar zal je dan weinig aan hebben gok ik

[bundit]

Ik heb de container van @aartvg inmiddels operationeel.
Hij heeft een privé bericht ontvangen over hoe hij deze statistieken nu kan inzien.

[Biite]

Ik vermoed dat er momenteel serieus wat aan de hand is bij Glasnet:

• Verbinding via glasnet ligt eruit (postcode 3151). Loopt via DFN netwerk bij mij en de lampjes branden allemaal groen, dus lijkt niet fysiek. Meldingen over pppoe authenticatie in de log van mijn router.
  Lang leve de failover via Odido Klik&Klaar nu
• glasnet.nl website onbereikbaar momenteel
• De helpdesk is druk, ben niet gewend om 10 minuten in de wacht te staan...

Anyway, ik wacht even af momenteel, gelukkig een stand-by verbinding dus het werk kan gewoon door.

[Quas]

Glasnet website is offline door verhuizing van server infra.

Ik dacht dat dit redundant naar het andere cluster zou gaan. Maar er is gekozen dat niet om te zetten. Excuus.


Ik ga even kijken wat ik zie op je postcode.

[Biite]

Quas schreef op vrijdag 19 juni 2026 @ 11:23:
Glasnet website is offline door verhuizing van server infra.

Ik ga even kijken wat ik zie op je postcode.

Dat verklaart een hoop, mocht je meer gegevens nodig hebben van me, stuur maar direct bericht

[Quas]

Biite schreef op vrijdag 19 juni 2026 @ 11:30:
[...]

Dat verklaart een hoop, mocht je meer gegevens nodig hebben van me, stuur maar direct bericht

Het is gefixt! Excuus. 1 van de 2 nodes voor auth had het niet goed overgenomen. Impact was 10 klanten. Jij was er 1 van ;)

Sorry!

[Biite]

Nice, snelle fix zo! Thanks.

[Streamert]

Glasnet website is uit de lucht.

[aartvg]

Ons k8s platform was niet even eenvoudig te verhuizen tussen DC's. de rest draaide allemaal door als goed is.

Een paar niet kritische dingen die we in Kubernetes draaide moesten even uit waaronder de Glasnet website.

Daag Eunetworks, Hallo NorthC :)

[Hotsoup]

Hi Allen,

Sinds woensdag ben ik over van Odido naar Glasnet (Reggefiber - KPN). Over Glasnet zelf qua support en kunde heb ik weinig tot niks te klagen, maar sinds de overstap loop ik tegen een paar dingen aan en ik ben benieuwd of iemand hier hetzelfde heeft gehad.

Voor context, mijn router is een Lenovo M920Q met een Intel X520 netwerkkaart (alle offloading staat uit).

Bij Odido heb ik goed gebruik kunnen maken van mijn Zaram XGS-PON ONT. Gelijk bij Glasnet dezelfde keuze gemaakt om op XGS te blijven, serienummer doorgegeven en... niks. Mijn PADI's gaan wel netjes de deur uit op VLAN 6, maar ik kreeg nul reactie (geen PADO) terug. Pas met een Nokia XGS-PON ONT werd de lijn geprovisioned en kwam de boel op.

Heeft iemand een third-party stick (Zaram of vergelijkbaar) wel werkend gekregen op Glasnet/KPN-infra, ondanks dat-ie geregistreerd is?

Tweede en grootste ding is de PPPoE-login. Uit een capture bleek dat de verbinding niet rond komt door de manier waarop de inlog wordt afgehandeld. De BNG vraagt eerst om de ene loginmethode (PAP), OPNsense gaat daarin mee (CHAP, PAP en EAP staan als accepted), en dan schakelt de BNG halverwege ineens over naar een andere methode (CHAP). Daar loopt OPNsense (mpd5) op vast en de login komt nooit af.

Voor de zekerheid een reserve UniFi Cloud Gateway Max opgehangen aan de Nokia ONT, en daar komt alles wel meteen online met exact dezelfde lijn en inloggegevens. Dus het lijkt echt iets tussen OPNsense (mpd5) en deze BNG te zijn.

Is iemand hier toevallig al eens eerder tegenaan gelopen, en zo ja, wat is de mogelijke oplossing? Eventuele troubleshootstappen verneem ik al te graag

[ernstoud]

Hotsoup schreef op zaterdag 20 juni 2026 @ 00:06:
Heeft iemand een third-party stick (Zaram of vergelijkbaar) wel werkend gekregen op Glasnet/KPN-infra, ondanks dat-ie geregistreerd is?

Hoe oud is de Zaram SFP? Ik denk nl. dat de speciaal voor KPN aangepaste firmware (versie V090 - ook geschikt voor Delta) er niet op draait. Waar heb je hem gekocht indertijd?

Zo te lezen ben je denk ik in staat deze zelf te updaten. Stuur met even een PB dan stuur ik je de link naar firmware en instructie.

[ Voor 19% gewijzigd door ernstoud op 20-06-2026 11:29 ]

[Hotsoup]

ernstoud schreef op zaterdag 20 juni 2026 @ 10:46:
[...]


Hoe oud is de Zaram SFP? Ik denk nl. dat de speciaal voor KPN aangepaste firmware (versie V090 - ook geschikt voor Delta) er niet op draait. Waar heb je hem gekocht indertijd?

Zo te lezen ben je denk ik in staat deze zelf te updaten. Stuur met even een PB dan stuur ik je de link naar firmware en instructie.

De Zaram module heb ik crica 10 maanden geleden aangeschaft bij Wimood.

Vanuit de Zaram module heb ik wel al eerder een env output gedraaid. Daar kwam helaas al de V090 naar voren:

board_revision=ZX300R03
equipment_id=ZXOS11NPI
vendor_product_code=0xffff
image0_version=ZR00_V090.08
image1_version=ZR00_V090.08
image0_product_code=ZXOS11NPI
image1_product_code=ZXOS11NPI

Of heb jij het toevallig over een nieuwere versie?

[ernstoud]

Hotsoup schreef op zaterdag 20 juni 2026 @ 15:08:
[...]

De Zaram module heb ik crica 10 maanden geleden aangeschaft bij Wimood.

Vanuit de Zaram module heb ik wel al eerder een env output gedraaid. Daar kwam helaas al de V090 naar voren:

board_revision=ZX300R03
equipment_id=ZXOS11NPI
vendor_product_code=0xffff
image0_version=ZR00_V090.08
image1_version=ZR00_V090.08
image0_product_code=ZXOS11NPI
image1_product_code=ZXOS11NPI

Of heb jij het toevallig over een nieuwere versie?

Nee, dat is dus al de goede versie. Recenter is er niet. Zou moeten werken op KPN en Delta.

Geen idee of Glasnet hetzelfde slot gebruikt op de OLT om de PPoE sessie uit te voeren. Dat moest aangepast worden naar ik meen slot 1 voor KPN.

[Hotsoup]

ernstoud schreef op zaterdag 20 juni 2026 @ 15:15:
[...]


Nee, dat is dus al de goede versie. Recenter is er niet. Zou moeten werken op KPN en Delta.

Geen idee of Glasnet hetzelfde slot gebruikt op de OLT om de PPoE sessie uit te voeren. Dat moest aangepast worden naar ik meen slot 1 voor KPN.

Voor de duidelijkheid, je bedoelt het slot/serviceprofiel op de OLT van KPN z'n infra toch? En is het dan logisch dat de Nokia XS-010X-Q die ik als test gebruik automatisch het juiste profiel krijgt omdat het een herkend model is, terwijl een eigen ONT zoals de Zaram dat profiel handmatig moet krijgen en er nu dus mogelijk naast valt?

[ernstoud]

Hotsoup schreef op zaterdag 20 juni 2026 @ 15:26:
[...]

Voor de duidelijkheid, je bedoelt het slot/serviceprofiel op de OLT van KPN z'n infra toch?

Inderdaad.

En is het dan logisch dat de Nokia XS-010X-Q die ik als test gebruik automatisch het juiste profiel krijgt omdat het een herkend model is, terwijl een eigen ONT zoals de Zaram dat profiel handmatig moet krijgen en er nu dus mogelijk naast valt?

Dat kan. Wellicht dat een Nokia ONT bij een PPoE sessie opzetten na een time-out een ander slot probeert? De KPN OLT is ook Nokia, zal net iets beter samenwerken denk ik.

In ieder geval moest voor KPN dat slot in de Zaram FW aangepast worden. Op de DFN infra draait een aanpassing in het OLT profiel dat de Zaram herkent en dan het juiste slot kiest. KPN wilde niet aan de OLT een aanpassing, dus moest dat in de Zaram.

Dat het nu op Glasnet niet werkt is dan bijzonder. Wellicht kan een Glasnet technicus hier eens aangeven hoe of wat.

Weet je zeker dat de Zaram goed geregistreerd is?

[Hotsoup]

ernstoud schreef op zaterdag 20 juni 2026 @ 15:41:
[...]


Inderdaad.


[...]


Dat kan. Wellicht dat een Nokia ONT bij een PPoE sessie opzetten na een time-out een ander slot probeert? De KPN OLT is ook Nokia, zal net iets beter samenwerken denk ik.

In ieder geval moest voor KPN dat slot in de Zaram FW aangepast worden. Op de DFN infra draait een aanpassing in het OLT profiel dat de Zaram herkent en dan het juiste slot kiest. KPN wilde niet aan de OLT een aanpassing, dus moest dat in de Zaram.

Dat het nu op Glasnet niet werkt is dan bijzonder. Wellicht kan een Glasnet technicus hier eens aangeven hoe of wat.

Weet je zeker dat de Zaram goed geregistreerd is?

Met support van Glasnet aan de lijn heb ik meermaals het ID van de Zaram meermaals gecontroleerd en opgevoerd (tijdens het testen met de Nokia). Volgens hen stond hij er correct in.

[ernstoud]

Hotsoup schreef op zaterdag 20 juni 2026 @ 16:25:
[...]

Met support van Glasnet aan de lijn heb ik meermaals het ID van de Zaram meermaals gecontroleerd en opgevoerd (tijdens het testen met de Nokia). Volgens hen stond hij er correct in.

ZRMTxxxxxxxx dus?

[Fiekert]

aankomende maandag ga ik over van KPN naar Glasnet, setup blijft verder gelijk, komt de PPPoE data hiermee ook maandag beschikbaar? of wordt dit zondag beschikbaar?

ik was iets te vroeg met de reactie, heb inmiddels de gegevens ontvangen.

[ Voor 19% gewijzigd door Fiekert op 20-06-2026 18:48 ]

[Hotsoup]

ernstoud schreef op zaterdag 20 juni 2026 @ 16:48:
[...]


ZRMTxxxxxxxx dus?

Correct, ZRMTxxxxxxx8 (uiteraard deels redacted).

[ernstoud]

Hotsoup schreef op zaterdag 20 juni 2026 @ 17:36:
[...]

Correct, ZRMTxxxxxxx8 (uiteraard deels redacted).

Tja, dan houdt mijn kennis wel op.

Wellicht heeft KPN voor Glasnet een eigen OLT profiel?

[aartvg]

Fiekert schreef op zaterdag 20 juni 2026 @ 16:51:
aankomende maandag ga ik over van KPN naar Glasnet, setup blijft verder gelijk, komt de PPPoE data hiermee ook maandag beschikbaar? of wordt dit zondag beschikbaar?

Deze is nu beschikbaar voor je in mijn Glasnet. Je hebt nog een AON aansluiting dus geen gezeur met XGSpon

[Fiekert]

aartvg schreef op zaterdag 20 juni 2026 @ 18:48:
[...]

Deze is nu beschikbaar voor je in mijn Glasnet. Je hebt nog een AON aansluiting dus geen gezeur met XGSpon

dank voor het versturen! laat nog even weten hoe de omzetting is gegaan maandag.

[aartvg]

ernstoud schreef op zaterdag 20 juni 2026 @ 17:45:
[...]


Tja, dan houdt mijn kennis wel op.

Wellicht heeft KPN voor Glasnet een eigen OLT profiel?

Wij draaien gewoon op KPN WBA zonder eigen profielen. We hebben andere klanten op KPN met Zaram draaien. Volgens mij zonder gekke aanpassingen maar zal eens bij collega moeten navragen die deze oplossing gebruikt.


Vlan 6 is en blijft nodig als je een Zaram gebruikt. Kan je inloggen in de Zaram (Als deze aangemeld is) je kan dan de vlan mapping opvragen.

[Hotsoup]

aartvg schreef op zaterdag 20 juni 2026 @ 18:50:
[...]

Wij draaien gewoon op KPN WBA zonder eigen profielen. We hebben andere klanten op KPN met Zaram draaien. Volgens mij zonder gekke aanpassingen maar zal eens bij collega moeten navragen die deze oplossing gebruikt.


Vlan 6 is en blijft nodig als je een Zaram gebruikt. Kan je inloggen in de Zaram (Als deze aangemeld is) je kan dan de vlan mapping opvragen.

Fijn om te horen dat andere klanten de Zaram gewoon hebben draaien, dan moet het bij mij ook lukken .

Vlan 6 is uiteraard logisch voor de router erachter, echter bij mij is het alleen dat de Zaram nooit van O1 naar O5 komt en het flink stil blijft vanuit de OLT.
Uit mijn hoofd meen ik me wel een Rx van rond de -13 dB te herinneren tijdens het testen met je collega's van support.

Maandag bel ik wel even om de Zaram weer eens te laten registreren.
Zijn er, los van de mapping controleren, alvast punten die voor jou bekend zijn (of bij die collega die dit gebruikt) waar ik op kan testen en eventueel jullie kant op kan aanleveren?

[aartvg]

-13 klink als heel veel singaal. Geen idee welke slitratio kpn gebruikt maar verwacht eerder tussen -16 of -20.

[Hotsoup]

aartvg schreef op zaterdag 20 juni 2026 @ 21:28:
-13 klink als heel veel singaal. Geen idee welke slitratio kpn gebruikt maar verwacht eerder tussen -16 of -20.

Nou goed, wie weet is het maandag een gevalletje "3 keer is scheepsrecht" .
Hij is al een paar keer geregistreerd geweest, dus benieuwd of het nu wel pakt.

Over die -13, dat was een ruwe uitlezing, dus de echte waarde ligt misschien wel in jouw verwachte -16/-20.

Ik lees maandag alles even netjes uit (O-state en RX) zodra de Zaram er weer in zit, dan heb ik concrete cijfers voor je.

[Fiekert]

afgelopen nacht is mijn verbinding overgezet naar Glasnet, in de bestaande setup met SFP op KPN WBA slechts een kwestie van PPPoE gegevens aanpassen en wachten tot de bestaande verbinding is omgezet. De cloud gateway fiber heeft geen downtime waargenomen in de omzetting. Administratief was een klein foutje gemaakt, maar dit is ook in no-time opgelost. tot zover een zeer positieve start.

[Hotsoup]

@aartvg, vanochtend heeft jouw collega van support de Zaram op verzoek er weer ingezet.
Na ongeveer 25 min lijkt deze nu wel online te komen.

Middels het aanvinken van "Disable Protocomp", krijg ik nu wel mijn PPPoE sessie.

Helaas ongeacht dat hij up is lijkt het er op dat er geen verkeer terug komt, de gateway zelf is ook niet te pingen (down). Enig idee wat dit nog zou kunnen zijn?

admin@ZXOS11NPI [/] # onu show pmapper

==================================================================================

*index = zapi-idx = MPON_MEM_TCONT-index

---------|-------|----------------------------------------------------------------

inst-id | index | pq-index : zapi-idx(pq-buf idx)

---------|-------|----------------------------------------------------------------

0x1102 0 9(0), 9(0), 18(9), 18(9), 27(18), 27(18), 36(27), 36(27)

==================================================================================

# onu show pq
===========================================================================================
Upstream priority queue mapping
PQ ME pririty : 0 is highest *inst-id: instance id
--------|--------------------|-------------|--------|--------------------|-----------------
pq-buf |------ PQ ME -------| GEM port | T-CONT |----- T-CONT ME ----|--802.1p Mapper--
idx | inst-id | priority | inst-id/idx | index | inst-id | alloc-id | inst-id | index
--------|---------+----------|-------------|--------|---------+----------|-----------------
0 0x8000 0 0x043C ( 1) 0 0x8000 0x0415 0x1102 0
9 0x8011 1 0x043D ( 2) 1 0x8001 0x0416 0x1102 0
18 0x8022 2 0x043E ( 3) 2 0x8002 0x0417 0x1102 0
27 0x8033 3 0x043F ( 4) 3 0x8003 0x0418 0x1102 0
===========================================================================================
admin@ZXOS11NPI [/] # onu show pon sync
=============================================
ONU Downstream Synchronization state
---------------------------------------------
Sync state | Sync(2)
=============================================
admin@ZXOS11NPI [/] # onu show pon activation
=============================================
ONU Downstream Synchronization state
---------------------------------------------
Oper. state | Operation
=============================================
admin@ZXOS11NPI [/] # onu show pon optic
=============================================
ONU PON LOS state
---------------------------------------------
LOS state | ACT
=============================================

admin@ZXOS11NPI [/] # onu show ponlink

ponlink-status : connect-OK

[aartvg]

Hotsoup schreef op maandag 22 juni 2026 @ 14:33:
@aartvg, vanochtend heeft jouw collega van support de Zaram op verzoek er weer ingezet.
Na ongeveer 25 min lijkt deze nu wel online te komen.

Middels het aanvinken van "Disable Protocomp", krijg ik nu wel mijn PPPoE sessie.
[Afbeelding]
Helaas ongeacht dat hij up is lijkt het er op dat er geen verkeer terug komt, de gateway zelf is ook niet te pingen (down). Enig idee wat dit nog zou kunnen zijn?[Afbeelding]

Ik zie aan onze zijde de PPP sessie ook als actief staan. Er gaat idd 0 bites aan data doorheen. Gebruik je zelfde ppp profiel als via de Nokia / Genixes TK01?


PS. Bel even naar support en vraag of ze willen doorverbinden kijken we even samen.