Een kleine opmerking:

Ik had in het openingsbericht een aantal getalletjes aangepast omdat mij die wel leuk leken, maar bedenk mezelf net dat VLAN ID's niet hoger kunnen zijn dan 4096. Je moet de netwerknummers en ID’s dus niet rechtstreeks overnemen, maar dat was je natuurlijk toch al niet van plan, toch?
 

Inderdaad, ik vond de nummering al wat vaag, ik gebruik zelf een andere methode voor naamgeving van VLANs, ben ook niet in detail op de hoogte met Gentoo netifrc. Maar het principe is duidelijk, hoewel ik geen TV heb en me blijf verbazen over de methode van TV-stream distributie richting de klant, maar dat zal alles met een hoop legacy in de KPN infra te maken hebben.

Mijn oog viel vooral op 2x Gbit i.c.m. SATA interface, is er voor deze SoC mainline Linux kernel beschikbaar?

Ik ook. Maar ik weet wel hoe het werkt. De internetsnelheid op vlan 6 word beperkt tot de hoogte van het abonnement. De snelheid op vlan 4, voor tv dus, is onbeperkt. Zo kan de klant dus de volledige snelheid van zn internetabonnement benutten zonder dat tv daar last van heeft.

KPN trekt zn eigen tv dienst zo wel enorm voor op diensten van externe partijen. Zoals bijv Netflix. Want Netflix komt natuurlijk gewoon over vlan 6. Internet dus. Ook Netflix op de decoders. Daarom is dus ook die igmp server nodig. Omdat de decoders zowel gebruik maken van vlan 4 voor KPN's eigen tv, als ook gebruik maken van vlan 6 voor Netflix en YouTube.

Een verschrikkelijk ingewikkelde constructie eigenlijk. Vroeger bij een ADSL abonnement van 20 mb misschien nog wel nuttig. Maar met de stijging van de snelheden word het meer en meer een nodeloos gedoe. Bij glasvezel met een 100 mb interabonnement of hoger heeft dit echt geen nut meer.

Heeft alleen maar nadelen: eigen modem/router keuze zal hierdoor altijd beperkt blijven tot modellen die deze constructie ondersteunen. En voor KPN is het aanbieden hun diensten op glasvezelnetwerken die aangelegd zijn door een andere partij bijna onmogelijk. Ze moeten namelijk heel veel apparatuur installeren bij deze partij in de knooppunten van het netwerk om deze constructie mogenlijk te maken. Waardoor het dus bijna nooit gebeurt.

De machine wordt nog wel geproduceerd, maar de software wordt niet meer bijgehouden. Dit is nog steeds dezelfde Debian Squeeze. Via het gebruikersforum worden daarentegen wel nog enkele andere OS’en aangeboden: Debian Buster, Redsleeve v7, Arch en Gentoo.

Twee zeer belangrijke punten in deze:

1) De IGMP proxy server zorgt er voor dat een live TV stream (zender) maar één keer over het netwerk gestuurd wordt ookal kijken er 100.000 mensen live naar die zender. Dat scheelt dus enorm veel data.

2) QoS is heel belangrijk bij live streaming. De TV streams moeten bij live uitzendingen absoluut voorrang krijgen op Internet verkeer, met name bij aansluitingen met een lagere beschikbare bandbreedte. Dit om haperingen te voorkomen. De eenvoudigste en minst CPU vretende inrichting van QoS is op het niveau van vlans. Vlan 7 (telefonie) krijgt de hoogste prioriteit, gevolgd door vlan 4 (televisie) en de laagste prioriteit heeft vlan 6 (Internet).

Die besparing van data is alleen van toepassing als je 2 (of meer) decoders in huis hebt die beide op dezelfde zender staan afgesteld. Hoe vaak gebeurt dat nou? Bijna nooit.

