In Soest al sinds donderdag geen multicast
Dank allemaal.
Ik vrees dat men pas morgen verder gaat zoeken 
Mocht er toch iets te melden zijn dan laat ik het weten.
Hm, dat duidt op onvolledige of te beperkte beheer-/QoS afspraken. Daar ben ik niet zo blij mee. Iets dermate ernstigs als het volledig (nou ja) ontbreken van het TV-signaal is bij een totaalprovider een bijzonder serieuze kwestie (zou dat moeten zijn).
Het goede imago van Freedom lijdt hier toch ook onder, maar dat weten
ze ongetwijfeld zelf donders goed.
Hoe zit het met change management bij FC en een eventuele rollback ?
Sinds de herstart van mijn Amino heb ik foutmelding S815 ook.
Het hele netwerk is uit geweest in verband met het wisselen van de Fritzbox.
Het komt voor bij b.v. bij het oproepen van het journaal zondag NPO1 13:00 in uitzending gemist.
Er komt eerst een voorbereiden mededeling en daarna komt de foutmelding.
Ik heb het ook gehad met de uitzendingen van Op1 op donderdag en vrijdag.
Via de browser lukt het wel om te kijken.
Ik heb ook wel gehad dat even spanningsloos maken van de Amino dat het kijken mogelijk maakte.
Met de uitzending van vandaag, is me dat niet gelukt.
Het probleem heb ik alleen nog maar bij de NPO gezien.
Het aantal zenders dat ik zo bekijk is ook beperkt.
De foutmelding is niet te vinden op help pagina’s
Graag deze toevoegen? @arien
https://helpdesk.freedom.nl/ik-krijg-een-foutmelding-wat-moet-ik-doen
Hmm… zit je ook op Fiber Crew @Erik ?
Nee, in zit op Cambrium.
Cambrium verzorgd, net als KPN, de multicast stream zelf. Dat loopt dus helemaal buiten ons om. Dat je het ook zag bij Uitzending Gemist maakt dat de unicast stream niet goed binnenkwam. Als het structureel is dan is ook hier is een packet trace handig. Daar moet je dan wel een ticket voor openen.
Ik kan zelf niets op de website zetten, dus dat moet ik vragen. Maar S815 betekend dat de player de video niet kan starten. Bij opstarten van video duurt het laden dan langer dan 15 sec. En tijdens het kijken is er langer dan 60 sec geen content ontvangen.
In Soest nog steeds geen enkele multicast. Is er nog behoefte aan packet traces?
Een of meer van deze opties ?
|Internet connection
|Interface 0 (‘internet’)
|Interface 1 (‘iptv’)
|Routing interface
Na de laatste trace is er hier niets veranderd
We hebben iedereen op OTT (alles unicast) gezet. Dus je zou nu live TV (niet via multicast) moeten kunnen zien. De beeldkwaliteit is wat minder, en het heeft ook geen radio en geen teletekst.
Dus als TV nu nog niet werkt dan moeten we daar nog in duiken.
Ik wilde al melden dat TV werkt, maar dit verklaart een hoop. Ik zie ook geen verkeer meer op vlan4.
Het werkt weer … goed gedaan.
We gaan vannacht aan de gang met Fiber Crew in een poging de problemen eruit te hameren.
Op dit moment is onze DHCP-relay in het ongerede geraakt. Dat is een keer eerder gebeurd met dit type switch. Het betrof toen een ander access-netwerk en een andere switch.
Toen hebben we dat alleen met een reboot van de switch kunnen oplossen. Het is onduidelijk of dit een gevolg is van de multicast-problematiek. Het zou ook de lange uptime kunnen zijn. Het is in elk geval niet de oorspronkelijke oorzaak.
Heb je dan geen mensen nodig die meekijken? Monitoren lukt niet begreep ik!
We kunnen wel wat meer zien dmv tellers.
Bovendien hebben we ook een idee waar we naar moeten gaan kijken
En last but not least is er een Freedom medewerker op Fiber Crew met een Raspberry Pi staat waar ik remote op in kan loggen en IGMP vandaan kan sturen om MC-verkeer te kunnen ontvangen en ook stoppen.
We komen dus een heel eind.
Is, het feit dat we allemaal nu unicast gebruiken (idd, werkt weer), ook de reden dat het geluid gewoon stereo (dus slecht) is? Volgens mij is het bij terugkijken etc. inderdaad kwalitatief minder dan bij multicast…
Die vraag over het geluid kan ik niet beantwoorden. Dat is teveel de applicatie laag en die is me te ingewikkeld 
Moeilijke vragen graag naar de helpdesk 
Fiber Crew heeft een probleem gevonden waarbij specifiek IGMP-verkeer loop-te* door een geaggregeerde link. Dit is hoogst waarschijnlijk de oorzaak van het nogal grillige gedrag tijdens het wisselen van zenders.
Hoewel de loop* alleen IGMP-verkeer betrof gaf het een station-movement voor het source-MAC-adres van de multicast-streams. Dat resulteerde in kortstondige haperingen in de TV- en radio-streams.
In de loop van het weekend is de DHCP-agent in het ongerede geraakt. Bij een ieder waar de lease-tijd van een dag verstreek stopte de Amino STB hierdoor helemaal met live TV.
We wijten het falen van de DHCP-agent ook aan de hierboven genoemde loop*. Hoewel we dit niet met zekerheid kunnen stellen. De agent is spontaan weer gaan werken kort nadat de loop* was gevonden en weggenomen.
Tot slot hebben we gezamenlijk veel tijd besteed aan het probleem van het spontaan volledig stoppen van de radio- en TV-streams. Dit konden we in onze test-opstelling goed reproduceren. Na lang zoeken bleek dit een nogal ongelukkig gekozen forwarding timer in een apparaat in Hilversum die het multicast verkeer per multicast groep na 30 seconde deed stoppen Tenzij er binnen die tijd een IGMP-bericht voor die specifieke multicast-groep de timer een reset gaf.
Al-met-al hebben we veel vertrouwen gekregen en besloten jullie weer van OTT af te halen. Uiteraard zijn we erg benieuwd naar jullie ervaringen.
Vanzelfsprekend gaan we ook nadenken hoe we zo’n langdurige storing in de toekomst kunnen voorkomen.
* dit is het Engelse woord voor lus, met de uitspraak ‘loep’.
Dat was een flinke graafklus. Helaas heb ik in Lelystad nu een kleine uitdaging, geen dhcp antwoord op vlan4 hier. ONT is al gereset en ik zie verkeer, veel dhdcp requests, geen antwoorden. Ook arp requests voor ip 100.66.0.1 (gateway) en geen antwoorden.
Vrij vertaal veel verkeer inkomend en uitgaand, geen antwoorden, maar om lokaal gemiste resets uit te sluiten een reboot van de router (als ik 'm even kan missen).
Oh ik hoop dat de DHCP relay niet toch weer in de knoop zit 