Dat zou gewoon moeten werken, ik ben de laatste week aan het testen geweest met OPNsense en PFsense waar de core linux is. Het opbouwen van de connectie via pppoe is geen probleem, de uitdaging zit meer in het stabiel krijgen van de routed iptv gedeelte en de proxy server in bovenstaande opensource sw. Mogelijk heb je aan deze link wat, deze is minder oud dan de link die jij hebt meegegeven. Ik probeer nu, tot ergernis van de rest van de familie, Sophos XG home edition aan de praat te krijgen met IPTV, maar als ik alle reviews lees gaat dit waarschijnlijk zonder al te veel gerommel niet lukken.

https://blog.affien.com/archives/2015/05/28/setup-ubuntu-ipv4ipv6-router-for-vlan-tagged-pppoe-internet-connection/comment-page-1/

PPPoE is gelukt. Dat was redelijk straightforward;

# Minimalistic default options file for DSL/PPPoE connections

noipdefault
defaultroute
replacedefaultroute
hide-password
#lcp-echo-interval 30
#lcp-echo-failure 4
noauth
persist
#mtu 1412
mtu 1500
#maxfail 0
#holdoff 20
plugin rp-pppoe.so eth0.6
user "kpn"

Alleen het routeren gaat heel raar. Op de Linux bak zelf doet alles het. Als ik via de Squid proxy daar mee werk, gaat het ook goed. Maar als ik gewoon masquerade dan doet de 80% van alles sites het niet. 

Edit: De MTU op de Ubuntu box aanpassen naar 1452 lijkt het op te lossen.

   # Minimalistic default options file for DSL/PPPoE connections

noipdefault
defaultroute
replacedefaultroute
hide-password
#lcp-echo-interval 30
#lcp-echo-failure 4
noauth
persist
#mtu 1412
mtu 1500
#maxfail 0
#holdoff 20
plugin rp-pppoe.so eth0.6
user "kpn"

Das mooi. waar draai je dit op?, heb je nog andere NIC's in het systeem zitten waar het verkeer naar toe gerouteerd wordt?  

EDIT: en is het niet verstandiger om bovenstaande (Pfsense/OPNsense pakketten te gebruiken, zo heb je wat meer controle over de firewall rules

Dit draait op Ubuntu server 18.04 LTS.

De Firewall is een Firehol configuratie. Die heb ik zelf opgesteld, veel diepere controle dan dit handwerk ga ik niet krijgen. Er zit nog 1 fysieke ander NIC in die doos en een Wireguard VPN, een LXC instance en wat docker spul, plus natuurlijk router zijn voor het lokale netwerk. Dat netwerk heeft een paar smart switches en wat Wifi AP's nog.

The MTU op 1452 lijkt voor bijna alles sites genoeg. Behalve dit KPN forum, dan moet het nog lager, maar hoeveel precies ben ik aan het uitzoeken nog. Wellicht dat tcpmss aanzetten kan werken, maar tot nu toe nog niet.

Later eens kijken of we ook IPTV geregeld kunnen krijgen. For the record, dit is de werkende config;

noipdefault
defaultroute
replacedefaultroute
hide-password
#lcp-echo-interval 30
#lcp-echo-failure 4
noauth
persist
mtu 1452
#maxfail 0
#holdoff 20
plugin rp-pppoe.so eth0.6
user "kpn"

  noipdefault
defaultroute
replacedefaultroute
hide-password
#lcp-echo-interval 30
#lcp-echo-failure 4
noauth
persist
mtu 1452
#maxfail 0
#holdoff 20
plugin rp-pppoe.so eth0.6
user "kpn"

Mogelijk heb je wat aan deze MTU waardes, deze komen vanuit het script wat wjb heeft gemaakt. grootste gedeelte van mijn Vlans en subnets zijn op dit moment inactief gezien alles ligt te pitten en ik ook niet meer aan het werk ben;-)

Op de PFsense config staat overigens alles op MTU1500 en dat werkt ook