Mee eens, maar de concurrentie, bijv. Netflix of NLziet, hebben dit voordeel niet. Dat is oneerlijk. En tevens laten die partijen zien dat het ook helemaal niet nodig is. In ieder geval niet bij een fatsoenlijk snelle verbinding.

Met Debian Buster dus 4.19 is het eigenlijk wel prima; Had ooit bijna een ESPRESSObin gekocht, daar die een miniPCI-E slot heeft wat dan gunstig leek voor 4G WAN. Maar dat blijkt alleen USB2 te zijn, en dan loont het niet t.o.v. een standaard USB2 connector/interface, althans niet voor wat ik er mee van plan was.

QoS is uiteraard alleen van belang wanneer meerdere diensten gelijktijdig worden afgenomen. Voor zoiets als Netflix is dat wat minder waarschijnlijk dan bij de NOS

Dan heb jij mijn bericht niet helemaal begrepen.

Als in jouw dorp duizend mensen live naar die zender kijken dan zou zonder IGMP die TV stream dus duizend keer verzonden moeten worden van de KPN servers naar jouw dorp. Met IGMP hoeft die TV stream maar één keer naar jouw dorp verzonden te worden.

Het gaat dus niet over de belasting van het lijntje tussen jouw woning en de straatkast, wijkcentrale of Point of Presence maar juist over de lijn van daar naar de KPN servers.

Hoe KPN zn hoofdnetwerk ingedeeld heeft, dat doet niet terzake. Het is behrijpelijk dat kpn op zn hoofdnetwerk 1 dezelfde stream niet 1000 x over dezelfde verbinding laat lopen. Maar daar gaat het niet om. Het gaat erom hoe het in de meterkast aan komt bij het modem. Dat gedoe met vlans en igmp (bij mij in de meterkast dus, niet op het hoofdnetwerk van kpn) is gewoon nodeloos ingewikkeld.

Begrijp je het niet of wil je het niet begrijpen.

Als er geen gebruik gemaakt kan worden van IGMP (wikipedia) dan zou elke TV ontvanger zijn eigen verbinding hebben met de server vanwaar de TV stream verzonden wordt. Met IGMP wordt de TV stream als multicast verzonden zodat deze op het gehele netwerk maar één keer verzonden hoeft te worden.

Het gaat dus juist wel om het hoofdnetwerk en niet om dat lijntje naar jouw woning.

Het wordt wel een beetje topicvervuiling zo, jongens. Het gaat er hier om hoe je een probleem dat KPN heeft veroorzaakt kunt oplossen. Volgens mij zitten jullie hier beiden wel lang genoeg om te weten dat KPN daar verder toch geen verantwoording over gaat afleggen of zelf voor een oplossing gaat zorgen.

Om het af te maken: het is mij verteld dat de bandbreedte van mijn contract inclusief de bandbreedte voor TV zou zijn. Aangezien het via de VLAN’s om twee gescheiden netwerken gaat zal dat voor KPN lastig te tracken zijn, tenzij het iTV kastje dus het datagebruik terug meldt over de connectie die op basis van de afgenomen bandbreedte geknepen dient te worden.

Nick heeft uiteraard wel gelijk over de onzin van dat multicasten, want het is vrijwel ondenkbaar dat er mensen zijn die nooit op het groene knopje of de pauzetoets drukken. Het is gewoon hopeloos oude troep bij KPN, wat je ook kunt zien aan dat malle PPPoE, alsof er nog mensen bestaan die via een 9600 baud modem inbellen. Dat krijg je dus wanneer je de boel laat runnen door pennelikkers, verkapte ambtenaren en politici die volgens hun partij een leuke positie verdiend hebben.

Ik weet niet wie jou dat verteld heeft, maar dat is onjuist. De gecontracteerde snelheid is de gecontracteerde snelheid voor Internet. Als de lijn meer capaciteit heeft, dan wordt die capaciteit gebruikt voor televisie en telefonie. Een glasvezelabonnee met een 200Mbps aansluiting zal die snelheid altijd kunnen halen, ook als hij op zes televisies naar verschillende HD-"Glas" zenders kijkt.

