Enterprise QoS Solution Reference Network Design Guide

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