@wjb  ik heb nog even zitten debuggen en sniffen op het WAN, ik heb denk ik nog een verbetering voor op de Edge Routers.

• Je hebt 802.1P/COS → een QoS waarde in een VLAN header (is link local, en wordt dan overgenomen in remote device zoals straatkast waarna deze kast weer acties onderneemt)
• Je hebt DCSCP → een QoS waarde in een IP header (blijft behouden over hele internet)

https://www.kpn-wholesale.com/w3/file?uuid=4c656652-c579-404f-882a-b23e03ee95e0&owner=a7c50efb-c547-48a2-99c7-81c55be15337&contentid=24082

FritzBox op mijn toenmalige KPN aansluiting

2: name iptv 2: sync_group: sync_dsl 2: iface ptm0 RBE/18/dsl 9c:c7:a627:3d stay online 1 vlan 4 prio 5 2: IPv6: off

0: name internet 0: sync_group: sync_dsl 0: iface ptm0 PPPoE/26/dsl 9c:c7:a627:3b stay online 1 vlan 6 prio 1 (prop: default internet) (prop6: default internet) 0: IPv6: native unnumbered (ia_pd)

FritzBox configuratie zie je dat Internet =1 en IPTV =5

Als ik snif met de ERL op BudgetThuis (Telfort profiel) dan zie je dat IGMP binnenkomt met vlan 4 en internet met vlan 34. Uiteindelijk staat er bij mij een bridge modem Vigor 130 die alles 1op1 doorzet. Ik heb geen IPTV waardoor ik deze mapping niet kan testen iemand die wil sniffen? Iemand met IPTV kan testen dmv een wireshark capture dan kunnen we die config voor IPTV ook bijwerken naar COS=5 zoals WBA/Fritzbox ook doen.

Snif commando:

run sudo tcpdump -i eth0 -w /home/ubnt/kpn.pcap
 

Als ik de default config van de ERL bekijk dan verstuurt hij alles met COS=0 en stuurt KPN al het internet terug over WBA met COS =1. Omdat te verhelpen heb ik op de ERL het verkeer uitgaand ook gemapped met COS 1. In feite overschrijf je COS 0→1 met dit onderstaande commando.

 set interfaces ethernet 2 vif 34 egress-qos "0:1"

Na deze aanpassing is ook het egress verkeer gemarkeerd met 1 ipv 0

IPTV:  

Als de IGMP requests (zappen) uitgestuurd worden met 0 is onderstaande config goed

set interfaces ethernet 2 vif 4 egress-qos "0:5”

Mooi zou zijn als iemand even kan sniffen tijdens het zappen en mij die file kan laten lezen zonder aanpassingen, dan kunnen we zien wat de ERL al zelfstandig op de IGMP paketten markeert?

Onderstaand zou ook kunnen, dan herschrijf je 0-4 → 5

set interfaces ethernet 2 vif 4 egress-qos "0:5 1:5 2:5 3:5 4:5”

Bedoel je zoiets?

Ik gebruik met opzet geen QoS omdat daarmee geen hardware offloading meer mogelijk is en dat heeft een enorme impact op de maximale throughput van een EdgeRouter.

Haal je met hardware offloading zo'n 940Mbps op een ERL-3 terwijl dat zonder hardware offloading rond de 300Mbps blijft hangen.

Zolang de throughput van de router en het LAN hoger zijn dan de gecontracteerde bandbreedte is dat ook niet echt zinvol immers alle datapakketjes zullen dan real-time verwerkt kunnen worden.

Weet overigens dat COS waarde 1 een lagere prioriteit heeft dan COS waarde 0.

Bron.

Je kunt de COS dan ook beter op de waarde 0 laten staan.

@wjb wat jij nu door elkaar haalt is UBNT CPU QoS noem dat voor het gemak “smart queues” waarbij de router zelf meedenkt over welk pakket wanneer het beste de lijn op kan. Inderdaad dat is volledig “crap” voor je performance en moet je ook zeker niet gebruiken.