Je moest eens weten hoeveel mensen echt live kijken.

Stel dat dat 50% is, dan bespaar je met IGMP multicasting toch al snel weer 49,5% op de benodigde bandbreedte.

Uitgesteld kijken was overigens precies de reden waarom de uitrol van "HD op 1" zo ontzettend lang geduurd heeft. Een aanzienlijk deel van de abonnees keek nog SD terwijl ze met "HD op 1" automatisch HD gingen kijken. De extra capaciteit die daarvoor benodigd was op de netwerkknooppunten was heel groot en werd nauwkeurig gemonitored tijdens de uitrol. Overigens was ook hier dus niet het lijntje naar de woning de bottleneck, maar de rekencapaciteit op de netwerkknooppunten.

Toch ben ik blij dat KPN op vlan 6 (Internet) geen DHCP gebruikt immers dat zou betekenen dat ik bij het switchen van router (MAC adres) of het wat langer uit zetten van de router een nieuw publiek IP adres toegewezen zou krijgen en dat is het laatste wat ik wil. Op vlan 4 (televisie) wordt wel DHCP gebruikt en daar zie je dan ook regelmatig een ander WAN IP adres. Vandaar dat het essentieel is om rfc3442-classless-static-routes te implementeren op vlan 4.

Ik zie dat je in jouw configuratie altnet 213.75.0.0/16 gebruikt voor het IPTV platform.

Dat is een te groot subnet, 213.75.112.0/21 is voldoende.

Het subnet 217.166.0.0/16 wordt volgens mij niet meer gebruikt.

Overigens gebruik ik binnen de IGMP proxy server upstream altnet 0.0.0.0/0 zodat ik geen problemen zal krijgen mocht KPN ooit weer een keer het IPTV platform naar een ander subnet verplaatsen.

Je definieert upstream jouw LAN subnet 10.84.86.0/24. Dat is mijns inziens niet correct, dat subnet zou downstream gedefinieerd kunnen worden maar ook daar kan 0.0.0.0/0 gebruikt worden.

Wat voor een hardware moet ik minimaal aan denken?

Wat is ongeveer de prijs van geschikte hardware voor zo'n Linux router?

Moet de hele configuratie via de command line interface gedaan worden?

Geldt dat dan ook bijvoorbeeld voor het maken van port-forwardings?

Hoe worden updates van het OS en de "router functionaliteit" geïnstalleerd?

@wjb Een voorbeeld voor minimale hardware zou kunnen zijn https://www.armbian.com/orange-pi-r1/

Maar hoe en wat ligt zo sterk aan wat de eisen zijn dat er weinig generiek over te zeggen valt. Als low-power het belangrijkste is (mobile, batterij-gevoed) is het een heel ander verhaal vergeleken met iets wat altijd aan de 230V hangt. En 4G/LTE is o.a. raw-IP, dus aan de WAN zijde zijn het direct IP pakketten.

Anderzijds komen uit een FTU/NTU doorgaans ethernetpaketten. Momenteel gaan die bij mij direct via een patchkabel naar een RJ45 poort van een PC met een extra ethernetkaart erin. Die PC is feitelijk een netwerk- en storage virtualisator, dus daarbinnen zijn diverse netwerkinterfaces middels bridging en VLANs beschikbaar die dan het I/O van virtuele machines zijn. 1 van die virtuele machines is de router. Dat kan van alles zijn, van iets met een linux kernel waarbij NAT en IPv4 forwarding aanstaat of OpenWRT of pfSense AMD64, etc.

Als ik toch iTV zou nemen, zou ik denk ik een Gentoo ‘template’ aanzwengelen als virtuele machine en daarop dan het stappenplan van gordonb3 toepassen. Het wisselen van router gaat softwarematig (ompluggen van virtuele kabels).

