qos - Manage the network QoS (Quality of Service)
[1] qos [bandwidth [(internal | external | auxiliary) [[(ingress | egress)] <bandwidth>]]]
[2] qos [shape [(web | antivirus | file) [(internal | external | auxiliary) [(ingress | egress) [<qos>]]]]]
[3] qos [shape [tweb [(internal | auxiliary) [(ingress | egress) [<qos>]]]]]
[4] qos [shape [rweb [(internal | external) [(ingress | egress) [<qos>]]]]]
[5] qos [shape [peer internal [(ingress | egress) [<qos>]]]]
[6] qos [shape [vpnipsec [external [(ingress | egress) [<qos>]]]]]
[7] qos [shape [router [((add | add:<rule-name> | insert:<rule-name>) <rule-name> (external | web | rweb | antivirus | admin | mon | file | peer | auxiliary) <protocol> <src-ip>[/<mask-prefix>] <src-port1>[:<src-port2>] <ingress-qos> <dst-ip>[/<mask-prefix>] <dst-port1>[:<dst-port2>] <egress-qos> [<dscp>]) | (del <rule-name>) | raz]]]
[8] qos [shape [router [move:(-|+)<rule-name> <rule-name> | move:<position>]]]
[9] qos [shape [default [(internal | external | auxiliary) [(ingress | egress) [<qos>]]]]]
[10] qos [borrow [(internal | external | auxiliary) [(ingress | egress) [on | off]]]]
[11] qos [report [(all | admin | routed | etc) | (web | tweb | rweb | peer | antivirus | file | router | default)] [diff]]
The QoS (Quality of Service) controller allows you to manage the network bandwidth used by different types of traffic exchanged with or via to the appliance. The bandwidth management is done using different technologies such as prioritising, shaping and scheduling the network traffic. All those technologies combined together allows you to protect your business critical traffic from being penalized by other traffic in your networks. To this end, network traffic are classified by category and each category or class is configured to receive the adequate network bandwidth. The QoS controller is deactivated by default. To activate it use the command mode.
The QoS configuration is done at different levels. To begin with, the overall incoming (ingress) and outgoing (egress) bandwidth limits should be configured for each logical network interface. The bandwidth limits are normally set according to the maximum supported bandwidth by connected networks. The network traffic can then be shaped to limit the bandwidth usage for each class of traffic. In addition, concurrent traffic in the same class are placed in multiple queues that are scheduled to equitably receive and transmit data. This way extensive usages by some clients (users or machines) in a class do not penalise others.
We distinguish the following traffic categories and classes:
• Management traffic used to administrate and monitor the appliance itself: unlike other class of traffic, management traffic is not shaped but is directly queued and managed with the highest level of priority. This means that as long as there data in the management queue, no other traffic is treated. This QoS policy ensure that the appliance is always reachable and can be monitored and administrated even if the network is overloaded. The QoS cannot be modified for management traffic. The following traffic are classified as management traffic: SSH, Web GUI, SNMP and SysLog. Management traffic is placed in a class named admin.
• Technical low level and basic service traffic destined to or initiated from the appliance: ARP, DHCP, ICMP, VRRP, NTP, OCSP and LDAP traffic are all placed in this category with a limited bandwidth that is automatically configured by the system. The etc designate this class of traffic.
• Technical traffic exchanged with the appliance itself: 2 classes of traffic are in this category which are file and peer. The class file designates file exchange traffic such as URL blacklists downloads and backup traffic. The class peer refers to traffic with shared or HA peer appliances via the internal network interface (see the command peer to manage peer appliances).
• Web traffic treated by the appliance before being routed. We distinguish 3 classes of web traffic: web, tweb and rweb traffic: web stands for web traffic exchanged with clients using the appliance as an explicit forwarding proxy ; tweb stands for web traffic transparently intercepted by the forwarding proxy ; rweb stands for web traffic exchanged between clients and web servers via the appliance implemented as a reverse proxy. Web traffic includes HTTP on port 80, HTTPS on port 443 and DOMAIN (for name resolutions) on port 53.
• Traffic exchanged between the appliance used as an antivirus service and clients like an MTA (Mail Transfer Agent). This class of traffic is named antivirus.
• Traffic exchanged in IPsec VPN tunnels established between the appliance via its external interface and remote peers. The class named vpnipsec designates this traffic. ESP, ISAKMP and IPsec NAT traversal (ESP encapsulation with UDP) traffic are placed in this category.
• Traffic that are just routed via the appliance without being intercepted or inspected. This class of traffic is only allowed when the router mode is activated (see the command mode to activate the router mode).
• Any traffic that is not classified into one of the above traffic types is classified in a class called default. In particular, routed traffic (see the seventh [7] usage form below) may be be classified as default if no QoS routing rule is defined for it.
The qos command uses the terms ingress and egress respectively for incoming traffic and outgoing traffic from a logical network interface. The <qos> value represents the shaping to apply to a traffic. It may be a percentage of the total bandwidth limit configured for a logical network interface or a bandwidth value expressed in kbps (kilo bit per second). If the <qos> value ends with the character ’%’ it is considered as a percentage (integer between 1 and 100). Otherwise it is considered as a kbps value. If you use percentages, real used values are always calculated to get values in kbps. In other words, values given in percentages are not dynamic and are not calculated whenever bandwidths are modified in runtime.
Note that there is always a gap between the perceived bandwidth at an application level and the defined <qos> value. This gap is due to protocol headers and other technical data in the traffic. In practice perceived bandwidths are from 6% to 9% less than specified <qos> values.
The first [1] usage form allows you to define the total bandwidth limit for each logical network interface for incoming and outgoing traffic. All bandwidths are given in kbps.
The second to sixth [2][3][4][5][6] forms allow you to shape steering traffic (destined to the appliance itself) and allocate different bandwidths to different types of traffic. Having defined global QoS with this command, a customisation is possible network by network with other commands like access, tweb (transparent), rweb and peer. The third [3] usage form applies to transparently intercepted web traffic only when tnat mode (see the mode command) is activated, causing client IP addresses to be NATed using the appliance’s external interface. When tnat mode is deactivated (i.e. transparently intercepted web traffic preserves the original client source IP addresses and is not NATed), transparently intercepted web traffic should instead be shaped using QoS routing rules (see the seventh [7] usage form below).
Note that for ingress IPsec VPN traffic, traffic shaping is applied twice: once to the encrypted IPsec VPN traffic and once after the IPsec VPN encryption has been removed. Consequently, the traffic type all reported by the QoS report (see the eleventh [11] usage form below) does not represent the actual overall traffic.
Protocols such as TFTP and FTP use dynamically allocated server-side ports, which are difficult to track. For this reason, the traffic shaping defined for file traffic (i.e. traffic exchanged between the appliance and trusted file servers) is based on IP addresses only. It is applied only if no other traffic shaping rule matches traffic involving the trusted file servers.
The seventh [7] usage form allows you to configure the appliance to shape routed traffic (i.e. traffic not destined for the appliance itself). Traffic shaping for routed traffic is configured using QoS routing rules. A QoS routing rule is associated with a logical network interface and specifies the portion of the available bandwidth to reserve based on the protocol, source, and destination of the traffic. QoS routing rules are evaluated in order, and the first matching rule is applied.
To correctly shape routed traffic, you should consider that egress traffic flows from a source to a destination, while ingress traffic flows in the opposite direction. Note that when traffic traverses the appliance, it enters through one network interface and exits through another. Consequently, the egress direction on one interface corresponds to the ingress direction on the other, and vice versa.
Logical network interfaces to which a QoS rule can be associated are: external, web, rweb, antivirus, admin, mon, file, peer and auxiliary. You may notice that it is not possible to associate a QoS rule to the vpnipsec virtual network interface as the traffic shaping of encrypted egress traffic is not supported by the system. However, as a routed traffic via an IPsec VPN tunnel ends up to pass via a logical network interface, you can manage its shaping with a QoS rule associated with that logical network interface. The logical network interfaces web, rweb, antivirus, admin, mon, file, and peer are all associated with the main internal interface. When VLAN mode is activated (see the mode command), they specify distinct interfaces. Otherwise, they are equivalent.
A traffic rule is uniquely identified by rule a name (<rule-name>). A valid rule name should begin with an alpha character and may contains alpha numeric characters as well as the characters "_" and "-". To add a QoS rule at the end of all rules, use the keyword add. To add a rule after a given rule, use the keyword add: followed by the rule name after which the new rule should be inserted. To insert a rule before a given rule, use the keyword insert: followed by the rule name before which the new rule is to be inserted.
Source and destination of a traffic are identified by their respective IP address and port. The port specification may be a unique port number or a port range. A port range is specified by giving two port numbers separated by a colon (:) character (for instance 3478-3481). The keyword any can be used to specify an undefined IP address or port number. When used as the protocol, the any keyword refers to either UDP or TCP. The default <mask-prefix> is 32 (to specify a single remote machine). Supported protocols are:
• tcp (Transmission Control Protocol)
• udp (User Datagram Protocol).
The <ingress-qos> parameter specifies the shaping applied to ingress traffic (flowing from the destination to the source) entering the specified network interface, while the <egress-qos> parameter specifies the shaping applied to egress traffic (flowing from the source to the destination) leaving the specified network interface. The specified <ingress-qos> and <egress-qos> values may be expressed either as a percentage of the bandwidth allocated to default traffic (see the ninth [9] usage form) or as an absolute bandwidth value in Kbps (kilobits per second).
Note that the following convention should be considered when defining QoS rules:
• Egress (outgoing) traffic flows from the specified source to the specified destination, while the corresponding ingress (incoming) traffic flows from the specified destination to the specified source (i.e. in the opposite direction).
• As NAT in firewall rules operate after IP packets come into the appliance, QoS rules are applied to non NATed IPs for incoming traffic. For IP packets that go out from the appliance, the NAT is already done. Hence QoS rules are applied to NATed IPs.
• When SNAT mode is activated (see the mode command), you must specify non-NATed IP addresses in QoS routing rules, as the system automatically translates them to their NATed addresses when required.
When a <qos> value is expressed in Kbps, it must be less than or equal to the configured bandwidth limit for the corresponding logical network interface. The apply command verifies the integrity of the <qos> values configured here.
Finally when defining QoS rules for routed traffic, you have the possibility to set a DSCP value for IP packets. DSCP stands for Differentiated Services Code Point and is a 6-bits value in the IP header. If your appliance is connected to a network that supports the classification of traffic based on the DSCP filed you can set this value. Note that the DSCP field is meaningful only if all network devices between the source and destination take it into consideration. For instance the DSCP field is meaningful in an MPLS network while it is useless on the internet. A valid DSCP value is an integer between 0 and 63.
The eighth [8] usage form allows you to move a rule from one position to another in the list of shaping rules for routed traffic. To move a rule before or after another denoted rule use the keyword move: followed by the sign - (for before) or + (for after), the rule name of the denoted rule and the rule name of the rule to move. Note that white spaces are not allowed between the keyword move:, the signs - or + and the rule name of the denoted rule. To move a rule to an absolute position use the move: followed by the position number and the rule name of the rule to move (the first position is the position number 1). Note that white spaces are not allowed between the keyword move: and the position number.
Any other steered (i.e. destined for the appliance) traffic not managed by usage forms [2] to [6], as well as any routed traffic not matched by a QoS routing rule (usage forms [7] and [8]), is classified as default. The ninth [9] usage form allows you to define the bandwidth allocated to default traffic.
In a concurrent environment, the configured <qos> limit may be exceeded when the load generated by other traffic types remains below their configured <qos> limits. This mechanism is called borrowing, as one traffic type temporarily borrows unused bandwidth from other traffic types. The tenth [10] usage form allows you to activate or deactivate the borrowing mechanism for each network interface. Disabling borrowing enforces strict bandwidth allocation for each traffic type, whereas enabling it allows the available bandwidth to be shared more flexibly.
The eleventh [11] usage form allows you to display a report on the network traffic (in kilobit) managed by the QoS controller since the last QoS configuration modification. This can help you to test your QoS configuration and validate that the bandwidth is managed as expected. If a traffic type is specified, the report covers only that type of traffic. If the optional diff keyword is specified, the differential network traffic (in kilobit) since the last report display is displayed (instead of the network traffic since the last QoS configuration modification).
Traffic types that can be specified with this usage form are as follows:
• all: the total traffic exchanged by the appliance (including traffic destined for or initiated by the appliance, as well as traffic routed through the appliance). Note that ingress IPsec VPN traffic is counted twice: once as encrypted IPsec VPN traffic and once after the IPsec VPN encapsulation has been removed.
• admin: administration and monitoring traffic destined for or initiated by the appliance itself.
• routed: all traffic routed through the appliance (same as router).
• etc: technical low level and basic service traffic destined to or initiated from the appliance itself (Refer to the explanation above for more detailed information).
• web, tweb, rweb, peer, antivirus, file, router, default : these are traffic types that can be shaped (descriptions are given above in the qos shape usage form).
• Some IPsec VPN-related traffic cannot be classified and is therefore assigned to the default class. For this reason, you should always reserve some bandwidth for the default class.
• The QoS controller classifies the network traffic according to the used protocol (TCP or UDP), the source/destination IP address and the source/destination port. In certain circumstances, the appliance may not shape the traffic as requested because of an ambiguity in the configuration. For instance if an external FTP server and an antivirus client (such as an MTA) share the same IP address, the traffic can be classified as antivirus traffic as well as file traffic. The reason is that both FTP and antivirus traffic use dynamic ports, thus creating ambiguity.
• In VLAN mode (see the mode command), QoS routing rules for inter-VLAN ingress traffic share the same virtual network interface (attached to the internal network interface). Therefore, if identical QoS routing rules (same source and destination IP addresses, same ports, and same protocols) are defined for different VLAN interfaces, the <qos> value from the rule defined first is the one that will be applied.
access(1), firewall(1), apply(1), mode(1), peer(1), port(1), rweb(1), transparent(1), vlan(1)
CacheGuard Technologies <www.cacheguard.com>
Send bug reports or comments to the above author.
Copyright (C) 2009-2026 CacheGuard Technologies - All rights reserved