qos - Manage the network QoS (Quality of Service)
[1] qos [bandwidth [(internal | external | auxiliary) [[(ingress | egress)] <bandwidth>]]]
[2] qos [shape [(web | antivirus | file | default) [(internal | external | auxiliary) [(ingress | egress) [<qos>]]]]]
[3] qos [shape [tweb [(internal | auxiliary) [(ingress | egress) [<qos>]]]]]
[4] qos [shape [rweb [(internal | external) [(ingress | egress) [<qos>]]]]]
[(] 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> (internal | external | auxiliary) <protocol> <src-ip>[/<mask-prefix>] <src-port> <ingress-qos> <dst-ip>[/<mask-prefix>] <dst-port> <egress-qos> [<dscp>]) | (del <rule-name>) | raz]]]
[8] qos [shape [router [move:(-|+)<rule-name> <rule-name> | move:<position>]]]
[9] qos [borrow [(internal | external | auxiliary) [(ingress | egress) [on | off]]]]
[10] qos [report [(all | admin | gateway | 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 bandwith. 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 in case where the network is overloaded. The QoS can’t 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 orinitiated 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 exchnaged 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 remotre peers. The class named vpnipsec designates this traffic. ESP, ISAKMP and IPsec NAT transversal (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 other traffic which is not classified in one of the above traffic types is classified in a class called default.
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.
Please 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 of this command 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 the 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, transparent, rweb and peer. Traffic shaping is subject to the following classification rules:
• If a network is declared to have web (forwarding) access and transparent access at the same time, the QoS defined for the transparent access (using the transparent command) has a higher priority than the QoS defined for the web access (using the access web command).
• Incoming IPsec VPN traffic via the external network interface pass twice in the QoS controller: first as an encrypted vpnipsec traffic type and then as an unencrypted and classified as other traffic types (web, file, ...).
• Reverse websites traffic (see the rweb command) requested by clients using the appliance as an explicit proxy are shaped as being web traffic (and not rweb traffic).
The seventh [7] usage form allows you to configure the appliance to shape routed traffic (not destined to the appliance itself). The traffic shaping for routed traffic is configured with QoS rules. A QoS rule is associated to a logical network interface and specifies the part of the total bandwidth to reserve according to the used protocol, the source and destination of a traffic. Logical network interfaces to which a QoS rule can be associated are: internal, externaland auxiliary. You may notice that it’s 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 to that logical network interface.
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 keyword any can be used to specify an undefined protocol, IP address or port number. 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> specifies the shaping for forth traffic (from source to destination) that come in from the given network interface while the <egress-qos> specifies the shaping for back traffic (from destination to source) that go out from the given network interface.
Please note that the following convention should be considered when defining QoS rules:
• An ingress (incoming) traffic comes from the source and goes to the destination while the related egress (outgoing) traffic comes from the destination and goes to the source (in the opposite sense).
• 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.
Please note that when all <qos> values are expressed as percentages, there is no obligation to have a total of 100% even if this is a recommended configuration when no shaping rules are defined for routed traffic. When a <qos> is expressed as a kbps value, it should be less than or equal to the defined bandwidth limit for the given logical network interface. The command apply verifies the integrity of <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. Please 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. Please 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). Please note that white spaces are not allowed between the keyword move: and the position number.
In a concurrent environment the <qos> limit may be configured to be surpassed when the load of other networks is under their configured <qos> limits. This mechanism is called borrowing (a traffic type borrows its available bandwidth to other traffic types). The ninth [9] usage form of this command allows you to activated or deactivated the borrowing mechanism. Deactivating the borrowing allows you to affect strict bandwidth to a traffic type while its activation allows you to share the available bandwidth more flexibly.
The tenth [10] 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 (includes traffic destined to or initiated from the appliance as well as traffic routed via the appliance).
• admin: administration and monitoring traffic destined to or initiated from the appliance itself.
• gateway: all traffic destined to or initiated from the appliance itself except administration and monitoring traffic.
• etc: technical low level and basic service traffic destined to or initiated from the appliance itself.
• 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).
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.
When the vlan mode is activated (see the mode and vlan commands), the DSCP is only set for the web VLAN.
access (1) firewall (1) apply (1) mode (1) peer (1) port (1) rweb (1) transparent (1) vlan (1)
CacheGuard Technologies Ltd <www.cacheguard.com>
Send bug reports or comments to the above author.
Copyright (C) 2009-2024 CacheGuard - All rights reserved