Adding a profile¶
Quality of Service configurations are known as profiles. Multiple profiles can be created and each profile can be assigned to one or more bonds.
Add add a new profile, click Add profile from the QoS profile list page.
To edit an existing profile, do one of the following:
- On the profile list page, click the
icon beside the profile - On the profile details page, click the Edit button
Profiles, traffic classes, and packet filters have the following fields.
Profile¶
A profile is a collection of traffic classes and packet filters.
Name¶
A descriptive name for the profile. This must be unique in the profile’s space.
Overhead margin¶
The amount of bandwidth, in percent, to allocate for avoiding ISP queues so that latency is minimized.The available bonded bandwidth is reduced by this amount. For example, with 5% overhead, a 10.0 Mbps bond would be limited to 9.5 Mbps.
This value is dependent on two things:
- The size of packets being sent on a bond—bonds with a high rate of small packets (for example, bonds that support VoIP systems) need to have a QoS profile with a larger overhead margin.
- The layer 2 overhead of the legs in a bond—bonds with DSL or T1 legs need to have a QoS profile with a larger overhead margin than bonds with only cable or fixed wireless legs, because the layer 2 overhead of DSL and T1 lines (which use ATM cells) is higher than that of most other types of legs (which frequently use Ethernet frames).
The default, 5%, is appropriate for bonds with cable or Ethernet legs, which have lower layer 2 overhead, or for bonds with DSL legs that don’t use VoIP or other latency-sensitive applications that send or receive large numbers of small packets. On bonds with DSL or T1 legs that support VoIP or other applications that use small packets, the overhead may need to be set between 10-20%. The appropriate value can be found by starting a bulk upload or download, starting the maximum number of VoIP calls that the bond needs to support, and adjusting the overhead field to the lowest value that keeps VoIP quality high.
Traffic classes¶
A traffic class represents a level of service supported by the network. A profile could have one class for applications requiring low latency, one for applications requiring high bandwidth, and one for everything else. Classes can also be used to limit throughput for undesirable traffic (i.e. P2P protocols in some networks).
Traffic classes can be re-ordered by clicking and dragging on the
icon beside the class.
Comment¶
A descriptive comment for the class.
Reserved percent¶
The amount of bandwidth, in percent of available bandwidth, to reserve for this class for both download and upload traffic. For example, for a 10 Mbps down/1 Mbps up bond, a class with 40% reserved would be guaranteed 4.0 Mbps down and 0.4 Mbps up.
Reserved bandwidth is guaranteed to be available for traffic of the class. However, if a class throughput is less than the reserved bandwidth (i.e. when there is only 1 Mbps of traffic in a class with a 10 Mbps guarantee), then other classes can borrow bandwidth from the class.
Reserved minimum¶
The minimum amount of bandwidth, in Mbps, to reserve for this class. The reservation will never be less than this value, even if the reserved percent multiplied by the bond speed is less than this.
For example, suppose a class reserves 40% of bandwidth in a 10 Mbps bond. It should reserve 4.0 Mbps. However, if it is given a reserved minimum of 5.0 Mbps, then it will reserve 5.0 Mbps instead of 5.0 Mbps. This will reduce the bandwidth available for lower-priority classes to reserve.
Reserved maximum¶
The maximum amount of bandwidth, in Mbps, to reserve for this class. The reservation will never be more than this value, even if the reserved percent multiplied by the bond speed is greater than this value.
For example, suppose a class reserves 40% of bandwidth in a 10 Mbps bond. It should reserve 4.0 Mbps. However, if it is given a reserved maximum of 2.0 Mbps, then it will reserve 2.0 Mbps instead of 4.0 Mbps. This will increase the bandwidth available for lower-priority classes to reserve.
Limit percent¶
The maximum amount of bandwidth, in percent of available bandwidth, that can be used by this class. Specifying a limit will prevent this class from ever using more than the calculated share of bandwidth, even if bandwidth is available to borrow from other classes.
Limit minimum¶
The minimum amount of bandwidth, in Mbps, to which this class should be limited. The limit will never be lower than this value.
Limit maximum¶
The maximum amount of bandwidth, in Mbps, to which this class should be limited. The limit will never be higher than this value.
Default¶
Checked if packets not matching any filter should be sent to this class. Only one class can be selected as default.
Leaf qdisc¶
The algorithm used to manage packets within the class. PFIFO transmits packets in the same order they are received and is good for classes offering low-latency, low-jitter service. SFQ ensures fairness between all the flows using the class and is good for high-bandwidth service.
Delete¶
Click Delete to remove the class when the form is submitted. If you accidentally click Delete, simply click Restore before submitting the form.
When deleting a traffic class, filters assigned to that class are also deleted.
Packet filters¶
Packet filters represent characteristics of a packet that are used to assign the packet to a certain traffic class. When more than one match is defined for a filter, each match must be satisfied for a packet to be classified. For example, if a filter matches on protocol, source network, and size, a packet must match each of those characteristics in order to receive the selected level of service.
Packets not matched by any filter are assigned to the default class. Packets matching multiple filters are assigned to the lowest priority target class of the matched filters. This is true for filters in the same traffic class and filters in different traffic classes. For example, if there is a rule at the top of the list matching all UDP traffic for a “bulk” traffic class and another rule further down the list matching UDP packets with DSCP flags for VOIP for a “real-time” traffic class, the VOIP filter will be considered the lowest priority and any of the matching VOIP packets will be marked as “real-time” instead of “bulk” which is higher on the list.
Packet filters can be re-ordered by clicking and dragging on the
icon beside the filter.
Packet filters cannot be specified while adding a new profile— to do so, first save the profile and then return to the edit page.
Traffic class¶
The destination traffic class for matched packets.
Comment¶
A descriptive comment for the packet filter.
Protocol¶
The IP protocol of the packet.
Length¶
The length in bytes of the IP packet; can either be a single number or a range with the syntax X:Y. For example, “80:160” would match packets between 80 and 160 bytes inclusive.
Source network¶
The source network and netmask in CIDR notation of the packet’s source when sent from the bonder.
In order to track both directions of the connection, the match on the aggregator is reversed and matches on packet destination network. For example, the value “203.0.113.0/24” matches packets sent from the host 203.0.113.1 behind the bonder as well as reply traffic returning to 203.0.113.1.
Destination network¶
The destination network and netmask in CIDR notation of the packet’s destination when sent from the bonder.
In order to to track both directions of the connection, the match on the aggregator is reversed and matches on packet source network. For example, the value “198.51.100.0/24” matches packets sent to the host 198.51.100.1 on the Internet as well as reply traffic returning from 198.51.100.1.
Ports¶
The port number of the packet, when the Protocol field is TCP or UDP. This matches both source and destination ports and can be a list of comma separated values or ranges in the format X:Y. For example, “80,443,8000:8050” would match ports 80, 443 and everything between 8000 and 8050 inclusive, going either direction.
Advanced settings¶
To show advanced filter settings, click the 
icon beside the
filter.
Source ports¶
The source port number of the packet when sent from the bonder, when the Protocol field is TCP or UDP. Like the Source network field, this is reversed and matches the destination port on the aggregator. Like the Ports field, this can be a list of comma separated values or ranges.
Destination ports¶
The destination port number of the packet when sent from the bonder, when the Protocol field is TCP or UDP. Like the Destination network field, this is reversed and matches the source port on the aggregator. Like the Ports field, this can be a list of comma separated values or ranges.
ICMP type¶
The ICMP type of the packet, when the Protocol field is ICMP.
TCP flags¶
The TCP flags to match, when the Protocol field is TCP. The Consider group of flags determines which ones will be considered and the “Match” group determines which flags must be set out of the considered group in order to be a match. For example, if the Syn and Ack flags are considered and only Syn is matched, a packet would match if it had its Syn flag set and its Ack flag unset. The value of its Fin, Rst, Urg, and Psh flags would not matter.
Service request (DSCP)¶
The DSCP field of the packet.
Global frequency¶
Match packets up to a certain number in a given period of time. For example, if this is set to 10/minute it will only match the first 10 packets a minute that meet the rest of the criteria. A burst value specifies how many packets can be matched initially or after a period when no packets are matched at all.
Connection frequency¶
Match packets up to a certain number in a connection in a given period of time. For details, refer to the hashlimit section of the Linux Iptables manual page.
Connection bytes¶
Match packets in a connection, based on bytes, packets or average packet size. For example, with size set to 2000000, mode set to bytes and direction set to both, packets in a flow would be matched after the total throughput of the connection was 2 MB or more. For details, refer to the connbytes section of the Linux Iptables manual page.
Connection tracking¶
The state of the connection. For example, with state set to Established and protocol to TCP it will match TCP packets that are part of an already-established connection.
Protocol helper¶
Assist with matching complex protocols such as SIP or H.323 data and active FTP connections that assign ports dynamically.