Quality of Service (QoS) enables outbound network traffic to be identified and controlled to give priority to certain types of traffic. Network traffic may be categorized based on a variety of criteria including addressing information, protocol, port number (TCP and UDP), and packet length.
Configuring Quality of Service on the
PowerLink ProSeries Prioritizing Network TrafficOverviewThe purpose of this document is to provide a basic understanding of Quality of Service (QoS) functionality and configuration on the PowerLink ProSeries devices. By using a simplified example network, it will show how Quality of Service might be implemented to allow for organized access to upstream bandwidth over WAN links. The QoS features described here are available beginning with firmware version 5.1.5. Earlier versions of the PowerLink QoS bear no resemblance to the current version. This document is intended for users who wish to implement QoS on their PowerLink; a basic understanding of PowerLink configuration and functionality is assumed.Quality of Service allows for outbound network traffic to be identified and controlled in order to provide a desired level of service. Traffic may be categorized based on a variety of criteria including addressing information, protocol, port number (TCP & UDP), and packet length. Traffic classified in this way may then be associated with a particular class that defines how the traffic may consume available bandwidth and whether the identified traffic should be given priority over other types of traffic. These classes are organized into a tree structure that allows for flexibility in designing the best QoS implementation for your organization.The following diagram describes the example network that will be referred to throughout the remainder of this document. It is assumed that there are public services available on servers behind the PowerLink, but these devices are omitted for brevity.
PlanningBefore proceeding with a QoS implementation, it is a very good idea to inventory network services in use on the network and determine what services require special consideration. Any traffic that does not fall into a defined category will be applied to a default category (described later). Since every installation has unique requirements, this document does not detail how traffic control requirements should be made, though it will describe the rationale behind decisions made for the example network.The example network hosts a number of services, including a web server, mail server, DNS (on the PowerLink), and a number of services that are used by a remote site. Of these, it is most important that DNS resolution be timely and that clients on the Internet can access the web server quickly. An application in use between the two locations also requires a minimum amount of bandwidth to work properly. Outbound email, while important, is not as time-sensitive as the other traffic, so it can be given a lower priority to prevent interference with other traffic. Based on this analysis, we can begin working out how the QoS will be structured:. DNS traffic is not bandwidth-intensive, though it does need to be timely. Therefore we will guarantee 256kbps for DNS on each line and give it priority over other traffic if more bandwidth is required. On the PowerLink, bandwidth ranges are configured as a percentage of the uplink speed for a given WAN link (as set in Configure WANs). For WAN1, we will need to allocate 10% of the available bandwidth to guarantee 256kbps. WAN2 has twice the throughput of WAN1, so DNS can be set at 5%. We will identify DNS traffic by a source UDP or TCP port of 53.. Pages being served to clients can be identified by the source port as well; TCP/80 for HTTP, and TCP/443 for HTTPS. This traffic is more bandwidth-intensive, so it will require a higher guaranteed rate. Since WAN2 has higher throughput, we will be using it as the primary line for web traffic (controlled by Authoritative DNS). We will allocate 35% of the available bandwidth on WAN2, and 25% will be available on WAN1 if WAN2 fails.. The application running between our sites requires a minimum bandwidth of 700k, though we will assume 768k to ensure that enough bandwidth is available, 38% on WAN1 and 19% on WAN2. This traffic can be identified by the destination network (at the remote site), 20.20.20.0/24. Additionally, this traffic can use a lower priority than web traffic for bandwidth beyond its rated 768kbps.. O utbound SMTP traffic will be identified by a destination port of TCP/25. This traffic is considered bulk traffic, and can be given a lower priority than all other traffic. It will be allotted 10% on each link and be directed out WAN2 by default (using a static route).. ICMP should also b... [download for more]