30.

1 Designing QoS for the WAN

Introduction 

An auto insurance company has decided to start a small branch office on the other side of
town. It is still a relatively small company and wants to make sure it does not end up
spending a large amount of money on the WAN.

To ensure this, the company has hired you to help an engineer install the WAN link between
the headquarters and the branch and to implement QoS on it.

The network engineer, Craig, is still new to networking, because his experience is with
servicing servers, laptops, and printers. He does not know much about WAN QoS, so while
installing the WAN link, you give him an overview of WAN links and QoS. He has some
questions about the topics that you have just taught him.

Choose an option:

 Review one or more topics before going to the Challenge

o Need for QoS in WAN and Branch
o Platform Performance Considerations
o Latency and Jitter Considerations
o Queuing Considerations
o Example: WAN and Branch QoS
 Go directly to the Challenge.
30.2 Designing QoS for the WAN

Need for QoS in WAN and Branch 

Packet loss and jitter are most apparent on WAN and branch devices. Because of this fact,
QoS in those places must be carefully considered because it can have a major impact on the
quality of real-time applications.

Primary goals of WAN and branch QoS:

 Control packet loss and jitter by queuing.

 Increase classification granularity by using deep packet inspection engines.

Same strategic QoS principles must be followed to enable end-to-end QoS design.

A major problem with the WAN and branch edge is in low-speed links in comparison to
speeds in LAN and campus networks. The difference in those speeds can lead to filled buffers
and lost packets. On WAN and branch links, a packet can be significantly delayed. A delayed
packet is just as bad as a dropped packet, because sometimes a packet is delayed too much
and is dropped at the receiver because it exceeds the dejitter buffer space. To cope with
packet loss and jitter, appropriate queuing policies must be implemented.

The WAN and branch edge devices enable the use of QoS tools such as medianet or AVC
that will enhance classification granularity.

Like in a campus, data center, or VPN, you must follow the same strategic QoS principles
and best-design principles to enable end-to-end QoS design:

 Perform QoS in hardware whenever possible.

 Classify and mark applications as close as possible to the source.
 Enable queuing at every node that has a potential for congestion.
 Enable Control Plane Policing to protect the data and control planes.
30.3 Designing QoS for the WAN

Platform Performance Considerations 

You must be aware of several platform performance considerations when you choose a WAN
or branch router for a QoS configuration.

You must consider the following performance facts when you deploy QoS on Cisco routers:

 Most Cisco routers perform QoS operations in software.

 The selected router platform must fulfill performance requirements.
 Hardware acceleration features, link speeds, policy complexity, packet rates, and sizes
influence your platform selection.

Most Cisco routers perform QoS operations in software, which results in increased CPU
cycles when QoS is deployed. Some exceptions, such as the Cisco Catalyst 6500 Series
Switch, the Cisco 6700 Series Multiservice Access Platform, and the Cisco Aggregation
Services Router (ASR), perform QoS operations in both software and hardware.

Enabling QoS in Cisco IOS Software has several advantages:

 Cross-platform consistency of QoS features—for example, LLQ, CBWFQ

 Syntax of QoS configuration is consistent—MQC configuration approach is present in
all platforms
 Reach set of QoS features—NBAR/NBAR2 or hierarchical QoS is not available on
Catalyst switch platforms



Cisco Router Platform Performance Capacity
Cisco ASR 1000-ESP100 100 Gbps
Cisco ASR 1000-ESP20 20 Gbps
Cisco ASR 1002 2.5 Gbps
Cisco 3945E Integrated Services Routers Generation 2 (ISR G2) 350 Mbps
Cisco 3945 ISR G2 150 Mbps
Cisco 2951 ISR G2 75 Mbps
Cisco 2901 ISR G2 25 Mbps
Cisco 1921 ISR G2 15 Mbps

The table represents the product platforms and related performance capacity examples that
are used as a planning reference.

Note

Note that the products that are listed in the table are illustrative. Please refer to Cisco.com for
updated information.

Note

You usually use ISR G2 routers as branch routers. You usually use aggregation routers in a
WAN.
30.4 Designing QoS for the WAN

Latency and Jitter Considerations 

Latency and jitter are important factors when you deploy real-time applications over WANs.
Control of latency and jitter is performed by using reliable WAN links and by using QoS
tools within your network.

Main latency and jitter considerations:

 Latency is commonly beyond your control.

 Choose reliable ISP to maintain latency in reasonable limits.
 Latency should not exceed 150 ms and jitter should not exceed 30 ms.
 You can only influence variable delay such as queueing delay.

The ITU G.114 recommendation states that one-way latency for real-time applications such
as voice and video is within 150 ms. To stay within this limit, it is important that you
understand factors that influence overall delay in the network:

 Serialization delay
 Propagation delay
 Queuing delay

