Help: queues on IPTV do not work

RouterOS General
1

Hello,

appologies in advance as I am but a novice trying to mess about with my home network, but I am stumped with queues and I am possibly misunderstanding the documentation on this. Searching for similar problems also did not lead to a resolution, possibly due to different models being used in those threads, different ways IPTV is transmitted or I am blind and not seeing something.

I wish to set up queues to make sure my IPTV always has priority over anything else on the network. I have a RB750Gr3 and I was told my ISP that I just need to put the STB on VLAN 6, which is what I did with a bridge (as I understood the MT7621 does not support the other method which is to set it up on the switch). This bit works fine

[admin@MikroTik] /interface> bridge print
Flags: X - disabled, R - running 
 0 R name="bridge-iptv" mtu=auto actual-mtu=1500 l2mtu=1592 arp=enabled arp-timeout=auto mac-address=48:8F:5A:58:CD:42 protocol-mode=rstp fast-forward=no igmp-snooping=no auto-mac=yes ageing-time=5m priority=0x8000 max-message-age=20s 
     forward-delay=15s transmit-hold-count=6 vlan-filtering=no dhcp-snooping=no 

 1 R ;;; defconf
     name="bridge-main" mtu=auto actual-mtu=1500 l2mtu=1596 arp=enabled arp-timeout=auto mac-address=48:8F:5A:58:CD:3F protocol-mode=rstp fast-forward=no igmp-snooping=no auto-mac=no admin-mac=48:8F:5A:58:CD:3F ageing-time=5m priority=0x8000 
     max-message-age=20s forward-delay=15s transmit-hold-count=6 vlan-filtering=no dhcp-snooping=no 
[admin@MikroTik] /interface> bridge port print
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload 
 #     INTERFACE                                                                                      BRIDGE                                                                                     HW  PVID PRIORITY  PATH-COST INTERNAL-PATH-COST    HORIZON
 0     ;;; defconf
       ether2                                                                                         bridge-main                                                                                yes    1     0x80         10                 10       none
 1     ;;; defconf
       ether3                                                                                         bridge-main                                                                                yes    1     0x80         10                 10       none
 2 I   ;;; defconf
       ether4                                                                                         bridge-main                                                                                yes    1     0x80         10                 10       none
 3     ;;; defconf
       ether5                                                                                         bridge-iptv                                                                                yes    1     0x80         10                 10       none
 4     vlan-iptv                                                                                      bridge-iptv                                                                                       1     0x80         10                 10       none
[admin@MikroTik] /interface> vlan print
Flags: X - disabled, R - running 
 #   NAME                                                                                                        MTU ARP             VLAN-ID INTERFACE                                                                                                     
 0 R vlan-iptv                                                                                                  1500 enabled               6 ether1

In order to create queues I understood that I need to mark the packets, so I disabled fast track rule on the firewall and disabled it on the bridge (not sure if that was necessary since the firewall rule seems to allow mangle to pick up everything anyway). I then set up mangle rules like this:

3    chain=prerouting action=mark-packet new-packet-mark=main-packet passthrough=yes src-address=192.168.88.0/24 dst-address=192.168.88.0/24 log=no log-prefix="" 
4    chain=prerouting action=mark-packet new-packet-mark=iptv-packet passthrough=yes in-interface=bridge-iptv log=no log-prefix=""

and I can see the traffic matches what I see on the interface. The problem is when I try to create queues. No matter how I change the settings, the queue shows no packets at all (I also tried a simple queue and just poiint it to ether5 and the iptv bridge for the target but that also does not show any traffic matching the queue)

[admin@MikroTik] /queue> tree print
Flags: X - disabled, I - invalid 
 0   name="iptv" parent=global packet-mark=iptv-packet limit-at=0 queue=default-small priority=1 max-limit=0 burst-limit=0 burst-threshold=0 burst-time=0s bucket-size=0.01

Am I missing something or does this mean that with my configuration I have no way to prioritize this traffic over others?

2

