Need some help to priority L2TP first packet first rule ( traffic limit, queues not helped )
Scenario:
Ether1 (WAN) 100Mbits up/down
Ether2 (LAN - DHCP) -WIFI AP
Ether3 (LAN - DHCP) - PC
Ether5 (L2TP-eoip tunnel) IPTV stream to iptv-set top box
Problem is that L2TP iptv stream freezing and skips
L2TP packets are marked.
Tried to limit speed on 192.168.88.0/24 80Mbits max or 50Mbits max and prioriti 8 - limiter is working but still iptv stream over L2TP still not working correctly. (pcq, pfifo, red)
L2TP queue 20Mbits max and priority 1. (Stream is 6-8 Mbits)
If no download, youtube etc, then iptv stream will working properly
You need to use queues that limit the traffic.
I presume your PC and WiFi are saturating your download and not enough bandwidth is left for the L2TP.
Of course the optimal solution would be to mark and prioritize on the other side of your 100Mb link (at the ISP).
When this is not possible, you have to do it locally on your own outputs.
With 3 different output networks this is going to be a bit tricky…
I put it limit on 192.168.88.0/24 50Mbits and limit was working well (speedtest.net) - there was left plenty of traffic speed for L2TP (50 Mbits), iptv stream needs only below 10Mbits.
IPTV on L2TP is continuous UDP flow and must be always priority1 IN ether1 and OUT ether5.
If I just surfing on internet then no affect on iptv stream, but doing some download, then iptv freez.
Mikrotik is RB450G
Maybe solution is use switch with port base vlan-s with low and high priority ? Mirkotik ether2 - to- switch port1 vlan1 (low priority), out port 2-3 to PC and wifi AP. Mikrotik ether5 -to- switch port 4 vlan2 (high priority) out port 5 to set up box.
The problem is most likely not occurring in your router, but in the router of the ISP.
It has too large queues (buffer bloat).
When you start downloading from the PC at 100 Mbit/s it puts so many packets in the queue that
the low-rate traffic for the TV gets delayed too much.
This is really something that the ISP should fix, but often it can be fixed by putting a lower rate
traffic limit on the other (PC) output. There should be no bursting in that queue and a reasonably
small queue buffer. When this does not help, there is little you can do, it is not a local problem I think.