Enterprise QoS Solution Reference Network Design Guide
Enterprise QoS Solution Reference Network Design Guide
Enterprise QoS Solution Reference Network Design Guide
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Summary<br />
Summary<br />
2-124<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 />
This chapter began with establishing the case for Campus <strong>QoS</strong> by way of three main <strong>QoS</strong> design<br />
principles:<br />
The first is that applications should be classified and marked as close to their sources as technically<br />
and administratively feasible.<br />
The second is that unwanted traffic flows should be policed as close to their sources as possible.<br />
The third is that <strong>QoS</strong> should always be performed in hardware, rather than software, whenever a<br />
choice exists.<br />
Furthermore, it was emphasized that the only way to provide service guarantees is to enable queuing at<br />
any node that has the potential for congestion, including campus uplinks and downlinks.<br />
A proactive approach to mitigating DoS/worm flooding attacks within campus environments was<br />
overviewed. This approach focused on access edge policers that could meter traffic rates received from<br />
endpoint devices and when these exceed specified watermarks (at which point they are no longer<br />
considered normal flows), these policers could markdown excess traffic to the Scavenger class. These<br />
policers would be coupled with queuing policies throughout the enterprise that provisioned for a<br />
less-than Best-Effort Scavenger class on all links. In this manner, legitimate traffic bursts would not be<br />
affected, but DoS/worm generated traffic would be significantly mitigated.<br />
Common endpoints were overviewed and classified into three main groups: 1) Trusted Endpoints, 2)<br />
Untrusted Endpoints, and 3) Conditionally-Trusted Endpoints. Untrusted Endpoints were subdivided<br />
into two smaller models: Untrusted PCs and Untrusted Servers; similarly, Conditionally-Trusted<br />
Endpoints were subdived into two models: Basic and Advanced.<br />
Following these access edge Model definitions, platform-specific recommendations were given to on<br />
how to implement these access edge models on Cisco Catalyst 2950, 2970, 3550, 3560, 3750, 4500, and<br />
6500 series switches. Platform-specific limitations, caveats, or nerd-knobs were highlighted to tailor<br />
each model to each platforms unique feature sets. All configurations were presented in config-mode to<br />
continually highlight what platform was being discussed. Furthermore, many relevant verification<br />
commands were discussed in detail (in context) to illustrate how and when these could be used<br />
effectively when deploying <strong>QoS</strong> within the campus.<br />
Recommendations were also given on how to configure queuing on a per-platform/per-linecard basis.<br />
These recommendations included configuring 1P3Q1T queuing on the Catalyst 2950, 1P3Q2T queuing<br />
on the Catalyst 3550, configuring 1P3Q3T queuing on the Catalyst 2970/3560/3750, and configuring<br />
1P3Q1T queuing (with DBL) on the Catalyst 4500. For the Catalyst 6500, linecard-specific queuing<br />
structures were examined in detail, including CatOS and IOS configurations for configuring 2Q2T,<br />
1P2Q1T, 1P2Q2T, 1P3Q1T, 1P3Q8T, and 1P7Q8T queuing.<br />
Following this, the Catalyst 6500 PFC3’s Per-User Microflow Policing feature was discussed in the<br />
context of how it could be leveraged to provide a second line of policing defense at the distribution layer.<br />
Finally, Campus-to-WAN/VPN handoff considerations were examined. It was recommended:<br />
First, resist the urge to automatically use a GigabitEthernet connection to the WAN Aggregation<br />
router, even if the router supports GE.<br />
Second, if the combined WAN circuit-rate is significantly below 100 Mbps, enable egress shaping<br />
on the Catalyst switches (when supported).<br />
Third, if the combined WAN circuit-rate is significantly below 100 Mbps and the Catalyst switch<br />
does not support shaping, enable egress policing (when supported).<br />
Version 3.3