Quite possibly yes. You need to define “IPTV” in your local context before you can mark its streams with anything better than guesswork and cargo-cult solutions. Not all “IPTV” operates the same way, so a solution meant for one system won’t always work for another.

I could tell you how I define “IPTV” here, but that doesn’t help if your local IPTV system doesn’t work the same way.


[admin@MikroTik] /interface> bridge print
0 R name=“bridge-iptv”…
1 R name=“bridge-main”…

>

Two bridges per switch chip is likely a mistake. Excepting only the CRS1xx/2xx devices, ROS devices support only one hardware-offloaded bridge per switch chip. Your router has only one switch chip, so you get only one hardware-offloaded bridge.

RouterOS will let you define additional bridges, but they end up loading the CPU. You see this in the next command, where none of the bridge ports are marked with "H" flags.

I would've thought _some_ of the bridge ports would end up offloaded under this configuration, but you've managed to get _all_ off them kicked off the switch chip, somehow. That's a feat, of sorts. Congratulations. 🙄

To implement your ISP's recommendation "to put the STB on VLAN 6," that translates into RouterOS speak as "implement bridge VLAN filtering so VLAN 6 packets from the Internet go to the STB ports, and vice versa." This directs IPTV traffic to appropriate destination ports while keeping that traffic from loading ports where it cannot possibly have a valid recipient.

That suggests one way to solve this: put the queue on the non-IPTV ports only, reserving some amount of bandwidth under your data rate cap for the IPTV ports. That is, if each IPTV stream maxes out at 20 Mbit/sec and your data rate cap is 100 Mbit/sec, you could configure the other ports to have a max aggregate bandwidth of 60 Mbit/sec since you have two STBs, ether4 and ether5 in your example.