Iets dergelijks heb ik dus ook. Ik heb alleen geen glasvezel. Hangt hier een Experiabox v9 in de meterkast. Daar een pc met 2 gigabit netwerkt kaarten op aangesloten. Daar draait Ubuntu Server op met libvirt. 1 van de virtuele machines is pfsense. Daar heb ik vlans op geconfigureerd. Met netplan heb ik 2 virtuele switches aangemaakt, 1 voor elke interface. De pfsense installatie staat dus met 2 pootjes gekoppeld aan deze beide virtuele switches. Elke volgende virtuele machine kan ik aan de virtuele switch achter pfsense aan een vlan naar keuze koppelen. Of eventueel aan de switch voor de pfsense, waarmee deze dus feitelijk rechtstreeks aan de Experiabox komt te hangen. Allemaal software wat gewoon recent is en actief ontwikkeld word. Updaten met apt-get update & apt-get upgrade 

Maar ik heb dus niks te maken met interactieve tv. Want de decoders zitten dus uiteraard gewoon aan de Experiabox. 

Erg zuinig is het natuurlijk niet ...   maar werkt wel leuk  En allicht zuiniger dan vroeger, toen had ik wel 3 of 4 van die antieke systeemkasten draaien, nu maar 1   

Ik ben alleen bang dat dat apparaat niet krachtig genoeg is om een 200Mbps glasvezelaansluiting te bedienen en met die 100Mbps nic's gaat dat sowieso al niet lukken.

Ik ben ook nog geen Gigabit dual nic mini PC tegen gekomen die in prijs lager ligt dan een EdgeRouter Lite 3. En dan vraag ik me af waarom ik mij de moeite zou nemen om alles via een command line in te richten terwijl ik blijkbaar voor minder geld een linux based router kan aanschaffen waarop ook nog eens een uitgebreide GUI voor het configureren beschikbaar is.

Ik heb gewoon een enkele nic in de pc zitten van iets meer dan een 10tje. De andere zit onboard.

De EdgeRouter Lite 3 en vele andere commerciele routers/NASsen danken hun (Gigabit) snelheid vaak aan custom accelerator blokken in de SoC. Daarvoor zijn flink wat aanpassingen nodig t.o.v. van wat op kernel.org staat en die aanpassingen zijn vaak closed-source en grootdeels de basis van het verdienmodel van de firma’s die de routers leveren/verkopen. Maar daarmee is de mogelijkheid om als eindklant aanpassingen te doen op bron-code of module niveau vrijwel onmogelijk. In mijn geval is de eis om makkelijk en snel aanpassingen aan de bron-code te kunnen doen groter dan het hebben van het gemak van een GUI.

Er was een tijd dat Intel z’n Atoms min of meer weggaf en toen kon je voor 70 euro (excl. geheugen, voeding en kastje) dual Gbit boards kopen. Maargoed, dan zitten we op de eis lage hardware aanschafprijs .

Overigens kun je, als je al een switch met VLAN ondersteuning hebt, ook wel met 1 NIC toe als je niet absolute Gbit snelheid simultaan nodig hebt.

Ik kreeg in eerste instantie geen stream binnen en zag via debug mode meldingen binnen komen over de genoemde segmenten. Een internet zoekopdracht leverde het altnet 213… segment op en de grootte van het 217 segment heb ik vervolgens zelf bepaald via whois.

Dat staat mijns inziens ietwat haaks op je eerder opmerking dat mijn definitie te ruim zou zijn?

Tja, zo stond het gedocumenteerd. Het levert hier ook een werkende situatie op. De logica lijkt enigszins op dat van ipsec waar je eveneens tureluurs wordt van wat links en en wat rechts is. Strikt genomen maakt het voor deze configuratie verder ook niet echt niet uit om 0.0.0.0/0 te definiëren omdat de iTV kastjes toch in een apart segment staan waar ze geen schade kunnen toebrengen aan het interne netwerk. Ik heb die keuze echter niet gemaakt.

