Prioritising VoIP Traffic
One of the many fantastic features provided by the Mikrotik RouterOS system is the ability to differentiate and independently prioritise traffic passing through the system based on a wide variety of criteria including source and destination address and port, traffic type and protocol, and even application.
A common requirement taking advantage of this funtionality is prioritisation of interactive traffic related to real time and multimedia applications (e.g. VoIP and streaming video) over non real time traffic like mail and web. This article demonstrates how we can use the tools provided in RouterOS to always give priority to VoIP traffic above all else, so that voice calls remain crisp and continuous even while the internet uplink is congested with ftp downloads etc.
There are two basic steps to this task:
- Identify, and mark, the traffic to prioritise
- Set the priority specification
1. Identify priority traffic:
We use the Mangle Rule features of the Mikrotik RouterOS firewall system to mark packets that match our identification rules. These rules support matching of data packets according to various criteria:
- Source and Destination address: If there is a specific destination address, like a SIP server or specific client, you may want to simply prioritise all traffic headed to or from that IP address. If you choose this method, be sure to mark packets that have that address as source and destination.
- Source and destination port: Many traffic types can be readily ientified by port, such as web traffic using tcp port 80. Most VoIP protocols, however, use a wide range of ports and so would need a large number of rules to make sure that all voice traffic is covered, and probably also end up marking other traffic that is not voice related.
- TOS (type of service) data: Many VoIP vendors set the TOS bits in their IP headers to advertise traffic produced by their products. If the vendor documentation does not state what value is set for the TOS data, you can use the RouterOS packet sniffer to trap data and then use an analyser such as wireshark or ethereal to extract the TOS information. Then you can covert the TOS info to a decimal value to use in the Mangle rule.
Once you have settled on a method to identify traffic, you can begin setting up the mangle rules. In the following example, we use a pair of rules that matches all traffic passing to and from a given IP address (10.10.2.3) and marks those packets with "voip-mark" packet mark.
/ip firewall mangle add action=mark-packet chain=forward comment="mark voice packets" \
protocol=udp dst-address="10.10.1.2" disabled=no new-packet-mark=voip-mark passthrough=no
/ip firewall mangle add action=mark-packet chain=forward comment="mark voice packets" \
protocol=udp src-address="10.10.1.2" disabled=no new-packet-mark=voip-mark passthrough=no
|
|---|
It is sometimes preferable to seperate the matching and marking process so that you can conduct further processing. For example, you may want to exclude non-voice traffic traffic headed to the SIP server from marking, and so first a rule to send traffic to a target mangle chain:
/ip firewall mangle add action=jump chain=forward comment="send voice packets to voip-target chain" \
disabled=no dst-address="10.10.1.2" jump-target=voip-target protocol=udp
/ip firewall mangle add action=jump chain=forward comment="send voice packets to voip-target chain" \
disabled=no src-address="10.10.1.2" jump-target=voip-target protocol=udp
|
|---|
And then implement the destination chain:
/ip firewall mangle add action=return chain=voip-target comment="exclude 10.10.1.2 traffic" disabled=no dst-port=80 |
|---|
Note how the excluded web traffic (destination port 80 and 443) is dealt with using the return action which sends processing back to the main chain for further iunspection if needed.
2. Set up traffic priority:
Now that we have marked all relevant traffic with the packet mark of "voip-mark", the next step is to set the traffic priority higher than all other traffic passing through the router.
RouterOS provides the Queue subsystem for this purpose. You can think of traffic queues as similar to queues at a supermarket express checkout where there are several checkout stations for a single queue of customers. When a checkout operator becomes available, the next customer in line proceeds to that checkout for service.
For our traffic prioritisation, we create a new queue for the marked traffic, and give that queue priority over the existing queue/s. In our supermarket analogy, we are creating a second queue for "VIP" customers who proceed to the next available checkout regardless of how many customers might be already in the normal queue.
Mikrotik RouterOS has 8 levels of priority. Queues with priority of 1 get handled first, and priority 8 handled last. In this example, we will prioritise voice traffic with level 2, reserving the highest priority for important network management functionality such as routing protocol data etc.
Keep in mind that independent queues operate on each router interface, and so we need to set up priority queues on each interface that will handle our voice traffic. It follows, of course, that any interfaces that do not handle priority traffic need not be included in this configuration step!
The following example assumes that the router has two interfaces - eth1 connects to the network with a SIP destination, and eth2 connects to the SIP clients:
/ queue tree
add name="ether1_voip" parent=ether1 packet-mark=voip-mark limit-at=0 queue=default priority=2 \
max-limit=0 burst-limit=0 burst-threshold=0 burst-time=0s disabled=no
add name="ether2_voip" parent=ether2 packet-mark=voip-mark limit-at=0 queue=default priority=2 \
max-limit=0 burst-limit=0 burst-threshold=0 burst-time=0s disabled=no
|
|---|
Notice that we have not set any maximum or burst limitations on our marked traffic, thus allowing VoIP trafic to use up all available bandwidth, potentially bringing all other activity, including ordinary http web access to a grinding halt. If you want to, you can set a maximum bandwidth utilisation by setting the max-limit and burst-threshold values to restrict even priority traffic into just a portion of the total bandwidth available.
Need help with your Mikrotik Configuration projects? As an authorised Mikrotik Consultant, we are available to assist on short term or contract basis. Contact us for more info.