Skip to main content

Onderstaande gaat er vanuit dat je reeds beschikt over een Linux machine welke je gebruikt om KPN internet op jouw LAN omgeving ter beschikking te stellen.

Indien je dezelfde instructies hebt gevolgd welke ik jaren terug zelf via het internet heb gevonden dan ben je in het bezit van een redelijk prijsgunstige switch met ondersteuning voor het 802.1q protocol, waarschijnlijk een Netgear GS105E Pro of de 8-poorts variant daarvan, en heb je deze vóór je router staan om de VLAN’s te splitten én distribueren. Sinds medio november 2019 levert dit een nogal vervelende melding op de iTV kastjes op en dit komt doordat deze buiten het streaming netwerk dat via VLAN-4 wordt aangeboden andere internetdiensten willen gebruiken welke KPN nu via datzelfde netwerk heeft geblokkeerd. Dit houdt in dat deze diensten nu via de normale internetconnectie moeten lopen, hetgeen inhoudt dat de iTV kastjes in ons interne netwerk zouden moeten staan. Aangezien wij reeds over een 802.1q capabele switch beschikken gaan wij dat natuurlijk niet doen ;)

Mijn hardware is een Excito B3, gebaseerd op een ARMv5te Marvell SoC met twee (echte) gigabit poorten, optionele WiFi via de PCI-e poort en twee SATA poorten waarvan een intern. Het oorspronkelijke besturingssysteem van deze machine is Debian Squeeze met een noob interface, maar ik draai Gentoo met een door mijzelf geporteerde versie van die noob interface, gewoon omdat het kan. Waarmee ik wil zeggen dat je geen extreem dikke machine nodig hebt én dat onderstaande netwerkconfiguratie betrekking heeft op netifrc en je deze dus zal moeten vertalen naar je eigen Linux smaak.

Stap 1:
Indien je ook vaste telefonie hebt via KPN en daarvoor de Experia router als VOIP interface achter de primaire switch hebt opgenomen, configureer dan de switch om VLAN-4  als "tagged” naar je router door te geven. Voor de volgende stap veronderstel ik dat je voor dezelfde poort VLAN-6 eveneens wijzigt van “untagged” naar “tagged”.
Plug anders de kabel van je glasvezelkastje over van de switch rechtstreeks naar je router machine

Stap 2:
Definieer de VLAN ID’s (netifrc)

config_eth0="null"
rc_net_eth0_provide="!net"
vlans_eth0="4 6"

# vlan voor iTV
config_eth0_4="dhcp"
dhcpcd_eth0_4="-i IPTV_RG" # bedankt @wjb
rc_net_eth0_4_provide="!net"
rc_net_eth0_4_need="net.eth0"

# vlan voor internet via PPPoE
config_eth0_6="null"
rc_net_eth0_6_provide="!net"
rc_net_eth0_6_need="net.eth0"

Verander “link_ppp0” van eth0 naar eth0.6 en herstart zowel eth0 als de ppp interface om te controleren dat je internet nu ook werkt zonder dat de switch eerst de VLAN-6 tag heeft gestript
Hint: je kunt dit ook zonder de kabel om te pluggen testen door via de ProSAFE Plus utility de betreffende poort om te zetten van “untagged” naar “tagged”.

