Community discussions

 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8233
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

Re: Using RouterOS to prioritize (Qos) traffic for a Class C net

Tue Jan 08, 2019 10:31 am

Should this topic be moved to Useful user articles forum?
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

For every complex problem, there is a solution that is simple, neat, and wrong.

MikroTik. Your life. Your routing.
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 932
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to prioritize (Qos) traffic for a Class C net

Wed Jan 09, 2019 12:18 am

Should this topic be moved to Useful user articles forum?

I would like to rewrite it, make it a little easier to follow.
 
pegasus123
Frequent Visitor
Frequent Visitor
Posts: 55
Joined: Tue Jul 24, 2018 7:02 am

Re: Using RouterOS to prioritize (Qos) traffic for a Class C

Fri Jan 25, 2019 12:27 pm

I'm a little curious why you have some rules twice

ros code

/ip firewall mangle
add chain=forward action=mark-connection protocol=udp   src-address=192.168.100.5 connection-state=new new-connection-mark="VOIP" comment="IP-PBX"
add chain=forward action=mark-packet     passthrough=no connection-mark="VOIP"    new-packet-mark="VOIP"
add chain=forward action=mark-connection protocol=udp   dst-address=192.168.100.5 connection-state=new new-connection-mark="VOIP"
add chain=forward action=mark-packet     passthrough=no connection-mark="VOIP"    new-packet-mark="VOIP"
 
You are marking packets twice based on the same options. In my opinion rule 2 can be removed.
Then first there are two rules marking the connection and setting connection-marks. Then use the connection-mark to mark the packets in one single rule.

This two rules are not the same... src/dst address are in use :)
isn't it enough to just mark it once? once a packet is read, it will be marked with connection mark, connection mark works both ways upload and download in which case you can mark the packet and be used in queue tree.

is my understanding correct?
 
sindy
Forum Guru
Forum Guru
Posts: 2698
Joined: Mon Dec 04, 2017 9:19 pm

Re: Using RouterOS to prioritize (Qos) traffic for a Class C

Fri Jan 25, 2019 4:33 pm

is my understanding correct?
Your understanding is correct in terms that the rule translating connection-mark into packet-mark may be there only once (as the last one after the two assigning the connection-mark). Regarding the need for two rules assigning the connection-mark, it is a more complex question.

One approach would be to have only one such rule (for src- or dst-address) and say that if a single packet in the "wrong" direction doesn't get connection-marked, it causes no harm as the first subsequent packet in the opposite direction will fix this. The other approach, however, is to save CPU by having the connection-mark->packet-mark translation rule before the connection-marking rules so that these rules would only handle packets belonging to not yet marked connections. And this is usually combined with allowing these rules to handle only the initial packet of each connection (connection-state=new), so then you need to use both rules because you don't know in advance which RTP packet will be the first one in a given call.

And of course, the translation rules have to be doubled in the latter case - the first one handles packets belonging to already marked connections early in the chain, and the other one has to be there to handle the translation for the initial packets after the connection-mark has been just assigned.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
pegasus123
Frequent Visitor
Frequent Visitor
Posts: 55
Joined: Tue Jul 24, 2018 7:02 am

Re: Using RouterOS to prioritize (Qos) traffic for a Class C

Sat Jan 26, 2019 5:49 am

is my understanding correct?
Your understanding is correct in terms that the rule translating connection-mark into packet-mark may be there only once (as the last one after the two assigning the connection-mark). Regarding the need for two rules assigning the connection-mark, it is a more complex question.

One approach would be to have only one such rule (for src- or dst-address) and say that if a single packet in the "wrong" direction doesn't get connection-marked, it causes no harm as the first subsequent packet in the opposite direction will fix this. The other approach, however, is to save CPU by having the connection-mark->packet-mark translation rule before the connection-marking rules so that these rules would only handle packets belonging to not yet marked connections. And this is usually combined with allowing these rules to handle only the initial packet of each connection (connection-state=new), so then you need to use both rules because you don't know in advance which RTP packet will be the first one in a given call.

And of course, the translation rules have to be doubled in the latter case - the first one handles packets belonging to already marked connections early in the chain, and the other one has to be there to handle the translation for the initial packets after the connection-mark has been just assigned.
Thanks for the detailed explanation!
 
User avatar
denisun
newbie
Posts: 45
Joined: Wed Jul 16, 2014 6:38 pm
Location: Greece

Re: Using RouterOS to prioritize (Qos) traffic for a Class C net

Fri Feb 08, 2019 8:56 am

I am also writing here because I have not found a solution.
Has anyone managed to give priority to VoIP, and to work with no problem, with full load on the line?
My problem is this.
"What one programmer can do in one month, two programmers can do in two months."
Fred Brooks...
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 932
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to prioritize (Qos) traffic for a Class C net

Fri Feb 08, 2019 3:13 pm

I am also writing here because I have not found a solution. Has anyone managed to give priority to VoIP, and to work with no problem, with full load on the line? My problem is this.

Someday, I hope to do another write up on this subject, when I get time. I had hoped that one would not need to be an expert to get this correct, but as of 2019, it still does. However, I think a better article would help.

