Need assistance re VoIP Prioritization

RouterOS General
1

@sindy, and other VoIP/TCP experts,

If you do not mind giving me feedback on the below as a “quick fix” for prevent downloads affecting voip traffic, in a nusthell, client have 20Mb/20Mb fibre connection, onsite SIP/PBX device and about 8 onsite extensions, I have set bandwidth limits for up and down and allocated bandwidth and priorities to/from the SIP/PBX device and rest of network.

Also, how do I set the “passthrough=yes/no” on these mangle rules?

/ip firewall mangle
add chain=prerouting src-address=<SIP/PBX device IP> action=mark-connection \
new-connection-mark=voip_con
add chain=forward connection-mark=voip_con action=mark-packet  \
new-packet-mark=voip_pkt
add chain=prerouting src-address=<LAN Subnet> connection-mark=no-mark action=mark-connection \
new-connection-mark=other_con
add chain=forward connection-mark=other_con action=mark-packet  \
new-packet-mark=other_pkt

/queue tree
add name=Main_Q1 parent=ether1 max-limit=19M 
add name=Voip_Q1 parent=Main_Q1 max-limit=19M limit-at=2M priority=1 \
packet-mark=voip_pkt
add name=Other_Q1 parent=Main_Q1 max-limit=19M limit-at=17M priority=7 \
packet-mark=other_pkt
add name=Main_Q2 parent=ether4 max-limit=19M 
add name=Voip_Q2 parent=Main_Q2 max-limit=19M limit-at=2M priority=1 \
packet-mark=voip_pkt
add name=Other_Q2 parent=Main_Q2 max-limit=19M limit-at=17M priority=7 \
packet-mark=other_pkt

Thanking you in advance.

2

This should work, but…

if you leave the “other” as is → “no-mark”

  1. less cpu usage as bulk will be left alone
  2. you could use FastTrack for that “other” / “no-mark” traffic

Ps: also, you don’t need limits set on the child queue, they will get bandwidth based on their pirority,
unless a guaranteed bandwidth is needed => set limit-at
unless max limit should be used => set max-limit

3

Thank you sebastia,

Eish, you guys are clever, I am learning a lot here. This coming Monday I will start with MTCTCE course and then shortly after that I will do MTCRE, hopefully I will catch up with you clever guys :slight_smile:

Keep up the good work and thank you again

4

Err… I am afraid @Sebastia didn’t have the full context. If I haven’t missed something, what he suggests would go against your goal as it would actually let anything but the VoIP traffic bypass the bandwidth control and would rate-limit the VoIP traffic alone.

You need to do the reverse - set no limit for the VoIP packets but limit all the other traffic to a maximum of about 17 Mbytes/s in your case. So @Sebastia’s idea how to simplify your configuration remains the same except that you’ll set no mark to the VoIP traffic and thus let it bypass the queueing:

/ip firewall mangle
add chain=prerouting src-address=!<SIP/PBX device IP> protocol=tcp action=mark-connection new-connection-mark=non_voip_con
add chain=forward connection-mark=non_voip_con action=mark-packet new-packet-mark=non_voip_pkt

etc.

A crucial moment is that the queues would perform rate equalizing rather than rate limiting as described here. The problem is that I haven’t understood from that page how exactly to achieve that :frowning:

Rate limiting by dropping what exceeds the limit is fine if you do it before the bottleneck. Rate limiting by dropping after the bottleneck only causes more load on the line because TCP retransmits the dropped packets. And any treatment of UDP packets typically changes nothing except the user experience because the sender has no feedback about what happens further downstream. That’s why I have added “protocol=tcp” to the rule above.

So try to set up your mangle rules and the queue the way you’ve suggested with those simplifications by @Sebastia corrected by me and see whether it has a positive effect on how your users can hear the remote parties and, if possible, use packet sniffing and Wireshark to see how many retransmissions happen on the TCP sessions. Each TCP session is likely to begin with a burst which the queue may not be able to accommodate completely, but if during the “stable” phase of the download there remains a lot of packet retransmissions, it is a warning sign that the queue is dropping the packets immediately rather than delaying them.

5

Hi Sindy

Actually no, what I understood is to limit the whole traffic with priority for voip.

Than can exactly be achieved with what I suggested.

The second / lower prio queue needs to match then on “no-mark” mark. So anything that isn’t marked will go in second queue en be rate limited to 19-voip bandwidth. And that traffic can be fasttracked as no mangling is needed.

Try it out if you don’t believe me :wink:

Like so:
https://forum.mikrotik.com/download/file.php?mode=view&id=30609
Queues.jpg

6

I didn’t know that fasttracking bypasses only firewall rules, not queues, my bad.

7

FT doesn’t bypass firewall, you need to mark connection for FT IN firewall.

FT does bypass mangling.

PS: And FT will bypass simple queues, but not the queues attached to interfaces.

8

I knew I’ve seen it somewhere that FT bypasses queues as well.
As I’ve thought so far that queues attached to interfaces can only be used for traffic being sent out through the interface, I didn’t deem this exception relevant to this use case.

9

A crucial moment is that the queues would perform rate equalizing rather than rate limiting as described here. The problem is that I haven’t understood from that page how exactly to achieve that > :frowning:

Today’s reading has led to much better comprehension. Rate equalization and rate limiting are just extremes of a single behaviour for unlimited queue length and zero queue length respectively. To tweak that, you need to adjust the pfifo-limit or bfifo-limit of the queue “type” you use for that particular queue.

10

Even more broadly, any queue with memory can be used for equalisation. No memory only rate limitation.