1. Reliable and secure Wi-Fi access. Smartphones, tablets, and wireless IP phones need the speed and stability of Wireless-N (802.11n) network access, as well as quality of service (QoS) support. Some wireless routers integrate security — such as VLANs, firewall, VPN, and security services — to increase and simplify your control.
2. Power over Ethernet (PoE). PoE juices up a network in two ways: It gives you more flexibility locating wireless access points and other wired devices, and it adds more power per port to support higher-draw technologies such as Wireless-N.
3. Stronger network security. Mobility, social networking, cloud services, and international hacking are growing. Is your security technology keeping pace? Essential technologies include content security, firewall, VPN, and VLANs. Integrated security solutions can increase application performance and give you better control.
4. Collaborative communications. Businesses can reduce operating costs and raise productivity by through unified communications and video and audio conferencing applications. Collaboration technologies demand high-performance, high-availability connections and reliable, intuitive user devices, ranging from basic IP phones to unified IP phones.
5. High-performance, high-availability connections. Businesses that use mobile devices, cloud applications, or IP voice or video require a fast and efficient traffic flow. If you want to optimize your traffic flow by investing in a new router or switch (or DNS server), it should include support for IPv6.

Recreated with permission from Cisco.com.

“…suppose I wanted to prioritize two different traffic types…could I set limits as to the maximum bandwidth used by at least one of the flows?”

Well, the answer to that question is a resounding “YES”.

As the screenshot below indicates, the QoS tab of the Service Policy Rule Wizard uses check boxes instead of radio buttons.  Radio buttons are “either-or” options vs. check boxes which are multi-option.

When the check box for Enable priority for this flow is marked, the pop-up warning that appears above is seen. Two interface configuration commands can be used to enable priority queuing: queue-limit <num-packets> and tx-ring-limit <num-packets> where “num-packets” is the number of packets.

Beneath the priority checkbox, both input and output policing and default values are shown. Although priority queuing is only applicable to egress packets, policing can be done for both ingress and egress traffic. While the Committed Rate is left blank, we would expect the default behaviors of transmit when this configured value is obeyed and drop when this value is exceeded – and they are.

There is some interesting history behind the Burst Size parameter. For a number of years the VPN Concentrator had (past tense here since the product is EoS) been configurable for bandwidth management. The training associated with this product recommended that the instantaneous burst size be set to 1.5 times the committed rate in bytes/sec. As an example, if the committed rate was 56Kbps, the recommended burst size was (56000/8)*1.5 = 10,500 bytes.

Newer QoS literature (especially the Cisco Press book on this topic) has changed these recommendations. Cisco IOS^® chooses a default value for the burst size, if omitted, to the value of CIR/32 (where CIR would be our Committed Rate) or 1500, whichever is larger. As we can see here, the ASA chooses 1500 which must be manually overridden regardless of the value entered above for the Committed Rate.

References:

Cisco IP Telephony — Weighted Random Early Detection

Configuring Service Policy Rules using ASDM6.2

Related Courses:

ASAE — ASA Essentials

BW percent example

The mission-critical class gets a 200 Kbps bandwidth reservation since it is given a fixed sum guarantee of 20 percent.  20 percent of 1000k would be 200 kbps, so the voice priority class gets a maximum 200 kbps, mission critical receives 200 kpbs, the class interactive receives 100 kpbs and finally the class-default receives 250kpbs.

policy-map egressclassvoip class mission-critical
bandwidth percent 20
class interactive
bandwidth percent 10
class class-default
bandwidth percent 25
!
int s0/0
bandwidth 1000
service-policy output egress

BW Remaining example

See how bandwidth will be calculated when assigning the bandwidth always based upon an remaining value.  Let’s consider the same example from above but change it from bandwidth percent to remaining bandwidth percent:

policy-map egress
classvoip
priority percent 20
class mission-critical
bandwidth remaining percent 20
class interactive
bandwidth remaining percent 10
class class-default
bandwidth remaining percent 70
!
int s0/0
bandwidth 1000
service-policy output egress

Notice that the voice class still has a fixed sum guarantee of 20 percent of the interface configured bandwidth — .20 *  1000kpbs which is 200kpbs.

