The Quality of Service in IPFire is now based on CAKE. See the IPFire Blog:


IPFire supports Quality of Service (QoS) policies which allow bandwidth to be reserved for specific types of traffic. This means that when a network connection is congested, high priority traffic will be allowed at the expense of slowing low priority traffic (by dropping low priority packets).

When QoS is enabled the fq_CoDel packet scheduling algorithm is also active. This algorithm prevents excessive buffering, a problem known as bufferbloat. Bufferbloat occurs where too much buffering of packets (temporary storage in memory) causes high latency (long time between message and response) and packet delay variation (known as jitter).

Both upload and download limits can be configured separately. Different types of traffic (classes) can be configured to have different priorities and a set amount of guaranteed (reserved) bandwidth. When bandwidth is needed for a Class, the QoS algorithm intelligently decides if it needs to borrow bandwidth from a lower priority Class in order to maintain the minimum guaranteed bandwidth that is defined. Even if most of the bandwidth is used up, an amount is still reserved and given if needed, based on the user-configurable settings "Priority", "Guaranteed Bandwidth" and "Maximum Bandwidth" under each Class.

Configuring QoS in IPFire

  • Using the IPFire web user interface, click "Quality of Service" in the "Services" menu.
  • Before starting, ensure QoS is stopped.
  • Click the Modify button to the Downlink (download) and Uplink (upload) speeds your ISP provides in kilobits per second format
  • You can check this using a speed test site while there is no other traffic on your network
    • Using the curl or wget utilities will return a result in kibibytes per second, not bits per second. To convert these to kibibit per second, multiply the value by 8.
    • Or while saturating your link, note the speed displayed in the IPFire WUI. Multiply this amount by 1024 to convert it from mebibit per second to kibibit per second (Note the units are binary not decimal).
    • It is recommended that you reduce both speeds by 3% to reduce the chance of excessive buffering. See the Bufferbloat section below for more information.

Note: The changes made to QoS will apply to new connections. For example: If you have an open OpenVPN connection your have to close it (be sure is closed in Status > Connections), and then open it. Only then you can see the changes to your new rules in QoS.

IMQ Device

The IMQ (Intermediate Queueing Device) is a virtual network interface in IPFire designed to handle incoming (download) traffic. When incoming packets reach the external "RED" interface (red0), they are enqueued to the imq0 device during the PREROUTING chain for QoS processing before entering the local network. This setup enables precise control over download traffic, facilitating prioritization or rate-limiting as needed.


  • Classes define the priority, guaranteed bandwidth, maximum bandwidth and TOS for a set of communications you define.
  • Classes which begin with 1 (101, 102, etc) are outbound rules. These control traffic being uploaded on your internet connection, such as sending email or uploading a document online.
  • Classes beginning with 2 are rules for your download bandwidth.
  • Special Classes include 101, 110 and 210. It's best not to change these three classes as it may cause problems with QoS in IPFire.
    • 110 and 210 are defined as Default downlink and uplink respectively. All traffic which does not match any other class will be regulated by this class. These classes should have low priority (6 or 7) and low Guaranteed Bandwidth values to ensure they stay out of the way of higher priority traffic.
    • 101 is defined as the ACK class, for acknowledgement packets.
      *Tip: You may wish the colors of similar classes in your Uplink and Downlink graphs to match. Just name them identically in the remark.


Traffic that is defined by a class with priority 1 will be given priority over all other traffic. Priority 7 has the lowest priority.

Carefully consider which types of communications are most important. For example, your network may be used for VoIP and video calls. These types of communications need to have high priority as any delayed packets will be discarded leaving users with choppy audio and video.

Also, if you mostly use a VPN after hours, it might make more sense to prioritize VPN below web traffic. Otherwise, when someone does use VPN during work hours and it is prioritized above web traffic, it could negatively impact web traffic performance for many users. In contrast, if most users work from home, then it might make sense for VPN traffic to have a higher priority than web traffic.

Guaranteed and maximum bandwidth

Use Kilobits per second format. Guaranteed bandwidth will reserve a certain amount of your bandwidth to a Class regardless of its priority. In most cases it is good to be conservative so you do not over-commit your available bandwidth. Maximum bandwidth is how much bandwidth you would like the Class to have when there is extra bandwidth available.


This optional field defines the packet size for data that will be sent at the Class maximum bandwidth. When you leave this field blank, IPFire defaults to 1600 bits. Some experimenting with this value (see footnote1) has determined that the default value seems to work best, but you may choose to manually change this. The value you enter should be in kilobytes. So if you wanted a bit value of 5120, you would enter 5 (5 KB = 5120 bits). In other words, divide the bit value by 1024 to get the value you will input.

Ceil Burst

This optional field defines the packet size for data that will be sent at maximum link speed (the downlink and uplink speeds you define at the top of the QoS page). The value also defaults to 1600 bits, which seems to be ideal for most cases (see footnote1 for more discussion).


