Klopt het dat Fibercrew niet meer aan te vragen is in o.a. Hilversum?
Er gaat toch hopelijk niet mee gestopt worden?
Beslissing van de directie om geen nieuwe orders aan te nemen. Teveel problemen. Ik hoop met je dat deze kunnen worden opgelost.
Oke. moet zeggen dat de 3 verbindingen die ik beheer, prima zijn.
De verbinding zelf is stabiel, TV is de uitdaging. Wij hebben maar 1 zender op staan, maar zelfs die heeft haperingen af en toe.
Voor ipv6 heb ik wel de acceptatie van RA moeten uitschakelen, anders werkt ipv6 routering niet.
Ik heb inderdaad geen TV.
Was dat altijd al zo? Of is dat pas sinds december? Want toen hebben we RAs aangezet vanwege de vele overstappers van Tweak die dat gewend waren.
Ik kwam er eind januari achter wat er fout ging met m’n ipv6 routering en heb 29 januari RA uit gezet. Het leek alsof ik in de helft van de tijd verkeer kon routeren met een gespecificeerde target voor de routering. (nu is het default de pppoe link op en gaat het goed)
Ik heb deletes van default routes naar 2 LL adressen in de command history staan, fe80::8a90:9ff:fe73:402b en fe80::6a22:8eff:fe2a:5a64 .
Is er al meer nieuws over de FiberCrew uitdagingen? Vanuit hier lijkt het er op dat ze ondertussen erg stabiel zijn. (Zolang er geen KPN kabels opgegraven worden)
Hun netwerk kan nog steeds bar slecht tegen fiberbreuken.
Ik zou graag van andere Fiber Crew klanten horen of live-TV (multicast) nu goed werkt. Ik heb er namelijk geen zicht meer op.
IK heb geen klachten in elk geval, heel af en toe zakt de resolutie wat weg (blokkerig beeld), maar na zappen is het weer in orde. Ik heb in elk geval niet meer dat TV kijken niet lukt.
Sinds het directiebesluit (en de FNORK terug is gegaan naar Freedom) is er voor ons weinig veranderd.
De internetverbinding werkt naar tevredenheid. Het enige dat opvalt is “DNS disruption detected/ended” in het FRITZ!Box Event Log.
De TV verbinding hapert nog steeds, regelmatig bevroren of zwart beeld gedurende seconden tot minuten. Een paar minuten terugspoelen en dan afspelen is ondertussen ingesleten gedrag bij ons geworden. Of opnemen en later afspelen.
Die meldingen over DNS disruptions zijn niet exclusief voor Fiber Crew.
Die heb ik na onderzoek, met bewijs als een bug bij FRITZ! (AVM) aangemeld.
Als je de fallback naar publieke DNS-services uitzet zie je die niet meer en doet DNS het nog net zo goed. En met meer privacy.
1 like
Geen idee of ik via FiberCrew (het lijkt er wel op, ontsluiting was vroeger Tweak) een netwerk verbinding heb.
Ik merk wel dat regelmatig de verlenging van de IGMP subscription kwijtraakt. direct opnieuw de zender kiezen of naar OTT overschakelen verhelpt het wel.
Dat is al een tijdje aan de gang.. (Ik dacht eerst dat het aan een switch lag die inmiddels overleden is, maar het gebeurt met een nieuwe switch nog steeds).
Fiber Crew levert alleen op KPN-fibers.
Ik vermoed dat je belichter Fiber Operator is; want die hebben de infra van Tweak overgenomen.
Beide operators bedienen niet alleen Freedom maar ook andere ISPs. Beide hebben om bedrijfstechnische redenen besloten dat de multicast-feeds van de ISPs dienen te komen.
Nu zijn er nogal wat ISPs, Freedom incluis, die dezelfde multicast-boom van KPN gebruiken. Fabrikanten van apparatuur hebben in het algemeen nooit bedacht dat dezelfde multicast-boom meer dan één keer in er netwerk voor kan komen. Het kán werken maar problemen met IGMP komen over het algemeen uit dat gegeven. En technisch is het… nou ja… laat ik het netjes houden.
Het beste kun je een ticket aan maken. Dan duik ik er met mijn liefde voor multicast in. Als het even kan met een pcap-file van de multicast stream met onderbreking. Zet de snap-lengte op 96 bytes. Dat geeft voldoende header info voor zowel IGMP als RTP.
Ik ga het proberen het komt onregelmatig voor, dus het kan ook even duren voor ik een capture heb.
Die blijven hopen dat er ooit Freedom specifieke multicast diensten bijkomen 
(misschien wel ongerelateerd aan TV….)
Ik heb mogelijk een oorzaak gevonden…..
Er is geen spec gegeven voor waar de multicast vandaan komt.
(igmpproxy moet dat netwerk kennen….)
Het leek erop dat het ooit 217.166.0.0/16 was…? Ik kan niet meer terug vinden waar de /16 vandaan komt. Nu is het 100.64.0.0/16 lijkt op CGNAT. De bron dan de /16 is vermoedelijk het oude adres.
Nu komt de query bij 100.65.0.1 vandaan, dat valt buiten de intellingen.
Ik heb nu als test het netmask wat kleiner gemaakt (/10 conform the CGNAT RFC)… maar wat is de juiste instelling?
Het staat niet in de TV-instellingen…. ( Welke instellingen heb ik nodig voor mijn eigen modem? | Freedom Helpdesk )
noot: tcpdump maakt nog steeds een recording.
Het source-adres van het multicast-verkeer zelf is niet belangrijk. Dat is dus het RTP-verkeer. Die adressen zijn van KPN.
IGMPv3 kan weliswaar source specific multicast (SSM) doen maar dat wordt hier helemaal niet gebruikt. De Amino’s zelf doen IGMPv2 en dat kent geen SSM.
Klanten die via KPN zijn aangesloten krijgen het multicast verkeer rechtstreeks van hen. Voor alle andere klanten loopt die feed via ons.
IGMP-queries komen dus, behalve voor de klanten die via KPN lopen, ook van ons. De source adressen voor het IGMP-verkeer zijn inderdaad CGNAT-adressen, daar over later meer. Die 100.64.0.0/10 hebben we gesubnet, wat ook gebruikelijk is.
Dus die /10 als subnetmasker klopt niet. Het subnetmasker krijg je via DHCP optie 1 en kan aan verandering onderhevig zijn. Je krijgt ook DHCP optie 121 (Classless-Static-Route) om je router te vertellen dat alle 100.64.0.0/10 naar het eerste host-adres van je subnet moet worden gestuurd.
We hebben indertijd CGNAT-adressen gekozen, ook al zijn die hier niet echt voor bedoeld. We hebben dit gedaan in de hoop die te mogen adverteren aan wat toen nog Canal Digitaal (CD) was. Want KPN vroeg heel in het begin van Freedom werkelijk een godsvermogen per bit ‘internet verkeer’ en helemaal niets voor TV-verkeer. Dat is nu anders. Maar als we toen het Video on Demand (VoD) verkeer, zoals we nu wél gebeurd, zouden hebben gerouteerd over de PPP-tunnels, dan waren we in een paar maanden failliet gegaan.
Cambrium adverteerde om die reden RFC-1918 adressen aan CD. Daar hadden ze hele oude afspraken voor gemaakt met de voorloper van Canal Digitaal. Kennelijk waren die al lang vergeten; want samen met CD hebben we toen uitgevonden dat allerlei maffe storingen werden veroorzaakt doordat CD dezelfde RFC-1918 adressen gebruikt. Met CGNAT-adressen zouden we dit conflict niet hebben. Toch wilde CD, na het debacle met Cambrium, deze adressen niet van ons accepteren. Uiteindelijk is er een andere, veel betere, oplossing gekomen voor de verkeerskosten.
Het probleem is dat de igmpproxy niet vanuit de DHCP server gevoed wordt.
Het heeft ook weinig met routering te maken, het is meer welke igmp adressen als afzender geaccepteerd worden.
Dus een meegeleverde parameter is niet direct ergens anders op te voeren. (Er is geen voorziening voor hook scripts oid), zelf knutselen aan de firmware wordt een uitdaging bij elke update.
CGNAT range hergebruiken voor dit doel lijkt me niet zo schadelijk, tenzij andere interfaces van een router ook met CGNAT geconfronteerd wordt. (dat zou evt. bij een 5G modem een issue kunnen zijn.
Maar als dat als uitwijk is bedoeld voor iets dat ook connecties moet kunnen ontvangen is er al iets anders fout gegaan in de planning.)
Hmmm, ik dnek dat ik weet waarom we hier geen issues met TV hebben. Sinds woensdag heb ik de traffic stats weer actief (nu vanuit de router ipv de rpi) en ik zie dat ik extra verkeer op vlan6 heb zodra de TV ontvanger aan staat en vlan4 redelijk ongebruikt is.