But now we have to calculate the max reserve bandwidth since this must deducted first before determining the bandwidth remaining.  As a reminder, the maximum reserved is how much you can ever reserve using the bandwidth or bandwidth percent statements. Cisco defines this formula as

Bandwidth available =
Bandwidth fixed sum guarantees – Max Reserve (75% of bandwidth by default)

Applying the formula to our example, we have 750Kpbs – 200 kpbs = 550kpbs.  Now the 550 kpbs will be divided out based upon the pre-defined percentages fore each class. Therefore, the Mission Critical class would receive (.20)(550 kpbs) = 110 kpbs, the class interactive will be 55 kpbs, and the class-default would receive 385 kpbs.

Also, if any class doesn’t use its full bandwidth allocation, the leftover will automatically be distributed to the other classes proportionally, based upon the configured percentages.

Author: Joe Parlas

Entry number 13 of this series offered a challenging pop quiz on how to configure QoS on a Cisco router using Modular QoS Command Line Interface (MQC) queuing mechanisms.

Here is the pop quiz question with the answer in the CLI output below.

Author: Paul Stryer

On the HQ WAN router, configure the appropriate MQC based queuing mechanism for the outbound traffic to the WAN s0/0, so that the following requirements will be met.

Only add the QoS commands to the below configuration, assume everything else needed for the network is finished or will be put in later.

• Class Map for voice that matches RTP, EF, CS3, and AF31
• Class Map for Bulk that matches FTP, and aF11
• Class map for Interactive that matches Citrix, and af21
• Name the policy: qos-policy
• Voice Traffic: 128 Kbps Maximum, use the IOS default burst values
• Interactive Traffic: 30 Kbps minimum
• Bulk Traffic: 24 Kbps minimum, also limit traffic to an average rate of 24 kbps by buffering excess traffic. Use the IOS default BC and BE
• Class-Default: Weighted Fair Queue with no bandwidth guarantee

Here is the basic configuration of the HQ router.

HQ#sh run
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname HQ
!
boot-start-marker
boot-end-marker
!
no aaa new-model
memory-size iomem 5
ip cef
!
multilink bundle-name authenticated
!
archive
log config
hidekeys
!

class-map match-any bulk match protocol ftp match ip dscp af11 class-map match-any interactive match protocol citrix match ip dscp af21 class-map match-any voice match protocol rtp match ip dscp cs3  af31  ef ! policy-map qos-policy class voice priority 128 class interactive bandwidth 30 class bulk bandwidth 16 shape average 24000 class class-default fair-queue !
interface FastEthernet0/0
ip address 192.168.100.1 255.255.255.0
duplex auto
speed auto
!
interface Serial0/0
bandwidth 384
ip address 10.11.12.1 255.255.255.254
encapsulation ppp
clock rate 2000000
service-policy output qos-policy
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
interface Serial0/1
no ip address
shutdown
clock rate 2000000
!
ip http server
no ip http secure-server
!
control-plane
!
line con 0
line aux 0
line vty 0 4
!
webvpn cef
!
end