Waar ik het over heb is echte netwerk QoS, dat is een veld wat sowieso in elk vlan pakket zit. Mijn advies is, slechts,  om het met de juiste waardes te vullen en staat volledig los van CPU UBNT QoS. Je verzend die VLAN headers nu ook al met je huidige setup als je hier een reactie tikt, zonder dat je UBNT QoS aan hebt staan. Mijn advies is slechts om de waardes uit te lijnen tussen wat WBA kan verwerken en de ER verstuurd.

Het gaat misschien wat diep, maar het is mijn vak waardoor ik redelijk comfortabel in ben.

@obelisk kijk dat is interessante informatie!  Want WBA lijkt alleen 1 of 5 te ondersteunen en geen 6 ;-)

Heb je voor mij de hele pcap file in een PM zodat ik eens diep technisch kan kijken, bij voorkeur met wat veelvuldig zappen en een stukje stream van bv 1 minuut beeld? Misschien kan je de files exporteren met een IGMP / MC filter waardoor ik je unicast verkeer niet zie (privacy).

In verband met die privacy had ik ook alleen even deze snippet gepost. Wat je hier zag was de ‘idle’ multicast die via VLAN4 binnen kwam. Ik had een capture (Mikrotik → tools → packet sniffer) op ‘ether1-wan’ welke aan de FTU hangt. De capture werd vervolgens gestreamd naar een laptop met wireshark. 

Zo te zien kan ik vanuit wireshark als PCAP opslaan dus dat gedeelte zou moeten lukken. Maar ik moet er even tijd voor maken en overdag hoor ik me eigenlijk met andere dingen bezig te houden. ;)

COS waarde 0 heeft echter een hogere prioriteit dan COS waarde 1. Je kunt die mijns inziens dan ook beter op 0 laten staan.

Inkomend wordt als het goed is de COS waarde ongewijzigd doorgezet en dat is mijns inziens ook precies goed.

Uitgaand zou je mijns inziens alleen SIP/VoIP verkeer kunnen voorzien van een COS waarde 5 maar dan zit je direct aan een QoS policies immers dit kan dan niet meer op poort level.

Beter is het dan om de COS al door de VoIP ATA in te laten stellen.

Op vlan 4 (IPTV) zou wel alle communicatie op COS waarde 5 gezet kunnen worden maar de upsteam communicatie op vlan 4 is marginaal en daar zie ik dan ook geen meerwaarde.

De vraag is ook of de TV ontvangers zelf niet al de COS op 5 zetten.

Als het goed is ontbreekt er in de ethernet-frames van/naar de TV ontvangers de 802.1Q-tag. Misschien dat de ER op IPv4-layer iets met ToS field doet.

I.i.g. bij provider KPN (als WBA-klant) zal een router VLAN tags verwijderen op de weg van NTU naar LAN-apparaat. De weg de andere kant op zit in feite prioriteit al opgesloten in het VLAN ID, behalve voor SIP/VoIP buiten VLAN7 om.

@wjb nu haal je de bekende, zeer veel gemaakte, details door elkaar.

De TV ontvanger zit routed aan de LAN port van de ERL, en we spreken hier over COS waardes in het VLAN header veld. Lees: alleen toepasbaar op een link waar vlan tagging gebruikt wordt, 4,6,34.  Als een STB (product zonder VLAN tagging) een QoS DSCP waarde in het IP pakket meegeeft, zou er een translatie gedaan kunnen worden om dat pakket te transleren in COS 5 te stoppen wat WBA ondersteund.

Voor de echte 802.2P priority pakketten waar we hier over spreken is 0 echt de laagste en is 1 beter dan 0. Je doet daar een te vlugge aanname waar je mij ook wel eens van beschuldigd hebt ;-)

@obelisk ja laten we in de prive tijd ff verder gaan, ik ben erg benieuwd naar de capture.

We hebben het over precies hetzelfde hoor. 

De priority loopt inderdaad van 0 tot 7 waarbij 0 de laagste is en 7 de hoogste.

De class of service (CoS) nummering loopt, als ik wikipedia mag geloven, echter anders.

De vraag is nu dus: Heb je het in jouw oorspronkelijke bericht nu over CoS of over prority?