If 20 Mbit/sec seems unreasonably high, it's actually a common value due to cable TV channel map standards, ATSC, DVB and so forth. If you can't get your provider to admit how high it can go, measure flow rates on a premium 1080p channel. Measuring on a basic channel will often give lower values, since they pack multiple logical streams per physical "channel" to get everything into the space available.
\
<br>
> I disabled fast track rule on the firewall and disabled it on the bridge (not sure if that was necessary since the firewall rule seems to allow mangle to pick up everything anyway

I believe that's a further consequence of the first problem: by shifting everything to the CPU, you've effectively disabled fasttrack already.
\
<br>
> new-packet-mark=main-packet passthrough=yes src-address=192.168.88.0/24 dst-address=192.168.88.0/24

I'm not sure what you're trying to accomplish with that rule, but what it does is marks all intra-LAN traffic (from local IP to local IP) as "main-packet". It says nothing of traffic to/from the Internet. Surely you want something broader, having the effect "not IPTV."
\
<br>
> new-packet-mark=iptv-packet in-interface=bridge-iptv

Following the above advice takes the second bridge away, so I predict that your next question is, "How do I mark the IPTV packets, then?"

I suggested one way above: don't mark IPTV at all. Instead, mark non-IPTV, then limit that with queues to a value that gives IPTV enough space to work without dropping packets.

Another way will fall out of answering my first questions to you. The local definition of "IPTV" may suggest something. For instance, if IPTV on your ISP's system is on multicast IP 239.255.0.0/16, UDP port 1234, that directly suggests the mangle rule you need.
3

This rule was just something that got changed when I was messing around

new-packet-mark=main-packet passthrough=yes src-address=192.168.88.0/24 dst-address=192.168.88.0/24

It was actually meant to be

chain=prerouting action=mark-packet new-packet-mark=main-packet passthrough=yes dst-address=192.168.88.0/24 log=no log-prefix=""

And I had reverted back to it later, not that it was doing me much good (I did not have problems with mangle marking IPTV and non-IPTV traffic, just that queues do not pick up the IPTV traffic for prioritization)

I would’ve thought some of the bridge ports would end up offloaded under this configuration, but you’ve managed to get all off them kicked off the switch chip, somehow. That’s a feat, of sorts. Congratulations. > :roll_eyes:

To be honest all I did was add a new bridge, VLAN 6 and assigned eth5 and the vlan to the bridge based on some older instructions from the same provider for MikroTik devices (couldn’t even find the same source now, but was for Telia in Estonia and there are other examples such as this one https://www.ccisrd.eu/trainings/hands-on/mikrotik-router-and-telia-iptv/ which basically covers what I did)

My idea was that I would flag IPTV traffic and non-IPTV traffic and try to use queue tree to prioritize traffic for IPTV over any non-IPTV traffic. The reason is that I had tried to limit traffic towards 192.168.88.0/24 however I have a 1 Gbps connection (speedtest shows it goes up to ~930 Mbps with fast track enabled), but when I disable fast track even putting a limit of 600 Mbps is not enough to avoid IPTV stutters. Though to be honest only after reading your post it dawned on me to look at the CPU load and it was ~82% so I guess the router is just not capable of handling queues for such a bandwidth? I am wondering if it’s possible to creates queues without disabling fast track. I found this https://wiki.mikrotik.com/wiki/TransparentTrafficShaper#Bridge and tried creating mangle rules like this

3    chain=prerouting action=mark-connection new-connection-mark=main-connection passthrough=yes dst-address=192.168.88.0/24 log=no log-prefix="" 
4    chain=prerouting action=mark-packet new-packet-mark=iptv-packet passthrough=no connection-mark=iptv-connection log=no log-prefix="" 
5    chain=prerouting action=mark-packet new-packet-mark=main-packet passthrough=yes connection-mark=main-connection log=no log-prefix="" 
6    chain=prerouting action=mark-connection new-connection-mark=iptv-connection protocol=udp dst-port=1234 log=no log-prefix=""

Also based on your comments on the bridge I disabled the iptv bridge, put eth5 and vlan6 on the main bridge and seems like everything works fine as well. Did I understand correctly that this would be the prefferable configuration?

EDIT: did some reading, I suspect I can’t really get away with what I want to achieve with this router. In order to properly utilize my connection I must have fast track on, however fast track will immediately cut it more or less in half, which I will then have to limit once again. I suppose I might as well just put on limits on individual devices where applicable

4

Yes, and I’m telling you that it’s possible to do everything you want with one bridge + bridge VLAN filtering.


I guess the router is just not capable of handling queues for such a bandwidth?

The hEX is indeed borderline for gigabit class speeds. It’s possible, but only within limits on configuration complexity.

A hAP ac² would be better at pushing this level of traffic, with its quad-core ARM CPU.


even putting a limit of 600 Mbps is not enough to avoid IPTV stutters.

It isn’t entirely about bandwidth. IPTV systems tend to be UDP-based, so there is no retransmission in the face of excess latency. If your stream is 30fps, every frame has to get to its endpoint in no more than one thirtieth of a second. (33 ms) Each and every time.

59.94 fields per second for 1080i instead? Okay, now your max packet jitter is down to 17 ms.

Instead of simple queues, maybe what you need is intelligent ones like fq_codel or CAKE, to keep bufferbloat down.


I am wondering if it’s possible to creates queues without disabling fast track.

No. Quoting the relevant docs, “…be sure the FastTrack rule is disabled for this particular traffic, otherwise, it will bypass Simple Queues and they will not work.”

Queues push the traffic through the CPU, by their nature: the switch chip isn’t nearly smart enough to do proper queueing. The best you can get down at the hardware level is crude rate-limiting.

Contrast FastTrack, which exists to help traffic bypass the CPU once the firewall’s made a decision about it.

You get to pick one, not both.


Also based on your comments on the bridge I disabled the iptv bridge, put eth5 and vlan6 on the main bridge and seems like everything works fine as well. Did I understand correctly that this would be the prefferable configuration?

There are good reasons to have 2+ bridges on a single-switch-chip device, but I don’t see that this is such a case.

5

Thanks for the help, will look into trying cake and fq_codel again (the whole reason why I was trying to get queues working was because I thought that was not supported on these devices) and if that fails either just get a better router (sadly my ingress is in a tight space that does not allow for routers much larger without making a mess) or just work with per device limits from the device end (or maybe switch my RT-AC68U back to router mode and use that to limit)