From the moment that audio transmits from your equipment, until it gets back, there must not be greater than a 150ms interruption (or thereabout) otherwise you will notice the delay. Now, think about everything that an audio packet has to go through to make that happen. When you understand that, you'll have solved your VoIP issue.

The permanent fix, a separate Internet service line. Can't do that? Then fast hardware performing QoS where VoIP packets get the best treatment when bad things happen (and they will).

:-)
 
User avatar
denisun
newbie
Posts: 45
Joined: Wed Jul 16, 2014 6:38 pm
Location: Greece

Re: Using RouterOS to prioritize (Qos) traffic for a Class C net

Fri Feb 08, 2019 4:13 pm

I am also writing here because I have not found a solution. Has anyone managed to give priority to VoIP, and to work with no problem, with full load on the line? My problem is this.

Someday, I hope to do another write up on this subject, when I get time. I had hoped that one would not need to be an expert to get this correct, but as of 2019, it still does. However, I think a better article would help.

From the moment that audio transmits from your equipment, until it gets back, there must not be greater than a 150ms interruption (or thereabout) otherwise you will notice the delay. Now, think about everything that an audio packet has to go through to make that happen. When you understand that, you'll have solved your VoIP issue.

The permanent fix, a separate Internet service line. Can't do that? Then fast hardware performing QoS where VoIP packets get the best treatment when bad things happen (and they will).

:-)
I have a CRS109-8G.
I can not believe that my provider's simple modem/router equipment work perfect with VoIP packets and full load
and the MT have problem.
My question is...
- Have i somewhere wrong in mangles, tree or queue types?
- Is MT hw low specifications and can't process the load?
- Is ROS bug?
With ubiquity the result is much perfect.
"What one programmer can do in one month, two programmers can do in two months."
Fred Brooks...
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 932
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to prioritize (Qos) traffic for a Class C net

Fri Feb 08, 2019 4:50 pm

I have a CRS109-8G. With ubiquity the result is much better.

I would not use the CRS109 for QoS tasks. Too under powered in my opinion. However, there are many variables.
 
User avatar
denisun
newbie
Posts: 45
Joined: Wed Jul 16, 2014 6:38 pm
Location: Greece

Re: Using RouterOS to prioritize (Qos) traffic for a Class C net

Fri Feb 08, 2019 7:26 pm

I have a CRS109-8G. With ubiquity the result is much better.

I would not use the CRS109 for QoS tasks. Too under powered in my opinion. However, there are many variables.
I don't believe that the problem is the hw specifications of CRC.
My ISPs equipment cost ~20-50e and work perfect with traffic (VoIP and dw).
"What one programmer can do in one month, two programmers can do in two months."
Fred Brooks...
 
bolean
just joined
Posts: 5
Joined: Fri Apr 13, 2018 2:45 pm

Re: Using RouterOS to prioritize (Qos) traffic for a Class C net

Sat Feb 23, 2019 3:08 pm

version 3, running smooth

Image
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Topic Author
Posts: 932
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Using RouterOS to prioritize (Qos) traffic for a Class C net

Sat Feb 23, 2019 6:43 pm

Version 3, running smooth

@bolean,

How does this test compared to what you're doing?

Image

/queue tree

# DOWN
add max-limit=90M name=DOWN parent=bridge1 queue=default

add name="1. VOIP" packet-mark=VOIP parent=DOWN priority=1 queue=default
add name="2. ACK" packet-mark=ACK parent=DOWN priority=1 queue=default
add name="3. DNS" packet-mark=DNS parent=DOWN priority=2 queue=default
add name="4. UDP" packet-mark=UDP parent=DOWN priority=3 queue=default
add name="5. ICMP" packet-mark=ICMP parent=DOWN priority=4 queue=default
add name="6. HTTP" packet-mark=HTTP parent=DOWN priority=5 queue=default
add name="7. HTTP_BIG" packet-mark=HTTP_BIG parent=DOWN priority=6 queue=default
add name="8. QUIC" packet-mark=QUIC parent=DOWN priority=7 queue=default
add name="9. OTHER" packet-mark=OTHER parent=DOWN priority=8 queue=default

# UP
add max-limit=90M name=UP parent=ether1 queue=default

add name="1. VOIP_" packet-mark=VOIP parent=UP priority=1 queue=default
add name="2. ACK_" packet-mark=ACK parent=UP priority=1 queue=default
add name="3. DNS_" packet-mark=DNS parent=UP priority=2 queue=default
add name="4. UDP_" packet-mark=UDP parent=UP priority=3 queue=default
add name="5. ICMP_" packet-mark=ICMP parent=UP priority=4 queue=default
add name="6. HTTP_" packet-mark=HTTP parent=UP priority=5 queue=default
add name="7. HTTP_BIG_" packet-mark=HTTP_BIG parent=UP priority=6 queue=default
add name="8. QUIC_" packet-mark=QUIC parent=UP priority=7 queue=default
add name="9. OTHER_" packet-mark=OTHER parent=UP priority=8 queue=default

Who is online

Users browsing this forum: No registered users and 1 guest