Het wireshark filter, waar mijn screenshots op gebaseerd zijn is: vlan.priority. 

Er is maar één 3 bits veld wat gevuld kan worden.

@wjb het lijkt nogal vendor afhankelijk, hoe ze e.a. afhandelen.

Anyway de enige houvast welke toepassing heeft op xDSL → FritzBox  gebruikt ook 1 resp 5. Dat zie ik zelf wel als een partij welke de templates in samenwerking met providers samenstellen, of is dat te voorbarig?

Wopper en ook ik willen duidelijk maken dat dezelfde principes (prioriteit, service type, etc), gespecificeerd in bitfields, op 2 lagen in de OSI network stack aan de orde zijn, zowel op DataLink layer als Network layer. In de Network layer is er bovendien verschil in bitfields, n.l. IPv4 en IPv6.

In downlink komen datapaketten gewoon binnen, dat heeft een router/CPE maar te slikken. In uplink is ook maar de vraag of een CPE daadwerkelijk iets kan beinvloeden. Anders zou iemand die ‘lekker snel wil uploaden’ de hier besproken bitfields zodanig kunnen instellen die ‘voorrang’ krijgt op internet.

Je hoeft mij niet uit te leggen dat hetzelfde QoS principe op zowel ISO layer 2 (CoS) als ISO layer 3 (DSCP) gehanteerd wordt. Overigens hebben Wopper en ik het volgens mij alleen over CoS op ISO layer 2.

 

 

Mogelijk heb je wat aan deze MTU waardes, deze komen vanuit het script wat wjb heeft gemaakt. grootste gedeelte van mijn Vlans en subnets zijn op dit moment inactief gezien alles ligt te pitten en ik ook niet meer aan het werk ben;-)

Op de PFsense config staat overigens alles op MTU1500 en dat werkt ook

Ik zie dat de FTTH daar op 1512 staat. Die staat bij mij op 1452. Die extra 12 bytes zouden het verschil kunnen zijn.

KPN hanteert op de pppoe verbinding een MTU size van 1500 bytes.

De overhead van een pppoe verbinding is 8 bytes, vandaar dat ik de MTU size van vlan 6 (eth0.6) op 1508 bytes heb staan.

De overhead van een vlan is 4 bytes, vandaar dat ik de WAN poort (eth0) een MTU size van 1512 heb gegeven.

Ook op vlan 4 (IPTV) hanteert KPN een MTU size van 1500 bytes. Hier is echter geen pppoe verbinding van toepassing en dus heb ik de MTU size van het vlan zelf (eth0.4) op 1500 staan.

Door deze instellingen zal er dus geen MTU fragmentatie plaatsvinden.

Zo dus:
 

KPN hanteert op de pppoe verbinding een MTU size van 1500 bytes.

De overhead van een pppoe verbinding is 8 bytes, vandaar dat ik de MTU size van vlan 6 (eth0.6) op 1508 bytes heb staan.

De overhead van een vlan is 4 bytes, vandaar dat ik de WAN poort (eth0) een MTU size van 1512 heb gegeven.

Ook op vlan 4 (IPTV) hanteert KPN een MTU size van 1500 bytes. Hier is echter geen pppoe verbinding van toepassing en dus heb ik de MTU size van het vlan zelf (eth0.4) op 1500 staan.

Door deze instellingen zal er dus geen MTU fragmentatie plaatsvinden.

Zo dus:

 

Precies. 

Over welke bits heb je het dan in je zin:

“De vraag is ook of de TV ontvangers zelf niet al de COS op 5 zetten.” ?

Over deze:

Ik neem aan dat je wel eens van "vlan 0 priority tagging" gehoord hebt.

Iets wat ik op mijn N300A IP ook gewoon kan instellen.

Vroeger ... toen we nog bridged IPTV hadden ... werd de CoS in ieder geval nog wel gezet.

Die ontvangers krijgen toch voornamelijk data gepushed? Is het als zodanig dan niet aan de router een eventuele prio te zetten?