Stap 3:
Na de herstart van eth0 zou je nu ook een interface eth0.4 moeten hebben en daar een 10.x.x.x adres op zien. Mocht je een andere dhcp client gebruiken dan DHCPCD en geen IP adres zien, dan zul je zelf moeten uitvinden hoe je de “vendor class ID” moet doorgeven (dat is dus "IPTV_RG”).

Stap 4:
Creëer een nieuw VLAN op je interne netwerk (netifrc)

 

vlans_eth1="1921"

# vlan voor communicatie met iTV LAN (ASCII 84 86 = "TV")
config_eth1_1921="10.84.86.254 netmask 255.255.255.0 brd 10.84.86.255"
rc_net_eth1_1921_need="net.eth1"

Stap 5:
Voeg het nieuwe VLAN ID toe aan je switch configuratie: “tagged” op de LAN poort van je router en “untagged” op de poort waar het iTV kastje moet komen.

Stap 6:
Voeg het nieuwe IP segment toe aan je DHCP server. Voor DNSmasq ziet dat er zo uit:

interface=eth1.1921

# Set range for a maximum of 5 clients
dhcp-range=eth1.1921,10.84.86.2,10.84.86.6,1h

# Set DNS servers to Google DNS
dhcp-option=eth1.1921,6,8.8.8.8

# Set default route
dhcp-option=eth1.1921,3,10.84.86.254

Controleer eventueel met een laptop of iets dergelijks of je ook echt een adres in deze range ontvangt op deze specifieke switch poort.

Stap 7:
Je kan het amper verzinnen, maar omdat het protocol voor de streaming helemaal niet gerouteerd kan worden moet je een proxy installeren. In de meeste distributies is “igmpproxy” wel te vinden. In Gentoo is deze gemaskeerd als zijnde niet helemaal hoe het netwerk zich zou moeten gedragen. Mocht het in jouw distributie helemaal niet worden aangeboden dan kan je de source hier vinden: https://github.com/pali/igmpproxy

Wijzig de inhoud van /etc/igmpproxy.conf als volgt:

##------------------------------------------------------
## Enable Quickleave mode (Sends Leave instantly)
##------------------------------------------------------
quickleave

##------------------------------------------------------
## Disabled Interfaces
##------------------------------------------------------

# real interface - no untagged traffic there
phyint eth0 disabled
# virtual WLAN ID 6 - carrier for PPPoE connection
phyint eth0.6 disabled
# internet connection
phyint ppp0 disabled

# real lan interface
phyint eth1 disabled

# do tag any other interfaces your system may contain as
# disabled as well
# ...

##------------------------------------------------------
## Downstream Interface
##------------------------------------------------------
phyint eth1.1921 downstream ratelimit 0 threshold 1


##------------------------------------------------------
## Upstream Interface
##------------------------------------------------------
phyint eth0.4 upstream ratelimit 0 threshold 1
altnet 10.84.86.0/24 # that's my local segment
altnet 213.75.0.0/16
altnet 217.166.0.0/16


Stap 8:
De volgende iptables regels moeten worden toegevoegd:

*filter
-N iTV_fwd
-N iTV_in
-A FORWARD -i eth1.1921 -j iTV_fwd
-A FORWARD -i eth0.4 -j iTV_fwd
-A INPUT -i eth0.4 -j iTV_in
-A iTV_fwd -i eth0.4 -m pkttype --pkt-type multicast -j ACCEPT
-A iTV_fwd -d 10.84.86.0/24 -i eth0.4 -j ACCEPT
-A iTV_fwd -o eth0.4 -j ACCEPT
-A iTV_fwd -o ppp0 -j ACCEPT
-A iTV_fwd -j REJECT
-A iTV_in -m pkttype --pkt-type multicast -j ACCEPT

*nat
-A POSTROUTING -s 10.84.86.0/24 -o eth0.4 -j MASQUERADE

*raw
-A PREROUTING -d 224.0.0.0/4 -i eth0.4 -p udp -m ttl --ttl-lt 7 -j ACCEPT


Stap 9:
Nog één ding te doen. Wijzig in de ProSAFE Plus utility het ID voor IGMP Snooping van ‘4’ naar ‘1921’

Sluit het iTV kastje aan en als het goed is start deze helemaal door, krijg je langer dan 10 seconden beeld en heb je ook weer een menu.
 

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?


... hoewel ik geen TV heb en me blijf verbazen over de methode van TV-stream distributie richting de klant ...

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.


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

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.


..., 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.

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).


..., 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.

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.

 

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.

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).

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.


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

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.

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.


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.

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 :wink:


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.

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.


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.

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.


Hoe KPN zn hoofdnetwerk ingedeeld heeft, dat doet hier niet terzake. Het is behrijpelijk dat kpn op zn hoofdnetwerk 1 dezelfde stream niet 1000 x over dezelfde verbinding laat lopen. Maar dat doet er niet toe. Het gaat erom hoe het in de meterkast aan komt bij het modem. Dat gedoe met vlans en igmp 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.


Om het af te maken: het is mij verteld dat de bandbreedte van mijn contract inclusief de bandbreedte voor TV zou zijn. 

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.

 

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.

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.

 

Het is gewoon hopeloos oude troep bij KPN, wat je ook kunt zien aan dat malle PPPoE, ...

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).


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.

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 :blush:

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 ... :thinking:  maar werkt wel leuk :yum: En allicht zuiniger dan vroeger, toen had ik wel 3 of 4 van die antieke systeemkasten draaien, nu maar 1 :joy:  


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. 

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.


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. 

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.

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 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.

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.

 

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.

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

   

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.

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.

   

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?

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.

    

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

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

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).

   

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

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.


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.

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).


 

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.

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

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

 

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.

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.


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.

Omdat de downstream zijde van de IGMP proxy gedefinieerd is op een vlan 8486 (die we natuurlijk niet 1 op 1 overnemen :wink: ) 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”).