[youtube=http://www.youtube.com/watch?v=HKWLrttpPOY]

Here is how the pop quiz will work. The question will be posed in this entry, number 13 in the QoS series. You can post your answers in the comments section below this text. The answer to the question will be posted in entry number 14 of this QoS series.

Here is the pop quiz question – Good Luck!

Author: Paul Stryer

On the HQ WAN router, configure the appropriate MQC based queuing mechanism for the outbound traffic to the WAN s0/0, so that the following requirements will be met.

Only add the QoS commands to the below configuration, assume everything else needed for the network is finished or will be put in later.

• Class Map for voice that matches RTP, EF, CS3, and AF31
• Class Map for Bulk that matches FTP, and aF11
• Class map for Interactive that matches Citrix, and af21
• Name the policy: qos-policy
• Voice Traffic: 128 Kbps Maximum, use the IOS default burst values
• Interactive Traffic: 30 Kbps minimum
• Bulk Traffic: 24 Kbps minimum, also limit traffic to an average rate of 24 kbps by buffering excess traffic. Use the IOS default BC and BE
• Class-Default: Weighted Fair Queue with no bandwidth guarantee

Here is the basic configuration of the HQ router.

HQ#sh run
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname HQ
!
boot-start-marker
boot-end-marker
!
no aaa new-model
memory-size iomem 5
ip cef
!
multilink bundle-name authenticated
!
archive
log config
hidekeys
!
interface FastEthernet0/0
ip address 192.168.100.1 255.255.255.0
duplex auto
speed auto
!
interface Serial0/0
bandwidth 384
ip address 10.11.12.1 255.255.255.254
encapsulation ppp
clock rate 2000000
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
interface Serial0/1
no ip address
shutdown
clock rate 2000000
!
ip http server
no ip http secure-server
!
control-plane
!
line con 0
line aux 0
line vty 0 4
!
webvpn cef
!
end

As seen in the previous section of this QoS series, CBWFQ provides user defined traffic classes allowing for more control and functionality than weighted Fair Queuing. CBWFQ uses matching criteria obtained by Network Based Application Recognition (NBAR), or access control lists (ACLs). A queue is reserved for each class and matching traffic is directed to that queue.

Low Latency Queuing
LLQ adds strict priority to the CBWFQ and allows delay sensitive data (Voice and Video) to be dequeued and sent before lower priority packets. This practice gives delay sensitive data preferential treatment over other traffic. To direct traffic to the LLQ, use the priority command for the class after the named class within a policy map is specified. Any class of traffic can be attached to a service policy, which uses priority scheduling, and that traffic can be prioritized over other class traffic.

When you specify the priority command for a class, it takes a bandwidth argument that gives maximum bandwidth in kilobits per second (kbps). Use this parameter to specify the maximum amount of bandwidth allocated for packets belonging to the class configured with the priority command. The bandwidth parameter both guarantees bandwidth to the priority class and restrains the flow of packets from the priority class.

Without Low Latency Queueing, CBWFQ provides weighted fair queuing based on defined classes with no strict priority queue available for real-time traffic. CBWFQ allows you to define traffic classes and then assign characteristics to that class. For CBWFQ all packets are serviced fairly based on weight; no class of packets may be granted strict priority. This scheme poses problems for voice traffic that is largely intolerant of delay, especially variation in delay. For voice traffic, variations in delay introduce irregularities of transmission manifesting as jitter in the heard conversation.

LLQ Configuration

In this configuration notice that the Class-Map VoIP sets the IP Precedence of 5, which sets all traffic with an IPP of 5 to this class. The priority command within the policy-map indicates the VoIP Class is a Priority Queue (PQ) and this traffic will get priority over other queues. In this example, the priority is set to 10% of the bandwidth for this traffic.

Priority Bandwidth = Allocates a fixed amount of bandwidth to a class to ensure expedited forwarding.
Priority Percent = Allocates a percentage of the configured or default interface bandwidth to ensure expedited forwarding.

LLQ Show Command

Author: Paul Stryer

References

• Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.4T
• End-To-End QoS network Design, by Tim Szigeti and Christina Hattingh – ISBN # 1–58705-176–1
• DiffServ – The Scalable End-To-End QoS Model
• Integrated Services Architecture
• Definition of the Differentiated Services Field
• An Architecture for Differentiated Services
• Requirements for IP Version 4 Routers
• An Expedited Forwarding PHB (Per-Hop Behavior)

CBWFQ provides user defined traffic classes allowing for more control and functionality then weighted Fair Queuing. CBWFQ uses matching criteria obtained by Network Based Application Recognition (NBAR), or access control lists (ACLs). A queue is reserved for each class and matching traffic is directed to that queue.

Low Latency Queuing (LLQ) adds priority to the CBWFQ and allows delay sensitive data to be dequeued and sent before lower priority packets, giving delay sensitive data preferential treatment over other traffic. LLQ will be discussed in the next part of this QoS series.

Class Based Weighted Fair Queuing
Once the packets have been matched and the class is defined, a characteristic is assigned to the class. The characteristics that are assigned are bandwidth, weight, and maximum packet limit. The bandwidth is the minimum bandwidth delivered to the class during congestion, and the maximum packets is how many packets are allowed to accumulate in the class queue before tail drops start happening to the worst finish time packets.

CBWFQ supports multiple class maps to classify traffic, with tail drop being the default dropping scheme. Weighted random early detection (WRED) can be used with CBWFQ to prevent class congestion. Guaranteed bandwidth is configured by weights and assigned to traffic classes. The following weights can be used to specify class weight. The reserve default is set to 75%, and must be within the allocated bandwidth. Single service policies cannot mix fixed bandwidth and bandwidth percentages commands.

• Bandwidth = This command allocates a fixed amount of bandwidth and the reserve bandwidth is subtracted from the available bandwidth of the interface where the service policy is used.
• Bandwidth percent = This command is used to allocate a percentage of the default or available bandwidth of an interface.
• Bandwidth remaining percent = This command allocates a portion of the unallocated bandwidth.

CBWFQ Best Practice
Cisco has set a best practice called the 75% Rule to help guide the configuration of CBWFQ on Cisco routers. The network administrator configuring CBWFQ should add up the bandwidth requirements for each major application such as voice, video and data. This sum should represent the minimum bandwidth requirements for any given link. This bandwidth calculation should not exceed 75% of the total available bandwidth for the link or Committed Information Rate for Frame Relay and ATM. This rule allows 25% overhead for routing protocols, layer 2 keep-alives and class default traffic. The Max-rerserved bandwidth command can override the 75% limitation set by default for most interfaces, but is not recommend.

CBWFQ Configuration

• Bandwidth = Sets a fixed amount of bandwidth in kbps
• Bandwidth percent = Allocates a percentage of the bandwidth to a class based on the interface bandwidth
• Bandwidth percent remaining = Allocates the percentage or remaining bandwidth to a class
• Queue Limit = Maximum packets a queue can hold with the default being 64

CBWFQ Show Command

The next blog in this QoS series will discuss Low Latency queuing (LLQ).

Author: Paul Stryer

References

• Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.4T
• End-To-End QoS network Design, by Tim Szigeti and Christina Hattingh – ISBN # 1–58705-176–1
• DiffServ – The Scalable End-To-End QoS Model
• Integrated Services Architecture
• Definition of the Differentiated Services Field
• An Architecture for Differentiated Services
• Requirements for IP Version 4 Routers
• An Expedited Forwarding PHB (Per-Hop Behavior)

WFQ is a flow-based queuing algorithm used in Quality of Service (QoS) that does two things simultaneously: It schedules interactive traffic to the front of the queue to reduce response time, and it fairly shares the remaining bandwidth between high bandwidth flows.

A stream of packets within a single session of a single application is known as flow or conversation. WFQ is a flow-based method that sends packets over the network and ensures packet transmission efficiency which is critical to the interactive traffic. This method automatically stabilizes network congestion between individual packet transmission flows. There are three types of WFQ:

• Flow based Weighted Fair Queuing
• VIP distributed Weighted Fair Queuing
• Class based Weighted Fair Queuing

The WFQ method has the advantage of being fast, reliable and easy to implement. WFQ follows these main criteria:

• Dedicated queues for each flow (referred to as conversations), messages are sorted into conversations reducing starvation, delay, and jitter within the queue.
• Allocating bandwidth fairly and accurately among all flows, reducing scheduling delay and guaranteeing service.
• IP Precedence is used as weight when allocating bandwidth.

Although bandwidth is allocated fairly among all flows, unfairness is reinstated by giving proportionately more bandwidth to flows with higher IP precedence or lower weight.

WFQ has to classify individual flows using the following information taken from the IP/TCP/UDP headers. These parameters are used as input for a hash algorithm that produces a fixed length number that is used as the index of the queue.

• Source IP address
• Destination IP address
• Protocol number to identify TCP or UDP
• Type of service field
• Source TCP/UDP port number
• Destination TCP/UDP port number

There is a fixed number of per flow queues, and the hash algorithm translates flow parameters into a queue number. The number of dynamically allocated queues is based on the interface bandwidth configuration and can be configured in a range between 16 and 4096 in multiples of 2. Here is a list of default dynamic queues based on bandwidth.

WFQ Insertion and Drop Policy

WFQ uses two methods to drop packets, Early and Aggressive dropping. Early dropping is when the congestion discard threshold is reached and aggressive dropping is when the hold-queue out limit is reached. WFQ always dropspackets of the most aggressive flows and uses the following two parameters to affect the way WFQ drops packets.

In this example, N is the number of packets in the WFQ system when the N-th packet arrives.

• Congestive discard Threshold (CDT) is used to start dropping packets of the most aggressive flows, even before the hold-queue limit is reached.
• Hold-queue out limit (HQO) defines the maximum number of packets that can be in the WFQ system at any time.

WFQ Scheduling

For scheduling purposes, in WFQ the length of the queue is not measured in packets but in the time it would take to transmit all the packets in the queue. WFQ adapts the number of flows and allocates equal amounts of bandwidth to each flow. Small packet flows which are usually interactive flows (voice and video) typically receive better service because they do not need a lot of bandwidth. They do need and receive low delay because smaller packets have a lower finish time.

Finish time is the sum of the current time and the time it takes to transmit the packet. Current time is zero if there are no packets in the queue. The first packet into this queue will have a finish time of current time + transmission time.

For example:

Current time = 0ms (no packets in the queue)
First packet = 100ms to transmit this packet
Finish time = 0 + 100ms = 100ms

Packet two comes into the queue
Current time = 100ms
2nd Packet = 20ms to transmit this packet
Finish Time = 100ms + 20ms = 120ms

WFQ will place the packets into the hardware queue based on the finish time lowest to highest. The last piece is to use the finish time and the IP precedence to introduce the weight into the calculation of which queues will be serviced in which order.

The calculation to add weight is finish time divided by IP Precedence plus one (to prevent division by zero). In Cisco routers this calculation is done differently to decrease the load on the routers CPU. The Cisco router uses the packet size instead of the transmission time as they are proportional to each other. In addition, the packet size is not divided by IP Precedence; instead the packet size is multiplied by a fixed value (one value for each IP Precedence value). This is done because division is a CPU intensive operation in comparison to multiplication.

Pros and Cons of WFQ
Pro

• Simple Configuration
• Guarantees throughput to all flows
• Drops packets of most aggressive flows
• Supported on most Cisco platforms and all IOS versions

Con

• Multiple flows can end up in one queue
• Does not support the configuration of classifications
• Cannot provide fixed bandwidth guarantees

WFQ Configuration
WFQ is enabled by default on all interfaces that have a default bandwidth of less than 2Mbps. Use the fair-queue command to enable WFQ on interfaces that do not have WFQ enabled.

Router(config-if)# [cdt [dynamic-queues [reservable-queues]]]

Congestive discard threshold (CDT) – Optional

• Number of packets allowed in the WFQ system before the router starts dropping new packets for the longest queue, with a value of 1 to 4096 (default 64)

Dynamic-queues — Optional

• Number of dynamic queues, with values of 16,32,64,128,512,1024,2048,4096

Reservable-queues — Optional
• Number of reservable queues if the RSVP feature is configures on the interface, with values of 0 to 1000

Router(config-if)# hold-queue max-limit out

Hold-queue Max (HQO)

• Maximum number of packets that can be in all output queues on the interface at any time
• Default is 1000

In most cases the hold-queue limit will never be reached because the CDT will start dropping the most aggressive conversations.

WFQ Show Commands

Router#show interface interface

Output Queue

• 0 packets in the WFQ system
• 1000 packets allowed in the WFQ system, set by the HQO
• 64 packets in anyone queue before CDT starts dropping aggressive flows
• 0 packets have been dropped

Conversations

• 0 active conversations
• 4 maximum number of concurrent conversations
• 256 total number of WFQ queues

Router#show queue interface-name interface-number

Show queue displays the packets inside a queue for a particular interface

• Depth = number of packets in the queue, the above example displays 1 packet
• Weight = depending on the IOS version the weight is calculated by “IP Precedence + 1” or “32,384/(IP Precedence + 1), the above example displays 4096
• Discards = represents drops due to CDT
• Tail Drops = represents drops due to HQO

Summary
This blog discussed Weighted Fair Queuing, the next blog in this QoS series will discuss Class Based WFQ and Low Latency queuing (LLQ).

Author: Paul Stryer

References

• Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.4T
• End-To-End QoS network Design, by Tim Szigeti and Christina Hattingh – ISBN # 1–58705-176–1
• DiffServ – The Scalable End-To-End QoS Model
• Integrated Services Architecture
• Definition of the Differentiated Services Field
• An Architecture for Differentiated Services
• Requirements for IP Version 4 Routers
• An Expedited Forwarding PHB (Per-Hop Behavior)

To refresh our memories, congestion can occur anywhere within a network, such as sections of the network that have speed mismatches, aggregations points, or confluences. Queuing algorithms are used to manage congestion. There are many different algorithms to serve multiple needs. The ultimate goal is to provide bandwidth and delay guarantees in order to prioritize the network traffic.

Speed mismatches occur when traffic moves from one speed network (such as a 100Mbps LAN) to another network with a different speed (Such as a 10Mbps LAN). This could be a LAN-to-LAN or LAN-to-WAN mismatch; however, usually it is a high speed to a low speed connection.

Aggregation congestion occurs when multiple connections feed into one main connection. A typical situation would be when multiple remote sites connect into one central site. For example if you have twenty remote sites with 256K WAN links that all connect to the headquarters via a single T1 connection, it would be very easy for the T1 connection to become oversubscribed.

Queuing Components
Queuing accommodates bursts on the router when the arrival rate of packets is greater than the departure rate. Two main reasons for bursts are the cause of queuing to be used:

1. Input interface is faster than the output interface
2. Output interface is receiving packets coming in from multiple other interfaces

Queuing is split into two parts:

1. Hardware queue: Uses FIFO , and is sometimes called the transmit queue (TxQ)
2. Software queue: Schedules packets into the hardware queue based on the QoS settings

A full hardware queue indicates interface congestion and software queuing is used to manage it. When a packet is being forwarded, the router will bypass the software queue if the hardware queue is not full.
First In First Out(FIFO)  Queuing

FIFO queuing algorithm is the simplest of the congestion management methods. All packets are treated equally, and placed into a single queue and serviced the order they were received. Hence the name FIRST-IN FIRST-OUT. FIFO queuing offers the following benefits:

• FIFO is supported on all Cisco Platforms
• FIFO queuing is supported in all version of Cisco IOS
• FIFO queuing places an extremely low load on the system when compared with other queuing mechanisms.
• FIFO queuing is predictable, and delay is determined by the maximum depth of the queue.
• FIFO queuing does not add significant queuing delay at each hop as long and the queue depth remains low.

FIFO queuing also poses the following limitations:

• FIFO queuing is extremely unfair when an aggressive flow contests with a time sensitive flow. Aggressive flows send a large number of packets, many of which are dropped. Time sensitive flows send a modest number of packets and most are dropped due to the queue always being full of aggressive flow packets. This behavior is called starvation.
• When the Queue is full, packets entering the queue have to wait longer. When the queue is not full, packets entering the queue do not have to wait as long as when the queue was full. Variation in delay is called Jitter.
• A single FIFO queue does not allow routers to organize buffered packets and service one class of traffic differently from other classes of traffic.
• During periods of congestion, FIFO queuing benefits UDP flows over TCP flows. When experiencing packet loss due to congestion, TCP based applications reduce their transmission rate. UDP based applications remain oblivious to packet loss and continue transmitting packets at their usual rate. Because TCP based applications slow their transmission rate to adapt to changing network conditions, FIFO queuing can result in increased delay, jitter, and a reduction in the amount of output bandwidth consumed byTCP applications.

Author: Paul Stryer

References

• Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.4T
• End-To-End QoS network Design, by Tim Szigeti and Christina Hattingh – ISBN # 1–58705-176–1
• DiffServ – The Scalable End-To-End QoS Model
• Integrated Services Architecture
• Definition of the Differentiated Services Field
• An Architecture for Differentiated Services
• Requirements for IP Version 4 Routers
• An Expedited Forwarding PHB (Per-Hop Behavior)