Zoals gezegd: ik gebruik zelf een armv5te SoC. Een Pi overtreft dat al. De bottleneck ligt bij een Pi echter in de netwerkkaarten omdat daar alles via USB loopt. Exclusief harddisk kan je denk ik voor een 4-5 tientjes wel klaar zijn.

Ja, als je iets bijzonders wilt zul je in Linux in principe altijd naar de commandline moeten. Dat kan je als een nadeel opvatten, maar het is nog altijd beter dan dat het helemaal niet kan (zoals in Windows - maar wie dat rechtstreeks aan het internet knoopt is ronduit gestoord).

If it ain’t broken, don’t fix it. Zo heb ik ook nog een Windows XP machine in gebruik ten behoeve van een scanner, welke het dus niet doet onder Windows 10 (of Linux voor wat dat aangaat). En als je toch wilt updaten heeft praktisch elke Linux distributie wel een of andere geautomatiseerde update routine.

Ongeveer een maand nadat mijn schoonvader vrij plotseling overleed werd er een pakje bezorgd met daarin een “CherryPal”. Zonder dat dit bekend was bij zijn naasten bleek dit voormalige NLUUG bestuurslid een buitengewone interesse te hebben ontwikkeld om grote dingen te doen met kleine energiezuinige machines. Het was vanuit dit idee dat ik enige jaren later de Excito B3 kocht, een soort van NAS+ dat door een stel geïnspireerde Zweden in elkaar was gezet met de expliciete intentie dat gebruikers het ding voor totaal andere dingen zouden gaan gebruiken. Het energiegebruik van dit apparaat is volgens opgaaf tussen de 7 en 11 watt, afhankelijk van wat voor harddisk je plaatst. Als je er een SSD in plaatst is het apparaat compleet stil, want het is passief gekoeld. Voor mij primair een ding om mee te spelen, maar het bleek al snel zo’n geweldige aankoop dat ik er sindsdien nog een paar extra heb gekocht, waarvan ik er momenteel twee in gebruik heb als “productie”. Daarvan fungeert er eentje dus als internet router (en nog wat andere dingen).

Klopt, maar mijn filosofie daarin is of je definieert precies wat je nodig hebt of je definieert geen restrictie (0.0.0.0/0).

Omdat de downstream zijde van de IGMP proxy gedefinieerd is op een vlan 1921 kan rustig 0.0.0.0/0 gebruikt worden immers het vlan zorgt al voor de afsplitsing van het subnet.

Dat is dus wat ik bedoelde. Voor een tutorial vind ik het daarentegen wel aardig om te laten zien hoe het werkt. Dat is in dit geval ook niet geheel onbelangrijk omdat het gros waarschijnlijk toch op iets van Debian of RedHat gebaseerde systemen werkt en zich misschien ook wel heeft laten verleiden om zoiets als bind en isc-dhcp te installeren. Een op een overkloppen gaat het daarmee sowieso niet worden, maar als er mensen zijn die deze vertalingen reeds hebben gemaakt mogen ze die uiteraard hier delen voor degenen die wat minder bedreven zijn in wat nog wel eens wordt aangeduid als “half the fun”.

Whois meldt overigens 213.75.0.0/17

Zou daarnaast leuk zijn als ik dat afleidende foute nummertje mocht redigeren, dan hoeven we daar tenminste niet meer over te discussiëren.

Wat wil je aangepast hebben, Gordon? Dan pas ik het voor je aan.

@Erik_ Het VLAN ID mag niet hoger zijn dan 4096. Iedere instantie van het getal 8486 zonder puntjes of spaties er tussen dient derhalve te worden gewijzigd naar een getal binnen de geldige range. Dus wel “eth1_8486” en “eth1.8486”, maar niet “84.86”. Maak er maar 1921 van - dat is ("TV” - “AA”).