Type of Service (TOS) lets you define the bits of traffic sent from each class with an IP header value that receiving routers can use to further prioritize traffic. Select the appropriate value from the drop down box.

Option description ToS bit
disabled no special treatment for the packet (0)
minimum costs prioritizes cost-efficient transmission in paid-for based on usage (1)
maximum reliability avoid congestion and packet loss (2)
maximum throughput large file transfers or bulk data sharing (4)
minimum delay real-time voice and video communication (8)


  • The graphs on the QoS page display values in kilobytes per second (KB/sec). To convert these values to kilobit per second format, multiply the KB/sec value by 8.
  • Observe the uplink and downlink graphs for a period of days, or even weeks. Note the highest values under the "Maximal" column and use those to help determine your Guaranteed and Maximum bandwidths for each Class. For example, for Class 101 (ACKs) if the highest value ever recorded is 70 KB/sec (560 kbit/sec), then it might make sense to set the guaranteed bandwidth to 500 and the maximum to 600. If you guarantee too much bandwidth to a Class that never uses that much, you end up stealing bandwidth from other Classes.
  • An example configuration is available in footnote2.

Defining class traffic

  • After all classes have been defined, click the Green pencil icon to add a rule for each class
  • Use Port-Rules where possible as they require the least computing power for IPFire to process. These require a knowledge of the protocol and port used by a particular communication and are not ideal for traffic which can use random ports.
    • For Uplink (Upload) rules, specify the Destination Port
    • For Downlink (Download) rules, specify the Source Port
  • Level 7 Rules can be used to catch traffic which use random ports (or if you expect users will try to avoid your Quality of Service rules!)
    • Use these rules sparingly as they are less efficient and require higher CPU utilization for your IPFire router
  • TOS rule allow you to put all traffic which is already tagged by another router in to a class which you have defined. Depending on the complexity of your network this may have minimal benefit.
  • In its default state, IPFire's QoS configuration sets the IMQ_MODE to "PREROUTING." Due to this, local IP addresses cannot be used to define downstream rules, as the QoS operates on the RED interface, which is processed before NAT. If you find it necessary to use local IP addresses in your downstream rules, you can't change this via a settings file. Instead, you'll need to manually edit the Perl script located at /var/ipfire/qos/bin/ In this script, modify the iptables entry to place the mangle table in the "FORWARD" chain, as opposed to the default "PREROUTING" chain.

Advanced Editing

If you are an advanced user and comfortable working in a Linux shell, the easiest way to make major changes to QoS configuration is to edit the files directly in IPFire.

  • Be very careful when editing files directly, there is no error checking for mistakes so you could easily make a change which causes QoS to fail!
  • Make a backup copy of the /var/ipfire/qos/ directory before making changes
  • All settings in the QoS WUI are defined in text files in the /var/ipfire/qos/ directory. Most files are semicolon ; separated variable files.
  • After making changes, it's easiest to restart QoS using the WUI. You should also check the IPFire logs (especially the Kernel log) for errors.

Technical Details


QoS is important for dealing with "bufferbloat". This video explains the problem:
YouTube - Explaining And Fixing Bufferbloat

Buffering occurs when traffic goes from a link with high bandwidth to a link with lower bandwidth.
It is used to prevent packet loss which occurs as the lower bandwidth link cannot handle traffic at the same speed.

Buffering is more of a problem today as people have higher internet speeds and memory is cheap. As a result manufacturers have increased the buffers in their hardware.

The problem occurs when it takes a long time for traffic to go through a big buffer (100s of milliseconds to 1000s of milliseconds). If a large file download is occurring at the same time as shorter communications (like loading a simple webpage) everybody waits. The simple web page will also take a long time to load.

The solution to bufferbloat is Active Queue Management (AQM).


  • FQ_Codel measures latency and selectively drops packets on TCP connections which use too much bandwidth.
  • FQ_Codel is an active queue management combining two network scheduling algorithms; "Controlled Delay" scheduling (CoDel) and Stochastic Fairness Queuing (SFQ).


Measures the latency between traffic entering and leaving the buffer. If the latency is too high, it drops a packet which causes the TCP Connection to slow down


Organizes traffic based on type

The importance of QoS

Most ADSL and cable modems do not have an AQM. Even if your router (IPFire) shapes traffic using FQ_Codel, a modem will still buffer the traffic. To resolve this problem, limit your upload and download bandwidth to slightly below the full amount available.

Calculate Bandwidth for QoS

While your network is quiet (there is very little other traffic) use a speed test to find your upload and download speed. Sites such as,, are helpful. And specific tests for bufferbloat are available at

If your speed is in Megabits, multiply that number by 1000 to get Kilobits.

Multiply that number by about 97% (.97)


  • 60 Megabits Download = 60 x 1000 x 0.97 = 58200
  • 12 Megabits Upload = 12 x 1000 x 0.97 = 11640

You can adjust that percentage based on your observed latency.

This makes the connection between your router and modem and the internet (ISP Limit) about the same. As both your router (IPFire) and your internet connection will be around the same speed your modem will not need to buffer traffic.