Some types of delays such as serialization delay and propagation delay are fixed. The
network administrator cannot control them. Serialization delay mainly depends on the line
rate (circuit speed), and propagation delay depends on the physical distance between the
sender and receiver. However, queuing delay is a variable type of delay that depends on the
congestion in the device that processes the packet. For delay-sensitive packets, you can apply
a queuing policy that will shorten the time in which a packet stays in the queue of the device
that is congested. It is important to send real-time traffic packets onto the wire first because
they must be received within the dejitter buffer time limits. Any received packet that is
delayed beyond the dejitter buffer limit is as good as lost. Such cases affect the overall real-
time application quality.
30.5 Designing QoS for the WAN

Queuing Considerations 

It is important to control various types of delays such as queuing delay. So some

considerations regarding queuing must be taken into account when you plan and implement
end-to-end QoS in your network.

Main queuing recommendations:

 Tx ring is final FIFO queue; tune only if necessary.

 Limit LLQ to 33 percent of bandwidth; do not enable WRED.
 For CBWFQ, provision bandwidth allocation according to application requirements;
DSCP-based WRED can be enabled.

When you design queuing policies in the network, you must be aware of a few facts. The
final output when sending frames onto the wire is the Tx ring. The Tx ring is a FIFO queue
that maximizes bandwidth by matching the output packet rate to the rate of the physical
interface. On certain Cisco platforms, the Tx ring can be configured to allow a deeper or
shallow queue. Lowering the value of the Tx ring will enforce the Cisco IOS Software
queuing engine to queue packets sooner and more often, resulting in overall lower jitter and
delay values for priority traffic. On the other side, setting the Tx ring too low can cause
higher CPU utilization. You must bear this consequence in mind when making a trade-off
between delay and jitter and CPU utilization.

For queuing in software, there are three basic queuing management strategies that you can
use on WAN and branch edge devices:

 CBWFQ: CBWFQ is a queuing algorithm. Use this algorithm to guarantee minimum

bandwidth for certain traffic classes.
 LLQ: LLQ is a queuing algorithm. Use this algorithm to transport real-time traffic
applications within the priority queue and to guarantee minimum bandwidth for other
traffic types. This approach protects real-time traffic and prevents other traffic types
from interfering with real-time traffic. However, be aware that the priority queue is
always limited by the rate that is configured within that class, because an implicit
policer is applied for priority traffic class.
 WRED: WRED is a congestion avoidance algorithm. Use this mechanism for TCP-
based applications to avoid congestion by dropping lower-priority packets before
congestion occurs.

LLQ recommendations for the WAN and branch edge can be summarized in these ways:

 Provision no more than 33 percent of link bandwidth capacity for LLQ.

 Do not enable the WRED mechanism for LLQ.

CBWFQ recommendations for the WAN and branch edge can be summarized in these ways:
 On CBWFQ, separate classes are assigned bandwidth allocations according to
application requirements.
 Depending on the class of the traffic, you may use DSCP-based WRED to minimize
TCP global synchronization.
 For the control CBWFQ traffic class, it is not recommended to enable fair-queuing
presorters or DSCP-based WRED, because those packets should never be dropped or
reordered.
 For the multimedia and data CBWFQ class, fair-queuing presorters and DSCP-based
WRED can be enabled.
 For the scavenger CBWFQ class, it is not recommended to enable presorters or
DSCP-based WRED.
 For the default CBWFQ class, you can enable presorters or DSCP-based WRED if
needed. Also allocate a minimum of 25 percent of bandwidth.
30.6 Designing QoS for the WAN

Example: WAN and Branch QoS 

Company A has a hub-and-spoke network topology with WAN links over private WAN,
MPLS, and IPsec. The company wants to deploy QoS over those WAN links in order to
provide quality for real-time applications.

The resulting policies that are applied at different points on the network WAN and branch
edge devices are provided as follows:

 Policy 1 is for the WAN aggregator LAN edge—enable ingress DSCP-trust, and
optionally enable ingress NBAR2 classification and marking. Egress
LLQ/CBWFQ/WRED may be enabled if required.

 Policy 2 is for the WAN aggregator WAN edge—enable ingress DSCP-trust; egress
LLQ/CBWFQ/WRED should be enabled. RSVP policies or VPN-specific policies
may be enabled.
 Policy 3 is for the branch WAN edge—enable ingress DSCP-trust; egress
LLQ/CBWFQ/WRED should be enabled. RSVP policies or VPN-specific policies
may be enabled.

 Policy 4 is for the branch LAN edge—enable ingress DSCP-trust. NBAR2

classification and LLQ/CBWFQ/WRED policies may be applied if required.