19.07.2013 Views

Enterprise QoS Solution Reference Network Design Guide

Enterprise QoS Solution Reference Network Design Guide

Enterprise QoS Solution Reference Network Design Guide

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

<strong>QoS</strong> <strong>Design</strong> Overview<br />

2-2<br />

<strong>Enterprise</strong> <strong>QoS</strong> <strong>Solution</strong> <strong>Reference</strong> <strong>Network</strong> <strong>Design</strong> <strong>Guide</strong><br />

Chapter 2 Campus <strong>QoS</strong> <strong>Design</strong><br />

Classify and mark applications as close to their sources as technically and administratively feasible.<br />

This principle promotes end-to-end Differentiated Services/Per-Hop Behaviors. Sometimes<br />

endpoints can be trusted to set Class of Service (CoS)/Differentiated Services Code Point (DSCP)<br />

markings correctly, but this is not recommended because users can easily abuse provisioned <strong>QoS</strong><br />

policies if permitted to mark their own traffic.<br />

For example, if DSCP Expedited Forwarding (EF) received priority services throughout the<br />

enterprise, a user could easily configure the NIC on a PC to mark all traffic to DSCP EF, thus<br />

hijacking network priority queues to service their non-real time traffic. Such abuse could easily ruin<br />

the service quality of real time applications (like VoIP) throughout the enterprise. For this reason,<br />

the clause “as close as… administratively feasible” is included in the design principle.<br />

Police unwanted traffic flows as close to their sources as possible.<br />

There is little sense in forwarding unwanted traffic only to police and drop it at a subsequent node.<br />

This is especially the case when the unwanted traffic is the result of Denial of Service (DoS) or worm<br />

attacks. Such attacks can cause network outages by overwhelming network device processors with<br />

traffic.<br />

Always perform <strong>QoS</strong> in hardware rather than software when a choice exists.<br />

Cisco IOS routers perform <strong>QoS</strong> in software. This places additional demands on the CPU, depending<br />

on the complexity and functionality of the policy. Cisco Catalyst switches, on the other hand,<br />

perform <strong>QoS</strong> in dedicated hardware ASICS and as such do not tax their main CPUs to administer<br />

<strong>QoS</strong> policies. You can therefore apply complex <strong>QoS</strong> policies at Gigabit/TenGigabitEthernet line<br />

speeds in these switches.<br />

For these reasons, you should enable <strong>QoS</strong> policies such as classification and marking policies to<br />

establish and enforce trust boundaries as well as policers to protect against undesired flows at the access<br />

edge of the LAN.<br />

Most campus links are underutilized. Some studies have shown that 95 percent of campus access layer<br />

links are utilized at less than 5 percent of their capacity. This means that you can design campus networks<br />

to accommodate oversubscription between access, distribution and core layers. Oversubscription allows<br />

for uplinks to be utilized more efficiently and more importantly, reduces the overall cost of building the<br />

campus network.<br />

Common campus oversubscription values are 20:1 for the access-to-distribution layers and 4:1 for the<br />

distribution-to-core layers, as shown in Figure 2-1.<br />

Figure 2-1 Typical Campus Oversubscription Ratios<br />

Core<br />

Distribution<br />

Access<br />

Si Si<br />

Si Si<br />

Typical 4:1<br />

Oversubscription<br />

Typical 20:1<br />

Oversubscription<br />

Version 3.3

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!