25% developed

Advanced QoS for IPCop

From Wikibooks, open books for an open world
Jump to navigation Jump to search

The QoS addons for IPCop are advanced traffic shaping addons to the popular IPCop firewall. Maintained as GPL/Creative Commons Open Source projects by Markus Hoffmann.

There are currently two QoS packages being maintained, using two different packet scheduling protocols; HTB and HTSC.

A Brief Introduction to Traffic Shaping[edit | edit source]

Quality of Service (QoS) is a term used to all the different modules that make up traffic shaping. QoS is an attempt to bring all these different programs and protocols together to give priority to network traffic that is time dependent, like VoIP and online games, over less time critical data transfers such as P2P or FTP traffic. If it does it well, then you can have a conversation using VoIP while downloading/uploading large files without delay or gaps in the voice call.

Flavours[edit | edit source]

There are two versions of the Advanced QoS Addon:

  • Hierarchical Fair Service Curve scheduler (HFSC) – (QoS 2.5 Ipcop 1.4.8)
  • Hierarchical Token Bucket scheduler (HTB) – (QoS_NG)

Table of Contents[edit | edit source]

  1. Prerequisites
  2. Installation
  3. Setting up the Classes (For Outgoing Traffic)
  4. Setting ACK
  5. Defining the Traffic
  6. IMQ – Setting up Classes and Rules for Incoming Traffic
  7. Uninstalling QoS Addon
  8. Glossary

Notes[edit | edit source]

  • There are two approaches to limiting unwanted/low priority traffic:
    • Creating a rule pinpointing the traffic type with the layer 7 tools or using the specific port and then specifying the maximum bandwidth this traffic will be allowed to have.
    • Creating rules for allowable traffic and giving them maximum bandwidth (or known quantities) and then limiting the default rule's bandwidth limiting all unknown traffic.
  • The maximum root bandwidth is typically set at 90% of the actual bandwidth to reduce the effect of buffered data in the local modem or on the isp's end. The problem stems from the idea that requested data can be queued (in large quantities) to avoid gaps in data flow. While this works for large continuous transfers, mixed data transfers suffer because of having to wait "in queue" to be sent causing the net effect of sluggish response.
  • Port ranges can be entered as <port>[space]-[space]<port>. IE: 1000 - 2000
  • IP ranges can be entered as CIDR notation addresses. IE:

Questions-N-Answers[edit | edit source]

  • Q: Where can I download the Advanced QoS for IPCOP?
  • Q: What does the QOS "Maximum delay in milliseconds" really mean?
    • A:
  • Q: What does the QOS_NG "Maxbust" and "Ceilmaxburst" really mean?
    • A: Burst : Amount of bytes that can be burst at ceil speed, in excess of the configured maximum upload speed. Should be at least as high as the highest burst of all children

Ceilburst: Amount of bytes that can be burst at 'infinite' speed, in other words, as fast as the interface can transmit them. For perfect evening out, should be equal to at most one average packet. Should be at least as high as the highest cburst of all children. Both values could be empty because they will be computed automatically.

  • Q: Which is better QOS(HFSC) or QOS_NG(HTB)?
    • A:
      • QOS which is based on HFSC is supposed to be better for VOIP. The Hierchial tree method was designed to share bandwidth between branches or classes and rules (envision a tree, the trunk being the full bandwidth, each branch being class/rule taking bandwidth from the trunk).
      • QOS_NG which is based on HTB is supposed to be better at layer 7 (P2P for example) bandwidth control. The idea behind HTB is that the data flows like water in a hose into "buckets". Each bucket only holds so much data. The buckets are queued by priority to receive the available bandwidth.

Examples[edit | edit source]

QOS Symmetrical 128Kbps with OpenVPN priority[edit | edit source]


  • RED outgoing is eth0, incoming is imq0
  • GREEN is eth1
  • Clients and servers are on GREEN
  • VPN connections are accessing servers on GREEN intranet
  • Clients will produce typical web, ftp, etc... traffic
  • VPN is the only service available to the internet on RED


  • Create RED root classes 199(eth0) and 299(imq0) with the maximum bandwidth set to 115 Kbps
  • Create class 100, priority 1, minimum bandwidth 50 Kbps, delay 25ms, maximum bandwidth 115 Kbps
  • Create class 101, priority 2, minimum bandwidth 50 Kbps, delay 50ms, maximum bandwidth 115 Kbps
  • Create class 199, priority 7, minimum bandwidth 1 Kbps, delay 500ms, maximum bandwidth 100 Kbps
  • Assign ACK priority to class 100
  • Create class 200, priority 1, minimum bandwidth 50 Kbps, delay 25ms, maximum bandwidth 115 Kbps
  • Create class 201, priority 2, minimum bandwidth 50 Kbps, delay 50ms, maximum bandwidth 115 Kbps
  • Create class 299, priority 7, minimum bandwidth 1 Kbps, delay 500ms, maximum bandwidth 100 Kbps

At this point all traffic will traverse on the default classes 199 and 299 at a slightly reduced rate.

To ensure that vpn (OpenVPN specifically) traffic gets priority, the following rules should be added:

  • Create a rule "OpenVPNOut", interface eth0, protocol UDP, mark 101, source port 1194
  • Create a rule "OpenVPNIn", interface imq0, protocol UDP, mark 201, source port 1194

This scheme will make OpenVPN traffic higher priority than the default traffic, however since ACK's have a higher priority than everything else, normal traffic will still flow.

Viewing the graphs should provide insight into the flow:

  • 1:100 will show ACK traffic from GREEN clients to internet connections
  • 1:101 will show VPN outgoing traffic (port 1194)
  • 1:199 will show bulk outgoing traffic
  • 2:200 will show very little in this configuration as the rule is not used
  • 2:201 will show VPN incoming traffic (port 1194)
  • 2:299 will show bulk incoming traffic

Additional categorization of the bulk traffic could be done by adding more rules.