服务质量（QoS）在富媒体园区网络中的主要作用不是控制等待时间或抖动（就像在广域网[ WAN ]或虚拟专用网[ VPN ]中一样），而是管理数据包丢失。
在当今的园区网络中，端点以千兆位以太网（GE）的速度连接到网络，仅需几毫秒的拥塞即可导致瞬时缓冲区超载，从而导致边缘或10GE/40GE核心中的数据包丢失。
QoS在园区中通常扮演的次要角色是区分和管理应用程序流量，尤其是在访问边缘。
硬件QOS对比软件QoS
只要有选择，就始终在硬件而非软件中启用QoS策略。某些路由器（例如Cisco Integrated Services路由器[ISR]）在软件层面执行QoS，从而在CPU上增加了负载。
实际的增量负载将取决于众多因素，其中包括：
- policy策略的复杂性和功能
- 流量和构成
- 接口速率
- CPU速率
- 路由器内存尺寸
例如，假设管理员可以选择在端点直接连接到的Catalyst交换机（在硬件中）或该交换机连接到的ISR路由器的LAN边缘接口的分支网络中部署分类和标记策略。 （在软件中）。
在这里，由于可以选择策略的设计位置，因此在Catalyst交换机中进行分类和标记会更加有效。
但是，在某些情况下，可能不存在这样的选择。继续该示例：可能需要业务对分支机构发起的流量执行NBAR深度数据包检查（DPI）（Catalyst交换机当前不支持），因此管理员将必须应用所需的分类和标记策略在ISR路由器上。
QoS设计：分类和标记
- 在技术和管理上可行的情况下，将应用程序分类并标记为尽可能接近其来源。
- 尽可能使用DSCP标记。
- 遵循基于标准的差异化服务代码点（DSCP）每跳行为（PHB）标记，以确保互操作性和将来的扩展。
在对流量进行分类和标记时，建议的设计原则是在技术和管理上可行的情况下，对应用程序进行分类和标记，使其尽可能接近其来源。该原则促进了端到端差异化服务（DiffServ）和PHB。 通常，建议不要信任用户可以在其PC或其他类似设备上设置的标记，因为如果允许用户标记自己的流量，他们很容易滥用预配置的QoS策略。 例如，如果 已通过网络配置了快速转发（EF）PHB，则PC用户可以轻松地将其所有流量配置为标记为EF，从而劫持网络优先级队列以服务其非实时流量。 这种滥用很容易破坏整个企业中实时应用程序的服务质量。但是，如果有用于集中管理PC QoS标记的企业控件，则信任它们可能是可接受的设计选项。 遵循此一般规则，进一步建议尽可能使用DSCP标记，因为这些第3层IP标头标记比第2层标记是端到端，更精细和可扩展的。 只需记住，当媒体更改（例如，LAN到WAN/VPN边缘）时，第2层标记会丢失。
QoS设计：Policing管制和降级
- Policing管制的交通流尽可能靠近其来源。
- 尽可能根据基于标准的规则进行标记。
没有什么理由只将不需要的流量转发给Policing管制，并将其丢弃到下游节点，尤其是当不需要的流量是DoS或蠕虫攻击的结果时。此外，此类攻击可能会产生大量流量，这可能会通过将网络设备处理器驱动到最大级别来导致网络中断。
因此，建议对流量尽可能靠近其来源进行管制。
该原理也适用于合法流量，因为蠕虫生成的流量可能会在合法且众所周知的TCP/UDP端口下伪装，并导致大量流量涌入网络基础架构。此类过量应在源头进行监控，并适当加以标记。
无论何时支持，降价都应根据基于标准的规则进行，例如 RFC 2597，AF PHB定义。例如，标记为AFx1的多余流量应标记为AFx2。在进行此类降价之后，应将拥塞管理策略（例如基于DSCP的加权随机早期检测（WRED））配置为比AFx2更积极地丢弃AFx3，而AFx2则应比AFx1更积极地丢弃。
QoS设计排队和丢弃
在QoS设计中，您始终需要考虑一些因素。
- 在每个可能造成拥塞的节点上启用排队策略。
- 尽可能将每个应用程序类分配给自己的专用队列。
仅使用至少提供以下四种基于标准的排队行为的平台/服务提供商：
- 加急转发PHB
- 保证转发PHB
- 默认转发PHB
- 降低每个域的工作量
无论网络条件如何，关键业务应用程序都需要服务保证。提供服务保证的唯一方法是在任何可能发生拥塞的节点上启用排队；实际上，无论发生这种情况的可能性如何。 该原理不仅适用于速度不匹配最明显的园区到WAN/VPN边缘，还适用于园区间交换链路，其中超额订购比率会造成瞬时拥塞和缓冲区超载的可能性。除了在速度不匹配的任何地方启用排队之外，没有其他方法可以保证服务水平。 另外，由于每个应用程序类别都有独特的服务级别要求，因此最好将每个应用程序分配一个专用队列。以这种方式，可以将特定的带宽分配和丢弃策略分配给每个离散的应用程序类别，以满足其独特的QoS要求。 如果将多个应用程序类分配到一个公共排队存储桶中，则管理员不再可以根据其各自的需求来控制是否在这些应用程序类之间共享带宽资源。
QoS设计：33％LLQ规则
- 将严格优先级队列的数量限制为链路带宽容量的33％。
- 通过准入控制机制管理严格优先级的流量。
- 不要在此队列上启用WRED。
分配给实时队列的带宽量通常是可变的。但是，如果为大多数带宽提供了严格优先级排队（先进先出[FIFO]队列），则总体效果是削弱了QoS功能。这既会抖动敏感的实时应用程序（在FIFO优先级队列中相互竞争），也将是非实时应用程序。
发生这种情况的原因是，这些优先级队列可能会定期接收大量的带宽分配波动，具体取决于优先队列正在服务的流量的瞬时量。
请记住，融合的目标是使语音，视频和数据应用程序透明地共存于单个网络中。当实时应用程序主导链路时，非实时应用程序的响应时间会大幅波动，从而破坏融合网络的透明度。
例如，考虑配置为支持EF PHB服务的两个网真（CTS-3000）呼叫的（45-Mbps）DS3链路。假设两个系统都配置为在启用所有可选组件的情况下都支持最高级别的分辨率（全HD-1080p），则每个此类调用都需要约20 Mbps的严格优先级排队。
在发出这些TelePresence呼叫之前，非实时应用程序可以访问链路上100％的带宽。
为了简化示例，请假定此链接上没有其他实时应用程序。但是，一旦建立了这些网真呼叫，所有非实时应用程序都将突然争夺该链路的10％。
TCP窗口将生效，并且许多应用程序挂起，超时或陷入无响应状态，这通常会转化为用户致电IT服务台，抱怨网络恰好正常运行，尽管配置不正确。
清道夫类队列建议
- 为Scavenger类队列分配最小带宽。
- Scavenger类队列上不需要WRED。
每当启用Scavenger排队类时，都应该为其分配最小带宽，例如1％或平台支持的最小带宽分配。
Scavenger类队列上不需要WRED，因为分配给此队列的流量没有隐含的“诚信”服务保证或期望。无论如何，WRED仅在发生拥塞时才处于活动状态，并且此时该队列已经被非常积极地丢弃。因此，添加此功能几乎无济于事。
最后，如果在执行软件QoS的路由器上启用，则在此类上启用WRED实际上会被证明是浪费的，因为它将消耗额外的不必要的CPU资源。下图总结了这些最小排队功能和建议。
WRED建议
- 在AF队列上启用基于DSCP的WRED。
- 在DF队列上启用WRED。
- 不要在EF队列上启用基于DSCP的WRED。
- 不要在清除程序队列上启用WRED。
- 不要在控制流量应用程序类队列上启用WRED。
- （可选）一致地调整WRED阈值。
建议在所有AF队列上启用基于DSCP的WRED，并在默认的尽力而为队列上启用WRED（以提高应用程序吞吐量）。此外，它是不建议在EF队列启用WRED因为在这个队列的流量通常下降敏感，也不在清道夫队列，因为这是不必要的和潜在的浪费。
同样，不建议在专用于服务控制流量（例如路由，信令或管理）的任何队列上启用WRED。这样的流量对于基础架构的正常运行至关重要，因此绝对不能提早丢弃（如果有的话）。如果您注意到在分配给控制流量类别的队列上发生掉线，则应重新设置这些队列以适应这些情况。
最后，在某些平台上，默认WRED阈值与其他平台不一致或未完全使用队列深度。因此，可以按照以下方式将它们显式调整为一致和兼容。设置以下最低WRED阈值：
- AFx3到队列深度的60％。
- AFx2到队列深度的70％。
- AFx1到队列深度的80％。
- 将所有WRED最大阈值设置为100％。
下图显示了这些可选的WRED调整建议。
