目录

封面

扉页

版权

内容提要

关于作者

关于技术审稿人

献辞

致谢

前言

第1部分 QoS设计概述

第1章 QoS与QoE的介绍及回顾

1.1 历史与演变

1.1.1 曾经

1.1.2 现在

1.1.3 QoS的演变

1.2 QoS基础及概念

1.2.1 用户期望:QoS、QoE和QoX

1.2.2 QoS模型:集成服务和差分服务

1.2.3 QoS基础概念和工具集

1.2.4 数据包头

1.2.5 简化QoS

1.3 标准化与一致性

1.4 小结

1.5 扩展阅读

1.5.1 通用内容

1.5.2 IntServ（集成服务）

1.5.3 DiffServ（差分服务）

第2章 基于IOS的QoS体系框架和语法结构

2.1 部署QoS的原则

2.2 QoS体系框架

2.2.1 QoS行为模型

2.2.2 QoS特性排序

2.3 模块化QoS命令行模型

2.3.1 MQC语法

2.3.2 默认行为

2.3.3 流量分类（class map）

2.3.4 定义策略（policy map）

2.3.5 为流量应用策略（service policy）

2.3.6 层级式QoS和HQF

2.3.7 传统的QoS CLI不再使用

2.4 AutoQoS

2.5 小结

2.6 扩展阅读

2.6.1 通用内容

2.6.2 AutoQoS

第3章 分类与标记

3.1 分类和标记

3.1.1 分类和标记的术语

3.1.2 安全与QoS

3.1.3 视频和无线流量带来的分类挑战

3.1.4 不同技术的标记字段

3.1.5 QoS标记的映射

3.2 分类工具

3.2.1 基于类的分类（class map）

3.2.2 基于网络的应用识别

3.3 标记工具

3.3.1 基于类的标记（class map）

3.3.2 标记（或重标记）与限速联用

3.3.3 AutoQoS标记

3.4 建议与指导

3.5 小结

3.6 扩展阅读

3.6.1 分类和标记

3.6.2 NBAR

3.6.3 视频QoS

3.6.4 无线QoS

3.6.5 RFC

第4章 限速、整形和降级工具

4.1 限速和整形

4.1.1 限速与整形的术语

4.1.2 令牌桶算法

4.1.3 限速器类型

4.1.4 安全和QoS

4.2 限速工具

4.2.1 以限速器作为标记器

4.2.2 基于类的限速（policy map）

4.2.3 控制层面的限速

4.2.4 无条件数据包丢弃

4.3 流量整形工具

4.3.1 基于类的整形（class map）

4.3.2 传统整形工具

4.4 建议与指导

4.5 小结

4.6 扩展阅读

4.6.1 通用内容

4.6.2 差分服务限速标准

4.6.3 限速

4.6.4 整形

第5章 拥塞管理和拥塞避免工具

5.1 拥塞管理和避免

5.1.1 拥塞管理和拥塞避免的术语

5.1.2 拥塞管理和拥塞避免

5.1.3 调度机制算法

5.1.4 网络中各层的队列

5.2 队列和调度机制的工具

5.2.1 基于类的队列（policy map）

5.2.2 三层以下的队列技术:Tx-Ring的工作方式

5.3 拥塞避免工具

5.3.1 随机早期检测（RED）

5.3.2 加权随机早期检测（WRED）

5.4 建议与指导

5.5 小结

5.6 扩展阅读

5.6.1 队列技术

5.6.2 拥塞避免技术

第6章 带宽预留工具

6.1 准入控制工具

6.2 资源预留协议

6.2.1 RSVP概述

6.2.2 RSVP代理

6.2.3 RSVP部署模型

6.2.4 RSVP和LLQ

6.3 建议和指导

6.4 小结

6.5 扩展阅读

6.5.1 媒体网络中的RSVP

6.5.2 RSVP技术

第7章 IPv6网络中的QoS

7.1 IPv6和QoS概述

7.2 适用于IPv6的QoS工具

7.2.1 支持IPv6的QoS特性

7.2.2 数据包头部、分类和标记

7.2.3 限速和整形

7.3 建议和指导

7.4 小结

7.5 扩展阅读

第8章 媒体网络

8.1 介绍媒体网络

8.2 媒体网络的架构与框架

8.3 媒体网络的特性和能力

8.3.1 自动配置

8.3.2 媒体监测

8.3.3 媒体可感知

8.4 小结

8.5 扩展阅读

8.5.1 概述

8.5.2 设计文档

8.5.3 配置指南和命令说明

8.5.4 资源和服务

第9章 应用可视性控制

9.1 AVC使用案例

9.2 AVC的工作原理

9.3 AVC的构成

9.3.1 构成部分1:NBAR2

9.3.2 构成部分2:Flexible NetFlow

9.3.3 构成部分3:AVC的管理和报告

9.3.4 构成部分4:AVC的QoS控制

9.4 使用AVC的性能考量

9.5 小结

9.6 扩展阅读

第2部分 QoS设计战略

第10章 商业和应用的QoS需求

10.1 网络互联的全球发展趋势

10.2 视频应用的变革

10.3 媒体激增

10.4 社会网络互联现象

10.5 需求:自备设备

10.6 出现自下而上的应用

10.7 多媒体应用中融合了多种类型的媒体

10.8 迈向高清媒体时代

10.9 各个应用类别的QoS需求与推荐方案

10.9.1 语音应用

10.9.2 视频应用

10.9.3 多媒体应用

10.9.4 数据应用

10.9.5 控制层流量

10.10 Cisco（基于RFC 4594）为不同应用类别推荐的QoS策略

10.11 QoS标准的发展

10.11.1 RFC 2597, Clarification

10.11.2 RFC 5865, Proposed Standard

10.11.3 RFC 4594, Update Draft

10.12 小结

10.13 扩展阅读

第11章 QoS的设计原则与方法

11.1 QoS最佳做法的设计原则

11.1.1 硬件与软件QoS最佳方案

11.1.2 分类和标记最佳方案

11.1.3 限速及降级的最佳做法

11.1.4 队列及丢弃的最佳做法

11.2 QoS的设计原则

11.2.1 4类模型QoS战略

11.2.2 8类模型QoS战略

11.2.3 12类模型QoS战略

11.2.4 应用类扩展QoS战略

11.2.5 用于安全策略的QoS

11.3 小结

11.4 扩展阅读

第12章 战略性QoS设计的案例研究

12.1 Tifosi Software公司:公司概况

12.2 原始（4类）QoS模型

12.3 重新设计QoS的业务催化剂

12.4 8类QoS模型提议

12.5 “第8层”挑战

12.6 小结

12.7 扩展阅读

第3部分 园区网QoS设计

第13章 园区网QoS设计的注意事项与建议

13.1 MLS与MQC

13.2 默认QoS

13.3 内部DSCP

13.4 信任状态与工作原理

13.5 信任边界

13.6 DSCP透传

13.7 基于端口的QoS、基于VLAN的QoS与每端口/每VLAN QoS

13.8 EtherChannel QoS

13.9 园区网QoS模型

13.9.1 入向QoS模型

13.9.2 出向QoS模型

13.10 园区网端口QoS角色

13.11 园区网AutoQoS

13.12 控制层面限速

13.13 小结

13.14 扩展阅读

第14章 园区网接入层（Cisco Catalyst 3750）的QoS设计

14.1 Cisco Catalyst 3750 QoS架构

14.2 QoS设计步骤

14.2.1 启用QoS

14.2.2 入向QoS模型

14.2.3 队列模型

14.3 其他与平台相关的QoS设计选项

14.3.1 每VLAN QoS设计

14.3.2 每端口/每VLAN QoS

14.3.3 EtherChannel QoS设计

14.3.4 AutoQoS SRND4

14.3.5 控制层面限速

14.4 小结

14.5 扩展阅读

第15章 园区网分布层（Cisco Catalyst 4500）的QoS设计

15.1 Cisco Catalyst 4500 QoS架构

15.2 QoS设计步骤

15.3 队列模型

15.3.1 4类出向队列模型

15.3.2 8类出向队列模型

15.3.3 12类出向队列模型

15.4 与平台相关的其他QoS设计选项

15.4.1 访问边界设计选项

15.4.2 每VLAN QoS设计

15.4.3 每端口/每VLAN QoS

15.4.4 EtherChannel QoS设计

15.4.5 基于流的QoS

15.4.6 AutoQoS SRND4

15.4.7 控制层面限速

15.5 小结

15.6 扩展阅读

第16章 园区网核心层（Cisco Catalyst 6500）的QoS设计

16.1 Cisco Catalyst 6500 QoS架构

16.2 QoS设计步骤

16.3 队列模型

16.3.1 4类（4Q4T入向和1P3Q4T出向）队列模型

16.3.2 8类（8Q4T入向和1P7Q4T出向）队列模型

16.3.3 12类（8Q4T入向和1P7Q4T出向）队列模型

16.3.4 2P6Q4T入向和出向队列模型

16.4 与平台相关的其他QoS设计选项

16.4.1 接入边界设计选项

16.4.2 微流限速

16.4.3 每VLAN QoS设计

16.4.4 EtherChannel QoS设计

16.4.5 AutoQoS SRND4

16.4.6 控制层面限速

16.5 小结

16.6 扩展阅读

第17章 园区网QoS设计的案例研究

17.1 Tifosi园区网接入层QoS设计

17.1.1 策略1:打印机设备的接入边界设计（不信任）

17.1.2 策略2:无线接入点设备的接入边界设计（DSCP信任）

17.1.3 策略3:Cisco TelePresence 设备的接入边界设计（条件信任）

17.1.4 策略4:Cisco IP电话或PC的接入边界设计（条件信任、分类和标记）

17.1.5 8类1P1Q3T入向队列设计

17.1.6 8类1P1Q3T出向队列设计

17.1.7 策略5:接入层上行链路设计

17.2 Tifosi园区网分布层QoS设计

17.2.1 策略6:分布层下行链路端口（Catalyst 4500E Supervisor 7-E）

17.2.2 策略7:分布层分布链路/核心上行链路端口

17.3 Tifosi园区网核心层QoS设计

17.3.1 策略8:核心层（10GE）下行链路设计

17.3.2 策略9:核心层（40GE）核心链路设计

17.4 小结

17.5 扩展阅读

第4部分 无线LAN QoS设计

第18章 无线LAN QoS设计的注意事项与建议

18.1 对比有线和无线LAN环境中的QoS

18.2 WLAN QoS的基本构成

18.2.1 分布式协调功能

18.2.2 CSMA/CA

18.2.3 DCF竞争窗口

18.3 IEEE 802.11e和WMM

18.3.1 DCF技术改造:增强型分布式信道接入

18.4 QoS设计的注意事项

18.4.1 明确上游和下游数据流

18.4.2 QoS映射和标记的注意事项

18.4.3 上游QoS标记战略

18.4.4 下游QoS标记战略

18.5 小结

18.6 扩展阅读

第19章 集中式（Cisco 5500无线LAN控制器） QoS设计

19.1 WLAN中的QoS实施位置

19.2 在WLAN控制器中管理QoS配置文件

19.2.1 QoS标记和条件信任边界

19.2.2 WLAN QoS配置文件

19.2.3 建立访客QoS配置文件

19.3 VoIP应用的QoS设计

19.3.1 调整EDCA配置

19.3.2 无线网络上的呼叫准入控制

19.4 在WLAN上启用WMM QoS策略

19.5 在WLAN上启用WMM QoS策略

19.6 媒体会话侦听（也称为SIP侦听）

19.7 WLC中的应用可视性控制

19.8 为WLAN部署QoS规划

19.8.1 4类模型设计

19.8.2 8类模型设计

19.8.3 12类模型设计

19.9 小结

19.10 扩展阅读

第20章 融合接入（Cisco Catalyst 3850和Cisco 5760无线LAN控制器）QoS设计

20.1 融合接入

20.2 Cisco Catalyst 3850 QoS体系结构

20.3 QoS设计步骤

20.3.1 启用QoS

20.3.2 入向QoS模型

20.3.3 队列模型

20.4 小结

20.5 扩展阅读

第21章 融合接入QoS设计的案例研究

21.1 Tifosi融合接入QoS设计:有线

21.1.1 策略1:有线打印机终端设备的接入边界设计（不信任）

21.1.2 策略2:有线接入终端设备的接入边界设计（信任DSCP）

21.1.3 策略3:Cisco TelePresence终端设备的接入边界设计（条件信任）

21.1.4 策略4:Cisco IP电话和PC的接入边界设计（条件信任、分类和标记）

21.1.5 策略5:接入边界有线队列设计

21.2 Tifosi融合接入QoS设计:无线

21.2.1 策略6:移动无线客户端的接入边界设计（通过动态策略应用分类和标记）

21.2.2 策略7:接入边界无线队列设计

21.2.3 策略8:访客SSID和企业SSID之间的带宽分配（分离带宽的SSID策略）

21.2.4 策略9:CT 5760 WLC上行链路端口

21.3 Cisco身份服务引擎

21.4 小结

21.5 扩展阅读

第5部分 数据中心QoS设计

第22章 数据中心QoS设计的注意事项与建议

22.1 数据中心体系结构

22.1.1 高性能数据中心体系结构

22.1.2 大数据（HPC/HTC/Grid）体系结构

22.1.3 虚拟多服务数据中心体系结构

22.1.4 安全多租户数据中心体系结构

22.1.5 大规模可扩展数据中心体系结构

22.2 数据中心QoS工具

22.2.1 数据中心桥接工具集

22.2.2 数据中心传输控制协议

22.3 NX-OS QoS框架

22.4 数据中心QoS模型

22.4.1 数据中心标记模型

22.4.2 数据中心QoS模型

22.5 数据中心接口QoS角色

22.6 小结

22.7 扩展阅读

第23章 数据中心虚拟接入层（Nexus 1000V）的QoS设计

23.1 Cisco Nexus 1000系统体系结构

23.2 Nexus 1000V配置注意事项

23.3 入向QoS模型

23.3.1 信任模型

23.3.2 分类和标记

23.3.3 服务器限速模型

23.4 出向QoS模型

23.4.1 4类出向队列模型

23.4.2 8类出向队列模型

23.5 小结

23.6 扩展阅读

第24章 数据中心接入层/汇聚层（Nexus 5500/2000）的QoS设计

24.1 Cisco Nexus 5500系统体系结构

24.1.1 体系结构概述

24.1.2 虚拟输出队列

24.1.3 QoS组和系统类别

24.1.4 QoS设计步骤

24.2 入向QoS模型

24.2.1 信任模型

24.2.2 分类和标记模型

24.2.3 应用限速服务器模型

24.2.4 更改入向缓存大小

24.3 出向队列模型

24.3.1 4类模型

24.3.2 8类模型

24.4 更多QoS设计选项

24.4.1 Nexus 5500 L3 QoS配置

24.4.2 Nexus 2000 FEX QoS

24.4.3 使用network-qos策略设置MTU

24.5 小结

24.6 扩展阅读

第25章 数据中心核心层（Nexus 7000）的QoS设计

25.1 Nexus 7000概述

25.2 Nexus 7000 M2模块:体系结构和QoS设计

25.2.1 M2模块的QoS设计步骤

25.2.2 M2模块的队列模型

25.2.3 M2 OTV边界设备QoS设计

25.3 Nexus 7000 F2模块:体系结构和QoS设计

25.3.1 F2模块的QoS设计步骤

25.3.2 F2模块的网络QoS策略设计

25.3.3 F2模块的队列模型

25.3.4 FEX QoS设计

25.4 M2/F2模块的其他QoS设计选项

25.4.1 受信任的服务器模型

25.4.2 不受信任的服务器模型

25.4.3 单应用服务器标记模型

25.4.4 多应用服务器分类和标记模型

25.4.5 服务器限速模型

25.4.6 DSCP变化模型

25.5 CoPP设计

25.6 小结

25.7 扩展阅读

第26章 数据中心QoS设计的案例研究

26.1 Tifosi数据中心虚拟接入层Nexus 1000V QoS设计

26.1.1 策略1:受信任的VM

26.1.2 策略2:单应用VM

26.1.3 策略3:多应用VM

26.1.4 策略4:网络边界队列

26.2 Tifosi数据中心接入/汇聚层Nexus 5500/2000 QoS设计

26.2.1 策略5:受信任的服务器

26.2.2 策略6:单应用服务器

26.2.3 策略7:多应用服务器

26.2.4 策略8:网络边界队列策略

26.3 Tifosi数据中心核心层Nexus 7000 QoS设计

26.3.1 策略9:网络边界队列（F2模块）

26.3.2 策略10:网络边界队列（M2模块）

26.3.3 策略11:园区网与数据中心之间针对信令流量的DSCP变化

26.4 小结

26.5 扩展阅读

第6部分 WAN和分支QoS设计

第27章 WAN和分支QoS设计的注意事项与建议

27.1 WAN和分支的体系结构

27.2 硬件与IOS软件的QoS

27.3 延迟和抖动

27.4 Tx-Ring

27.5 CBWFQ

27.6 LLQ

27.7 WRED

27.8 RSVP

27.9 媒体网络

27.10 AVC

27.11 AutoQoS

27.12 控制层面限速

27.13 链路类型和速率

27.14 WAN和分支QoS模型

27.14.1 入向QoS模型

27.14.2 出向QoS模型

27.14.3 控制层面限速

27.15 WAN和分支接口QoS角色

27.16 小结

27.17 扩展阅读

第28章 WAN 汇聚服务路由器（Cisco ASR 1000）的QoS设计

28.1 Cisco ASR 1000 QoS体系结构

28.2 QoS设计步骤

28.3 ASR 1000内部QoS

28.3.1 基于SPA的PLIM

28.3.2 基于SIP的PLIM

28.4 入向QoS模型

28.5 出向QoS模型

28.5.1 4类模型

28.5.2 8类模型

28.5.3 12类模型

28.6 其他与平台相关的QoS设计选项

28.6.1 RSVP

28.6.2 AutoQoS SRND4

28.6.3 控制层面限速

28.7 小结

28.8 扩展阅读

第29章 分支路由器（Cisco ISR G2）的QoS设计

29.1 Cisco ISR G2 QoS体系结构

29.2 QoS设计步骤

29.3 入向QoS模型

29.3.1 媒体网分类模型

29.3.2 NBAR2分类模型

29.4 出向QoS模型

29.4.1 4类模型

29.4.2 8类模型

29.4.3 12类模型

29.5 其他与平台相关的QoS设计选项

29.5.1 RSVP

29.5.2 AutoQoS SRND4

29.5.3 控制层面限速

29.6 小结

29.7 扩展阅读

第30章 WAN和分支QoS设计的案例研究

30.1 策略1:ASR 1000的内部（PLIM）QoS

30.1.1 策略1a:基于SIP的PLIM QoS

30.1.2 策略1b:基于SPA的PLIM QoS

30.2 策略2:LAN边界QoS策略

30.3 策略3:WAN边界QoS策略

30.4 小结

30.5 扩展阅读

第7部分 MPLS VPN QoS设计

第31章 MPLS VPN QoS设计的注意事项与建议

31.1 MPLS VPN基础设施

31.2 MAN和WAN以太网服务的演变

31.3 亚线路速率以太网设计的启示

31.4 QoS思考模式的转变

31.5 运营商的服务类别模型

31.6 MPLS DiffServ隧道的模式

31.6.1 统一模式

31.6.2 短管道模式

31.6.3 管道模式

31.7 企业到运营商的映射

31.7.1 映射实时语音和视频

31.7.2 映射控制和信令流量

31.7.3 将TCP和UDP分隔开

31.7.4 重新标记和恢复标记

31.8 MPLS VPN的QoS角色

31.9 小结

31.10 扩展阅读

第32章 企业客户边界（Cisco ASR 1000和ISR G2）的QoS设计

32.1 QoS设计步骤

32.2 入站方向的QoS模型

32.3 出站的QoS模型

32.3.1 亚线路速率以太网:分层整形与队列模型

32.3.2 企业-服务供应商的映射模型

32.4 小结

32.5 扩展阅读

第33章 服务供应商边界（Cisco ASR 9000）的QoS设计

33.1 QoS的体系结构

33.2 QoS的设计步骤

33.3 MPLS 差分服务的隧道模型

33.3.1 统一模式的MPLS 差分服务隧道

33.3.2 管道模式的MPLS 差分服务隧道

33.3.3 短管道模式的MPLS 差分服务隧道

33.4 总结

33.5 扩展阅读

第34章 服务提供商核心（Cisco CRS）的QoS设计

34.1 QoS的体系结构

34.2 QoS设计步骤

34.3 运营商核心的CoS QoS模型

34.3.1 4-CoS的SP模型

34.3.2 6-CoS的SP模型

34.3.3 8-CoS的SP模型

34.4 总结

34.5 扩展阅读

第35章 MPLS VPN QoS设计的案例研究

35.1 策略1:CE路由器的入向QoS（Cisco ASR 1000）

35.2 策略2:CE路由器的局域网边界QoS策略

35.3 策略3:CE路由器的VPN边界QoS策略

35.4 策略4:PE路由器的内部QoS（Cisco ASR 9000）

35.5 策略5:PE路由器的客户边界QoS

35.6 策略6:PE路由器的核心边界QoS

35.7 策略7:P路由器的内部QoS（Cisco CRS-3）

35.8 策略8:P路由器的接口QoS

35.9 总结

35.10 扩展阅读

第8部分 IPSec QoS设计

第36章 IPSec VPN QoS的注意事项与建议

36.1 IPSec VPN 拓扑

36.1.1 标准的IPSec VPN

36.1.2 GRE IPSec

36.1.3 远程接入VPN

36.2 IPSec数据包的QoS分类

36.3 IOS预分类特性

36.4 MTU的注意事项

36.4.1 GRE如何解决MTU的问题

36.4.2 IPSec如何解决MTU的问题

36.4.3 运用TCP MSS调整特性

36.5 对VPN上的数据执行压缩

36.5.1 使用WAAS对TCP进行优化

36.5.2 在VPN连接上使用语音编码器

36.5.3 CRTP和IPSec的不兼容性

36.6 防重放的启示

36.7 总结

36.8 扩展阅读

第37章 DMVPN的QoS设计

37.1 DMVPN网络中QoS的作用

37.1.1 DMVPN的构成

37.1.2 如何在DMVPN中实施QoS

37.2 DMVPN QoS 配置

37.2.1 下一跳路由协议

37.2.2 在DMVPN环境中，需要通过不同的方式来实现QoS策略

37.2.3 DMVPN的每隧道QoS特性（Per-TunnelQoSForDMVPN Feature）

37.3 DMVPN QoS 设计实例

37.3.1 DMVPN QoS设计步骤

37.3.2 在中心路由器配置每隧道QoS（Per-Tunnel QoS）

37.3.3 在分支路由器上配置每隧道QoS

37.3.4 验证DMVPN的QoS配置

37.4 分支路由器间的每隧道QoS

37.5 总结

37.6 扩展阅读

第38章 GET VPN的QoS设计

38.1 GET VPN QoS概述

38.1.1 组域的概念

38.1.2 GET VPN的搭建

38.1.3 IP头部保留

38.2 GET VPN配置概述

38.2.1 密钥服务器的配置

38.2.2 GM的配置

38.3 GET VPN的QoS配置

38.3.1 使用4类的模型配置GM路由器

38.3.2 使用8类的模型配置GM路由器

38.3.3 使用12类的模型配置GM路由器

38.3.4 确认QoS策略

38.3.5 何时、如何使用QoS预分类特性

38.4 将GET VPN与DMVPN结合起来的案例

38.5 在部署GET VPN时，需要与服务提供商合作

38.6 小结

38.7 扩展阅读

第39章 家庭办公环境VPN网络中的QoS案例分析

39.1 构建技术解决方案

39.2 QoS的应用需求

39.3 QoS配置

39.3.1 前端路由器的配置

39.3.2 家庭办公环境的路由器（Spoke）配置

39.4 小结

39.5 扩展阅读

端到端QoS网络设计（第2版）

End-to-End QoS Network Design Quality of Service for Rich-Media & Cloud Networks Second Edition

〔美〕Tim Szigeti，CCIE#9794　〔加〕Robert Barton，CCIE#6660　〔美〕Christina Hattingh　〔美〕Kenneth Briley，CCIE#9754　著

YESLAB工作室　译

田玥　审

人民邮电出版社

北京

图书在版编目（CIP）数据

端到端QoS网络设计:第2版/（美）西格提（Szigeti，T.）等著；YESLAB工作室译.--北京:人民邮电出版社，2015.3

ISBN　978-7-115-37700-5

Ⅰ.①端…　Ⅱ.①西…②Y…　Ⅲ.①计算机网络—网络设计　Ⅳ.①TP393.02

中国版本图书馆CIP数据核字（2015）第009417号

版权声明

End-to-End QoS Network Design:Quality of Service for Rich-Media & Cloud Networks (ISBN:1587143690) Copyright © 2014 Pearson Education, Inc.

Authorized translation from the English language edition published by Cisco Press.

All rights reserved.

本书中文简体字版由美国Pearson Education授权人民邮电出版社出版。未经出版者书面许可，对本书任何部分不得以任何方式复制或抄袭。

版权所有，侵权必究。

◆著　[美]Tim Szigeti　[加]Robert Barton　[美]Christina Hattingh　[美]Kenneth Briley

译　YESLAB工作室

审　田玥

责任编辑　傅道坤

责任印制　张佳莹　焦志炜

◆人民邮电出版社出版发行　　北京市丰台区成寿寺路11号

邮编　100164　　电子邮件　315@ptpress.com.cn

网址　http://www.ptpress.com.cn

北京艺辉印刷有限公司印刷

◆开本:800×1000　1/16

印张:55

字数:1083千字　　2015年3月第1版

印数:1-3000册　　2015年3月北京第1次印刷

著作权合同登记号　图字:01-2013-8472号

定价:138.00元

读者服务热线:（010）81055410　印装质量热线:（010）81055316

反盗版热线:（010）81055315

内容提要

本书是Tim与Christina继本书第一版之后的又一重磅之作。这一次，Tim响应新时代网络技术的发展趋势，力邀无线技术专家Kenneth和自己的挚友、数据中心专家Robert加盟本书的创作，补充了本书上一版中数据中心和无线网络领域的空白。

本书从QoS的基本理念与基础理论入手，以QoS在不同环境中的配置与应用方法为纲，搭配各类环境中的案例分析，再辅以在各类环境中部署不同QoS策略的注意事项及建议，由浅入深，由小及大，层层深入地向读者展开了QoS世界的巨幅画卷。

鉴于本书涉及领域甚广，当今又鲜有网络敢言弃用QoS技术，因此本书完全可以充当各个层次、各个领域网络技术从业者的工具书。准备考取高级网络技术认证（如CCIE）的人员则可以将本书作为QoS技术的自学教材；网络初学者和在校生可以参详其中的基本理论与设计原则；网络设计师和售前工程师可以参考其中的设计方案与案例研究；售后技术人员和网络运维人员可以参照这本书中的配置方法与思路。

关于作者

Tim Szigeti，CCIE #9794，是Cisco 公司系统设计部（Systems Design Unit）的高级技术主管，主要负责针对企业移动解决方案设计网络架构。在过去的15年中，他一直专注于QoS技术，并撰写了许多技术论文和设计指南，现已通过Cisco Press 出版两本著作，即End-to-End QoS Network Design（第1 版）和Cisco TelePresence Fundamentals。前者已由人民邮电出版社引进并出版。

Robert Barton，CCIE #6660，现与妻子和两个孩子生活在温哥华。他毕业于不列颠哥伦比亚大学，拥有工程物理学学位，也是一名注册的职业工程师。Rob持有路由交换和安全的双料CCIE认证，也是加拿大的第一位CCDE。Rob在入职Cisco前曾供职于ArrowPoint，是ArrowPoint的数据中心专家，为许多大型的加拿大企业提供技术支持。自ArrowPoint被Cisco收购后，Rob就一直担任公共部门的系统工程师，主要从事无线与安全架构的工作。现在， Rob主要负责研究智能电网技术，包括从事智能电表及智能变电站设计工作。

Christina Hattingh 在Cisco 公司企业网络路由组（前身为服务路由技术组，或称SRTG）担任统一通信（UC）方向的资深技术人员达13年。SRTG的产品主要包括2900、3900、2800、3800系列ISR路由器以及它们的前身，SRTG的产品是第一个通过TDM网关接口、WAN接口、呼叫控制以及QoS功能，在IP网络中统一传输语音、数据、视频流量并提供网络服务的Cisco平台。ISR系列路由器经常应用于小型的远程办公网络，在WAN边缘，对于QoS 服务的需求是最为敏感的。担任这一职务期间，Christina 曾经在Cisco Live 会议（Cisco在线会议）中发表过演讲，对Cisco的销售人员和二级经销商的雇员提供过技术培训（内容是路由器上的UC 技术），也曾经与Cisco Press 合作撰写过多部作品，就UC 网络的部署与设计方案向客户提供过咨询意见（包括QoS 的设计方案），并帮助客户实现了从TDM 到SIP trunk的转换。

Kenneth Briley, Jr.，CCIE #9754，是Cisco 公司网络操作系统技术组（Network Operating Systems Technology Group）的技术主管。在超过10 年的时间里，他一直专注于QoS 的设计和应用、QoS 的特性和功能、使用QoS 技术的新产品营销。在此期间，他在Cisco Live（思科在线）中撰写了多部部署指南和白皮书。最近，他正在从事的工作是将有线与无线网络中的QoS策略进行融合。

关于技术审稿人

John Johnston，CCIE #5232，是Cisco 公司的一名技术营销工程师。他的工作领域是移动安全技术及设计校验。John有超过19年的IP互联网工作经验，其中包括企业网络的设计与实施经验。在加入Cisco之前，John曾为数家世界五百强企业提供过网络设计方面的技术支持服务。他拥有北卡罗来纳大学夏洛特分校的电子工程学士学位。

Roland Saville 是Cisco 公司系统开发部门（Systems Development Unit）的技术主管，主要负责针对部署企业网络的工作设计最佳做法的指导方针。他曾在Cisco历任系统工程师、产品经理、系统咨询工程师、技术营销工程师以及技术主管等职，工作经验逾18年。在此期间，他曾深入研究大量不同的技术领域，包括网络基础设施中语音和视频的融合、网络安全、无线局域网互联、RFID、能量管理、Cisco TelePresence 以及BYOD。此外，他还花费时间用于研究零售市场。在进入Cisco之前，他曾在雪佛兰公司担任过8年的通信工程师。Roland拥有爱达荷州立大学颁发的电器工程学士学位以及圣塔克拉拉大学颁发的工商管理硕士学位。除曾与别人合著过Cisco TelePresence Fundamentals外，他还是IEEE 成员，拥有12 项专利。

献辞

Tim Szigeti:

每逢为一本书撰写献词，我都会陷入一个两难的境地。

一方面，我一直在对周围的亲朋好友解释:要是没有把这本书的第1版献给我的妻子，我一定犯下了一个不可饶恕的错误。而自那以后，我更是一直想要把我的第二本书献给我的儿子，可现在我又有了一个可爱的女儿，我也很希望能把第二本书献给她（正是由于她的不期而至，才让这个版本的问世推迟了数月之久）。

我的问题来了:每本书真的就只能献与某一个人吗？还是说，我可以把一本书的不同版本献给不同的人。何况，我也不想和我妻子去争论“献辞”的确切涵义——英语言文学和哲学可是她的老本行。

所以，我只好在这里玩弄一下权衡术的把戏，在其中寻找一个折衷的方法:我愿将本书的第一版献给Lella，并将本书的第二版献给Lella的2.0版（也就是我们的女儿Isla）。

我可是亲眼见识了女儿是多么珍视我的作品。过去好几个月的时间里，这本书的第一版都垫在她的婴儿床下，这是为了把婴儿床的一边垫高一点，让它在夜晚不会发出恼人的响声。看到她每天早上笑靥如花地从睡梦中醒来，我猜她一定体会到了这本书的重要价值。不仅如此，她还很喜欢用小嘴撕咬这些书，并在上面留下很多口水，直到它变得湿漉漉的方才罢休，这个过程对她似乎是一种享受。这就是她对作者表示尊敬的方式吧？我想。

所以，我愿意把这本书献给我可爱的小女儿。你每天晚上让我消停不了几个小时，连我自己都说不清自己是怎么坚持把这本书写完的。我知道，很可能你永远都不会去阅读这本书，但这又有什么关系呢？我只想让你明白，你的身影不时出现在我的脑海之中，让我几乎无法集中精力来写作这部作品。现在这本书终于交稿了，我也有了更多的时间可以同你玩耍，任由你稚嫩柔弱的手指紧紧地抓住我的衣襟。

Rob Barton:

我愿将这本书献给我的两个孩子Adrian和Matthew。但我并不是希望你们认真阅读这本书，最终成为QoS领域的专家，我甚至不会去主动鼓励你们向网络设计师或者工程师的方向发展，虽然它们都是崇高而神圣的职业。写作本书期间我获得了一些其他的感悟:只有当你们认识到自己要去从事哪一个行当，并下定决心要在那个行业中有所建树时，你们才会成长起来。很多时候，我们并不知道自己的努力能否带来成功，但当你决心去完成一些困难重重、极具挑战并会让你经历磨难的任务时，你就会收获成长。没有付出，就没有收获，这是生活的真谛。我希望这本书能给予你们寻找成长动力的契机，无论是在精神的层面、内心的层面、专业的层面、肉体的层面还是灵魂的层面。这本书是我献给你们的礼物。

Christina Hattingh:

愿将这本书献给Robert Verkroost 和我的父母，感谢你们不懈的支持与鼓励。

Kenneth Briley, Jr.:

这是我的第一本书，我愿意听从Tim的建议，将它献给我美丽的妻子Mirah。Mirah会不时阅读这本书并给与我充分的肯定，我都数不清她曾经花了多少小时来纠正我语法的错误，并在我滔滔不绝地谈论QoS技术有多么有趣时，耐心地聆听。对于我们家庭成员——Lukas、Erik和Max:求你们不要太快长大，还要铭记一点:一切皆有可能。

致谢

Tim Szigeti:

首先我想要感谢第1版的所有读者，正因为你们这本书才能大获成功。很少有图书能在出版10年后依旧保持销售量稳步增长。所以我要特别感谢那些评论过我的图书的读者，每当我在亚马逊上看见五星的评级时，感激和自豪之情便溢于言表，谢谢你们！

感谢我的主管Neil Anderson，这么多年来，你从未轻视QoS 在网络系统和解决方案中的重要作用，并一直确保QoS 问题能够得到妥善的解决。也要感谢Greg Edwards，是你帮我定义并阐释了这些端到端的QoS战略。

感谢Fred Baker 在定义和诠释各种QoS 标准方面，给予我的指导。也要感谢James Polk在IETF中不断挑战极限，定义未来QoS模型的架构。

我要感谢温哥华Cisco 实验室的管理员Mojan Mobasser，感谢你在设备采购和编排方面所做出的贡献。同样我要感谢Dawid Brink 能让我使用他的Nexus box，而且从未产生任何质疑。

同时，我要感谢加拿大Toronto Bell 公司的团队能让我访问他们的ASR 和CRS 实验室，还要感谢在地球另一端（新加坡办公室）的Lim Fung，能够让我访问他的实验室。

我要由衷感谢Tim Stevenson，你在数据中心平台这一领域的超强技术能力，帮助我解决许多我自己无法解决的硬件架构问题。谢谢你，Tim！

此外，我还要感谢Lukas Krattiger 在瑞士进行的研究与测试，是你的贡献保证了我们能够在Nexus 7000 上正确地完成QoS 操作。感谢你敏锐的洞察力、超凡的耐心和辛勤的工作， Lukas！

必须感谢Lucien Avramov 能够将他在数据中心所做的QoS 工作与我们分享。还要感谢目前不知身在何方的Mike Herbert，感谢你在这个领域所做出的开拓性成就。

我还要感谢Cisco产品团队，他们在听取了我们对于这本书的反馈后，升级了QoS的特性集。包括Albert Mitchell 和Catalyst 2K/3K 团队将我们最新的设计方案加入到了新版的AutoQoS 之中。也应感谢Sarath Subrahmanya 和Ramachandra Murthy 对于WLC QoS 增强功能的建议。还要感谢Oz Ben-Rephael 和以色列的团队，感谢他们不断更新NBAR2 的应用特征，其中包括我们自己的Jabber应用。

感谢Cisco 的出版团队。Brett Bartow，感谢你在这个项目上的付出，感谢你让我们对此前的版本进行了彻底的推翻和重建。当我们一次又一次突破我们实现商定的页数，使得最终的成书比预计的页数多了整整一倍，可你始终没有大发雷霆。还要感谢你因我女儿的降生，特许我推迟数月发表这部作品，让我能够暂时将注意力放在家庭成员身上。

感谢Chris Cleveland 让技术审稿的过程变得如此轻松。你的建议这本书变得愈发完美，对此我铭感五内。也要感谢Seth Kerney 为协调副本的审稿工作所做出的努力，还要感谢Vanessa Evans，在创作本书中的各个阶段，你一直为我们提供一切所需。

我想，最应该感激的是我们的技术编辑Roland Saville 和John Johnston。Roland，在我有幸共事过的人中，你无疑是最具才华的人之一，而且你似乎无所不知，真不知道你是怎么把这么多东西装进你的大脑的。它不会爆炸吗？我喜欢将你比作哲学工程师，无论什么设计建议，你都能想象出一种它无法适应的极端情况。这对我们极为重要，因为你只需要置身事外，听听我们的想法，就能得出必须通过大量实验才能达到的结论，这极大地节省了我们泡在实验室中的时间，同时还能确保最终的设计方案完美无瑕。也要谢谢你，JJ！感谢你让我使用你的大规模RTP实验室并一路给予我帮助。你对于细节的关注让我印象深刻。你竟然能在上百页配置中找出那些细微的错误，对此我五体投地。

最后，我要对我的合著者表示感谢。

Ken:感谢你展现出来的博学与灵活。你可以随时参与到一个陌生的工作中，并将你的研究成果完美融入到这项工作之中。能在过去的10年中与你在很多项目中进行合作实属幸事，期待与你再次合作，十分感谢，Ken！

Christina:十分感谢你能在退休后还能为这些项目做出自己的贡献。你的工作要比Jack Kerouac更多，与你合作让我获益良多！感谢你为了这本书，重操QoS的旧业，你的知识和经验让这本书的内容更加坚实可靠。

Rob:过去的20年，我们一直是朋友、同学、室友以及工作伙伴，是彼此婚礼上的“第二伴郎”和图书的合著伙伴。你的勇气和决心是非常振奋人心的。说实话，要不是看到你实现了这一目标，我真不知道自己会不会考取CCIE。我能参与半程马拉松（和全天的马拉松）也是受你的影响。感谢你为这个项目所做的巨大贡献。多少次我们必须停下手里的工作，用大量实验和测试去探索技术世界中的一个又一个主题，这可不是胆小鬼能完成的任务。感谢你能一直坚持到今天，Rob。不过，你对兄弟一直都是这样，这就是你的交友之道。

Rob Barton:

首先，我要感谢Cisco温哥华办公室中的同僚，我用两年的时间把系统工程师分为了两类:热衷于解决QoS理论问题的和喜欢帮助客户排忧解难的，而你们一直对此十分宽容。特别要感谢Cisco 审计团队的同仁Mike MacDonal，他是一个极具耐心的人；感谢我的经理Ralph Wright，他积极支持我的工作并给予了我很多鼓励；感谢我的主管Bill Kastelic，他在工作上赋予了我更高的灵活度，让我得以完成这本书的创作。没有你们的支持，一切皆成空谈。

我还要感谢我实验室的管理员Mojan Mobasser，他在我最需要实验设备时帮我把它搞到了手。测试这些QoS解决方案需要很多的时间，没有你的支持，我就无法搭建和测试这些解决方案。

特别感谢Ian Procyk 和我的合著人Ken Briley，感谢你们帮我测试了很多困难的无线方案。同样，我也要感谢Larry Ross，感谢你花费很多时间用邮件或者电话与我讨论各种无线QoS的解决方案。我还要感谢Kangwarn Chinthammit 帮助我撰写了AVC 部分的概述，感谢Scott Wainer 帮我完成了GET VPN 一章的写作任务。在本书的创作过程中，你们就是我技术灵感的源泉。

我还要感谢Terra-Comm Solutions 的Bruno Wollman，当我们讨论去年我在Cisco Live（思科在线）所做的演讲时，你向我介绍了DMVPN同GETVPN结合起来使用，以解决实际项目VoIP 问题的方法，这对于GET VPN 这一章的内容是极好的补充。

Chris Cleveland 和Brett Bartow，感谢你们一直为这个项目辛勤工作并一直给与我支持。这个项目需要付出的时间与精力，几乎超过了我们所有人的预期，在这部作品中，你们不仅向读者分享了自己对于QoS机制的理解与体会，更让这本书变得更富有创造力，还通过技术文献为本书提供了大量的支持。

最后，我要感谢Tim Szigeti，你不仅是20多年来我最亲密的朋友之一，更是一位优秀的工程师。是的，我说的就是“工程师”——那个你经常拿来恭维我的字眼。我依然清楚地记得，在两年半前，这个项目开始的那一天，在我们跑完半程马拉松之后，我们一起在White Spot 共进早餐。当时我跟你说，你的《端到端QoS网络设计》固然是一部伟大的作品，但这本书已经过时了。而你的回答却让我难以忘怀，当时你说:“那你干吗不和我一起写本新的呢？”于是，那一天，这个项目启动了。虽然这是一个漫长而艰巨的任务，但它同时也是一段难忘的经历。感谢你，Tim！

Kenneth Briley, Jr.:

首先我要感谢Roland Saville，我们一同解决汇聚访问平台上的QoS 问题时，你的指导与洞见使我获益良多。

感谢Stephen Orr:无线技术此前只是浮云，如今却成气候——感谢你那些闪耀着智慧光辉的精彩评论。

还要感谢Tripti Agarwal、Saravanan Radhakrishnan、Anuj Kumar 和Bhavana Kudipudi，没有这个团队的辛勤工作，一切皆为泡影。

前言

“关于QoS我们现在做得还不够吗？”

这是一个我时不时就会被问及的问题，对于这个问题我喜欢这样回答:“什么时候我们在可用性和安全性上的工作可以画上句号，我们在QoS上的工作也就算大功告成了。”

毋庸讳言，虽然QoS技术诞生至今也已经历了一段不短的时间，但它仍是一种基本的网络基础设施技术（同高可用性技术和安全技术一样）。这些基本的技术会始终作为一切网络系统中一个固有的组成部分，出现在不同的平台上、不同的网络位置（PIN）中，最终出现在端到端网络之间。

此外，为了满足新的业务和技术需求，这些基本的网络技术也在不断发展变化。以QoS为例，从大约10年前本书的第一版问世之时，它就从未停下变化和发展的步伐。

在此，我们不妨以一类需要借助QoS技术的应用为例:视频应用。

2004年，大多数的企业网络中只会传输两类视频流量，即流媒体视频（单向数据流，同时通过网络级缓存和应用级缓存，来平衡传输中延迟的波动）和视频会议（双向数据流，在专用的硬件系统之间传输，所占带宽为384kbit/s或768kbit/s）。于是，我们进入了位于北卡罗来纳州三角研究园的大型Cisco 校验实验室（Cisco Validation Lab），总结出了适用于这两类视频流量的最佳设计方案。大功告成了，不是吗？

当然不是！

在接下来的几年里，编解码器和硬件的发展降低了视频制作的成本和门槛，时至今日，几乎每个人都拥有一部能够随时随地拍摄高分辨率视频的智能手机。同样，随着社交网站的涌现，视频分享和发布突然成了每个人的日常行为，人们不论身在何处都可以将自己制作的视频发布出去（而且是在全球范围内！）与他人分享。得益于硬件和无线网络技术的发展，人们也可以随时随地在任何设备上浏览视频。

于是，视频现在成了Internet上所占比例最大的一类网络流量，在未来几年之内，其所占的比例将达到90%。与此同时，视频流量出现了许多新的形势和变化，如网真、IP视频监控、桌面视频和数字标牌等。这些视频中的每一类都有为保证终端用户高质量的体验所必须满足的独特的服务等级需求。因此，我们又回到了QoS的问题上，因为这项技术的作用就是保障用户的体验。

但视频只是众多应用中的一类。

数据中心、云网络和无线网络的发展，无不对QoS网络设计带来了相应的影响。

因此，本书的新版应运而生。

出版本书第2版的另一个初衷是为了反映QoS相关工业标准的演化。Cisco一直提倡无论何时部署QoS，都要遵循业界的标准和建议，因为这样做不但能够简化QoS的设计方案，还可以在管理域上扩展QoS策略，并提高管理域之间的QoS策略效率。因此，新的标准、RFC和提案已经——并将继续——对当今和未来的战略性QoS设计产生重大影响。

出版本书新版本的第三个关键原因是，在本书前一版中进行了详细介绍的每一个网络平台都已经进行了代替或升级。所以，本书在第2版中对（本书写作时的）最新的平台进行了介绍，展示了十多个Cisco产品系列。事实上，几乎每个设计章节都介绍了适用该角色的不同Cisco平台，无论讨论的角色是数据中心虚拟交换机、分支路由器、无线LAN控制器、园区网分布层交换机、WAN汇聚路由器，还是服务提供商的核心路由器或其他。

最后，QoS是一个无所不包而又晦涩艰深的内容，它包含了大量基本的技术概念，以及在某些特定平台上实施这些技术的具体方法。因此，网络管理员能有一本关于此主题的参考读物是很有价值的，就像本书，涵盖了所有相关的工具，展示了多个端到端的战略，并详细介绍了市面上每一个主流的Cisco平台的设计建议。

想求全责备？别这样，关于QoS的工作，才刚刚开始！

本书的目标

本书的主要目标是以全面且紧密的方式展示QoS设计中的各个层面，包括工具的概述、设计方案的战略战术，以及各个平台的具体配置方式。因此，无论是新手还是资深的网络管理人员，都可以把本书当作这个主题的手边参考书，并从中获益。

此外，本书中还在多个平台上，提供了可以充当QoS模板的配置案例。读者可以这样看待这些模板（借用帕累托的二八原则）:80%是企业或服务提供商的通用QoS解决方案，另外20%可以通过自定义和修改，成为最终为顾客量身定制的解决方案。书中解释了设计背后的注意事项和基本原理，管理员充分了解设计背后的基本原理，就能放心地对其进行修改，以满足自己特定的需求和限制条件。

在这本拥有丰富配置案例的书中，我们始终在配置命令中添加了解释说明。通过这种方式，我们可以着重介绍与QoS相关的命令，逐行详细介绍每个配置命令的功能，并阐明它们是怎样组成整体解决方案的。

为了给这些逐行的设计建议提供补充，本书还介绍了相关的验证命令。这些验证命令均展示在相应的设计示例中，并用阴影突出强调了输出信息中需要特别关注的内容。这使得本书的验证示例与软/硬件文档中展示的类似示例相比，更加丰富，也使得网络管理员能够更快地确定自己是否正确地部署了推荐的设计方案。

最后，每一个设计部分的末尾都有一个案例研究章节，它可以将这一部分中介绍的众多战略性原则、战术性建议和某些平台的注意事项联系在一起。这些案例研究章节说明了如何利用通用的抽象设计概念，来满足客户的不同需求。这些案例研究章节代表了实际生产环境中的要求。每一个案例研究的示例都跨越了多个设备，并突出了它们之间的联系。此外，所有的案例研究章节都是该部分中的一个完整的端到端QoS网络设计方案。

谁应该阅读本书

本书面向的主要读者是那些需要部署QoS技术的网络管理员。此外，本书的读者还可包括其他相关的IT专业人士，如系统管理员、音频/视频专家、VoIP专家和操作人员。

此外，读者中也可能包括技术决策的制定者，这些人不仅负责根据目标来起草网络部署方案与实施步骤，也负责评估QoS部署方案的战略及可行性。

其他的读者包括系统工程师、合作伙伴、培训机构的讲师，以及所有因需要考取Cisco认证或需要掌握实际操作技能而渴望提升QoS技术的网络从业者。

阅读本书的门槛很低，本书开篇部分涵盖了从高到中级的QoS技术细节，包括协议、工具和相关标准。此外，对于不熟悉某些特定概念的读者，每章的扩展阅读部分也提供了拥有更多具体信息的参考文献。

因为本书的内容范围从高级技术细节到低级技术细节不等，因此适合的读者技术水平也很广泛，从中级到专家级别的人士均可阅读本书。

本书是如何组织的

本书分为39章，8个部分，还包括2个附录。虽然本书也可以逐页阅读，但这样的组织方式也方便读者找出符合自己感兴趣的章节，以便将本书当作一本参考书来使用。

第1部分，“QoS设计概述”，向读者介绍了QoS技术，展示了这些QoS工具的简史及结构框架。接下来，这一部分对一组QoS工具进行了概述，其中包括分类和标记工具、限速和整型工具、队列和丢弃工具、带宽预留工具以及一些（如媒体网、应用可见性与控制的）高级工具。

第2部分，“QoS设计战略”，脱离了纯技术的讨论，以概括性的视角探讨了业务需求是如何驱动QoS设计方案变革的。这一部分分析了应用服务等级需求以及战略层面的QoS最佳设计方案。这一部分提供了全书中的第一个案例研究章节，说明了定义一个端到端QoS设计战略时，需要考虑的诸多因素。

第3部分，“园区网QoS设计”，开始将战略性QoS模型运用到到战术性的网络位置（PIN）中，这一部分介绍的PIN即为企业园区网。这一部分深入讨论了适用于园区网的设计注意事项及建议，后续章节专门对园区网的接入层、分布层和核心层的设计注意事项进行了讨论。这一部分最后以一个园区网QoS设计方案的案例研究篇章作结。

第4部分，“无线LAN QoS设计”，将战略性的QoS模型应用到了企业的无线LAN环境中。因为与网络的其他部分相比，WiFi是一种独特的媒介，因此本部分也介绍了额外的概念来解释如何通过无线信号实现QoS。这些注意事项包括对增强型分布式协调功能（Enhanced Distributed Coordination Function）以及 IEEE 802.11e/ 无线多媒体QoS 的介绍。接下来， QoS设计章节针对集中式的无线LAN控制器部署模型和新的无线有线融合接入部署模型进行了介绍。这一部分以一个WLAN QoS 的设计案例研究结束。

第5部分，“数据中心QoS设计”，继续对QoS战略进行应用，这次将其应用到了数据中心网络中。由于数据中心汇聚了存储区网络和局域网，其中有些协议要求获得完全无损的服务，这一点传统的QoS工具无法保证。因此，这一部分讨论了数据中心专用的QoS工具，包括可用来保证无损服务的数据中心桥接工具集。接下来，QoS的设计章节分析了数据中心网络的虚拟接入层、接入和汇聚层，以及核心层。该部分以一个数据中心QoS设计的案例研究结束。

第6部分，“WAN和分支QoS设计”，将讨论的范围扩展到了局域网的范畴之外，将战略性QoS原则应用到了广域网环境中。这一部分介绍了WAN汇聚路由器和分支路由器上的QoS 设计方案。该部分以一个WAN QoS 设计的案例研究结束。

第7部分，“MPLS VPN QoS设计”，继续广域网问题的讨论，但将焦点转移到了MPLS VPN网络中的QoS战略，在端到端的设计方案中，分别从企业客户和服务提供商的角度进行了探讨。这一部分介绍了企业客户边界路由器，提供商边界路由器和提供商核心路由器的设计。该部分以一个MPLS VPN QoS 的案例研究结束。

第8 部分，“IPSec QoS设计”，将战略性QoS 原则应用到了IPSec VPN 环境中，这一部分是全书的结尾。在这一部分中，本书对动态多点VPN（Dynamic Multipoint VPN）和组加密传输VPN（Group Encrypted Transport VPN）进行了详细的探讨。

全书共分39章和2个附录，其内容如下。

■ 第1章，“QoS与QoE的介绍及回顾”:本章会介绍服务质量和体验质量的演化简史，基础的QoS概念和标准，以及迫使本书出版第2版的那些革命性的改变。

■ 第2章，“基于IOS的QoS体系结框架和语法结构”:本章概述了如何将QoS工具相互关联，也会介绍Cisco 基于IOS 的MQC（模块化QoS 命令行界面），这是一种在大多数Cisco平台上配置QoS的通用语法结构。

■ 第3章，“分类与标记”:本章会描述许多用于区分数据包的分类技术，分类是提供差分服务的第一步。此外，本章还会讨论多种标记的方式，这些技术可以让数据包不必在各个节点都由设备进行重分类。

■ 第4章，“限速、整形和降级工具”:本章会对多种可用来检测和限制数据流的工具进行讨论，其中包括限速器（用于丢弃过量的流量）、整形器（用于延迟过量的流量）和标记器（用于重标记过量的流量）。

■ 第5章，“拥塞管理和拥塞避免工具”:本章会通过分析队列工具（用于确定哪些包可以在拥塞期间获得优先处理）和早期丢弃工具（用于减少拥塞发生的概率），来介绍处理网络瓶颈的各种选择。

■ 第6章，“带宽预留工具”:本章会介绍带宽预留的概念，以及终端设备/基础设施通过通信来判断何时、如何预留带宽的具体细节。

■ 第7章，“IPv6网络中的QoS”:本章会介绍IPv6的数据包格式、分类和标记选项，以及在IPv6网络或IPv4和IPv6的混合网络中，配置QoS工具的方式。

■ 第8章，“媒体网络”:本章简要概述了媒体网的架构，并会对如何在媒体网环境中配置和监测QoS进行详细介绍。

■ 第9章，“应用可视性控制”:本章会介绍用于对不同应用进行识别、分类和监测的深度数据包监控技术，以及它们在网络中的使用方法。

■ 第10章，“商业和应用的QoS需求”:本章会对影响QoS设计的商业趋势及各种应用类别的QoS需求进行介绍。

■ 第11章，“QoS的设计原则与方法”:本章将此前章节中介绍的QoS工具和商业需求综合运用到QoS战略性模型中，以分析初级、中级和高级的需求。

■ 第12章，“战略性QoS设计的案例研究”:本章是一个系列中的第一个案例研究章节。本章会介绍一个虚拟的公司——Tifosi Softeware（Tifosi 软件），并讨论定义端到端QoS策略时，商业和技术层面的注意事项。

■ 第13章，“园区网QoS设计的注意事项与建议”:本章概述了各种与园区网QoS设计相关的注意事项与建议，包括信任边界、基于端口与基于VLAN的设计方法，以及设计EtherChannel QoS 时应予考虑的因素。

■ 第14章，“园区网接入层（Cisco Catalyst 3750）的QoS设计”:本章是第一个特定平台的设计章节，这一章会从配置层面详细介绍通过Cisco Catalyst 3750 系列交换机来充当园区网接入层边界的最佳QoS设计方案。

■ 第15章，“园区网分布层（Cisco Catalyst 4500）QoS设计”:本章会详细介绍通过Cisco Catalyst 4500 系列交换机来充当园区网分布层时的配置建议，同时也会介绍将该交换机配置为园区网访问边界交换机的具体方法。

■ 第16章，“园区网核心层（Cisco Catalyst 6500）QoS设计”:本章会详细介绍通过Cisco Catalyst 6500 系列交换机来充当园区网核心层时的配置建议，同时也会介绍将该交换机配置为园区网访问边界交换机和分布层交换机的具体方法。

■ 第17章，“园区网QoS设计的案例研究”:这个案例研究的章节将会描述Tifosi Software 是如何将他们的战略性QoS 设计模型应用到一个由Cisco Catalyst 3750、4500和6500系列交换机组成的园区网络的。

■ 第18章，“无线LAN QoS设计的注意事项与建议”:本章概述了多种与无线LAN QoS设计相关的注意事项与建议，同时也会介绍如增强型分布式协调功能和无线多媒体QoS 等WLAN QoS 工具。

■ 第19章，“集中式（Cisco 5500 无线LAN 控制器）QoS 设计”:本章会通过Cisco 5500 WLC来详细介绍通过GUI和CLI部署集中式无线LAN控制器（WLC）时的建议。

■ 第20章，“融合接入（Cisco Catalyst 3850和Cisco 5760无线LAN控制器）QoS设计”:本章会详细介绍将Cisco Catalyst 3850 系列交换机和 Cisco 5760 WLC 部署到融合接入WLAN部署模型中时的配置建议。

■ 第21章，“融合接入QoS设计的案例研究”:这个案例研究的章节将会描述Tifosi Software 如何将他们的战略性QoS 设计模型应用到一个由Cisco Catalyst 3850 系列交换机和Cisco 5760 WLC 组成的无线与有线相融合的LAN 中。

■ 第22章，“数据中心QoS设计的注意事项与建议”:概述了与数据中心QoS设计相关的各种注意事项与建议，并会介绍数据中心桥接工具集。

■ 第23章，“数据中心虚拟接入层（Nexus 1000V）的QoS设计”:本章会详细介绍通过Cisco Nexus 1000V 系列虚拟交换机来充当数据中心接入层交换机时的配置建议。

■ 第24章，“数据中心接入/汇聚层（Nexus 5500/2000）的QoS设计”:本章会详细介绍通过Cisco Nexus 5500 系列交换机（有可能外接Cisco Nexus 2000 系列矩阵扩展模块）来充当数据中心接入/汇聚交换机时的配置建议。

■ 第25章，“数据中心核心层（Nexus 7000）的QoS 设计”:本章会详细介绍通过Cisco Nexus 7000 系列交换机来充当数据中心核心交换机时的配置建议，也会深入介绍M系列模块和F系列模块上的QoS设计方案。

■ 第26章，“数据中心QoS设计的案例研究”:这个案例研究的章节将会描述Tifosi Software 是如何将他们的战略性QoS 模型应用到一个由Cisco Nexus 1000V、5000/2000和7000系列交换机组成的数据中心网络的。

■ 第27章，“WAN和分支QoS设计的注意事项与建议”:概述了多种与WAN QoS 设计相关的注意事项与建议，包括硬件与软件方面的注意事项、延迟和抖动的目标以及带宽预留技术的几种选择。

■ 第28章，“WAN汇聚服务路由器（Cisco ASR 1000）的QoS设计”:本章会详细介绍通过Cisco ASR 1000 系列路由器来充当WAN 汇聚路由器时的配置建议，其中涉及的WAN媒介包括租用线缆、ATM和Packet-Over-SONET。

■ 第29章，“分支路由器（Cisco ISR G2）的QoS设计”:本章会详细通过Cisco ISR G2系列路由器来充当分支路由器时的配置建议，以及媒体网和AVC的设计方案。

■ 第30章，“WAN和分支QoS设计的案例研究”:这个案例研究的章节将会描述Tifosi Software 是如何将他们的战略性QoS 设计模型应用到一个由Cisco ASR 1000 和ISR G2 系列路由器组成的广域网中的。

■ 第31章，“MPLS VPN QoS设计的注意事项与建议”:本章从企业和服务提供商的角度概述了多种与MPLS VPN QoS 设计相关的注意事项与建议，包括企业到提供商的映射模型，以及MPLS的差分服务隧道模型。此外，本章设计方案的特点是以电信级以太网作为WAN媒介。

■ 第32章，“企业客户边界（Cisco ASR 1000 和ISR G2）的QoS 设计”:本章会详细介绍通过Cisco ASR 1000 或ISR G2 系列路由器连接企业客户边界路由器与MPLS VPN服务提供商时，在配置方面的建议。

■ 第33章，“服务提供商边界（Cisco ASR 9000）的QoS设计”:本章会详细介绍通过Cisco ASR 9000 系列路由器来充当服务提供商边界路由器时的配置建议。

■ 第34章，“服务提供商核心（Cisco CRS）的QoS 设计”:本章会详细介绍通过Cisco CRS-3 系列路由器来充当服务提供商核心路由器时的配置建议。

■ 第35章，“MPLS VPN QoS 设计的案例研究”:这个案例研究章节描述了Tifosi Software是如何调整战略性8类企业QoS模型，并使其融入服务提供商的6类服务模型的。本章会涉及Cisco ISR G2、ASR 1000、ASR 9000 和CRS-3 系列路由器。

■ 第36章，“IPSec VPN QoS的注意事项与建议”:本章概述了多个与IPSec VPN QoS设计相关的注意事项与建议，包括加密包的分类、MTU注意事项以及反重放技术。

■ 第37章，“DMVPN 的QoS设计”:本章会详细介绍通过Cisco ASR 1000 和ISR G2系列路由器来分别充当DMVPN中心路由器和分支路由器时的配置建议。

■ 第38章，“GET VPN的QoS设计”:本章会详细介绍通过Cisco ISR G2 路由器来充当GET VPN 路由器时的配置建议。

■ 第39章，“家用办公环境VPN网络中的QoS案例分析”:这个案例研究章节描述了Tifosi Software 是如何调整DMVPN 上的战略性QoS 模型，使其能够为在家办公的员工提供远程办公服务的。本章会以Cisco ASR 1002 系列路由器充当前端设备，并将ISR 881 系列路由器连接在家中以太网的宽带调制解调器身后。

■ 附录A，“媒体网的AutoQoS”:这个在线附录采用了与书中相同的QoS设计方案，概述了最新AutoQoS特性的发展变化。这个附录还通过首批支持这一特性的平台展示了它具体的语法结构，这些平台包括Cisco Catalyst 3750 和4500 系列交换机。

■ 附录B，“控制层限速”:这个在线附录概述了控制层限速特性，该特性将QoS（限速）功能应用到虚拟接口（的控制层）上，以增强网络基础设施对抗拒绝服务或蠕虫攻击的能力。本附录还展示了这一特性的最佳方案建议及配置方法。

第1部分 QoS设计概述

第1章 QoS与QoE的介绍及回顾

本章既会对多媒体及云网络的演化史进行简要的介绍，也会讨论服务质量（QoS）与经验质量（QoE）这两个概念的大背景。同时，QoS/QoE的基本概念和它们的标准也会在这一章中进行解读。另外，为了展现当代网络技术的发展变化，本书第2版中新增了许多内容，这些内容都将在第1章中有所体现。本章的主要内容包括:

■ 流量类型与类的演化；

■ QoS与QoE；

■ 电路交换网路技术与数据包交换网络技术；

■ 集成服务（IntServ）与差分服务（DiffServ）。

QoS是一种基本的网络架构技术，它与高可用性（High-Availability）技术及安全（Security）技术属于同一类型。和这种类型的其他技术一样，QoS的基本理论也没有发生过什么太大的变化，但很多具体的QoS技术却在过去几年得到了不断的完善和补充，可以使用这些技术的平台也在不断扩展。另外，近些年来，网络与用户的需求、应用的类型与容量都已经产生了翻天覆地的变化，而这种变革仅仅是个开始。

不过，真正的变化（同时也是促成作者创作本书第二版的成因）在于QoS网络设计方面的几大因素正在快速演变，这些因素如下所示。

■ 各类网络流量在不断融合，网络的特征也日趋变得复杂。随着移动设备的更新换代、无线访问的日渐普及、业务应用和客户应用的升级改造，这种趋势会变得越来越明显。而这一切，都给网络流量的传输和管理提出了更高的要求。

■ 视频应用呈爆炸式增长。与语音流量相比，视频流量占用的带宽更多，也更不稳定。此外，视频流量往往是由许多不同类型的流量组成的（如被动视频流、互动式视频、仿真视频会议流等），其中每种流量需要使用的QoS网络设计技术又各不相同。在2010年，视频流量总量已经超越了点到点的网络流量。根据相关预测，到2016年时，互联网中的视频流量将会占据全部互联网用户流量的86%。

■ 随着早期的技术（如帧中继、ATM）日渐被IP的访问方式所取代，网络核心层与接入层的带宽正在疾速发生变化。虽然带宽仍有限制，拥塞点也仍然存在，但它们在网络中表现方式却在不断的变化。

■ 网络中各个位置（PIN）的平台不断升级，而新兴平台上大都集成了更加完善也更加高端的QoS工具与特性集。因此，QoS技术的设计与实施方式也在持续的变化当中。

■ 目前，网络中传输的流量不断变化，不同策略的工作方式也日新月异，如何（在使用不同的设备或不同网络接入技术的场合中）将所有这些元素集成到当代网络中，优化用户的体验，是整个行业都要面临的挑战。这些都会让通信网络中的标准（IETF RFC）和设计指导方针不断变化。

■ 随着越来越多的用户和企业都开始使用无线设备，更多的用户都希望无论自己是否能够在所处位置连接到网络设备，自己都能与这些设备建立通信。在这样的背景下，无线网络正在以极快的速度普及，它的覆盖范围也在不断扩大。

■ QoS被越来越多地用来实现安全策略，而不只是用来作为一项流量管理工具。QoS工具可以通过检测和分析流量的模式与特征，来优化/丢弃流量。同样，这些工具也可以提供相关流量在安全方面的特征。

所有上述因素都说明了同样一个道理:随着QoS的概念、工具和技术的日渐成熟，在部署网络时使用的网络设计方案和网络应用工具也会不断快速革新。

1.1 历史与演变

从第一条连接不同位置的电报线缆设立至今，电子通信网络的历史已经延续了超过150年的时间。在这一个多世纪的时间里，实现通信网络的技术已经多次发生了重大的变化。在一波又一波高新技术的潮流下，整体的网络架构都业已经历了数次的更替。

1.1.1 曾经

一个世纪以前，公共电话交换网络（PSTN）开始扩建为全球范围的电路交换网络。该网络由固定带宽和专用电路构成，非常适合承载实时流量，比如语音。

大约50年后，军方和教育界的网络专家们引入了分组交换网络来解决在电路交换网络中十分常见的单点故障问题。分组交换将信息流切分成小块的数据，这样的数据块就能够沿着独立的路径，通过寻址和路由被转发到相同的目的地了。

由于分组交换网络能够实现故障的快速恢复，因此这种网络推动了无连接通信协议的使用，而这类协议可以处理那些没有按照发送顺序到达的数据包。但是，对很多应用而言，这种协议过于复杂，而且仅凭这类协议也无法解决所有的问题。于是，面向连接的协议应运而生，如X.25和系统网络体系结构（SNA），以及之后的帧中继和异步传输模式（ATM）。这类协议可以在下层无连接的数据包交换网络基础上，通过定义一条逻辑电路（永久虚电路或者交换虚电路， PVC或SVC），来处理两个设备或端点之间的通信会话。

理论上，实时通信（如语音和视频）可以在一切底层网络互联技术的基础上构建出这样的“虚电路”；但是在当时，通过数据包交换网络技术在虚电路上传输实时流量并不现实，因为那时的网络处理能力和内存容量都不足以传输应用的流量。这种传输方式直到20世纪90年代中叶才得以实现。

不过，通过数据包交换网络承载实时流量的做法很快又出现了一些其他方面的问题。由于缓冲、溢出或其他网络事件导致的数据包延迟，让终端用户的实时会话时断时续，用户体验不佳。语音通话会出现中断，电报和调制解调器呼叫会被挂断，视频数据帧会在播放时卡壳。一些定义在IOS模型第7层的智能协议可以解决上述问题，因为这类协议拥有错误校验和修正的机制（如超时和重传）。这些协议虽然足以满足那些非实时数据应用的需求，但却往往难以满足实时流量所需。

无论电路交换网络（如PSTN），还是数据包交换网络（如X.25、SNA以及后来的IP协议），都试图让实时流量和非实时流量在网络中共存。最终，灵活、高效、运用广泛的数据包网络战胜了死板而又浪费带宽的电路网络。当前，即使传统的PSTN网络，也已广泛采用了数据包交换的骨干技术。

1.1.2 现在

为了能够在数据包交换IP网络中无延迟地发送实施流量，需要创建一个电路的逻辑环境，流量类的概念由此诞生。通过流量类，设备就可以对属于不同类别的流量进行区别处理了。在早期，SNA网络在APPN（高级对等网络）架构中引入了服务类别（CoS）的概念，尽管APPN CoS使用的方法与当前的QoS很不相同，但这种技术却是网络设备针对网络流量的类型，对流量进行区分处理这种处理方式的始祖。

有很多基本的特征可以定义一种流量，指出网络正在处理的流量属于某种流量类型。这些特征中最重要的几项如下所示。

■ 延迟（亦称时延）:这是指数据包从发送方发出，直至其到达接收方，所经历的时间之和。

■ 抖动（亦称延迟变量）:这是指多个数据包之间，端到端延迟的差异或变化。

■ 丢包率:用成功收发的数据包数，除以发送的数据包总数，所得到的百分比。

或多或少，每一类流量都会对上述某几项特征有些敏感。如果网络可以合理利用处理、缓存、带宽和内存资源，将各类流量比较敏感的特征降至最低，那么所有类型的流量就可以通过同一个网络进行传输，同时也可以大大提升终端用户对于各个会话的体验。

1.1.3 QoS的演变

在21世纪的头几年，IP网络中占主导地位的流量一度为语言流量和数据流量。其中，语音流量属于实时流量，这类流量往往占据固定带宽，无论是其所占带宽，还是流量的到达时间都是可以预测的。数据流量则属于非实时流量，其所占带宽难以预测（经常会出现突发流量），数据包的到达时间变化也很大。

从那个年代开始，各类视频流量对于业务通信和业务操作的重要性就已开始日渐增加。视频流量由多个子类型组成，其中包括被动视频流、互动式视频、仿真视频会议流等。视频流量有可能是实时流量（但有时也是非实时流量），它对于带宽的需求并不是固定的，因为视频流量是由很多不同类型的数据包组成的，所以从终端用户体验（即会话）的角度来看，各类数据包在延迟和丢包的宽容度方面各有不同。图1-1描述了这几类流量的大体特征。

在过去几年间，无线的访问方式也变得越来越火。当前，可以进行无线漫游，并注册到各个公有和私有无线网络的设备可谓不胜枚举。802.11 WiFi 网络拥有可变的带宽和吞吐量，这些参数皆因终端设备（AP）的位置和性能而定，这种网络是依靠一种与经典802.3以太网截然不同的MAC（媒体访问控制）层架构来实现的。由于这种访问方式与固定带宽有线网络的访问方式大异其趣，因此无线访问也为QoS技术带来了一系列全新的挑战。

图1-1 几种主要流量的大体特征

最初，人们部署QoS特性的目的只是为终端用户提供不同级别的服务，在那之后不久，网络管理人员就开始通过实施QoS特性来实现一些安全方面与业务方面的需求。比如，企业往往希望自己内部的培训视频在网络中传输的优先级高于员工自己播放的互联网视频——即使这两类视频是同一种类型的视频流量（广播视频或组播视频），而且使用的也是同一种技术。

1.2 QoS基础及概念

QoS的基本理念是为终端用户提供最理想的会话体验（无论会话的类型是什么），为此， QoS需要协调网络资源之间的竞争关系。数据包各不相同，因此也不应按照同样的方式来处理每一个数据包。

QoS 特性可以在网络中实现一种可控不平等（managed unfairness）的处理方式，也就是让有些会话的优先级高于其他会话，让对延迟敏感的会话在队列中排在那些对延迟不那么敏感的会话（的数据包）之前；当队列中的数据包溢出时，那些可以容忍一定程度丢包的会话，以及对于业务影响不大的会话，它们的数据包会被丢弃。为了给那些对于业务影响极大，丢包又会严重破坏用户体验的会话腾出空间，其他的会话必须由网络中实施的QoS策略进行管理（所谓管理，就是指在出现竞争的情况下，这些会话的流量会被有选择地搁置或丢弃）。

1.2.1 用户期望:QoS、QoE和QoX

为不同数据包执行不同级别的处理，这是QoS最初也最基本的理念，同时QoS也从技术的角度描述了网络的性能，并对延迟、抖动和丢包进行了量化。随着网络管理员越来越关注终端用户对网络性能的感受，而不仅仅像过去那样仅仅着眼于网络的技术参数，体验质量（Quality of Experience，QoE）的概念便应运而生。QoE 是非常主观的，无法进行量化，但却代表了用户对于这个网络的印象或评价，因此仍然应该是网络管理员致力于提升的重要目标之一。部署QoS特性与技术的目的是为了提升用户的QoE。QoX是一个更加宽泛的概念，它包含了与质量有关的一切术语（如服务质量、体验质量等）。

用户的期望无非是“网络应用能够正常工作”而已，他们并不关心网络中使用的是哪种类型的设备，或者自己是通过什么方式访问网络的。要想建立一个能够达到用户期待值的网络绝非易事，更没有惯例可循，只要有新的应用或者设备添加到网络中，就会影响可用带宽和流量的组成。

关于QoE的概念，有一种不成文的理解方式，那就是必须在网络中（为用户A到用户B的会话）端到端地实施和管理QoS。因为QoE指的是用户的体验，与中间网络的数量、网络的类型或网络的所有者全都没有关系。所以，只在网络中的某一个部分实施QoS几乎毫无意义，因通信路径上的任何一个网段出现故障所导致的不良用户体验，就直接等于用户的QoE。QoS就是短板效应原理的一个经典范例。

1.2.2 QoS模型:集成服务和差分服务

人们第一次尝试对QoS进行标准化始于20世纪90年代中期，彼时，IETF发布了一些有关集成服务（IntServ）的RFC（1633、2211和2212）。这些RFC的重点在于一种称为RSVP（资源预留协议）的信令协议。RSVP会通知从发送方到接收方沿途（逻辑线路）的所有节点，某个会话的带宽和延迟需求。最初，RSVP要求所有节点都服从自己提出的预留需求，但对于跨越互联网的会话而言，这种做法极不实用，因为互联网是一个各厂商各年代服务器、交换机、路由器并存的环境。RSVP也要求每个节点都以流为单位提出预留需求。

为解决上述问题，很快出现了另一种类型的标准——差分服务（DiffServ）模型，这是将QoS 标准化的第二次尝试（见RFC 2474、2597、2598、3246、4594）。DiffServ 模型描述了各个节点的不同行为。根据设备厂商的不同，这些节点可以使用任意特性（无论是厂商私有特性还是公有特性）。对于关键类型的流量，其数据包会被打上某种标记（如IP优先级[IPP]、差分服务代码点[DSCP]等），并定义不同的逐跳行为（PHB）。

在IntServ模型和DiffServ模型演化的过程中，这两类模型均不乏支持者，它们也都曾在不同时期占据过优势。针对这两种模型何者更优的辩论至今仍未偃旗息鼓（因为这两种模型都无法彻底解决相关问题），但在当今网络架构中所实施的QoS技术以DiffServ模型为主，偶尔也会使用一些IntServ特性。不过，在当今网络中，可变带宽的访问链路（如802.11无线网络）不断增加，对于延迟和抖动敏感的流量（如视频）迅速增长。对于上述流量，IntServ模型拥有不可取代的优势，这使得RSVP在当今网络中死灰复燃。

尽管IntServ和DiffServ模型在概念上相互矛盾，但是在实际使用中却常常可以取互补之效。因此，在实施QoS时，这两类模型常常会一起使用。只有IntServ可以在动态网络中为不同的流执行准入控制，因此IntServ非常适用于带宽资源非常宝贵的网络。DiffServ则在灵活性和可扩展性方面远胜IntServ，因此DiffServ可以部署在网络的每一个角落中，以确保每个节点都会遵照PHB来执行转发行为。

1.2.3 QoS基础概念和工具集

很多作品都曾对QoS的概念、技术和功能进行过介绍。因此，本书的目的并不是进一步深入讲解这些QoS工具的工作方式，而是展示这些工具之间如何相互作用，以及怎样将它们联合起来使用，来达到优化QoS设计方案的目标。

总地来说，QoS工具分为以下几类。

■ 分类和标记工具:设备会对会话或数据流进行分析，以判断这个会话属于哪种类型的流量，并以此决定应该对这个流中的数据包执行什么样的策略。一旦判断出了数据包的类型，设备就会对这些数据包进行标记，因此只有有限的几台设备会对数据流执行这样的分析，执行分析的设备往往位于网络边缘，处于数据包的入站方向。数据包要到达目的节点可能需要穿越多个不同的网络，因此在进入一个新网络的交接节点对数据包进行重分类和重标记，是非常常见的。

■ 限速、整形和降级工具:这类工作的作用是将某一特定比例（既可以是绝对比例，也可以是相对比例）的网络资源分配给某一特定类型的流量。当流量超过了可用网络资源的限制，有一部分流量就会有选择地被丢弃、推迟发送或者重新进行标记，以免出现拥塞。会话会受到监测，以确保它们占用的资源不会超过分配给它们的资源，如果它们占用的资源超过了这个限度，设备就会通过丢弃（限制）、推迟发送（整形）、或重新打标（降级）的方式，确保流量不会占用过量的资源。

■ 拥塞管理和调度机制工具:当流量超过了可用的网络资源时，它就会被置入队列中等待可用资源的处理。流量类型对于那些延迟敏感的流量，可以尽可能将流量保留下来，直到拥有了“有保障的”资源，可以无延迟地传输流量再对其进行传输。

■ 链路相关工具:有些类型的链路需要使用一些特殊的处理方式和工具，如分片和交错技术。有些链路希望确保流量不会超过协议中规定的带宽（低于物理速率），如果有突发流量超过了这个限制，设备就会对这个流量进行整形（或降速），以确保以速率不高于协议中的带宽。

图1-2显示了QoS工具集，以及在这些工具处理数据流时，它们的操作顺序。

图1-2 QoS工具集

1.2.4 数据包头

IPv4和IPv6都在数据包头部中为标记预留了一些字段。这些字段的作用是承载QoS分类工具分配给该数据包的标记，以确保网络中其他设备可以赋予这个数据包相应的优先级与丢包率。

图1-3所示为IPv4和IPv6的数据包头部结构。

IPv4数据包中包含了8位长度的服务类型（ToS）字段，而IPv6头部则携带了一个8位长度的流量类型（Traffic Class）字段。这两种字段的头3 位都是IPP 位，因此一共有8 种服务类型。这头3位与接下来的3位，合称为DSCP位。这些6位可以提供一共64种可能的服务类型。

除了3层有数据包标记字段之外，2层数据帧也存在标记字段，其中包括以太网802.1p CoS 位、MAC 桥接802.1D 用户优先级位、MPLS EXP（多协议标签交换值）、VLAN（虚拟局域网）标志位、FR DE（数据帧丢弃合格位）、ATM CLP（异步传输模式信元丢弃优先级）值。这些字段都会在第3章中进行介绍。

图1-3 IPv4与IPv6数据包头部

1.2.5 简化QoS

在20世纪90年代后期，Cisco倾力开发了一套广泛适用的QoS工具与特性集。这个QoS机制和可选项的工具集拥有十分丰富的特性，但部署起来也很复杂。于是，到了21世纪早期，一系列有关QoS简化和自动配置的项目开始启动，其内容包括:

■ 创建了一个模块化的QoS命令行界面（CLI）；

■ 建立了一个QoS基线，以描述不同特性的工作原理和默认行为，这些内容此后被记录进了很多个RFC 当中（包括RFC 2474、2597、2598、3246）；

■ 通过MQC、QoS基线和RFC标准，确保在不同平台上实施QoS特性时，这些特性的功能能够保持一致；

■ 自动QoS（AutoQoS），这是一种智能操作方式，用户只需要输入一两条简单的命令，就可以在某个接口上将所有相关QoS特性都设置为某个应用的推荐QoS参数。

■ 通过分层队列框架（Hierarchical Queuing Framework，HQF），将分布式QoS 代码和特性都应用到非分布式的平台上。

1.3 标准化与一致性

在20世纪90年代末，人们刚刚开始使用QoS特性时，不同的QoS特性在配置和操作方面拥有极大的差异。在早期，Cisco为了提升QoS特性一致性的早期做法是，开发了一系列的基线。

随着时间的推移，IETF制订了大量的RFC，这些RFC在很大程度上让不同厂商的设备在QoS特性的工作方式上保持了一致。而这些RFC的主要贡献在于，它们描述了各类流量的特征，以及对不同类别流量进行分类识别和处理的方式:也即RFC为各类流量指定的行为。

一切都在发展，目前，各类主要流量都是通过RFC 4594 进行分类识别的，包括图1-4 第一列所示的流量。

图1-4 各类流量的RFC推荐做法

不过，QoS特性的实施与配置方法仍然是由厂商指定的。Cisco平台在提高操作一致性方面已经迈出了重要的一步，因为Cisco创建了一个QoS基准。此外，Cisco也在尽量让QoS特性在不同产线和软件平台上的配置方法能够保持一致。

由于RFC 4594 中定义的12 种流量类型在实际的网络实施环境中显得分类过细，因此这个12类流量的模型也可以简化为8类模型或4类模型，如图1-5所示。

最近的相关协议栈是RFC 5865，该RFC率先使用DiffServ标记来指定设备的操作方式（在此之前，这属于IntServ的功能）。这条标准让此前（相互独立的）IntServ模型和DiffServ模型之间的边界变得模糊。虽然RFC的实施让QoS的部署和配置变得更加复杂，但由于实时流量的需求越来越大，因此AC（准入控制）成为了一大利好，这是因为对于实时流量而言，与其对其进行延迟发送/丢弃，不如直接拒绝这类流量的访问。

图1-5 4类流量、8类流量和12类流量的模型

1.4 小结

本章介绍了服务质量的基本概念，并解释了为什么QoS目前仍然是一项基本的、重要的、不断进步的网络技术。新的设备、应用与技术仍在不断发生变化。鉴于提高终端用户的QoE是网关管理员的基本职责，因此新技术的出现都在考验着管理员部署QoS的能力。

本章中介绍的QoS演化史为读者了解其演变至今的过程，提供了相关的背景知识。此外，本章也对QoS的概念、工具、基本模型以及行业标准进行了一番简短的介绍。

1.5 扩展阅读

1.5.1 通用内容

Cisco.com QoS page（Cisco.com QoS页面）:http://www.cisco.com/go/qos

Enterprise QoS Solution Reference Network Design Guide 3.0（企业QoS 解决方案参考网络设计指南3.0）:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/QoS-SRNDBook.html

Enterprise Medianet Quality of Service Design 4.0（企业媒体网服务质量设计4.0）:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/ QoS_SRND_40/QoSIntro_40.html

1.5.2 IntServ（集成服务）

Cisco IntServ white papers（Cisco集成服务白皮书）:http://www.cisco.com/en/US/products/ps6611/prod_white_papers_list.html

IETF工作组制定了一系列的RFC对集成服务（IntServ）进行描述，读者可以在IETF官方网站查询这些RFC文档:http://www.ietf.org。

RFC 1633:Integrated Services in the Internet Architecture:An Overview

RFC 2205:Resource Reservation Protocol (RSVP) Version 1 Functional Specification

RFC 2210:The Use of RSVP with IETF Integrated Services

RFC 2211:Specification of the Controlled-Load Network Element Service

RFC 2212:Specification of Guaranteed Quality of Service

RFC 2215:General Characterization Parameters for Integrated Service Network Elements

1.5.3 DiffServ（差分服务）

DiffServ—The Scalable End-to-End QoS Model (Cisco.com white paper)（差分服务——可扩展的端到端QoS模型（Cisco.com白皮书））:http://tinyurl.com/cmcogtc

IETF工作组制定了一系列的RFC对差分服务（DiffServ）进行描述，读者可以在IETF官方网站查询这些RFC文档:http://www.ietf.org。

RFC 2474:Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers

RFC 2475:An Architecture for Differentiated Services

RFC 2597:Assured Forwarding PHB Group

RFC 2598:An Expedited Forwarding PHB

RFC 2697:A Single Rate Three Color Marker

RFC 2698:A Two Rate Three Color Marker

RFC 3168:Explicit Congestion Notification (ECN) to IP

RFC 3246:An Expedited Forwarding PHB (replacing RFC 2598)

RFC 4594:Configuration Guidelines for DiffServ Service Classes

RFC 5865:A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic

第2章 基于IOS的QoS体系框架和语法结构

本章包含了如下主题:

■ 部署QoS的原则；

■ QoS特性的体系结构，以及基于IOS的Cisco路由器与交换机的功能；

■ 在基于IOS的Cisco路由器与交换机上，配置QoS特性的命令行语言与结构。

本书将从第3章到第7章开始，对这些特性本身、这些特性的工作方式，以及它们的配置命令进行深入的介绍。至于这些特性在不使用IOS系统的Cisco产品（特别是无线产品）上，如何运行和配置，将在本书的第18章、19章和20章中进行讲述。

2.1 部署QoS的原则

在研究各个QoS特性的具体内容及配置方法之前，工程师首先应当对在这个网络中部署QoS的业务目标及组织目标进行一番深入的了解。要想成功地部署QoS解决方案，最佳做法一般包括以下几个步骤。

1.清晰地定义出部署QoS 的业务/ 组织目标:这项任务包括对网络中使用语音/ 视频流量的实时服务进行规划；为发送关键业务数据的应用提供传输保障；对穿越业务网络的“计划外流量”实施管控。此外，在部署网络和QoS方案之前，应该寻求执行部门的通力支持（否则，行政分歧有就可能影响网络实施工作的开展）。

2.根据这些业务目标，判断出需要使用多少种类型的应用才能满足相关的业务需求。然后，定义一个端到端的策略，指定如何对穿越网络的不同类型流量进行区分和处理。

3.分析各类应用提供服务的需求，以便使用合理的QoS 工具来分别满足它们的需求。

4.根据不同平台，分别制定不同的QoS 策略来满足相关需求，这里需要考虑到网络中不同区域的特殊需求。

5.在可控环境下（比如实验室环境中）测试QoS 的设计成果，以便了解这些QoS 策略是否能够满足目标应用的需求。

6.开始部署QoS 策略，在部署过程中进行严密的监测，并对效果进行评估。

7.在非工作时间内，将经过了测试和效果评估的QoS 策略部署到真实的生产网络当中。

8.监测服务的效果，确保QoS 策略达到了预期的效果。

成功的QoS部署方案不会始于技术层面，而往往始于企业层面，即判断企业部署QoS的需求。然后定义出满足这些需求需要使用多少种类型的流量。接下来的一步才需要通过技术的方式进行处理，即定义一种端到端的QoS战略来区分不同的应用类型，然后指定如何用不同的方式对它们进行处理。在这一步之后，需要对各类流量的服务需求进行分析，以便为不同的流量选择不同的QoS工具和策略。

2.2 QoS体系框架

本书曾在图1-2中介绍过下面几项主要的QoS功能。

■ 分类:判断各个数据包分别属于哪种类型的流量。

■ 标记:在数据包头部写入一个值，以便设备在分类这个数据包时，识别出数据包的流量类型。

■ 限速（丢弃与降级）:判断何时丢弃数据包，以及在哪里丢弃数据包；或在流量超过可用资源的承载能力时，对数据包进行重新标记。

■ 整形:降低流量的速度使其能够满足指定的带宽速率（一般是为了让流量不超过服务提供商合同规定的带宽）。

■ 列队:当入站流量超过了可用的出站资源（带宽）时，将数据包缓冲下来等待传输。

■ 分配带宽:对某类流量进行监测，确保这类流量占用的带宽不超过管理员通过配置指定的数值。

■ 准入控制:根据可用资源判断是否允许让某个数据包进入网络。

各个QoS功能并不是独立工作的，而且其中的任何一项功能又会由一些不同的特性组成。在下面的内容中，我们会首先解释各项特性如何与其他特性进行联动，以及设备处理这些特性的次序，然后会对（基于IOS的）模块化QoS命令行语句的结构进行介绍。

2.2.1 QoS行为模型

QoS概念所规定的行为与实施该QoS特性的平台无关，我们建议网络管理员在设计和配置QoS特性时，尽量使用通用的QoS规范，而不要使用那些某个设备平台或网络中某个区域专用的QoS特性。图2-1所示为配置界面、下层的工作方式模型，以及不同平台实施方案，这三个概念之间的关系。

图2-1 QoS行为模型

2.2.2 QoS特性排序

具体而言，在思考QoS的行为时，不妨认为这些行为有一个通用的执行顺序（如图1-2所示）。

■ 分类:也即对不同的流量进行区分。

■ 预列队:在将数据包排入出站队列中等待传输之前，最好首先对其执行准入控制、丢弃和标记等操作。

■ 列队:对在队列中等待传输的数据包进行排序。

■ 列队后:一般为可选操作。但有时需要根据数据包传输次序（如顺序编号）来为流量执行一些操作（例如压缩或加密），这些操作会在QoS调度函数根据优先级将数据包从队列中提取出去时，才会执行。

在考虑QoS的行为时，不妨从数据包流量穿越网络节点，以及QoS特性与数据包其他出入站特性相互作用的角度去思考。图2-2对数据包特性的执行顺序进行了高度的包括，其中方块1、2、6、7和12所代表的行为与QoS特性无关。

在数据包的入站接口(3)/出站接口(8)上有可能会执行分类。一般来说，应该在尽可能靠近源（也就是入站）的位置执行分类，但有时，设备只有在执行了输出特性(7)之后才能获得执行分类所需的属性。对于本地创建的数据包（而不是过境数据包），这种情况尤为常见，因为这类数据包不需要通过入站路径进入设备。

同样，数据包有可能会在入站(4)时进行标记，但设备也会可能会在出站时(9)根据数据包的某些变化，或者因为设备获取到了数据包的更多信息，而对数据包进行重新标记。例如，限速器（policer）可能会在出站方向上对一个未经确认的（confirming）数据包进行重新标记，而不是直接丢弃该数据包——但数据包未确认这件事只有在数据包到达路径的出站端设备才会知道，因为这是根据这段时间内流量的情况而定的，并不是数据包自身的某种独特属性。

图2-2 数据包特性执行顺序的高度概括

2.3 模块化QoS命令行模型

MQC这种结构化的命令行旨在为操作人员提供一种统一的、独立于设备平台的、灵活的配置方式，以简化在Cisco IOS 平台上配置QoS 特性的工作。为此，MQC 对QoS 行为的模式进行了简化和概括，让管理员无需了解设备平台的具体信息，就可以操作设备来完成QoS的配置工作。

2.3.1 MQC语法

MQC为实施下一列每一步QoS的配置定义了一个语法框架。

1.定义流量类型，并定义不同流量分别属于什么类型。

2.定义各个流量应该应用的动作或策略（例如，应用标记，或者为流量分配带宽）。

3.将策略关联到某个特定的逻辑或物理接口。

上述三个配置步骤可以通过三个基本的命令集来实现，它们是class map、policy map 和service policy。

■ class map:这个命令集的作用是指定各类数据包的匹配标准。

■ policy map:这个命令集的作用是为各个流量类型定义动作。其中每种类型的流量都可以指定一条或多条策略。策略的内容包括为流量限制一个最大的带宽，或者为队列中的某一类流量指定一个更高的优先级别等。

■ service policy:这条命令的作用是将policy map（以及相应的策略和管理员定义的流量类型）绑定到一个逻辑或物理接口，并指定在哪个方向（入站还是出站）上应用这条策略。

例2-1所示为MQC语法的通用结构。

例2-1 通用的MQC语法结构

! Define class maps:Packet matching criteria for classification

class class-map-name-n

<match-1>

<match-2>

...

<match-n>

! Define policy maps:Apply actions to each traffic class

policy-map policy-map-name

class class-map-name-1

<policy-1>

<policy-2>

...

<policy-n>

! Define service policy:Attach policy to an interface

interface serial 1/0/0

service-policy output policy-map-name

例2-2为使用MQC结构配置QoS的一个案例。在这个案例中，管理员定义了4种类型的流量，并对其中的三种进行了命名（REALTIME、CONTROL、CRITICAL-DATA），还有一种“默认”的理性。在这个案例中，设备会根据此前在数据包上应用的标记对其进行分类（match语句）。而在此前的图2-2中，QoS特性先对数据包进行了分类（方块8），然后才根据分类结果对其进行了标记（方块9）。在实际应用中，这两种顺序都很常见；边缘节点往往会根据对流量所进行的分析来分类流量，然后再对数据包进行打标（如图2-2所示），而其后的节点则会使用数据包上现有的标记对数据包进行分类，然后再对其应用策略（如例2-2所示）。

要注意，class map 和policy map 的名称都是区分大小写的。因此，class map type1、class-map Type1 和class-map TYPE1 定义的是三个不同的class map。在policy map 中调用class map 时，名称和大小写一定要和相应的class map 完全一致。

例2-2 MQC语法结构示例

Router# show run

class-map match-any REALTIME

match dscp ef　　! Matches VoIP bearer traffic

match dscp cs5　　! Matches Broadcast Video traffic

match dscp cs4　　! Matches Realtime-Interactive traffic

!

class-map match-any CONTROL

match dscp cs6　　! Matches Network-Control traffic

match dscp cs3　　! Matches Voice/Video Signaling traffic

match dscp cs2　　! Matches Network Management traffic

!

class-map match-any CRITICAL-DATA

match dscp af41 af42 af43　! Matches Multimedia Conf.on AF4

match dscp af31 af32 af33　! Matches Multimedia Streaming on AF3

match dscp af21 af22 af23　! Matches Transactional Data on AF2

match dscp af11 af12 af13　! Matches Bulk Data on AF1

!

policy-map WAN-EDGE-4-CLASS

class REALTIME

priority percent 33　　! 33% LLQ for REALTIME class

class CONTROL

bandwidth percent 7　　! 7% CBWFQ for CONTROL class

class CRITICAL-DATA

bandwidth percent 35　! 35% CBWFQ for CRITICAL-DATA class

fair-queue　　　　! Fair-queuing on CRITICAL-DATA

random-detect dscp-based ! DSCP-based WRED on CRITICAL-DATA

class class-default

bandwidth percent 25　! 25% CBWFQ for default class

fair-queue　　　　! fair-queuing on default class

random-detect dscp-based ! DSCP-based WRED on default class

!

interface serial 1/0/0

service-policy output WAN-EDGE-4-CLASS

注释:本书中对class map、policy map和访问列表采用全大写的命名方式，以便于将MQC命令与传统的IOS命令集区分开。

2.3.2 默认行为

未分类流量会被归入隐式默认类别中，根据相应的方式进行处理。默认类会自动成为MQC配置中的一部分。

如例2-2 所示，默认类不能在class map 那一部分中进行配置。因为根据定义，默认类包含所有在class map 的配置中无法归类的流量。但管理员可以通过例2-2 所示的CLI 命令，为class-default指定policy map，以此来为默认类型的流量指定QoS特性（列队、整形、分配带宽等）。这是可选的，如果没有为默认类分配policy map，那么也就相当于管理员没有为默认类型的流量分配QoS特性，因此设备会对这类流量提供尽力而为的传输，也就是使用所有没有通过配置明确指定给任何类别的带宽。

在没有为未分类流量配置QoS特性时，处理这类流量的默认做法是先进先出（FIFO）尾部丢弃的策略，这种策略会按照平等的方式处理所有流量，在输出队列满载时，设备就会开始丢弃数据包。

2.3.3 流量分类（class map）

下面是三种最为常见的流量分类方式。

■ 标记:检查第2层（服务类型[CoS]）或第3层（IP优先级[IPP]或差分服务代码点[DSCP]）的设置。

■ 地址:检查接口的源/目的，或第2层目的地址，或者第3层源/目的地址，或者第4层源/目的端口。使用IP地址可以分类由不同设备发送过来的流量，而使用端口号的方式则往往适用于将流量按照类型进行分类的场合。

■ 应用签名:检查数据包负载中的应用内容，也称为深度数据数据包监控。

使用标记和地址进行分类的方法，会使用到数据包头部/数据帧头部/标记头部的信息，而使用应用进行分类的方法，则需要检查数据包应用层（L7）的负载。

class map是一种CLI框架，它适用于全部上述三种机制（基于标记/地址/应用的分类）。在一个class map 中，可以包含一条或多条match 语句，以定义属于某一种分类的流量；一个class map 可以采用上述三种机制之一（或者将这三种机制结合起来）来分类流量，而match语句后面的关键字决定了这个class map 使用的是哪（几）种机制。可以匹配的内容包括CoS或DSCP标记、源或目的地址、协议或应用协议等，如例2-3所示。

例2-3 class map示例

Router# show run

class-map markings

match dscp af41 af42 af43

!

class-map mac-address

match destination-address mac 00:00:00:00:00:00

!

class-map ftp

match protocol ftp

管理员可以通过class map 这条CLI 命令指定如何组合各个匹配标准，来定义一个流量。有三种方式可以定义一种流量分类。

■ 匹配所有的标准（match-all）。

■ 不匹配任何一种标准（match not）。

■ 至少匹配其中的某一项标准（match-any）。

注释:（在没有指定的情况下）默认的逻辑操作方式为match-all。

2.3.4 定义策略（policy map）

管理员可以在policy map 中为通过class map 指定的各个流量类型，定义一个或多个动作（或QoS 处理方式）。在例2-2 中，包含了一个名为WAN-EDGE-4-CLASS 的policy map，它为4种类型的流量指定了相关的QoS策略。在该示例中显示的处理方式包含了分配带宽（关键字为priority和bandwidth）、队列算法（关键字为priority和fair-queue）、弃门限值（关键字为random-detect）。

在定义策略时可以包含以下几种类型的处理方式:

■ 分配带宽；

■ 队列检测（优先级队列、公平队列、队列长度限制）；

■ 流量整形（通过队列的方式限速或延迟发送数据包）；

■ 数据包丢弃（通过丢弃数据包进行限速，如随机丢弃、尾部丢弃或无条件丢弃）；

■ 标记数据包（将头部字段设置为某个数值）；

■ 对数据包计数；

■ 压缩数据包头部；

■ 准入控制。

尽管在配置中定义class map 的顺序并不重要，但在policy map 中类的次序却很关键。与ACL（访问控制列表）的处理方式相同，policy map也会采用“优先匹配”的规则，也就是说，数据包会按照policy map中各个类的顺序进行校验，直到找到匹配条目为止。一旦找到匹配条目，检查的过程就会中止，设备不会再尝试匹配后面的类。如果没有找到匹配条目，数据包就会被归入默认的类别。

为了说清楚policy map 中各个类别排序的重要性，不妨参考例2-4。在这个示例中，包含了两个流量类，其中VOICE归类语音流量，而FAX-RELAY归类传真流量。这两个类在全局配置中的顺序无关紧要。但我们的目的是按照不同的方式处理语音流量和传真流量（为了严格控制各类流量可以使用的最大带宽），虽然这两类流量是以同样的方式进行标记的——所有数据包都在各自的源标记了DSCP EF。

例2-4 policy map排序示例

Router# show run

class-map match-all FAX-RELAY

match dscp ef

class-map match-all VOICE

match protocol rtp audio

!

policy-map VOICE-AND-FAX

class VOICE

priority 216

police cir 216000

class FAX-RELAY

priority 64

police cir 64000

在例2-4 中，管理员对于policy map VOICE-AND-FAX 中各个类别的顺序进行了精心的规划。其中类VOICE的次序在前，执行NBAR（基于网络的应用识别）分类来区分某种流量是否为实时传输协议（RTP）的音频流量（也就是语音流量）。只有不符合这一类别的流量才会由policy map 中第2 个类别（FAX-RELAY）进行校验。

类FAX-RELAY会检验数据包的DSCP值是否为EF。因为只有两类流量的DSCP值为EF（语音流量和传真中继流量），而语音已经被过滤掉了，因此其他满足这一标准的流量只能是传真中继流量。接下来，管理员为传真中继流量分配了相同的队列策略，但为它们分配了不同的带宽。如果policy map中的两条class语句调换顺序，这个策略的工作方式就会全然不同:不会有策略属于VOICE这个类别，因为语音和传真中继流量都匹配DSCPEF的条件，因此语音流量也会被归入FAX-RELAY这个类别中。图2-3显示了policymapVOICE-AND-FAX校验各个数据包时的逻辑。

图2-3 policy map VOICE-AND-FAX的执行顺序

2.3.5 为流量应用策略（service policy）

policy map 需要与一个逻辑接口或物理接口进行关联，这些接口包括:

■ 主接口；

■ 子接口；

■ 多链路点到点协议（MLPPP）束；

■ 虚拟模板；

■ 虚拟局域网（VLAN）；

■ 异步传输模式（ATM）或帧中继（FR）虚链路（VC）。

命令service policy 同时也会指定相关策略应该应用到这个接口的哪个方向（入站方向还是出站方向）上，如例2-5所示。在不同平台上，这条命令的作用可能会略有区别，因为该命令也会应用于无线空间SSID（服务集标记）的设置当中。

例2-5 入站策略与出站策略

Router# show run

policy-map POLICY-1

...

bandwidth 20000

policy-map POLICY-2

...

bandwidth 64000

!

interface Ethernet 1/0

service-policy input POLICY-1

!

interface Ethernet 1/1

service-policy output POLICY-2

2.3.6 层级式QoS和HQF

长期以来，MQC框架和语法结构始终支持层级式的结构，这可以让管理员以子接口为单位来部署一部分策略（例如，让穿越该子接口的某一类流量不高于某个速率），同时还能够以接口为单位对所有流量应用全部策略（比如让整形后的总速率符合服务提供商合同中的规定）。

图2-4 所示为管理员在主接口（Gigabit Ethernet 1）下的两个子接口1.1 和1.2 上部署的分层策略。在这个示例中，这两个子接口一共可以放行22kbit/s的流量进入主接口，通过整形，这个吞吐量被限制在20kbit/s以内。因此，如果这两个子接口同时占用了全部分配给它们的带宽，主接口就会额外实施流量整形策略，以保障穿越接口的流量之和不会超过20kbit/s。

在实施层级式的策略时，需要在policy map 中（而不是接口配置模式下）应用service policy，如例2-6所示。这个案例显示了在接口下，总流量都会整形为20kbit/s（policy-map AGGREGATE），但在这个速率范围内，语音流量可以获得最小3kbit/s带宽的保障。

图2-4 层级式的策略

例2-6 层级式的策略

Router# show run

! Definitions for sub-interface GE1.1

policy-map CHILD1

class VOICE1

priority 3000

class VIDEO1

bandwidth 5000

policy-map PARENT1

class class-default

shape average 15000

service-policy CHILD1

!

! Definitions for sub-interface GE1.2

policy-map CHILD2

class VOICE2

priority 1500

class VIDEO2

bandwidth 2500

policy-map PARENT2

class class-default

shape average 7000

service-policy CHILD2

!

! Definitions for the main interface

policy-map AGGREGATE

class class-default

shape average 20000

!

interface ge 1/1.1

service-policy output PARENT1

interface ge 1/1.2

service-policy output PARENT2

interface ge 1/1

service-policy output AGGREGATE

在2006年，为了增强层级式的策略，以支持层级式队列，出现了QoS HQF（层级式队列框架）的理念。这意味着队列可以以子接口为单位进行应用（或者应用在逻辑接口的层面），同时接口队列也能够与这些逻辑级别的队列共存。接口级的队列算法可以反向作用于更高级别的队列，以确保各个层级的数据包都能够正常地调度和发送。

2.3.7 传统的QoS CLI不再使用

MQC CLI 存在于Cisco IOS 系统中的时间已经超过了10 年，但有些QoS 配置命令比MQC的历史还要悠久。这些传统的CLI命令长期以来一直和MQC语法共存，因此导致很多人在使用MQC配置的QoS特性，与不使用MQC配置的QoS特性之间如何互动这一方面，产生了很多误解。因此，从2011 年7 月开始，一些比MQC 古老的传统QoS CLI 命令就开始陆续从系统中删除；15.2M和15.2T版的系统发布了警告，指出这些命令有可能会被取消。如果读者有一些较老的平台正在使用这些命令，读者应该尽早将它们转换成对应的MQC命令。

总之，读者务必将使用非MQC的CLI命令行配置的QoS特性转换为表2-1中所示的相应MQC命令。如需进一步了解MQC命令的具体信息，可以查看Cisco产品公告（PB）之Legacy QoS CLI Commands Deprecation，PB580832，April 2012。

表2-1 将传统QoS CLI修改为MQC CLI的汇总信息

续表

2.4 AutoQoS

为了简化QoS的部署工作，Cisco设计出了自动QoS（AutoQoS）特性来自动实现QoS设计方案的最佳做法。AutoQoS是一种智能的宏命令，这种技术可以让管理员仅输入一到两条命令，就在特定平台的特定接口上，为相关命令启用推荐的QoS特性与设置。管理员既可以全权依赖AutoQoS特性，也可以先使用AutoQoS进行快速配置，然后再按照自己的特定需求，对系统自动生成的命令进行进一步的调整。

AutoQoS VoIP 是AutoQoS 特性的第一个版本，这个特性自12.2(15)T 版开始就可以在Cisco IOS 路由器平台上使用。AutoQoS VoIP 可以让Cisco Catalyst 交换机和Cisco IOS 路由器为VoIP流量提供最佳的QoS设计方案。管理员只需输入一条全局模式的命令或者一条接口模式的命令（具体在哪种模式下输入命令依设备的平台而定），AutoQoS VoIP 特性就可以在该平台或应用AutoQoS CLI 命令的接口上添加推荐的VoIP QoS 配置（这些参数和配置都是经过了计算的）。

对于园区中的Catalyst 交换机，AutoQoS VoIP 会自动执行以下操作。

■ 在Cisco IP 电话上添加一个信任边界。

■ 在交换机接入端口和上行链路/下行链路上添加一个信任边界。

■ 为语音流量启用严格的优先级队列，同时为数据流量启用加权轮巡队列。

■ 修改队列的准入标准（即修改CoS与队列之间的映射关系）。

■ 在有必要时修改队列长度，以及队列的权重。

■ 修改CoS与DSCP之间的映射关系，以及IP优先级和DSCP之间的映射关系。

对于Cisco IOS 路由器，FR（帧中继）、ATM、HDLC（高级数据链路控制）、MLPPP 和FT-ATM 链路上支持AutoQoS VoIP，路由器会自动执行以下操作。

■ 对流量进行分类，标记VoIP承载的流量（DSCPEF）和呼叫信令流量（DSCPCS3）。

■ 应用合理的队列配置。

■ 为语音流量应用低延迟（LLQ）队列。

■ 为呼叫信令应用基于类的加权公平（CBWFQ）队列。

■ 为所有其他类型的流量应用公平（FQ）队列。

■ 在有必要时，以优化参数启用帧中继整形（FRTS）。

■ 在有必要时，针对低速链路（768kbit/s）启用链路分片与交错（LFI）。

■ 在有必要时，启用IP RTP 头部压缩（cRTP）。

■ 为丢弃的VoIP数据包提供远程监测（RMON）告警。

AutoQoS 特性的第二个版本称为AutoQoS Enterprise，自12.3(7)T 版本的系统开始，这个特性便可以在Cisco IOS 路由器上进行使用了。AutoQoS Enterprise 只能应用于Cisco IOS 路由器上，它可以检测和提供多达10个类别的流量，包括:

■ 语音流量；

■ 互动式视频流量；

■ 视频流；

■ 呼叫信令流量；

■ 业务性数据；

■ 大数据；

■ 路由流量；

■ 网络管理流量；

■ 尽力而为传输的流量；

■ 清道夫流量。

Auto QoS Enterprise 特性由2 部分组成，它们的顺序如下所示。

■ Autodiscovery（数据收集）:使用基于NBAR的协议发现机制来检测网络中的应用，并对网络流量执行数据分析。

■ AutoQoS模板的创建与安装:使用通过Autodiscovery步骤中收集的数据来创建模板，并将创建出来的这些模板安装在接口上。接下来，设备会以这些模板为基础，来为网络创建class map 和policy map。在创建出了class map 和policy map 后，它们就会被安装到接口上。

在2010 年，Cisco 通过12.2(55)SE 版本的系统，为Catalyst 2960-G/S、2975-GS、3560-G/E/X和3750-G/E/X系列交换机提供了一个针对视频应用的新版AutoQoS特性。它可以为这些交换机系列所支持的富媒体应用部署推荐的QoS方案。这个版本的AutoQoS可以在接口配置模式下提供四大类的入站QoS策略。

■ auto qos voip [ cisco-phone | cisco-softphone | trust ]:这个选项对VoIP模型进行了扩展，在其中包含了其他类别的富媒体应用，同时包含了数据层限速/清道夫类QoS策略等元素，以保护这些类型的应用。

■ auto qos trust { cos | dscp }:这个选项的作用是对端口进行配置，以静态地信任CoS或DSCP。如果管理员既没有明确配置CoS，也没有明确配置DSCP，那么命令auto qos trust 就会（默认）在2 层交换端口上配置CoS 信任，同时在3 层路由接口上配置DSCP信任。

■ auto qos video [ cts | ip-camera ]:这个新的选项可以通过配置，自动支持 Cisco TelePresence系统（通过命令cts）和IP视频监控摄像头（通过命令ip-camera）。

■ auto qos classify { police }:这个选项可以提供一个通用的模板，以便管理员对流量进行分类，并对多达6种富媒体流量进行标记，同时也可以根据管理员的需要，（通过命令policy）为这些流量提供数据层限速/清道夫类QoS策略。

2.5 小结

本章对QoS架构、语法和结构的内容进行了概述。QoS特性的结构和行为模型，以及MQC 框架与语法结构都在本章中进行了介绍，包括class map、policy map 和service policy 等命令。此外，通过本章的内容，读者还应该了解到QoS的部署原则和层级，以及AutoQoS的功能。

本章的内容是读者进一步学习此后各章技术所必备的基础知识。

2.6 扩展阅读

2.6.1 通用内容

Quality of Service Solutions Configuration Guide Library（QoS解决方案配置指南实验）:http://www.cisco.com/en/US/docs/ios-xml/ios/qos/config_library/15-0m/qos-15-0m-library.html Modular QoS (MQC) Command-Line Interface Configuration Guide（MQC命令行界面配置指南）:http://www.cisco.com/en/US/docs/ios-xml/ios/qos_mqc/configuration/15-1mt/Applying_QoS_Features_Using_the_MQC.html

Hierarchical Queuing Framework (HQF) Configuration Guide（HQF 配置指南）:http://www.cisco.com/en/US/docs/ios-xml/ios/qos_hrhqf/configuration/15-0m/qos-hrhqf-15-0m-book.html

Cisco Product Bulletin Legacy QoS CLI Commands Deprecation, PB580832,April 2012 (also available at http://www.cisco.com/go/qos > Data Sheets and Literature > Bulletins):http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6558/product_bulletin_c25-580832.html

2.6.2 AutoQoS

AutoQoS At-a-Glance（AutoQoS 攻略）:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/autoqosmediacampus.pdf

Overview（概述）:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSIntro_40.html#wp61040

Tools（工具）:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/QoSIntro.html#wp46186

AutoQoS Enterprise:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/BranchQoS.html#wp100320

AutoQoS for switches（交换机的AutoQoS）:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSCampus_40.html#wp1098289

Technical presentation（技术演示）:http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6558/ ps6613/ps6656/prod_presentation0900aecd80313756.pdf

AutoQoS Configuration Guide（AutoQoS 配置指南）:http://www.cisco.com/en/US/docs/ios-xml/ios/qos_auto/configuration/15-1mt/ qos-auto-15-1mt-book.html

第3章 分类与标记

本章包含了如下主题:

■ 专业术语；

■ 用不同技术执行数据包标记:用来执行分类和标记的数据包头部字段与隧道头部字段；

■ 分类工具与机制；

■ 标记工具与机制；

■ 推荐做法。

实施QoS策略的第一步是对流量进行分析和区分，以便针对不同的流量采取不同的处理方式。一旦判断出了流量的类型，那么设备就会在属于某一类型的数据包的头部字段写入一个数值，这样可以让后面的设备无需再对流量重新进行分析（分析往往会在网络边缘的入站位置执行，这个位置越接近流量的源越好）。

3.1 分类和标记

在深入了解各种分类和标记工具之前，不妨先来回顾下面几个与分类和标记相关的主题:■ 分类与标记的术语；

■ 安全与QoS；

■ 视频和无线流量带来的挑战；

■ 不同技术的标记字段；

■ QoS标记的映射。

3.1.1 分类和标记的术语

虽然分类和标记这两个词经常交替使用，但是这两个词代表的意思却不尽相同。

■ 分类:分类指将数据包归类为不同类型的流量，以便为不同的流量应用不同的策略。在没有标记的情况下也可以对数据包进行分类。

■ 标记（或重标记）:指在数据包头部写入一个数值。打标的行为往往发生在网络边缘的信任边界，或者位于两个不同网络的交界处。因为在这些位置，设备经常要决定是接收还是拒绝数据包上现有的标记（若拒绝，设备则会对数据包进行重标记）。标记的行为也会发生在网络中的其他位置，而且标记的作用有时也并不是单纯为了对数据包进行分类。

在执行标记和分类这两种不同的行为时，实际的工具也会对流量应用一些不同的动作。

■ 分类工具:监控数据包中的一个或多个字段，以识别数据包所携带的流量类型。一旦设备识别出了流量的类型，就会对其应用针对这种类型流量所预先定义的策略，包括标记、队列、限速、整形或者几种QoS策略的组合。

■ 标记工具:在数据包头部、数据帧、标记、信元或标签中写入一个数值，这是为了在网络的信任边界将对于该数据的分类保存下来。这样一来，在这个信任边界中的后续节点就不需要再重复对数据流进行分析和判断了（因为这样会大量消耗网络的计算资源）。

DSCP（差分服务代码点）、CS（类选择器）代码点、CoS（服务类型）、服务类型（ToS）和TID（流量标志），这些都是在数据帧第2层或数据包第3层头部中指定这个字段值的一些概念。这些字段的不同数值往往对应着一种（设备）对数据帧或数据包的处理方式。

上述这5个字母缩写的概念和用途都是相同的，这些词在有些场合中可以替换使用，但这些词在适用范围和确切的定义上，还是存在一些区别的。

■ CoS 多用于以太网2 层数据帧（IEEE 802.1Q/p 占主导地位）的环境，这个字段包含3比特位的长度。

■ ToS指的经常是3层IPv4数据包中的字段，这个字段包含8个比特位，其中3个是RFC 791 所定义的IP 优先级字段。IPv6 RFC 2460 则对数据包头部的同一个字段中，流量类型（Traffic Class）的概念进行了修改。

■ DSCP 定义在RFC 2474、2597 和2598 中，这是一个长度为6 比特的字段，它指定的是3 层IPv4 ToS 字段的数值（即图1-3 那个8 位字段的最左侧6 位）。

■ CS是DSCP中一个3位长度的子集；它使用的数据位与IP优先级字段的那3位相同，但CS的数值与逐跳行为相对应（数值与行为之间的对应关系符合定义6比特DSCP的RFC文档）。

■ TID 指的是802.11 WiFi MAC 数据帧中，QoS 控制字段内的一个3 比特位。这个字段中的8个比特位对应8种用户优先级（UP），这个字段可以大致与CoS相对应。但TID一般用于无线以太网连接的环境，而CoS则多用于有线以太网连接。

3.1.2 安全与QoS

安全技术与QoS技术的公共领域包括以下内容:

■ 信任边界；

■ 对蠕虫或网络的其他安全威胁进行识别、分类和处理。

1.信任边界

信任边界是指网络中不接受数据包标记的那个位置（因此，也常常是对数据包进行重标记的位置）。相反，信任域则是接收数据包标记并根据数据包标记执行操作的网络区域。

不信任的区域可能包括那些终端用户可以直接访问的网段或设备，如计算机和打印机等，而信任区域则往往包括只有网络管理员也会访问的路由器和交换机等设备。信任边界也可能会位于企业网络和服务提供商网络之间:其中，服务提供商在建立自己的信任边界时，完全不会考虑企业网络认为自己的区域有多安全。在政府网络和教育网络的各个部门、学院或机构之间，经常也会出现信任边界。在一个企业园区网中，信任边界一般都会位于边界交换机上。

从非信任区域发来的流量，其QoS标记一般会被忽略，设备会对流量进行重新监控、重新分类和重新标记，然后再将它发送给信任网络。这可以防止流氓设备滥用网络的QoS处理机制，造成严重的后果。比如，即使用户通过设置自己的计算机，将所有的流量都打上了DSCP EF 标记，当这些流量到达信任边界时，接入层的交换机也会忽略掉这些标记，这台交换机会按照企业QoS策略对流量进行监控和重标记。

2.网络攻击

拒绝服务（DoS）攻击和蠕虫攻击发生的频率越来越高，攻击方式越来越复杂，攻击的范围也越来越广。QoS工具和设计方案可以降低蠕虫攻击的效果，而且能够让关键应用在DoS攻击期间正常工作。

举例而言，根据RFC 3552 的描述，QoS“清道夫类”的作用就是为那些对企业业务毫无帮助的流量（比如那些以娱乐为目的的应用所发送的流量）提供一种“比尽力而为程度更低”的服务。此外，在网络出现拥塞时，清道夫类流量也是设备主要丢弃的流量。

DoS攻击和蠕虫攻击的实现方式都是让网络中充斥着恶意流量，而通过特征区分出流量中的合法数据和恶意数据，并对超过清道夫类限制的流量进行限速和重标记，就可以缓解这两种类型的攻击。

3.1.3 视频和无线流量带来的分类挑战

与传统类型的流量和通过有线方式进行访问的流量相比，视频流量和通过无线边界技术进行访问网络流量更难以进行分类。

视频流量一般是由多种不同类型的流量所组成的，与清道夫类（与业务无关的娱乐视频，如YouTube）的流量相比（在很多环境中，这类流量都会被直接丢弃），发送这些流量的应用可能拥有极高的优先级，而且对延迟非常敏感（如仿真Cisco TelePresence 流量）。

根据RFC 4594，视频流量可以大致分为4 种类型（这些都可以归类为交互式流量）。

■ 互动视频

■ 实时互动:高清交互视频应用（如Cisco TelePresence）。

■ 多媒体会议:桌面软件多媒体协作应用（如，CiscoUnifiedPersonalCommunicator）。

■ 流视频

■ 广播视频:广播IPTV、实况新闻（如IP视频监控和数码指示牌应用）。

■ 多媒体流:按需视频（VoD）流，由于这类流量（如网络教学视频和视频会议的重播）可以进行缓冲，因此对于延迟和抖动并不敏感。

通过无线访问的方式到达网络的流量，则会给数据分类带来另一个层面的挑战，因为无线设备可以进行漫游，无论用户身处何地，网络都必须能够为相同的终端用户提供“相同”级别的服务。这种QoS需求会使用缓存下来的无线数字证书（用于快速漫游，以及向设备发送实时信息），以及IEEE 802.11 规范来实现，其中IEEE 802.11 规范可以为无线设备请求通过不同访问方式，并携带有不同标记的流量（这类流量往往位于网络信任边界的不信任一侧，因此这就会引发一个问题，即对于无线设备而言，信任边界是否能够，或者说是否应该，可以在某些条件下随着无线设备的移动进行扩展）。

WiFi多媒体（WMM）和IEEE 802.11e标准的分类方式（原802.11e无线标准已经结合到了更加宽泛的802.11以太网标准中）与Cisco网络推荐和采用的分类方式不同，因为Cisco的分类标准参考的是IETF推荐的分类方式。这些无线设备（以及用户设备和接入点[AP]）使用的无线QoS用户文件必须与网络QoS设计战略所定义的QoS类别和设置之间，建立映射关系。在Cisco当前的无线模型中，无线设备发送的所有流量类型都会带有自己的服务集标识（SSID），而SSID会与VLAN之间建立映射。SSID决定了QoS的处理方式。由于AP和控制器之间传输的无线流量也常常需要进行加密和隧道传送，因此无法使用在头部的QoS标记字段打标的传统做法。

3.1.4 不同技术的标记字段

在1.2.4节中，我们曾经介绍过在数据帧和数据包的2层和3层头部中，有很多字段可以用来对流量进行打标。除此之外，还有一些隧道头部可以对IP数据包进行封装，包括GRE（通用路由封装）、MPLS（多协议标签交换）和IPSec（因特网协议安全）等其他形式的虚拟专用网（VPN）隧道协议，以及多用于实现无线传输的CAPWAP（Control and Provisioning of Wireless Access Points，无线接入点控制与实现）隧道协议。本节会对上述字段和技术分别进行介绍。

使用IP优先级和DSCP进行3层数据包标记是对数据包进行标记时，最为常见的一种选择，因为3层数据包标记具有实现端到端通信的重要意义，而将3层数据包标记转换为2层数据帧标记，或者将2层数据帧标记转换为3层标记，也都比较简单。

1.字段取值及表意

使用1比特位的字段（如异步传输模式[ATM]和帧中继[FR]）只能为不同数据帧提供丢弃优先级（高或低）的相对数值。而使用3比特位的字段则可以最多标记8种不同的服务类型。6字节宽度的字段可以对数据提供最为细致的分类标准，即定义多达64种类型的服务。表3-1对各类技术和字段的长度进行了总结。

表3-1 2层和3层标记字段总结

* DE（可丢弃位）、CLP（信元丢弃优先级位）、EXP（实验位）

以太网的CoS 和3 层IP ToS 的IP 优先级字段，它们取值的含义如表3-2 所示。

表3-2 各应用类型的CoS/IP优先级值

在IPv4和IPv6头部中的6比特位DSCP字段，它们的含义如图3-1所示。DSCP值既可以以数字的形式表示，也可以通过特殊关键字名称（称为逐跳行为）的形式来表示。DSCP PHB定义了三种类型:尽力而为（BE或DSCP为0）、确认转发（AFxy）和快速转发（EF）。除了这三类定义的PHB之外，根据定义，CSx（类选择器）代码点也可以反向匹配IP优先级（换言之， CS1到CS7等同于IP优先级值1到7）。描述这些PHB的RFC为RFC 2547、2597和3246。

图3-1 DSCP编码含义

RFC 2597 定义4 种确认转发的类型，表示方式是在字母AF 后面加上两个数字。AF 类后面第1位数字指代AF的类别，取值范围为1～4。第2个数字则指代各AF类的丢弃优先级，取值范围从1（丢弃优先级最低）到3（丢弃优先级最高）。例如，（符合RFC 2597 标准的节点）在拥塞期间，AF33丢弃数据包的频率应高于AF32，而AF32丢弃数据包的频率则高于AF31。图3-2 所示为AF PHB 的编码方式。

图3-2 DSCP确认转发编码含义

2.以太网802.1Q/p

在802.1Q头部设置802.1p用户优先级比特位（CoS）就可以在2层为以太网数据帧标记一个相对的重要性指数，如图3-3所示。

图3-3 以太网数据帧:802.1Q/p CoS字段

3.以太网802.11WiFi

在802.11 WiFi MAC 头部的QoS 控制（QoS Control）字段中设置802.11 WiFi 流量标识符（TID）字段，就可以在2层对无线以太网数据帧进行标记，如图3-4所示。

图3-4 802.11 WiFi MAC数据帧QoS控制字段

4.ATM和FR

本书在此仅从历史的角度对ATM和FR进行介绍，因为它们都是比较古老的技术。虽然这两种技术都得到了广泛的部署，但是几乎没有人会在新建网络中使用这两种技术。

ATM CLP 位是一个二进制字段，这个字段只能取两个数值:0（默认值）表示流量优先级高；1用于携带低优先级流量的信元，这类数据在网络拥塞时可以进行丢弃。例3-1显示了如何根据不同的类别标记ATM CLP 位。

例3-1 设置ATM CLP位

Router# show run

policy-map SET-ATM-CLP

class OUT-OF-SLA

set atm-clp

帧中继DE 位在定义和使用方面与ATM CLP 位完全相同。例3-2 所示为如何在服务策略中设置帧中继DE位。

例3-2 设置帧中继DE位

Router# show run

policy-map SET-FR-DE

class OUT-OF-SLA

set fr-de

5.IPv4和IPv6

IPv4数据包会携带一个长度为8比特的服务类型（ToS）字段，而IPv6头部则拥有一个8比特长度的流量类型（Traffic Class）字段。这两个字段的头3个比特位都是IP优先级（IPP）位。这3个比特位与后面的3个比特位结合在一起，就组成了前文介绍的差分服务代码点（DSCP）。

本书在第1章中曾经提供了IPv4和IPv6数据包的头部结构。这些字段（CS或DSCP）可以使用例3-3所示的方式进行设置。

例3-3 在IPv4或IPv6头部设置IP优先级或DSCP字段

Router# show run

policy-map SET-DSCP

class DSCP-AF31

set dscp af31

6.L2和L3隧道

Cisco路由器提供了大量的隧道特性，如GRE、IPSec和L2TP（二层隧道协议）。通过这些技术，服务提供商可以使用一个IP数据包来对另一个IP数据包进行封装，以建立三层VPN隧道。这种封装方式可以在数据包原头部的基础上封装一个外部头部，以便让原数据包在穿越中间网络的过程中，也可以保留原来的地址。另外，隧道技术也可以提供加密类的特性，这种特性使得隧道技术不仅能够保留数据包的地址，而且可以为数据提供私密性方面的保护。

RFC 3378 描述了EoIP（Ethernet over IP tunnels）技术，这种技术可以通过IP 网络，为两端的非IP协议建立隧道。从本质上讲，EoIP隧道是一种用于无线部署环境的L2TP隧道。

图3-5所示为GRE、IPSec、EoIP隧道数据包的头部信息。

图3-5 三层隧道数据包示意图

内部头部的标记字段未必会自动复制到外部头部中。如果内部头部的标记字段并没有自动进行复制，管理员就必须通过CLI命令来对外部头部进行标记。实现这一功能的方法包括在隧道接口（GRE 或L2TP）或（IPSec 的）crypto map 中实施qos pre-classify。在L2TP 隧道上也可以使用CLI 命令l2tp tos reflect。在跨越IP 网络传输2 层数据帧的环境中，L2TPv3 是一种广泛使用的协议。

7.CAPWAP

CAPWAP 是一款定义在RFC 5414 中的IEEE 协议，这个协议可以让无线控制器对一组无线接入点进行管理。这款协议是以LWAPP（轻量级接入点协议）为基础设计出来的，它的工作包括建立数据报传输层安全（DTLS），并提供无线AP的配置和设备管理功能。作为一款隧道协议，CAPWAP在外部IP头部中包含了一个DSCP字段，以便对数据包进行标记。

8.MPLS

MPLS是一个隧道协议，它会在IP数据包中插入一个长度为4字节的标签。MPLS标签中包含了一个3 比特位的CoS 标记字段，这个字段称为MPLS EXP（实验）位，如图3-6 所示。

图3-6 MPLS标签中的MPLS EXP位

MPLS EXP 位的取值与802.1Q/p CoS 和IP 优先级的取值相同，也可以按照相同的方式与6 比特的DSCP 值建立对应关系。MPLS EXP 位可以通过class map 中的match 和set 命令进行控制。

在MPLS 隧道方案中，一个数据包可能带有多个MPLS 头部。命令set mpls experimental imposition 可以为数据包的所有标签都设置一个数值，而命令set mpls experimental topmost则只会在最外层的标签上设置管理员指定的数值。

3.1.5 QoS标记的映射

在很多环境下，我们必须对流量进行重标记，这些环境包括:

■ L2到L3网络的边界；

■ Cisco 到RFC 4594 网络的边界；

■ 无线到有线网络的边界。

1.将L2标记映射为L3标记

在L2 CoS 或L3 IPP 值中，往往包含6 比特的DSCP 值中3 个最重要的比特位。因此，可以直接将其映射为区分服务RFC所定义的CS（代码选择器）点。

例如，CoS 5（二进制值为101）会被映射为DSCP40（二进制值为101000）。对应的原则是，将如图3-2所示的示意图中，XXX的部分用CoS值来代替，而YY的值则依然为0。表3-3显示了CoS、CS、DSCP 值之间的对应关系。表3-3 中所示的对应关系，也可以将L3 IPP 映射为L3 DSCP。

表3-3 L2 CoS与L3类选择器/DSCP之间的对应关系

*类选择器0 是一个特例；它代表的是默认的标记值（定义在RFC 2474 Section 4.1 中）。因此，人们很少称之为类选择器0，而常常称它作默认发送或DF

2.Cisco标记映射为RFC 4594标记

Cisco在QoS标记的使用方面参照了RFC 4594的标准，两者唯一的区别在于，Cisco将呼叫信令（Cisco=CS3，RFC 4594=CS5）和广播视频（Cisco=CS5，RFC 4594=CS3）的标记值进行了对调，如图3-7所示。

注释:将这两个标记对调的理由将在第9章中进行介绍。

若要将Cisco 网络与一个严格按照RFC 4594 文档的标准来对流量进行标记的网络进行互联，可能就需要在网络边界对广播视频和呼叫信令流量重新进行标记。

图3-7 Cisco在RFC 4594标准的基础上修改的标记值

3.无线网络的标记映射

Cisco 统一无线产品支持WiFi 多媒体（WMM），这是一个基于IEEE 802.11e（电气和电子工程师协会）且由WiFi联盟发布的QoS系统。802.11e无线修正案已经结合到了更加宽泛的802.11 以太网标准中，当前人们一般称之为802.11 WiFi。IEEE 802.11 WiFi 分类与Cisco 无线技术对分类的处理方式（后者基于IETF RFC 4594）存在区别，如表3-4 所示。它们在分类方面的主要区别在于，Cisco 无线技术将语音和视频流量的标记调整为了CoS 5 和CoS 4（而在IEEE 802.11 WiFi 标准中，它们的标记为CoS 6 和CoS 5）。

表3-4 IEEE 802.11 WiFi、WMM和DSCP的对应关系

续表

为了同时满足这两种标准，当流量穿越无线-有线边界时，Cisco统一无线解决方案会对数据包标记执行一次转换。WMM 语音流量在到达无线控制器或AP 时，会带有CoS 6 的标记，而控制器或AP会执行一次CoS-DSCP转换。在统一无线网络中，管理员应该始终按照IEEE 802.11 WiFi 分类的方式去思考网络的标记方式，并且让Cisco 统一无线网络解决方案在IEEE分类方式和Cisco QoS 推荐做法之间进行转换。

3.2 分类工具

流量分类的作用是判断一组数据流中的数据包或数据帧属于哪一种类型。只有对流量进行了有效的分类之后，才能对其实施有针对性的策略。因此，在设计网络时，推荐的最佳做法是在信任边界对流量进行区分和标记，而这个边界应该进行可能贴近流量的源地址，因此边界的位置一般就位于配线柜之内，或者位于受信设备（如IP电话或无线控制器）自身。如果对于标记和信任边界的设置正确无误，那么中间的设备就不需要重复对数据包进行深入的分类了，这些设备完全可以按照之前设备为其设置的标记对其应用策略（比如执行队列调度）。比起让每一台都通过深度数据包监控来区分流量的类型，这种及其占用处理器资源的做法来说，这种做法可谓多快好省。

正如第2章中介绍的那样，分类流量大体有3种方式，头两种方法使用头部信息来分类流量，第三种则使用数据包的负载对其进行分类。

■ 标记:查看L2（CoS）或L3（DSCP）的设置。

■ 地址:查看源/目的端口、接口或地址（L2或L3地址）。

■ 应用签名:查看数据包负载中的应用内容，这种方法也称为深度数据包监控。

3.2.1 基于类的分类（class map）

在MQC的结构中，数据包分类是通过本书第2章中介绍的class map来实现的。具体地说，是通过在class map 中设置的CLI 语句match（字面意思即为匹配）来实现的。

匹配语句可以通过多种不同的方式进行组合，以制定出非常精确和细致的分类标准。总地来说，match语句可以定义下列标准，对流量进行分类。

■ 数据包头部标记

■ match atm-clp:匹配ATM 的CLP（信元丢弃优先级）位。

■ match cos:匹配802.1Q/p CoS 值。

■ match discard-class:匹配丢弃类的设置。

■ match dscp:匹配IPv4 和IPv6 DSCP 值。

■ match fr-de:匹配FR 的DE（易丢弃）位。

■ match ip dscp:匹配IPv4 DSCP 值。

■ match ip precedence:匹配IPv4 IP 优先级值。

■ match mpls experimental:匹配MPLS EXP（实验）位。

■ match precedence:匹配IPv4 和IPv6 优先级值。

■ 数据包属性、特征或字段值

■ match access-group:匹配一个访问控制列表（ACL）。

■ match class-map:匹配另一个class map 中的match 语句。

■ match field:匹配PHDF（协议头部描述文件）中的一个字段。

■ match flow pdp:匹配一个PDP（数据包数据协议）流。

■ match group-object:匹配源和目的安全组中的一个用户。

■ match packet length:匹配IP 头部中的L3 数据包长度。

■ match qos-group:匹配一个QoS 组的值。

■ match start:匹配头部中从一个指定位置开始的值。

■ match tag:匹配头部的一个标记（tag）类型。

■ 协议

■ match application:匹配元数据应用值。

■ match atm:匹配ATM 控制流量。

■ match protocol:匹配NBAR（基于网络的应用识别）协议。

■ 地址信息

■ match destination-address:匹配目的MAC 地址。

■ match source-address:匹配源MAC 地址。

■ 逻辑或物理接口

■ match atm-vci:匹配一条ATM 虚电路。

■ match fr-dlci:匹配一条FR 虚电路。

■ match input vlan:匹配从一个指定VLAN 进入设备的数据包。

■ match input-interface:匹配从一个指定接口进入设备的数据包。

■ match vlan:匹配一个VLAN 的所有流量。

■ 端口

■ match ip rtp:匹配一个RTP 端口的流量。

■ match port-type:匹配路由端口或交换端口。

在模块化QoS命令行界面（MQC）的语法结构中，管理员可以将多个匹配标准组合起来使用，以定义出一个流量类别。根据管理员的需求，定义出的流量既可以是匹配全部标准（AND）的流量，也可以是匹配任一标准（OR）的流量，如例3-4所示。

例3-4 match-any与match-all的示例

Router# show run

class-map match-any TRAFFICTYPE1

match <criteria1>

match <criteria2>

class-map match-all TRAFFICTYPE2

match <criteria3>

match <criteria4>

class-map TRAFFICTYPE3

match not <criteria5>

class-map DETAILS

match <criteria6>

class-map HIGHER-LEVEL

match class-map DETAILS

match <criteria7>

在这个例子中，class TRAFFICTYPE1定义了一个能够匹配标准1（criteria 1）或标准2（criteria 2）其中之一，或同时匹配这两个标准的数据包类型。而class TRAFFICTYPE2定义的则是能够同时匹配标准3（criteria 3）或标准4（criteria 4）这两个标准的数据包类型。如果管理员在定义class map时没有指定关键字为match-any或match-all，那么默认的匹配方式为match-all。

对于自身包含了多个数值的match 语句（如例2-2 中的match dscp af21 af22 af23），数据包只有匹配其中的一个数值，才能满足这个匹配语句的条件，并进而满足这个类的匹配标准。

此外，管理员也可以顶一种类，它不匹配任一标准。如例3-4 中的class TRAFFICTYPE3就定义了这样一个数据包类——除了匹配标准5（criteria 5）的数据包之外，其他所有数据包都满足这种类型的定义。

管理员可以将一种此前定义的流量类型作为一项匹配标准，置于另一个流量类型之中。例3-4中所示的类HIGHER-LEVEL就包含了其子类DETAILS中匹配的流量。

3.2.2 基于网络的应用识别

NBAR 是一种在class map 中通过match protocol 语句触发的L4-L7 深度数据包监控分类机制。这种技术占用的CPU资源，要明显多于通过标记（DSCP）、地址或ACL区分流量所占用的资源。

虽然大多数数据应用都可以采用L3或L4标准（如独立的IP地址或公共TCP/UDP端口号）进行分类，但并非所有应用都是如此。例如，有些点到点的媒体共享应用会为了穿越防火墙，而故意使用动态端口来协商建立会话。

当L3或L4参数并不足以将一个应用区分出来之时，NBAR可以通过查看无状态协议的数据负载来识别数据包，并将数据包与PDLM（协议描述语言模块，一种应用签名）进行对照，来识别应用层的协议。PDLM 的定义是模块化的，管理员无需更新Cisco IOS 的版本就可以将新的定义添加到系统当中。

例3-5所示为NBAR提供的两种操作模式。

■ 被动模式（Passive mode）:以接口或协议为单位，发现并记录实时的统计数据，可以提供双向的统计数据，如比特率（bit/s）、数据包的数量，以及字节数。

■ 主动模式（Active mode）:为了标记流量并有针对性地应用QoS策略，而对应用进行分类。

例3-5 NBAR示例

! NBAR used in application discovery mode

Router# show run

interface fastethernet 0/0

ip nbar protocol-discovery

! NBAR used as a classifier

Router# show run

class-map match-any MY-VIDEO

match protocol cuseeme

match protocol h323

match protocol rtp video

NBAR2（NBAR这一工具的最新版本）可以对大量无状态和状态化的协议进行分类，包括那些既非TCP也非UDP的IP协议、使用静态或动态分配的TCP和UDP端口号的协议，以及使用动态分配的TCP和UDP端口号和子端口分类的协议。

NBAR协议

Cisco产品公告627831（NBAR2协议大全）提供了完整的协议列表（http://cisco.com/go/qos > Network Based Application Recognition (NBAR) > Data Sheets and Literature > Bulletins）。

总的来说，NBAR可以监控以下几类协议。

■ 信息浏览协议（如HTTP和Gopher）。

■ 业务与商业协议（如Citrix和ClearCase）。

■ 邮件协议（如IMAP[互联网消息访问协议]和MAPI[邮件撰写应用程序接口]）。

■ 文件共享协议（如CIFS[网络文件共享系统]和FTP[文件传输协议]）。

■ 游戏协议（如Doom）。

■ 工业协议（如DICOM和OPC-Job-Start）。

■ 即时消息协议（如gTalk和ICQ）。

■ 互联网隐私协议（如IPSec和SSL[安全套接字层]）。

■ 跨越IP的3层协议（如Argus和AX25）。

■ 网络管理协议（如sshell和SunRPC）。

■ 语音和视频协议（如appleqtc和CoolTalk）。

例3-6所示为一些NBAR分类配置的CLI命令。

例3-6 NBAR示例

Router# show run

class-map match-any ERP

match protocol sqlnet

match protocol ftp

match protocol telnet

class-map match-any AUDIO-VIDEO

match protocol http mime "*/audio/*"

match protocol http mime "*/video/*"

class-map match-any WEB-IMAGES

match protocol http url "*.gif"

match protocol http url "*.jpg|*.jpeg"

例3-6定义了3个class map。第1个class map是ERP，这个class map会让分类技术（NBAR）从后面语句中定义的协议中找出相应的流量。在class map AUDIO-VIDEO 中，NBAR 寻找的是一些特殊类型的MIME流量——在这个示例中，即音频和视频类型的MIME流量。而class map WEB-IMAGES 的作用是将HTTP 流量中的图片内容（GIP 或JPEG）提取出来。

RTP流量

分类语音和视频流量的方式往往不像深度数据包协议监控那么复杂。在必要时，NBAR也可以用来对这些流量进行分类。比如，命令match protocol h123 可以识别出所有H.323 语音流量。当管理员需要根据编解码器的类型来分类流量时，就可以使用命令match protocol rtp[ audio | video | payload-type payload-string ] 来根据实时传输协议（RTP）的负载值对流量进行分类。关键字audio会匹配RTP负载类型值为0-23的流量，而关键字video可以匹配值24-33的流量，关键字payload-type可以匹配某些特定的二进制、十进制和十六进制值，以对流量进行更具体的匹配和控制。

性能路由

性能路由（PfR，Performance Routing）也可以与NBAR 结合在一起使用，以对流量进行分类，并为PfR描述某一种应用的特征，如例3-7所示。通过这种方式得到的流量类型会被添加到PfR应用数据库中，以便设备对这些流量进行被动监测或主动监测。

例3-7 PfR与NBAR的示例

Router# show run

ip prefix-list LIST1 permit 10.2.1.0/24

ip prefix-list LIST1 permit 10.2.2.0/24

ip prefix-list LIST1 permit 172.17.1.0/24

pfr-map APP_NBAR_MAP 10

match traffic-class application nbar rtp-audio prefix-list LIST1

元数据分类

有一种新的深度数据包监控功能可以根据某些应用（特别是视频应用）插入到数据包中的元数据（Metadata）来对流量进行分类。元数据可以理解为“关于数据的数据”。在QoS的语境中，元数据是指添加到数据包中，用以描述其余数据包内容的数据或类型信息。（如果信任这类信息的话）可以使用数据包中的元数据来对流量进行分类。

3.3 标记工具

在对流量进行标记时，需要在数据帧或数据包头部写入一个数值，以记录设备（通过分类）所判断出的该数据包所属流量的类型。标记和分类结合在一起，可以确保数据包不会在沿途的每个节点都由设备重新进行重分类。一旦数据包在网络的信任边界进行了分类和标记，后续的节点就可以完全按照数据包的标记对其进行处理了（前提是后面节点都被配置为信任这些标记，如果不信任，这些节点会将数据包重标记为DSCP 0）。

主要的标记工具是基于类的标记，或者将标记作为基于类的策略中的一部分。经典的标记方式包括CAR（承诺访问速率）和PBR（策略路由）。

在Cisco语音和视频产品中，标记往往是由终端产品（例如由IP电话、语音网关和TelePresence设备）来执行的。终端设备标记往往不会受到信任，这是因为终端用户可以访问这些终端设备，因此从这些设备发送出来的流量会在网络的信任边界重新进行标记。不过，网关管理员所控制的设备（比如语音网关）往往会部署在网络的信任边界之内，而这些网关设备所执行的终端设备标记一般也会得到信任。此外，如果一台终端设备所应用的标记是在管理员的操作下由服务器或管理应用集中进行控制和下载的，那么这台终端设备也是可以被是为一台“可靠”设备（并处于信任边界之内）的。

3.3.1 基于类的标记（class map）

在MQC 的语法结构中，标记数据包需要通过class map 命令来实现，这一点在第2章已经进行了介绍。具体而言，class map 中的set 命令就可以用来对数据包进行标记。例3-8 显示了通用的语法命令。

例3-8 set命令的示例

Router(config)# policy-map CB-MARKING

Router(config-pmap)# class FOO

Router(config-pmap-c)# set ?

atm-clp　　Set ATM CLP bit to 1

cos　　　Set IEEE 802.1Q/ISL class of service

dscp　　Set DSCP in IP(v4)and IPv6 packets

mpls　　Set MPLS specific values

precedence　Set precedence in IP(v4) and IPv6 packets

qos-group　Set QoS Group

总的来说，set命令可以控制下列类型的标记，也即在数据帧和数据包头部字段写入管理员所需的数值。

■ ToS值

■ set cos

■ set dscp

■ set dscp cos

■ set dscp qos-group

■ set precedence

■ set qos-group

■ 数据包丢弃资格

■ set atm-clp

■ set fr-de

■ 隧道ToS值

■ set cos inner

■ set discard-class

■ set dscp tunnel

■ set precedence tunnel

■ set ip dscp tunnel

■ set ip precedence tunnel

■ set mpls experimental

■ set vlan-inner

注释:命令set dscp可以应用于IPv4和IPv6数据包，但命令set ip dscp只能应用于IPv4数据包。在大多数情况下，管理员都应该使用set dscp和set precedence这类格式的命令。

特性排序的影响

基于类的标记会在设备对数据包进行分类之后执行（换言之，set命令会在设备执行匹配之后才被应用）。因此，如果将数据包标记的策略应用于出站方向上，那么虽然下一个节点的设备可以使用这个标记来对数据包进行分类，但是这个节点却无法使用标记对数据包进行分类。不过，如果将基于类的标记作为一个入方向的策略应用在入站接口，那么执行标记的这台设备本身就也可以在出站接口上使用数据包上所携带的标记为其执行分类了。

在出站策略上，分类和标记都可以根据需要，在隧道封装之前或者在隧道封装之后执行，具体何时执行取决于管理员在哪里应用了service policy。如果将策略应用在了一个GRE 或IPSec隧道接口上，标记就会被应用在内层原数据包的头部上。但若将策略应用在物理接口上，那么设备就只会对隧道头部进行标记，而内部的数据包头部则不会有任何的变化。

使用Table Map特性对标记进行映射

CLI命令set也可以用来对下列几种不同的QoS标记进行转换:

■ CoS；

■ IPP；

■ DSCP；

■ QoS组；

■ MPLS EXP。

管理员可以使用CLI命令table-map来建立一个转换表，然后使用set命令调用这个表，对标记进行转换，如例3-9 所示。在这个示例中，DSCP 值会根据映射表（table map）map1 中定义的CoS值进行设置。一切没有在“to-from”关系中明确进行定义的数值都会被设置为默认值。如果管理员没有在表中设置默认值，那么设备就不会更改数据包头部的数值。

例3-9 映射QoS值

Router# show run

table-map MAP1

map from 0 to 0

map from 2 to 1

default 3

!

policy-map POLICY1

class traffic1

set dscp cos table MAP1

例3-10显示了很多使用映射表特性来转换不同类型数据包标记的set命令。

例3-10 映射表特性的示例

set precedence cos table TABLE-MAP-NAME

set dscp cos table TABLE-MAP-NAME

set cos precedence table TABLE-MAP-NAME

set cos dscp table TABLE-MAP-NAME

set qos-group precedence table TABLE-MAP-NAME

set qos-group dscp table TABLE-MAP-NAME

set mpls experimental topmost qos-group table TABLE-MAP-NAME

set mpls experimental topmost precedence table TABLE-MAP-NAME

set mpls experimental imposition dscp table TABLE-MAP-NAME

set qos-group mpls exp topmost table TABLE-MAP-NAME

set precedence qos-group table TABLE-MAP-NAME

set dscp qos-group table TABLE-MAP-NAME

3.3.2 标记（或重标记）与限速联用

限速（policing[1]）及其他速率限制工具（将在本书的第4章讲解）可以提供另一种标记数据包的方式。这种方式不会对整个类型流量中所有的数据包都标记上某个数值，限速一般只会对违反某个速率或服务级别协议（SLA）的数据包进行重标记。

基于类的限速可以根据速率测量的结果，为数据包设置不同的标记字段（包括IP优先级字段、DSCP 和MPLS EXP），如例3-11 所示。

例3-11 为基于类的限速器进行重标记的几种选择

Router(config)# policy-map CB-POLICING

Router(config-pmap)# class FOO

Router(config-pmap-c)# police 8000 conform-action ?

drop　　　　drop packet

exceed-action　　action when rate is within conform and conform + exceed burst

set-clp-transmit　　　set atm clp and send it

set-discard-class-transmit　set discard-class and send it

set-dscp-transmit　　　set dscp and send it

set-frde-transmit　　　set FR DE and send it

set-mpls-exp-imposition-transmit　set exp at tag imposition and send it

set-mpls-exp-topmost-transmit　set exp on topmost label and send it

set-prec-transmit　　　rewrite packet precedence and send it

set-qos-transmit　　　set qos-group and send it

transmit　　　　　transmit packet

3.3.3 AutoQoS标记

AutoQoS Enterprise（已经在2.4 节中进行了介绍）可以自动标记流量的类型。表3-5 所示为默认的AutoQoS标记值，当然，管理员可以修改这些参数。

表3-5 AutoQoS Enterprise流量类型标记值

3.4 建议与指导

在网络中对流量进行分类和标记时，可以参考下列推荐做法与指导方针。

■ 在技术条件和管理条件均可行的前提下，在尽可能靠近源的位置对流量进行分类和标记。

■ 分类和标记既可以在入站方向上使用，也可以在出站方向上使用。但其他QoS策略（如队列技术）则往往会在出站方向上使用。

■ 使用端到端的差分服务PHB模型来标记网络中的数据包。

■ 在技术条件和管理条件均可行的前提下，在尽可能靠近源的位置将准确度不高的标记字段（如只有3 比特位的Ethernet CoS 和MPLS 字段）转换为6 比特位的DSCP 值。

■ 设置一个信任边界，并对从信任边界之外（通常是从那些终端用户可以访问的不可靠设备和终端）发送到网络的流量进行标记或重标记。

■ 使用基于标准的差分服务PHB标记方式，以确保自己的网络在其他服务提供商网络和其他企业网络之间进行连接或融合时，能够实现互操作。

■ 尽量使用set dscp 和set precedence（可以对所有IP 流量进行标记）命令，而不要使用set ip dscp 和set ip precedence 命令（只能对IPv4 流量进行标记）进行配置。

■ 在使用隧道接口时，要考虑到设备执行各个特性的次序，这样才能确保数据包内部和外部的头部能够按照自己所设定的方式进行标记。

3.5 小结

本章对分类和标记的特性与工具进行了解读。其中，分类是一种通过监控数据包（数据包中的某些字段）来判断该数据包属于哪种类型的行为。判断的结果会指导节点和网络处理这些数据包（以及同一类型流量中的其他数据包）的方式。

标记是指修改数据包头部中的某个字段，以记录分类器分类结果的行为。本章介绍了多种在L2和L3，乃至L7对数据包进行标记的方式，同时还讨论了将一种标记类型转换为另一种标记类型的方法。

（根据分配和标记的结果）处理数据包的方式包括限速、整形以及队列等功能。其中，限速和整形将在第4章中进行讨论，而队列技术则会在第5章中进行介绍。

3.6 扩展阅读

3.6.1 分类和标记

Enterprise QoS Solution Reference Network Design Guide (3.0) Overview（企业QoS解决方案参考网络设计指南[3.0] 概述）:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/QoSIntro.html#wp46124

Enterprise Medianet Quality of Service Design 4.0 Overview（企业媒体网服务质量设计4.0概述）:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSIntro_40.html#wp60933

Classification Configuration Guide（分类配置指南）:http://www.cisco.com/en/US/docs/ios-xml/ios/qos_classn/configuration/15-0m/qos-classn-15-0m-book.html

Classification of Locally Sourced Packets（本地始发数据包的分类）:http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/12sclocp.html

Marking（标记）:http://www.cisco.com/en/US/docs/ios-xml/ios/qos_classn/configuration/15-0m/qos-classn-mrkg-ntwk-trfc.html

Class-Based Marking（基于类的标记）:http://www.cisco.com/en/US/docs/ios/12_1t/12_1t5/feature/guide/cbpmark2.html

Implementing Quality of Service Policies with DSCP（使用DSCP来实施服务质量策略）:http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a00800949f2.shtml

Classification, Policing, and Marking on LAC (L2TPAccess Concentrator)（在LAC[L2TP访问集中器]上的分类、限速与标记）:http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/qos_on_lac_ps6350_TSD_Products_Configuration_Guide_Chapter.html

3.6.2 NBAR

General NBAR information（NBAR通用信息）:http://www.cisco.com/en/US/products/ps6616/products_ ios_protocol_group_home.html

NBAR white papers（NBAR白皮书）:http://www.cisco.com/en/US/products/ps6616/prod_white_papers_list.html

NBAR Configuration Guide（NBAR配置指南）:http://www.cisco.com/en/US/docs/ios-xml/ios/qos_nbar/configuration/15-0m/qos-nbar-15-0m-book.html

NBAR2 Frequently Asked Questions(FAQ)（NBAR2常见问题）:http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6558/ps6616/qa_c67-697963.html

NBAR2 Protocol Library（NBAR2协议大全）(Cisco Product Bulletin 627831):http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6558/ps6616/product_bulletin_c25-627831.html

3.6.3 视频QoS

QoS Requirements of Video（视频的QoS需求）:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/QoSIntro.html#wp46626

3.6.4 无线QoS

Cisco Unified Wireless QoS（Cisco统一无线QoS）:http://www.cisco.com/en/US/docs/solutions/Enterprise/ Mobility/emob41dg/ch5_QoS.html

3.6.5 RFC

RFC 3378:EtherIP:Tunneling Ethernet Frames in IP Datagrams

RFC 5415:Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification

RFC 5416:Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11

第4章 限速、整形和降级工具

本章涵盖了下列主题:

■（与限速、整形及降级工具有关的）术语、推荐做法与区别；

■ 限速工具与机制；

■ 整形工具与机制；

■ 高级限速工具（比如单速率、双向速率、三色限速器；以及分层的、多种策略的、可以识别标色的、基于百分比的限速器）。

实施服务质量（QoS）策略有一个重要的步骤，那就是对要采取某些行为的流量进行分析和识别。本书已经在第3章中介绍了如何将流量划分进不同的类别中，然后才通过标记的方式将分类记录下来。QoS的下一项任务就是为这些类型的流量分配处理动作或处理策略，其中包括为它们分配带宽，对它们进行限速、整形、执行队列或丢弃处理等。

本章会对限速和整形工具进行介绍，同时也会多少涉及一些丢弃的机制。而本书的第5章则会对丢弃机制进行深入的介绍。

4.1 限速和整形

在深入介绍具体的限速和整形工具之前，读者必须了解下列关于限速和整形的内容:

■ 限速与整形的术语；

■ 尾部丢弃与随机丢弃；

■ 安全与QoS。

4.1.1 限速与整形的术语

限速器（Policer）和整形器（Shaper）的作用是识别出流量的违约情况（violation），并对此作出响应。限速器和整形器往往都是以相同的方式来识别流量违约的。但它们对于违约所作出的响应却并不相同。

■ 限速器会按照配置的速率校验流量是否出现了违约的情况，当违约发生时立刻采取预定动作（如对超速的流量进行丢弃或重标记）。限速器不会推迟流量，它只会对流量进行校验并采取相应的策略。

■ 整形器是可以与缓冲机制结合起来使用的工具，其作用是使流量变得较为平滑。整形器的目的不是丢弃流量，而是以平滑的方式将流量高峰发送出去，使流量的峰值速率不会超越配置的速率。整形器通常用来满足服务级协议（SLA）。如果出现的流量瞬间超过了预定速率，超出部分的流量就被缓存起来，直到流量抵达的速率再次低于预定速率，再对其进行发送。但若流量抵达的速率低于预定速率，流量就会立刻得到发送。

图4-1所示为限速和整形之间的差异。这两种机制都会检测流量是否违反给定的流量速率，因此它们都可以归类为速率限制工具，它们的区别在于它们对超量流量的处理方式不同。

图4-1 限速与整形的比较

表4-1对限速和整形工具的特性进行了比较。

表4-1 限速器和整形器之间的比较

续表

1.在网络中安置限速器和整形器

由于限速器可以即时作出发送/丢包的判断，因此限速器往往会部署在入站方向上；通过这种方式，如果有些数据包需要丢弃，那么这些数据包可以在浪费掉设备的路由与处理资源之前就被丢弃掉。不过，限速策略有时也会部署在出站方向上，以控制某一类流量对带宽的占用比例（或为某一类流量分配带宽），因为设备无法在数据包到达出站接口之前对相关流量执行这种处理。

而整形器则会通过缓存的方式，将高峰流量在事后以平滑的方式进行发送。因此整形器往往只会作为一种出站工具使用。整形器多用于企业与服务提供商之间的链路上（即企业的出站方向），以确保去往服务提供商的流量不会超过预定的速率。因为一旦去往SP的流量超越了预定的速率，SP（部署在入站方向上）的限速器就会丢弃掉这些流量，以确保企业流量只占用了服务协议规定的速率。在这种环境中，限速器会同时作用于入站流量和出站流量。因为对于服务提供商而言，这是确保位于SP设备（提供商端）与客户设备（企业端）之间的直连链路上，流量速率符合标准的最简单的方法。

2.尾部丢弃和随机丢弃

丢弃数据包有两种主要的方式:尾部丢弃和随机丢弃。

限速器会执行尾部丢弃，即所有超过指定速率的数据包都会被丢弃，直到流量速率降低到指定速率以下。整形器则尽量不去丢弃数据包，但是如果流量长时间超过给定速率导致缓冲溢出，整形器也会采用尾部丢弃的方式丢弃数据包。

尾部丢弃的作法在处理TCP重传流量时会出现不良的效果，使得网络中出现一波又一波的流量峰值。而丢弃数据包还有一种机制，叫作随机丢弃（如随机早期检测[RED]与加权早期检测[WRED]使用的就是这种机制）。对于TCP重传流量而言，这种技术的效率更高，但这种机制并不属于限速/整形工具。RED和WRED将在第5章中进行具体的介绍。

3.重标记/降级

当流量超过了指定的速率，限速器可以采取下列两种行动之一:

■ 丢弃流量；

■ 将这类流量打上另一种服务类型的标签，这种类型流量遭到丢弃的几率往往更高。

在一切有可能的情况下，重标记（或曰降级）都会参照标准的RFC 2597（AF PHB组）来执行。比如，超出速率的流量如果在到达时的标记为AFx1，那么这类流量就有可能被标记为AFx2（如果支持双向限速，那么根据RFC 2698 的定义，这类流量则会被标记为AFx3）。为此，拥塞管理策略（如基于差分服务代码点的WRED）应该与降级的策略相配合，让设备丢弃的AFx3比AFx2流量更多，丢弃的AFx2流量比AFx1流量更多。

4.限速和整形的流量类型

通过限速（丢弃）和整形（推迟发送）的方式对实时流量（如视频和语音流量）进行管制多半会产生事与愿违的效果。在这种环境中，应该通过呼叫准入控制（CAC）来防止实时流量的速率超过网络的承载能力。而限速和整形工具则最适合用来管理基于TCP的数据流量。

4.1.2 令牌桶算法

Cisco IOS 限速器和整形器都是以令牌桶算法为模型设计出来的，虽然它们的处理方式并未完全照搬令牌桶的做法。不同的令牌桶算法在不同Cisco平台上的工作方式很难用一句话进行概括。因为在不同的产品和不同的系统版本上，令牌桶有很多不同的具体实现方式。

令牌桶算法是一种测量引擎，它会对流量进行跟踪，以便了解要想不突破指定的流量速率，还能发送多少流量。一个令牌代表可以发送1个比特位（通常为1个比特位，但有时也可以是1字节）的流量。某个时间增量开始时，设备就会根据指定的速率（称为承诺信息速率[CIR]）获得一些数量的令牌（这个时间增量通常是每秒）。CIR即是与服务提供商签订的SLA协议中所规定的访问比特速率。

举例来说，如果将CIR设置为8000bit/s，那么每个时间周期开始时，就会有8000个令牌被注入到“桶”中。每当限速器接收到1个比特位的流量时，它就会查看桶中的令牌。如果桶里有令牌，这个流量就会被视为是符合设定的速率，该流量一般就会得到放行。每当流量中有1比特的数据得到放行，令牌桶中就会有一个令牌被移除出去。而当桶里没有令牌后，所有到达的流量都被视作超出速率，此时设备就会执行超速的策略，这类策略一般是对流量进行重标记或丢弃。

注意:到每秒的最后，都可能还有一些未被使用的令牌。处理未用令牌的方式是限速器之间的关键区别。这一点将在本章后面的4.1.3节中进行讨论。

因为不能通过更改接口时钟速率来实现CIR策略，能够对接口施加速率限制的唯一方法就是使用时分多路复用（TDM）的方式。如果采用TDM，在对某个接口实施速率限制（或CIR）时，受限制的流量就会分配到一个亚秒级时间片，而流量可以在这个时间片中进行发送。亚秒级时间片也可以称为间隔（或Tc）。例如，如果一个64kbit/s的链路上实施了8kbit/s的CIR，流量就可以以125毫秒（64000bit/s/8000bit）的间隔进行发送。

从理论上讲，CIR限定的总量（8000比特）可以一次性地发送出去，但此时（为了满足速率限制的规定），在设备能够发送其他数据之前必须等待875毫秒，而这会产生过量的延迟。因此，为了将每秒流出的流量以平滑的方式发送出去，可以将CIR分成更小的单位，这些单位称为承诺突发（Bc），即每个Tc间隔可以持续发送的比特位数。这些更小的单位会在1秒中以多个实例的形式进行发送。还以前文中的数据为例，如果将Bc设置为1000，那么在时钟速率下，每个Bc 只用15.6 ms（1000bit/s/64000bit）就可以将流量从接口发送出去。该算法会等待109.4ms（125ms-15.6ms），然后再用15.6ms来发送另一组数据（1000比特）。这个过程每秒会重复8次。Bc值为1000（因此Tc为125ms）的数据传输“突发”示意图，如图4-2底部所示。

1500字节的数据包或数据帧中包含12000（1500*8）比特的数量。如果每个时间片（在本例中，Tc值为125ms）可以发送1000比特（Bc值）的数据，那么把所有数据发送出去需要花12个时间片的时间。每个时间片为125ms，因此发送所有的数据需要花1.5秒的时间（在线速传输速率下，每次发送100比特的小突发数据）。

因此，令牌桶算法可以描述如下:Bc=CIR*Tc（比特数=速率*时间）

Cisco IOS 软件不支持直接对间隔时间（Tc）进行定义，而是将CIR 和Bc 作为可以进行定义的参数，间隔和每秒的突发量可以根据这两个参数计算得出。例如，如果CIR是8000，而Bc被设置为4000，那么每秒就会产生两个突发（Tc=500ms）。将Bc值设置为4000所得到的传输状态如图4-2中间所示。如果将Bc设置为2000，那么每秒就会产生4个突发（Tc=250ms）。如果将Bc设置为1000，每秒就会产生8个突发（Tc=125ms）。将Bc值设置为8000所得到的传输状态如图4-2顶部所示。

图4-2 令牌桶算法

上面的例子从理论的角度阐述了这个特性的工作方式。从实际操作的角度来说，在实施网络时，Tc不应超过125ms。配置成较短的间隔对限制实时流量的抖动非常必要，对于大部分网络而言，间隔不应配置得过长，因为这会导致数据包与数据包之间的延迟时间过大。

4.1.3 限速器类型

限速算法有很多不同的变体，其中包括:

■ 单速率双色；

■ 单速率三色；

■ 双速率三色。

1.单速率双色限速器

最早期的限速器使用的是一种单速率、双色的模型，其中包括:

■ 单速率单令牌桶算法；

■ 所有流量都会被分类为两种状态（或颜色）之一:符合CIR或超出CIR。设备会对于不同状态的流量，执行标记或丢弃的策略。

这种类型的限速器相当简单，其工作方式如图4-1上半部分所示。

2.RFC 2697单速率三色限速器

RFC 2697 对单速率双色限速器进行了改善，该RFC 文档详细描述了单速率三色模型的工作方式，其中包括:

■ 单速率双令牌桶算法；

■ 所有流量都会被分类为三种状态（或颜色）之一:符合CIR、超出CIR或违反CIR。设备会对于不同状态的流量，执行标记或丢弃的策略。

第一个令牌桶的工作方式与单速率双色系统的工作方式别无二致。但如果每个时间间隔后，令牌桶中还有剩余的令牌，这些令牌会被放入第二令牌桶中，如果出现超出CIR的临时突发流量，这些流量便会使用这些令牌。放在第二个令牌桶中的令牌成为超量突发（Be），在Bc未满的情况下，这些令牌会保留在令牌桶中。Be是流量可以超越Bc突发值的最大比特数量。

这个双令牌桶机制可以将流量标记为如下三种不同的状态（或三种颜色）。

■ 符合:CIR之内的流量——通常会得到发送（也可以对其进行重标记）。

■ 超出:超出CIR的范畴，但仍在超量突发范围之内的流量——可以对这类流量进行丢弃、重标记或发送处理。

■ 违反:超出超量突发范围的流量——一般会被丢弃（也可以对其执行重标记或传输处理）。

单速率三色标记器/限速器使用了下列参数对流量进行测量。

■ CIR:承诺信息速率，也是限速的速率。

■ CBS:承诺突发值，第一个令牌桶的最大容量。

■ EBS:过量突发值，第二个令牌桶的最大容量。

■ Tc:CBS的令牌数量，留在CBS桶中令牌的瞬间数量（不要将这里的Tc与前面限速或整形流量间隔中使用的术语Tc相混淆）。

■ Te:EBS的令牌数量，留在EBS桶中的令牌瞬间数量。

■ B:接收到的数据包字节数。

图4-3说明了单速率三色标记器/限速器（双令牌桶）算法的逻辑流程。

图4-3 RFC 2697单速率三色限速器的逻辑

单速率三色限速器允许流量中出现一定的临时突发数据，而这会让网络中的TCP重传数据变得相对较少，因此单速率三色限速器可以提高带宽利用率。此外，这种限速器也非常适合依照RFC 2597 的AF 类对流量进行标记，因为3 种不同的颜色（或丢弃优先级）正好可以对应AF的各类（AFx1、AFx2和AFx3）。当然，只有为每种颜色采取的策略都各不相同，使用三色的限速器才有意义。如果准备为两种或两种以上的颜色采取相同的策略，那么就不妨采用更简单的限速器（使用的QoS策略自然也就更加简单），这样就可以简化网络的维护工作。

3.RFC 2698双速率三色限速器

单速率三色标记器/限速器是限速器发展过程中的一项显著的进步——只要总的平均传输速率不高于CIR规定的速率，这种机制就可以允许设备转发临时的突发流量。不过，由于流量积累下来的超量突发信用量（excess burst credit）并不固定，因此这种机制有可能会在一定程度上导致流量变得不可预测。为了改进这一弊端，RFC 2698定义了一种双速率三色标记器/限速器。这种限速器解决了高峰信息速率（PIR）的问题，而PIR在RFC 2697模型中是无法预测的。此外，双速率三色标记器/限速器可以持续地转发超量突发流量（因为这种限速器不需要为处理临时突发流量而积累信用量），而且可以对于超出不同突发值的流量采取不同的策略。

这种双速率三色标记器/限速器使用了下列参数对流量进行测量。

■ PIR:高峰信息速率，流量可以转发的最高速率。

■ PBS:高峰突发值，第一个令牌桶的最大容量。

■ CIR:承诺信息速率，也是限速的速率。

■ CBS:承诺突发值，第一个令牌桶的最大容量。

■ Tp:PBS的令牌数量，留在CBS桶中令牌的瞬间数量。

■ Tc:CBS的令牌数量，留在CBS桶中令牌的瞬间数量。

■ B:接收到的数据包字节数。

双速率三色限速器也使用了一种双令牌桶的算法，但它的算法与单速率的算法略有不同。这种算法不会将没有使用的令牌从一个桶转移到另一个桶中，而是使用两个相互独立的桶，同时每秒以不同的速率向这两个桶中填充令牌。第一个桶中装入的是PIR令牌，而第二个桶中装入的则是CIR令牌。在这个模型中，Be的工作方式与Bc相同，只不过Be是PBS桶（而不是CBS桶）的参数。也就是说，Be代表的是在一个亚秒的时间间隔内，可以发送的流量高峰限制。

在流量的处理逻辑方面，双速率三色限速器与单速率限速器的差异较大，因为设备会首先校验流量的速率是否在PIR之内，然后才会将流量速率与CIR相比较。换言之，违反条件是第一个进行校验的条件，然后校验超出条件，最后才是符合条件，这一顺序与前一种限速器的顺序正好相反。图4-4显示了这种限速器的校验逻辑。

图4-4 RFC 2698双速率三色限速器的逻辑

4.1.4 安全和QoS

QoS限速器不仅可以用来实现的传统QoS策略，它还可以实现其他的功能。例如，QoS限速器也可以提升网络的安全水准。使用限速器提升网络安全性的方法包括通过限速器来缓解拒绝服务攻击和网络蠕虫的攻击。DoS攻击的目的是在网络中泛洪无用流量。蠕虫攻击的目标往往不是网络的基础设施本身，但由于蠕虫可以大量自我复制，因此这种攻击方式可以导致网络中产生过量的流量。

因此，QoS策略可以提升网络基础设施的安全性，因为QoS可以通过应用的特征来判断哪些流量是正常的，哪些流量则为异常。通过门限值区分正常/异常的数据流有很多不同的标准，即使是合法流量有时也会临时超出流量的门限值。但是，在系统为合法流量提供了服务之后，由多个主机同时生成的大量异常数据（这是DoS/蠕虫攻击的典型特征）应该立即进行丢弃。然后，在了解了这类流量的特征之后，网络边缘的限速器就可以对所有的流量进行测量，并将异常流量划分进清道夫（Scavenger，DSCP CS1）类型之中。最后，为了给这些重新标记的流量制定一个完整的策略，应该在整个网络范围内，为这类“优先级低于尽力而为”的清道夫类流量部署专门的队列策略。

另一种与安全技术有关的限速器使用方式称为控制层面限速（CoPP）。CoPP这一特性的作用是对发往交换机/路由器主CPU的流量执行速率限制。这种CoPP限速器可以保护交换机/路由器的控制层面，使其免遭DoS攻击和网络侦查的侵扰。

使用QoS限速器来提升网络基础设施安全性的方法将在第10章中进行深入的介绍。

4.2 限速工具

限速算法有很多种变体，这一点我们刚刚在4.1.3节中进行了介绍。但所有这些算法都会将流量分为下列几个类型，然后再为每一类分配一种独立的策略。可供选择的策略包括发送、重标记后再发送，以及丢弃。

■ 符合:流量速率在配置的速率范围之内。

■ 超出:流量速率超出了管理员配置的速率，但仍在突发参数的范围之内。

■ 违反:流量速率同时超出了管理员配置的速率和突发参数所规定的范围。

4.2.1 以限速器作为标记器

如果为一个限速器配置的所有动作中都没有丢弃这项策略，那么限速器的工作就会变得和标记器毫无二致。在使用限速器对数据包进行重标记时毋须小心谨慎，把整个网络的策略铭记在心。在技术条件和管理条件均可行的前提下，流量通常会在尽可能靠近源的位置进行标记（如果信任源的话，可以在源设备直接进行标记；否则就应在网络信任边界对流量进行标记）。在这些地方，流量往往是由应用进行标记的（如标记为语音、呼叫信令、视频、高优先级数据等）。这可以理解为是一种纵向的流量分离方式。

但是，限速器并不具备应用识别的功能，它只能根据流量的速率对流量进行标记（如果配置命令要求限速器按照速率标记流量的话）。这种做法则可以理解为是一种横向的流量分离方式。限速器可以通过自己所在位置获得的流量特征，了解到关于应用的间接信息。但限速器本身是看不到流量的类型；它只能看到穿越自己的流量的速率。

4.2.2 基于类的限速（policy map）

基于类的限速是执行限速时推荐使用的工具。在MQC（模块化QoS命令行界面）的语法框架中，命令police 的作用是在一个policy map 内，为一个流量类别配置一种策略行为。如果没有使用关键字pir的话，那么系统就会使用单速率限速器。如果使用了关键字pir，系统则会使用双速率限速器。

单速率限速器的通用语法结构为:

police cir bps [ [ bc ] normal-burst-bytes [ maximum-burst-bytes |

[ be ] [ burst-bytes ] ]] [ conform-action action [ exceed-action action

[ violate-action action ]]]

双速率限速器的通用语法结构为:

police cir cir [ bc conform-burst ] [ pir pir ] [ be peak-burst ]

[ conform-action action [ exceed-action action [ violate-action

action ]]]

流量的CIR速率和PIR速率不仅可以通过绝对速率的方式来表示，也可以通过百分比的方式进行表示。例4-1所示为基于类的限速命令（police）的所有三种变体。

例4-1 基于类的限速

Router# show run

! Single-rate policer

policy-map POLICY1

class C1

police cir 1000000 conform-action transmit exceed-action drop

!

! Dual-rate policer

policy-map POLICY2

class C2

police cir 500000 bc 10000 pir 1000000 be 10000 conform-action

transmit exceed-action set-prec-transmit 2 violate-action drop

!

! Percentage-based policing

policy-map POLICY3

class C3

police cir percent 20 bc 300 ms be 400 ms pir percent 40

conform-action set-cos-inner-transmit 3

那些没有执行限速的流量会与该接口的所有其他流量竞争带宽。在没有拥塞的情况下，所有流量都可以得到传输。但一旦出现了拥塞，无论这一类流量是否被限速，它都会被接口丢包。因此，管理员最好明确配置限速器，这样系统才能根据管理员选择的优先级来执行丢包的策略。

可以对超出或违反限速策略的流量执行的策略可以总结为以下几项（其中有些关键字是某些特定平台专用的）。

■ drop

■ set-clp-transmit

■ set-cos-inner-transmit

■ set-cos-transmit

■ set-discard-class-transmit

■ set-dscp-transmit

■ set-dscp-tunnel-transmit

■ set-frde-transmit

■ set-mpls-experimental-imposition-transmit

■ set-mpls-experimental-topmost

■ set-mpls-experimental-topmost-transmit

■ set-prec-transmit

■ set-prec-tunnel-transmit

■ set-qos-transmit

■ transmit

其中，丢弃和传输是最基本的策略。（除了传输之外）另一种策略是重标记，总的来说，重标记与第3章中通过命令set来指定的标记策略没有什么区别。

1.多行为限速

有时，对于符合（或超出、或违反）限速规则的流量需要采取多种策略行为（比如，数据包可能需要在2层和3层都进行重标记）。例4-2显示了如何对超出限速规则和违反限速规则流量的（第3层的）DSCP和（第2层的）帧中继（FR）DE位同时进行标记。

例4-2 多行为限速

Router# show run

policy-map MULTIACTION-POLICER

class class-default

police cir 10000 pir 2000000

conform-action transmit

exceed-action set-dscp-transmit af32

exceed-action set-frde-transmit

violate-action set-dscp-transmit af33

violate-action set-frde-transmit

2.分层限速

对于有些应用而言，执行多层限速是很有好处的。例如，有时我们可能需要将所有TCP流量的速率限制在10Mbit/s之内，同时还要将FTP流量（也属于一种TCP流量）的速率限制在1.5 Mbit/s 之内。为了实现这个嵌套的限速需求，就可以使用分层限速的方式。

在分层结构中，第二级的限速器会对第一级限速器传输或重标记的数据包再执行一次处理。例4-3显示了这种套嵌策略的配置方法，在该实例中，限速策略分为了2层，分别对TCP和FTP流量执行限速。

例4-3 分层限速

Router# show run

policy-map FTP-POLICER

class FTP

police cir 1500000

conform-action transmit

exceed-action drop

!

policy-map TCP-POLICER

class TCP

police cir 10000000

conform-action transmit

exceed-action drop

service-policy FTP-POLICER

!

interface ge 1/1

service-policy output TCP-POLICER

3.基于百分比的限速

大部分网络都包含大量具有不同带宽的接口。如果管理员希望在整个网络中都部署一个整体策略的话（如FTP流量所占用的带宽不超过各接口带宽的10%），就可以采用基于百分比的带宽限制策略。

只有CIR和PIR值可以使用百分比指定，突发值则不能这样来指定。突发值需要以毫秒为单位进行配置。如果CIR是采用百分比的方式进行配置的，那么PIR也必须通过百分比来指定。在将服务策略（service policy）绑定到接口上之后，CIR（和 PIR，如果配置了的话）就将由接口带宽的百分比来决定。如果接口带宽出现了变化，那么CIR和PIR的值以及突发值将自动根据新接口带宽值重新进行计算。对于子接口，系统也会使用主接口的带宽进行计算。

如果在第二级或第三级策略中使用了百分比特性，那么较低级的策略语句带宽将由较高级（或父级）的配置决定。表4-2总结了这个决策的过程。

表4-2 基于百分比的CIR/PIR限速行为

4.基于多个类别限速

RFC 2697 和 RFC 2698 描述了三色的限速器，这种限速器可以将数据包标记为三种不同的颜色，标明其是否符合、超出或违反限速条件。这两个RFC定义了限速器的两种工作模式。

■ 一种是色盲模式，在这种模式下，限速器会认为数据包是没有事先进行过标记的。

■ 一种是可识别颜色的模式，在这种模式下，限速器会看到前面的实体为数据包打上的标记。

表4-3对比了双速率限速器是如何在色盲模式和可识别颜色的模式下进行工作的。在该表中，数据包的字节数是以pkt-length（数据包长度）为单位的。

表4-3 双速率限速器的色盲限速模式和颜色觉察模式

5.低延迟队列的限速

队列工具将在第5章中进行介绍，但是在这里，我们很有必要先介绍一下LLQ机制（这种队列机制需要在MQC中通过关键字priority来启用），这种机制包含了一个隐式的限速器。为了减少延迟，LLQ会为实时流量提供一个严格的高优先级，为此，这种队列机制有可能会“饿死”较低优先级的流量。同时，为了避免出现较低优先级的流量得不到传输，LLQ机制可以通过尾部丢弃的方式，丢弃那些超出了管理员配置速率的流量（在例4-4中，管理员将速率指定为了512kbit/s），并以此将流量限制在命令priority所指定的带宽范围之内。

例4-4 LLQ限速

Router# show run

policy-map LLQ

class VOICE

priority 512

例4-4中所示的关键字priority既可以指定绝对的带宽数，也可以指定占用带宽的百分比。

4.2.3 控制层面的限速

CoPP可以通过配置QoS限速器来对那些需要由交换机主CPU进行处理的流量进行限速。这些限速器的作用是保护交换机/路由器的控制层面，使其免遭DoS攻击和侦查攻击的侵扰。QoS策略可以通过CoPP来对发往主CPU的流量进行控制，包括对这些流量进行放行、阻塞或限速。例如，如果有许多TTL为1的组播流量流入网络中，这些流量有可能会进入交换机，而此时它们的TTL值就会减1，于是控制层面就必须发送一条ICMP（Internet控制报文协议）错误消息。如果这类事件大量发生，CPU就会疲于处理这些流量，于是这个节点很快也就无法提供服务了。CoPP可以对节点进行保护，使其免遭这类攻击。例4-5显示了一个相关的策略，该策略将BGP（边界网关协议）路由流量限制在了每秒500个数据包（pps）之内，将IGP（内部网关协议）路由流量限制在了50pps之内，将所有未分类（默认）流量限制在了100pps之内。管理员将该策略关联在了控制层面（控制层面在配置文件中显示为一个逻辑接口）的入站方向和出站方向上。

例4-5 CoPP策略

Router# show run

! Define the policy CPP-POLICY

policy-map CPP-POLICY

class CPP-ACL-BGP

police rate 500 pps

conform-action transmit

exceed-action drop

! Polices BGP control-plane traffic to 500 pps

class CPP-ACL-IGP

police rate 50 pps

conform-action transmit

exceed-action drop

! Polices IGP control-plane traffic to 50 pps

class CPP-ACL-FILE-MANAGEMENT

police rate 400 pps

conform-action transmit

exceed-action drop

! Polices File-Mgmt control-plane traffic to 400 pps

class class-default

police rate 100 pps

conform-action transmit

exceed-action drop

! Polices all other control-plane traffic to 100 pps

! Apply CPP policy to the control plane in both directions

control-plane

service-policy input CPP-POLICY

service-policy output CPP-POLICY

4.2.4 无条件数据包丢弃

属于某一类（class）的数据包可以无条件丢弃，虽然严格来说，这并不属于一种限速工具（因为这种方法并不会像限速器那样根据某个速率对流量进行测量），但这是另一种调节网络流量的方式。例4-6显示了如何通过MQC将流量（通常是网络中的无关流量）彻底丢弃。

例4-6 无条件数据包丢弃

Router# show run

policy-map EXAMPLE

class UNDESIRABLE

drop

4.3 流量整形工具

整形器与限速器有些类似，它也会测量（穿越网络的）数据包的传输速率。但整形器与限速器的不同之处在于，整形器会推迟发送（而不是丢弃或标记）那些超出CIR的数据包。这种推迟发送的方式可以让突发流量以一种平滑的方式发送出去，使其符合SLA的规定，如图4-5所示。

图4-5 对数据流执行流量整形的效果

在有些场合，整形器的作用会格外明显，比如在流量必须符合某个特定的速率要求才能满足SLA规定的环境中，或者在流量必须低于某个数值以确保发往服务提供商的流量不超过协议规定速率的场合下。曾几何时，人们总是将整形器与非广播多路访问的2层WAN拓扑关联在一起，比如异步传输模式（ATM）和帧中继（FR）的环境，因为在这类环境中，存在（潜在的）传输速率不匹配的情况。但整形器在3层WAN访问环境中的部署也越来越频繁，因为整形器可以让流量符合某个低于线速的标准。整形器同样也是分层队列框架（HQF）中的核心组成部分。HQF已经在第2章中进行了介绍，在HQF中，各个站点的整形器可以让应用在连接各站点隧道的QoS策略发挥作用。这种做法在WAN汇聚路由器和VPN部署环境中均得到了广泛的使用。

与限速器类似的是，整形器也会使用令牌桶算法，并使用CIR、Bc和Be将流量以某个特定的速率平滑地发送出去。在默认情况下，某些整形器会将Bc设置为CIR/8，由此产生125 ms的间隔（Tc）。尽管这个间隔值也许足以应付数据应用的传输，但对于实时流量而言， 125ms端到端的延迟则未免显得过长。

因此，我们建议在承载实时流量的整形接口上，将间隔（Tc）设置为10ms。不过Cisco IOS命令无法直接对Tc值进行设置，只能通过调节Bc来间接地设置Tc值。要将Tc间隔设置为10ms，需要将Bc设置为CIR/100。

4.3.1 基于类的整形（class map）

基于类的整形是流量整形的推荐工具。在MQC 中，管理员可以在policy map 中通过命令shape 对某一类的流量实施整形（这个policy map 还定义了CIR、Bc、Be 及其他整形参数）。

基于类的整形通用的语法结构为:

shape [ average | peak ] [ cir ] [ Bc burst_size [ Be excess_burst_size ]]

例4-7所示为管理员在T1接口上部署的基于类的整形。在这个示例中，CIR被设置为了768kbit/s，同时为了满足实时流量的间隔推荐值而对Bc进行了设置（CIR/100），Be值则被设置为0。

例4-7 基于类的流量整形

Router# show run

policy-map CBS-768

class class-default

shape average 768000 7680 0

1.分层的基于类的整形

与分层限速一样，整形策略有时候也需要进行分层，以便对各个子层的流量提供额外的QoS功能。例如，服务提供商希望将发往客户的汇聚流量整形为384kbit/s，而在这个384kbit/s之内，还要（通过队列策略）为交易数据提供200kbit/s的带宽保障，并为大数据提供100kbit/s的带宽保障。这就可以通过一种套嵌的、分层的整形策略来实现，如例4-8所示。为了创建背压，管理员在接口上关联了PARENT-POLICY，因为QoS只有在出现拥塞的情况下才会发挥作用。

例4-8 分层的基于类的整形

Router# show run

policy-map PARENT-POLICY

class CUSTOMER1-TRAFFIC

shape average 384000

service-policy CHILD-POLICY

!

policy-map CHILD-POLICY

class CUSTOMER1-TRANSACTIONAL-DATA

bandwidth 200

class CUSTOMER1-BULK-DATA

bandwidth 100

2.基于百分比的整形

与限速一样，管理员同样可以使用带宽的百分比而不是绝对的带宽数来制定整形策略。突发值不能使用百分比进行配置，但可以在命令中用毫秒来指定。当使用百分比配置平均或高峰整形速率时，系统会自动分配到默认的突发值，管理员也可以使用例4-9所示的方法来自行配置突发值。当管理员在某个接口下关联了这个服务策略（service policy）之后，CIR 值就会通过接口带宽和管理员配置的CIR百分比值确定下来。

例4-9 基于百分比的整形

Router# show run

policy-map POLICY1

class-map class1

shape average percent 25 300 ms 400 ms

interface serial 3/1

service-policy output POLICY1

4.3.2 传统整形工具

早在MQC QoS 出现之前，就曾出现过许多整形工具（如ATM、帧中继流量整形[FRTS]和通用流量整形[GTS]等），在这里对这些古老的工具进行介绍只是为了帮助读者补充一些技术领域的历史知识。基于类的整形才是当前最佳，也是我们最推荐的Cisco IOS 整形工具。

1.ATM流量整形

整形是ATM PVC L2规范中规定的一个环节。通过配置不同的PVC流量协定（VBR-RT[实时可变比特率]、VBR-NRT[非实时可变比特率]、ABR[可用比特率]、UBR[未指定比特率]）， ATM技术可以实现不同级别的2层QoS技术。3层整形机制（如基于类的整形）往往不会与ATM 技术（包括DSL[ 数字用户线路]）一起使用。在ATM PVC 配置中指定的参数会决定整形后的平均速率或高峰速率，以及突发参数，如例4-10所示。

例4-10 ATM PVC的配置

Router# show run

interface ATM3/0.1 point-to-point

ip address 10.2.12.1 255.255.255.252

pvc 0/12

vbr-nrt 149760 149760

2.帧中继流量整形

帧中继接口最早的整形机制是FRTS，在接口下通过命令frame-relay traffic-shaping 就可以启用这种机制，如例4-11所示。但这种传统的工具不应该继续沿用下去。当前，在FR接口上也应该通过基于类的流量整形技术来执行流量整形。

例4-11 传统的帧中继流量整形工具

Router# show run

interface Serial0/1

no ip address

encapsulation frame-relay

frame-relay traffic-shaping

!

interface Serial0/1.50 point-to-point

bandwidth 1536

ip address 10.200.50.1 255.255.255.252

frame-relay interface-dlci 150

class FRTS-1536

!

map-class frame-relay FRTS-1536

frame-relay cir 1536000

frame-relay bc 15360

frame-relay be 0

frame-relay mincir 1536000

4.4 建议与指导

对于流量限速和整形的常用指导方针包括如下几项。

■ MQC基于类的限速与整形技术是十分重要的工具，只要有机会，就应该尽量使用它们。

■ 应该在尽可能靠近源的位置部署限速技术，同时应该尽可能在入站方向（而不是出站方向）上部署限速，尤其是在需要丢弃数据包的场合中。

■ 单速率三色限速器可以接受一定程度的临时突发流量，因此这种限速器比双色限速器算法导致的TCP重传更少。由此可见，单速率三色限速器在带宽使用方面效率更高。

■ 应该在存在速率不匹配现象的接口（无论是物理传输速率与SLA不匹配，还是远端接入链路与头端汇聚链路的速率不匹配）部署整形技术，将流量以平滑的方式输入出去。

■ 如果在传输实时流量的接口上配置了整形，就应该将Tc值设置为10ms。

4.5 小结

本章对限速和整形的算法、特性与工具进行了介绍。限速和整形这两种方法都会对流量进行测量，并对超越给定速率的流量实施某项策略。限速的方式会即时对每个数据包执行处理，处理的方式包括丢弃、传输或重标记后传输，而整形的方式则会（在缓冲的帮助下）推迟转发流量，并将流量以平滑的方式发送出去，以满足配置的流量速率。

排序工具（如队列技术），以及其他丢弃超量流量的技术将在第5章中进行介绍。

4.6 扩展阅读

4.6.1 通用内容

QoS Policing and Shaping Configuration Guide（QoS限速与整形配置指南）:http://www.cisco.com/en/US/docs/ios-xml/ios/qos_plcshp/configuration/15-1mt/qos-plcshp-15-1mt-book.html

4.6.2 差分服务限速标准

RFC 2697, A Single Rate Three Color Marker:http://www.ietf.org/rfc/rfc2697

RFC 2698, ATwo Rate Three Color Marker:http://www.ietf.org/rfc/rfc2698

4.6.3 限速

QoS SRND:policing and markdown tools（QoS SRND:限速与降级工具）:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSIntro_40.html#wp60957

Class-based policing（基于类的限速）:http://www.cisco.com/en/US/docs/ios-xml/ios/qos_plcshp/configuration/15-1mt/qos-plcshp-class-plc.html

Control plane policing（控制层面限速）:http://www.cisco.com/en/US/docs/ios-xml/ios/qos_plcshp/configuration/15-1mt/qos-plcshp-ctrl-pln-plc.html

Control plane policing（控制层面限速）:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSWAN_40.html#wp131394

QoS:Classification Policing and Marking on a LAC (L2TP Access Concentrator) Configuration

Guide（QoS:在LAC上的分类、限速与标记配置指南）:http://www.cisco.com/en/US/docs/ios-xml/ios/qos_lac/configuration/15-1mt/qos-lac-15-1mt-book.html

Committed access rate（承诺访问速率）:http://www.cisco.com/en/US/docs/ios-xml/ios/qos_plcshp/configuration/15-1mt/qos-plcshp-oview.html#GUID-B9D42CA8-EE64-4EE4-B82C-5931CFAFF335

ATM policing（ATM限速）:http://www.cisco.com/en/US/docs/ios-xml/ios/qos_plcshp/configuration/15-1mt/qos-plcshp-atm-plc.html

4.6.4 整形

QoS SRND:shaping tools（QoS SRND:整形工具）:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSIntro_40.html#wp60968

Class-based shaping（基于类的整形）:http://www.cisco.com/en/US/docs/ios/12_1t/12_1t2/feature/guide/clsbsshp.html

Class-based shaping for FR（为 FR 执行基于类的整形）:http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/frqosmqc.html

Configuring ATM traffic parameters（配置 ATM 流量参数）:http://www.cisco.com/en/US/docs/ios/12_2/wan/configuration/guide/wcfatm.html#wp1001126

Configuring Frame Relay Traffic Shaping for VoIP and VoFR（为VoIP和VoFR配置帧中继流量整形）:http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a00800d6788.shtml

第5章 拥塞管理和拥塞避免工具

本章涵盖了下列主题:

■ 术语与推荐做法；

■ Cisco IOS 2 层与3 层队列工具；

■ Cisco IOS 拥塞避免工具（如随机早期检测[RED] 与加权RED[WRED]）。

在对流量进行了分析，然后通过分类，为它们制定了此后要采取的策略之后，服务质量（QoS）的下一项任务是为这些不同类型的流量分配行为或策略，其中包括分配带宽、限速、列队及丢弃等。

在第4章中，本书介绍了一些限制流量速率的方式。而在本章中，我们会对拥塞管理（队列技术）与拥塞避免（早期丢弃）工具进行介绍，这些工具可以在设备不得不发送过量的流量之前，对其进行管理。

注释:本章中介绍的队列和调度机制都是基于Cisco IOS路由器的实施方案，这有两点原因:第一，IOS路由器是本书中最为核心的设备平台；第二，本章的宗旨是向读者介绍一些与队列技术和调度技术有关的一般概念。但其他网络位置（如园区往交换机的硬件队列、数据中心的Nexus 优先级流控制[PFC，Priority Flow Control] 以及增强传输选择[ETS]、WLAN 的无线多媒体[WMM]访问类别）中专用的队列与调度技术也会在相关的设计章节中进行介绍，这其中也包括某些平台所专用的内部队列机制。

5.1 拥塞管理和避免

有可能会经历拥塞的接口上都可以使用拥塞管理工具（包括队列工具）。当数据包进入设备的速率高于离开设备的速率时，这台设备上就有可能出现拥塞的情况，因此需要应用队列机制。有一点必须注意，那就是只有在出现拥塞的情况下，队列工具才会发挥作用。在没有出现拥塞的情况下，数据包会随收随发。但是当拥塞出现时，数据包就必须要缓存起来，或放入队列中（进行临时保存，然后再调度这些保存下来的数据包）以缓解丢包的情况。

在2层或3层对数据包进行标记往往会影响队列策略，以便设备在传输之前重新排列数据包的顺序。因此，队列策略策略需要依赖分类和标记策略，并为它们提供补充。

5.1.1 拥塞管理和拥塞避免的术语

拥塞管理包括队列技术和调度技术。从概念上说，队列与调度是互补的两项技术，它们之间的关系密不可分。而这些术语也经常被人们（错误地）替换使用。

■ 队列技术（也常常被人们成为缓存技术）是将数据包按顺序放入出站缓存中的处理方式。当接口出现拥塞时，系统就会采用队列的处理方式，而当拥塞清除之后，队列也就不会再发挥作用了。当队列满载时，设备就会对数据包重新进行排序，这是为了确保高优先级的数据包比低优先级的数据包更快地得到转发，离开设备。

■ 调度技术是判断接下来发送哪一个数据包的处理方式。无论接口是否出现拥塞，调度都会发挥作用（这一点调度与队列不同）。

图5-1所示为队列与调度技术的一般示例。

图5-1 队列技术的一般示例

5.1.2 拥塞管理和拥塞避免

拥塞管理包含了队列技术和调度技术两种做法，通过拥塞管理的方式，超量的流量在出站接口等待接受发送时，就可以被缓存下来或排入队列中（当然有时也会被丢弃）。

拥塞避免工具则更加简单；这类工具会检测网络流量，以预测并避免网络中出现拥塞。为了达到这个目的，这类工具会在拥塞出现前就开始有选择地丢弃一部分流量。

5.1.3 调度机制算法

在出现拥塞的条件下，队列算法就会发挥作用，调度程序则会判断接下来先让哪个队列接受服务。可以执行这类判断的调度算法有很多种，包括下列几项Cisco IOS 路由器提供的机制。

■ 严格优先级:只有当高优先级队列完全清空后，系统才会处理低优先级队列。这种类型的调度机制有可能会“饿死”低优先级队列中的流量。

■ 轮询（Round-robin）:队列按照一定顺序接受服务。虽然这种算法永远不会导致某种类型的流量被“饿死”，但却会使得实时、对延迟敏感的流量产生无法预测的延迟。

■ 加权公平:队列中的数据包（通常是通过IP优先级）被赋予了加权值，这是为了让其中的一些队列能够比另一些队列更加频繁地接受系统的服务。虽然这种算法解决了严格优先级与轮询算法中的一些缺陷，但是它也不能为实时流量提供其所需要的带宽保障。系统为每组数据流分配的带宽多少不一，且变化很大，具体的数值因当前数据流的数量，以及其他数据流的加权值而异。

为了解决上述问题，QoS部署方案中采用的调度工具对上述几种算法进行了组合，同时提供了多种解决它们缺陷的方式。管理员可以根据网络中实际的流量情况，灵活使用这些调度工具对网络进行调优。

Cisco交换机平台采用了队列技术的其他变体，其中包括整形轮询（SRR），以及差额加权轮询（DWRR），这些算法会在交换机设计的相关章节中进行介绍。

5.1.4 网络中各层的队列

对于任何特定的流量而言，队列技术（以及调度技术）都会在很多层对其进行处理。其中最为复杂的队列算法位于第3层，这种算法与接口的类型无关。在分配带宽时，3层队列技术一般只会考虑IP 数据包上层的内容。在Cisco IOS 路由器平台上，管理员也可以通过一种分层的方式来配置3层队列技术，让高级别的L3队列将流量送入低级别的队列中。

对于某些类型的接口来说，2层也存在队列技术的概念，这些2层的队列技术可以满足特定媒体（如过去的ATM[异步传输模式]和FR[帧中继]线路）的需求与特性。当2层队列满员时，它们会轮流将数据包注入3层队列中。

最后的一个队列（人们常常称之为传输环，或Tx-Ring）位于1层设备的驱动器之中。Tx-Ring因媒体和硬件的不同而异，它在各类路由器、板卡和模块的工作方式不尽相同。当Tx-Ring的队列满员后，较高级队列会优先获得服务，这就是在设备上使用QoS策略的初衷。

注释:并非所有级别的队列技术都很常用。

5.2 队列和调度机制的工具

在这一节中，我们会介绍一些不同的L1、L2和L3的队列工具，其中3层工具将是本节的重点。Cisco IOS 基于类的加权公平队列（CBWFQ）和低延迟队列（LLQ）将在本节进行深入的介绍，因为这两种队列技术是最适合部署在富媒体网络中（不同类型的流量共享同样传输媒介的环境）的队列机制。而传统的队列技术只会从历史的角度简单地进行概述。

在使用队列机制时，究竟是直接使用默认设置还是需要对队列参数进行调整，这个问题没有放之四海而皆准的答案。它取决于网络的软硬件平台及设计方案。因此，是使用默认设置还是对设置进行修改，将在介绍各PIN（Places In the Network）与平台的章节分情况讨论。

5.2.1 基于类的队列（policy map）

Cisco IOS 系统采用队列技术已有很长一段时间了。但对于当前的富媒体网络，许多过去的方法都已经不再适用——这些方法的历史比当前富媒体网络中很多类型的流量都长。尽管如此，还是不妨对过去的技术进行一下简单的回顾。在传统的队列机制中，核心的队列技术包括以下几项（这些技术的历史都比MQC[模块化QoS命令行界面]架构的历史更长）。

■ 先进先出队列（FIFO）:只有一个队列，数据包发送的顺序与它们到达队列的顺序完全相同。

■ 优先级队列（PQ）:共有4个队列，系统采用严格优先级的方式来处理数据包。这种方法最大的弊端在于，它有可能会造成较低优先级的流量被“饿死”。

■ 自定义队列（CQ）:系统通过轮询的方式调度16个队列中的数据包。这种方法可以为流量提供带宽保障，防止某些类型的流量永远无法获得服务，但无法为那些对延迟比较敏感的流量和实时流量提供它们所需的严格优先级服务。

■ 加权公平队列（WFQ）:这种算法会用接口的带宽除以流量的数目（流量可以通过IP优先级[或曰IPP]获得一个加权值），确保所有应用都能分配到合理的带宽。这种方法可以为高优先级的实时流量提供更好的服务，但无法保障某类特定流量的带宽。

■ IP RTP优先级队列（PQ-WFQ）:这是一种过渡形的算法，它会为实施流量提供一个单独的延迟优先级队列，同时对其他流量采用WFQ队列机制。但这种算法很快就被低延迟队列（LLQ）取代了。

当前最新的队列机制最好能够同时拥有上述诸项传统算法的优势，并捐弃它们的不足，只有这样的队列算法才适合应用在当前富媒体的网络环境中（同时，这种算法也要能够通过MQC来实现）。实时流量，及对延迟敏感的流量要求队列算法拥有下列两大特征:这种队列算法需要能够为自己保障一个绝对的传输带宽，并确保延迟值不会超出某个范围。其他类型的流量则需要在网络中存在实时流量的情况下，也能获得一定的服务。有鉴于此，当前我们最为推荐的队列算法如下。

■ 基于类的加权公平队列（CBWFQ）:这种机制是一个混合的队列算法，它将（CQ）保障带宽的能力，及（WFQ）动态为其他流量公平分配带宽的特点结合了起来。但是它无法提供延迟方面的保障，因此这种队列技术只适合用于传输数据流量。

■ 低延迟队列（LLQ）:这种方法在CBWFQ的基础上添加了严格优先级的功能，这种队列技术适合部署在那些传输混合流量（既包含实时流量又包含非实时流量）的环境中。LLQ可以同时为流量提供带宽及延迟方面的保障。

表5-1对上述两种推荐的算法进行了对比。

表5-1 队列算法的比较

* LLQ 在功能上只支持一个延迟优先级队列，但管理员可以配置多个“LLQ”。关于这一点，本章将在稍后提供解释

1.基于类的加权公平队列

CBWFQ可以创建最多256个队列，为多达256种类型的流量提供服务。系统会按照分配给各类的带宽，来服务不同的队列。配置 CBWFQ 的方式是在 policy map 中使用关键字bandwidth。在使用CBWFQ机制时，管理员需要明确配置和实施一个最低带宽。这个带宽既可以采用绝对带宽的方式，也可以采用带宽百分比的方式（关键字为percent）来进行指定。

例5-1中显示了两个通过CBWFQ进行管理的应用。首先，管理员为TRANSACTIONAL-DATA这一类流量分配了最低的带宽保障。其次，所有其他流量（也就是那些被归类为class-default 类的流量）都采用公平队列（fair queue）获取服务。

例5-1 CBWFQ策略的示例

Router# show run

policy-map WAN-EDGE

class TRANSACTIONAL-DATA

bandwidth percent 20　! Bandwidth for this class to 20%

fair-queue　　　! fair-queuing pre-sorter

class class-default

fair-queue　　　! Fair-queuing for unclassified traffic

在出现拥塞的情况下，接口的L1 Tx-Ring就会满载，并将数据包注入L3 CBWFQ队列（如果配置了CBWFQ队列的话）。每个CBWFQ类都会分配到自己的队列。CBWFQ队列也可以（通过在policy map 中使用关键字fair-queue）应用公平队列预分类程序，来管理竞争同一个队列资源的多组数据流。此外，系统会根据分配给每个类的带宽，以加权轮询（WRR）的方式处理各个CBWFQ。接下来，CBWFQ调度程序就会将数据包发送给Tx-Ring。

图5-2所示为CBWFQ的工作方式。

图5-2 CBWFQ的工作方式

2.低延迟队列

LLQ其实就是将CBWFQ与一个严格PQ结合了起来。系统会在为其他CBWFQ队列提供服务之前，使用分配给严格优先级队列的带宽，来为（使用关键字priority）分配给这个队列的流量提供服务。因此，管理员应该通过配置，让所有实时流量都享受优先级队列的服务。管理员可以定义许多类型的实时流量，并为每一种实时流量提供独立的带宽保障，但调度所有这些流量（的混合流量）的优先级队列只有一个。

为LLQ分配带宽也与为CBWFQ分配带宽一样，管理员既可以指定绝对带宽值，也可以按照百分比来执行带宽分配。在例5-2中，管理员为实施流量分配了接口带宽的33%，作为实时流量的带宽保障；其他类型的流量则会接受CBWFQ提供的带宽保障。

注释:Cisco曾经在实验室中进行了大量的测试，测试结果表明，对于承载混合了语音、视频和数据流量的链路，严格优先级队列流量（即所有使用了priority命令的流量）所占的带宽之和不应该超过链路总带宽的33%。上述建议并不适用于专门用来传输某一类流量（如TelePresence服务）的链路。

例5-2 LLQ策略的示例

policy-map WAN-EDGE-4-CLASS

class REALTIME

priority percent 33　! 33% LLQ for REALTIME traffic

class CONTROL

bandwidth percent 7　! 7% CBWFQ for CONTROL traffic

class TRANSACTIONAL-DATA

bandwidth percent 35　! 35% CBWFQ for TRANSACTIONAL-DATA traffic

fair-queue　　　! fair-queuing pre-sorter

class class-default

bandwidth percent 25　! 25% CBWFQ for Best-Effort traffic

fair-queue　　　! fair-queuing pre-sorter

本书在4.2.2节的“低延迟队列的限速”一节中曾经介绍过，LLQ包含了一个隐含的限速器，其作用是限制可供实时队列流量占用的带宽，由此防止CBWFQ调度程序所服务的非实时数据流被“饿死”。这个隐式限速器所限制的流量速率也就是分配给这个类的带宽，超过这个速率的流量就会被尾部丢弃。

图5-3描绘了LLQ的工作方式。在该图中，3类实时流量都被装入了LLQ的优先级队列中，而其他类型的流量则使用了CBWFQ的算法。例5-3提供了针对这种流量模型的配置方案，其中总计10Mbit/s的实时流量会被分配到同一个优先级队列中，其中，VoIP流量被限速为1Mbit/s，广播视频流量限速为4Mbit/s，互动式视频流量为5Mbit/s。

图5-3 LLQ的工作方式

例5-3 多类型LLQ流量的配置示例

Router# show run

class-map match-all VOIP

match dscp ef

class-map match-all BROADCAST-VIDEO

match dscp cs5

class-map match-all REALTIME-INTERACTIVE

match dscp cs4

policy-map WAN-EDGE

class VOIP

priority 1000 ! 1M of VoIP traffic

class BROADCAST-VIDEO

priority 4000 ! 4M of Broadcast video traffic

class REALTIME-INTERACTIVE

priority 5000 ! 5M of Interactive video traffic

5.2.2 三层以下的队列技术:Tx-Ring的工作方式

第1 层的设备驱动器级队列（device driver level queuing）是设备将信息传输出去之前，执行的最后一个出站队列。有些链路技术（如FR和ATM）也具有2层队列技术，但这都是一些十分过时的技术，这里不加赘述。

Tx-Ring是一种1层的队列机制，它其实是一个比较小的FIFO队列，也是WAN接口的最后一个出站缓存机制。其目的是让出站传输速率与物理接口的速率相匹配，以提升物理链路的带宽利用率。图5-4描述了Tx-Ring的工作方式。

图5-4 Tx-Ring的工作方式

图5-2和图5-3的右侧显示了Tx-Ring在3层队列中的位置。如果Tx-Ring满载，就可以认为该接口已经出现了拥塞，此时软件就会激活该接口所应用的全部LLQ/CBWFQ策略。

Tx-Ring队列的长度由硬件、软件、2层媒介以及该接口上配置的队列算法而定。最好的做法是在最高768kbit/s的WAN接口上将Tx-Ring的值设置为3。

Tx-Ring在ATM链路（包括DSL[数字用户线路]）上尤为重要，因为各PVC（永久虚电路）上都有一个专用的驱动器级Tx-Ring 来确保流量符合ATM PVC 的CoS（服务类型）。默认的ATM Tx-Ring 往往比较深（长），包含至少64 个粒子（每个粒子通常为576 字节），这是为了确保缓存中有足够的粒子可以让PVC充分利用带宽。这是因为如果Tx-Ring长度比较短，传输中断的次数就会增加，驱动器和主CPU也就必须进行等待，而对于高速电路来说，这显然是不够理想的。但如果Tx-Ring的队列过深，则会影响语音的流量，因为Tx-Ring是一个FIFO的队列，它无法根据优先级来重新排列数据包的顺序，并降低延迟。

因此，调整Tx-Ring需要在减小实时数据包延迟，与提高CPU和带宽利用率之间进行权衡。链路（或电路）的带宽越高，加深Tx-Ring的长度就越不会给语音或视频流的质量造成不良的影响。

5.3 拥塞避免工具

在任何接口上，缓存的资源都很有限，而一旦队列缓存满载，数据包就有可能在到达时即被丢弃（尾部丢弃），或者有选择地遭到丢弃，这是为了防止全部的缓存统统过载。而当队列排满时，设备有选择地丢弃数据包的这种行为称为拥塞避免。队列算法管理的是队首，而拥塞避免机制管理的则是队尾。

拥塞避免机制最适合基于TCP的应用，因为有选择地丢弃数据包可以让TCP窗口收紧，将流量速率限制在管理员设置的范围之内。TCP拥有一个内置的流量控制机制，它可以提高流量的传输速率（即使流量的速率受到缓存和窗口大小的限制）直到出现丢包的现象。此时， TCP会突然收紧传输的速率，然后再逐渐地提高速率。图5-5中所示的带宽利用率不够理想， TCP流量存在尾部丢弃的现象。在这种情况下，使用随机丢弃拥塞避免机制来管理TCP流量就会高效得多。虽然图5-5多少有点理论化，但这幅图至少从直观上展示出了管理TCP流量队列的效果——在实际环境中，这些“波”的形状可能与图中不尽相同，因为具体的波形取决于实际流量的特征，每种数据流都有自己的模式。

图5-5 TCP全局同步

5.3.1 随机早期检测（RED）

RED会在队列满载之前，随机丢弃数据包，以此来防止TCP全局同步这一现象（TCP会话会周期性地进行同步，这一过程所产生的数据交换会导致网络中生成额外的数据流量。如果这些流量同时出现，就会产生全局同步这一事件）。随机丢弃数据包（而不是立刻将数据包全部丢弃）可以避免TCP流出现全局同步的情况。RED会监测缓冲区的深度，一旦超过了管理员定义的最低队列门限，RED就会开始随机对数据包执行早期丢弃。

注释:用户数据报协议（UDP）不包含内置的重试机制，因此（狭义上和理论上）拥塞避免的方法在管理UDP流量方面没有什么显著的效果。但是在实际使用中，情况要复杂得多——拥塞避免技术对于不同的UDP流量也会产生不同的效果，因此管理员在使用前应该进行认真的评估。这是因为有一些高层协议（如TFTP[简单文件传输协议]）或一些以UDP作为传输层协议的应用自身具有重试的机制。此外，RTP控制协议（RTCP）有时会充当一种确认机制，这会使得基于UDP的应用丢弃数据包。视频应用有很多丢弃数据包的方式，拥塞避免机制是否有效取决于应用会丢弃哪种类型的数据包:参考数据帧还是常规数据帧。

Cisco IOS 系统只支持加权RED（WRED），而不支持RED。不过，如果分配给某一接口的所有数据包或者类全都拥有相同的DSCP（差分服务代码点）标记，那么设备执行的实际策略其实就是RED。

5.3.2 加权随机早期检测（WRED）

Cisco IOS 系统的核心拥塞避免机制是WRED。通过IPP 或DSCP 赋予流量的权重可以影响设备在随机丢弃数据包时所作的选择。IPP值较低的数据包比数值较高的数据包更容易遭到丢弃（比如，IPP为1的数据就比IPP为6的数据更容易被丢弃）。

对于WRED而言，基于DSCP的权重是用AF（确认转发）丢弃优先级（Drop Preference）值来进行表示的，AF丢弃优先级的值越高，越容易被丢弃（例如，从概率的角度上讲，AF23就比AF22更可能被丢弃，而AF22则比AF21更容易被丢弃）。

WRED 也可以对IP ECN（显式拥塞通知）位进行设置，来指示传输过程中出现了拥塞的情况。

图5-6显示了基于DSCP的WRED的工作方式。

图5-6 基于DSCP的WRED的工作方式

在Cisco IOS 系统的CLI 命令行界面中输入random-detect 就可以启动WRED。如果输入了可选的关键字dscp-based，即可以启用基于DSCP的WRED——在条件允许的情况下，往往应该尽量使用这种特性。例5-4显示了WRED的配置方式。

例5-4 WRED的配置

Router# show run

policy-map WAN-EDGE

class REALTIME

priority percent 33

class TRANSACTIONAL-DATA

bandwidth percent 35

fair-queue

random-detect dscp-based

class class-default

bandwidth percent 25

fair-queue

random-detect dscp-based

对于WRED与基于DSCP的WRED技术，它们的门限值与标记概率分母（mark probability denominator）都可以以代码点为单位进行调整。在例5-5 中，管理员将最低门限值设置为队列深度到达50即开始丢弃标记为AF11的数据包（也就是说，一旦队列深度到达50个数据包的门限值，WRED就会开始随机丢弃数据包）。而AF11的最大门限值被设置为了60（此时所有标记为AF11的数据包统统会被丢弃）。标记概率分母则被设置为了8（这就是说，在这两个门限值之间，每8个数据包中最多有一个AF11的数据包会被丢弃；当队列深度达到最大门限值时，每8个数据包中就一定有一个AF11的数据包会被丢弃；在超出了最大门限之后，所有AF11的数据包都会被丢弃）。

例5-5 配置了门限值的WRED

Router# show run

policy-map DSCP-WRED

class class-default

random-detect dscp-based af11 50 60 8

WRED也可以对RFC 3168 IP ECN位进行设置，以表示在传输过程中出现了拥塞。如果在配置policy map时，在random-detect后面添加关键字ecn，就会启用ECN功能，如例5-6所示。

例5-6 配置了ECN的WRED

Router# show run

policy-map pol1

class class-default

bandwidth per 70

random-detect ecn

5.4 建议与指导

队列技术与拥塞避免技术的常用指导方针包括如下几项。

■ 无论网络的条件是好是坏，重要应用（如VoIP）的服务必须得到保障。而为这些服务提供保障的唯一方式就是在有可能出现拥塞的节点上启用队列技术。

■ 由于大量没有进行分类的应用最终都会被划分到默认的类别中，因此建议为默认类（尽力而为类）预留出至少25%的带宽。

■ 如果一条链路承载了视频、语音和数据的混合流量，那么就应将严格优先级队列的总量限制在链路承载能力的33% 之内；这33% 中，包含了所有在policy map 中使用了关键字priority的流量。

■ 只要网络中存在实时流量或对延迟敏感的流量，就应启用LLQ。

■ 对于TCP流量，应选择WRED作为拥塞避免工具（同时也要仔细评估WRED有可能会对不同类型的UDP流量造成何种影响）。

■ 要尽可能使用基于DSCP的WRED。

5.5 小结

本章对拥塞管理工具进行了介绍，尤其强调了基于Cisco IOS 的CBWFQ 与LLQ 算法。这两种队列技术是最适合在富媒体网络中进行部署的Cisco IOS 队列工具。

虽然大多数队列策略都发生在网络第3层，但读者也不妨了解一下底层的队列技术，如2层队列和1层的Tx-Ring队列，了解它们对于设计整体的网络方案不无裨益。

本章还涵盖了最核心的拥塞避免工具——WRED。WRED可以在队列溢出导致流量被尾部丢弃之前，通过一种优化带宽的方式来调节TCP数据的流量。

对于某些平台上专用的拥塞管理工具，以及这些拥塞管理工具的各种变体、默认值和调试方式，都会在介绍相关平台的章节进行详细讲解。

在第6章中，我们会着重深入介绍在某些特定类型链路上可供选用的QoS工具。

5.6 扩展阅读

5.6.1 队列技术

Congestion Management Configuration Guide（拥塞管理配置指南）:http://www.cisco.com/en/US/docs/ios-xml/ios/qos_conmgt/configuration/15-1mt/qos-conmgt-15-1mt-book.html

CBWFQ operation（CBWFQ的工作方式）:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSWAN_40.html#wp129419

LLQ operation（LLQ 的工作方式）:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSWAN_40.html#wp129441

Tx-Ring operation（Tx-Ring的工作方式）:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSWAN_40.html#wp129403

ATM Tx - Ring tuning（ATM Tx-Ring的调试）:http://www.cisco.com/en/US/tech/tk39/tk824/technologies_tech_note09186a00800fbafc.shtml

5.6.2 拥塞避免技术

Congestion Avoidance Configuration Guide（拥塞避免配置指南）:http://www.cisco.com/en/US/docs/ios-xml/ios/qos_conavd/configuration/15-1mt/qos-conavd-15-1mt-book.html

RED:http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfconav_ps1835_TSD_Products_Configuration_Guide_Chapter.html#wp1000899

WRED:http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfconav_ps1835_TSD_Products_Configuration_Guide_Chapter.html#wp1000959

WRED Solution Reference Network Design (SRND):http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSWAN_40.html#wp129476

第6章 带宽预留工具

本章包含了如下主题:

■ 准入控制机制；

■ RSVP IntServ 与DiffServ 设计与部署模型；

■ RSVP本地策略与应用ID；

■ 扩展性、端点与代理。

本书迄今为止讨论过的所有QoS（服务质量）工具包括标记、队列、限速与整形机制，这些机制基本都属于差分服务（DiffServ）工具。DiffServ机制可以（在不同程度上）提供带宽保障，但是它无法提供带宽预留功能。带宽保障是指在需要时有带宽可供使用，但这些带宽并没有为了某一个特定的应用或数据流被闲置（或保留）起来。而预留是指系统可以识别出数据包流，同时为这一类数据流保留了一定数量的带宽。

本书到目前为止所介绍的QoS工具，其作用都是处理网络中现有的流量。准入控制（AC）则与那些工具存在本质上的区别，它处理的是尚未获准进入网络的流量，因此AC可以辅助设备来判断是否允许某种新的流量进入到网络当中。对于那些对延迟和丢包不那么敏感的流量（往往是数据流量）而言，使用AC技术可谓收效甚微。但实时流量（如语音和视频流量）则可以大大获益于AC技术，因为这些类型的流量对延迟和丢包非常敏感，所以延迟和丢包的情况一旦出现，立刻就会使这个数据流对于终端用户变得毫无意义。由此，人们也常常将AC称为“呼叫准入控制（CAC）”，但从基本概念的角度，准入控制技术对所有延迟和丢包敏感型的流量都可以产生良好的效果，而不仅有益于语音“呼叫”。

CAC可以从方法上分为两大类别。

■ 基于测量的CAC:这类方法采用的是计数机制，也就是说，它只放行有限数量的呼叫（即会话）。限制的数量往往是管理员根据自己的知识与经验手动进行设置的，与网络当前的状态无关。这类方法不会在本章中进行深入介绍，因为这种方法存在于应用程序之中，对于网络操作是透明的。

■ 基于资源的CAC:这类方法是根据网络资源的可用性（通常为带宽），以及网络当前的状态来执行准入控制的，这类方法是本章将重点进行讨论的内容。

资源预留协议（RSVP）是Cisco IOS 中最古老的QoS 工具之一，这项协议的历史可以追溯到20世纪90年代中期。RSVP的发展和实施甚至早于富媒体网络时代，但当时，RSVP的目的是为了符合当时的网络发展趋势:为时间敏感应用提供可预测的延迟并预留带宽。RFC 2205是这样定义RSVP的。

RSVP是一台主机为某种应用的数据流而向网络请求特定服务质量的协议。

RSVP广泛应用于多协议标签交换流量工程（MPLS-TE）网络中，充当一种“可以保障带宽的”隧道建立机制。

RSVP与其他QoS工具存在如下区别。

■ RSVP是一项信令协议。

■ RSVP会预留资源（带宽）。

■ 完整实施RSVP要求网络中的所有节点都:

■ 理解RSVP；

■ 在节点上通过一种方式来预留资源。

6.1 准入控制工具

互动式应用（如语音和视频）要求网络提供实时的服务。由于这些资源是有限的，竞争这种稀缺资源的流量数量也必须受到限制；否则，所有实时流的质量都会受到影响，最终会导致所有实时会话都难堪使用。即使是在网络资源不能满足需求的情况下，实时流也不能推迟发送或缓冲起来（数据应用则不妨），因此新入站的实时数据流必须使用可用的网络资源予以放行，而且是在会话发起时便使用可用资源来承载这些流量。上述行为中即包含了准入控制这项技术。

AC的功能在应用级别（如控制VoIP、IP视频与TelePresence的Cisco统一通信管理器）最见成效。因此，本书不会对AC进行详细的阐述，只会对AC与（通过QoS）分配网络资源之间的关系这一层面的内容进行介绍。

大多数AC机制都是相当简单的“计数”算法，这些算法并不了解数据流所经过的网络设备与路径——因此这些算法也常常被人们称为“离径”AC工具。当大多数流（如G.711和G.729语音呼叫）所占的带宽都可以预测出来，而且网络的复杂程度也不高（通常是星型拓扑）时，这类AC机制都可以完美胜任，而且也都得到了广泛的部署。但如果数据流的带宽需求波动很大（如语音和一些不同格式的视频流），或者网络的拓扑比较复杂，在网络的A点和B点之间有多条路径可供选择时，这类AC 机制则用处不大。基于路由器的Cisco IOS 拥有一种会话计数机制（CLI 命令为call threshold），这种机制经常与SIP（会话初始化协议）进行关联，但这种机制自身并不是该协议中的一个组成部分。当Cisco IOS 路由器在网络中充当语音或视频网关或会话边界控制器时，就会使用这些CAC工具。

无线网络也有一种有限的功能来实现AC功能（需要管理员通过配置来实现），这取决于802.11e客户端为了将自己的流量需求发送给访问点（AP），而能够插入的流量特征（TSpec）信息。

6.2 资源预留协议

资源预留协议（RSVP）是一项可感知网络环境的技术（因此也称为“径内”AC工具），它可以在数据流获准进入网络之前，沿着数据流会途径的真正路径来分配带宽。因此，RSVP拥有双重功能:访问控制与带宽预留（或为某个数据流预留隧道的保障带宽）。其中第一项功能（准入控制）很容易扩展，而第二项功能（在数据流到达前预留带宽）则不容易扩展（至少无法在动辄上万数据流共存的网络汇聚骨干中进行扩展）。因此，人们常常在设计网络时，在网络边缘部署RSVP来作为一种AC工具（集成服务[IntServ]），同时在网络深处的节点使用更具扩展性的差分服务（DiffServ）工具来对汇聚流量进行分类、队列与带宽管理。

6.2.1 RSVP概述

RSVP 是一个以流为单位（per-flow）发挥效用的协议，它会请求数据流路径中的每个节点为流量预留带宽。端点（或其他代表端点的网络设备）会发送单播的信令消息，以在数据流获准进入之前，为其预留带宽。图6-1所示为基本的RSVP操作。

图6-1 基本的RSVP操作

通过图6-1可以看出:

■ 在理想的情况下，数据流路径中每个启用了RSVP的路由器都会查看到这些消息，并根据接口的配置为指定数据流分配相应的带宽；

■ 在更贴近现实的环境中，网络骨干内部那些没有RSVP功能的节点只会将消息转发给边缘节点进行查看；

■ 当设备1向设备2发起一条会话时，它（或者距离作为代理的那台设备最近的路由器）会沿着与实际数据流最终将采取的路径相同的道路来发起RSVP预留消息；

■ 若各处带宽均充足，预留就会成功，会话就会获准进入网络当中；

■ 如果设备3发起了一次会话，但路径中有些位置带宽不足，预留就会失败，会话就不会获准进入网络。

RSVP以及具体的操作方式在多个IETF（互联网工程任务组）RFC中均有记载，包括RFC 2205-2212、2747、2961、2998、3175、3209、3936、4420、4874、4874、5151、420、5711，读者可以在http://www.ietf.org/rfc.html查看这些文档。

6.2.2 RSVP代理

大多数终端设备，如电话与视频端点（独立设备以及移动设备、平板和电脑上的软件应用）并不支持RSVP协议栈。如需以RSVP协议为这些设备发起的会话提供AC机制，就需要让距离这些设备最近的路由器来充当代理，如图6-2所示。

图6-2 RSVP代理的工作方式

（与端点设备同处于站点中的）路由器会使用RSVP代理配置，与Cisco统一通信管理器（CUCM）结合起来，在会话获准进入网络之前建立AC。在应用程序的层面上，CUCM拥有准入的最终决策权，但它会通过（启用了RSVP的）路由器所获得的网络状态，来辅助自己作出判断，这可以将（集中策略导向的应用级，centralized policy-oriented application-level）AC工具，以及（像RSVP这类）了解拓扑情况的协议，这两者的功能结合起来。

6.2.3 RSVP部署模型

RSVP有两种操作模型，如图6-3所示。

■ IntServ模型（集成服务模型）:这是传统的RSVP操作模型，但由于这种模型存在扩展性方面的缺陷，因此当前已经并不常用。

■ IntServ/DiffServ模型（集成服务/差分服务模型）:控制层面的操作与数据层面的操作相互独立。RSVP的操作仅限于AC功能，同时由DiffServ机制处理分类、标记、限速及调度操作。因此，IntServ/DiffServ模型扩展性极强，亦极为灵活。

如图6-3所示，在IntServ/DiffServ模型中，RSVP只用于执行AC（控制层面功能）；所有其他的QoS功能（包括分类、标记、限速、整形、队列与丢弃等）都由DiffServ策略进行处理，而后者都术语数据层面的功能。这种组合方式可以有效地扩展策略。

图6-3 RSVP操作模型:IntServ模型与IntServ/DiffServ模型

图6-3 右侧的IntServ/DiffServ 模型，是在可扩展的部署环境中以RSVP 协议充当QoS AC机制的推荐模型。这种模型可以进一步分为两种设计方案，这两种设计将在下一节中进行详细介绍。

■ 基本RSVP设计方案。

■ 高级RSVP设计方案（具有应用ID功能）。

1.基本RSVP设计（IntServ服务/DiffServ服务模型）

在配置了IOS RSVP 代理之后，管理员可以在接口配置模式下输入命令ip rsvp bandwidth来启用基本的RSVP功能，这条命令可以指定接口需要根据RSVP的请求而为其预留多少带宽（默认为预留链路带宽的75%）。

如果所有的优先级流量都启用了RSVP，那么命令ip rsvp bandwidth 中指定的数值，以及LLQ（低优先级队列）命令priority就要匹配。但是，如果有些优先级流量没有启用RSVP，那么命令ip rsvp bandwidth 中所指定的数值，与带外的呼叫AC 机制所指定的数值之和，绝不能超过LLQ命令priority所指定的带宽。

在网络的WAN边界应该启用RSVP，包括WAN链路两端的路由器WAN接口，以及所有WAN拥塞点（包括不同速率的冗余链路）。而在高带宽的园区网中，RSVP的应用则并不普遍，因此园区网边缘（即终端设备连接到交换机而非路由器的环境）不会在这里进行讨论。

配置 IntServ/DiffServ RSVP 模型需要在接口下多添加两条命令，即 ip rsvp resource provider none 与ip rsvp data-packet classification none。这两条命令的作用是让RSVP 不要去执行那些应当由DiffServ策略进行处理的数据层面的QoS操作。

例6-1 所示为基本的IntServ/DiffServ RSVP 配置。

例6-1 RSVP IntServ/DiffServ模型的配置

! Configures basic IntServ/DiffServ RSVP on a WAN interface

Router(config)# interface Serial2/0

Router(config-if)# description CAMPUS-TO-BRANCH-SERIAL-T3-WITH-RSVP

Router(config-if)# bandwidth 44210

Router(config-if)# service-policy output WAN-EDGE-DIFFSERV-POLICY

! Attaches the DiffServ MQC policy to the interface

Router(config-if)# ip rsvp bandwidth 15000

! Specifies the amount of reservable BW (should match LLQ BW)

Router(config-if)# ip rsvp signalling dscp 24

! Marks RSVP signaling traffic to DSCP 24

Router(config-if)# ip rsvp data-packet classification none

! Enables IntServ/DiffServ by disabling RSVP for classification

Router(config-if)# ip rsvp resource-provider none

! Enables IntServ/DiffServ by disabling RSVP for scheduling

2.高级RSVP设计（IntServ服务/DiffServ服务模型）

RSVP本地策略提供了一种机制，可以根据应用的ID来控制资源预留的配额。管理员通过命令ip rsvp policy identity 可以在应用ID 与RSVP 本地策略之间建立一个映射关系。RSVP本地策略身份（local policy identity）需要在全局进行定义，然后再在接口下调用实施。每个身份都可以定义一个策略定位标记（policy locator）来匹配应用ID。

为了让用户尽可能灵活地使用应用策略定位标记来匹配本地策略，RSVP本地策略命令可以使用UNIX格式的正则表达式作为应用ID的匹配标准。

CUCM 可以为语音和视频流量设置RFC 2872 应用ID，这个应用ID 会成为集群范围内的服务参数（clusterwide service parameter）。在默认情况下，CUCM使用的应用ID为:语音流——AudioStream、视频流——VideoStream（同时代表视频流中的音频与视频成份）。因此，在全局配置模式下定义（与CUCM语音和视频流量的应用ID相匹配的）相应RSVP策略身份的命令（分别）为:

■ ip rsvp policy identity rsvp-voice policy-locator.*AudioStream.*

■ ip rsvp policy identity rsvp-video policy-locator.*VideoStream.*

接下来，需要通过命令ip rsvp policy local identity将基于应用ID的本地策略应用到接口上。例6-2显示了如何通过配置，来为语音和视频应用ID分配不同的本地策略。

例6-2 配置应用ID的RSVP本地策略

Router(config)# interface Serial2/0

Router(config-if)# description CAMPUS-TO-BRANCH-SERIAL-T3-WITH-RSVP

Router(config-if)# bandwidth 44210

Router(config-if)# service-policy output WAN-EDGE-DIFFSERV-POLICY

! Attaches the DiffServ MQC policy to the interface

Router(config-if)# ip rsvp policy local identity RSVP-VIDEO

Router(config-rsvp-local-if-policy)# maximum bandwidth group 12500

Router(config-rsvp-local-if-policy)# forward all

! Local RSVP policy to admit <12.5 Mbps of video flows

Router(config-if)# ip rsvp policy local identity RSVP-VOICE

Router(config-rsvp-local-if-policy)# maximum bandwidth group 2500

Router(config-rsvp-local-if-policy)# forward all

! Local RSVP policy to admit up to 2.5 Mbps of voice flows

Router(config-if)# ip rsvp bandwidth 15000

! Specifies the amount of reservable BW (should match LLQ BW)

Router(config-if)# ip rsvp signalling dscp 24

! Marks RSVP signaling traffic to DSCP 24

Router(config-if)# ip rsvp data-packet classification none

! Enables IntServ/DiffServ by disabling RSVP for classification

Router(config-if)# ip rsvp resource-provider none

! Enables IntServ/DiffServ by disabling RSVP for scheduling

! This section defines regular expressions to match RSVP AppIDs

Router(config)# ip rsvp policy identity RSVP-VIDEO policy-locator.*VideoStream.*

! RSVP AppIDs with the string "VideoStream" are

! associated with the RSVP-VIDEO local RSVP policy

Router(config)# ip rsvp policy identity RSVP-VOICE policy-locator.*AudioStream.*

! RSVP AppIDs with the string "AudioStream" are

! associated with the RSVP-VIDEO local RSVP policy

6.2.4 RSVP和LLQ

在使用RSVP IntServ/DiffServ 模型的设计环境中，RSVP只会（通过命令ip rsvp bandwidth）执行AC功能，而由LLQ通过基于类的规则来控制队列算法（往往需使用差分服务代码点[DSCP]标记来实现）。图6-4显示了这种模型的工作方式。

图6-4 RSVP IntServ/DiffServ与LLQ

部署了RSVP与LLQ的设备并不会控制以哪些带宽值来满足RSVP请求，它只会根据请求作出响应。因此，用哪个值来满足端点、应用或代理的RSVP请求对于不同的端点和应用而言，可能会存在相当大的差异（尤其是在一个会话中，对带宽的需求波动极大的视频流量）。

LLQ和基于类的队列（CBWFQ）代理只需如常配置，然后在接口上为它们分配带宽。不需要通过命令ip rsvp bandwidth 来预留带宽；这条命令的作用是启用AC 技术来判断哪些数据流应该获准，哪些数据流则应该拒绝。RSVP流量会根据LLQ规则分配到不同的队列。如果存在非RSVP的实时应用，可以使用命令priority来处理RSVP与非RSVP数据流，并确保非RSVP流会通过其他形式的AC来确保它们不会超额占用带宽。

如果为了针对不同的应用而更加精确地控制带宽的分配情况，而采取了RSVP与应用ID共用的设计方案，那么RSVP与LLQ之间的相互关系如图6-5所示。

总的来说，LLQ与RSVP还是会按照图6-4所示的方式协同工作，但RSVP流不仅会以ip rsvp bandwidth 命令作为唯一的匹配标准，还会匹配包含了数据流应用ID 的本地策略（也就是命令ip rsvp policy local identity 中指定的带宽）。

图6-5 含应用ID的RSVP IntServ/DiffServ与LLQ

6.3 建议和指导

随着富媒体应用与数据流的爆炸式增长，Cisco推荐在基于路由器的代理设备上使用RSVP IntServ/DiffServ 模型。这种部署模型更便于扩展QoS 策略，也可以让动态可感知网络的AC更易满足多变的带宽需求。

6.4 小结

多年来，Cisco一直不懈地扩展RSVP的功能，并让RSVP具有更强的适应性和更出色的效率，这也是Cisco媒体网络（Medianet）倡议行动中的一个组成部分。RSVP是一个信令协议，这一点与本书到目前为止所介绍的其他QoS工具都不相同。它是一项核心的网络感知技术，可以在各类对带宽需求各异的实时流量（从G.729呼叫到高清多屏幕视频流）竞争带宽资源时，发挥仲裁者的作用。

在所有实施流量（如G.729和G.711语音呼叫）对带宽的需求都大同小异时，“呼叫计数”AC法倒也可以勉强应付得过来，但它无法有效处理各类流量（如语音和多种视频流量）对带宽需求差别较大的环境。

本章对RSVP的工作方式进行了简要的介绍。其中，在IntServ/DiffServ混合部署模型中，仅以RSVP作为AC机制（而没有使用整个协议栈中所有功能）的设计方案是这一章的重中之重。这种设计方案可以在富媒体网络流量中，更加高效地使用RSVP来提供AC机制，同时扩展性也更强。

一些媒体网络特性（Mediatrace与媒体监测）也会使用RSVP。不过，这些特性使用的并不是RSVP的AC和带宽预留方面的功能，它们只会使用RSVP来获得媒体检测信息。这部分内容将在第8章进行深入介绍。

6.5 扩展阅读

6.5.1 媒体网络中的RSVP

Medianet WAN/VPN QoS Design At-a-Glance（企业网络 WAN/QoS 设计攻略）:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/qoswanvpnaag.html

Enterprise Medianet Quality of Service Design 4.0（企业媒体网络服务质量设计4.0）:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSIntro_40.html

Medianet WAN Aggregation QoS Design 4.0（媒体网络WAN汇聚QoS设计4.0）:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSWAN_40.html#wp129507

6.5.2 RSVP技术

Configuring RSVP Support for LLQ（通过配置使RSVP 支持LLQ）:http://www.cisco.com/en/US/docs/ios-xml/ios/qos_rsvp/configuration/15-2mt/rsvp_sprt_llq.html

Configuring RSVP Agent（ 配置RSVP代理）:http://www.cisco.com/en/US/docs/ios-xml/ios/voice/cminterop/configuration/15-2mt/vc-rsvp-agent.html

Configuring RSVP（配置RSVP）:http://www.cisco.com/en/US/docs/ios-xml/ios/qos_rsvp/configuration/15-2mt/config-rsvp.html

RSVP Scalability Enhancements（增强 RSVP 的扩展性）:http://www.cisco.com/en/US/docs/ios-xml/ios/qos_rsvp/configuration/12-4/rsvp-scalability.html

RSVP Refresh Reduction and Reliable Messaging（RSVP 刷新减少与可靠消息传输）:http://www.cisco.com/en/US/docs/ios-xml/ios/qos_rsvp/configuration/15-2mt/rsvp-messaging.html

RSVP Local Policy Support（RSVP本地策略支持）:http://www.cisco.com/en/US/docs/ios-xml/ios/qos_rsvp/configuration/15-2mt/rsvp_local_plcy_sprt.html

第7章 IPv6网络中的QoS

本章包含了如下主题:

■ IPv6的编址与分类；

■ 在处理IPv6流量时，QoS工具如何发挥作用，以及如何配置相关的QoS工具。

本书前面7章中所有关于所有服务质量（QoS）的内容都是既适用于IPv4网络，也适用于IPv6网络的。当网络中出现IPv6流量时，数据流中往往也混有IPv4流量（在本行业中，IPv4到IPv6的过渡恐怕要经历很长的一段时期）。因此，为了确保QoS工具的配置能够同时适用于IPv4和IPv6流量，有一些因素必须详加考虑。这些需要加以考量的因素正是本章的重点。

7.1 IPv6和QoS概述

IPv6是由IETF（互联网工程任务组）开发的协议，旨在解决IPv4地址空间不足的问题。IETF RFC 2460（Internet Protocol Version 6, IPv6, Specification）与RFC 3697（IPv6 Flow Label Specification）这两个文档是IPv6 的核心标准。

IPv6对IPv4的功能进行了扩展，但这两个协议无法一起使用，因此必须通过隧道技术或其他的互通方式才能让IPv4设备和IPv6设备在相同的网络中进行通信。其中，最为常用的互通方式就是使用具有双协议栈功能的设备。

IPv6大体上可以无缝支持QoS特性，这里只有几点需要注意。

■ IPv6可以支持基于类的QoS特性，但许多更老的特性则没有得到IPv6的支持。

■ IPv6的头部比IPv4的头部要大得多，因此由IPv6小型数据包所组成的数据流对带宽的占用量会更高。

■ 配置命令有一些微小的区别（例如，在set和match命令中需要添加[或不使用]关键字ip）。

7.2 适用于IPv6的QoS工具

本书到目前为止所介绍的QoS特性均可以运用于IPv4和IPv6流量，包括:

■ 数据包分类与标记；

■ 限速与整形；

■ 拥塞管理与避免；

■ 带宽预留。

7.2.1 支持IPv6的QoS特性

IPv6环境中所支持的QoS特性包括基于类的数据包标记与分类、队列技术（低延迟队列或LLQ）、基于类的流量整形、加权随机早期检测（WRED）与基于类的限速。IPv6所支持的所有QoS特性也皆可使用模块化QoS命令（MQC）进行配置。但IPv6不支持早于MQC特性的QoS特性，如cRTP、CAR（承诺访问速率）与优先级队列（PQ）。

建议读者在网络中部署某项特性之前先查看IPv6是否支持该特性。7.5节将会提供Cisco文档《Cisco IOS IPv6 特性对照表》的链接。

7.2.2 数据包头部、分类和标记

IPv4与IPv6的数据包头部是不同的，如图7-1所示。其中最重要的区别包括如下两点。

■ IPv6的地址字段（128位或16字节）要比IPv4大得多。

■ IPv6 的头部有20 位的流标签（Flow Label）字段。

地址字段比较大会影响到QoS的部署，因为IPv6头部（40字节）是传统IPv4头部相应字段大小（通常为20字节，但如果使用了一些不常用的可选项，有可能会比20字节大一些）的2倍。如果数据流是由一些非常小的数据包所组成的，那么IPv6数据包会给带宽带来极大的影响——如G.729语音流的数据包负载就只有20字节。因此，在以IPv6作为传输协议时，一定要慎之又慎，为小数据包流分配更多的带宽。

1.数据包分类

基于类的命令match可以对数据包进行分类，这个命令有一个可选的关键字ip，如例7-1所示。如果使用了ip这个关键字，那么分类就只会应用于IPv4数据包。如果没有使用ip这个关键字，那么分类的处理就会同时应用于IPv4和IPv6数据包。因此Cisco建议在配置网络时不要使用ip这个关键字。

2.数据包标记

当前，IPv6可以通过IPv6头部中的流量类型（Traffic Class）字段来实现QoS标记的功能。这个字段在图7-1中可以看到，同时1.2.4节中也曾经简短地介绍过这个字段。无论结构还是功能，IPv6数据包中的流量类型字段，都与IPv4头部中的服务类型（ToS）字段别无二致，它们都可以通过不同的服务类别（CS1到CS7）和差分服务代码点进行标记。

图7-1 IPv4与IPv6的数据包头部

例7-1 对IPv4和IPv6数据包进行分类

! This pair of class-maps matches on IPv4 and/or IPv6 DSCP values

Router(config)# class-map MULTIMEDIA-CONFERENCING-IPV4

Router(config-cmap)# match ip dscp af21

! Classifies only IPv4 traffic marked with DSCP AF21

Router(config)# class-map MULTIMEDIA-CONFERENCING-ALL

Router(config-cmap)# match dscp af21

! Classifies both IPv4 and IPv6 traffic marked with DSCP AF21

! This pair of class-maps matches on IPv4 and/or IPv6 IPP values

Router(config)# class-map MULTIMEDIA-CONFERENCING-ALL

Router(config-cmap)# match ip precedence 5

! Classifies only IPv4 traffic marked with IPP 5

Router(config)# class-map MULTIMEDIA-CONFERENCING-ALL

Router(config-cmap)# match precedence 5

! Classifies both IPv4 and IPv6 traffic marked with IPP 5

在使用基于类的set命令来标记数据包时，也有可选的ip关键字，如例7-2所示。如果使用了ip这个关键字，那么标记就只会应用于IPv4数据包。如果没有使用ip这个关键字，那么分类的处理就会同时应用于IPv4和IPv6数据包。因此Cisco建议在配置网络时不要使用ip这个关键字。

例7-2 对IPv4和IPv6数据包进行标记

Router(config)# policy-map IPv4-IPv6-MARKING

Router(config-pmap)# class MULTIMEDIA-CONFERENCING-IPv4

Router(config-pmap-c)# set ip dscp af21

! Marks only IPv4 traffic to DSCP AF21

Router(config-pmap)# class MULTIMEDIA-CONFERENCING-ALL

Router(config-pmap-c)# set dscp af21

! Marks both IPv4 and IPv6 packets to DSCP AF21

Router(config-pmap)# class-map MULTIMEDIA-CONFERENCING-IPv4

Router(config-pmap-c)# set ip precedence 5

! Mark only IPv4 traffic to IPP 5

Router(config-pmap)# class-map MULTIMEDIA-CONFERENCING-ALL

Router(config-pmap-c)# set precedence 5

! Marks both IPv4 and IPv6 traffic to IPP 5

IPv4和IPv6之间可以通过多种隧道技术实现共存。如果使用了这些隧道，那么正确识别和分类IPv6数据流就不会像在端到端的双栈环境中识别和分类原生的IPv4和IPv6数据包流那么简单。

如果数据流共存的方式不是通过隧道技术来实现的，那么可以使用match命令将IPv6流量区分出来（并进行分类和标记），如例7-3所示。

例7-3 分类IPv6数据流

Router(config)# class-map IPV6-TRAFFIC

Router(config-cmap)# match protocol ipv6

若IPv6流量通过隧道或封装技术被置于IPv4之内，那就需要使用NBAR2（基于网络的应用识别）命令来将这类流量区分出来，如例7-4所示。

例7-4 分类用隧道封装的IPv6流

Router(config)# class-map IPV6-TEREDO

Router(config-cmap)# match protocol teredo-ipv6-tunneled

! Matches IPv6 traffic tunneled with the Teredo method

Router(config)# class-map IPV6-ISATAP

Router(config-cmap)# match protocol isatap-ipv6-tunneled

! Matches IPv6 traffic tunneled with the ISATAP method

Router(config)# class-map IPV6-6TO4

Router(config-cmap)# match protocol sixtofour-ipv6-tunneled

! Matches IPv6 traffic tunneled with the 6to4 method

7.2.3 限速和整形

本书的第4章已经介绍了如何配置基于类的限速和整形，这些配置方法既适用于IPv4流量，也适用于IPv6流量。如果将IPv6流量划分到一个独立的类别中，那么就可以使用不同于IPv4流量的参数来对IPv6流量进行限速或整形。

而本书的第5章则介绍了基于类的队列和包丢弃技术，这些配置方法亦同时适用于IPv4与IPv6流量。如果将IPv6流量划分到一个独立的类别中，那么就可以使用不同于IPv4流量的参数来对IPv6流量进行列队和丢弃。

7.3 建议和指导

Cisco建议管理员不要在命令set和match中添加关键字ip，这样实施的QoS策略可以适用于所有的数据包，无论传输层协议是IPv4还是IPv6。

总的来说，QoS命令不会区分IPv4和IPv6流量。在语法命令不变的情况下，网路中部署的限速、整形、队列和丢弃配置适用于这两种类型的流量。这是最灵活也最包容的网络配置方案。

如果确有需要将IPv6流量单独进行考虑，因为客观环境要求按照一种不同于IPv4流量的方式来处理IPv6 流量，那么可以使用NBAR2 的命令match protocol 来将IPv4 流量划入到一个独立的类中，并针对这个类部署一些不同于IPv4流量的策略。不过，这毕竟只是一种临时的解决方案，因为IPv4和IPv6的混合流量很有可能会在这个网络中长期共存，而针对不同类别的流量如何分配带宽、如何分别进行处理，这都很有可能需要不断地进行修改和完善。

IPv6的头部要比IPv4大得多，因此要确定为纯IPv6小数据包所组成的流量，或用IPv6封装的IPv4小数据包所组成的流量，分配了充足的带宽。

7.4 小结

当前，许多网络都处于IPv4到IPv6的长期过渡阶段。也就是说，在可以预见的未来，网络中的流量仍将长期以这两种协议的混合流量为主。因此，网络的设计者必须采取一些特定的网络部署方案，来处理同一个网络中的这两种流量，因为这两种流量本身是无法实现互操作的。有许多操作（如路由技术、隧道技术及双栈设备）本身超出了本书的范围，而本章内容所关注的，更多是IPv6协议对于网络中部署的QoS特性所带来的影响，其中包括:

■ QoS特性的命令语法大体可以无缝地管理传输协议，只有少数地方需要进行一点改动，譬如set和match命令中是否需要使用关键字ip等；

■ 要确保为小数据包组成的IPv6数据流分配了充足的带宽；

■ IPv6流量分类对于隧道技术的影响；

■ IPv4和IPv6都包含了8位的ToS字段，因此CS和DSCP数据包标记会自动转换。

7.5 扩展阅读

IPv6 QoS At-a-Glance（IPv6 QoS攻略）:http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8026004d.pdf

Implementing QoS for IPv6（为 IPv6 流量实施 QoS）:http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-qos.html

Application Visibility and Control for IPv6（IPv6的应用可见性与控制）:http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6553/aag_c45-665915.pdf

IPv6 Configuration Guide（IPv6配置指南）, Cisco IOS Release 15.2MT:http://www.cisco.com/en/US/docs/ios-xml/ios/ipv6/configuration/15-2mt/ip6-qos.html

Cisco IOS IPv6 Command Reference（Cisco IOS IPv6 命令参考）:http://www.cisco.com/en/US/docs/ios/ipv6/command/reference/ipv6_book.html

Cisco IOS IPv6 Feature Mapping（Cisco IOS IPv6特性对照表）:http://www.cisco.com/en/US/docs/ios-xml/ios/ipv6/configuration/15-2mt/ip6-roadmap.html

第8章 媒体网络

本章包含了如下主题:

■ 媒体网络的框架；

■ 媒体网络的特性，如Performance Monitor、Mediatrace 与流元数据。

在本书前7章中，我们介绍了如何通过一些专门的QoS工具来处理传统流量，也就是如何在IPv4和IPv6网路中对数据流执行分类、标记、限速、整形、拥塞管理、拥塞避免以及带宽预留等策略。但媒体网络这一章涵盖的范围更广，包含的主题和考量因素并不全都与QoS相关。本章会对媒体网络的架构进行介绍，其中的重点是从不同的角度来介绍如何配置某些特定的QoS策略，以及监测和控制技术。

8.1 介绍媒体网络

媒体网络是一个端到端的网络架构，这个网络包含了许多高级的工具、技术及设备，其作用是提供无处不在的最佳富媒体用户体验。当代网络中，富媒体应用的部署越来越多，这些应用会产生大量不同的数据流量，而用户也希望网络和设备能够给他们提供更好的使用体验，因此媒体网络已经成为了当代网络中必不可少的一个组成部分。

语音、视频和媒体应用的趋势如图8-1所示，所有这些应用都让媒体网络技术变得更加重要。这会使得网络的设计与管理出现如下几种趋势。

■ 应用不再只是生成单一的语音、视频或数据流量，而常常产生由语音、视频或数据流量共同组成的混合流量，具体是何种流量取决于用户目前正在使用应用的何种功能。

■ 网络中出现了不受控的应用，这些应用是由其他工作人员添加到网络中的，因此有可能并没有获得企业网络管理员的首肯。

■ 各类人员和企业大量使用移动设备，这些移动设备的用户把它们带到企业中来就是希望这些设备能够24小时不间断地工作。

图8-1 媒体网络应用的演化过程

Cisco WebEx 就是一个生成多类流量的重要应用实例，这个系统可以为处于不同位置的所有与会方提供文本、音频、即时消息、应用共享和桌面视频会议服务。WebEx这类应用摒弃了安装视频会议呼叫的冗杂过程，大大简化了视频呼叫的安装过程，同时可以在会议的基础上添加一些视频功能，整个过程就和安装其他媒体（比如音频媒体）一样简单。这些应用给网络管理员增加的麻烦与应用的分类有关:由于媒体应用包含语音、视频和数据等多种成分，因此如何对某一种媒体应用进行标记也就变得更加复杂和模糊了。而媒体网络的架构和工具则降低了配置、检测和排错的难度。

媒体网络架构具有如下特征。

■ 端点可感知能力:网络可以自动检测并配置媒体的端点。

■ 媒体可感知能力:网络可以检测并优化不同的流量、媒体和应用（如TelePresence、视频监控、桌面协作和流媒体），并为用户带来更好的网络使用体验。

■ 网络可感知能力:网路可以检测出网络中设备、连接、流量和服务的变化，并对变更作出响应。

注释:读者可以通过下面的网址进一步了解媒体网络的各种优势和解决方案:http://www.cisco.com/go/medianet。

8.2 媒体网络的架构与框架

媒体网络的框架让网络具备了感知应用和媒体的功能，使网络能够智能地应用重要的网络服务。媒体网络的框架同时也可以让富媒体应用具备感知网络的功能，让这些应用可以动态地适应网络的条件。将网络的功能与应用的功能集成在一起，可以更好地为终端用户提供服务，这种网络框架的用户体验要远远强于应用程序自己盲目地工作，或者网络完全不了解应用程序对于终端用户的价值，这种单兵作战的网络框架。

媒体网络框架中包含了网络的端点、接入层、分布层和核心层这四部分。在这种框架中，网络的边界扩展到了端点的位置，网络服务与富媒体应用之间也更加紧密地结合在了一起。图8-2所示为媒体网络的架构框架。

图8-2 媒体网络的架构与框架

媒体网络架构包括以下几部分。

■ 端点:媒体网络中必须能够部署各类不同的端点设备，包括视频监控摄像头、桌面客户端应用、视频与语音端点和仿真TelePresence会话。

■ 网络服务:指端点、代理、路由器和交换机所包含的功能，包括自动配置的功能、监测网络行为的功能、根据策略处理媒体流的功能、在网络中传输信息、提供共享服务和连续处理流量的功能，具体包含:

■ 接入服务；

■ 传输服务；

■ 桥接服务；

■ 存储服务。

■ 云服务:可以将媒体网络功能扩展到企业之外的网络中，让用户能够体验到服务提供商到企业、企业到企业、企业到消费者之间的优质媒体服务。

8.3 媒体网络的特性和能力

如图8-3所示，媒体网络的网络架构采取了分层的结构，在网络中实现QoS特性和功能。

图8-3 媒体网络:分层的特性

这个框架中的媒体网络特性与功能包括以下几层。

■ 自动配置:可以简化并随时部署各类富媒体端点（如IP监控摄像头、IP电话和数据媒体播放器）。

■ 媒体监测:提供各类工具来对网络功能进行规划，对网络性能进行监测，对网络故障动态排错，以降低网络维护的成本。

■ 媒体可感知:能够区分应用，以实现端到端的服务保障并优化用户体验。

上述内容本书均会从功能的角度通过下面几节进行介绍。

注释:读者可以通过下面的媒体网络（Medianet）页面，来进一步了解最新的媒体网络功能，以及各类产品和系统中分别包含了哪些特性:http://www.cisco.com/en/US/prod/collateral/routers/ps10536/data_sheet_c78-612429.pdf。

8.3.1 自动配置

在园区网环境中，自动配置功能可以让部署（配置和注册）富媒体端点的工作变得更加轻松，减少网络变更和配置QoS特性的操作环节。

1.Auto Smartports

接入交换机上的Smartport宏命令可以对交换机的端口或VLAN接口进行静态（Smartport特性）或动态（Auto Smartport 特性）的配置。这些预先定义在Catalyst IOS 交换机软件中的宏命令包括以下几项。

■ 配置与Cisco IP 电话相连的端口（包括在交换机端口上配置和执行AutoQoS VoIP）。

■ 配置与Cisco 数码媒体播放器（DMP）相连的端口。

■ 配置与Cisco IP 视频监控（IPVS）摄像头相连的端口。

■ （使用802.1Q 协议）配置与其他Cisco Catalyst 交换机之间的连接。

■ 配置其他Cisco路由器和Cisco无线接入点。

2.AutoQoS

AutoQoS特性可以简化在接入交换机和接入路由器上部署QoS的工作。AutoQoS特性可以自动为语音、基于IP的视频应用（如IPVS、Cisco TelePresence、会议应用和流视频应用），以及各类数据应用设置QoS最佳做法设计方案。

管理员可以通过一个接口级别的命令自动配置最佳做法的QoS设计方案，这条接口级别的命令与该接口相连的端点类型有关。相关的命令包括下列几项。

■ auto qos voip [ cisco-phone | cisco-softphone | trust ]

■ auto qos trust { cos | dscp }

■ auto qos video [ cts | ip-camera ]

■ auto qos classify { police }

本书已经在第2章中对AutoQoS的特性与功能进行过介绍，通过相关的内容也可以参见本书的在线附录A。

8.3.2 媒体监测

媒体网络的媒体监测功能可以让管理员实时观察到网络的真正性能。无论是真正的应用数据流，还是会话或仿真流量都可以通过媒体监测功能来评估网络应用的影响。媒体监测可以让管理员观测到网络流的具体信息，并协助管理员降低操作成本，更快地对使用富媒体流的应用进行排错。

媒体监测由三种特性组成:

■ 媒体追踪；

■ 性能监测；

■ IPSLA 视频操作（IPSLAVO）（流量创建与模拟）。

这三种特性构成了一系列的工具，这些工具可以让网络工程师监测媒体的性能，并显著降低他们排错的工作量。

1.媒体追踪

媒体追踪的概念与traceroute功能类似，它们都采用一种逐跳记录路径的方式来指出某个（模拟的）数据流所遵循的网络路径。媒体追踪技术针对实时应用进行了功能上的强化，但它还是沿用了在中间网络中逐跳返回信息的方式，来提供数据流从源到目的之间所经过的路径。在每一跳，返回给网络工程师的信息都可以体现出这个数据流在这一跳所接受的处理，其中包括实时的性能参数。

此前的traceroute特性会追踪路由器IP地址（这个地址往往是目的地址方向的出站接口地址）。媒体追踪特性对traceroute进行了强化，可以适用于源地址为摄像机（或一台设备）真实地址的环境。如果路由器到目的地址之间存在多条路径（往往是为了实现负载分担），这种功能就会相当有效。媒体追踪特性可以告知网络技术人员一条数据流每一跳入站和出站接口的名称，当然前提是这条路径中每一跳的设备都支持媒体追踪技术。如果路径中有些设备不支持媒体追踪技术，那么将媒体追踪技术与traceroute结合起来使用就是一种非常实用的做法:traceroute可以发现网络中两点间每一跳的地址（如果这两点之间只有一条路径），而媒体追踪则可以发现它们之间的实际路径，但有可能并不会报告它们值中每一跳的信息。

信息资源可以让网络工程师迅速察觉到数据包有可能在哪里被重新进行了标记（并导致QoS服务无法在这里贯彻执行），或者数据包在哪里遭到了丢弃，抑或网络中哪里出现了拥塞等。媒体追踪与traceroute类似，也是从网络中的某一点发起的（这一点也就是网络工程师的所在位置）。流量在这里就会受到追踪，媒体追踪技术会向路径中的每一跳垂询统计数据，所有相关信息都会返回给初始设备以兹网络工程师进行分析。一旦网络中配置了媒体追踪技术，网络工程师无需访问命令行界面即可以了解某条数据流的统计信息了。

2.媒体追踪的配置

网络中的某台设备会首先开始进行媒体追踪轮询，而这台设备往往是接入交换机。对于每一台需要获取信息的网络设备（比如路由器或交换机），都应启用媒体追踪响应（Mediatrace Responder）功能（这是一次性的配置，一旦配置，这台设备上就会一直运用这项服务）。对于网络中负责发起轮询并输出信息以供工程师查看的那台设备，管理员也必须将其配置为媒体追踪发起（Mediatrace Initiator）功能。

媒体追踪响应功能需要在CLI的全局配置模式下启用，工程师希望接收轮询信息的所有设备上都应该启用这项功能。媒体追踪发起功能也需要在CLI界面的全局配置模式下启用，但只需在发送轮询并接收响应信息的设备上才需要配置这一功能。图8-4所示为在媒体网络路径中所涉及全部交换机和路由器上启用了媒体追踪响应功能，同时在边缘路由器上启用媒体追踪发起功能的配置案例。

图8-4 媒体追踪的配置

3.媒体追踪的操作

使用mediatrace poll 命令配置了媒体追踪发起功能的设备会发起网络统计信息的轮询。这条命令有许多可选项和可选功能，读者如需了解详细信息，可以查看8.5节的媒体追踪命令参考（Mediatrace Command Reference）条目。

例8-1所示为针对特定流收集性能监控信息（由perf-mon选项指定）的轮询示例。

例8-1 媒体追踪性能监测轮询

! This command initiates a performance monitor request for the

! flow path from source IP address 10.87.93.162 to destination

! IP address 10.87.80.11

CAT3750# mediatrace poll path source 10.87.93.162 destination 10.87.80.11 perf-mon

Started the data fetch operation.

Waiting for data from hops.

This may take several seconds to complete...

Data received for hop 0

Data received for hop 1

Data received for hop 2

Data fetch complete.

图8-5 所示为mediatrace poll 命令所收集和显示出的信息。在输出信息中，可以看到路径中一共包含3跳:在第1跳和第3跳中，数据包的DSCP（差分服务代码点）值被标记为了0x20，但在第2跳中，这个值则被标记为了0，这足以说明这一跳设备疏于对数据流执行QoS处理，这种情况可能是因这台设备（或这台设备上游的某台设备）配置不当所致。通过排错信息，网络技术人员可以迅速发现实时数据流在网络中没有得到QoS处理，并能通过这些信息及时分析问题，解决问题。

图8-5 媒体追踪的输出信息示例

图8-5 左下方方框中的内容显示了mediatrace poll 命令返回的大量性能参数，包括大量实时传输协议（RIP）的统计数据。

注释:读者如需了解这条命令可以提供的详细信息，可以查看8.5节的媒体监测配置指南（Media Monitoring Configuration Guide）条目所引述的文档（在该文档中，读者可以查看“Mediatrace[ 媒体追踪]”部分，在该部分中，查看“Metrics That You Can Collect Using Cisco Mediatrace[可以通过Cisco媒体追踪技术获取的参数]”这一部分内容）。

媒体追踪功能会以RSVP（资源预留协议）作为传输协议。不过，这里并没有呼叫准入控制（CAC）和带宽预留的概念；RSVP封装在这里只会充当一种传输协议，来传输媒体监测信息，也就是说其他与RSVP相关的功能是不能在这里使用的。注意，在配置网络节点时，不需要手动启用RSVP，因为mediatrace responder这条命令就会自动启用与媒体追踪技术相关的RSVP功能。

管理员可以通过CPCM（Cisco Prime Collaboration Manager），以图形化的形式接收统计信息。对于无法通过CLI访问路径中某台（或所有）设备的网络技术人员而言，这种方式尤为重要。只要能够通过CLI访问这些设备的人启用了基本的媒体追踪特性（包括媒体追踪响应功能与媒体追踪发起功能），网络技术人员就可以通过CPCM控制台来执行轮询和排错，而无需再通过CLI来访问这些网络设备了。此外，流量在穿越几跳设备时即会产生庞大数据信息，数据量之大，也不适宜通过CLI进行处理和分析。

4.性能监测

媒体监测工具箱中的第二个工具就是性能监测。这个特性可以帮助管理员实时查看网络的实际性能。相比之下，媒体追踪属于问题排查工具，而性能监测则属于监测工具，无论网络是否报错，都可以用它来查看数据流的具体信息。

主动的性能监测技术对于视频流量特别重要，因为高质量的交互视频流量对于网络问题极为敏感。性能监测对于测量网络中（新的或计划中的）应用的流量相当重要。

性能监测技术利用了Cisco 的Flexible NetFlow（FnF）技术，它们的配置方法也相当类似。Cisco FnF 可以对穿越路由器的数据包提供统计数据，是获取IP 网络中IP 操作数据的一项标准工具。

图8-6显示了性能监测特性的配置方法。

图8-6 性能监测的配置

例8-2所示为性能监测特性的配置方法。

例8-2 性能监测特性的配置

! This configuration monitors TCP metrics on HTTP traffic

! Define the access list to match HTTP traffic

Router(config)# ip access-list extended HTTP

Router(config-ext-nacl)#)# permit tcp any any eq www

! Classify all HTTP traffic into the class TCP-CLASS

Router(config)# class-map match-all TCP-CLASS

Router(config-cmap)# match access-group name HTTP

! Define the default NetFlow capabilities in the policy

Router(config)# policy-map type performance-monitor TCP-METRIC

Router(config-pmap-c)# class TCP-CLASS

Router(config-pmap-c)# flow monitor inline

Router(config-pmap-c)# record default-tcp

! Attach the policy to monitor performance on the interface

Router(config)# interface GigabitEthernet0/2

Router(config-if)# service-policy type performance-monitor input TCP-METRIC

Router(config-if)# service-policy type performance-monitor output TCP-METRIC

除了NetFlow收集器和分析器之外（它们的结果可以通过GUI界面进行查看），性能监测的结果也可以通过在CLI 界面中使用命令show performance monitor status 来进行查看。此外，管理员也可以使用SNMP（简单网络管理协议）工具来搜集和输出NetFlow管理信息数据库（MIB）的信息。

5.IPSLA视频操作（流量模拟、IPSLA VO）

Cisco IOS IP SLA（服务等级协议）是一项标准的Cisco IOS 系统特性，这项特性可供使用已有经年。这项协议可以主动监测网络的性能，以帮助管理员理解IP的服务级别。这项协议可以用来对网络进行排错、对网络的部署进行评估、对网络的健康情况进行监测。

Cisco IP SLA 视频操作（IPSLA VO）是对标准IP SLA 特性集的强化，而后者可以模拟网络中各种类型的音频流量。增强的版本可以评估视频流量的影响和服务级别。可以充当IPSLA VO源或响应设备的设备只能是Cisco路由器和交换机，而且这些路由器和交换机必须能够在平台的帮助下创建视频流量并作出响应。

IPSLAVO 与其他IP SLA 的操作不同，因为所有的流量都是单向的，响应设备需要在本地处理序列号和时间戳，它会等到源设备发来请求之后，才将计算好的数据发送回去。

例8-3 所示为IPSLAVO 的配置中最重要的部分。

例8-3 IPSLA VO的配置

! This configuration turns on IP SLA operation number 10

Router(config-term)# ip sla 10

!

! A TelePresence profile is enabled for this IPSLA VO

Router(config-ip-sla)# video 192.168.2.17 997 source-ip 192.168.2.16 source-port 555

profile telepresence

表8-1 所示为截止到Cisco IOS 15.2(2)T 系统，各类视频流量的汇总信息。

表8-1 视频流量的特征

续表

注释:读者如需了解IP SLA视频操作配置的具体信息，可以查看8.5节的配置IP SLA视频操作（Configuring IP SLAs Video Operations）条目所引述的文档。

8.3.3 媒体可感知

媒体可感知技术可以让网络感知到网络中的应用与富媒体，因此网络可以与视频端点与应用一起为终端用户提供更好的网络使用体验，并帮助网络技术人员进一步了解网络中的情况。

媒体可感知技术由4部分组成。

■ 流元数据（Flow metadata）在整个网络中管理和分发应用的属性，这可以保证网络应用的策略是合理的，并且自动学习网络流量的特征。

■ NBAR2（基于网络的应用识别）将早期的NBAR功能与流元数据功能结合了起来，增加了NBAR的功能。

■ 媒体服务接口（MSI）是Cisco视频端点中包含的一个中间件，它可以将设备的功能宣告给网络。

■ 媒体服务代理（MSP）可以生成流元数据属性，这些属性可以在各个不会自行生成这类信息的网络节点之间共享。

1.流元数据

流元数据特性的作用是为了解决富媒体应用流量分类所面临的难题。其中第一大难题在于富媒体流来源于大量以HTTP（超文本传输协议）作为传输层协议的应用（用HTTP 80 端口传输未加密流量，用HTTPS 443 端口传输加密流量），这类应用的数量还在不断扩大。一时间， HTTP就是新TCP协议的说法甚嚣尘上，这种说法也就暗示了应用媒体类型和数据流也就不像过去那么容易通过协议和端口（传输的流量特征五元组）进行区分了。

许多富媒体应用（如WebEx）也会同时以不同类型的流量建立会话。流元数据特性为此在应用中引入了一个新的专门信息（也就是元数据），通过这种信息可以轻松地区分流量的特征与类型。

对富媒体流量进行分类的第二大难题在于所有应用QoS策略的节点都要对流量进行识别和分类，而节点之间无法共享它们对于同一组数据流的信息。通过元数据特性，节点可以对应用数据流的特征进行标记（标记上<Attribute><Vaule>数据对），然后把它们整理到一个控制平面的数据库中，再将这些信息分发给其他的节点，这种方式与路由更新的概念不无相似之处。通过这种方式，一个节点学习到的数据流信息也可以由其他节点进行使用，以便它们应用相应的QoS策略。

流元数据特性引入了创建者（producer）和使用者（consumer）的概念。有些网络设备会在应用流量中创建元数据信息（创建信息的设备往往是源节点或接近源的节点），而其他节点则会使用这些信息来应用相应的策略。经过配置，许多拥有元数据属性的Cisco端点（如TelePresence端点）都可以将自己“宣告”到网络中，这些应用和端点扮演的就是元数据创建者的角色。而路由器和交换机等网络基础设备则是元数据的使用者，这些节点会根据元数据的属性执行匹配，然后对其实施相应的QoS策略。

应用流量的元数据提供的信息要比传统的五元组多得多。同时，数据流是否经过加密也不会影响到元数据的信息。元数据属性与传统的五元组一样，都包含了许多描述数据流的信息，但元数据并不属于数据流中的一部分。图8-7提供了流量元数据特性中的应用信息。

图8-7 流量元数据中包含的信息

流元数据信息会在使用RSVP PATH 消息的节点之间传播。但和本章早先介绍的媒体追踪特性一样，RSVP在这里也只是充当一种纯粹的传输协议，因此启用这个特性时，并不需要专门对RSVP进行配置。不过，如果有防火墙的话，需要对防火墙进行配置，使其放行RSVP消息（RSVP使用的是IP协议号46），否则元数据就无法穿越防火墙进行传播了。

在全局配置模式下使用命令metadata flow 和metadata flow transmit 可以启用流元数据特性，命令show metadata application table 和show metadata flow local-flow-id <n> 可以用来查看这个节点当前了解的元数据信息。读者如需了解元数据配置的具体信息，可以查看8.5节的元数据配置指南（Metadata Configuration Guide）和元数据参考命令（ Metadata Command Reference）条目所引述的文档。

2.基于网络的应用识别

传统的NBAR 功能（也就是通过match protocol 命令来激活的那种NBAR 特性）已经在本书第3章中进行了介绍。NBAR2则在那种技术的基础上结合了元数据的特性，可以在网络中让设备扮演元数据创建者和使用者的角色。这些功能可以通过命令match application来启用。

命令match application 可以根据元数据对流量进行分类，这条命令包含了例8-4 中所示的4个可选项。

例8-4 流元数据配置命令的可选项

! This configuration turns on IP SLA operation number 10

Router(config-cmap)# match application attribute ?

category　Category attribute to match

device-class Device Class attribute to match

media-type Media type attribute to match

sub-category Sub Category attribute to match

图8-8 显示了match application 命令这4 种可选项有可能分类的应用。

传统的NBAR特性很难了解到这个节点是如何对流量进行分类的，而NBAR2的命令match application 以及metadata flow transmit 则可以将NBAR2 创建的应用元数据发送给相邻的节点。例8-5所示为实现这一功能的相关配置方法。

图8-8 NBAR2流元数据配置的可选项

例8-5 NBAR与元数据的集成

! These commands enable metadata to be collected on the node

! and transmitted to neighboring nodes

Router(config)# metadata flow

Router(config)# metadata flow transmit

! Define a class to classify/match WebEx application traffic

Router(config)# class-map CLASS-1

Router(config-cmap)# match application webex-meeting

! Define a policy for the class of traffic

Router(config)# policy-map POLICY-1

Router(config-pmap)# class CLASS-1

! <specify the QoS action for the specific application class>

! Attach the policy to the interface

Router(config)# interface gigabitethernet 0/0

Router(config-if)# service-policy output POLICY-1

3.媒体服务接口

媒体服务接口（MSI）是视频端点和协作应用中内置的中间件软件。MSI组件（如WebEx或Jabber客户端）负责将应用的流元数据宣告给网络，并且让端点设备与（本章刚刚介绍的）媒体追踪特性和性能监测功能完美地结合起来。Windows和Linux操作系统中都提供了应用程序编程接口（API），也可以在Cisco.com中进行下载。

4.媒体服务代理

媒体服务代理（MSP）是网络基础设施的一项功能，可以为没有嵌入MSI组建的非Cisco端点或Cisco端点提供媒体网服务。接入交换机或路由器都具有这项功能，它们可以自动学习与设备和数据流有关的信息。

Cisco IOS 设备的传感器特性可以通过各种协议（如CDP[Cisco 发现协议]、LLDP[ 链路层发现协议]和DHCP[动态主机控制协议]），收集端点设备的信息。MSP可以利用设备传感器的框架来获取其他协议（如mDNS[组播域名系统]、H.323和SIP[会话初始化协议]）的信息。这种机制如图8-9所示。

一旦掌握了与网络相连的设备的相关信息，这些信息就会在元数据库中进行分享，于是媒体网就可以为第三方设备和那些无法感知媒体网功能的设备与端点，提供与具有媒体网功能的设备类似的服务。

图8-9 用媒体服务代理充当元数据创建者

8.4 小结

媒体网络是一个端到端的网络框架，其作用是提供无处不在的最佳富媒体用户体验。这个网络架构中包含了端点设备、网络基础设施及云服务。Cisco IOS 仍在不断地开发媒体网络的特性与功能，而本章的目的就是对当前可用的功能进行简短的介绍，其中包括下述功能。

■ 自动配置:交换机上的Auto Smartports 特性可以自动配置交换机的端口，来满足与这些端口相连的设备。AutoQoS QoS 特性会自动在交换机和路由器上配置一些具体的QoS特性（如分类、限速和队列等）。

■ 媒体监测:Mediatrace特性可以大大提高排错的效率，因为这项特性可以获取到媒体流所循路径的信息。而Performance Monitor 特性可以通过具体的数据来查看许多网络性能的参数。IPSLA VO 特性则可以在网络中模拟各类不同的视频流，以预测网络的性能。

■ 媒体可感知:这类技术可以根据一些独特的属性（元数据）来区分应用与数据流量，而这些流量通过传统的五大特征（五元组）是无法识别出来的。此外，不同的网络设备之间可以共享元数据，使网络能够自动习得数据流的信息，并为它们应用相应的策略。MSI可以为端点提供中间件，将端点的元数据宣告给网络，且MSP可以为不具备MSI功能的端点提供代理服务。

8.5 扩展阅读

8.5.1 概述

Medianet Overview（媒体网络概述）:http://www.cisco.com/go/medianet

Cisco Networking Capabilities for Medianet Datasheet（Cisco网络功能之媒体网络数据表）:http://www.cisco.com/en/US/prod/collateral/routers/ps10536/data_sheet_c78-612429.pdf

Medianet QoS Design Strategy At-a-Glance（媒体网络QoS 设计战略概述）:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/qosmrn.pdf

AutoQoS for Medianet Campus Networks At-a-Glance（媒体网络园区网AutoQoS概述）:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/autoqosmediacampus.pdf

Medianet Architecture:http://cisco.com/web/solutions/trends/medianet/indepth.html

Medianet ASR 1000 QoS Design At-a-Glance（媒体网络ASR 1000QoS设计概述）:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/qoswanaggasraag.html

Medianet Reference Guide（媒体网络参考指南）:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/Medianet_Ref_Gd/medianet_DG.pdf

8.5.2 设计文档

Enterprise Medianet Quality of Service Design 4.0—Overview（企业媒体网络服务质量设计4.0—概述）:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSIntro_40.html

Medianet Campus QoS Design 4.0（媒体网络园区QoS 设计4.0）:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSCampus_40.html

8.5.3 配置指南和命令说明

Media Monitoring Configuration Guide（媒体监测配置指南）:http://www.cisco.com/en/US/docs/ios-xml/ios/media_monitoring/configuration/15-mt/mm-15-mt-book.html

Media Monitoring Command Reference（媒体监测命令参考）:http://www.cisco.com/en/US/docs/ios/media_monitoring/command/reference/mm_book.html

Configuring IP SLAs Video Operations（配置IP SLA 视频操作）:http://www.cisco.com/en/US/docs/ios-xml/ios/ipsla/configuration/12-2se/sla_video.html

IP SLAs Command Reference（IP SLA 命令参考）:http://www.cisco.com/en/US/docs/ios-xml/ios/ipsla/command/sla-cr-book.html

NBAR Configuration Guide（NBAR 配置指南）, Cisco IOS Release 15M&T:http://cisco.com/en/US/docs/ios-xml/ios/qos_nbar/configuration/15-2mt/qos-nbar-15-2mt-book.html

Metadata Configuration Guide（元数据配置指南）:http://cisco.com/en/US/docs/ios-xml/ios/mdata/configuration/15-mt/mdata-15-mt-book.html

Metadata Command Reference（元数据参考命令）:http://cisco.com/en/US/docs/ios-xml/ios/mdata/command/mdata-cr-book.html

Media Services Proxy Configuration Guide（媒体服务代理配置指南）:http://cisco.com/en/US/docs/ios-xml/ios/msp/configuration/15-mt/media-ser-prxy.html

Media Services Proxy Command Reference（媒体服务代理命令参考）:http://cisco.com/en/US/docs/ios-xml/ios/msp/command/reference/guide/msp-cr-book.html

8.5.4 资源和服务

Medianet Knowledge Base Portal（媒体网络知识基础）:http://cisco.com/web/solutions/medianet/knowledgebase/index.html

Medianet Readiness Assessment Service（媒体网络准备评估服务）:http://cisco.com/go/mra

Cisco Developer Network for Medianet（Cisco开发商网络之媒体网络）:http://developer.cisco.com/web/mnets

第9章 应用可视性控制

本章包含了如下主题:

■ 应用可视性控制（AVC）使用案例；

■ AVC的工作原理；

■ AVC的构成；

■ 使用AVC的性能考量。

在IP网络初期，根据TCP或UDP的端口号来对不同的流量进行识别、分类和控制曾经一度是一项十分简单的任务。不过，随着应用程序日渐成熟（特别是在过去几年间），越来越多的应用都无法再通过这种传统的方式进行识别了。于是，基于TCP或UDP端口号的传统分类方法也就日益难以满足在网络边界实施QoS（服务质量）战略的需要。

举例而言，在过去，每个应用都会为不同的流量分别使用一个周知（well-known）的TCP或UDP端口。电子邮件、网页浏览、线上视频流、企业智能工具等，都是通过周知端口来实现信息交互的。但时至今日，诸如WebEx、企业智能工具、客户关系管理（CRM）应用、OWA（Outlook Web Access）、即时消息等，都可以以HTTP 进行传输，并通过网页浏览器来实现。甚至有人放言:“HTTP已经成为了新一代的TCP协议”。

个中挑战在于，QoS分类工具通常是依靠TCP/IP头部中的字段来识别流量的类型。当前，大多数重要的应用程序（实时应用及其他）都通过网页浏览器来使用的现象早已不足为奇。在这样的情况下，设备要想“夺回”网络流量的知情权和控制权，就必须深入了解这些通过HTTP会话（或其他上层协议）传输的应用究竟是什么类型的应用。虽然在过去，人们直观上也不觉得HTTP和HTTPS算是什么“上层”协议，但到了今天，对于许多新的应用而言， HTTP真的变成了一种传输协议。对于这些以HTTP作为传输机制的新型应用，我们甚至可以认为它们工作在应用层的应用层。

为了解释清楚新形势下的挑战，读者不妨假想这样一个环境:你的企业为带宽敏感应用制定了严格的策略，因此，企业将P2P、文件共享和视频应用都严格限制在了网络中的尽力而为传输这一类别中。但是，由于这些应用都被内嵌在了HTTP会话中，甚至可能在用HTTP对其进行传输之前先对流量进行了加密，因此QoS策略几乎无法进行贯彻实施，这也让现有的QoS策略形同虚设。更惨的是，管理员可能对这些应用在网络中的使用情况毫无把握，也就是说网络管理员甚至不能对这种情况进行分析，以便改善自己的QoS策略。

在过去，人们关注的仅仅是协议而已，但现如今，协议已经不是唯一重要的因素；真正需要人们去管理的，是这些协议之上的应用。这正是AVC着力解决的问题。在一个设计无误的AVC部署环境中，人们不难发现许多实实在在的好处，其中包括:

■ 总的QoS策略，以及所有用户的QoE（体验质量）均可以通过应用可感知的网络优化与控制技术，而得到增强；

■ 可以实现主动监测，并提供端到端的应用可视性，因此可以帮助网络技术人员对应用性能进行排错；

■ 通过QoS工具集的应用，企业关键应用可以获得更好的优先级；

■ 可以在Internet边界、WAN边界、分支机构以及无线汇聚点，更好地控制内嵌在HTTP中的应用。

9.1 AVC使用案例

由于AVC的主要作用就是为了更加清晰地了解网络中应用的工作方式，因此AVC可以帮助网络技术人员控制这些应用，许多重要的场合都适合使用AVC技术。

早在Cisco首次引入AVC之时，就曾经提出了最适合使用AVC的两大场合，即Internet边界和网络WAN 汇聚点的Cisco ASR 1000 路由器上。在Internet 边界启用AVC 具有许多明显的优势，譬如Internet边界POP（存在点）的带宽可以始终限制在一个确定的数值范围之内，另一个优势在于网络技术人员可以同时观察和控制从这个点进入和离开的流量。WAN汇聚点同理可证（WAN 汇聚点有可能使用的是ASR 1000）。如果一个WAN 网络拥有成百上千个分支（spoke），那么，如果有一种技术能够限制每一个远端分支办公室的带宽，这对于那些希望深入了解WAN链路上各个应用行为的网络技术人员而言，无疑是很有吸引力的。

随着时间的推移，AVC 也被引入到了集成服务路由器（ISR）G2 设备之中。在ISR G2 也能够支持AVC 技术之后，AVC 就被人们部署在了分支办公室，以及其他没有使用ASR 1000的WAN及Internet边界POP环境中。

另一种部署AVC的设备是Cisco无线控制器（WLC）。在过去许多年的时间里，在WLC中部署AVC都是一种自然而然的选择，因为大量流量都会汇聚到一台控制器（或一个WLC集群）中。通过在WLC中部署AVC技术，网络设备就可以不再仅仅识别和控制企业无线网用户的应用，同时也对（使用相同网络设备的）客户无线网络的其他人群进行应用的识别和控制。在802.11无线网络中使用AVC的内容，将在本书第5部分进行详细的介绍。

注释:Cisco 汇聚服务路由器（ARS）1000 自IOS XE 3.4S 版开始，可以支持AVC 技术。Cisco ISR G2路由器自IOS 15.2(4)M2开始可以支持AVC，而WLC自AireOS 7.4版本开始可以支持AVC。

图9-1所示为当今网络中部署AVC最为常见的四大环境。

图9-1 四种使用AVC的典型环境

9.2 AVC的工作原理

顾名思义，AVC有两大作用:

■ 帮助网络技术人员了解（在网络中传输数据的）应用的具体信息；

■ 帮助网络技术人员控制这些应用。

由于目前大量应用使用的都是同一个协议（如HTTP），因此如果希望控制协议应用，就必须有一种比查看它们TCP或UDP端口号更行之有效的方法。AVC也可以让网络设备（如路由器）通过深度数据包监控（DAI）等技术，从应用层（而不是TCP/IP层）的深度来了解网络中的应用。

严格来说，AVC并不是一项技术，而是一种包含许多设计步骤的解决方案，这种能够将所有技术连接起来的步骤就叫做AVC。AVC设计过程包括下面几大重要的步骤。

1.通过NBAR（基于网络的应用识别）2发现应用。

2.通过FNF（Flexible NetFlow）收集、汇总并导出应用信息及性能参数，然后使用一种报告工具对数据进行分析。

3.根据前面两步中获得的信息来定义QoS控制策略。

图9-2显示了AVC的设计步骤。

图9-2 AVC的设计步骤

如图9-2所示，通过AVC设计和管理QoS的方式是一种连续的、周期性的行为，这种方式可以不断地自我完善QoS策略。在处理应用程序使用的动态操作方式，以及不断变化的网络环境时，这是一种非常实用的办法。

在网络中部署应用层QoS控制的这项任务，看上去难于上青天，因为设备没办法了解网络应用的工作原理。此外，网络技术人员也不知道每个应用会在WAN链路、Internet边界POP或WLC上产生多少数据。因此在第一步中，人们必须了解网络中各个应用的行为方式。例如，网络技术人员必须首先搞清楚社交网站会使用多少数据、YouTube会消耗多少带宽、P2P流量会产生多少并发连接等。

NBAR2就是一种AVC技术特性集，它会对数据流执行DPI，以帮助设备识别各种不同类型的流量。目前，大多数ISR G2、ASR 1000 系列路由器，以及AireOS 无线LAN 控制器上都可以支持NBAR2 特性。此外，NBAR2 也会在应用服务设施（Application Services Appliance） CX应用防火墙中充当DPI引擎。

不过，如果管理员的目的是在网络中实施强大的应用层QoS策略，那么仅仅能够识别和分类大量应用显然是不够的。在每个网络中使用的应用数量都有成百上千种之多，除非有一种更加简单的方式能够诠释和理解这些信息，否则这种技术对于在网络中应用合理的QoS技术这一最终目的而言，依旧杯水车薪。

因此人们才需要借助FNF。FNF是经典NetFlow特性集的增强版，Cisco对FNF的支持已有经年。与此前版本的NetFlow类似的是，FNF也可以分类IP流量，并识别这些流量源地址、目的地址和时间信息。但FNF增加了一项重要的新功能，这项功能可以增强AVC解决方案:FNF也可以利用NBAR2引擎来报告DPI应用信息。由于设备可以导出NBAR2提供的具体应用信息，以及其他相关的性能参数（如流量及延迟），因此网络技术人员也就可以使用网络管理工具对网络进行管理了。在启用了AVC的网络节点上，这些可以收集FNF报告的管理工具可以对于应用的性能和行为给出相当具体的图形化信息。

通过FNF报告工具提供的全新信息，网络技术人员就可以在网络中的各个节点部署有针对性的应用QoS工具。图9-3所示为前文中刚刚讨论过的AVC四大组成部分。

图9-3 AVC的四大组成部分

下面介绍如何在真实环境中使用上述AVC设计四步走原则。假设公司的管理层意识到公司网络中存在有人违规使用应用的情况。他们怀疑许多员工都把大量时间花在了BitTorrent、Facebook和YouTube上。这不但浪费了员工的工作时间，还占用了Internet和WAN上的大量可用带宽。为了证实自己的猜测，网络技术人员就可以在WAN汇聚点和Internet边界路由器上启用NBAR2，并通过FNF将数据导出到一个报告工具中。由此，管理员就可以看到YouTube的流量占用了大量的带宽，导致其他使用80端口的应用出现带宽不足的情况。要想解决这个问题，就可以在网络中的很多（支持NBAR2的）节点上启用QoS控制机制，以降低YouTube带给网络的负面影响。

这个简单的例子解释了如何遵循上面的四步走原则来对网络中一些应用的行为进行干预。本章会在接下来的内容中深入介绍在网络中的不同位置使用AVC的案例。

简而言之，AVC解决方案可以分为如下四大部分。

■ 第1部分:NBAR2。

■ 第2部分:FNF。

■ 第3部分:AVC报告工具。

■ 第4部分:应用QoS控制策略。

在下一节中，我们会对这四部分进行深入的介绍。

9.3 AVC的构成

恰如上一节中所介绍的南洋，部署AVC分为4个步骤。这四步骤将在后面几个小节中进行具体的探讨。

9.3.1 构成部分1:NBAR2

有些Cisco IOS 平台（如ISR 系列）早已开始对经典的NBAR 特性集提供支持。本书在第3章中介绍过，NBAR可以让路由器检视数据包的应用层。经典NBAR掌握的应用特征并不算很多，因此它的DPI功能也比较有限。

NBAR2（亦称为下一代NBAR）基于另一种Cisco产品（服务控制引擎[SCE]）对NBAR进行了彻头彻尾的重新设计。NBAR2包含了更加高级的分类方式，这种分类方式所掌握的特征比经典NBAR要多得多。此外，NBAR2还支持一种新的高级特征保真功能，这种技术可以显著提供设备根据特征匹配流量的准确性。

另外，NBAR2也成为了一种Cisco跨平台协议分类机制，也就是说，大量Cisco平台都支持相同的NBAR2特性。NBAR2支持超过1500种应用和子分类，Cisco每年还会向协议集中添加上百种新的应用特征。

NBAR2的一大重要特性在于，协议特征是以协议包的形式来传输的。协议包是指将多个协议打包到一个文件中。设备可以通过协议包向IOS路由器分发应用与协议特征的更新信息，而不需要升级或重启Cisco IOS 系统。虽然路由器也许能够下载并使用新的协议包，但任一设备每次只能有一个协议包处于“在用”状态。如果设备下载了一个新的协议包，它就会取代当前的协议包。每个IOS镜像文件都有一个内置的默认协议包。如果卸载掉在用的协议包，IOS系统就会回退到内置的默认协议包。

注释:在传统的NBAR中，协议应用模块曾经称为“包描述语音模块（PDLM）”。用于NBAR2技术的协议包与PDLM不同，它们是一个压缩文件，其中包含多个PDL文件。协议包可以让用户一次载入大量协议，而每次分别载入一个协议。

在协议包中，NBAR2 DPI 会把特征分为几大类，然后再在下面划分一些子类。例如，主类中包括浏览流量、业务与生产工具流量、电子邮件流量、文件共享流量等。子类对于类似应用的分类更加精细。例如，YouTube流量属于语音与视频（Voice and Video）大类、流媒体子类。此外，每个应用都会获得一个属性，以识别该流量是否属于P2P流量，是否进行了隧道封装或加密。

再以WebEx 和YouTube 为例，它们都属于语音和视频（Voice and Video）大类，但子类不同。YouTube的子类是流媒体（Streaming），而WebEx的子类则是语音视频聊天协作（Voice-Video-Chat Collaboration）类。此外，在WebEx默认属性中，加密（Encryption）被设置为是（Yes），而YouTube则正相反。

总之，NBAR2是按照如下方式对应用分类实施监控的。

■ 应用组（Application group）:也就是将同一个应用栈或同一个“品牌”的应用分为一组。如 Yahoo Messenger、Yahoo VoIP Messenger 和 Yahoo VoIP-over SIP 就都归于Yahoo Messenger 组中。

■ 大类（Category）:也就是将一个端点上支持类似功能的应用分为一组。如电子邮件、游戏、新闻等。

■ 子类（Subcategory）:对于一个设备或网络节点上具有类似功能的应用再次进行细分。如路由协议、数据库、流媒体等。

■ P2P技术（P2PTechnology）:为应用分配的属性，标明该应用是否使用了P2P技术。

■ 隧道（Tunnel）:NBAR2分配给应用的一种Boolean属性，标明该应用是否用其他协议进行了隧道封装。

■ 加密（Encrypted）:NBAR2分配给应用的一种Boolean属性，标明该应用是否进行了加密。

NBAR包括下面两种主要的操作模式，本章后面几节会对此进行详细介绍:

■ NBAR协议发现；

■ MQC流量分类。

注释:读者会发现，在本章中NBAR和NBAR2这两个术语会交替出现。因为NBAR2是以原NBAR技术为蓝本设计出来的特性集，因此它们的语法、命令结构和功能都比较类似。因此，虽然这两种缩写在本章中都会有所设计，但是它们指的基本是同一种技术。不过NBAR2是本章的重点。

1.NBAR2协议发现

在前一节中，我们介绍了NBAR2的分类方式。接下来，我们会介绍如何启用NBAR2协议发现，并用这种技术来分配应用。为了简化起见，NBAR2在这里使用了与经典NBAR相同的配置步骤。使用NBAR2分为两步。

1.在一个特定接口上启用NBAR 协议发现技术，让设备了解网络中的应用。

2.使用模块化QoS命令行界面（MQC）来分类协议。实际上，MQC与协议发现没什么关系，但MQC 会使用NBAR2 DPI 引擎来对流量进行分类，然后再对应用进行控制。

NBAR协议发现技术可以识别应用，可以获取当前网络应用的实时统计数据。接下来，可以使用协议发现技术获取的信息来创建QoS分类和策略。

注释:NBAR协议发展技术是这一小节的重点，而另一种使用NBAR DPI的技术——FNF，则会在本章稍后部分进行介绍。

协议发现技术与经典NBAR相同，它也需要在需要执行发现功能的接口上进行配置。一旦启用协议发现技术，它就会对穿越接口的应用提供实时统计数据。NBAR还可以提供另外的信息，如双向比特率、数据包计数和字节计数统计信息。

例9-1显示了如何配置NBAR协议发现技术。

例9-1 启用NBAR协议发现技术

ASR1002(config)# interface GigabitEthernet0/0/3

ASR1002(config-if)# ip nbar protocol-discovery

NBAR2的一个重要的方面在于，它也可以支持IPv6流量。例9-2显示了如何针对IPv6流量启用NBAR协议发现技术。

例9-2 针对IPv6流量启用NBAR协议发现技术

ASR1002(config)# interface GigabitEthernet0/0/3

ASR1002(config-if)# ip nbar protocol-discovery ipv6

一旦启用了协议发现技术，管理员就有可能看到每个接口上都发现了哪些应用。例9-3显示了Top-N报告的输出信息，该输出信息显示了接口GigabitEthernet0/0/3发现的头5个应用。

例9-3 5大NBAR活跃应用的显示结果

ASR1002# show ip nbar protocol-discover top-n 5

GigabitEthernet0/0/3

Input　　　　　Output

-----　　　　　------

Protocol　　Packet Count　　　Packet Count

Byte Count　　　　Byte Count

30sec Bit Rate (bps)　30sec Bit Rate (bps)

30sec Max Bit Rate (bps) 30sec Max Bit Rate

--------------- ------------------------ ---------------------

sunrpc　　　135　　　　　　2799106

21850　　　　　4237830347

0　　　　　　0

4000　　　　　47720000

ftp　　　92340159　　　　186761181

4989796991　　　　263959173216

211000　　　　　11160000

284000　　　　　15170000

netflix　　67438860　　　　84034631

51098349136　　　　100709287113

2171000　　　　　4223000

3278000　　　　　6476000

webex-meeting　45807530　　　　163458047

2497543722　　　　129842885217

115000　　　　　5998000

152000　　　　　7799000

bittorrent　　59667396　　　　156155174

12768822744　　　　103187176646

555000　　　　　4715000

697000　　　　　5077000

Top-N报告对于理解网络中（穿越NBAR发现接口的）一类协议和应用是相当有帮助的。这类信息在SNMP管理信息库（MID）CISCO-CLASS-BASED-QOS-MIB也可以方便地进行查询。

如例9-3 所示，BitTorrent 和Netflix（这类流量对于企业来说显然裨益不大）会消耗相当多的带宽，因此很适合对它们进行限制。但也要注意，协议发现这个称谓可能会引起一定程度的误解:NBAR2能做的要比发现一种协议要多得多，它的主要任务是发现通过上层协议执行传输的应用。

注意:有时候，命令show ipnbar protocol-discovery的输出信息会将协议表示为Unkown（未知）。这种情况有可能是因为以下三个原因导致的。

■ 有可能是因为设备没有这个应用的NBAR2特征。在这种情况下，管理员可以自定义特征。

■ 流量可能不对称。NBAR2需要通过对称流量才能发现一个应用的完整特征。

■ 分配给NBAR2的系统内存不足（详见9.4节中的信息）。

2.NBAR2 MQC流量分类

在介绍完NBAR协议发现技术之后，这一节的重点将是使用MQC来实现NBAR流量分类。NBAR协议发现技术是路由器上的一种机制，它可以凭借自身的功能来检测并实实在在地“发现”应用与协议，但是这项技术对于控制这些应用的行为毫无建树。

总地来说，NBAR 分类沿用了与其他协议相同的MQC QoS 分类语法。例9-4 所示为用来执行NBAR 应用分类的通用class map。

例9-4 创建一个NBAR class map

ISRG2(config)# class-map [match-any|match all] <CLASS-MAP-NAME>

ISRG2(config-cmap)# match protocol <application|attribute>

通过这种方式来创建class map 可以匹配某一项应用协议（如HTTP），也可以匹配整个应用协议组。例如，若技术人员想要创建一个class map 来匹配一个庞大的文件共享应用组。那么在这种情况下，技术人员就不会匹配一种特定的应用，而是一组应用。因此，必须使用关键字attribute来匹配一个大类或一个子类的应用，如例9-5所示。

例9-5 匹配文件共享应用的NBAR2 class map

ISRG2(config)# class-map MY-CLASS

ISRG2(config-cmap)# match protocol attribute category file-sharing

在这个案例中，class map会匹配拥有file-sharing这个属性的大类。但是在大多数情况下，大类的范围都有些过于宽泛，因此人们常常需要匹配一个更加具体的类别。比如说，读者不妨看一看特定协议的属性（如webex-meeting），如例9-6所示。

例9-6 查看NBAR2协议属性的具体内容

ISRG2# show ip nbar protocol-attribute webex-meeting

Protocol Name:webex-meeting

category:voice-and-video

sub-category:voice-video-chat-collaboration

application-group:webex-group

p2p-technology:p2p-tech-no

tunnel:tunnel-no

encrypted:encrypted-yes

在这个例子中，webex-meeting是总的协议属性，但这个协议是voice-and-video大类中的一部分，属于子类voice-video-chat-collaboration的应用组webex-group。此外，除了encrypted（加密）属性之外，其他属性均为no。在创建一个class map时，所有这些字段都会涉及。

NBAR2也可以帮助技术人员看到一个主类中都包含了哪些子类，一个子类中又包含了哪些应用。例如在创建class map 时，技术人员可能想要了解一下voice-video-chat-collaboration这个子类中支持哪些应用。例9-7的输出信息显示了这个子类中的各个应用。

例9-7 在子类中查看NBAR应用

ISRG2# show ip nbar attribute sub-category voice-video-chat-collaboration

aol-messenger　　　AOL Messenger Text Chat

aol-protocol　　　America OnLine protocol

bnet　　　　　bnet

cisco-phone　　　Cisco IP Phones and PC-based UC

conference　　　chat

cooltalk　　　　Internet telephony tool

cuseeme　　　　CU-SeeMe desktop video conference

directplay　　　DirectPlay

fring-voip　　　Fring Voip

通过IOS 命令也可以找到NBAR2 支持的所有子分类。例9-8 显示了运行IOS XE 3.7S 的ASR设备所支持的NBAR2子分类。

例9-8 查看NBAR2参数子分类

ASR1000# show ip nbar parameter subclassification

Protocol　　Parameter　　　Parameter type

--------　　---------　　　--------------

share-point　Blog　　　　enum

share-point　Document　　　enum

share-point　Admin　　　　enum

share-point　Calendar　　　enum

vnc　　　file-transfer　　enum

edonkey　　search-file-name　regexp

edonkey　　file-transfer　　regexp

edonkey　　text-chat　　　regexp

rtp　　　payload-type　　multi

rtp　　　video　　　　enum

rtp　　　audio　　　　enum

webex-meeting　payload-type　　multi

webex-meeting　video　　　　enum

webex-meeting　audio　　　　enum

kazaa2　　　file-transfer　　regexp

gnutella　　file-transfer　　regexp

fasttrack　　file-transfer　　regexp

citrix　　　app　　　　　regexp

citrix　　　ica-tag　　　　integer

http　　　mime　　　　regexp_url

http　　　content-encoding　regexp_url

http　　　location　　　regexp_url

http　　　server　　　　regexp_url

http　　　from　　　　regexp_url

http　　　referer　　　　regexp_url

http　　　user-agent　　　regexp_url

http　　　host　　　　regexp_url

http　　　url　　　　　regexp_url_nl

例9-9将上面介绍的内容加了在一起，在这个示例中，运行AVC的路由器有三个NBAR2 class map:

■ 一个用于 SAP 流量；

■ 一个用于一般的Internet浏览流量；

■ 一个专门匹配HTTP URI（也就是所谓的子分类）cisco.com。

例9-9 为各类应用组创建class map

ISRG2(config)# class-map match-all SAP

ISRG2(config-cmap)# match protocol sap

! Class map to match only the "sap" protocol

ISRG2(config)# class-map match-any BROWNSING

ISRG2(config-cmap)# match protocol attribute category browsing

! Class map to match the entire category of "browsing"

ISRG2(config)# class-map match-any INTERNAL-DATA

ISRG2(config-cmap)# match protocol http url "*cisco.com"

! Creates a class-map to match on "cisco.com"

通过show class-map 命令可以验证自己的配置。

AVC的第二个组成部分是FNF的导出功能，这部分内容是下一小节的重点。

9.3.2 构成部分2:Flexible NetFlow

AVC 解决方案第2 大重要组成部分是Flexible NetFlow（FNF）。在前面的章节中，我们介绍了如何启用NBAR2协议发现功能。而这种方法并不便于管理，在分析应用性能数据方面也显得比较麻烦。除了NBAR2 协议发现之外，我们也可以使用FNF 来收集DPI NBAR2 信息和流量统计数据，同时通过FNF NetFlow Version 9 或IP FIX（IP Flow Information Export）将数据导出到一个报告工具中。

NetFlow Version 9 并不是IETF 标准的方式（它被归在了信息[informational]的类别中），但它却是一种开放的标准，而Cisco已经公布了这项工具的规范，还有许多其他厂商也支持NetFlow Version 9。Cisco曾经长期与IETF合作以期将一种名为IPFIX的数据流导出格式标准化，而IPFIX也是IETF的标准。IPFIX并不像传统的NetFlow那样只能使用固定的字段，它可以使用灵活的字段，也就是说它可以只收集和报告与某些字段有关的数据。当路由器将数据导出到NetFlow收集器中时，数据流记录的格式也会一并通告给信息收集器，以便报告工具能够理解数据发送的方式。

FNF 会依靠NetFlow Version 9 和IPFIX 来导出数据流记录信息。如图9-4 所示，FNF 可以对传统的NetFlow功能进行扩展，使其包含更多的信息，包括第2层到第7层的协议栈信息。正是由于NetFlow Version 9 能够将具体应用统计数据导出，AVC 解决方案才能够得以实现，而最终的QoS控制策略也才能够得以应用。

1.Flexible NetFlow的关键字段和非关键字段

在学习如何在路由器上配置FNF之前，必须首先理解FNF的一项核心概念:关键字段与非关键字段。

图9-4 FNF涵盖的协议栈

对于启用了FNF接口而言，它会在发送每个数据包之前检查一系列的IP数据包属性，而这些属性都可以唯一地确定一组数据流。在FNF的专业术语中，这些属性都称为关键字段（key fields）。读者不妨将所谓的关键字段理解为数据库的索引信息。对于数据流而言，这些字段必须是唯一的。而非关键字段则不同，所谓非关键字段只是一组现有数据流中的一些属性或特征。

例如，如果一台路由器要对某些入站数据包进行检查，它会在检查了流缓存之后，意识到这组数据流的关键字段与任何现有流量的关键字段均不相同，于是路由器就会创建一个新的数据流记录。当这组会话继续通过路由器时，FNF会检查数据流的行为（如它的字节数和数据包数量），并最终将信息导出到数据流收集器中，不过路由器并不会使用这些信息来创建数据流。

在这个案例中，数据流的源和目的IP地址、源和目的端口、协议类型等都可以分辨出这组数据流，因此这些属性都是关键字段。而数据包和字节计数器等都属于数据流的特征，它们就是非关键字段。

图9-5显示了关键字段是如何在流缓存中唯一确定一组数据流的。

图9-5 两个数据包之后，FNF的关键字段与非关键字段

2.FNF的配置

在路由器上配置FNF的步骤如下所示。

1.配置流导出器（flow exporter）。

2.配置流记录（flow record）。

3.配置流监测（flow monitor） [2] 。

4.在相关接口上启用FNF。

步骤1 配置流导出器（Flow Exporter）

流导出器可以的作用是告诉路由器将FNF流记录发往哪里。FNF流记录往往需要发送给某种NetFlow 收集设备或FNF 管理工具（如Insight、Cisco Prime Infrastructure 或其他网络管理工具）。如有必要，可以将不同的流导出到不同的收集设备中。在例9-10中，管理员将所有FNF流都导出到了IP地址为172.16.1.1的收集设备中。此外，如有必要，还可以指定FNF收集器的UDP端口号。

例9-10 定义FNF流导出器

ISRG2(config)# flow exporter MY-EXPORTER

ISRG2(config-flow-exporter)# destination 172.16.1.1

ISRG2(config-flow-exporter)# transport udp 2055

! Pay attention to the UDP port number, as this may be different

! depending on what netflow collector is used

管理员可以通过命令show flow exporter name 来查看上述配置。

步骤2 配置流记录（Flow Record）

下一步是配置FNF流记录。流记录的作用是告诉路由器要对什么信息进行测量。例如，设备可以测量字节数和数据包数量、应用名称等。例9-11所示为在一个WAN接口上测量到的数据流量。

通过例9-11不难发现，流记录应该配置两个，一个用于入站方向，另一个则用于出站方向。如果在没有使用NBAR2的情况下使用FNF（也就是说配置FNF并不是识别应用），那么就可以跳过命令match application name。一旦通过协议发现技术或FNF 的match application命令激活了NBAR2，NBAR2就是双向启用的。换句话说，无论FNF是否在双向同时启用， NBAR2都会自动在接口的双方向上监控流量。但是，如果管理员在入向和出向上同时应用了FNF，FNF就可以同时收集出站和入站的流量，这可以方便管理员查看网络中应用的行为。通过例9-11，可以看到如何在双向配置FNF。

例9-11 配置FNF流记录

ISRG2(config)# flow record INPUT-APP-RECORD

! Use whatever name suits best – "INPUT-APP-RECORD" is used here

ISRG2(config-flow-record)# match interface input

ISRG2(config-flow-record)# match flow direction

! These two commands identify this as an "input flow"

ISRG2(config-flow-record)# match application name [account-on-resolution]

! This command uses NBAR2 to classify the application

ISRG2(config-flow-record)# collect counter packets

ISRG2(config-flow-record)# collect counter bytes

<snip>

ISRG2(config)# flow record OUTPUT-APP-RECORD

! The output (egress) flow record

ISRG2(config-flow-record)# match interface output

ISRG2(config-flow-record)# match flow direction

! These two commands identify this as an "output flow"

ISRG2(config-flow-record)# match application name [account-on-resolution]

! This command uses NBAR2 to classify the application

ISRG2(config-flow-record)# collect counter packets

ISRG2(config-flow-record)# collect counter bytes

例9-11中，流记录部分使用了两个不同的关键字。其中关键字match用来表示一个关键字段，因此该命令的作用是识别和创建数据流（关键字段的含义详见前文）。而关键字collect则用来表示非关键字段，因此用于数据流的附加信息，如字节数和数据包数等。

在例9-11中，命令match application name的作用是使用NBAR2来对应用进行识别和分类。但在有些案例中，NBAR2必须先查看过足够多的数据包之后，才能正确地分类应用。在这类情况下，可以使用可选的关键字account-on-resolution让路由器将计数器和计时器缓存进数据流表（flow table）中，直到NBAR2 能够正确地分类应用为止。例如，如果一名用户正在用自己的网页浏览器下载一个网页，那么这次通信发送的第一组数据包是进行TCP 握手（(SYN ->SYNACK -> ACK），下面则是发送HTTP GET。只有当网页浏览器看到HTTP GET 和HTTP 200响应消息之后，NBAR2才能将这次会话识别为一个HTTP连接。

在正确地分类了应用之后，应用名（Application Name）字段就会被设置为未知（Unknown）。在正确地对应用进行了分类之后，路由器就会开始在FNF缓存中进行计数，然后将先前缓存的计数器添加到数据流表中。

管理员可以通过命令show flow record 来查看流记录的配置。

步骤3 配置流监测（Flow Monitor）

第3步是配置流监测。流监测就是第2步中配置的流记录与第1步中配置的流导出器两者的连接之处。这种方法极为灵活，可以为不同的流记录自定义不同的导出方式。例如，通过创建不同的流监测，可以让不同的流记录检查数据流中的不同字段，然后再把它们导出到不同的设备之中。

配置流监测的另一个重点在于，管理员需要为数据流在不同方向上分别设置流记录。例9-12显示了如何配置FNF流监测。要注意管理员在这个案例中配置了两项流监测（和前面配置流记录的方式相同），其中一项用于入站方向，另一项则用于出站方向。

例9-12 配置入站和出站方向的FNF流监测项

ISRG2(config)# flow monitor MY-FLOW-MONITOR-IN

! Create the input flow monitor

ISRG2(config-flow-monitor)# record INPUT-APP-RECORD

! References the previously configured input flow record

ISRG2(config-flow-monitor)# exporter MY-EXPORTER

! Refers to the previously configured exporter "MY-EXPORTER"

<snip>

ISRG2(config)# flow monitor MY-FLOW-MONITOR-OUT

! Create the output flow monitor

ISRG2(config-flow-monitor)# record OUTPUT-APP-RECORD

! References the previously configured output flow record

ISRG2(config-flow-monitor)# exporter MY-EXPORTER

! Refers to the previously configured exporter "MY-EXPORTER"

管理员可以通过命令show flow monitor 来查看上述配置。

步骤4 在相关接口上启用FNF

配置FNF的最后一步是将流监测关联到一个接口，如例9-13所示。在一台WAN路由器上，这个接口往往是面向WAN的接口，而在Internet边界，这个接口则是朝向Internet的接口。这里一定要注意的一点是，流监测是有方向性的，因此在步骤3中配置的双向流监测都要添加到接口上，每个方向上绑定一个。

例9-13 在接口上启用流监测（Flow Monitor）

ISRG2(config)# interface GigabitEthernet3/0/0

ISRG2(config-if)# ip flow monitor MY-FLOW-MONITOR-IN input

! Attach the flow monitor in the ingress direction

ISRG2(config-if)# ip flow monitor MY-FLOW-MONITOR-OUT output

! Attach the flow monitor in the egress direction

管理员可以通过命令show flow monitor 来查看上述配置。

9.3.3 构成部分3:AVC的管理和报告

AVC解决方案的第3个组成部分是支持FNF收集器功能的管理与报告工具。同时这些管理和报告工具可以帮助管理员清晰地看到流经网络的流量与应用。Cisco并没有专门推荐的管理与报告工具。实际上，截止到本书创作之时，Cisco可以支持很多种管理工具，其中包括Insight Reporter、Cisco Prime Network Analysis Module (NAM) 和Cisco Prime Infrastructure。读者还应切记，AVC 使用的是公开标准的流导出机制（如NetFlow Version 9 和IPFIX）。因此，网络技术人员应该紧跟Cisco的步伐，以丰富监测功能，满足网络所需。

本书的主旨并不是对各项管理工具进行完整的说明，不过，我们会在下文中对Insight Reporter进行一个简短的介绍。

Insight Reporter

Insight Reporter 是一项复杂的管理工作，它可以收集NetFlow 9 记录，并以一种一目了然的方式将这些记录显示出来，以帮助管理员更好地了解网络中应该实施哪种应用层QoS工具。简言之，Cisco Insight 可以提供下列主要特性。

■ 看到各个接口的应用信息:

■ 显示数据使用情况（包括带宽、流量、持续时间、会话等）；

■ 显示应用的使用率排名（哪些是最受欢迎的应用）；

■ 监测应用的处理情况（Top-N报告、应用趋势）。

■ 数据的分组与过滤:

■ 显示应用的组别与ID（YouTube、BitTorrent等）；

■ 将应用分入不同的大类与子类中；

■ 显示哪些应用进行了加密或隧道封装。

■ 网络图形化显示与在线监测:

■ 网络中的用户排名；

■ 使用率趋势；

■ 跟踪用户的在线活动。

图9-6 显示了Cisco Insight 管理工具提供的报告，其中显示了FNF 报告提的多种协议与应用的活动情况。

最后，诸如Cisco Insight 等工具可以帮助管理员看到网络中应用活动情况的清晰图像。因此这些信息可以帮助网络技术人员判断网络中需要实施哪些应用层QoS策略，以及如何来搭建这些策略。这部分的内容会在AVC 的最后一个构成部分（AVC 的 QoS 控制）中进行介绍。

图9-6 Cisco Insight管理工具的报告示例

9.3.4 构成部分4:AVC的QoS控制

前面的3个构成部分可以帮助读者理解网络中应用的动态。可是，仅仅看到网络中有哪些应用正在使用、这些应用占用了多少带宽，这显然是不够的。应用性能代表了用户对网络性能的观感。例如，对于那些重要的（基于Web的）客户关系管理（CRM）应用，我们可能就要为其提供带宽保障，使其免受网络拥塞的困扰；而对于延延迟敏感的企业智能（BI）应用，我们则可能要提供低延迟的处理方式；至于那些烦人的P2P应用，我们甚至会对它进行严格的限制，让它们尽可能少地占用Internet边界资源。

下面的两个案例介绍了如何在WAN边界（第一个案例）和Internet边界部署AVC。

1.在WAN边界部署AVC QoS控制

假设一位网络技术人员想要在WAN 边界的一台ASR 1000 路由器上实施QoS 策略，这台路由器负责对HTTP流量进行识别，并可以将HTTP流量分类为不同的应用。表9-1总结了在ASR 1000WAN 边界路由器上推荐的QoS 处理方式。

表9-1 在Internet边界路由器ASR 1000上部署AVC QoS策略的示例

配置这些QoS策略包含如下3个步骤。

1.配置NBAR2 应用class map（见例9-14）。

2.配置相应的policy map（见例9-15）。

3.将policy map 绑定到正确的接口上（见例9-16）。

首先，为表9-1 中所示的每个应用分别创建class map。在对需要使用DPI 技术的应用进行匹配时，设备就会自动使用NBAR2引擎。

例9-14 步骤1:配置应用class map

ASR1000(config)# class-map match-all CITRIX

ASR1000(config-cmap)# match protocol citrix

! Matches citrix traffic

ASR1000(config)# class-map match-all BROWSING

ASR1000(config-cmap)# match protocol attribute category browsing

! Matches general HTTP browsing

ASR1000(config)# class-map match-any INTERNAL-BROWSING

ASR1000(config-cmap)# match protocol http url "*internalweb.com*"

! Matches any internal browsing traffic going to internalweb.com

可以通过命令show class-map 来查看上述配置。

第2 步是配置相应的QoS policy map。例9-15 显示了如何进行相应的配置。要注意在下面的例子中，管理员在父类BROWSING中调用了一个叫做INTERNAL-BROWSING-POLICY的子类。这种使用父类和子类相套嵌的策略，实现了在整体的浏览带宽之内，为内部浏览流量流量划分带宽比例的需求。

例9-15 步骤2:配置policy map

ASR1000(config)# policy-map INTERNAL-BROWSING-POLICY

ASR1000(config-pmap)# class INTERNAL-BROWSING

ASR1000(config-pmap-c)# bandwidth remaining percent 60

! This is the child policy of the "browsing" parent policy

ASR1000(config-pmap)# policy-map WAN-NETWORK-POLICY

ASR1000(config-pmap-c)# class CITRIX

ASR1000(config-pmap-c)# police percent 50

! Allocates 50 percent of bandwidth to Citrix

ASR1000(config-pmap)# class BROWSING

ASR1000(config-pmap-c)# bandwidth remaining percent 30

ASR1000(config-pmap-c)# service-policy INTERNAL-BROWSING-POLICY

! The parent policy calls the child policy to protect internal browsing

! when congestion occurs where more than 30% of the bandwidth

! is needed for browsing.

可以通过命令show policy-map 来查看上述配置。

第3 步是将policy map 应用到接口上，如例9-16 所示。

例9-16 步骤3:将policy map应用到接口上

ASR1000(config)# interface GigabitEthernet0/0/0

ASR1000(config-if)# service-policy output WAN-NETWORK-POLICY

可以通过命令show policy-map interface GigabitEthernet0/0/0 来查看上述配置。

下面我们介绍部署AVC的另一个案例，即在Internet边界部署AVC的方法。

2.在Internet边界部署AVC QoS控制

现在，假设要在网络的Internet 边界部署AVC QoS 控制技术。在这个案例中，ASR 1000是一台Internet边界路由器。企业希望用一条新的Internet连接连接到一个支持双向（入站和出站共）50Mbit/s的本地ISP。ASR物理接口是吉比特以太网接口，因此如果总流量超出了50Mbit/s的上限，就需要通过多层整形器来提供浏览整形。

企业在Internet上使用得主要是基于Web的应用（如基于Web的文件共享、CRM和BI应用）。假设网络中有许多员工同时也在使用P2P（如文件共享），而企业则希望通过QoS策略将P2P流量限制在可用带宽的20%之内，而那些使用Web浏览的关键应用则可以获得其余至少80%的可用带宽。

概括地说，Internet边界路由器的QoS策略包括以下三点。

■ Internet连接要限制在50Mbit/s之内。

■ 浏览流量应被视为一种关键流量，并为其分配80%的可用带宽。

■ P2P应用（如文件共享类应用）的带宽要限制在可用带宽的20%以内。

下面的配置与“在WAN 边界部署AVC QoS 控制”小节中所介绍的配置步骤完全相同， QoS策略的具体配置方法如例9-17所示。

例9-17 在Internet边界配置QoS策略

ASR1000(config)# class-map match-all BROWSING

ASR1000(config-cmap)# match protocol attribute category browsing

! This class map matches all browsing traffic

ASR1000(config-cmap)# class-map match-all P2P

ASR1000(config-cmap)# match protocol attribute sub-category p2p-file-transfer

! This class map matches any P2P traffic with specific attention

! on the file-transfer sub-category

ASR1000(config)# policy-map CHILD-PRIORITY-POLICY

ASR1000(config-pmap)# class P2P

ASR1000(config-pmap-c)# bandwidth remaining percent 20

! This allocates 20% of remaining bandwidth to P2P class

ASR1000(config-pmap-c)# class BROWSING

ASR1000(config-pmap-c)# bandwidth remaining percent 80

! This allocates 80% of remaining bandwidth to BROWSING class

ASR1000(config-pmap-c)# policy-map PARENT-PRIORITY-POLICY

ASR1000(config-pmap-c)# class class-default

ASR1000(config-pmap-c)# shape average 50000000

! The Internet pipe is shaped down to 50 Mbps

ASR1000(config-pmap-c)# service-policy CHILD-PRIORITY-POLICY

! The parent policy (PARENT-EDGE-POLICY) first shapes the pipe

! down to 50 Mbps, then when back pressure is applied it calls

! the child policy (CHILD-PRIORITY-POLCIY) to prioritize traffic

! within the shaped rate

ASR1000(config)# interface GigabitEthernet0/0/2

ASR1000(config-if)# service-policy output PARENT-EDGE-POLICY

ASR1000(config-if)# description The Internet Facing Interface

! This attaches the INTERNET-EDGE-POLICY map to the Internet

! interface in the outbound direction

同样，管理员也可以使用下列三条命令来验证自己的配置。

show class-map

show policy-map

show policy-map interface GigabitEthernet0/0/2

另一种验证配置正常工作与否的方法，是检查Cisco Insight Reporter 收集到的信息。图9-7显示了在接口上应用QoS策略之前与之后的报告。

如图9-7所示，在QoS策略实施之前，路由器的总出站流量达到了近120Mbit/s，但这个环境总的可用带宽却只有50Mbit/s，这意味着有高达70Mbit/s的流量会被ISP无情地丢弃。通过该图可以清晰地看到，在哪个时间点上，QoS策略开始生效，因为彼时带宽发生了显著的变化。首先，总出站带宽被整形到了50Mbit/s，而设备则启用了分层的策略。这样一来，设备就会按照需求来对流量进行列队:其中八成用于传输网页浏览数据（即这类流量最高可用带宽为40Mbit/s），两成用于P2P文件共享流量（即这类流量最高可用带宽为10Mbit/s）。

这个示例显示了AVC是如何轻松地检测出多种以HTTP作为基本传输协议的流量，并对它们实施控制的。

图9-7 可以体现AVC QoS策略效果的Insight Reporter报告

9.4 使用AVC的性能考量

只要在网络中使用了NBAR2或FNF技术，技术人员毋须格外留意它们给设备性能带来的影响。NBAR2执行的是应用层深度数据包监控技术，这项技术对于CPU及可用系统内存的消耗相当巨大。

由于NBAR2需要监控整个连接的数据流，因此这个数据流中的数据就要保存在DRAM中，而DRAM的资源毕竟是有限的。在每个系统中，都为保存NBAR2数据流信息分配了一定默认数量的内存。但设备显示出的并不是为NBAR2数据流分配的实际内存空间，而是这个平台所支持的最大NBAR2 数据流的数量。例如，管理员可以在ASR1000 上通过命令show ip nbar resources flow 来查看它支持的NBAR2 最大数据流数量，如例9-18 所示。

例9-18 显示NBAR系统资源

ASR1002# show ip nbar resources flow

NBAR flow statistics

Maximum no of sessions allowed:1000000

Maximum memory usage allowed　:367001 KBytes

Active sessions　　　　:0

Active memory usage　　　:83453 KBytes

Peak session　　　　　:4124

Peak memory usage　　　　:83453 Kbytes

上述输出信息中的核心内容是最大允许会话数（本例中为100万），以及当前的会话峰值数量。一般来说，建议分配给NBAR的可用内存不超过内存总量的70%。如果活动数据流的数量超过了分配给NBAR的最大数量，就会发生下面两种情况:

■ 路由器会创建一条系统日志消息，向管理员警示这一情况；

■ 超出总量的会话会被归类为Unknown（未知）。

除了内存方面的考量之外，NBAR和FNF对于CPU性能的影响同样不可谓不大。在ISR G2路由器上，设备的CPU会同时处理数据平面和控制平面的信息。因此，在ISR G2路由器上， NBAR造成的影响有可能会削弱设备的转发性能和其他控制协议的效率（如SNMP、路由协议等）。在ISR G2 上，可以通过命令show proc cpu 来监测CPU 的使用情况。

在ASR系列设备上，控制平面与数据转发平面是相互分离的。在这个平台上，NBAR会在ESP（内嵌服务处理器）模块中执行，这个模块负责数据转发的处理工作，因此show proc cpu这条命令就没什么太大作用了（这条命令输出的是路由处理器模块的CPU性能，不是ESP 的性能）。在ASR 中，要通过命令show platform hardware qfp active datapath 来查看ESP模块自身的CPU性能，以了解NBAR对系统造成了什么程度的影响，如例9-19所示。

例9-19 查看ASR 1000 ESP CPU与内存

avc-asr1002a# show platform hardware qfp active datapath utilization summary

CPP 0:　　　　5 secs　1 min　5 min　60 min

Input:　Total (pps)　　98　　45　　39　　39

(bps)　325592　234000　103432　103400

Output:　Total (pps)　　99　　46　　40　　40

(bps)　343368　240440　111376　111328

Processing:Load (pct)　　0　　0　　0　　0

如例9-19阴影部分（Processing）所示，Load部分显示的是ESP交换矩阵的CPU与内存使用情况，而不是RP的信息（在运行NBAR2时，主要应该关注ESP的性能）。

总之，在路由器或无线控制器上启用AVC之前，建议查看各个平台的NBAR2和FNF性能特征，以确保这些特性不会给网络性能造成严重的负面影响。

9.5 小结

本章介绍了AVC解决方案的概念与技术构成。商业应用与个人应用日新月异，越来越多的应用都是基于Web来实现的。这种趋势使得传统的应用分类法——根据应用的TCP或UDP端口号来识别应用——变得日渐难以为继。AVC是由Cisco设计的一项解决方案，这项解决方案旨在解决这一问题，并为网络设备提供DPI功能，以实现应用层的QoS分类与控制功能。

本章讨论了AVC的四大常用场合，即在Internet边界、WAN边界或分支路由器、以及无线路由器上使用AVC 解决方案。当今，ASR 1000 系列设备、ISR G2 路由器以及Cisco 无线LAN控制器均已开始广泛支持AVC技术。

本章接下来讨论了AVC的四个组成部分，即NBAR2、FNF、报告工具以及QoS控制。本章介绍了NBAR2的结构，以及一些NBAR2的配置案例。此外，本章也介绍了何时使用NBAR协议发现功能。FNF在本章中进行了具体的介绍，包括经典NetFlow与FNF之间的区别。读者也了解了FNF 是使用NBAR2 DPI 引擎在网络中发现和分类应用的。本章利用配置案例阐述了FNF的实际部署场景，并介绍了FNF报告与信息收集工具（包括Cisco Insight）。在最后一部分中，本书介绍了如何使用FNF报告工具收集到的信息。这一部分包含了两个针对应用层协议实施QoS控制的案例，其中之一在Internet边界实施控制，另一个则在WAN边界实施控制。

最后，本章介绍了在路由器和WLC上使用AVC的效果。若不精心设计，AVC可能会对设备的CPU和DRAM产生副作用。因此在任何设备上配置AVC之前，都应该详细了解AVC在这个平台上的性能特征。

9.6 扩展阅读

FNF technology white paper（FNF技术白皮书）:http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6555/ps6601/ps6965/prod_white_paper0900aecd804be1cc.html

NBAR2protocollibrary（NBAR2协议信息库）:http://www.cisco.com/en/US/partner/prod/collateral/iosswrel/ps6537/ps6558/ps6616/product_bulletin_c25-627831.html

NBAR2 overview（NBAR2概述）:http://www.cisco.com/go/nbar

Cisco Insight Reporter:http://www.cisco.com/en/US/prod/collateral/ps7045/ps6129/ps6257/ps6135/cisco_insight.html

注　释

[1].policing 也曾被翻译为“管制”，但“限速”的译法目前看来更为合适。

[2].flow exporter、flow record和flow monitor都是Cisco IOS系统中配置Flexible NetFlow技术的命令（关键字）。就这个层面的意义而言，这些专有名词都不应该译出，而应该以原文的形式保留下来。更重要的是，既然是命令，那么无论把它们翻译成什么中文，都难免词不达意。但在进行了一番保留的尝试之后，译者发现如果保留原文，会导致译文中出现大量的英文单词，以及英文单词与英文单词、英文单词与缩略简称连接出现的情形，对于中文读者的阅读造成障碍。最后迫不得已，译者只好以流导出器、流记录、流监测对它们进行了直译。在英文原文中，这些单词交替以首字母同时大写和首字母同时小写的形式出现，毫无规律，足见作者对于它们是否为专有名词，亦难委决。若读者对译文感到拗口，不妨在阅读下面的内容时，在心中将中文翻译代以FE、FR、FM等简称。

第2部分 QoS设计战略

第10章 商业和应用的QoS需求

本章会介绍当前影响QoS设计方案及各类应用QoS需求的商业趋势:

■ 网络互联的全球发展趋势；

■ 视频应用的变革；

■ 媒体爆炸式增长；

■ 社交网络的涌现；

■ 自备设备的需求；

■ 应用自顶向下的涌现趋势；

■ 多媒体应用中媒体组成部分的汇聚；

■ 媒体向高清媒体过渡；

■ 不同应用类的QoS需求与推荐方案。

实践证明，QoS是融合语音、视频和数据网络的一类最为基本的网络基础设施级技术。此外，QoS还可以实现并扩展网络的整体安全水准。不过，由于企业往往需要不断演化和发展，因此QoS策略的规则和需求也要随之发展变化。

成功的QoS部署方案往往都是以实现业务/企业目标为基本原则的。因此，在学习QoS的设计和配置方法之前，网络管理员很有必要先对企业的发展趋势，以及与网络QoS策略相关的应用需求作一番了解。毕竟，这些需求都会影响QoS部署的战略与设计方案。

10.1 网络互联的全球发展趋势

Cisco正在与一些顶尖的服务提供商和大型企业客户合作，监测Internet流量的统计数据和发展趋势，并每年发布Cisco Visual Networking Index:Forecast and Methodology Report。这些报告可以在以下网址进行访问http://www.cisco.com/go/vni。

当前的报告揭示出了许多网络互联的重要趋势，而下列趋势都对QoS需求与设计方案具有直接的影响。

■ 在过去5年间，全球IP流量增长了8倍，在接下来的5年中，IP流量还会在目前的基础上再增长3倍（总之，在2011年到2016年之间，IP流量的年复合增长率为29%）。

■ 到2016年，连接到IP网络的设备数量会高达届时全球人口总数的3倍。

■ 越来越多的IP流量和Internet流量是由非PC设备始发的（在2011年，22%的IP流量是由非PC设备产生的，但是到2016年，非PC设备产生的流量则会占总流量的31%）。

■ 到2016年，无线设备产生的流量将会超过有线设备产生的流量。

■ 截止到2011年底，视频流量超过了全球客户Internet流量总量的一半。到2016年时，各类视频流量的总量将会占全球客户流量的86%左右。

■ 2011年底，高清的按需视频（VoD）流量已经超过了标清视频的流量。到2016年时，高清Internet视频将会占VoD总量的79%。

10.2 视频应用的变革

本书第1版发布之时（2004年），企业网中部署的视频应用基本只有两大类。

■ 流视频:常常被人们称为单向的对时间不敏感的数据流，如单播或组播VoD（大量的应用级缓存抵消了过度的抖动）。

■ 互动视频:常常被人们称为单向的对时间敏感的协作视频流，如基于H.323的视频应用。（通常工作在384kbit/s或768kbit/s）

但是，自那时起，视频应用就已经开始出现了惊人的变化，这种变化还在不断的持续和发酵，如图10-1所示。

图10-1 视频应用的进化过程

回忆一下最早的流媒体视频吧——最早的视频应用就是发送给桌面的VoD流。VoD流有可能包含事先录音的内容——比如员工之间的通信、培训、网上教学及社交方面的内容。而今天，由于创建内容越来越简单，因此按需的内容不仅可以通过专业的厂商来为客户提示（自顶向下的传播），也可以由每一个人自行制作上传（自底向上的传播）。因此，读者一定要意识到，所有VoD内容都一定要与业务有关；至于那些与业务无关的、娱乐相关的内容，可以通过大量按需视频（比如说在YouTube上）进行浏览。VoD视频可以是发送给桌面的实况/广播视频流。而广播流中包括公司会议、特殊事件、企业内部通告等内容。因此，广播视频流往往是专门制作的自顶向下传播的视频。

在那之后，随着平板数字显示器的普及，桌面应用显然已经不再是输出视频流的唯一媒介。于是，数字标记应运而生，成为了另一种显示视频流的工具（既可以输出按需视频，也可以输出广播媒体流）。数字标记指的是那种负责将数字媒体输出到网络显示器中的几种管理发布解决方案。数字标记可以用来广播内部信息（比如在最关键的位置发布最新的日程表和新闻，或提供实时位置与导航信息）。此外，数字标记在营销和广告领域也能发挥显著的作用。

几乎就在数字标记大行其道的同时，IP对于视频的优势也被一些厂商应用到了视频监控领域之中。这些优势包括向本地或远程控制转发实况视频流，以便有关人员进行观察和处理。有趣的是，视频监控与其他视频流应用相比，对信息互动提出了更高的要求——简单地说，就是要求监控人员能够向视频摄像头传输控制信息（比如跟踪局势的发展情况），以此实现信息流的“互动”。

在视频应用的互动视频领域，应用同样出现了显著的变化。基本的视频会议应用（最开始只能在专门的视频会议房间中使用）发展成了基于软件的PC应用。对于用户而言，从依赖房间的硬件应用转换到基于PC的软件应用这一转变过程，带来了两大明显的利好。

■ 随时随地可以实现桌面协作，非常方便（无需事先预定或者遍寻不到可以进行视频会议的房间）。

■ 便宜的网络摄像头随处可见。

桌面视频会议既可以以一对一的方式实现，也可能同时支持多为与会者同时交流。

当视频会议通过软件来实现之后，通信的可能性立刻出现了爆炸式的增长，因为这种变革让桌面的视频会议应用转变为了多媒体协作应用。多媒体协作应用不仅共享语音和视频，也会共享数据应用（譬如即时消息、文件和幻灯片共享、应用共享，以及其他集成的多媒体特性）。

不过，并不是所有的互动视频都迁移到了桌面。在固定房间中使用的视频会议解决方案也在不断发展，并使用了高清视频和音频技术，如Cisco TelePresence解决方案等。此外，（借鉴自多媒体会议应用的）应用共享功能也被添加到了这些高清专用房间视频会议的解决方案之中。

最后，还有一点必须说明，视频应用的发展并不会就此停下脚步；这个过程无疑会随着时间的发展、新型需求与技术的涌现而持续下去。

10.3 媒体激增

还有一种因素使得富媒体应用穿越IP网络发送流量的需求激增，那就是媒体内容的爆炸式发展。而媒体内容的激增，在很大程度上是因为创建视频、传输视频和浏览视频的门槛越来越低了。

试想一下创建视频的门槛是如何得以显著降低的:20年前，视频摄像头的价格相当昂贵，也只有专业的工作室才能搞到创建/编辑视频的工具。但现如今，几乎每一部手机、每一块平板、每一台笔记本、每一部数码相机都拥有高清视频捕捉功能。此外，很多视频创建和编辑软件唾手可得，业余视频用户借助这些软件也可以创建出足以匹敌专业工作室的高清视频产品。

通过如Facebook、YouTube等社交网络，传播视频信息的门槛也不复存在。用户在这些社交媒体上只需点击一个按钮就能够将内容传播出去。

浏览视频的门槛同样在无形中消弭。在短短10到15年前，笨重的电视屏幕才是人们浏览视频的主要硬件设备，现在想起来真是可笑。因为今天，人们几乎能够在所有设备上随时随地地浏览视频。

综上所述，视频通信当前几乎已经毫无门槛，于是这种高效的通信方式便开始在网络中蓬勃地发展。

10.4 社会网络互联现象

社交媒体已经成为了一种消费现象，但它对于商业网络的影响同样不容回避，因为社交媒体的用户数量已经过亿。

试想:通过社交网站，人们可以共享他们的个人信息，以及它们感兴趣的事物，通过这种方式，人们可以和志同道合的人进行沟通互动。相应地，在工作场合，企业目录和协同内部网站也可以反映出这些社交站点的观感和功能。

例如，Cisco 就曾经经历过这种社交网络应用进入工作场合的转换过程（如Cisco Vision[C-Vision]）。C-Vision 最初的作用是为员工提供一种ad hoc 服务，也就是为员工提供一个中心站点来和其他人共享各类媒体（其中也包括视频片段）。Cisco的员工一度通过这项服务来共享项目文档、新产品信息、竞争策略等信息。随着使用这项服务的人越来越多，Cisco自己的IT部门只好行使自己的所有权，并将这项服务推广到Cisco在全球各地的分支机构中。这样做的结果是，只要有员工的工作效率得到了提升，他们就可以将自己的经验分享给同事，让他们知道自己是如何提升工作效率的，这就是富媒体应用为提升效率、简化工作所作出的贡献。

10.5 需求:自备设备

早先，企业都会给员工提供台式机或笔记本电脑，这几乎就是员工能接触到的最高级的设备了。但随着无线设备（包括笔记本电脑、上网本、平板电脑、智能手机、电子阅读器）的普及，员工自己往往就备有某些极为高端的设备。于是，员工就会经常向IT部门发出这样的质疑:我凭什么不能用这些更高端的设备来工作？起初，许多机构的IT部门都会拒绝员工的这类要求，究其原因，主要是安全性和扩展性方面的考量。

最近几年来，终端用户不断要求使用自己的平板电脑和智能手机来工作，以提升自己的工作效率，他们为此甚至甘愿自掏腰包。针对这种趋势，许多IT部门也不得不采取一些相对开放的策略，也就是通过基本的连接与IT网络和企业应用建立会话关系，有些企业甚至允许员工使用自己的设备与企业网络和企业应用建立各种连接。

过去，很多人拥有台式机或笔记本电脑，同时也会为自己添置一台移动电话（手机）来接打电话。而目前，移动电脑已经基本被智能手机所取代，而智能手机的功能与台式机和笔记本相差无几，它也可以让用户使用大量新的应用。

有人推测，在未来，用一台设备就可以满足所有的计算、通信和应用需求。不过目前，大多数人还是认为，不同的设备各有最为适合的使用场合。比如，笔记本电脑不如智能手机便携，因此大多数人都会带上智能手机来建立移动通信。平板电脑同样也是相当强大的设备，但人们很可能还是会用笔记本和台式机来创建和发布文件。也就是说，人们还是会携带和使用多种不同的设备，因此多功能设备也就不太可能在短期内问世。

另一种趋势是，“工作”已经成为了人们履行的职责，而不是人们服务的处所。通过移动设备远程访问企业网络赋予了员工更高的自由度，也让员工的工作效率得到了提升。因此，工作时间和私人时间的界限也变得更加模糊了，因为员工可以根据自己的意愿，为自己设置更加灵活的工作日程，这样的工作方式通常会把工作与个人生活交织在一起。

各类不同的用户设备大行其道，这些设备不仅被应用于个人生活之中，更被引入到了工作环境之内，这不仅对网络安全提出了更高的挑战，也对QoS提出了新的挑战——毕竟，分辨哪类设备是可靠的，变得越来越麻烦。在这些BYOD设备上，应该信任哪些应用也是一个新的课题。

10.6 出现自下而上的应用

在传统意义上，IT部门有权决定企业环境中支持哪些应用、哪些设备；这种部署方案有时成为自上而下的部署方式。

相反，就像上文中的C-Vision一例那样，当前的趋势是，企业的应用部署方案是由用户自下而上驱动的。换句话说，用户群会提出要求，或者直接开始使用某一项应用，无论他们是否得到了管理层或IT部门的首肯。

自上而下和自下而上的应用相结合、设备数量的增加，这都给IT部门带来了巨大的负担，让IT部门的从业人员不仅需要处理大量获得了官方支持的应用和设备，还要处理那些一些并没有获得官方支持但是用户数量庞大的应用和设备。

10.7 多媒体应用中融合了多种类型的媒体

在汇聚网络的早期，不同的应用会生成各自的媒体信息，其中应用包括语音、视频或数据应用，但不会将它们结合起来。这主要是因为不同类型的应用都有自己专属的硬件。比如说， IP电话会生成语音流量，专用的IP/VC设备会生成视频流量，PC则会生成（大量的）数据流量。

但现如今，由于硬件平台（包括笔记本电脑、平板电脑和智能手机）变得越来越强大，也越来越灵活，因此许多应用会生成多媒体的流量，也就是将上述两种或多种类型的媒体结合在一起。比如，Cisco WebEx 就可以同时发送视频、音频和数据流量。同样，Cisco TelePresence则具有发送高清音频和视频流量，以及数据共享的功能。

这种多媒体应用却让网络管理员陷入了这样一种困境:是应该把这种应用分类为语音应用（以便保障语音信息的质量）、视频应用（基于相同的原因）或数据应用（从QoS的角度来看，将一种应用归类为数据应用意味着最低标准的处理方式），还是应该把这类应用细分为不同类型的媒体，并把它们分类到不同的服务级别中呢？关于这部分内容，我们将在10.9.3节进行具体的介绍。

10.8 迈向高清媒体时代

房间到房间的这种传统视频会议系统，以及桌面网络摄像头视频会议系统近年来备受质疑，人们认为它们的通信效率不高。究其原因，其中往往也包括这类系统依赖标清或低清晰度音频和视频格式。

而高清互动媒体应用（如Cisco TelePresence）则可以通过高清音频和视频来为用户提供更真实的远程协作体验:通过这类应用，与会者的感受几乎与他们就在会议室中一般无异。此外， IP视频监控摄像头也在进入高清视频时代，以便为一些新型功能（面部识别、在运动中基于视觉特征智能触发事件）提供实现它们所需的数字分辨率。

另外，就像在前文中提到的那样，高清VoD在Internet中的传输量已经超过了标清VoD。因此，随着人们已经开始作为消费者，日渐适应了高清视频的清晰影像，他们也会要求企业环境能够为他们提供同等水准的视频。

10.9 各个应用类别的QoS需求与推荐方案

在介绍了上述那些影响QoS的企业趋势之后，我们不妨回顾一些应用级别的需求，以便在部署QoS设计方案时，能够更好地满足客户的需求。

端到端的网络应用大体上可以分为如下5大类:

■ 语音应用；

■ 视频应用；

■ 多媒体应用；

■ 数据应用；

■ 控制层流量。

注释:这并不是说，网络中就不存在其他类型的应用。但其中有些应用可能只会在网络中的某些特定区域内传播。比如，FCoE就是这样一种特殊的应用协议，这类应用只会出现在数据中心环境中。本书会在第5部分对此详加探讨。在端到端的应用类别中，对此内容不再赘述。

在下文中，我们会依次对这些类型的应用进行介绍。

10.9.1 语音应用

下面总结了语音流量的主要QoS需求与推荐方案。

■ 语音流量的需求:

■ 单向延迟不应超过150ms；

■ 单向的峰值抖动不应超过30ms；

■ 每跳的峰值都等不应超过10ms；

■ 丢包率不应超过1%；

■ 每次呼叫的保障优先级带宽应于20～320kbit/s之间（具体带宽依取样率、编解码器和2层媒体开销而定）。

■ 语音流量的推荐方案（根据RFC 4594 和RFC 3246）:

■ 应为语音流量打上EF（加速转发）/DSCP（差分服务代码点）46的标记；

■ 应以EF作为PHB（严格优先级队列）来处理语音流量；

■ 应对语音流量施以准入控制。

如果延迟过大，人们交谈的声音就会重合。在设计支持VoIP的网络时，最常用的要求是满足ITU标准G.114所规定的目标。该标准指出，单向端到端延迟在150ms以内，可确保电话通讯应用呈现的质量能够让用户满意。网络设计方案应该保证各个不同部分（骨干部分的转发延迟、拥塞造成的调度延迟，以及串行延迟）的网络延迟，以及服务延迟之和在这个规定的延迟范畴之内。

VoIP流使用抖动缓冲来减少网络延迟造成的效果。抖动缓冲可以改善数据包不同步到达的问题，它可以在目的终端系统中，将各类网络延迟调节为一个连贯的延迟值，以此保证数据流是同步的。抖动缓冲的作用是在延迟和因数据包迟到而影响数据流播放之间进行平衡。迟到或失序的数据包会被丢弃。

VoIP数据包丢包会让语音听上断断续续。数据包丢失隐藏（PLC）这项技术的作用是隐藏VoIP数据包丢失或被丢弃所造成的负面影响。PLC所使用的方法取决于编解码器的类型。波形编码器（如G.711）所使用的一种简单的方法是重放最后接收到的样本，并在每次重复时增加衰减；相邻两个样本的波形不会有太大变化。这种技术可以有效地隐藏20ms以下样本丢失的情形。

语音数据包所需的带宽可以进行相当准确的预判，因为语音数据的大小是连续的（这是编解码器的功能之一），而数据包速率也是连续的（默认为50pps）。不过，在预判语音流量的带宽时，网络管理员切记要将2层网络协议的开销计算进去。

RFC 4595 推荐，语音类型应该用EF 进行标记（DSCP 46），并对语音流量施加准入控制。推荐对这种类型的流量执行EF PHB。EF PHB 定义在RFC 3246 之中，是一种严格优先级队列服务，因此这种类型应该执行准入控制。这类流量如G.711 和G.729 VoIP 呼叫等。

10.9.2 视频应用

视频应用（特别是高清视频应用）对IP网络提出了很多特殊的挑战与要求。图10-2所示为语音和视频流量在数据包层面的比较。

图10-2 VoIP与高清视频应用的对比（数据包级别）

从图10-2中可以看出，视频数据包在尺寸和封包速率上都存在明显的变化，这一点与VoIP数据包很不相同。这是因为设备发送的视频信息总量会因压缩率而不断变化。压缩率从本质上来说就是随机的，它会因视频图像自身（包括图像呈现的色彩和质感、图像中的动作幅度、运动中的平移、倾斜和缩放）而变。

视频编解码器同时采用了时间压缩和空间压缩的方式:

■ 空间压缩会将相邻的类似像素组压缩到一个视频帧当中；

■ 时间压缩会将一个视频帧中的类似像素组压缩到下一个（或几个）帧中。

空间压缩和时间压缩的效果是，视频编解码器可以实现惊人的压缩率，如果不采取这些压缩技术，哪怕通过吉比特以太网或万兆以太网，也难以发送视频信息。

下面我们以压缩全高清（1080p30）视频流为例进行解释。其中第一个参数（1080）指横向分辨率为1080行，（如在16∶9宽屏中使用HD视频格式）那么纵向分辨率则为1920列。因此，每个屏幕就会分为2 073 600 个像素。而第二个参数p，指的则是逐行扫描率，也就是每个数据帧都会对每一行的分辨率进行刷新（这与隔行扫描[用i表示]的概念不同，隔行扫描是指每一帧只会隔行刷新）。第三个参数30指的是传输速率为每秒30个数据帧。虽然视频采样技术种类繁多，但每个像素的色彩/亮度信息却差不多都在3字节左右。因此，把上述参数组合起来（2 073 600 个像素 ×3 字节 ×8 位/ 字节 ×30 帧/ 秒），可以得到全高清视频的信息速率约为1.5Gbit/s，如图10-3所示。

图10-3 未经压缩的全高清映像

而各类编解码器（如H.264）可以将高清视频流压缩到5Mbit/s以下——这就表示，这些编解码器的压缩率可以达到300:1。

这类高压缩率的压缩技术也有缺点，那就是这类算法对于丢包极为敏感。因此，信息遗失的效果都会被放大——和压缩的效果正好相反（也就是在时间和空间上都会放大）。比如，如果一个经历了高压缩率空间压缩的数据包在传输过程中被丢弃，那么在播放视频帧时，视频影像中就会出现一个大大的块状马赛克。如果丢弃的数据包经历过高压缩率的时间压缩，那么这个马赛克就有可能持续很多秒，直到新的未压缩视频帧将它刷新掉。

Cisco实验室的测试结果显示，即使每10000个高清视频数据包中丢失1个数据包也会被终端用户觉察到。与VoIP相比（100个数据包中丢失1个也可以瞒过终端用户），可以说高清视频要比VoIP对丢包敏感100倍之多！然而，由于在网络繁忙期间，画面中出现一些马赛克人们也能接受，因此很多高清视频应用都把丢包目标设定为0.1%（只是VoIP数据包丢包率的1/10）；但这种现象不应该得到鼓励，丢包目标应该按照相应的标准来制订（收紧）。

视频应用还可以进一步下分为广播视频应用类（单向视频）和实时交互应用类（双向视频）。

注释:这些视频应用类不应该仅仅包含视频流量，因为这些类型的应用也有可能包括数据流量（如在视频流中同步共享PPT文件或其他数据信息）。

1.广播视频

广播视频应用类旨在服务单向、刚性的视频流，如广播TV、实况新闻和IP视频监控流量。

注释:流的弹性（elasticity）指的是应用能够根据丢包检测的结果，对视频流进行调整的功能。刚性流（Inelastic flow）要么缺乏这种功能，要么人为要求其在出现丢包时扔保持原来的视频质量。而弹性流则会对丢包作出响应，包括降低质量、分辨率、发送速率或执行某种降级功能。

广播视频的需求包括:

■ 丢包率不应超过0.1%。

（根据Cisco 对RFC 4594 和RFC 3246 的解释）广播视频的推荐方案包括以下几项:

■ 应为广播视频流量打上CS 5/DSCP 40 的标记；

■ 不妨以EF作为PHB（严格优先级队列）来处理广播视频流量；

■ 应对广播视频流量施以准入控制。

注释:本书在第3章中曾经介绍过:大体上，Cisco以RFC 4594作为自己的差分服务（DiffServ） QoS战略，但也有如下例外:Cisco将RFC 4594中推荐的广播视频类标记（CS3）和信令类标记（CS5）进行了对调。因此，Cisco会将广播视频流量标记为CS5，而将信令流标记为CS3。这么做主要是因为Cisco已经在过去10年中以CS3来标记信令流量（那会儿，RFC 4594甚至都没起草呢），而Cisco没有理由在所有的语音和视频电话通讯产品中修改这个默认值，如果Cisco这样做，那么所有的客户都要修改与信令类有关的QoS策略，于是Cisco决定延续过去的默认值。因此，Cisco将这两种流量的标记进行了交换，将广播视频标记为CS5，同时继续使用CS3来标记信令类流量。切记RFC 4594的目的只是提供一些参考信息，而不是强制执行的标准。

广播视频流往往是单向的，而且包括应用级别的缓冲（这在流视频应用中也很常见）。因此，这种类别在延迟或抖动方面并没有严格的需求。但这类流量对丢包的需求相当严格（尤其是这类中的高清流），因此有可能需要网络提供严格优先级服务。

这一类流量应该打上CS5（CS5/DSCP 40）的标记，并且可以执行EF PHB（这是一种严格优先级服务的处理方式，但也可以用来处理那些并没有标记为EF/DSCP 46 的流量）。这种类别应该执行准入控制（无论通过准入控制机制，还是通过分配带宽的方式执行）。这一类流量包括发送给桌面或Cisco DMS 播放器的实况Cisco DMS（数字媒体系统）流、实况Cisco 企业TV（ETV）流，以及Cisco IP 视频监控（IPVS）流。

2.实时互动视频

实时互动服务类旨在服务实时、双向、刚性的视频应用。这些流量通常是高清的。

实时交互视频的需求如下所示。

■ 单向延迟不应超过200ms。

■ 单向的峰值抖动不应超过50ms。

■ 每跳的峰值抖动不应超过10ms。

■ 丢包率不应超过0.1%。

■ 为之分配的带宽以编解码器、分辨率、帧速率、其他数据参数以及网络开销而定。

（根据RFC 4594 和RFC 3246）实时互动视频流量的推荐方案如下所示。

■ 应为实时互动视频流量打上CS 4/DSCP 32 的标记。

■ 不妨以EF作为PHB（严格优先级队列）来处理实时视频流量。

■ 应对实时视频流量施以准入控制。

实时互动类的延迟目标为200ms以内，与VoIP类相差无几；多出来的时间是高清视频编解码器与压缩算法的处理时间。同样，实时互动类的抖动目标也与VoIP类十分相似，只是为组成高清视频流量的大尺寸数据包增加了一些序列化延迟。丢包的目标则与广播视频类别无二致——两者的目标都是0.1%。

注释:高清视频是以帧为单位进行发送的，帧往往会跨越多个数据包。因此视频质量中的抖动度量并不一定是单个数据包的抖动，而是视频帧的总抖动。换言之，视频的整个数据帧必须全部在重放缓冲的抖动许用范围内接收到，否则质量将无法得到保障。

实时交互类中的流量应该打上CS4（CS4/DSCP 32）的标记，并且可以执行EF PHB，这种类别应该执行准入控制。这一类的应用包括Cisco TelePresence。

10.9.3 多媒体应用

由于目前很多应用都拥有多媒体的成份，因此管理员经常需要面对多媒体带来的困境:是应该把这种应用分类为语音应用或视频应用以保障语音或视频信息的质量呢，还是应该把它当作数据应用处理，亦或应该把这类应用细分为不同类型的媒体，并把它们分类到不同的服务级别中呢？

上述任何一种选择都面临取舍，第一种选择（将多媒体应用划分到语音或视频类别中）有可能会让实时带宽大幅提增加（若这些类别以EF PHB 进行处理尤其如此）。此外，许多多媒体应用对准入控制机制的支持相当有限（有些根本就不支持），因此将多媒体应用划分到语音和视频类别中，对于那些已经在这些类别中的语音和视频应用来说相当危险。

第二种选择是不对多媒体应用中的语音和视频成份提供特权（将它们留在数据类别中就行了）。

第三种选择（将多媒体应用的流量划分为不同的媒体，并为它们提供不同的服务类型）看上去似乎非常复杂，甚至在技术上根本就行不通（因为一个应用中的媒体流可能会随机使用TCP/UDP端口，或者将它们复用在一起）。此外，准入控制的问题也没有得到解决。最后，即使将多媒体应用分离为不同的媒体是可行的，也能够进行控制，这种做法似乎也不可取，因为对于接收端来说，分离多媒体有可能造成信息不同步（例如，在多媒体流量穿越网络的过程中，将视频和音频流以不同方式进行处理，可能会导致它们无法同时到达接收端设备）。

还有一个替代方法，那就是分清各个多媒体应用的具体需求，然后分情况处理。实际上，这正是RFC 4594 推荐的做法——RFC 4594 将多媒体应用分为了两种多媒体流量的类型。

■ 多媒体会议类:用于双向多媒体应用。

■ 多媒体流类:用于单向多媒体应用。

这一节会对这两种类型的多媒体分别进行简单的概述。

1.多媒体会议类

多媒体会议服务类别用来归类那些弹性的、双向的多媒体应用，如桌面软件多媒体/协作应用。

多媒体会议类的需求包括:

■ 单向延迟不应超过200ms；

■ 丢包率不应超过1%。

（根据RFC 4594 和RFC 2597）多媒体会议类的推荐方案包括:

■ 应为多媒体会议流量打上AF4类的标记（AF41/AF42/AF43或分别为DSCP34/36/38）；

■ 应以AF（确认转发）作为PHB来处理多媒体会议流量，即根据基于DSCP的加权随机早期检测（WRED）来提供有保障的带宽队列；

■ 应对多媒体会议流量施以准入控制。

这一类中的流量应该打上确认转发第4 类（AF41/AF42/AF43 或分别为DSCP 34/36/38）的标记，并通过DSCP WRED 提供有保障的带宽队列。这种类别应该执行准入控制。此外，这一类流量可以执行限速或重标记。这类应用包括Cisco Unified Personal Communicator、Cisco UnifiedVideo Advantage 和Cisco 统一IP 电话7985G。

2.多媒体流类

多媒体流服务类用来归类那些弹性的、单向的多媒体应用，如VoD流视频。

多媒体流的需求包括:

■ 单向延迟不应超过400ms；

■ 丢包率不应超过1%。

（根据RFC 4594 和RFC 2597）多媒体流的推荐方案包括:

■ 应为多媒体流打上AF3 类的标记（AF31/AF32/AF33 或分别为DSCP 26/28/30）；

■ 应以AF（确认转发）作为PHB来处理多媒体流，即提供有保障的带宽队列和基于DSCP的WRED；

■ 应对多媒体流施以准入控制。

这一类中的流量应该打上AF第3类（AF31/AF32/AF33或分别为DSCP 26/28/30）的标记，并通过DSCP WRED 提供有保障的带宽队列。建议对这种类别执行准入控制，而且这一类流量可以执行限速或重标记。这类应用包括Cisco数字媒体系统（Cisco Digital Media System）VoD流。

10.9.4 数据应用

大多数企业都有成千上万的数据应用需要在网络中传输信息。因此，把这些应用都归入一个大类中根本就行不通。因为其中有些应用（如投资银行的交易类应用）需要实时服务；有些应用（如一些科研类应用）虽然不需要实时服务但需要稳定的无丢包服务。还有一些应用的需求介于上面两类应用之间。

在过去几十年间，关键任务（mission-critical）数据应用的概念似乎已经沦为一种行业标准:必须通过一种比较主观的“业务相关程度”因素，将这些应用与其他应用严格区分开来，并对这些应用进行标记，然后为它们的流量设置一个专用的服务类别。但是在实际环境中，部署QoS时采取这种做法往往弊大于利。考虑这样一个毫无技术含量的主观因素，难免会引发一些政见或企业目标方面的争论，让部署QoS的工作在双方的扯皮中陷入停顿。比如，许多部门（甚至是大多数部门）的头目们都会坚称他们部门的应用与业务的关系最为紧密，因此需要受到特别优待。但如果把这么多应用都分配到专用的关键任务类别中，这些类别之间还是需要在这个先进先出（FIFO）队列中竞争带宽（换句话说，在很大程度上，这样的QoS策略和没有部署策略区别不大）。人们常常会要求企业的高管来制定QoS决策，而他们决策的结果最后往往是为了安抚员工情绪，而不是优化网络资源。

为了让大家信服，RFC 4594的作者废除了关键任务数据（Mission-Critical Data）这种类别，而建议用户将所有数据应用（除了尽力而为传输类和清道夫类应用外）都视为对业务十分关键的应用，并用一种纯技术的需求，将这些应用分为两类:

■ 业务性数据（或低延迟数据）；

■ 大数据（或高吞吐量数据）。

下面我们会依次介绍这两种类别。

1.业务性数据类（低延迟数据）

业务性数据服务类别（在RFC 4594 中称之为低延迟数据服务类别）用来归类那些交互式的前台数据应用。前台应用是指用户希望应用可以（通过网络）对操作作出响应，来让用户完成自己的工作。因此，过量延迟会影响前台应用的响应时间，并直接对用户的工作效率构成影响。

（根据RFC 4594 和RFC 2597）业务性数据的推荐方案包括:

■ 应为业务性数据流量打上AF2类的标记（AF21/AF22/AF23或分别为DSCP18/20/22）；

■ 应以AF（确认转发）作为PHB来处理业务性数据流量，即根据基于DSCP的加权随机早期检测（WRED）来提供有保障的带宽队列。

这一类中的流量应该打上AF第2类（AF21/AF22/AF23或分别为DSCP 18/20/22）的标记，并通过DSCP WRED 提供有专用的带宽队列。这一类流量可以执行限速或重标记。这类应用包括多媒体协作应用中的数据部分、企业资源规划（ERP）应用、客户关系管理（CRM）应用、数据库应用等。

2.大数据类（高吞吐量数据类）

大数据服务类别（在RFC 4594 中称之为高吞吐量服务类别）用来归类那些非交互式的后台数据应用。

（根据RFC 4594 和RFC 2597）大数据的推荐方案包括:

■ 应为大数据流量打上AF1 类的标记（AF11/AF12/AF13 或分别为DSCP 10/12/14）；

■ 应以AF（确认转发）作为PHB来处理大数据流量，提供有保障的带宽队列和基于DSCP的WRED；

■ 大数据类流量往往会被分配到一个拥有一定量带宽的队列，这是为了在网络出现拥塞的时候对这一类数据进行一些限制，以免TCP会话耗尽网络带宽。

所谓后台应用是指用户不会等待（通过网络发来）响应的应用。这类流量包括所有设备间的通信，因此后台应用的延迟时间过长往往并不会直接影响用户的工作。此外，由于大多数后台应用都是基于TCP的应用，因此这些应用（如果不加校验）有可能会占用过多的网络资源，让互动式的前台应用无法获得带宽。为大数据类数据流分配一个拥有一定带宽的保障带宽队列，可以让这类流量使用可以通过它们所需的带宽获得相应的服务，当链路占用率超过上限时（因为队列策略只有在网络拥塞时才会生效），这些数据流就会被限制，以免这些流量干扰到那些需要和用户进行互动的前台应用流量。

这一类中的流量应该打上AF第1类（AF11/AF12/AF13或分别为DSCP 18/20/22）的标记，启用DSCP WRED，并为其提供一个拥有一定带宽的专用的带宽队列。这一类流量可以执行限速或重标记。这类应用包括Email、后台操作、FTP/SFTP传输、视频和内容传播等。

3.尽力而为数据类

尽力而为数据服务类是默认的类别。

（根据RFC 4594）尽力而为数据的推荐方案包括:

■ 应为尽力而为数据打上DF 标记（DSCP 0）；

■ 应为尽力而为提供一个专用的队列；

■ 不妨为尽力而为数据分配一个有保障的带宽和WERD/RED。

在当今企业网络的成千上万种应用中，只有为数不多的几种应用会被分配到高优先级（或低优先级）类别中，而绝大多数应用只会被保留在默认的服务类别中。因此，应该为这种默认的类别分配一个专用的队列，同时，不妨为这个队列分配最小的带宽保障。

这个类别中的流量会被打上默认转发（DF 或DSCP 0）的标记，并获得一个专用的队列。为了提高吞吐量，避免TCP全局同步，推荐针对这种类别启用WRED。不过，从技术的角度上说，这个类别中所有的流量都会标记上相同的“权重”（DSCP 0），而拥塞避免机制从本质上讲就是RED。

4.清道夫类（低优先级数据）

清道夫服务类别（在RFC 4594中称之为低优先级数据服务类别）用来归类那些非业务流量，如娱乐类数据或媒体应用。

（根据RFC 4594 和RFC 2597）清道夫数据的推荐方案包括:

■ 应为清道夫流量打上CS1 的标记（DSCP 8）；

■ 应为清道夫类流量分配一个最小带宽的队列。

为非业务应用提供“低于尽力而为的”服务（而不是彻底把这类应用拒之门外），这种方法是IT部门与用户群之间的妥协。此外，使用清道夫类可以让IT部门对于自下而上的应用（也就是用户群体引入到网络中，但没有获得全部支持的应用）进行一定程度的管理。因此，在企业网络中，只要清道夫类应用不会影响到自上而下的关键业务应用，这类流量也是允许出现的。不过，一旦网络出现拥塞，这类流量会被大量丢弃。

这个类别中的流量应打上CS1（DSCP 8）的标记，并为其分配一个拥有最低带宽的队列，当网络出现拥塞时，这个队列会首当其冲被“饿死”。这类流量包括YouTube、Xbox Live/360电影、iTunes、BitTorrent等。

10.9.5 控制层流量

到目前为止，本书仅仅讨论了数据层的应用，别忘了还有控制层流量。与数据层相比，控制层流量的规模相对比较小，但是这类流量对于网络设备和语音视频端点的重要性可谓不言自明。

有些Cisco产品（包括硬件和软件产品）往往会包含一些自动保护控制层流量的机制，但网络管理员还是应该谨慎对待这类流量，并为这类流量提供带宽保障，以确保网络设备都可以正常工作。

控制层流量可以分为以下几类:

■ 网络控制类；

■ 信令类；

■ 操作/管理（OAM）类。

下面我们会依次介绍这几种控制层的流量类别。

1.网络控制类

网络控制服务类别用来归类那些网络控制层流量，这类流量对网络设备正常工作居功至伟。

（根据RFC 4594）网络控制流量的推荐方案包括:

■ 应为网络控制流量打上CS6 的标记（DSCP 48）；

■ 不妨将网络控制流量分配到一个拥有一定量带宽的带宽保障队列中。

这个类别中的流量应打上CS6（或DSCP 48）的标记，并为其提供一个拥有一定带宽的专用的带宽队列。针对这一类流量不应启用WRED，因为网络控制流量不应该被设备丢弃（如果这一类流量被设备丢弃，那么管理员应该重新为这类流量分配更合适的带宽）。这类流量包括EIGRP、OSPF、BGP、HSRP、IKE流量等。

2.信令类

信令服务类别用来归类支持IP语音和视频电话通讯的呼叫信令流量；从本质上讲，这类流量也属于语音和视频电话通讯设备创建的控制层流量。

（根据Cisco 对RFC 4594 的解毒）信令流量的推荐方案包括:

■ 应为信令流量打上CS3 的标记（DSCP 24）；

■ 不妨将网络控制流量分配到一个拥有一定量带宽的带宽保障队列中。

注释:如前文所述，Cisco对RFC 4594中广播视频和呼叫信令的标记进行了对调，也就是说， Cisco决定将广播视频流量标记为CS5，而将信令流量标记为CS3。

这个类别中的流量应打上CS3（或DSCP 24）的标记，并为其提供一个拥有一定带宽的专用的带宽保障队列。针对这一类流量不应启用WRED，因为信令流量不应该被设备丢弃（如果这一类流量被设备丢弃，那么管理员应该重新为这类流量分配更合适的带宽）。这类流量包括SCCP、SIP、H.323等。

3.操作/管理类

OAM服务类别（顾名思义）用来归类网络的操作、管理类流量。这类流量对于后续的网络维护和技术支持工作至关重要。

（根据RFC 4594）OAM 流量的推荐方案包括:

■ 应为OAM 流量打上CS2 的标记（DSCP 16）；

■ 不妨将OAM流量分配到一个拥有一定量带宽的带宽保障队列中。

这个类别中的流量应打上CS2（或DSCP 16）的标记，并为其提供一个拥有一定带宽的专用的带宽队列。针对这一类流量不应启用WRED，因为OAM流量不应该被设备丢弃（如果这一类流量被设备丢弃，那么管理员应该重新为这类流量分配更合适的带宽）。这类流量包括SSH、SNMP、系统日志、HTTP/HTTPS流量等。

10.10 Cisco（基于RFC 4594）为不同应用类别推荐的QoS策略

图10-4所示为本章上文中介绍的应用类别推荐方案汇总信息。

图10-4 Cisco根据RFC 4594为不同应用类别推荐的QoS策略

10.11 QoS标准的发展

在第一次面对图10-4 所示的（RFC 4598 定义的）12 类模型时，许多IT 经理和网络管理员都会感到不知所措。因此，为了避免不必要的惊慌失措，可以记住以下两点。

■ RFC 4594 并不是一个标准，它在RFC 中位于“信息”这一大类之中。因此，是否执行这个标准，是通盘采纳还是部分接纳，完全是各个企业的“主权”。

■ 这样一个复杂的模型也可以分步骤、渐进地实现，不必追求一蹴而就。

不过，网络管理员和网络架构师还是应该把这个高级QoS模型列入考量；随着业务和应用需求的不断发展，随着QoS RFC 的不断更新，这个QoS 模型无疑代表了这类技术的发展和推进方向。具体来说，近来至少有三项RFC文档可以体现出QoS模型会在复杂性上继续深入的趋势。

■ RFC 2597, Clarification

■ RFC 5865, Proposed Standard

■ RFC 4594, Update Draft

下面，我们对依次对这三个QoS RFC 进行介绍。

10.11.1 RFC 2597, Clarification

在RFC 2597 首度定义AF PHB 时，行业标准对此作出的解释是，端点流量应当被标记为AF类中的第一个丢弃优先级；换句话说，端点流量只应标记为AF11、AF21、AF31或AF41。此外，人们往往认为，AF类流量只能由限速器标记第2或第3级的丢弃优先级。

不过，2010年，就在Cisco收购了Tandberg之后不久，这个企业的产品团队和IT部门就面临着一个难题，那就是如何对Tandberg应用创建的各类视频流量区分对待，毕竟Cisco产品已经创建了与之类似的流量。有人建议，增加视频类别的数量，但这个建议会增加模型的复杂程度。也有人建议不要将各类多媒体会议端点的流量标记为AF41，而是直接在端点上（而不是由限速器）将它们发送的流量标记为AF42或AF43。这样一来，就可以将不同的视频流就分配到一个启用了DSCP WRED 的AF 类队列中，并为它们提供队列间QoS 策略。

Cisco 对于是否采取第二类建议踌躇不决，因为有人认为这种做法违反了RFC 2597 标准。但是，在反复认真阅读RFC 2597 之后，Cisco 对此作出了澄清，RFC 2597 并不妨碍端点将自己流量的丢弃优先级标记为第2级或第3级。

以此为例，无需添加任何队列类别，就可以将图10-4所示的12类模型扩展为20个QoS类别（只需要让端点将丢弃优先级标记为第2级或第3级，并在所有AF类队列中启用基于DSCP的WRED）。图10-5显示了按照Cisco澄清的内容扩展的QoS模型。

图10-5 根据对RFC 2597的澄清，所扩展的QoS模型

10.11.2 RFC 5865, Proposed Standard

2010 年，第二项增加QoS 模型复杂性的RFC 文档应运而生。在那一年，RFC 5865 提出了一个“可准入流量的差分服务代码点（DSCP）”的标准。

该RFC建议使用非标准的代码点来反映准入控制决策的结果。比如，它建议使用DSCP 44 标识获准进入网络中的语音流量（这个值不同于默认的语音标记DSCP 46/EF）。

此外，该RFC建议使用类似的非标准代码点来反映下面几种视频类流量的准入控制决策:

■ 广播视频流量；

■ 实时交互流量；

■ 多媒体会议流量。

注释:RFC 5865推荐使用非标准代码点来标识这些视频类别的准入控制决策，但是并没有推荐具体应使用哪些值来进行标识（在这个RFC中，只规定了用DSCP 44来标识获准进入网络的语音流量）。

这个标准等于间接要求人们在此前的模型中，添加个新的QoS服务级别（分别用于准入的语音流量、准入的广播视频流量、准入的实时互动流量和准入的多媒体会议流量）。因此，在此前QoS模型的基础上，新模型的应用类总数上涨到了24个，如图10-6所示。

图10-6 根据RFC 2597和RFC 2585扩展出来的QoS模型

10.11.3 RFC 4594, Update Draft

第三项提升了QoS 模型复杂性的RFC 是建议更新RFC 4594 的草案。这个草案建议使用28个不同的代码点标记值来标记14个流量类别，如表10-1所示（此为本书写作之时，该草案的建议）。

表10-1 RFC 4594提出的草案（2012年7月版）

续表

当然，这个草案最终是否会取代RFC 4594，如果会，那么它的最终形式为何，这一切都有待进一步的观察。

但是，至少有一点是相当明确的，那就是QoS标准意识到了业务的发展趋势，也意识到了QoS应用需求的发展变化。而且QoS标准会尽可能走在时代的前列，以适应未来QoS模型的需求。

一言以蔽之:QoS模型还会不断变化，也会愈加复杂。

10.12 小结

成功的QoS部署方案无不以企业/机构的目标作为首要的考量因素。因此，本章突破了这本书此前讨论的传统QoS技术，着眼于网络技术领域那些影响QoS设计方案的企业发展趋势。

本书介绍的全球网络趋势包括Internet的年平均流量以近30%的速度暴涨，无线与非PC设备产生的流量大量增加，视频流量在总流量中所占比例开始呈现主导趋势。

本章也对应用的趋势进行介绍，比如视频应用的发展变化，以及创建视频、传播视频和浏览视频的门槛不断降低，这些都对媒体的爆炸式增长产生了重要的影响。社交网络、自底向上的应用和设备开始出现在了工作环境当中。QoS设计对于多媒体应用和高清媒体的影响也在本章中进行了介绍。

在此之后，本章介绍了QoS的需求，以及RFC 4594中推荐的12种应用类型，即语音类、广播视频类、实时互动类、多媒体会议类、多媒体流类、业务性数据类、大数据类、尽力而为传输类、网络控制类、信令类和OAM类。

最后，本书介绍了三项重要的RFC 变更（也就是RFC 2597 的澄清、RFC 5865 的建议和RFC 4594 的更新），它们都显示出QoS 的技术方向还会不断发展变化，并且复杂程度会越来越高。因此，网络管理员应该走在技术的发展之前，不仅要适应当前的技术，也应该对QoS需求的发展作出预估。

10.13 扩展阅读

Cisco Visual Networking Index:Forecast and Methodology, 2011-2016（Cisco虚拟网络索引:前瞻与手段，2011-2016）:http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns827/white_paper_c11-481360_ns827_Networking_Solutions_White_Paper.html

Cisco MedianetQoS Design Strategy—At-A-Glance（Cisco媒体网QoS的设计理念——浅谈）:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/qosmrn.pdf

Cisco Enterprise Medianet Quality of Service Design 4.0—Overview（Cisco 企业媒体网QoS设计4.0——概述）:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSIntro_40.html

RFC 4594, Configuration Guidelines for DiffServ Service Classes（差分服务类的配置指南）:http://www.ietf.org/rfc/rfc4594

RFC 5865, A Differentiated Services Code Point (DSCP) for Capacity-AdmittedTraffic（准入流量的差分服务代码点[DSCP]）:http://tools.ietf.org/html/rfc5865

RFC 4594, Update Draft:Standard Configuration of DiffServ Service Classes（差分服务类配置标准的更新草案）:http://datatracker.ietf.org/doc/draft-polk-tsvwg-rfc4594-update/

第11章 QoS的设计原则与方法

在了解了QoS工具集，以及业务和应用的需求之后，读者应该已经能够将上述内容结合起来，为组织机构设计出统一的端到端QoS策略，这也正是本章的目标。

各类业务的需求各不相同，并没有一种放之四海而皆准的解决方案，因此本章将介绍三个等级（复杂度递增）的QoS模型战略。

■ 初级:4种类型的QoS模型战略。

■ 中级:8种类型的QoS模型战略。

■ 高级:基于RFC4594的12类QoS模型战略。

此外，本章也介绍了其他一些方法，以处理应用类型的扩展，以及使用QoS提高网络构架的整体安全性。

要牢记在面对一切特定的QoS问题，特别是在有丰富的QoS工具可供选择时，解决方案永远不是唯一的。因此，对一些简要的最佳方案设计原则进行一番了解，就可以简化和加快策略的设计过程。下面的内容将涵盖QoS最佳做法的设计原则。

11.1 QoS最佳做法的设计原则

解决某个问题的工具往往不止一个。有些工具虽然粗糙，但却十分有效，也有一些工具则可能既优雅又高效。打个比方，虽然用石头也可以将钉子砸到墙上，但是一个木匠（或者大部分正常人）应该更喜欢用锤子来钉钉子。

这个原则对于QoS工具来说也一样。例如本书在第1部分中介绍了很多可用来执行标记的工具，包括标记和限速。这两种工具均能对数据包进行标记，但它们的工作方式不同，因此这两种工具最好用于不同的设计情境中。了解一些QoS设计最佳方案可以有助于工程师在解决QoS问题时选用最为理想的工具。

11.1.1 硬件与软件QoS最佳方案

设计原则:

■ 只要可以选择，就应通过硬件而不是软件来启用QoS策略。

一项基本的QoS设计原则是，只要有选择的机会，就应通过硬件而不是通过软件来启用QoS策略。

有些Cisco路由器（如思科集成多业务路由器ISR）是通过软件来执行QoS策略的，这种做法会增加CPU的负载。实际增加的负载取决于许多因素，包括策略的复杂性与功能程度、流量的大小与构成、接口速率、CPU速率及路由器的内存等。

同时，也有其他一些设备（如Cisco Catalyst交换机）则会通过特定的硬件集成电路（ASIC）来执行QoS。因此即使在流量负载极大的情况下，这些交换机还是能以线速在GE/10GE的接口上执行最复杂的QoS策略，而且不会对CPU的性能造成哪怕一丁点的影响。

此外，还有一些新的平台（如思科汇聚业务路由器［ASR］）会以硬件和软件结合的方式处理QoS。也就是说，有些特定的QoS功能（如队列）可以在专用硬件ASIC上执行，而其他功能（如深度数据包监控）则仍通过CPU在软件中进行处理。

因此，如果可以选择，Cisco建议将QoS策略部署在能够通过硬件而不是软件来执行QoS操作的设备上，因为这可以让网络设备的利用效率更高。

比如说，假设有一名管理员要在分支网络中部署分类和标记这两项策略，那么他/她既可以在与终端设备直连的Catalyst交换机上（以硬件的方式）部署策略，也可在与交换机相连的ISR路由器的LAN边界接口上（以软件的方式）部署。此时，若管理员可以自主设计在何处部署策略，那么在Catalyst交换机上进行分类和标记就会更加高效。不过在有的环境中并不存在这样的选择。继续之前的例子，如果管理员希望对从分支网络产生的流量上执行NBAR深度数据包监控（Catalyst交换机暂不支持该功能），就需要在ISR路由器上执行所需的分类和标记策略。

11.1.2 分类和标记最佳方案

设计原则:

■ 在技术条件和管理条件均可行的前提下，要在尽可能靠近源执行分类和标记；

■ 在任何可能的情况下都要使用DSCP进行标记；

■ 按照基于标准的DSCP（差分服务代码点）的PHB（逐跳行为）标记，来确保设备间的互操作性，及未来的扩展性。

在分类和标记流量时，推荐的设计原则是在技术条件和管理条件均可行的前提下，尽可能靠近源在位置进行部署。该原则可适用于端到端的差分服务（DiffServ）和PHB。

总地来说，最好不要信任那些能够被用户PC或其他类似设备设置的标记，因为如果用户获准标记自己的流量，他们往往就会滥用预设的QoS策略。例如，如果网络上预设了EF（快速转发）PHB，那么PC只需将自己的所有流量都标记为EF，就可以轻松地劫持网络优先级队列来处理他的非实时流量。这种滥用行为可以在弹指间毁掉企业中实时应用的服务质量。不过，如果企业中有控制设备能够集中管理PC的QoS标记，信任这样的标记也不失为一种选择。

注释:虽然我们并不推荐信任来自PC及终端设备的QoS标记，但这种理念并不适用于所有的设计情景。例如，在WLAN（利用所有终端设备都争用的共享介质）环境中，为了在上游方向部署无线多媒体（WMM）QoS，最好信任来自终端设备的2层标记。本书的第4部分将深入探讨这些细节。但我们在这里想要强调的是，不信任终端设备只是一种一般性的建议，未必放之四海而皆准。

为了遵循上述建议，我们进一步建议读者尽可能地使用DSCP标记，因为3层IP头部的标记是端到端的，与2层标记相比，3层标记的粒度更细，也更具扩展性。要知道，在媒介发生改变时（如LAN到WAN/VPN的边界），2层标记就会丢失。2层标记的粒度也更粗。例如，像MPLS EXP 一样，802.1Q/p 的CoS（服务类型）只支持3 比特位的标记（值为0～7）。因此2 层只支持最多8 类流量，且不支持类间相对优先级（如RFC 2597，Assured Forwarding Drop Preference Markdown）。而3 层DSCP 标记则支持多达64 种类型的流量。

随着企业和服务提供商之间的界线愈加模糊，同时对QoS标记互操作性和互补性的需求愈发强烈，管理员更应使用基于标准的DSCP PHB 标记来保障不同QoS 标记的互操作性和未来的可扩展性。

正如前文所述，因为推荐的企业媒体网络标记都是基于标准的标记，所以企业可以轻松地在接口上应用服务提供商的标记。如果使用了基于标准的DSCP标记，那么当企业之间发生合并、收购及战略结盟时，对网络进行合并也会更容易实现。

11.1.3 限速及降级的最佳做法

设计原则:

■ 在尽可能靠近源的位置对流量进行限速；

■ 尽可能根据基于标准的规则执行降级（markdown）。

将无用流量转发给下游节点再由下游几点进行限速和丢弃，这样做毫无道理，这句话尤其适用于那些DoS攻击或蠕虫攻击引发的恶意流量。此外，攻击产生的大量流量会最大程度地消耗网络设备的处理资源，从而造成网络中断。因此，建议在尽可能靠近源的位置对流量进行限速。这种策略同样适用于合法流量，因为蠕虫产生的流量也可以伪装成合法流量并使用知名的TCP/UDP端口，而这同样会导致大量流量涌入网络基础设施。由此产生的过载应该在源的位置进行监测，并进行适当的降级处理。

只要设备支持，就应该按照RFC 2597（The AF PHB Definition）这种公共标准的规则来执行降级（markdown）处理。例如，标记为AFx1的过量流量应该降级为AFx2（若支持双向限速的话，也可以将其降级为AFx3，详见RFC 2698）。在降级之后，管理员应该配置一些拥塞管理策略（类似基于DSCP的加权随机早期检测机制），以便让设备丢弃（比AFx2）更多的AFx3流量，而相比AFx1流量，则丢弃更多地丢弃AFx2流量。

11.1.4 队列及丢弃的最佳做法

设计原则:

■ 在所有可能发生拥塞的节点上启用队列策略；

■ 尽可能为各个类型的应用都分配专属的队列；

■ 只选用至少能够提供如下四种标准队列的平台/服务提供商。

■ RFC 3246 快速转发PHB；

■ RFC 2597 确认转发PHB；

■ RFC 2474 默认转发PHB；

■ RFC 3662 低尽力型单域转发行为。

无论网络状况如何，关键的业务应用都要获得有保障的服务。提供服务保证的唯一方法是在所有可能发生拥塞的节点上启用队列技术，不管其发生拥塞的可能性有多小。这个原则不光适用于速率不匹配的情况比较明显的园区到WAN/VPN边界，也适用于有可能因为超额利用率而导致瞬时拥堵和缓冲区溢出的园区内部交换链路。因为除启用队列技术之外，也没有什么其他的方法能够在速度不匹配的情况出现时保证服务的水平。

此外，由于每种类型的应用在服务级别方面要求各不相同，因此每个应用类都应该分配到一个自己专属的队列。通过这样的方式，管理员就可以为不同的应用有针对性地分配带宽，并制定丢弃策略，以满足它们独特的QoS需求。否则，将多种类型的应用分配到一个共同的队列，那么当带宽资源就会由这些应用所共享时，管理员也就无法根据不同应用的需求对它们进行控制了。

上述建议适用于理想情况，但我们的底线是，在为富媒体应用部署业务QoS时，所有平台（或服务提供商链路）至少都应支持如下几种队列行为:

■ 实时队列（支持RFC 3246 EF PHB 服务）；

■ 保障带宽队列（RFC 2597 AF PHB 服务）；

■ 默认队列（支持RFC 2474 DF 服务）；

■ 约束带宽队列（支持RFC 3662 清道夫服务）。

下面我们将详细介绍上述几个队列服务。

1.EF队列的推荐做法:33%LLQ规则

设计原则:

■ 将严格优先级队列的带宽限制在链路总带宽的33%之内；

■ 使用准入控制机制管理严格优先级流量；

■ 不要在这个队列上启用WRED。

实时或严格优先级队列符合RFC 3246 EF PHB 的定义。分配给实时队列的带宽量通常是可变的。然而，如果将大部分带宽预分配给严格优先级队列（实际上就是先进先出[FIFO]队列），那么无论对抖动敏感的实时应用（在FIFO优先级队列中与互相竞争），还是对非实时应用（带宽的分配情况可能会周期性地出现波动，这取决于优先级队列处理流量的瞬时量），QoS的整体功能都会有所削弱。要知道收敛的目标是使语音、视频和数据应用透明地共存于同一个网络中。实时应用独占了链路，非实时应用的响应时间波动剧烈，就会破坏收敛网络的透明性。

例如，如果有一条DS3链路（45Mbit/s），管理员通过配置让这条链路支持两个TelePresence（CTS-3000）以EF PHB 服务发起呼叫。这两个系统均支持最高分辨率（全HD-1080p），同时也启用了所有可选的组件，因此每个呼叫需要占用约20Mbit/s的严格优先级队列。在TelePresence呼叫建立前，非实时应用已经占用了100%的链路带宽（为简化这个示例，假设本例中链路上没有其他的实时应用）。然而，一旦这些TelePresence通话建立起来之后，所有的非实时应用突然间就只能去竞争剩余的大约10%链路带宽。此时，TCP窗口将会生效，众多应用将会挂起，它们会超时或卡在无响应的状态，而这经常会导致用户向IT部门抱怨糟糕的网络情况（这种配置方式很烂，但有时网络也能正常工作）。

为了避免这样的情况，Cisco技术营销部门（Cisco Technical Marketing）进行了大量的测试，并发现当实时流量超过链路带宽的1/3时，非实时应用的响应时间将大幅度增加。事实上，无论是测试结果还是实际的客户部署情况，都表明最佳的队列方案是将严格优先级队列容量限制在链路带宽总量的33%以内。对于融合实时应用和数据来说，让严格优先级队列占据这样的比率是一个既保守又安全的设计规则。

注释:如前所述，Cisco IOS软件可以支持（和配置）多个严格优先级低延迟队列（LLQ）。在这样的多LLQ队列环境中，上述设计原则的应用方法为，将所有LLQ的带宽之和限制在链路总量的1/3之内。

上述严格优先级队列的设计规则只是一种实现最佳方案的建议，而不是强制的要求，理解这一点是非常重要的。在有些情况下，即使遵守这样的规则也无法满足特定的业务目标。在这样的情况下，企业必须根据自己的具体要求和限制来规划方案。在为严格优先级队列分配过量带宽所带来的优势，与这样做给实时数据流和非实时数据流的响应时间所带来的消极影响之间进行权衡，这一点也很重要。

此外，分配给严格优先级队列的流量也应该通过准入控制机制进行限制，以便防止这些流量占尽非实时应用的带宽。

最后，WRED（或任何类似的拥塞避免机制）都不应该在严格优先级队列中启用。分配给这种队列的流量往往是对丢包极为敏感的流量（例如，语音，特别是高清视频）；因此，永远不应该针对这类数据流采取早期丢弃的策略；如果管理员发现这个队列出现了丢包的情况（就说明是尾部丢弃，而不是早期丢弃），他/她就应该调整队列的长度以确保丢弃的情况不再发生。

2.AF队列的推荐做法

设计原则:

■ 根据应用的需求为其分配有保障的带宽；

■ 在这些队列上启用基于DSCP的WRED。

管理员至少应该为一个队列设置AF PHB。根据标准，管理员可以最多为4 个队列设置这项服务:AF1、AF2、AF3和AF4。管理员应该按照分配到这个应用类别的流量需求，为其分配有保障的带宽。

此外，管理员应该对这类队列启用基于DSCP的WRED。从概率上讲，标记为AFx3的流量比标记为AFx2的流量更早也更容易被丢弃，而标记为AFx2的流量也会比标记为AFx1的流量丢弃得更多。

3.DF队列的推荐做法

设计原则:

■ 为默认的尽力而为类（Best Effort class）分配至少25% 的链路带宽；

■ 在默认类上启用WRED。

对于所有没有专门为其分配应用类型的流量来说，尽力而为类是默认的流量类型。只有当管理员为一个应用选择了某种优先/特别的处理方式时，它才会从默认类中移除出来。因为大多数企业的网络上都运行着上千个应用，因此必须为这种类型分配充足的带宽来处理大量将这种类型作为默认类的应用流量。因此Cisco建议为默认的尽力而为类型预留至少25%的链路带宽。

此外，为了提升吞吐量并减少TCP同步，建议在默认类上启用WRED。因为所有发往此类的流量都将会被标记上相同的DSCP值（0），因此WRED在执行丢包决策时并没有“权重”这项因素。有鉴于此，拥塞算法实际上就是随机早期检测（RED）。

4.清道夫类队列的推荐做法

设计原则:

■ 为清道夫类队列分配最少的带宽；

■ 清道夫队列不需要启用WRED。

无论何时，只要启用了清道夫队列，就都应该为其分配最少的带宽，如1%（或平台支持的最小带宽）。

注释:在有些平台上，无法为大数据和清道夫流量分配不同的队列，这有可能是因为队列分配是由服务类型（CoS）的值所决定的（而这两种应用类型的CoS值都是1），也有可能是因为硬件队列数量有限，因而无法为这两个应用设置独立的专用队列。在这种情况下，分配给清道夫/大数据队列的带宽可适度调整，如调整为5%。

在清道夫类队列上并不需要启用WRED，是因为没人指望分配给这种队列的流量是“善意的”，也无需对这类流量提供任何服务保障。而WRED只会在拥塞发生时才会被激活，但彼时这个队列的丢包情况应该已经相当严重了。因此，增加这个特性并无太大作用。何况，如果在用软件处理QoS的路由器上针对这类流量启用WRED，会造成资源的浪费，因为这样做会消耗额外且不要的CPU资源。

图11-1总结了这些最低队列的比例及推荐分配方案。

图11-1 最低队列的比例及推荐分配方案

5.WRED的推荐做法

设计原则:

■ 在AF队列上启用基于DSCP的WRED；

■ 在DF队列上启用WRED；

■ 不要在EF队列上启用基于DSCP的WRED；

■ 不要在清道夫队列上启用WRED；

■ 不要在控制流量应用类上启用WRED；

■ 可选:将WRED的门限值调整一致。

如前所述，建议在所有AF 队列上启用基于DSCP 的WRED（遵循AF PHB 的标准），并在默认的尽力而为队列上启用WRED（提升应用的吞吐量）。

此外，我们之前也提到过，不建议在EF队列上启用WRED（因为这种队列中的流量往往对丢包比较敏感），也不要在清道夫队列上启用WRED（不仅没有必要，还可能造成浪费）。

同理，不建议在其他所有用来处理控制流量的专用队列（如路由、信令或管理队列）上启用WRED。这样的流量对于网络构架的正常运行来说至关重要，因此永远不该对它们执行早期丢弃。如果你注意到分配给控制流量类型的队列发生了丢包的情况，那么这些队列就应该进行调整。

最后，有些平台上默认的WRED门限值与其他平台并不一致，或不完全使用队列深度。因此，可以按照下列的方式将其调整一致。

■ 将AFx3的最小WRED门限值调整为队列深度的60%。

■ 将AFx2的最小WRED门限值调整为队列深度的70%。

■ 将AFx1的最小WRED门限值调整为队列深度的80%。

■ 将所有WRED最大门限值调整到100%。

图11-2所示为这些可选的WRED调整建议。

图11-2 调整WRED的建议

11.2 QoS的设计原则

在了解了这些最佳的QoS设计原则之后，下面我们将会开始介绍如何将它们组合成针对某项业务或组织的端到端策略。显然，业务目标和限制条件如此多变，世上从来都没有放之四海而皆准的解决方案。因此，有如下3个通用的模型:

■ 4类模型QoS战略；

■ 8类模型QoS战略；

■ 12类模型QoS战略。

下一节将按顺序对这些策略一一进行介绍。

11.2.1 4类模型QoS战略

4类QoS模型代表了一个基本的端到端QoS策略。部署IP电话需要一个3个类的模型（语音、信令和尽力而为/默认流量各为一类）。4类模型仅仅在这种IP电话通讯的最低需求基础上，增加了一个额外的类，这个增加的类有可能是用于业务数据应用的AF类，也有可能是用于视频/多媒体流量的AF类，甚至还有可能是一个清道夫类，具体的类型由QoS的业务目标而定。

这个4类QoS模型的流量类型、标记及处理方法如下。

■ 语音类:标记为EF，按照EFPHB的方式进行处理，但将严格优先级的带宽限制在33%以内。

■ 控制类:标记为CS3，为其预留7%的专用带宽。虽然这种类型主要用来处理信令流量，但其他控制流量（如OAM）也可以通过这个类型来接受服务。

■ 业务数据类:标记为AF21，按照AF PHB的方式进行处理，为其预留35%的专用带宽，启用基于DSCP的WRED。

■ 尽力而为类:标记为DF，为其预留25%的专用带宽，启用WRED。

图11-3显示了这种4类QoS模型的分类结构及相应的标记方式。

图11-3 4类QoS模型的分类结构和标记方式示例

图11-4显示了这种4类QoS模型的队列分配方式。

这个4类QoS模型是本书中介绍的所有4类QoS模型配置的基础。

图11-4 4类QoS模型的队列结构示例

11.2.2 8类模型QoS战略

8类QoS模型在之前的4类模型基础上增加了两个多媒体流量的类型:

■ 多媒体会议类；

■ 多媒体流类。

8类模型还新增了一个明确的网络控制类（用于处理路由协议和其他网络基础设施的控制流量）和一个“低于尽力而为”的清道夫类。

这个8类QoS模型的流量类型、标记及处理方法如下。

■ 语音类:标记为EF，按照EFPHB的方式进行处理，但将严格优先级的带宽限制在10%以内。

■ 多媒体会议类:标记为AF41，可以用EF PHB 的方式进行处理（借用了RFC 4594 中的实时交互类的处理方式，实时交互类在此模型中并未明确使用），但将严格优先级的带宽限制在23%以内。

因此，分配给语音和多媒体会议类的严格优先级带宽之和低于EF队列建议的33%限制。

■ 多媒体流类:标记为AF31，按照AF PHB的方式进行处理，为其预留10%的专用带宽，启用基于DSCP的WRED。

■ 网络控制类:标记为CS6，并为其预留5%的专用带宽；虽然这种类型的主要目的是为了服务信令流量，但其他控制流量（如OAM）也可以在这种类型中得到服务。

■ 信令类:标记为CS3，并为其预留2%的专用带宽。

■ 业务数据类:标记为AF21，按照AF PHB的方式进行处理，为其预留24%的专用带宽，启用基于DSCP的WRED。

■ 尽力而为类:标记为DF，为其预留25%的专用带宽，启用WRED。

■ 清道夫类:标记为CS1，并将这一类的带宽限制在总带宽的1%以内。

图11-5显示了这种8类QoS模型的分类结构及相应的标记方式。

图11-5 8类QoS模型的类结构和标记机制示例

图11-6显示了这种8类QoS模型的队列分配方式。

图11-6 8类QoS模型的队列结构示例

这个8类QoS模型是本书中介绍的所有8类QoS模型配置的基础。

11.2.3 12类模型QoS战略

12 类模型代表了Cisco 对RFC 4594 的解读（如前文所述，唯一变化是Cisco 将RFC 建议的信令标记和广播视频标记进行了交换）。

12类QoS模型在此前8类模型的基础上为无弹性多媒体流量增加了两个额外的类型，即实时交互类和广播视频类。12类模型还新增了一个专用的OAM类，同时还为大数据增加了一个限制带宽的类别。

这个12类QoS模型的流量类型、标记及处理方法如下。

■ 语音类:标记为EF，按照EF PHB 的方式进行处理，但将严格优先级的带宽限制在10%以内。

■ 广播视频类:标记为CS5，可以用EF PHB 的方式进行处理，但将严格优先级的带宽限制在10%以内。

■ 实时交互类:标记为CS4，可以用EF PHB 的方式进行处理，严格优先级的带宽限制在13%以内。

因此，分配给语音、广播视频和实时互动类的严格优先级带宽之和低于EF队列建议的33%限制。

■ 多媒体会议类:标记为AF41，按照AF PHB的方式进行处理，为其预留10%的专用带宽，启用基于DSCP的WRED。

■ 多媒体流类:标记为AF31，按照AF PHB的方式进行处理，为其预留10%的专用带宽，启用基于DSCP的WRED。

■ 网络控制类:标记为CS6，并为其预留5%的专用带宽。

■ 信令类:标记为CS3，并为其预留2%的专用带宽。

■ 管理/OAM类:标记为CS2，并为其预留3%的专用带宽。

■ 业务数据类:标记为AF21，按照AF PHB的方式进行处理，为其预留10%的专用带宽，启用基于DSCP的WRED。

■ 大数据类:标记为AF11，按照AF PHB 的方式进行处理，为其预留4% 的专用带宽，启用基于DSCP的WRED。

■ 尽力而为类:标记为DF，为其预留25%的专用带宽，启用WRED。

■ 清道夫类:标记为CS1，并将这一类的带宽限制在总带宽的1%以内。

图11-7显示了这种12类QoS模型的分类结构及相应的标记方式。

图11-8显示了这种12类QoS模型的队列分配方式。

图11-7 12类QoS模型的类结构和标记机制示例

图11-8 12类QoS模型的队列结构示例

这个12类QoS模型是本书中介绍的所有12类QoS模型配置的基础。

11.2.4 应用类扩展QoS战略

随着企业的业务目标和应用需求不断发展，组织机构的QoS战略也在发展变化。虽然许多企业也许并不愿意部署复杂的QoS模型（如12类模型），但各个机构至少会考虑到它们的QoS模型可能需要满足不断变化的业务需求。

值得深谋远虑的内容包括哪些标记值在未来需要进行改变，以及何时、如何划分类别（包括为不同类别分别分配多少带宽）。

Cisco建议持续监控应用流量大小和服务水平并根据需要逐渐进行相应调整。这种方法可以满足用户对网络的期望，并减轻网络管理人员大刀阔斧地改造网络QoS策略的负担。图11-9展示了一个将初级4类QoS模型逐渐迁移到12类QoS模型的阶段性过程。

图11-9 应用类型扩展战略的示例

网络管理员可以在一个服务类别中引入多个标记来跟踪类中不同类型的应用，以确定何时需要对应用类别进行分割。

例如，有一个企业使用了前文中介绍的8类模型。在这个模型中，多媒体会议类会被标记为AF41。现在假设这个类一开始是专用于处理基于桌面的会议应用的，但随后网络中又部署了几个高清晰度室内系统（如TelePresence设备）以进行测试。那么，为了调整并跟踪这些TelePresence系统需要的服务水平和流量大小，网络管理员可以将这些网络系统的流量标记为CS4。这样一来，一个用于处理多媒体会议流量的队列中就有了AF41和CS4两种流量。而网络管理员就可以监控TelePresence数据流的大小和质量，并在合适的时机将这个类分割成两个子类:一个用于处理实时交互流量（如TelePresence），另一个用于处理多媒体会议流量（如桌面会议应用）。

当需要分割应用类型时，网络管理员应该尽可能在带宽分配上保持与之前模型的一致性和向后兼容性。这样以来，用户的期望与体验也就不会发生什么变化。图11-10显示了在从4类模型到8类模型过渡的过程中，如何渐进式地细分带宽。

图11-10 应用类扩展队列的战略示例

11.2.5 用于安全策略的QoS

虽然部署QoS的首要目标是在众多应用类中预设服务的优先级（有时是为不同类型的应用提供不同的服务），但QoS策略也具有一种战略性作用，那就是为网络基础设施提供一层额外的安全保护，特别是在网络中存在缓解拒绝服务（DoS）攻击和蠕虫攻击的情况下。

DoS攻击主要有两类。

■ 欺骗攻击:攻击者假装提供合法的服务，但实际上是给请求者（如有）提供错误的信息。

■ 泛洪攻击:攻击者大量生成并传播流量，直到服务资源（服务器或网络基础设施）无法承受为止。

欺骗攻击通过授权和加密技术就可以很好地解决。而泛洪攻击则可以通过QoS技术进行缓解。

而蠕虫攻击则会探测目标主机的安全漏洞，并携带包含自我传播机制的恶意负载。网络基础设施一般不是蠕虫攻击的直接目标，但蠕虫成倍地自我传播时，也可能对网络基础设施造成连带伤害。因为快速倍增的流量最终会耗尽路径中路由器和交换机的CPU与硬件资源，从而间接导致合法数据流被拒绝服务，如图11-11所示。

图11-11 DoS/蠕虫攻击的直接损害及间接附带损害

抵御这种攻击的一种措施是对蠕虫进行破解，设置入侵检测机制与ACL/NBAR策略来限制这类信息的传播。但随着技术的发展，蠕虫亦变得愈发复杂和完善，从合法流量流中识别出这类信息也就越加困难。因此，从蠕虫开始传播时到完成下列两项操作之间的时间差也会加大。

■ 对该蠕虫的运行原理及其网络特性进行充分分析。

■ 将合适的补丁、插件或ACL添加到路径中可能存在蠕虫的网络设备上。这项操作任务本身就由可能因攻击而受到阻碍，因为网络设备在攻击期间有可能无法进行管理访问。

从绝对时间的角度上来看，上面介绍的时间也许看上去并不算长（比如几分钟的时间），但其造成的相对破坏机却有可能非常严重。例如，感染Slammer蠕虫的主机数量平均每8.5秒就可以翻倍，在这种蠕虫发布后的11分钟内，就对超过5千5百万台其他主机进行了扫描！

有一种方法可以在企业网络内部主动出击，缓解DoS/蠕虫攻击，那就是在网络内合适的位置设置能对标志着DoS或蠕虫攻击的异常网络行为及时响应的控制平面及数据平面限速策略。控制平面的限速可以保护（如路由器或交换机等）网络设备的CPU，使其不会因为处理中断而没有足够的时钟周期转发流量最终导致宕机。数据平面的限速（亦称为清道夫类QoS）的作用则是防止设备将全部带宽都用来转发DoS/蠕虫流量，使得合法流量无法得到传输。此外，数据平面限速策略也可以让设备更少地处理那些不必要的数据包，进而间接地保护控制平面。

1.控制平面限速建议

路由器或交换机可从逻辑上分为以下4个功能组件或平面:

■ 数据平面；

■ 管理平面；

■ 控制平面；

■ 服务平面。

大多数流量都是从数据平面穿过路由器的。不过，路由处理器还要处理一些特定的数据包，如路由更新包、keepalive数据包和网络管理数据包。这些流量一般就会称为控制与管理平面流量。

因为路由处理器对网络运行至关重要，所以路由处理器、或控制与管理平面一切形式的服务中断都对业务造成巨大的影响。针对路由处理器的DoS攻击（无论是否为恶意攻击）通常都会产生大量的“踢下线”流量（导致处理器中断的流量），并造成路由处理器的CPU使用率过高。这种会对网络稳定性和可用性带来毁灭性影响的攻击方式，通常具有如下特征。

■ 路由处理器的CPU使用率过高（接近100%）。

■ 线路协议的keepalive数据包和路由协议更新包出现丢包的情况，进而导致路由翻动和网络变化。

■ 因为CPU使用率高，命令行界面（CLI）的交互会话可能会变得非常缓慢或完全无响应。

■ 路由处理器资源耗尽——合法的IP数据包将无法利用设备的内存或缓存等资源。

■ 数据包队列出现拥塞，导致设备无差别丢弃其他的入站数据包（或因为缺少缓存资源丢弃包）。

控制平面限速（Cisco IOS 路由器的CPP 或Cisco Catalyst 交换机的CoPP）的方法可以满足保护控制与管理平面的需求，确保路由稳定、资源可用和数据包能够得到转发。它可以通过MQC（模块化QoS CLI）使用控制平面专用的配置方式，对控制平面数据包执行过滤和速率限制。

图11-12显示了多个接口的数据包流量。其中，控制平面服务的方框表示，发往控制平面的数据包会受到由控制平面的校验。

CPP和CoPP可以通过保护路由处理器，而在攻击期间保障路由器和网络的稳定。为此，我们推荐的最佳做法是在所有支持CPP/CoPP的路由器和交换机上都将这一特性作为关键的保护机制来进行部署。

图11-12 交换机/路由器内部的数据包流

为了成功地部署CPP，必须理解现有控制与管理平面的访问需求。虽然我们很难精确地判断出要过滤的流量具有哪些特征，但是定义CPP策略的推荐做法还是可以总结为下面这3个步骤。

1.在刚开始部署时，先定义一个能够放行大部分流量的宽松策略。

2.监测这个宽松策略收集到的流量特征统计数据。

3.使用上一步中收集的统计数据来收紧控制平面的策略。

注释:CoPP的主要作用是提供一种安全机制，因此，尽管本书第4章的例4-5也提供了一个CoPP的策略示例，但关于CoPP的大部分内容还是超出了本书的讨论范围。关于更多部署CoPP的细节，请参阅特定平台上这一特性的配置指南。

2.数据平面限速建议

用于保护控制平面的方式也同样可以应用于数据平面。数据平面限速有两个组成部分。

■ 检测终端设备发出的流量，并将“异常”流重标记为CS1（清道夫标记值）的园区访问边界限速器。

■ 所有对于清道夫流量提供区分服务类型的节点的队列策略。

图11-13显示了在数据平面中，用QoS策略执行限速的这两大组成部分。

大多数终端设备的流量模式都不难预测，因此就可以通过限速器来辨认“正常”数据流（代表终端设备通常产生流量速率的95%的流量）与“异常”数据流（其余的流量）。例如，一个本应连接到IP电话的端口如果收到超过128kbit/s的流量就是异常的。同样，如果一个本应连接到一个Cisco TelePresence 系统的端口接收到了超过20Mbit/s 的流量也是异常的。这两种情形都表示网络遭到了或有意或无意的滥用。终端PC和无线设备的流量特征也能通过统计分析来相对精确地找出一个基准。

图11-13 交换机/路由器内的数据包流

注释:例如，对于Windows系统的用户，Windows任务管理器（可同时按住Ctrl+Alt+Del选中）就能通过图形化的方式显示出网络统计数据（在网络标签页可见）。大多数用户通常都惊讶于自己PC在日常使用时的平均网络使用率，与链路的带宽速率相比竟然如此之低。

访问边界的限速器则没有那么智能。它们不能按照特定的网络特征来匹配出某种攻击类型，而只能在尽可能靠近源的位置来检测流量大小，并对异常的大量流量进行响应。这种方法比较简单，因此在编写限速器时，无需对攻击产生及传播的具体细节有所了解。恰恰是因为这种接入层检测限速器不够智能，才能让这类限速器不受蠕虫变异及进化的影响，对蠕虫攻击保持一以贯之的效果。这些限速器并不关心流量是如何产生的，或者流量具有什么特征；它们只关心有多少流量被传输到了线缆上。因此，在高级蠕虫不断改善自己繁殖方式的大背景下，这类限速器仍能对它们进行有效地限速。

例如，在大多数企业中，PC持续产生超过链路容量5%的流量是一种相当不正常的情况（在95%统计置信区间内）。这意味着在大多数组织中，对于吉比特以太网接入交换机端口而言，终端用户的PC持续产生超过50Mbit/s的上行链路流量就是不正常的。

注释:对于PC终端的正常终端使用值（5%）只是个例子，这很重要。这个值很可能因企业的不同或部门的不同（如部门职能不同）而变化。

有一点内容读者应当理解，那就是QoS策略中的数据层限速不是把所有的流量都限制为50Mbit/s的流量，将超出的流量全部丢弃。要是这么干的话，又何必使用吉比特以太网交换机来连接终端设备呢？因此，园区接入层的限速器根本不应丢弃任何流量；它们仅（在流量速率异常的情况下）对流量进行重标记。这些限速器应该与所有网络节点上（那些包含了专门处理清道夫流量的差分服务类别的）的队列策略结合起来。当且仅当链路出现拥塞时，队列策略才会生效。只有在流量超过了链路的承载能力（迫使队列策略生效，而队列缓冲达到上限）时，才会出现丢包的情况。在这种情况下，流量要么（按照后来先丢的原则）被无差别地丢弃，要么按照某种智能的方式进行丢弃（如果出现前文所涉之异常流量，就是这种情况）。

我们来看一看这种做法对于合法流量以及通过DoS或蠕虫攻击产生的非法流量，都会如何进行处理。

如果是前一种情形，比如当PC传输或备份一个大型文件时，生成了超过50Mbit/s的流量。园区网（在正常操作条件下）几乎不可能会出现拥塞，因为园区网通常都足以承载这些流量。园区网连接分布层和核心层的上行链路通常都是吉比特以太网或万兆以太网，要想让这种环境出现拥塞，接入层交换发送的流量好歹也要（分别）达到1000Mbit/s或10000Mbit/s才行。如果流量的目的是WAN/VPN链路的远端，那么即使不使用接入层限速器，流量也常常会遭遇队列和丢弃，因为园区网与WAN/VPN之间的速率不匹配常常会在边界产生瓶颈。于是，TCP滑动窗口机制最终就会找到一个（低于50Mbit/s）最优速率来传输文件。那些用来将超速流量降低为清道夫类别的接入层限速器并不会影响到合法的流量，最多只会对它们进行重标记。不会因为数据层限速器的缘故，导致这类流量遭到重排序或丢弃。

而在后一种情形中，由DoS或蠕虫攻击导致接入层限速器发挥作用，效果可就不同了。由于主机遭到感染导致流量激增，此时即使园区网内部也有可能因此出现拥塞。比如说，如果一台只连接了11台终端用户PC的交换机开始大量传播蠕虫流量，直至达到吉比特的链路承载上限，那么哪怕万兆的上行链路/核心链路也有可能会出现拥塞，于是队列及丢弃策略就会生效。此时，VoIP和媒体应用，甚至尽力而为传输的应用都可以获得高于蠕虫流量的优先级（因为清道夫类的流量被丢弃的比例最高）。此外，管理员也仍然可以对设备发起管理访问，进而通过打补丁、装插件、添加ACL和NBAR策略的方式应对网络攻击。WAN/VPN链路也可以得到类似的保护，这是一个重大的利好，因为WAN/VPN链路往往是DoS/蠕虫攻击中第一个中招的链路。而清道夫类策略可以明显缓解因DoS或蠕虫攻击产生的网络流量。

因此，网络管理员要想实施数据层限速的方式，就需要对应用进行分析，确认正常流量与异常流量的构成，置信区间要达到95%以上。区分正常/异常数据流的门限值因企业与应用的不同而异。不必过于细致地区分流量的行为，这样做不仅极其耗时，浪费资源，而且得到的信息每天都会变化。切记，合法流量偶尔也会突破门限值，但这类流量不应该遭到清道夫类的“惩处”。只有那些由大量不同主机持续不停发送的异常数据流（也就是那些高度疑似DoS/蠕虫的流量），才应该在合法流量接受服务之后，大量被设备丢弃。

要想让这类流量得到应有的处理，需要在园区接入层边缘部署限速器，以便将异常流量重标记为清道夫类（CS1）。此外，只要有机会，就应该利用microflow 限速器这类工具在分布层部署第二级限速。为了对这些重标记策略进行补充，有必要在网络中部署差分清道夫类的队列策略。

本章的最后一项内容是:读者一定要搞清楚缓解攻击与彻底防御攻击之间的区别。控制层限速无法保证DoS或蠕虫攻击不再发生，它只能降低遭受这类攻击的风险，让网络设备在遭受这类攻击时受到的危害更小。因此，在启用QoS的网络架构之外，还应该部署层一个完善的安全策略，这一点至关重要。

11.3 小结

本章始自一些最佳做法的设计原则，这些设计原则可以充当端到端QoS战略的基础。这些原则包括:

■ 只要有可能，就应在硬件（而不是软件）中启用QoS策略。

■ 在技术和管理均可行的条件下，应在尽可能接近源的位置对应用进行分类和标记。

■ 在一切有可能的条件下，均使用DSCP标记。

■ 采用标准的DSCP PHB 标记确保设备间的互操作性，方便未来的网络扩展。

■ 在技术和管理均可行的条件下，应在尽可能接近源的位置，按照标准规则对流量进行限速与降级。

■ 在一切有可能出现拥塞的节点上，启用队列策略。

■ 只要有可能，应该为每种应用类别分别一个专用的队列。

■ 只使用提供最少4种标准队列的平台/服务提供商:

■ RFC 3246 快速转发PHB；

■ RFC 2597 确认转发PHB；

■ RFC 2474 默认转发PHB；

■ PFC 3663 低于尽力而为的逐域行为（per-domain behavior）。

■ 将严格优先级队列的流量限制在带宽总量的33%之内。

■ 用一个准入控制机制来控制严格优先级流量。

■ 不要在严格优先级队列上启用WRED。

■ 为AF队列提供有专用带宽，并启用基于DSCP的WRED。

■ 为尽力而为类提供至少25%的链路带宽，并在默认类别上启用WRED（有效的RED）。

■ 为清道夫类队列分配最小带宽。

此外，端到端的QoS可以表现为一个:

■ 4类的QoS模型；

■ 8类的QoS模型；

■ 12类的QoS模型。

最后，本章介绍了扩展应用类别的最佳方案，以及使用QoS工具来提升网络基础设施安全性的方法。

11.4 扩展阅读

MedianetQoS Design Strategy At-A-Glance（媒体网QoS 设计战略浅析）:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/qosmrn.pdf

Enterprise Medianet Quality of Service Design 4.0—Overview（企业媒体网服务质量设计4.0—概述）:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSIntro_40.html

第12章 战略性QoS设计的案例研究

本章是一系列案例研究章节中的第一章，将奠定其余各章的基础。案例研究设计章节的目的是将各个部分的关键设计概念和建议（其中一些看起来可能看起来很抽象且理论）以实践、综合且全面的方式展现出来。每个案例研究设计章节都建立在前文案例的基础上，将其汇总在一起，代表了这个虚拟的企业（以Tifosi Software公司为例）整体的端到端服务质量（QoS）设计。

12.1 Tifosi Software公司:公司概况

Tifosi Software 公司是一个（虚拟的）总部设在加利福尼亚州圣克拉拉的公司，致力于开发云计算软件。Tifosi在全球有大约5000名员工，工程及销售办事处遍布北美（美国、加拿大和墨西哥）、南美（巴西和阿根廷）、欧洲（比利时、法国、德国、瑞士和英国）、亚太地区（澳大利亚、中国、印度、日本和新加坡），以及中东/非洲（迪拜、以色列和南非）。

12.2 原始（4类）QoS模型

Tifosi原始的QoS模型非常基础，并且遵从了Cisco的建议。它由一个4类的QoS模型构成，用来支持IP电话通讯和一个本地定义的“关键任务数据”流量类。这些类如下所示。

■ 语音:标记为EF，分配33% 的带宽，使用严格优先级队列，并执行EF PHB。

■ 信令:标记为CS3，分配7%的保证带宽。

■ “关键任务数据”:标记为AF31，分配35% 的带宽，并执行AF PHB。

■ 尽力而为:标记为DF，分配25%的保证带宽。

关键任务数据类由每个部门（包括工程、销售、市场、财务和人力资源）的经理自行选择，他们将自己部门的前三个关键业务应用提交给网络团队。这些流量在网络边界都会被标记为AF31，并为其实施端到端的AF PHB。

图12-1显示了Tifosi Software 原始的QoS 类和队列模型。

图12-1 Tifosi Software案例研究:原始4类QoS模型和队列模型

12.3 重新设计QoS的业务催化剂

一些业务需求使得Tifosi Software 的CIO（罗德）要求重新设计网络的QoS。

■ 即将部署24 个Cisco TelePresence 系统——每个主要的工程和销售部门办公室中安装一个，一些较大的站点安装多个——未来计划安装更多；此部署中还包括将所有的WAN/VPN链路进行相应的带宽升级。

■ 新兴的多媒体协作应用越来越普及，比如CiscoWebEx和Jabber，以及微软Lync。

■ 在工作时间，要识别出网络上“大量的”非业务流量，比如YouTube、BitTorrent、iTunes下载和游戏流量。

■ 对于整体QoS策略一致性的更高需求。Tifosi多年来收购了一些规模较小的公司，并发现在QoS模型上，这些小公司的部署方案与自己存在着显著的差异。

为此，罗德找到了公司的高级网络构架师汤姆来讨论这些顾虑。经过长时间的讨论，汤姆建议罗德为了提升QoS的一致性并满足新的业务需求，Tifosi应该升级QoS策略，并使其基于RFC 4597 的建议，这也是DiffServ（差分服务）QoS 设计事实上的工业标准。罗德原则上同意，但他对于实施和运行RFC中描述的12类模型的复杂性有更深的顾虑，他认为这与他们当前的4类模型来说“跨度”太大。此外，他指出他们的IP电话通讯构架基于Cisco CUCM（统一通信管理器），所有信令流量都被默认标记为CS3，而不是RFC中指定的CS5。汤姆同意给予这个问题更多的考虑和研究，再来跟罗德进行讨论。

12.4 8类QoS模型提议

在接下来的会议中，汤姆跟罗德分享了这样的的原则:由于RFC 4594是一个指导性RFC（而不是Internet标准），具体怎么应用由组织结构自己斟酌。基于此，汤姆建议Tifosi采用8类QoS 模型，这种模型可以在很大程度上基于RFC 4594。这样的8 类模型既将扩展，也将轻微修改他们现存的4类模型。罗德喜欢这个主意，在针对每个流量类进行了几轮详细讨论后，汤姆提出了以下的8类模型。

■ 语音:标记为EF，分配10% 的带宽，使用严格优先级队列，并执行EF PHB。

■ 实时交互:标记为CS4，分配23% 的带宽，使用严格优先级队列，并执行EF PHB。

■ 信令:标记为CS3，分配2%的保证带宽。

■ 多媒体会议:标记为AF41，执行AF PHB，分配10% 的保证带宽，启用基于DSCP的WRED。

■ 业务性数据:标记为AF21，执行AF PHB，分配25% 的保证带宽，启用基于DSCP的WRED。

■ 大块数据:标记为AF11，执行AF PHB，分配4% 的保证带宽，启用基于DSCP 的WRED。

■ 清道夫:标记为CS1，分配1%的带宽，使用带宽限制队列。

■ 尽力传输:标记为DF，分配25%的保证带宽，启用WRED。

汤姆对于每个类是这样考虑的。

■ 语音:随着TelePresence部署中带宽的增加，在保持相同语音呼叫量的前提下，分配给语音类的带宽百分比应该相应减少。

■ 实时交互:这个新的类别用来服务TelePresence 流量，通过执行EF PHB（根据RFC 4594的建议）来为这个高度丢弃敏感的应用提供最高等级的服务质量。此外，分配给语音和实时交互类的带宽总量，使实时流量保持在现有链路容量的1/3以下，这符合最佳方案设计的建议。

■ 信令:随着带宽的增加，在保持相同信令流量的前提下，分配给该类别的带宽百分比会相应减少；该类别中的流量将继续被标记为CS3（由于RFC 4594 并不是标准，所以可以按需修改）。

■ 多媒体会议:这个新的类别用来服务所有多媒体会议及协作应用，经分析这些应用的流量呈现出突发行为，因此为该类别部署WRED（加权随机早期检测）策略，将提供有效的拥塞避免机制。

■ 业务性数据:该类别（与大数据类一起）将代替公司自定义的“关键任务数据”类，并使其更加符合工业最佳做法的建议。此外，这也将优化网络，以适应“前台”数据应用。该类别的标记将从AF31变为AF21，使未来方便部署多媒体流媒体应用类。

■ 大块数据:该类别（与业务性数据一起）将代替“关键任务数据”类。具体地说，该类别将在拥塞期间，对“后台”数据应用进行一定程度的带宽限制。

■ 清道夫:该类别可用来在拥塞期间对非业务应用实施最大程度的带宽限制。在带宽拥塞时，非业务应用数据将被限制并大量丢弃，而不是完全被阻断（完全阻断可能不受用户欢迎）。其他时候，这些流量仍可以获得网络服务。此外，该类别还将服务所有不受管理的应用和设备（比如访客的自带设备），这些设备没有达到IT部门的安全和管理需求。最后，该类别还将服务访客VLAN（有线和无线）的流量。

■ 尽力而为:所有剩下的应用将会获得默认服务，默认服务的带宽总量将不少于任意给定带宽的1/4。

图12-2展示了汤姆提出的8类QoS队列模型。

图12-2 Tifosi Software案例研究:8类QoS建议及队列模型

在仔细考虑之后，罗德决定接受汤姆为Tifos软件提出的8类模型的建议。他们随后回顾了“关键任务数据”类中的所有应用，并根据每种流量的特征（主要考虑该应用是前台应用还是后台应用），将这些应用（主要）细分到业务性数据类和大数据类中。有一些应用（比如流媒体应用）被暂时分配到尽力而为类中，当发现它们需要占用较多的带宽时，再在未来将其分配到专用的应用类别中。

12.5 “第8层”挑战

就在罗德将概述这个新网络QoS模型的邮件发出之后不久，他就收到了不少火急火燎的反馈。

对于新QoS策略反对声音最强的人之一是人力资源部的经理卡特丽娜。在原始的QoS模型中，卡特丽娜“关键任务数据”类中的前三个应用如下:

■ 一个基于Oracle的企业资源规划（ERP）程序，用来管理所有HR记录和信息；

■ 员工培训视频点播（VoD）应用，用于培训公司政策和员工问题；

■ 电子邮件。

在新的QoS模型中:

■ Oracle ERP 应用将属于业务性数据类别；

■ 培训视频点播应用将属于尽力而为类别；

■ 电子邮件将属于大数据类别。

之所以这样变更，其背后的原因是罗德和汤姆了解到Oracle ERP 应用实质上就是业务性应用，它是前台应用（网络延迟会直接影响到用户的生产率），因此也是业务性数据类的首要候选应用。培训视频点播不适合放入业务性应用类中，但更合适放在未来规划的多媒体流媒体类中。然而，罗德希望追踪这类流的流量大小，并在其超过了特定的评分值时，将其分配到专用的类别中。同时，因为这些流媒体应用自带强大的应用级缓存功能，他觉得此时没必要为其进行单独的规划。最后，罗德和汤姆都认为电子邮件虽然对业务很重要，但更符合大数据应用（而不是业务性数据应用）的特征，因为在用户继续工作期间，可以在后台收发电子邮件，因此电子邮件所遭遇的网络延迟并不会直接影响用户的生产率。

罗德当面并几次通过邮件跟卡特丽娜解释了这些原因。尽管如此，卡特丽娜始终不为所动，并认为新的QoS策略不仅是独断的，也是不公平的，它们最终会妨碍她的部门的工作效率。她随后找到了罗德的上司，并向Tifos软件的CEO罗拉提出了这一问题。

罗拉很快召集了罗德、卡特丽娜和其他几个对新策略有异议的部门领导开会敲定此事。在听取了部门主管们的意见后，她向罗德仔细询问了新的QoS策略。罗德坚持了变更的原则并补充说，QoS天生就是不公平的，所以也几乎不可避免地会在组织和政治层面引发争议，他开玩笑地提到了“OSI网络模型的第8层”。他的玩笑没有得到回应，因为在房间里（或电话上）的人即使连OSI模型都没有听说过。尽管如此，罗拉支持了罗德的决定，并授权他部署新的QoS模型。

会后，回顾了之前的事情，罗德决定为了顺利开展工作，他需要事先与行政人员一起讨论网络QoS策略的变更，并透彻地解释这些新策略将怎样推进战略性业务需求并使公司受益。希望这样做能够在将来规避潜在的冲突。

注释:图12-2所示的8类模型将用于以下所有的案例研究。

12.6 小结

本章介绍了本书所有案例研究章节所使用的虚拟公司:Tifosi Software。

Tifosi Software原来使用4类QoS模型:语音、信令、关键任务数据和尽力而为应用。组成“关键任务数据”类的应用大都是主观决定的，并没有对流量进行流量模式和服务等级需求的客观分析。

大量的业务发展——包括部署Cisco TelePresence系统、多媒体协作和会议应用的日益普及，以及生产网中出现大量的非业务流量——导致公司重新评估当前的QoS策略，并考虑如何对其加以改进和扩展，以满足这些不断变化的业务需求。

本章使用一个8类的QoS策略来适应这些需求，并解释了添加和修改每个类别的理由。

之后，本章演示了一场政治风波事例（这在QoS部署中非常普遍，毕竟QoS是一种天生就不公平的技术）。如本章所示，解决这些政治挑战的关键是对整体策略进行大量的思考，对于应用及应用类进行客观的（而不是主观的）判决，并尽可能在部署前得到部门经理的支持。

12.7 扩展阅读

媒体网QoS设计策略一览:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/qosmrn.pdf

企业媒体网服务质量设计4.0概览:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSIntro_40.html

IETF RFC 4594，差分服务类别配置指南:http://www.ietf.org/rfc/rfc4594

第3部分 园区网QoS设计

第13章 园区网QoS设计的注意事项与建议

QoS在富媒体园区网中的首要作用并不像在WAN（广域网）或VPN（虚拟专用网络）中那样需要控制延迟或抖动，而是管理丢包。在当今的园区网络中，终端设备以吉比特（GE）的速率连接网络，几毫秒的拥塞就会造成瞬时的缓存溢出，并导致在网络边界或10GE/40GE核心网中出现的丢包。

以（在本书写作时）缓存最大的线卡之一:Cisco Catalyst 6900 系列40 GE 接口模块（WS-X6904-40G-2T）为例。这个线卡提供176MB缓存，每一对端口共享这些缓存。假设管理员配置每个端口使用全部8个出向硬件队列，并为这些队列均匀分配缓存，这样每条端口队列会拥有11MB 缓存（176 MB / 2 端口/ 8 队列）。以40Gbit/s 的速率计算，只需2.2 毫秒的线路速率突发，这些队列就能被占满（11 MB * 8比特/ 40 Gbit/s），而此时也就会开始丢包。如前所述，富媒体应用——尤其是HD（高清）视频应用——会受到严重影响，因为它们对丢包极度敏感，就算10000个包中丢弃1个，终端用户也能分辨出来。

QoS在园区网中经常扮演的次要角色是区分和管理应用流量，尤其在接入边界。

战略性的QoS设计原则已经在第11章中讨论了，应用于园区网的QoS设计原则如下。

■ 优先选择在硬件上实施QoS，别无他选时再实施软件QoS:Cisco Catalyst 交换机在专用的ASIC（专用集成电路）上执行QoS，因此在管理QoS策略时不会占用主CPU的资源。可以在这些平台上以GE/10GE的线路速率应用且高效地执行复杂的QoS策略。

■ 在技术条件和管理条件均可行的条件下，在尽可能靠近源的位置对应用进行分类和标记:该原则提升了端到端DiffServ（差分服务）和PHB（逐跳行为）。有时可以信任终端设备上设置的CoS（服务类别）或DSCP（差分服务代码点）标记，但不推荐这样做，因为允许用户自行标记流量的话，他们可以非常轻松地（有意或无意地）滥用现有的QoS 策略。举例来说，如果DSCP EF（快速转发）表示在企业网中获得优先级服务，那么用户可以轻易地配置PC 的NIC（网卡），使其将所有流量标记为DSCP EF，这样一来，用户就劫持了网络优先级队列来处理他的非实时流量。这样的滥用行为能够轻易地毁掉企业网中实时应用（如VoIP）的服务质量。

■ 在尽量靠近源的地方对不需要的流量进行限速:若转发无用的流量只是为了在下游节点对其实施限速或丢弃，这种转发行为是毫无意义的。当无用流量是由DoS（拒绝服务）或蠕虫攻击引发时，尤其如此。

■ 为了防止发生拥塞，在每个节点都启用队列策略，无论该节点发生拥塞的可能性有多小:这一原则同时适用于园区网边界和园区网内部的交换链路，因为超额预定会导致潜在的瞬时拥塞。由于园区网的速率通常为GE/10GE，大部分交换机平台在队列排满并开始丢包前（最多）只能提供几十毫秒的缓存。因此，在所有可能发生拥塞的节点上开启队列策略，是保证园区网服务水平并防止实时流量类丢包的唯一方法。

■（可选）启用控制层面限速来保护控制层面和数据层面:这样做加固了园区网基础设施，在园区网交换机上实施的数据层面限速（针对清道夫类QoS）可缓解并限制网络攻击。

然而，在将这些战略性QoS设计原则转化为特定平台的配置建议之前，应该考虑以下与园区网相关的注意事项:

■ MLS（多层交换）与MQC（模块化QoS CLI）；

■ 默认QoS；

■ 内部DSCP；

■ 信任状态和工作原理；

■ DSCP透传；

■ 信任边界；

■ 基于端口的QoS、基于VLAN 的QoS 和每端口/ 每VLAN QoS；

■ EtherChannel QoS；

■ 园区网QoS模型；

■ 园区网端口QoS角色；

■ 园区网AutoQoS；

■ CoPP（控制层面限速）。

接下来将依次讨论以上的每条注意事项。

13.1 MLS与MQC

设计建议:

■ 如果交换机同时支持MQC 和MLS，选择使用Cisco IOS 软件的MQC；这将提升跨平台的QoS一致性。

Cisco Catalyst 交换机（在本书写作时）使用以下两类配置语法之一:

■ MLS；

■ MQC。

MLS QoS 是两类语法中较早的版本，命令通常以mls 开始。例如，要在基于MLS QoS 的交换机上全局启用QoS，命令（通常）是mls qos。

MQC 是由class map、policy map 和service policy 构成的IOS QoS 语法结构。

注释:MLS QoS 使用class map 和policy map 来实施分类和限速策略，但不用它们执行队列策略，而MQC使用class map和policy map来实施几乎所有的QoS功能。

为了提升跨平台QoS的一致性，MQC从基于IOS的路由器移植到了Catalyst交换机。最早支持MQC 的交换机版本是Catalyst 4500E-Supervisor 6-E 的Cisco IOS 12.2(40)SG 版本。

注释:Catalyst 4900M、Catalyst 4948E和Supervisor Engine 6L-E也支持Cisco IOS 12.2(40)SG版本。

作为移植过程的一部分，需要添加或改写许多与交换机相关的命令和命令集。例如，IOS路由器的MQC中并没有条件信任的概念（详见本章后文内容），因此需要在交换机的MQC中添加这一新的概念。

在接下来的设计章节中，接入层Catalyst 3750-X QoS 设计使用MLS QoS，分布层Catalyst 4500E – Sup7E 和核心层Catalyst 6500 – Sup2T QoS 设计使用MQC。

这两类语法的最大区别在于队列配置；尽管如此，MLS QoS 和MQC 之间（在语法和功能方面）也有一些微小的差别，这将在必要时提到。

13.2 默认QoS

设计建议:

■ 若在基于MLS QoS 的交换机上配置QoS，首先需要全局启用QoS。

MLS QoS 和MQC 的一个功能性区别就是默认的QoS 状态和行为。

默认情况下，MLS QoS 是关闭的，这意味着交换机上所有与MLS 相关的QoS 功能也被禁用了。例如，如果一个携带第2层或第3层标记的数据包进入了交换机，那么在它离开交换机时，它的第2层或第3层标记将被保留。除此此外，所有的数据包都会被分配到默认队列中，并按照FIFO（先进先出）的逻辑进行处理。再者，虽然配置的所有命令（比如信任、分类、限速或队列命令）都会显示在配置中，但在手动输入全局命令mls qos 之前，所有这些命令全部都不会被激活。

注释:一旦在使用MLS QoS的交换机上全局启用了QoS，所有的端口都将被设置为不可信状态，这意味着在没有明确的信任配置的情况下，所有数据包的DSCP字段都将被重标记为0。

相反，在使用MQC时，QoS默认是启用的，因此没有启用QoS的全局命令（因为并不需要）。然而，默认的数据包处理行为与MLS相似:默认保留数据包的第2层和第3层标记，默认以FIFO 的逻辑处理所有数据包。只有当你通过class map 和policy map 配置了一条策略，并将其通过service policy 与一个接口绑定后，默认的QoS 行为才会发生改变。

13.3 内部DSCP

设计建议:

■ 理解内部DSCP的概念，以及它会如何影响基于MLS的QoS设计。

MLS QoS 交换机在“内部DSCP 值”概念的基础上实施QoS 操作，这个值与每个数据包相关联。

注释:本章将使用术语“数据包”来描述三层数据包和二层数据帧。

MLS QoS交换机使用内部DSCP（有时也被称为QoS 标签，但不要跟MPLS［多协议标签交换］的标签混淆）来确定一个数据包是将被重标记、限速、分配到哪个队列，还是应该被丢弃。内部DSCP值可能（也可能不）与IP数据包（IPv4或IPv6）实际的DSCP值相同。而且，甚至也可以为非IP协议生成内部DSCP值，比如生成树协议等第2层协议，以及IPX等第3层协议。

设备为一个数据包生成DSCP值的方式取决于接收到该数据包的端口的信任状态，这将随后说明。

13.4 信任状态与工作原理

设计建议:

■ 理解各种静态的和动态的信任状态的工作原理和含义。

一个交换机端口可以配置为以下三个（静态的）信任状态。

注释:从技术上说，如果信任IP优先级也算的话，一共有4个静态的信任状态。然而，此选项早就被信任DSCP替代了，所以本章不会讨论IP优先级。

■ 不可信:处在此信任状态的端口将无视数据包可能携带的所有第2层或第3层标记，并为数据包产生一个为0的内部DSCP值（除非明确设置其他值）。这是在全局启用mls qos 后，默认的端口QoS 信任状态。不过也可以使用接口配置命令no mls qos trust，明确地将端口设置为不可信状态。

注释:在大部分使用MLS QoS的Cisco交换机上，有关QoS的命令都包含mls前缀。但使用MLS QoS的Catalyst 4500/4900交换机（即Supervisor II+和SupV-10GE系列交换机）是个例外，这些交换机省略了mls前缀。然而，因为4500/4900系列交换机超出了本书的范围（本书关注较新的4500E Supervisor 6-E/7-E系列交换机），因此在本书的实例命令中将包含mls前缀。

■ 信任CoS:处在此信任状态的端口会接受802.1Q 数据包中的802.1p CoS标记，并结合CoS到DSCP映射表，用数据包携带的标记值来计算数据包的内部DSCP值。默认的CoS到DSCP映射表是将每个CoS 值乘以8，来计算默认的内部DSCP值（比如将CoS 1映射为DSCP 8，CoS 2映射为DSCP 16，诸如此类）。然而，可以通过全局配置命令mls qos map cos-dscp 来修改默认的CoS到DSCP 映射表（比如将CoS 5 映射为非默认的DSCP值EF46）。对于无标签的数据包（如通过Native VLAN收到的数据包），将对其应用默认的内部DSCP值0。你可以通过接口配置命令mls qos trust cos启用这个端口信任状态。

■ 信任DSCP:处在此信任状态的端口会接受数据包的DSCP标记，并将内部DSCP值设置为相同的值。对于非IP数据包（如IPX数据包），将对其应用默认的内部DSCP值0。可以通过接口配置命令mls qos trust dscp 启用这个端口信任状态。

图13-1说明了不可信、信任CoS和信任DSCP状态的工作原理。

图13-1 静态的信任状态及工作原理

除了上述4 个静态的信任状态之外，Cisco Catalyst 交换机还支持动态的信任状态，即在成功交换终端身份识别后，根据管理员配置的终端信任策略，动态地切换端口的信任状态。这个特性被称作条件信任和用户/终端设备移动性自动化。目前，条件信任通过CDP（Cisco发现协议）实现设备认证，因此只有Cisco终端设备支持该特性。

注释:CDP是用来实现实现邻居发现的轻量级私有协议，不能把它当作安全认证协议来使用。不应该将CDP视为或依赖为安全的协议，因为相对轻松地就可以欺骗过它。

图13-2说明了条件信任的工作原理。

图13-2 条件信任的工作原理

图13-2中事件的发生的顺序如下所示。

1.Cisco Catalyst接入层交换机和Cisco IP电话交换CDP信息；在成功交换后，交换机认出这台终端设备是IP电话，根据交换机端口上配置的策略，交换机将信任扩展到IP电话。

2.电话将VoIP 流量设置为CoS 5，将呼叫信令流量设置为CoS 3。

3.Cisco IP 电话将来自PC 端口的流量重标记为CoS 0。

4.交换机信任来自电话的CoS 值，并将CoS 映射为DSCP，从而为所有入站数据包生成内部DSCP值。

Cisco终端设备通过如下方式支持条件信任。

■ 对于Cisco IP 电话，使用接口命令mls qos trust device cisco-phone。

■ 对于Cisco 网真系统，使用接口命令mls qos trust device cts。

■ 对于Cisco IP 视频监控摄像头，使用接口命令mls qos trust device ip-camera。

■ 对于Cisco 数字媒体播放器，使用接口命令mls qos trust device media-player。

13.5 信任边界

设计建议:

清晰地描述园区网中的信任边界，并将终端设备分为以下3类:

■ 不可信；

■ 可信；

■ 条件信任。

学习了内部DSCP的概念和信任状态的工作原理后，需要考虑的是应该在何处设置信任边界（也就是区分是否接受数据包标记的网络边缘）。

与本章开始提到的战略性QoS分类原则一致，在技术条件和管理条件均可行的条件下，应该将信任边界设置在尽可能靠近源的位置。

之所以在设计建议中设置管理条件可行的前提，是因为很多终端设备（包括用户PC）在技术上能够在其NIC上对流量实施标记，但要是信任了这种标记，很容易造成网络滥用，因为用户可以将所有流量都标记为EF（快速转发），这样做能够劫持网络优先级队列，来为用户的非实时流量提供服务，这也就损害了企业中实时应用的服务质量。

因此，多年来一直倡导不要信任来自用户PC的流量。然而近些年发布了一些安全终端软件，使网络管理员能够集中管理并强制设置PC的标记。有了这种集中管理软件——同时将未安装此类软件的PC放入隔离的VLAN中——使网络管理员能够信任这种安全的终端PC。

从信任的角度出发，终端设备主要分为以下3类:

■ 条件信任的终端设备:包括Cisco IP 电话、Cisco TelePresence 系统、Cisco IP 视频监控摄像头和Cisco数字媒体播放器。

■ 可信的终端设备:包括集中管理的PC和服务器、IP视频会议单元、受管理的无线接入点、网关和其他类似的设备；

■ 不可信的终端设备:不安全的PC、打印机和其他类似的设备。

图13-3给出了信任边界的案例，以及为各类终端设备设置的配置命令。

图13-3 园区网信任边界

13.6 DSCP透传

设计建议:

■ 了解DSCP透传特性；该特性可以满足特定的设计需求。

先不管内部DSCP是如何生成的，现在要强调的是当IP数据包离开Catalyst交换机时（除非明确重标记，这将在后文中进行讨论），交换机会将这个数据包的DSCP值设置为最终计算出的内部DSCP值。如果出站交换机端口启用了Trunk，那么交换机也会相应地设置数据包的CoS值（但只会使用最终计算出的内部DSCP值的前3比特，因为与6比特的DSCP值相比， CoS值只有3比特）。

如果不希望用内部DSCP重标记数据包的入站DSCP值，可以使用DSCP透传特性，该特性可通过全局配置命令no mls qos rewrite ip dscp 启用。当启用了DSCP 透传特性后，无论交换机对数据包执行了何种内部QoS操作，数据包出站时携带的DSCP值总是与其入站时携带的值相同。

13.7 基于端口的QoS、基于VLAN的QoS与每端口/每VLAN QoS

设计建议:

■ 当简单性和模块化是关键的设计原则时，使用基于端口的QoS；

■ 希望在不增加配置长度的前提下扩展策略（比如分类、信任和标记策略）时，使用基于VLAN的QoS；

■ 不使用基于VLAN的QoS扩展（合并）限速策略；

■ 当策略粒度是关键的设计原则时，在设备支持的情况下使用每端口/ 每VLAN QoS。

管理员可以使用以下三种方式，在Cisco Catalyst 交换机上应用QoS 分类（包括信任）、标记和限速策略。

■ 基于端口的QoS:当基于每个端口应用QoS策略时，策略是附加在特定的物理交换机端口上的，并且该端口（且仅限该端口）收到的所有流量都应用该策略。QoS默认是基于每端口应用的。图13-4显示了基于端口的QoS。

■ 基于VLAN的QoS:当基于每个VLAN应用QoS策略时，策略是附加在逻辑VLAN接口上的，并且属于该VLAN的所有接口接收到的流量都应用该策略。在使用MLSQoS 的交换机上，应用基于每VLAN 的QoS 策略，需要使用接口命令mls qos vlan-based。在使用MQC QoS 的交换机上，只要在VLAN 接口（而不是物理接口）上应用service policy 就可以了。图13-5 显示了基于VLAN 的QoS。

图13-4 基于端口的QoS

图13-5 每VLAN QoS

■ 每端口/ 每VLAN QoS:当基于每端口/ 每VLAN 应用QoS 策略时，策略是附加在Trunk端口上的特定VLAN上的，并且该Trunk端口上的这个特定VLAN（且仅限这个VLAN）收到的所有流量都应用该策略。不是所有平台都支持每端口/每VLAN QoS，配置命令也因平台而异。图13-6显示了为语音和数据VLAN启用每端口/每VLAN QoS（可以为Trunk 端口上承载的任意VLAN 启用该特性）。

图13-6 每端口/每VLAN QoS

使用基于端口或基于VLAN的QoS策略，可以使策略部署更具效率和粒度。比如使用基于每VLAN的QoS策略时，可使标记策略更易于扩展。然而，对限速的粒度有要求的策略最好使用每端口/每VLAN的QoS策略。尤其是当管理员想要针对VoIP流量进行限速时，比如将每个IP电话的VoIP流量限速为128kbit/s；实现这一限速需求的最佳做法是在具体的物理端口上，为语音VLAN应用每端口/每VLAN限速策略。基于每端口的限速器对于本例来说并不足够，除非部署了额外的分类标准，能够只对来自IP电话的流量进行识别；本例也不能使用基于每VLAN的策略，因为这将把属于语音VLAN的所有端口的总流量限速到128kbit/s。

13.8 EtherChannel QoS

设计建议:

■ 理解在为EtherCannel捆绑链路应用QoS策略时，与平台相关的要求有哪些——尤其是，哪些策略元素（如果有的话）要应用在逻辑的Port-Channel接口上，哪些策略元素要应用在物理的成员接口上。

在QoS设计中，另一个逻辑接口与物理接口相关的情景是在EtherChannel接口上部署QoS。多个1Gbit/s或10Gbit/s以太网端口可以在逻辑上捆绑为单一的EtherChannel接口（也被称为Port Channel 接口，因为这是配置语法中的命名）。从第2 层或第3 层的立场上看，这些捆绑在一起的接口代表（且在功能上表现为）一个单一的接口。

在EtherChannel接口上部署QoS策略时应牢记以下两个重要的注意事项。

■ 第一个EtherChannel QoS设计注意事项与负载分担相关。根据不同的平台，在为Port Channel组配置负载分担时会有多种方式:根据源IP地址、根据目的IP地址、根据源MAC地址、根据目标MAC地址、根据源和目的IP地址，或者根据源和目的MAC地址。要注意EtherChannel技术并不考虑每个流的带宽。相反它通过使用统计概率，为众多数据流分配相对平等的带宽，并在Port Channel组中的所有链路上平等地分布流量负载。但情况也并不总是这样。通常建议基于源和目的IP地址进行负载分担，因为这样做可以实现统计学上的负载分担。当通过这种方式进行负载分担时，单个数据流中的数据包能够保持原本的数据包顺序。

■ 第二个EtherChannelQoS设计注意事项是:EtherChannel并不考虑单条吉比特以太网链路上的QoS配置。再次强调，它通过使用统计概率，为众多数据流分配不同的QoS标记，并在Port Channel组中的所有链路上平等地分布这些流量负载。当EtherChannel组中的一条链路发生故障时，这条链路上的会话将会被重新分配到EtherChannel组中的其他链路上。由于EtherChannel技术并不感知QoS标记，因此它可能会将更多的（超出配置上限的）实时流量重新分配到任意一条链路上；这样做可能会降低实时服务的质量。顺便一提，在没有发生链路故障的环境中也可能发生上述情况。因此，在选择使用EtherChannel技术，还是选择使用单个高速上行链路端口时，要谨慎地做出决定。

此外还要注意，在有些平台上（比如Catalyst 4500 和6500），入向QoS 策略必须应用在逻辑Port Channel 接口上；但在其他平台上，入向QoS 策略必须应用在物理的端口成员（Port Member）接口上。出向策略（通常是队列策略）总是应用在物理的端口成员接口上。表13-1总结了这些EtherChannelQoS设计。

表13-1 各平台EtherChannel逻辑与物理QoS策略要求

因为每个平台的EtherChannel QoS 配置都有细微的区别，因此设计案例中将包含各种交换机平台家族。

13.9 园区网QoS模型

设计建议:

■ 遵循部署园区网QoS的4个步骤。

通常来说，在园区网中部署QoS需要以下4个主要步骤。

1.全局启用QoS（只需在使用MLS QoS 的交换机上启用）。

2.应用入向QoS模型。

a.配置信任，或者明确配置分类、标记和限速策略。

b.配置入向队列（如果设备支持且设计需要的话）。

3.应用出向QoS模型，将数据流分配到传输队列并启用丢弃策略。

4.（可选）启用控制层面限速（在支持此特性的平台上）。

13.9.1 入向QoS模型

设计建议:

■ 在所有接入边界的端口上部署入向QoS模型，比如信任、分类和标记/限速；

■ 部署入向队列（如果设备支持且设计需要的话）。

入向QoS模型会为交换机端口（或VLAN接口，比如在基于VLAN的QoS设计中）应用某个端口信任状态，或者应用明确的分类和标记策略。入向QoS模型可能也包含可选的入向限速器或入向队列（如果设备支持且设计需要的话）配置。

在设计入向QoS模型时，不光要考虑端到端的战略性QoS模型（比如第11章中介绍的4类、8类和12类模型），还需要考虑当前园区网的接入边界上（入方向上）有哪些应用类。另一个需要注意的是这些应用类的源是可信终端设备还是不可信终端设备。

注意不是所有端到端战略性QoS模型中的应用类，都会在园区网接入问边界（入方向上）出现。因此，并不需要在这个节点上对所有的应用类进行分类、标记或限速。举例来说，永远也不应该收到从终端设备发来的网络控制流量，因此园区网接入边界并不需要这个应用类。对于操作、管理和维护流量（OAM，Operation, Administration and Management）来说，情况也类似，因为这些流量主要由网络设备产生，并由位于数据中心或网络控制中心（通常不在园区网中）的管理工作站收集。另外，多媒体流媒体流量可能会由数据中心的服务器产生，并单向发往园区网中的终端设备（且不应由终端设备发出）。因此，不太需要在园区网接入边界部署这些应用类。

除此之外，你必须考虑应用流量是源于可信的终端设备，还是源于不可信的终端设备。举例来说，语音流量主要源于语音VLAN（VVLAN）中的Cisco IP电话，因此可以被信任（可选:通过启用条件信任策略，来方便提升用户移动性）。然而，语音流量也可能源于PC上的软电话应用，比如Cisco Jabber。因为这种应用与多媒体会议流量使用相同的UDP 端口号范围（UDP/RTP端口16384～32767），从园区网接入边界分类的角度上看，几乎无法区分软电话VoIP流和多媒体会议流。除非能够绝对地将软电话的VoIP数据包从多媒体会议流中区分出来，否则将UDP端口号范围16384～32767标记为多媒体会议流（AF4）将会更简单且更安全。另一种方式是允许多媒体会议流（标记为AF4）进入严格优先级队列，这可能会增加准入控制的复杂性。

当一个应用类中的流量源自多个VLAN时，可能无法精确地识别流量，这时就需要使用多个class map，来正确地识别数据流。以信令流量为例，这类流量可能源自VVLAN，也可能源自动态VLAN（DVLAN；与软电话应用的情况相同）。使用一个class map 来识别源自VVLAN 的语音数据包，也就是匹配CoS 3。使用另一个class map 来识别源自DVLAN 的信令流量，可能需要匹配TCP/UDP端口或端口范围。

除了要配置明确的标记策略外，在园区网接入边界的入方向上还可以（可选）实施限速策略，来测量和管理数据流。举例来说，可以将语音流限速至128kbit/s，将源于VVLAN的其他流量（大部分是信令流量，极少数是管理流量）限速至32kbit/s。这两个VVLAN限速器都可以配置丢弃违反限制的流量，因为VoIP和信令流量的定义和行为已经被很好地限定了，因此超出定义速率的流量突发可能预示着网络违规行为或网络滥用行为。

数据层面限速策略（如第11章所述）可以用来监控业务性数据、大数据和尽力而为流量，限速策略可以测量这些流量，并使用特定的AF类来重新标记违反限制的流量，这个新的标记具有更高的丢弃优先级（比如AF12、AF22、AF32或AF42；甚至在使用双速限速器的情况下，标记AF13、AF23、AF33或AF43）。非AF类的流量可能会被限速器重标记为清道夫/CS1。重要的是这些数据包不会在入方向上被丢弃。例如，这些类中的每一个都可以被限速并重标记到10Mbit/s。

注释:数据层面限速速率（10Mbit/s）是一个示例值。在企业到企业之间，甚至是企业内的部门到部门之间这个值都可能不同。设置数据层面限速速率的关键是:保证该应用类中大约95%的流量处于测量速率之下。为了简便，在本书案例中，为这些应用类使用10Mbit/s的数据层面限速速率。

在为所有端口设置了信任设置，或者分类并标记（以及可选的限速）流量后，就可以应用入向队列策略了（在需要且支持该特性的平台上）。入向队列的细节将在随后相关特定平台的设计章节中讨论。图13-7显示了一般的园区网入向模型。

图13-7 园区网入向QoS模型

13.9.2 出向QoS模型

设计建议:

■ 在所有交换机端口上应用出向队列策略；

■ 使用最小的1P3QyT队列结构。

Cisco Catalyst交换机使用基于硬件的队列，因此，特定端口上的队列数量是固定的。每条（非优先级）队列可以设置多个丢弃门限值。因此，Catalyst的硬件队列模型通常使用1PxQyT命名法表示，其中:

■ 1P代表一条严格优先级队列；

■ xQ代表x条非优先级队列；

■ yT代表每条非优先级队列中有y个丢弃门限值。

如在第11章中讨论的，在为富媒体应用部署QoS时，至少应该在所有平台上支持下列基于标准的队列行为:

■ 实时队列（为了支持RFC 3246 定义的EF PHB 服务）；

■ 保证带宽队列（为了支持RFC 2597 定义的AF PHB 服务）；

■ 默认队列（为了支持RFC 2474 定义的DF 服务）；

■ 带宽限制队列（为了支持RFC 3662 定义的清道夫服务）。

这些基于标准的需求在Catalyst平台上将转化为最小硬件队列结构——1P3Qy；但目前多数Cisco Catalyst 交换机都支持每端口多于4 条基于硬件的队列。

注释:另外，也应该应用第11章中提到的带宽分配和丢包建议。

显然，如果设备能够支持更多的队列，管理员就应该使用这些队列，来为相应的应用类提供更细粒度的带宽保证。尽管如此，通常在应用类的层级结构中，实时应用（如语音、广播视频和实时交互流量）被分到严格优先级队中，然后是控制层面协议（包括网络/网络互联控制、信令[语音/视频基础设施的控制层面流量]和网络管理流量），接着是保证带宽、非实时应用（包括多媒体会议、多媒体流媒体和业务性数据），再接着是默认尽力而为流量，最后是大数据和清道夫应用。维护这样的应用类层级结构会确保一致的逐跳行为（PHB）。

一些平台提供DSCP 到队列的映射功能，而其他的（比如Catalyst 6500 的一些线卡）只限于使用CoS到队列的映射功能。在这两种情况中，都是由内部的DSCP值来决定将数据包分配到哪条传输队列中。不过在CoS到队列的映射中，内部DSCP值是以8个值为单位分配到队列中的。举例来说，如果将CoS 1 映射到队列1（Q1），那么内部DSCP 值8 ～15 会被分配到Q1；如果将CoS 2 映射到队列2（Q2），那么内部DSCP 值16 ～23 会被分配到Q2；如果将CoS 3 映射到队列3（Q3），那么内部DSCP 值24 ～31 会被分配到Q3（以此类推）。基本上在CoS到队列的映射中，设备会将CoS值*8，并将与这个值对应的内部DSCP值及其后续的7个值，一起分配到某条队列中。

最后，有些平台不光可以调整带宽分配，也可以调整缓存分配。每队列的缓存分配可以与每队列的带宽分配成正比（比如可以将尽力而为队列的缓存分配设置为25%，这与该队列的带宽分配百分比相同），也可以成反比（比如为实时流量服务的严格优先级队列，它不太可能需要与带宽百分比相同的33%缓存分配；而带宽限制队列却可以通过更深的缓存，来抵消其最小带宽分配的劣势）。调整缓存分配与单独调整带宽分配相比影响较小，但可被用来作为调度机制策略的补充。因此，在随后的设计章节中，严格优先级和低于尽力而为队列的缓存分配（只要有可能）会被调整为与带宽分配成反比，而其他的非优先级队列则被调整为与带宽分配成正比。

因为Catalyst队列模型因硬件而异，并没有通用的模型，所以4类、8类和12类队列模型将在后续设计章节以每个平台为基础进行介绍。

13.10 园区网端口QoS角色

设计建议:

为所有类型的交换端口定义一致的入向和出向QoS策略，其中包括连接以下设备的端口:

■ 不可信终端设备；

■ 可信终端设备；

■ 条件信任终端设备；

■ 网络基础设施组成部分。

根据园区网架构中的不同交换机端口（接口）类型，上述讨论过的QoS策略元素可以分为以下角色:

■ 连接不可信终端设备的交换机端口

■ 这类终端设备包括（非安全/不受管理的）PC、打印机或其他设备；

■ 应该在这些端口上禁用信任；

■ 可能会在这些端口上配置可选的入向标记或限速策略（比如数据层面限速策略）；

■ 可能会在这些端口上配置入向队列策略（如果设备支持，且在超额预订环境中需要的话，如交换机堆叠）；

■ 应该在这些端口上配置（至少）支持1P3QyT队列的出向队列策略，最好使用DSCP到队列的映射。

■ 连接可信终端设备的交换机端口

■ 这类终端设备包括安全/集中管理的PC和服务器、IPVS（IP视频监控）单元、IP会议站、模拟和视频会议网关，以及类似的其他设备；

■ 应该在这些端口上配置静态的信任策略，最好使用DSCP信任，以便获得最细粒度的分类和标记；

■ 可能会在这些端口上配置可选的入向标记和限速策略（比如数据层面限速策略）；

■ 可能会在这些端口上配置入向队列策略（如果设备支持，且在超额预订环境中需要的话，如交换机堆叠）；

■ 应该在这些端口上配置（至少）支持1P3QyT队列的出向队列策略，最好使用DSCP到队列的映射。

■ 连接条件信任终端设备的交换机端口

■ 这类终端设备包括Cisco IP 电话、Cisco TelePresence 系统、Cisco IP 视频监控摄像头和Cisco 数字媒体播放器；

■ 应该在这些端口上配置条件信任策略，最好使用DSCP信任，以便获得最细粒度的分类和标记；

■ 可能会在这些端口上配置可选的入向标记和限速策略（比如数据层面限速策略）；

■ 可能会在这些端口上配置入向队列策略（如果设备支持，且在超额预订环境中需要的话，如交换机堆叠）；

■ 应该在这些端口上配置（至少）支持1P3QyT队列的出向队列策略，最好使用DSCP到队列的映射。

■ 连接网络基础设施的交换机端口

■ 比如无线访问点、接入层/分布层的上行链路/下行链路、分布层/核心层的上行链路/下行链路、核心层链路、园区网到WAN/VPN边界的链路；

■ 应该在这些端口上配置静态信任策略，最好使用DSCP信任，以便获得最细粒度的分类和标记；

■ 可能会在这些端口上配置可选的入向标记和限速策略（比如数据层面限速策略）；

■ 应该在这些端口上配置（至少）支持1P3QyT队列的出站队列策略，最好使用DSCP到队列的映射。然而，为了在汇聚层上增强队列策略的粒度，建议在分布层和核心层使用支持1P7QyT队列的交换机平台和线卡。

图13-8说明了这些园区网的端口角色。

图13-8 园区网端口QoS角色

13.11 园区网AutoQoS

设计建议:

■ 理解AutoQoS特性的优势和限制；

■ 当考虑使用AutoQoS特性时，要记住你能够将其作为可修改和调整的设计模板。

由于一些QoS策略的复杂性，再加上通常Catalyst交换机上拥有大量端口，QoS部署经常变得繁重。一个选择是通过使用interface-range配置命令一次性在多个端口上部署策略。另一个选择是在适用的情况下使用AutoQoS。

为响应用户简化QoS部署的要求，Cisco开发了AutoQoS特性。AutoQoS是一项宏应用，允许用户输入一条或两条简单的AutoQoS命令，来对一个（或更多）应用启用所有推荐的QoS设置。在首个发布版本——AutoQoS-VoIP中，AutoQoS预设了用于指定交换机端口/接口的所有推荐的IP电话部署QoS设置。

Catalyst交换机的AutoQoS-VoIP特性支持三种操作模式，以下关键字配置在接口配置命令auto qos voip 之后。

■ cisco-phone:此模式可用于连接PC 或Cisco IP 电话的交换机端口，该命令将端口设置成条件信任状态，并为VoIP QoS 配置映射和队列策略。

■ cisco-softphone:此模式可用于连接PC 的交换机端口，且PC 上运行了Cisco IP Communicator或类似的软电话软件，该命令会为VoIP和信令流量配置限速策略，并为VoIPQoS配置映射和队列策略。

■ trust:此模式可用于在信任边界内的交换机端口（如内部交换链路，包括上行链路和下行链路），或用于连接可信终端设备的交换机端口，该命令将端口设置为静态的trust-dscp 状态，并为VoIP QoS 配置映射和队列策略。

注释:更多有关AutoQoS-VoIP以及特定平台的命令及其生成的配置，请参阅每平台各自的AutoQoS-VoIP文档（参见每个设计章节最后的特定平台的链接）。

一些读者自然会问，既然有了AutoQoS，我为什么还要读这些冗长又复杂的QoS设计章节？

首先，要知道对于（只）想为VoIP启用QoS、有基本的QoS需求、没时间或不想在QoS上进行太多工作的顾客来说，AutoQoS是一个绝佳的工具。

了解AutoQoS 的开发过程很重要。AutoQoS 特性是Cisco QoS 特性发展与（基于大规模实验室测试的）Cisco QoS 设计指导的结晶。AutoQoS-VoIP 是第一部QoS解决方案参考网络设计（SRND）指南（出版于1999年）的产品，从那时起AutoQoS-VoIP特性就没有较大的更新。因此，如果业务QoS需求中只涉及IP电话通讯，AutoQoS是加快QoS部署的绝佳工具。

然而2010年8月，更新的AutoQoS版本在Catalyst2960-G/S、2975-GS、3560-G/E/X和3750-G/E/X交换机家族上（IOS12.2(55)SE发布版本）发布了。这个版本直接基于最新的企业QoSSRND（4.0版本）中的建议，可支持富媒体应用。而且这个AutoQoS版本的全局配置命令是auto qos srnd4。在线附件A中讨论了最新AutoQoS的功能及选项，并讨论了其自动生成的QoS配置细节。

当考虑使用AutoQoS时，要注意并不需要把它当做是全有或绝无的工具。其实可以把AutoQoS当做是初始模板，可以根据需求对其进行修改，同时加速部署并减少潜在的人为错误（配置命令输入中的手误）。

关于AutoQoS 最后需要注意的是，同样可通过Auto SmartPorts 来部署这些策略。Auto SmartPorts 是一项宏应用，可以根据（通过CDP 或LLDP 发现的）设备类型，包括Cisco IP 电话、数字媒体播放器、IP视频监控摄像头、接入点，甚至其他Cisco交换机，自动配置交换机端口参数和最佳方案策略。SmartPorts宏的功能远超过了QoS，它还可配置安全及其他特性。SmartPorts调用AutoQoS进行QoS组件的端口配置——这实质上是在一个宏（SmartPorts）内触发另一个宏（AutoQoS）。

13.12 控制层面限速

设计建议:

■ 理解用于增强网络基础设施的可选QoS安全工具——控制层面限速特性的目的和用法。

控制层面限速（CoPP）是在运行Cisco IOS 的Catalyst 4500 和6500 系列交换机上可用的安全基础设施特性，它允许配置QoS策略，来对交换机主CPU处理的流量进行限率限制。这样做可保护交换机的控制层免受直接的拒绝服务（DoS）攻击、侦察活动或其他可能泛洪无用控制流量到CPU的网络错误（比如ICMP的错误消息等）的影响。

CoPP通过定义和强制执行QoS策略，控制主交换CPU（路由或交换处理器）处理的流量，来保护交换机。通过使用CoPP，这些配置的QoS策略用于放行、阻塞或限制主CPU处理的数据包。

由主CPU处理的数据包，也就是控制层面流量，通常包括以下内容:

■ 路由协议；

■ 发往路由器本地IP地址的数据包；

■ 来自网络管理协议的数据包，比如SNMP；

■ 交互访问协议，比如SSH和Telnet；

■ 其他协议，比如ICMP或可能要求交换CPU进行处理的其他IP协议；

■ 第2层数据包，比如BPDU、CDP、DOT1X等。

CoPP 使用MQC 来配置QoS 策略。MQC 允许根据不同的条件，在class map 中将去往CPU的流量分为多个类。

在定义好流量类之后，可以定义QoS policy map，并在这里为每个类配置放行所有数据包、丢弃所有数据包或仅当流量超出特定的速率限制时丢弃数据包。

最后，控制层面以虚接口的形式出现在配置中，并在这个虚接口上应用MQC service policy命令。

控制层面限速的更多细节和设计建议详见在线附录B。

13.13 小结

本章讨论了园区网QoS设计的注意事项和建议。QoS在富媒体园区网中的主要角色是标识和管理因为瞬间缓存溢出导致的数据包丢失——这种丢弃行为在GE/10GE速率的园区网络中可在几十毫秒之内发生。园区网QoS的次要角色是在接入边界区分和管理应用流量。

本章同样回顾了一些应用于园区网的战略性QoS设计原则，比如:

■ 优先选择在硬件上实施QoS，别无他选时再实施软件QoS；

■ 在技术条件和管理条件均可行的条件下，在尽可能靠近源的位置对应用进行分类和标记；

■ 在尽量靠近源的地方对不需要的流量进行限速；

■ 为了防止发生拥塞，在每个节点都启用队列策略，无论该节点发生拥塞的可能性有多小；

■（可选）启用控制层面限速来保护控制层面。

在这之后，介绍了基于MLS和基于MQC的QoS之间的语法和功能区别，并讨论了与园区网设计相关的注意事项和建议。

接下来介绍了内部DSCP的概念，并通过阐释静态和动态端口信任状态的工作原理，介绍了内部DSCP的值是怎样得到的。随后介绍了信任边界，并介绍了为什么要将终端设备分为三个主要的信任类别（不可信、可信和条件信任）。

在讨论了信任状态之后，介绍了物理接口QoS与逻辑接口QoS。然后回顾了最简单、最模块化的QoS设计选项——基于端口的QoS。随后概述了基于VLAN的QoS，并说明了它如何能够扩展特定的策略（比如信任、分类和标记），也说明了不适用的策略（比如汇聚层限速）。每端口/每VLAN是一种用于提供非常精细粒度的策略控制工具。这之后以平台为基础，讨论了在应用EtherChannel 时的物理和逻辑关系，即哪些QoS 策略元素应用于逻辑Port Channel 接口，哪些应用于物理成员接口。

之后介绍了在园区网中部署QoS的四步骤模型。

1.全局启用QoS（只需在使用MLS QoS 的交换机上启用）。

2.应用入向QoS模型。

a.配置信任，或者明确配置分类、标记和限速策略。

b.配置入向队列（如果设备支持且设计需要的话）。

3.应用出向QoS模型，将数据流分配到传输队列并启用丢弃策略。

4.（可选）启用控制层面限速（在支持此特性的平台上）。

接下来，根据交换机端口连接的设备类型，定义了详细的入向和出向端口QoS角色:

■ 不可信终端设备；

■ 可信终端设备；

■ 条件信任终端设备；

■ 网络基础设施组成部分。

接下来概述了AutoQoS特性。AutoQoS-VoIP是加速IP电话QoS部署的有效工具，而AutoQoS-SRND4用于对富媒体园区网有需求的设计选项。随后进一步指出了AutoQoS不是万能的设计选项，可以将其当做能被修改和调整的设计模板。

最后，简单讨论了控制层面限速，它是能够增强网络基础设施的可选的QoS安全工具。

13.14 扩展阅读

企业媒体网服务质量设计4.0—概览:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSIntro_40.html

企业媒体网服务质量设计4.0:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSCampus_40.html

媒体网QoSw设计策略一览:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/qosmrn.pdf

媒体网园区QoS设计一览:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/qoscampusaag.html

媒体网园区AutoQoS设计一览:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/autoqosmediacampus.pdf

第14章 园区网接入层（Cisco Catalyst 3750）的QoS设计

园区网接入层交换机的QoS角色是在边界区分和管理流量，并管理数据包丢失。图14-1说明了园区网接入层交换机特定端口的服务质量（QoS）角色。

图14-1 园区网接入层交换机端口QoS角色

在本书的设计章节中（从本章开始），将只选择一个平台来代表网络中的特定位置（PIN）。这只是为了减少配置的命令数量并帮助限制本书的范围（和页数）。例如，本设计章节将关注Cisco Catalyst 3750，该交换机适合扮演园区网接入层交换机的角色。当然，并不是说Catalyst 3750 是适合此角色的唯一平台，也不是说园区网接入层交换机是Catalyst 3750 能充当的唯一角色——只是它和这个角色比较匹配而已。

首先让我们回顾一下这个平台的架构，特别是与QoS相关的部分。

14.1 Cisco Catalyst 3750 QoS架构

从QoS 的角度来说，Cisco Catalyst 3750-X（以下简称Catalyst 3750）几乎和包括Catalyst 2960-S 和3650-X 在内的其他几个Catalyst 2K/3K 平台设备等同。因此，本设计章节中展示的配置命令在大多数情况下也都可以应用到其他平台上。然而，表14-1中总结了平台之间存在的一些关键区别。

表14-1 Cisco Catalyst 2960-S、3560-G/E/X和3750-G/E/X:主要功能特性表

图14-2展示了此平台的QoS架构。

图14-2 Cisco Catalyst 3750 QoS 架构模型

在入方向上，设备会根据信任状态或class map，对流量进行分类。可以在物理交换机端口或（多层交换机的）SVI（交换机虚接口）上应用标记或限速策略，这样做允许应用每VLAN或每端口/每VLAN的策略。

因为所有端口入方向的总带宽可能会超过堆叠或内部环的带宽，所以入向队列处于数据包被分类、限速和标记后，处于数据包被转发到交换结构（内部或堆叠环）之前。同样，因为多个入向端口可以同时的发送数据包到一个向站端口（如上行链路端口）并造成拥塞，出向队列位于堆叠或内部环之后。队列调度算法为SRR（共享轮询），丢包算法是WTD（加权尾部丢弃），两种算法都将随后在本章具体讨论。

这些交换机平台上与QoS相关的关键区别如下。

■ Catalyst 2960-G/S 不支持多层交换，也就不支持每VLAN 或每端口/ 每VLAN 策略。

■ Catalyst 2960-G 限速最小只支持到1Mbit/s。此产品家族的所有其他平台都能限速到最小8kbit/s（2960-S除外，虽然能配置其以8kbit/s限速，但其只能以最小16kbit/s进行限速）。

■ Catalyst 2960-S 不支持入向队列。

■ Catalyst 2960-S 不支持class-default class map。

■ 只有Catalyst 3650-E/X 和3750-X 支持IPv6 的QoS。

■ 只有Catalyst 3650-E/X 和3750-X 支持10Gbit/s 以太网接口上的限速。

■ 只有Catalyst 3650-E/X 和3750-X 支持10Gbit/s 以太网接口上的SRR 整形加权。

14.2 QoS设计步骤

在Cisco Catalyst 3750 系列交换机上配置QoS 有4 个主要的步骤。

1.启用QoS。

2.配置入向QoS模型，包括如下。

● 信任DSCP 模型。

● 条件信任模型。

● 服务策略模型。

3.配置入向队列。

4.配置出向队列。

这些设计步骤将相继介绍。

14.2.1 启用QoS

因为Catalyst 3750 是一个基于多层交换（MLS）的QoS 平台，其QoS 默认是被禁用的，所以需要在全局明确地启用QoS。这是在这些平台上部署QoS关键的第一步。如果忽略了这个小小的（但是重要的）步骤，将可能造成QoS排错过程中的难题；这是因为交换机软件能够接受QoS 命令，甚至会在交换机配置中显示这些命令，但这些命令在启用全局命令mls qos之前都不会激活。

C3750(config)# mls qos

可以通过show mls qos 命令验证此配置，如例14-1 所示。

注释:为了减少冗余，通常只展示一个验证命令的一个示例。

例14-1 在Catalyst 3750上验证全局QoS:show mls qos

C3750# show mls qos

QoS is enabled

QoS ip packet dscp rewrite is enabled

14.2.2 入向QoS模型

入向QoS模型包括:

■ 信任；

■ 分类和标记；

■ 可选的限速；

■ 入向队列。

这些入向QoS模型将相继介绍。

1.信任模型

一个端口可被配置成4种主要的信任状态:

■ 不可信状态；

■ 信任CoS状态；

■ 信任DSCP状态；

■ 条件信任状态。

除了条件信任状态是动态的，所有其他的信任状态都是静态的。下面将轮流介绍这些信任状态。

不可信状态

在Catalyst 3750上全局启用MLS QoS之后，所有端口都会被自动设置成默认不可信状态。因此，不需要使用明确的命令将端口设置为不可信状态。然而，如果要将一个之前被配置为其他信任状态端口还原成不可信状态，需要输入接口命令no mls qos trust。

信任CoS状态

可通过配置接口命令mls qos trust cos 将Catalyst 3750 交换机端口设置为信任CoS 状态。然而，如果一个接口被设置成了信任CoS状态，它默认将计算进入数据包的（CoS值*8），并将计算结果作为数据包的内部DSCP值。虽然这种默认的映射适用于许多标记，但可能不适用于VoIP，因为VoIP 通常使用CoS 5 标记，这默认会被映射为DSCP 40（而不是RFC 3246 定义中EF PHB 的46）。因此，如果接口被设置为信任CoS 状态，需修改默认的CoS 到DSCP 映射表，使CoS 5 映射为DSCP 46，如例14-2 所示。

例14-2 在Catalyst 3750上配置信任CoS状态，并且修改CoS到DSCP的映射

C3750(config)# mls qos map cos-dscp 0 8 16 24 32 46 48 56

! CoS 5 (the sixth CoS value, starting from 0) is mapped to 46

C3750(config)# interface GigabitEthernet 1/0/1

C3750(config-if)# mls qos trust cos

! The interface is set to statically trust CoS

可以通过如下命令验证例14-2的配置。

■ show mls qos map cos-dscp（详见例14-3）。

■ show mls qos interface（详见例14-4）。

例14-3 验证Catalyst 3750上的全局CoS到DSCP映射修改:show mls qos map cos-dscp

C3750# show mls qos map cos-dscp

Cos-dscp map:

cos:　0　1　2　3　4　5　6　7

--------------------------------

dscp:　0　8 16 24 32 46 48 56

在例14-3 中，CoS 5 的CoS 到DSCP 映射值从默认映射的40（CoS 5*8）修改为46（来匹配RFC 3246 中关于将实时应用标记为DSCP 46/EF 的建议）。

例14-4 验证Catalyst 3750上的接口信任设置:show mls qos interface

C3750# show mls qos interface GigabitEthernet 1/0/1

GigabitEthernet1/0/1

trust state:trust cos

trust mode:trust cos

trust enabled flag:ena

COS override:dis

default COS:0

DSCP Mutation Map:Default DSCP Mutation Map

Trust device:none

qos mode:port-based

信任DSCP状态

因为DSCP与QoS标记相比粒度更为精确，因此建议使用信任DSCP模型，而不是信任CoS 模型。可通过接口命令qos trust dscp 将Catalyst 3750 交换机端口配置为信任DSCP，如例14-5所示。

例14-5 在Catalyst 3750上配置信任DSCP

C3750(config)# interface GigabitEthernet 1/0/1

C3750(config-if)# mls qos trust dscp

! The interface is set to statically trust DSCP

可以通过命令show mls qos interface 验证例14-5 中的配置。

条件信任状态

除了配置交换机端口静态地信任终端设备之外，Catalyst 3750 家族还支持通过接口命令mls qos trust device 配置动态地条件信任状态。此命令支持如下的关键字选项。

■ cisco-phone:用于条件信任Cisco IP 电话。

■ cts:用于条件信任Cisco TelePresence 系统。

■ ip-camera:用于条件信任Cisco IP 视频监控摄像头。

■ media-player:用于条件信任Cisco数字媒体播放器。

除了指定要信任的设备类型，也可以指定要扩展的信任类型（CoS或DSCP）。例如，当为Cisco IP 电话配置条件信任时，建议动态扩展CoS 信任，因为Cisco IP 电话只能从二层（CoS）而不能从三层对PC的QoS标记进行重标记。对于其他没有重标记限制的终端设备，建议（与信任CoS相比）动态扩展信任DSCP，这不仅因为DSCP有更细的标记粒度，也因为在Catalyst 3750 入向交换机端口上配置的信任类型，最终会决定在出向端口上应用的队列策略。具体地说，如果一个入向交换机端口被配置为信任CoS状态——无论是静态配置还是动态配置（使用接口命令mls qos trust device）——CoS 到队列的映射将决定入向和出向的队列策略。相反，如果一个入向交换机端口被配置为信任DSCP状态——无论是静态配置还是动态配置——DSCP到队列的映射将决定入向和出向的队列策略。因为DSCP到队列的映射有更细粒度的策略选项，所以将入向交换机端口设置为信任DSCP状态，能够使数据包被分配到更多队列中，因此这是首选的配置方式。

如例14-6所示，使用动态的条件信任策略将CoS信任扩展到CDP发现的Cisco IP电话上。

例14-6 在Catalyst 3750上为Cisco IP电话配置（CoS模式）条件信任

C3750(config)# mls qos map cos-dscp 0 8 16 24 32 46 48 56

! CoS 5 (the sixth CoS value, starting from 0) is mapped to 46

C3750(config)# interface GigabitEthernet 1/0/1

C3750(config-if)# switchport access vlan 10

C3750(config-if)# switchport voice vlan 110

C3750(config-if)# spanning-tree portfast

C3750(config-if)# mls qos trust device cisco-phone

! The interface is set to conditionally trust Cisco IP phones

C3750(config-if)# mls qos trust cos

! CoS trust will be dynamically extended to Cisco IP phones

可以通过show mls qos interface 命令来验证此配置。

2.分类和标记模型

在许多情况下，信任模型可能不适用或无法区分端到端QoS战略模型所需要的那么多流量类型。因此，可能需要在访问边界上实施明确的分类和标记策略。

即使在基于MLS QoS 的交换机上，分类和标记策略也将使用class map 和policy map 的MQC方法，这会为策略选项带来近乎无限的变化。简单来说，例14-7展示的配置示例基于图11-5（8类QoS模型）。

注释:如前一章所述，不是所有的应用类都会出现在访问边界的入方向上。例如，流媒体视频流量就不太可能出现在访问边界的入方向上（因为这种流量不是从园区网终端设备发出的，但可能会发往这些终端设备），网络控制流量也不会从园区网终端设备发出。因此，访问边界的分类和标记policy map中并不需要包括这些应用类。

注释:为简洁起见，略去了策略实例中访问控制列表的配置部分。

例14-7 Catalyst 3750上的分类和标记策略

! This section configures the class maps

C3750(config-cmap)# class-map match-all VOICE

C3750(config-cmap)# match ip dscp ef

! Voice is matched on DSCP EF

C3750(config-cmap)# class-map match-all INTERACTIVE-VIDEO

C3750(config-cmap)# match access-group name INTERACTIVE-VIDEO

! Associates interactive video access-list with class map

C3750(config-cmap)# class-map match-all SIGNALING

C3750(config-cmap)# match ip dscp cs3

! Signaling is matched on DSCP CS3

C3750(config-cmap)# class-map match-all TRANSACTIONAL-DATA

C3750(config-cmap)# match access-group name TRANSACTIONAL-DATA

! Associates transactional data access-list with class map

C3750(config-cmap)# class-map match-all SCAVENGER

C3750(config-cmap)# match access-group name SCAVENGER

! Associates scavenger access-list with class map

C3750(config-cmap)# class-map match-all DEFAULT

C3750(config-cmap)# match access-group name DEFAULT

! Associates default access-list with class map

! This section configures the per-port ingress marking policy map

C3750(config-cmap)# policy-map PER-PORT-MARKING

C3750(config-pmap)# class VOICE

C3750(config-pmap-c)# set dscp ef

! VoIP is marked EF (see note below)

C3750(config-pmap-c)# class SIGNALING

C3750(config-pmap-c)# set dscp cs3

! Signaling (from the VVLAN) is marked CS3 (see note below)

C3750(config-pmap-c)# class INTERACTIVE-VIDEO

C3750(config-pmap-c)# set dscp af41

! Interactive video is marked AF41

C3750(config-pmap-c)# class TRANSACTIONAL-DATA

C3750(config-pmap-c)# set dscp af21

! Transactional data is marked AF21

C3750(config-pmap-c)# class SCAVENGER

C3750(config-pmap-c)# set dscp cs1

! Scavenger traffic is marked CS1

C3750(config-pmap-c)# class DEFAULT

C3750(config-pmap-c)# set dscp default

! An explicit class-default marks all other IP traffic to 0 (see note)

! This section attaches the service-policy to the interface(s)

C3750(config)# interface range GigabitEthernet 1/0/1-48

C3750(config-if-range)# switchport access vlan 10

C3750(config-if-range)# switchport voice vlan 110

C3750(config-if-range)# spanning-tree portfast

C3750(config-if-range)# service-policy input PER-PORT-MARKING

! Attaches the per-port marking policy to the interface(s)

注释:虽然Catalyst 3750的IOS中有隐含的class-default类，但分配到此类的策略行为并不是强制的。因此，例14-7中明确配置了DEFAULT类，将所有其他IP流量的标记/重标记策略设置为DSCP 0。

注释:即使对于可信的应用类（如语音和信令），也使用明确的标记命令（set dscp），而不使用policy map中的trust行为。这是因为policy map中的trust行为需要消耗更多的硬件资源。使用明确的（但看似冗余的）标记命令，能够从硬件的角度上提升策略的应用效率。

注释:分类和标记模型可基于每端口或每VLAN进行部署（将稍后在本章讨论）。

可以通过如下命令验证例14-7中的配置。

■ show mls qos interface

■ show class-map

■ show policy-map

■ show policy-map interface

注释:与验证命令show mls qos interface（详见例14-5）相比，其他验证命令都是静态的，只能返回已经配置的命令，而不能提供任何动态的验证信息。即使在Catalyst 3750上，命令show policy-map interface也不能显示动态的数据包计数、字节计数、丢包和比特每秒（bit/s）速率（与其他设备上的相应命令一样）。因此，除了返回一部分配置信息之外，能从这些验证命令中得到的信息很少，所以为了简洁就略去了这些命令的示例。

3.分类、标记和限速模型

可以选择使用限速策略并有效地将其部署在园区网的访问边界，来管理应用流量并丢弃无用流量。

在例14-8中，园区网访问边界采用了（基于图11-7）的12类策略（从策略中精简了网络控制和流媒体视频等不会出现的应用类），对来自语音VLAN（VVLAN）和动态VLAN（DVLAN）的流量进行了区分。具体说来，来自VVLAN的VoIP流量和信令流量被分别限速至128kbit/s和32kbit/s（因为超过此标准的流量可能预示着网络滥用）。相似地，DVLAN中的多媒体会议、信令和清道夫流量也可由限速器丢弃。然而，数据层面的限速策略可以应用于业务性数据、大数据和尽力而为流量上，这样这些流就可在严重超出速率限制时被重标记（而不是在入向边界被丢弃）。通过全局配置命令mls qos map policed-dscp 可以配置限速的DSCP 映射，从而实施重标记，这个命令指定了当超出速率时，哪些DSCP值可以被重标记，以及应当将其重标记为何值（在数据层面限速/ 清道夫类的QoS 策略中，此值为CS1/DSCP 8）。本例的策略逻辑与图13-8所示相同。

注释:为了简洁和最小化冗余，略去了class map的配置。

例14-8 Catalyst 3750上的分类、标记和限速示例

! This section configures the global policed-DSCP markdown map

C3750(config)# mls qos map policed-dscp 0 10 18 to 8

! DSCP 0 (DF), 10 (AF11) and 18 (AF21) are marked down to 8 (CS1)

! if found to be in excess of their (respective) policing rates

! This section configures the per-port policing policy map

C3750(config)# policy-map PER-PORT-POLICING

C3750(config-pmap)# class VVLAN-VOIP

C3750(config-pmap-c)# set dscp ef

C3750(config-pmap-c)# police 128k 8000 exceed-action drop

! VoIP is marked EF and policed to drop at 128 Kbps

C3750(config-pmap-c)# class VVLAN-SIGNALING

C3750(config-pmap-c)# set dscp cs3

C3750(config-pmap-c)# police 32k 8000 exceed-action drop

! (VVLAN) Signaling is marked CS3 and policed to drop at 32 Kbps

C3750(config-pmap-c)# class MULTIMEDIA-CONFERENCING

C3750(config-pmap-c)# set dscp af41

C3750(config-pmap-c)# police 5m 8000 exceed-action drop

! Multimedia conferencing is marked AF41 and policed to drop at 5 Mbps

C3750(config-pmap-c)# class SIGNALING

C3750(config-pmap-c)# set dscp cs3

C3750(config-pmap-c)# police 32k 8000 exceed-action drop

! (DVLAN) Signaling is marked CS3 and policed to drop at 32 Kbps

C3750(config-pmap-c)# class TRANSACTIONAL-DATA

C3750(config-pmap-c)# set dscp af21

C3750(config-pmap-c)# police 10m 8000 exceed-action policed-dscp-transmit

! Trans-data is marked AF21 and policed to re-mark (to CS1) at 10 Mbps

C3750(config-pmap-c)# class BULK-DATA

C3750(config-pmap-c)# set dscp af11

C3750(config-pmap-c)# police 10m 8000 exceed-action policed-dscp-transmit

! Bulk data is marked AF11 and policed to re-mark (to CS1) at 10 Mbps

C3750(config-pmap-c)# class SCAVENGER

C3750(config-pmap-c)# set dscp cs1

C3750(config-pmap-c)# police 10m 8000 exceed-action drop

! Scavenger traffic is marked CS1 and policed to drop at 10 Mbps

C3750(config-pmap-c)# class DEFAULT

C3750(config-pmap-c)# set dscp default

C3750(config-pmap-c)# police 10m 8000 exceed-action policed-dscp-transmit

! An explicit default class marks all other IP traffic to DF

! and polices all other IP traffic to re-mark (to CS1) at 10 Mbps

! This section attaches the service policy to the interface(s)

C3750(config)# interface range GigabitEthernet 1/0/1-48

C3750(config-if-range)# switchport access vlan 10

C3750(config-if-range)# switchport voice vlan 110

C3750(config-if-range)# spanning-tree portfast

C3750(config-if-range)# service-policy input PER-PORT-POLICING

! Attaches the per-port policing policy to the interface(s)

注释:如例14-8所示，Catalyst 3750的IOS允许使用命令后缀k（千比特）、m（兆比特）、g（吉比特）来设置限速速率。此外，可将十进制小数点与这些后缀一同使用。例如，10.5Mbit/s的速率可以通过policy map命令police 10.5m来表示。虽然这些配置中的限速速率都会转换为比特每秒的完整数值，但这种做法让用户输入这些速率更加方便，且不容易出错（否则可能需要输入10个0来定义限速速率）。

注释:从技术上看来，虽然可以在每VLAN的基础上应用这样的聚合限速策略，但并不建议这样做。这是因为在特定VLAN中，终端设备的数量是动态变化的，然而在聚合层限速的速率却是静态固定的，这就会导致每个终端设备的带宽分配不可预测。

可以通过如下命令验证例14-8中的配置。

■ show mls qos interface

■ show class-map

■ show policy-map

■ show policy-map interface

■ show mls qos maps policed-dscp（详见例14-9）

■ show mls qos interface interface x/y policers（详见例14-10）

例14-9 在Catalyst 3750上验证全局限速降级映射:show mls qos maps policed-dscp

C3750# show mls qos maps policed-dscp

Policed-dscp map:

d1:　d2 0　1　2　3　4　5　6　7　8　9

---------------------------------------

0:　08 01 02 03 04 05 06 07 08 09

1:　08 11 12 13 14 15 16 17 08 19

2:　20 21 22 23 24 25 26 27 28 29

3:　30 31 32 33 34 35 36 37 38 39

4:　40 41 42 43 44 45 46 47 48 49

5:　50 51 52 53 54 55 56 57 58 59

6:　60 61 62 63

例14-9显示了限速DSCP降级映射。数据包提供给限速器的DSCP值的第1位数字如表中Y轴所示。数据包提供给限速器的DSCP值的第2为数字如表中X轴方向所示。例如，业务性数据应用类（AF21/18）的DSCP值可在行d1=1、列d2=8位置查得。有此DSCP值（以及DF/0和AF11/10）的数据包都将在超过限速速率时被重标记为CS1（08）。

例14-10 在Catalyst 3750上验证接口限速器:show mls qos interface interface x/y policers

C3750# show mls qos interface GigabitEthernet 1/0/1 policers

GigabitEthernet1/0/1

policymap=PER-PORT-POLICING

type=Single, id=1 rate=128000, qlimit=8000, drop=1

type=Single, id=2 rate=32000, qlimit=8000, drop=1

type=Single, id=3 rate=5000000, qlimit=8000, drop=1

type=Single, id=4 rate=32000, qlimit=8000, drop=1

type=Single, id=5 rate=10000000, qlimit=8000, drop=0

type=Single, id=6 rate=10000000, qlimit=8000, drop=0

type=Single, id=7 rate=10000000, qlimit=8000, drop=1

type=Single, id=8 rate=10000000, qlimit=8000, drop=0

例14-10显示了G1/0/1接口上配置的限速器，包括限速速率、突发速率以及丢弃功能值（drop=1表示超出速率限制的流量将被丢弃；drop=0表示超出速率限制的流量不会被丢弃，但会进行重标记）。

14.2.3 队列模型

因为在Catalyst 3750 交换机上，所有端口的入方向带宽可能会超过堆叠或内部环的带宽，所以入向队列位于数据包分类、限速和标记后，且位于数据包转发到交换结构之前（如图14-2所示）。此外，因为多个入向端口可以同时将数据包发送给一个出向端口，从而导致拥塞，因此出向队列位于堆叠或内部环之后。

Catalyst 3750 上的入向队列和出向队列都由SRR 调度算法进行调度。SRR 可被配置为两种模式:整形或共享。

在整形模式中，出向队列获得一定百分比的带宽保证，并且也被限制在这个流量上。即使链路空闲，整形流量使用的带宽也不能超过分配的带宽限制。整形模式在时间上实现了更加均匀的流量，并减少了突发流量的波峰和波谷。整形模式通过使用权重的绝对值来计算队列的可用带宽。SRR 整形可通过接口命令srr-queue bandwidth shape 进行配置。

在共享模式中，入向队列和出向队列会根据管理员配置的权重来共享带宽。带宽会获得一定水平的保证，但并不被限制在这个流量上。例如，如果一个队列为空且不再需要共享链路，其余的队列就可以共享未使用的带宽。在共享模式中，权重的比率控制着数据包离开队列的频率；绝对值在这里是没有意义的。SRR共享可通过接口命令srr-queue bandwidth share进行配置。

此外，入向和出向队列结构都支持启用单条优先级队列，或称为快速队列（因为它相当于EF PHB）。快速队列的入向和出向队列操作完全优先于其他队列，直到快速队列中的数据包都发送出去为止。在优先级队列发送一空后，调度程序才会服务配置为整形或共享SRR模式的其他非优先级队列。通过接口命令priority-queue可启用严格优先级队列。

按照Catalyst 3750 交换机的调度机制层级，整形模式会覆盖共享模式，优先级模式会覆盖整形和共享模式。

此外，Catalyst 3750 支持WTD（加权尾部丢弃）拥塞避免机制。WTD 是部署在队列上的，用来管理队列长度，并且为不同流量类提供对其优先级。当数据包进入到特定的入向或出向队列后，WTD会根据分配给数据帧的内部DSCP值，来决定数据包的丢弃门限值。如果给定的内部DSCP值超过了门限值（换句话说，目标队列的可用空间小于数据包的大小），交换机就会丢弃这个数据包。每个队列有三个门限值，内部DSCP值将用来决定三个门限值中的哪一个会真正应用到这个数据帧上。在三个门限值中，管理员可以（明确）配置其中的两个，还有一个不可配置（为隐含的），因为最后一个门限值对应于队尾（100%限制）。

在Catalyst 3750 上，通过使用CoS 到队列/ 门限值或DSCP 到队列/ 门限值的方法来映射数据包。使用哪个映射方法直接取决于在入方向上是信任数据包的CoS值，还是信任数据包的DSCP值（不可信的数据包会直接分配到默认队列中）。

通常在与平台相关的设计章节中，会分别介绍第11章提到的4类、8类和12类战略性端到端QoS 模型的队列模型。然而，因为Catalyst 3750 只支持4 条固定的硬件队列，而且4 类、8类和12类队列模型的配置几乎相同，所以只为该平台展示一个入向和出向队列模型。

1.入向队列模型

因为Catalyst 3750交换机平台的架构是基于超额预订的，因此它的设计初衷就是当关键流量通过入向队列，试图穿越背板/堆叠环时，通过对其实施保护来提供QoS保证。此平台的入向队列可被配置为2Q3T或1P1Q3T，后者是推荐使用的配置（因为它支持RFC 3246 EF PHB）。

明确地将Q2启用为优先级队列，并为其分配一定带宽（比如30%），就完成了1P1Q3T入向队列的配置。接下来，可以为非优先级队列分配SRR权重，本例为70%。在调整缓存分配时，可以为Q1分配90%缓存，而为Q2（PQ）分配10%；因为PQ是被实时服务的，因此为它分配较少缓存，并为非优先级队列分配较多缓存的做法通常更为有效。此后，可以在Q1上定义WTD门限值，来提供队列间的QoS；具体说来，可以将Q1T1明确设置为80%队列深度，将Q1T2明确设置为90%队列深度（Q3保持默认设置，为100%队列深度）。

设置完队列和门限值之后，可以将VoIP（EF）、广播视频（CS5）和实时交互（CS4）流量映射到严格优先级入向队列中，将所有其他流量类映射到默认（非优先级）入向队列中。不过，可以为控制层流量设置丢弃优先级，比如将网络控制（CS7）和网间控制（CS6）流量映射为最高WTD门限值（Q1T3）。此外，将信令（CS3）流量映射为中级WTD门限值（Q1T2），所有其他流量映射为Q1T1。图14-3 显示了Catalyst 3750 上的1P1Q3T 入向队列映射。

图14-3 Catalyst 3750入向队列模型

例14-11显示了Catalyst 3750 上1P1Q3T 入向队列的配置。

例14-11 Catalyst 3750上1P1Q3T入向队列配置示例

! This section configures the ingress queues

C3750(config)# mls qos srr-queue input priority-queue 2 bandwidth 30

! Q2 is enabled as a strict-priority ingress queue with 30% BW

C3750(config)# mls qos srr-queue input bandwidth 70 30

! Q1 is assigned 70% BW via SRR shared weights

! Q2 SRR shared weight is ignored (as it has been configured as a PQ)

C3750(config)# mls qos srr-queue input buffers 90 10

! Q1 is assigned 90% of queuing buffers and Q2 (PQ) is assigned 10%

C3750(config)# mls qos srr-queue input threshold 1 80 90

! Q1 thresholds are configured at 80% (Q1T1) and 90% (Q1T2)

! Q1T3 is implicitly set at 100% (the tail of the queue)

! Q2 thresholds are all set (by default) to 100% (the tail of Q2)

! This section configures ingress CoS-to-queue mappings (if required)

C3750(config)# mls qos srr-queue input cos-map queue 1 threshold 1 0 1 2

! CoS values 0, 1 and 2 are mapped to Q1T1

C3750(config)# mls qos srr-queue input cos-map queue 1 threshold 2 3

! CoS value 3 is mapped to ingress Q1T2

C3750(config)# mls qos srr-queue input cos-map queue 1 threshold 3 6 7

! CoS values 6 and 7 are mapped to ingress Q1T3

C3750(config)# mls qos srr-queue input cos-map queue 2 threshold 1 4 5

! CoS values 4 and 5 are mapped to ingress Q2 (the PQ)

! This section configures ingress DSCP-to-queue Mappings

C3750(config)# mls qos srr-queue input dscp-map queue 1 threshold 1 0 8 10 12 14

! DSCP DF, CS1 and AF1 are mapped to ingress Q1T1

C3750(config)# mls qos srr-queue input dscp-map queue 1 threshold 1 16 18 20 22

! DSCP CS2 and AF2 are mapped to ingress Q1T1

C3750(config)# mls qos srr-queue input dscp-map queue 1 threshold 1 26 28 30 34 36 38

! DSCP AF3 and AF4 are mapped to ingress Q1T1

C3750(config)# mls qos srr-queue input dscp-map queue 1 threshold 2 24

! DSCP CS3 is mapped to ingress Q1T2

C3750(config)# mls qos srr-queue input dscp-map queue 1 threshold 3 48 56

! DSCP CS6 and CS7 are mapped to ingress Q1T3 (the tail of Q1)

C3750(config)# mls qos srr-queue input dscp-map queue 2 threshold 3 32 40 46

! DSCP CS4, CS5 and EF are mapped to ingress Q2T3 (the tail of the PQ)

注释:只有在交换机端口的入向方向上配置了信任CoS时，才需要使用CoS到队列的映射。在此情况下，也应当修改CoS到DSCP的映射，也就是将CoS 5映射为DSCP EF（如例14-2所示）。此外还需注意的是，因为CoS到队列映射的粒度有限，无法将多媒体会议（AF4）和实时交互（CS4）流量分别分配到单独的队列中（因为它们共享相同的CoS值4）；也无法给信令（CS3）和多媒体流媒体（AF3）流量分别分配单独的队列门限值（因为它们共享相同的CoS值3）。

注释:为了简洁起见，本章的配置中未展示非标准的DSCP到队列映射。

可以通过如下命令验证例14-11的配置。

■ show mls qos input-queue（详见例14-12）

■ show mls qos maps cos-input-q（详见例14-13）

■ show mls qos maps dscp-input-q（详见例14-14）

例14-12 在Catalyst 3750上验证入向队列:show mls qos input-queue

C3750# show mls qos input-queue

Queue　:　　1　　2

------------------------------------------

buffers　:　　90　　10

bandwidth:　　70　　30

priority　:　　0　　30

threshold1:　　80　100

threshold2:　　90　100

例14-12 中展示了在Q1和Q2之间以90:10分配入向队列缓存，以70:30分配带宽。为Q2启用了严格优先级队列，并分配30最大带宽保证。Q1T1和Q2T2的门限值分别被设置为80%和90%，但所有的Q2门限值都是100%。

例14-13 在Catalyst 3750上验证入向队列映射:show mls qos maps cos-input-q

C3750# show mls qos maps cos-input-q

Cos-inputq-threshold map:

cos:　0　1　2　3　4　5　6　7

------------------------------------

queue-threshold:1-1 1-1 1-1 1-2 2-3 2-3 1-3 1-3

例14-13展示了入向CoS到队列的映射。具体来看，CoS值1和2映射到Q1T1，CoS值3映射到Q1T2，CoS值4和5映射到Q2T1（PQ），CoS值6和7映射到Q1T3。

例14-14 在Catalyst 3750上验证入向队列映射:show mls qos maps dscp-input-q

C3750# show mls qos maps dscp-input-q

Dscp-inputq-threshold map:

d1:d2　0　1　2　3　4　5　6　7　8　9

------------------------------------------------------------

0:　01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01

1:　01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01

2:　01-01 01-01 01-01 01-01 01-02 01-01 01-01 01-01 01-01 01-01

3:　01-01 01-01 02-03 01-01 01-01 01-01 01-01 01-01 01-01 01-01

4:　02-03 02-01 02-01 02-01 02-01 02-01 02-03 02-01 01-03 01-01

5:　01-01 01-01 01-01 01-01 01-01 01-01 01-03 01-01 01-01 01-01

6:　01-01 01-01 01-01 01-01

例14-14显示了入向DSCP到队列的映射。数据包DSCP值的第1位数字如表Y轴方向所示；数据包DSCP值的第2位数字如表X轴方向所示。映射表对应于图14-3。注意CS4（DSCP 32）、CS5（DSCP 40）和EF（DSCP 46）都被映射到了Q2（PQ）。还需注意内部DSCP 值40～47默认映射到Q2T1，这解释了为什么表中会有更多值被映射到这个队列。

2.出向队列模型

Catalyst 3750交换机家族上的出向队列可被配置为4Q3T或1P3Q3T，后者是推荐的配置（因为其支持RFC 3246 EF PHB）。

可以在Catalyst 3750 上配置两个不同的出向队列集。然而，为了维持一致的PHB（逐跳行为），通常建议只使用一个。

Catalyst 3750 中一个独一无二的特性是可以为硬件队列提供灵活的缓存分配，缓存可以动态地（按需）租出或借入。具体来说，每个队列都可以租出其缓存容量的一部分，除非达到了特定的最小预留门限值。此外，每个队列可以在可用的情况下从公共缓存池（不分配给任何特定队列）借入至多4倍于其自身容量的缓存。队列1到队列4的建议缓存分配是20%、30%、35%和15%。对应地，建议的预留门限值参数和非优先级队列最大（过载）门限值分别是100%和400%。对于优先级队列来说，所有门限值都应设置为100%。

一旦将主要的队列集设置为1P3Q3T出向队列后，可在Q1和Q4上定义WTD来提供队列间QoS。具体来说，可以将Q2T1明确地设置为80%队列深度，将Q2T2明确地设置为90%队列深度（Q3保持默认设置，即100%队列深度）。将Q4T1明确地设置为60%队列深度，除最大（过载）门限值被设置为400%以外，Q4的其他门限值保持为默认值（100%队列深度）。最后的这个设置使得即使是清道夫和大块数据流量也可以获益于从此平台扩展的缓存容量，尤其从带宽的角度考虑时，这些流量是最不受青睐的数据流，因此也就可能需要最大的队列深度。

在设置了队列和门限值之后，可以将VoIP（EF）、广播视频（CS5）和实时交互（CS4）流量映射到严格优先级出向队列中（Q1）；将网络管理（CS2）、业务性数据（AF2）、多媒体流媒体（AF3）和多媒体会议（CS2）流量映射到Q2T1中；将信令（CS3）流量映射到Q2T2中；将网络控制（CS7）和网间控制（CS6）流量映射到Q2T3中；将默认（DF）流量映射到默认队列Q3中；将清道夫（CS1）流量映射到Q4T1中，将大块数据流量映射到Q4T2中。图14-4 说明了Catalyst 3750 上的1P3Q3T 出向队列映射。

图14-4 Catalyst 3750出向队列模型

例14-15显示了Catalyst 3750 上1P3Q3T 出向队列的配置。

例14-15 Catalyst 3750上1P3Q3T出向队列的配置示例

! This section configures buffers and thresholds on Q1 through Q4

C3750(config)# mls qos queue-set output 1 buffers 15 30 35 20

! Queue buffers are allocated

C3750(config)# mls qos queue-set output 1 threshold 1 100 100 100 100

! All Q1 (PQ) Thresholds are set to 100%

C3750(config)# mls qos queue-set output 1 threshold 2 80 90 100 400

! Q2T1 is set to 80%; Q2T2 is set to 90%;

! Q2 Reserve Threshold is set to 100%;

! Q2 Maximum (Overflow) Threshold is set to 400%

C3750(config)# mls qos queue-set output 1 threshold 3 100 100 100 400

! Q3T1 is set to 100%, as all packets are marked the same weight in Q3

! Q3 Reserve Threshold is set to 100%;

! Q3 Maximum (Overflow) Threshold is set to 400%

C3750(config)# mls qos queue-set output 1 threshold 4 60 100 100 400

! Q4T1 is set to 60%; Q4T2 is set to 100%

! Q4 Reserve Threshold is set to 100%;

! Q4 Maximum (Overflow) Threshold is set to 400%

! This section configures egress CoS-to-Queue mappings (if required)

C3750(config)# mls qos srr-queue output cos-map queue 1 threshold 3 4 5

! CoS 4 and 5 are mapped to egress Q1T3 (the tail of the PQ)

C3750(config)# mls qos srr-queue output cos-map queue 2 threshold 1 2

! CoS 2 is mapped to egress Q2T1

C3750(config)# mls qos srr-queue output cos-map queue 2 threshold 2 3

! CoS 3 is mapped to egress Q2T2

C3750(config)# mls qos srr-queue output cos-map queue 2 threshold 3 6 7

! CoS 6 and 7 are mapped to Q2T3

C3750(config)# mls qos srr-queue output cos-map queue 3 threshold 3 0

! CoS 0 is mapped to Q3T3 (the tail of the default queue)

C3750(config)# mls qos srr-queue output cos-map queue 4 threshold 3 1

! CoS 1 is mapped to Q4T3 (tail of the less-than-best-effort queue)

! This section configures egress DSCP-to-Queue mappings

C3750(config)# mls qos srr-queue output dscp-map queue 1 threshold 3 32 40 46

! DSCP CS4, CS5 and EF are mapped to egress Q1T3 (tail of the PQ)

C3750(config)# mls qos srr-queue output dscp-map queue 2 threshold 1 16 18 20 22

! DSCP CS2 and AF2 are mapped to egress Q2T1

C3750(config)# mls qos srr-queue output dscp-map queue 2 threshold 1 26 28 30 34 36 38

! DSCP AF3 and AF4 are mapped to egress Q2T1

C3750(config)# mls qos srr-queue output dscp-map queue 2 threshold 2 24

! DSCP CS3 is mapped to egress Q2T2

C3750(config)# mls qos srr-queue output dscp-map queue 2 threshold 3 48 56

! DSCP CS6 and CS7 are mapped to egress Q2T3

C3750(config)# mls qos srr-queue output dscp-map queue 3 threshold 3 0

! DSCP DF is mapped to egress Q3T3 (tail of the best effort queue)

C3750(config)# mls qos srr-queue output dscp-map queue 4 threshold 1 8

! DSCP CS1 is mapped to egress Q4T1

C3750(config)# mls qos srr-queue output dscp-map queue 4 threshold 2 10 12 14

! DSCP AF1 is mapped to Q4T3 (tail of the less-than-best-effort queue)

! This section configures interface egress queuing parameters

C3750(config)# interface range GigabitEthernet1/0/1-48

C3750(config-if-range)# queue-set 1

! The interface(s) is assigned to queue-set 1

C3750(config-if-range)# srr-queue bandwidth share 1 30 35 5

! The SRR sharing weights are set to allocate 30% BW to Q2

! 35% BW to Q3 and 5% BW to Q4

! Q1 SRR sharing weight is ignored, as it will be configured as a PQ

C3750(config-if-range)# priority-queue out

! Q1 is enabled as a strict-priority queue

注释:如前所述，此平台只展示了（第11章中）4类、8类和12类战略性QoS模型中的一个队列模型，因为这些队列模型的配置和功能性几乎相同。唯一的例外是在4类模型中，建议对例14-15进行如下修改:mls qos srr-queue output dscp-map queue 4 threshold 2 24。此修改将信令流量（被标记为CS3/DSCP 24）映射到Q4T2（而不是Q2T2），从而更符合4类战略性模型。

注释:只有在交换机端口的入向方向上配置了信任CoS时，才需要使用CoS到队列的映射。在此情况下，也应当修改CoS到DSCP的映射，也就是将CoS 5映射为DSCP EF（如例14-2所示）。此外还需注意的是，因为CoS到队列映射的粒度有限，无法将多媒体会议（AF4）和实时交互（CS4）流量分别分配到单独的队列中（因为它们共享相同的CoS值4）；也无法给信令（CS3）和多媒体流媒体（AF3）流量分别分配单独的队列门限值（因为它们共享相同的CoS值3）；也无法给清道夫（CS1）和大块数据（AF1）流量分配单独的队列门限值（因为它们共享相同的CoS值1）。

可以通过以下命令验证例14-15中的配置。

■ show mls qos queue-set（详见例14-16）

■ show mls qos maps cos-output-q

■ show mls qos maps dscp-output-q

■ show mls qos interface interface x/y queueing（详见例14-17）

■ show mls qos interface interface x/y statistics（详见例14-18）

例14-16 在Catalyst 3750上验证出向队列:show mls qos queue-set

C3750# show mls qos queue-set 1

Queueset:1

Queue　:　　1　　2　　3　　4

----------------------------------------------

buffers　:　　15　　30　　35　　20

threshold1:　100　　80　100　　60

threshold2:　100　　90　100　100

reserved　:　100　100　100　100

maximum　:　100　400　400　400

例14-16所示案例已在每队列集的基础上，正确配置了的队列缓存、丢弃门限值、预留门限值和最大（过载）门限值。

例14-17 在Catalyst 3750上验证出向队列:show mls qos interface interface x/y queueing

C3750# show mls qos interface GigabitEthernet 1/0/1 queueing

GigabitEthernet1/0/1

Egress Priority Queue:enabled

Shaped queue weights (absolute):25 0 0 0

Shared queue weights:1 30 35 5

The port bandwidth limit:100 (Operational Bandwidth:100.0)

The port is mapped to qset:1

例14-17显示了已在接口上启用严格优先级队列，队列Q2、Q3、Q4分别获得剩余带宽的30%、35%和5%。

例14-18 在Catalyst 3750上验证出向队列:show mls qos interface interface x/y statistics

C3750# show mls qos interface GigabitEthernet 1/0/49 statistics

GigabitEthernet1/0/49 (All statistics are in packets)

dscp:incoming

-------------------------------

0 -　4:　　1729　　　0　　　0　　　0　　0

5 -　9:　　　0　　　0　　　0　　　0　　0

10 - 14:　　　0　　　0　　　0　　　0　　0

15 - 19:　　　0　　　0　　　0　　　0　　0

20 - 24:　　　0　　　0　　　0　　　0　　0

25 - 29:　　　0　　　0　　　0　　　0　　0

30 - 34:　　　0　　　0　　　0　　　0　　0

35 - 39:　　　0　　　0　　　0　　　0　　0

40 - 44:　　　0　　　0　　　0　　　0　　0

45 - 49:　　　0　　127292　　　0　　1263　　0

50 - 54:　　　0　　　0　　　0　　　0　　0

55 - 59:　　　0　　　0　　　0　　　0　　0

60 - 64:　　　0　　　0　　　0　　　0

dscp:outgoing

-------------------------------

0 -　4:　　947678　　　0　　　0　　　0　　0

5 -　9:　　　0　　　0　　　0　23842155　　0

10 - 14:　1190043　　　0　　　0　　　0　　0

15 - 19:　　　0　　　0　　　0　　1061726　　0

20 - 24:　　　0　　　0　　　0　　　0　10372

25 - 29:　　　0　　　0　　　0　　　0　　0

30 - 34:　　　0　　　0　　　0　　　0　8320623

35 - 39:　　　0　　　0　　　0　　　0　　0

40 - 44:　　　0　　　0　　　0　　　0　　0

45 - 49:　　　0　　127291　　　0　　　784　　0

50 - 54:　　　0　　　0　　　0　　　0　　0

55 - 59:　　　0　　　0　　　0　　　0　　0

60 - 64:　　　0　　　0　　　0　　　0

cos:incoming

-------------------------------

0 -　4:　　130653　　　0　　　0　　　998　　0

5 -　7:　　127599　　　613　　3156

cos:outgoing

-------------------------------

0 -　4:　　947754　25032199　　1061726　　10372　8320623

5 -　7:　　127291　　　784　　3462

output queues enqueued:

queue:threshold1 threshold2 threshold3

-----------------------------------------

queue 0:　　　0　　　0　　127291

queue 2:　　　0　　　0　　947611

queue 1:　9382416　　10396　　4246

queue 3:　23842155　1190043　　　0

output queues dropped:

queue:threshold1 threshold2 threshold3

-----------------------------------------

queue 0:　　　0　　　0　　　0

queue 1:　　　0　　　0　　　0

queue 2:　　　0　　　0　　　0

queue 3:　　　892　　　0　　　0

Policer:Inprofile:　　　0 OutofProfile:　　　0

例14-18显示了一台接入层Catalyst 3750 的一个上行链路端口的一系列动态更新的数据包统计表，此端口经常在接入到分布方向发生拥塞。第一张表显示了（自分布层）入站数据包的DSCP 值。DSCP 值分为五组。例如，携带DSCP EF/46 标记的入站数据包位于DSCP 45-49 行的第二列（127,291个数据包）。第二张表以相同格式显示了出站（到分布层）数据包的统计数据。例如，携带DSCP CS1/8 标记的出站数据包位于DSCP 5-9 行的第三列（23,842,155 个数据包）。第三张表按CoS值显示了（自分布层）入站数据包（分为四组）的统计数据。相似地，第四张表按CoS值显示了出站（到分布层）数据包的统计数据。第五和第六张表在队列统计方面非常有趣:第五张表显示了分配到每个队列/门限值组合的包数量。

注释:在此验证命令的输出中，队列数量比实际配置语法中使用的队列编号数值少1。例如，在配置中，队列编号是从1到4（没有队列0）。然而，在此验证输出中，队列1的统计数据以队列0显示。相似地，Q2以Q1显示，Q3以Q2显示，Q4以Q3显示。这只是工程上的疏忽。

例如，从第五张表中可知127,291个数据包被发送到（表中所示Q0）PQ（的队尾）；相似地， 23,842,155个数据包被发送到清道夫/大块数据队列的第一个门限值（表中所示Q3T1）。最后，第六张表以每队列/每门限值的方式显示了发生的任何丢包情况。从表中可知在清道夫/大块数据的第一个门限值发生了892次丢包（清道夫类的丢包）。

14.3 其他与平台相关的QoS设计选项

上述的设计代表了园区网访问边界中Catalyst 3750 QoS 的一些通用选项。但它们不是唯一可用的设计选项。其他选项如下:

■ 每VLAN QoS；

■ 每端口/ 每VLAN QoS；

■ EtherChannel QoS；

■ AutoQoS SRND4 ；

■ 控制层面限速。

每个设计选项都将相继简单地讨论。

14.3.1 每VLAN QoS设计

在Catalyst 3750平台上部署标记策略的另一种方法是以每VLAN的方式进行部署。为此，需要在属于该VLAN 的接口上，使用接口命令mls qos vlan-based。此外，还可以简化/ 拆分policy map，使其适用于每个VLAN。例14-19显示了每VLAN 标记模型。

例14-19 Catalyst 3750上的每VLAN策略示例

! This section configures the interface(s) for VLAN-based QoS

C3750(config)# interface range GigabitEthernet 1/0/1-48

C3750(config-if-range)# switchport access vlan 10

C3750(config-if-range)# switchport voice vlan 110

C3750(config-if-range)# spanning-tree portfast

C3750(config-if-range)# mls qos vlan-based

! Enables VLAN-based QoS on the interface(s)

! This section attaches the DVLAN policy to the DVLAN interface

C3750(config)# interface Vlan 10

C3750(config-if)# description DVLAN

C3750(config-if)# service-policy input DVLAN-MARKING

! Attaches the DVLAN Per-VLAN Marking policy to the DVLAN interface

! This section attaches the VVLAN policy to the VVLAN interface

C3750(config)# interface Vlan 110

C3750(config-if)# description VVLAN

C3750(config-if)# service-policy input VVLAN-MARKING

! Attaches the VVLAN Per-VLAN Marking policy to the VVLAN interface

可通过以下命令验证例14-19中的配置。

■ show mls qos interface

■ show class-map

■ show policy-map

■ show policy-map interface

14.3.2 每端口/每VLAN QoS

从技术的角度说，Catalyst 3750 支持每端口/ 每VLAN 特性。然而，在此平台上部署这个特性非常复杂，需要分层的QoS策略。

第一步需要配置class map，来定义与策略相关联的那些交换机端口。然后需要（根据不同级别的限速速率或超出速率限制所需的行为）定义一个或多个每端口限速器。这些限速器调用之前定义的class map，也就是指定了限速交换机端口的class map。这些每端口的限速器构成了分层中的“子”policy map。

接下来，为给定VLAN 中的多种流量类关联每端口限速器，来配置“父”policy map。顺便说一下，嵌套/ 子policy map 只能被一个父service policy 调用。每个父policy map 调用子限速器，来实现基于每端口的限速功能。最终，这些父policy map 会被应用到VLAN 接口上。

此外，需注意在Catalyst 3750 平台上，在交换机堆叠上启用基于VLAN 的QoS 并配置分层的policy map（启用每端口/ 每VLAN QoS）时，当堆叠配置变化时将会自动发生以下行为:

■ 当选出新的堆叠master后，堆叠master会在所有可以应用这些特性的端口上，重新启用并配置这些特性；

■ 当添加了新的堆叠member后，堆叠master会在所有可以应用这些特性的端口上，重新启用并配置这些特性；

■ 当合并交换机堆叠后，新的堆叠master会在新堆叠的交换机上，重新启用并配置这些特性；

■ 当一个交换机堆叠被分为两个或多个时，每个堆叠中的master会在自己及堆叠member上所有可以应用这些特性的端口上，重新启用并配置这些特性。

因此，即使Catalyst 3750支持每端口/每VLAN的QoS，但由于它过于复杂（与在Catalyst 4500上实施相同的特性相比）且有如此多不可避免的特殊情况，所以只建议高级管理员使用。

注释:可在http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSCampus_40.html#wp1099172上找到每端口/每VLAN的示例策略。

14.3.3 EtherChannel QoS设计

在Catalyst 3750 EtherChannel 链路上应用QoS 策略时，要求在EtherChannel 的每个物理端口成员接口上也应用相同的QoS策略；这包括入向信任/分类/标记/限速策略和出向队列策略（入向队列策略是全局定义的，因此不受此需求限制）。如果没有配置相同的策略，即使它们出现在了配置中也不会生效。逻辑的Port Channel 接口不需要策略配置。

14.3.4 AutoQoS SRND4

2010 年8 月，用于Catalyst 2K 和3K 交换机家族的更新版本的AutoQoS 同IOS 发布版本12.2(55)SE一起发布。此发布版本直接基于支持媒体网应用的最新QoSSRND中的建议。事实上，此版本AutoQoS的新关键字及名称正是AutoQoS-SRND4（从Solution Reference Network Design Guide Version4中取出，这是此设计章节的Cisco名称）。在线附录A中详细讨论了AutoQoS-SRND4。

14.3.5 控制层面限速

在本书写作时，Catalyst 3750 尚不支持控制层面限速。

14.4 小结

本设计章节详细介绍了作为园区网接入层交换机的Catalyst 3750 系列交换机，在QoS 设计中的最佳方案建议（另外，大部分的设计建议也同样适用于Catalyst 2K/3K 交换机家族）。

在MLS QoS 平台上部署QoS 的第一步是全局启用QoS。如果没有进行这个虽然小但是重要的步骤，所有配置的QoS命令都会处于未启用状态。

下一步是定义入向QoS策略，这可能包括信任（信任CoS、信任DSCP或Cisco设备的条件信任）、分类和标记（以及可选的限速策略）。也建议在此平台配置入向队列，因为入方向的所有带宽总和可能会超过背板/环容量。建议使用的入向队列模型是1P1Q3T。

在不考虑4条队列的硬件限制情况下，本章也（通过1P3Q3T出向队列模型）详细介绍了出向队列策略，展示了此平台上如何预设4类、8类和12类战略性模型。

本章还讨论了其他与平台相关的设计选项和注意事项，包括怎样配置每VLAN QoS 和EtherChannel QoS。AutoQoS SRND4特性也是此平台的配置选项，但在在线附录A中进行讨论。

14.5 扩展阅读

企业媒体网服务质量设计4.0:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSCampus_40.html

媒体网园区QoS设计一览:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/qoscampusaag.html

媒体网Catalyst 3560/3750 QoS设计一览:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/qoscampuscat3xxxaag.html

媒体网园区AutoQoS设计一览:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/autoqosmediacampus.pdf

Cisco Catalyst 3750-X 和Catalyst 3560-X 交换机软件配置指南，Cisco IOS 15.0(2)SE 版本——配置QoS:http://www.cisco.com/en/US/docs/switches/lan/catalyst3750x_3560x/software/release/15.0_2_se/configuration/guide/swqos.html

第15章 园区网分布层（Cisco Catalyst 4500）的QoS设计

园区网分布层交换机上的主要服务质量（QoS）角色是管理数据包丢失。因此，分布层交换机应该相信入方向的（在之前由访问边界交换机设置的）DSCP（差分服务代码点）标记，并使用入向（如果要求且支持）及出向队列，如图15-1所示。

图15-1 园区网分布层交换机端口QoS角色

Cisco Catalyst 4500E Supervisor 7-E 是适用于园区网分布层的交换机平台，本设计章节将详细介绍这个型号的设备。

作为分布层交换机的Cisco Catalyst 4500E Supervisor 7-E，它的QoS 设计需求与园区网核心交换机的需求大体一致。

15.1 Cisco Catalyst 4500 QoS架构

从QoS 的角度来看，Cisco Catalyst 4500-E Supervisor 7-E 几乎与Supervisor 6-E 平台和Catalyst 4500-X 等同，因为这些平台都是基于MQC（模块化QoS 命令行界面）的。然而，较早的Catalyst 4500平台（如Supervisor II-Plus到Supervisor V-10GE）都是基于MLS QoS平台的，也被称为Classic Supervisors。

注释:这些较老的Classic Supervisors QoS设计超出了本章的范围。然而，你可以通过以下链接找到这些平台的设计指南:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSCampus_40.html#wp1099634。

图15-2 说明了Cisco Catalyst 4500-E Supervisor 7-E（以下简称Catalyst 4500）平台的QoS架构。

图15-2 Cisco Catalyst 4500 QoS架构模型

在所有基于MQC 的平台上，QoS 是默认启用的，Catalyst 4500 也是如此。此外，所有端口默认被设置为信任DSCP/信任CoS状态。

在基于MQC 的Catalyst 4500 上，按照如下方式应用QoS 策略。

1.（基于各种数据包字段、接收端口或VLAN）将入站数据包分类到对应的流量类中。

2.根据流量类和配置的策略，对数据包执行限速，这可能会导致数据包被丢弃或重标记。

3.数据包被标记/ 重标记后，设备会查找转发数据包的路径，查找结果是得出传输数据包所需使用的传输端口或VLAN。

4.根据传输端口或VLAN标记，在输出方向上对数据包进行分类。

5.根据输出策略，对数据包执行限速，这可能会导致数据包被丢弃或重标记。

6.根据流量类和配置的出向队列策略，来决定数据包所属的传输队列。

7.通过DBL（Dynamic Buffer Limiting，动态缓存限制）和配置的丢弃门限值，来动态监控传输队列的状态，以便决定数据包是被丢弃还是入队待传。

8.如果可以进行传输，数据包会被分配到传输队列中。

基于这些QoS 操作，接下来将讨论配置分布层交换机Catalyst 4500 的设计步骤。

15.2 QoS设计步骤

分布层交换机需要明确配置两个QoS策略（即在入方向上信任DSCP和实施队列策略），因为在基于MQC 的平台上有默认的QoS 设置，在Catalyst 4500 上配置QoS 只需一步。

1.配置入向QoS 模型——建议配置为信任DSCP（此状态默认在所有基于MQC 的平台上启用）。

注释:此步骤还包括在支持入向队列策略的平台上配置出向队列策略（然而Catalyst 4500不支持此特性）。

2.配置出向队列。

15.3 队列模型

Catalyst 4500 不支持入向队列，只支持出向队列。

注释:其他入向QoS策略（包括信任、分类、标记和限速）都支持；只有入向队列不支持。

Catalyst 4500支持1条严格优先级硬件队列和（至多）7条其他的非优先级硬件队列。此外， Catalyst 4500 支持DSCP 到队列的映射。

在本书写作时，Catalyst 4500平台不支持基于DSCP的WRED（加权随机早期检测）。然而， Catalyst 4500 家族使用一种平台特定的拥塞避免算法，来提供AQM（活跃队列管理，Active Queue Management），即DBL（动态缓存限制）。DBL 会跟踪交换机中每条数据流的队列长度。当流超过了队列长度的限制时，DBL进行丢数据包或在数据包头设置ECN（显式拥塞通知， Explicit Congestion Notification）位。DBL算法能辨识“好斗”流（即未检查/非适应/非弹性的流）并更多地丢弃这些流的数据包。“好斗”流会占用大量的带宽资源和交换机缓存，导致正常流的应用程序性能下降。因此，DBL不止会促使随机“概率性丢弃”（以类似WRED的方式），也会促使“好斗流丢弃”，在启用了DBL的类上，以上两种丢包都会被计数，并可通过命令show policy-map interface 输出显示（详见例15-4）。

因此，Catalyst 4500 平台的出向队列模型可被表示为1P7Q1T+DBL。

注释:DBL是Catalyst 4500平台独有的。在本书写作时，DBL没有调整选项。

Catalyst 4500 可配置支持4 类、8 类和12 类队列模型，这将在随后章节讨论。

15.3.1 4类出向队列模型

在4类模型（如图11-3和图11-4所示）中，应用类到队列的映射如下所示。

■ 实时流量（标记为EF）被分配到优先级队列（可选择将其限速至带宽的30%）。

■ 控制流量（标记为CS3）被分配到有10%带宽分配的专用非优先级队列。

■ 业务性数据（标记为AF2）被分配到其他启用DBL且有35%带宽分配的专用非优先级队列。

■ 尽力传输流量（标记为DF）被分配到启用DBL且有25%带宽分配的默认队列。

注释:DBL只在业务性数据队列和默认队列上启用（因为永远不应该提早丢弃实时流量和控制流量）。

注释:当在一个类别的policy map中配置优先级队列，并且没有使用限速器时，其他类的配置只能使用bandwidth remaining percent命令（在优先级队列使用带宽后，为其他类提供剩余带宽中的最小带宽保障）。在使用了限速器的情况下配置优先级队列时，其他队列可以使用bandwidth percent或bandwidth remaining percent。

注释:如果要在EtherChannel接口上应用队列策略，建议不对优先级队列进行限速。因为这种情况下需要两个策略映射:一个策略映射用来限速优先级队列（需在逻辑EtherChannel接口的出方向应用）；另一个策略映射用来定义队列策略（使用bandwidth remaining percent），将在所有EtherChannel物理端口成员接口的出方向应用。因此，为简化队列策略并增加策略的可移植性及模块性，本章的队列设计示例中不对优先级队列进行限速（这就必须在非优先级队列上使用bandwidth remaining percent命令）。

注释:使用bandwidth percent或bandwidth remaining percent确实会在带宽分配上产生细微的差别。然而，因为差别相对较小，为了保持一致，在示例中将使用相同的数值。

图15-3 说明了Catalyst 4500 的4 类（1P3Q1T+DBL）出向队列模型。

例15-1 显示了Catalyst 4500 上4 类（1P3Q1T+DBL）出向队列的相应配置。

图15-3 Catalyst 4500的4类出向队列模型

例15-1 Catalyst 4500上4类（1P3Q1T+DBL）出向队列配置

! This section configures the class maps for the egress queuing policy

C4500(config)# class-map match-all PRIORITY-QUEUE

C4500(config-cmap)# match dscp ef

! VoIP (EF) is mapped to the PQ

C4500(config)# class-map match-all CONTROL-QUEUE

C4500(config-cmap)# match dscp cs3

! Signaling (CS3) is mapped to a dedicated queue

C4500(config)# class-map match-all TRANSACTIONAL-DATA-QUEUE

C4500(config-cmap)# match dscp af21 af22 af23

! Transactional Data (AF2) is mapped to a dedicated queue

! This section configures the four-class egress queuing policy map

C4500(config)# policy-map 1P3Q1T

C4500(config-pmap-c)# class PRIORITY-QUEUE

C4500(config-pmap-c)# priority

! Enables the priority queue

C4500(config-pmap-c)# class CONTROL-QUEUE

C4500(config-pmap-c)# bandwidth remaining percent 10

! Defines the control queue with 10% BW remaining

C4500(config-pmap-c)# class TRANSACTIONAL-DATA-QUEUE

C4500(config-pmap-c)# bandwidth remaining percent 35

C4500(config-pmap-c)# dbl

! Defines a transactional data queue with 35% BW remaining + DBL

C4500(config-pmap-c)# class class-default

C4500(config-pmap-c)# bandwidth remaining percent 25

C4500(config-pmap-c)# dbl

! Provisions the default/Best Effort queue with 25% BW remaining + DBL

! This section attaches the egress queuing policy to the interface(s)

C4500(config)# interface range TenGigabitEthernet 1/1-2

C4500(config-if-range)# service-policy output 1P3Q1T

注释:为出向队列策略定义的class map需要有唯一的名称，要区别其他入向策略class map的名称；否者将会因为重复的分类逻辑而产生分类错误。

可通过如下命令验证例15-1中的配置。

■ show class-map

■ show policy-map

■ show policy-map interface

15.3.2 8类出向队列模型

在8类模型（如图11-5和图11-6所示）中，应用类到队列的映射如下所示。

■ 实时流量（标记为EF）被分配到优先级队列（可选择将其限速至带宽的10%）。

■ 交互式视频（标记为AF4）被分配到启用DBL且有23%带宽分配的专用非优先级队列。

■ 流媒体视频（标记为AF3）被分配到启用DBL且有10%带宽分配的专用非优先级队列。

■ 网络控制流量（标记为CS6）被分配到有5%带宽分配的专用非优先级队列。

■ 信令流量（标记为CS3）被分配到有2%带宽分配的专用非优先级队列。

■ 业务性数据（标记为AF2）被分配到启用DBL且有24%带宽分配的专用非优先级队列。

■ 清道夫流量（标记为CS1）被限制在有1%带宽分配的专用非优先级队列。

■ 尽力而为流量（标记为DF）被分配到启用DBL且有25%带宽分配的默认队列。

注释:和之前相同，不在实时控制流量类上启用DBL（因为永远不应该提早丢弃实时或控制流量）；也不需要为清道夫类启用DBL，因为不用为这个类别提供“善意的”服务保证。在交互式视频和流媒体视频上启用DBL，这是假设这些流的视频编码器是可适应/弹性的，因此就能在发生拥塞时调整传输速率。

图15-4 说明了Catalyst 4500 的8 类（1P7Q1T+DBL）出向队列模型。

图15-4 Catalyst 4500的 8类（1P7Q1T+DBL）出向队列模型

例15-2 显示了Catalyst 4500 上8 类（1P7Q1T+DBL）出向队列的相应配置。

例15-2 Catalyst 4500上8类（1P7Q1T+DBL）出向队列配置

! This section configures the class maps for the egress queuing policy

C4500(config)# class-map match-all PRIORITY-QUEUE

C4500(config-cmap)# match dscp ef

! VoIP (EF) is mapped to the PQ

C4500(config)# class-map match-all INTERACTIVE-VIDEO-QUEUE

C4500(config-cmap)# match dscp af41 af42 af43

! Interactive-Video (AF4) is assigned a dedicated queue

C4500(config)# class-map match-all STREAMING-VIDEO-QUEUE

C4500(config-cmap)# match dscp af31 af32 af33

! Streaming-Video (AF3) is assigned a dedicated queue

C4500(config)# class-map match-all CONTROL-QUEUE

C4500(config-cmap)# match dscp cs6

! Network Control (CS6) is mapped to a dedicated queue

C4500(config)# class-map match-all SIGNALING-QUEUE

C4500(config-cmap)# match dscp cs3

! Signaling (CS3) is mapped to a dedicated queue

C4500(config)# class-map match-all TRANSACTIONAL-DATA-QUEUE

C4500(config-cmap)# match dscp af21 af22 af23

! Transactional Data (AF2) is assigned a dedicated queue

C4500(config)# class-map match-all SCAVENGER-QUEUE

C4500(config-cmap)# match dscp cs1

! Scavenger (CS1) is assigned a dedicated queue

! This section configures the 1P7Q1T+DBL egress queuing policy map

C4500(config)# policy-map 1P7Q1T

C4500(config-pmap-c)# class PRIORITY-QUEUE

C4500(config-pmap-c)# priority

! Defines a priority queue

C4500(config-pmap-c)# class INTERACTIVE-VIDEO-QUEUE

C4500(config-pmap-c)# bandwidth remaining percent 23

C4500(config-pmap-c)# dbl

! Defines a interactive-video queue with 23% BW remaining + DBL

C4500(config-pmap-c)# class STREAMING-VIDEO-QUEUE

C4500(config-pmap-c)# bandwidth remaining percent 10

C4500(config-pmap-c)# dbl

! Defines a streaming-video queue with 10% BW remaining + DBL

C4500(config-pmap-c)# class CONTROL-QUEUE

C4500(config-pmap-c)# bandwidth remaining percent 5

! Defines a control/management queue with 5% BW remaining

C4500(config-pmap-c)# class SIGNALING-QUEUE

C4500(config-pmap-c)# bandwidth remaining percent 2

! Defines a signaling queue with 2% BW remaining

C4500(config-pmap-c)# class TRANSACTIONAL-DATA-QUEUE

C4500(config-pmap-c)# bandwidth remaining percent 24

C4500(config-pmap-c)# dbl

! Defines a transactional data queue with 24% BW remaining + DBL

C4500(config-pmap-c)# class SCAVENGER-QUEUE

C4500(config-pmap-c)# bandwidth remaining percent 1

! Defines a (minimal) scavenger queue with 1% BW remaining/limit

C4500(config-pmap-c)# class class-default

C4500(config-pmap-c)# bandwidth remaining percent 25

C4500(config-pmap-c)# dbl

! Provisions the default/Best Effort queue with 25% BW remaining + DBL

! This section attaches the egress queuing policy to the interface(s)

C4500(config)# interface range TenGigabitEthernet 1/1-2

C4500(config-if-range)# service-policy output 1P7Q1T

可以通过如下命令验证例15-2中的配置。

■ show class-map

■ show policy-map

■ show policy-map interface

15.3.3 12类出向队列模型

在12类模型（如图11-7和图11-8所示）中，应用类到队列的映射如下所示。

■ 语音（标记为EF）、广播视频（标记为CS5）和实时交互流量（标记为CS4）被分配到优先级队列（可选择将其限速至带宽的30%）。

■ 多媒体会议流量（标记为AF4）被分配到启用DBL且有10%带宽分配的专用非优先级队列。

■ 多媒体流媒体流量（标记为AF3）被分配到启用DBL且有10%带宽分配的专用非优先级队列。

■ 网络控制流量（标记为CS6）、信令流量（标记为CS3）和网络管理流量（标记为CS2）全部被分配到有10%带宽分配的专用非优先级队列；可选择将CS7流量也映射到此队列。

■ 业务性数据流量（标记为AF2）被分配到启用DBL且有10%带宽分配的专用非优先级队列。

■ 大块数据流量（标记为AF1）被分配到启用DBL且有4%带宽分配的专用非优先级队列。

■ 清道夫流量（标记为CS1）被限制在有1%带宽分配的专用非优先级队列。

■ 尽力传输流量（标记为DF）被分配到启用DBL且有25%带宽分配的默认队列。

图15-5 说明了Catalyst 4500 的12 类（1P7Q1T+DBL）出向队列模型。

图15-5 Catalyst 4500 的12类（1P7Q1T+DBL）出向队列模型

例15-3 显示了Catalyst 4500 上12 类（1P7Q1T+DBL）出向队列的相应配置。

例15-3 Catalyst 4500上12类（1P7Q1T+DBL）出向队列配置

! This section configures the class maps for the egress queuing policy

C4500(config)# class-map match-any PRIORITY-QUEUE

C4500(config-cmap)# match dscp ef

C4500(config-cmap)# match dscp cs5

C4500(config-cmap)# match dscp cs4

! VoIP (EF), Broadcast Video (CS5) and Realtime Interactive (CS4)

! are all mapped to the PQ

C4500(config)# class-map match-any CONTROL-MGMT-QUEUE

C4500(config-cmap)# match dscp cs7

C4500(config-cmap)# match dscp cs6

C4500(config-cmap)# match dscp cs3

C4500(config-cmap)# match dscp cs2

! Network Control (CS7), Internetwork Control (CS6),

! Signaling (CS3) and Management (CS2) are mapped

! to a Control/Management Queue

C4500(config)# class-map match-all MULTIMEDIA-CONFERENCING-QUEUE

C4500(config-cmap)# match dscp af41 af42 af43

! Multimedia Conferencing (AF4) is assigned a dedicated queue

C4500(config)# class-map match-all MULTIMEDIA-STREAMING-QUEUE

C4500(config-cmap)# match dscp af31 af32 af33

! Multimedia Streaming (AF3) is assigned a dedicated queue

C4500(config)# class-map match-all TRANSACTIONAL-DATA-QUEUE

C4500(config-cmap)# match dscp af21 af22 af23

! Transactional Data (AF2) is assigned a dedicated queue

C4500(config)# class-map match-all BULK-DATA-QUEUE

C4500(config-cmap)# match dscp af11 af12 af13

! Bulk Data (AF1) is assigned a dedicated queue

C4500(config)# class-map match-all SCAVENGER-QUEUE

C4500(config-cmap)# match dscp cs1

! Scavenger (CS1) is assigned a dedicated queue

! This section configures the 1P7Q1T+DBL egress queuing policy map

C4500(config)# policy-map 1P7Q1T

C4500(config-pmap-c)# class PRIORITY-QUEUE

C4500(config-pmap-c)# priority

! Defines a priority queue

C4500(config-pmap-c)# class CONTROL-MGMT-QUEUE

C4500(config-pmap-c)# bandwidth remaining percent 10

! Defines a control/management queue with 10% BW remaining

C4500(config-pmap-c)# class MULTIMEDIA-CONFERENCING-QUEUE

C4500(config-pmap-c)# bandwidth remaining percent 10

C4500(config-pmap-c)# dbl

! Defines a multimedia conferencing queue with 10% BW remaining + DBL

C4500(config-pmap-c)# class MULTIMEDIA-STREAMING-QUEUE

C4500(config-pmap-c)# bandwidth remaining percent 10

C4500(config-pmap-c)# dbl

! Defines a multimedia streaming queue with 10% BW remaining + DBL

C4500(config-pmap-c)# class TRANSACTIONAL-DATA-QUEUE

C4500(config-pmap-c)# bandwidth remaining percent 10

C4500(config-pmap-c)# dbl

! Defines a transactional data queue with 10% BW remaining + DBL

C4500(config-pmap-c)# class BULK-DATA-QUEUE

C4500(config-pmap-c)# bandwidth remaining percent 4

C4500(config-pmap-c)# dbl

! Defines a bulk data queue with 10% BW remaining + DBL

C4500(config-pmap-c)# class SCAVENGER-QUEUE

C4500(config-pmap-c)# bandwidth remaining percent 1

! Defines a (minimal) scavenger queue with 1% BW remaining/limit

C4500(config-pmap-c)# class class-default

C4500(config-pmap-c)# bandwidth remaining percent 25

C4500(config-pmap-c)# dbl

! Provisions the default/Best Effort queue with 25% BW remaining + DBL

! This section attaches the egress queuing policy to the interface(s)

C4500(config)# interface range TenGigabitEthernet 1/1-2

C4500(config-if-range)# service-policy output 1P7Q1T

可以通过如下命令验证例15-3中的配置。

■ show class-map

■ show policy-map

■ show policy-map interface（详见例15-4）

例15-4 在Catalyst 4500上验证队列策略:show policy-map interface

C4500# show policy-map interface TenGigabitEthernet 1/1

TenGigabitEthernet1/1

Service-policy output:1P7Q1T

Class-map:PRIORITY-QUEUE (match-any)

102598 packets

Match:dscp ef (46)

102598 packets

Match:dscp cs5 (40)

0 packets

Match:dscp cs4 (32)

0 packets

priority queue:

Transmit:22782306 Bytes, Queue Full Drops:0 Packets

Class-map:CONTROL-MGMT-QUEUE (match-any)

24847 packets

Match:dscp cs7 (56)

0 packets

Match:dscp cs6 (48)

0 packets

Match:dscp cs3 (24)

24847 packets

Match:dscp cs2 (16)

0 packets

bandwidth remaining 10 (%)

Transmit:24909844 Bytes, Queue Full Drops:0 Packets

Class-map:MULTIMEDIA-CONFERENCING-QUEUE (match-all)

22280511 packets

Match:dscp af41 (34) af42 (36) af43 (38)

bandwidth remaining 10 (%)

Transmit:4002626800 Bytes, Queue Full Drops:0 Packets dbl

Probabilistic Drops:0 Packets

Belligerent Flow Drops:0 Packets

Class-map:MULTIMEDIA-STREAMING-QUEUE (match-all)

0 packets

Match:dscp af31 (26) af32 (28) af33 (30)

bandwidth remaining 10 (%)

Transmit:0 Bytes, Queue Full Drops:0 Packets

dbl

Probabilistic Drops:0 Packets

Belligerent Flow Drops:0 Packets

Class-map:TRANSACTIONAL-DATA-QUEUE (match-all)

235852 packets

Match:dscp af21 (18) af22 (20) af23 (22)

bandwidth remaining 10 (%)

Transmit:247591260 Bytes, Queue Full Drops:0 Packets dbl

Probabilistic Drops:0 Packets

Belligerent Flow Drops:0 Packets

Class-map:BULK-DATA-QUEUE (match-all)

2359020 packets

Match:dscp af11 (10) af12 (12) af13 (14)

bandwidth remaining 4 (%)

Transmit:2476460700 Bytes, Queue Full Drops:0 Packets dbl

Probabilistic Drops:0 Packets

Belligerent Flow Drops:0 Packets

Class-map:SCAVENGER-QUEUE (match-all)

78607323 packets

Match:dscp cs1 (8)

bandwidth remaining 1 (%)

Transmit:98144078642 Bytes, Queue Full Drops:26268 Packets

Class-map:class-default (match-any)

12388183 packets

Match:any

12388183 packets

bandwidth remaining 25 (%)

Transmit:13001465825 Bytes, Queue Full Drops:0 Packets

dbl

Probabilistic Drops:0 Packets

Belligerent Flow Drops:0 Packets

C4500#

例15-4显示了多个队列类及它们相关的数据包和字节计数，包括清道夫队列上的26,268次队列丢弃。

15.4 与平台相关的其他QoS设计选项

上述的设计代表了园区网分布层中Catalyst 4500 QoS 的一些通用的设计选项。但它们不是唯一可用的设计选项。其他选项如下所示:

■ 访问边界设计选项；

■ 基于VLAN的QoS设计；

■ 每端口/每VLAN的QoS设计；

■ EtherChannel QoS 设计；

■ AutoQoS SRND4；

■ 控制层面限速。

每个设计选项都将相继讨论。

15.4.1 访问边界设计选项

本章着重介绍园区网分布层交换机Catalyst 4500 的QoS 设计（通常与园区网核心层使用的Catalyst 4500QoS设计等同）。然而，Catalyst 4500也可作为园区网接入层交换机使用。因此，其作为接入层交换机有一些其他的设计选项，包括下列访问边界模型:

■ 条件信任模型；

■ 分类和标记模型；

■ 分类、标记和限速模型。

每个访问边界设计选项都将相继介绍。

1.条件信任模型

就像之前提到的，基于MQC的平台默认信任二层和三层标记，因此也就不需要明确的命令来执行这种功能了。所以就没有（也不需要）与mls qos trust cos 或mls qos trust dscp 等同的命令。

然而，有必要为所有可能部署为接入层交换机的交换机平台提供条件信任的功能。在Catalyst 4500 上就有对应的条件信任命令（即qos trust device）。

在本书写作时，Catalyst 4500 支持以下设备的条件信任:

■ Cisco IP 电话通过cisco-phone 关键字选项配置；

■ Cisco TelePresence 系统通过cts 关键字选项配置；

■ Cisco IP 视频监控摄像头系统通过ip-camera 关键字选项配置；

■ Cisco Digital Media Players 通过media-player 关键字选项配置。

当把条件信任扩展到Cisco IP 电话时，需注意这只能（在PC 产生的流量上）重标记CoS位。因此，在Catalyst 4500 上配置条件信任模型时，要求在端口上应用动态的条件信任策略，并使用简单的MQC 策略来明确匹配CoS 5（语音）和CoS 3（信令）流量，并将这些数据包的DSCP值分别标记为EF和CS3（实质上也就是执行CoS到DSCP的映射）。例15-5显示了Catalyst 4500 的条件信任模型。

例15-5 在Catalyst 4500上为Cisco IP电话配置（基于CoS的）条件信任

! This section defines the class maps to match Voice and Signaling

C4500(config-cmap)# class-map match-all VOICE

C4500(config-cmap)# match cos 5

C4500(config-cmap)# class-map match-all SIGNALING

C4500(config-cmap)# match cos 3

! This section defines the CoS-to-DSCP re-marking policy map

C4500(config-cmap)# policy-map CISCO-IPPHONE

C4500(config-pmap)# class VOICE

C4500(config-pmap-c)# set dscp ef

! Maps CoS 5 to DSCP EF

C4500(config-pmap-c)# class SIGNALING

C4500(config-pmap-c)# set dscp cs3

! Maps CoS 3 to DSCP CS3

C4500(config-pmap-c)# class class-default

C4500(config-pmap-c)# set dscp default

! All other traffic is set to DSCP DF

! This section applies conditional trust and policy map to the int(s)

C4500(config)# interface GigabitEthernet 3/1

C4500(config-if)# switchport access vlan 10

C4500(config-if)# switchport voice vlan 110

C4500(config-if)# spanning-tree portfast

C4500(config-if)# qos trust device cisco-phone

! Applies conditional-trust to the switch port

C4500(config-if)# service-policy input CISCO-IPPHONE

! Attaches the CoS-to-DSCP mapping policy map

可以通过如下命令验证例15-5中的配置。

■ show qos interface

■ show class-map

■ show policy-map

■ show policy-map interface

2.媒体网元数据分类模型

在Cisco IOS XE 3.3.0SG 和IOS 15.1(1)SG 上，可以通过元数据过滤器来配置class map。包含这些类的QoS策略被称为基于元数据的QoS策略。这允许用户轻松使用元数据属性来对数据流进行分类，而无需根据访问控制列表（ACL）的分类原则（如源/目的地址/端口等）来分类数据流。

在Catalyst 4500 系列交换机上使用基于元数据的QoS 策略时，有以下限定:

■ 只能关联在输入方向的目标上；

■ 只能关联在物理端口或EtherChannel端口信道接口上，不能关联在VLAN、端口VLAN及交换机虚接口（SVI）上；

■ 一条策略可以有多个基于元数据的分类器；

■ 通过match-any 或match-all 语句，可以为一个class map 配置一个或多个元数据过滤器；

■ 与元数据类相关的策略行为是应用在聚合流量上的；然而，如果元数据同Flexible NetFlow记录过滤器一同配置，策略行为（如限速器）则应用在独立的流上。

注释:基于流的QoS策略和Flexible NetFlow（FNF）将在后续章节介绍。

例15-6说明了一个具有两个类、使用元数据过滤器的基于元数据的QoS策略。

例15-6 Catalyst 4500上的媒体网元数据分类策略示例

! This section configures the medianet metadata class maps

C4500(config-cmap)# class-map match-all REALTIME-INTERACTIVE

C4500(config-cmap)# match application telepresence-media

! Identifies TelePresence media flows via metadata

C4500(config-cmap)# class-map match-any MULTIMEDIA-CONFERENCING

C4500(config-cmap)# match application webex-video

! Identifies WebEx video flows via metadata

C4500(config-cmap)# match application webex-voice

! Identifies WebEx voice flows via metadata

可通过如下命令验证例15-6中的配置。

■ show class-map

■ show policy-map

■ show policy-map interface

3.分类和标记模型

在许多情况下，要想区分端到端QoS战略性模型要求的所有流量类型，信任模型可能不可用或不够用。因此，可能需要在访问边界上明确配置分类和标记策略。

例15-7显示了基于图11-5（8类QoS模型）的配置示例。

注释:如前章所述，不是所有的应用类都会出现在访问边界的入方向上。例如，流媒体视频流量就不太可能出现在访问边界的入方向上（因为这些流不是从园区网终端设备发出的，但可能会发往这些终端设备），网络控制流也不会从园区网终端设备发出。因此，访问边界的分类和标记policy map中并不需要包括这些类。

注释:为简洁起见，略去了策略示例中的访问控制列表。

例15-7 Catalyst 4500上的分类和标记策略

! This section configures the class maps

C4500(config-cmap)# class-map match-all VOICE

C4500(config-cmap)# match dscp ef

! Voice is matched on DSCP EF

C4500(config-cmap)# class-map match-all INTERACTIVE-VIDEO

C4500(config-cmap)# match access-group name INTERACTIVE-VIDEO

! Associates INTERACTIVE-VIDEO access-list with class map

C4500(config-cmap)# class-map match-all SIGNALING

C4500(config-cmap)# match cs3

! Signaling is matched on DSCP CS3

C4500(config-cmap)# class-map match-all TRANSACTIONAL-DATA

C4500(config-cmap)# match access-group name TRANSACTIONAL-DATA

! Associates TRANSACTIONAL-DATA access-list with class map

C4500(config-cmap)# class-map match-all SCAVENGER

C4500(config-cmap)# match access-group name SCAVENGER

! Associates SCAVENGER access-list with class map

! This section configures the Per-Port ingress marking policy map

C4500(config-cmap)# policy-map PER-PORT-MARKING

C4500(config-pmap)# class VOICE

C4500(config-pmap-c)# set dscp ef

! VoIP is marked EF

C4500(config-pmap-c)# class INTERACTIVE-VIDEO

C4500(config-pmap-c)# set dscp af41

! Interactive-Video is marked AF41

C4500(config-pmap-c)# class SIGNALING

C4500(config-pmap-c)# set dscp cs3

! Signaling is marked CS3

C4500(config-pmap-c)# class TRANSACTIONAL-DATA

C4500(config-pmap-c)# set dscp af21

! Transactional Data is marked AF21

C4500(config-pmap-c)# class SCAVENGER

C4500(config-pmap-c)# set dscp cs1

! Scavenger traffic is marked CS1

C4500(config-pmap-c)# class class-default

C4500(config-pmap-c)# set dscp default

! All other traffic is marked DF

! This section attaches the service-policy to the interface(s)

C4500(config)# interface range GigabitEthernet 2/1-48

C4500(config-if-range)# switchport access vlan 10

C4500(config-if-range)# switchport voice vlan 110

C4500(config-if-range)# spanning-tree portfast

C4500(config-if-range)# qos trust device cisco-phone

! The interface is set to conditionally trust Cisco IP Phones

C4500(config-if-range)# service-policy input PER-PORT-MARKING

! Attaches the Per-Port Marking policy to the interface(s)

可以通过如下命令验证例15-7中的配置。

■ show qos interface

■ show class-map

■ show policy-map

■ show policy-map interface

4.分类、标记和限速模型

除了分类和标记，访问边界可能也需要实施限速。Catalyst 4500 可进行单速率（双色）限速和三色限速——通过使用RFC 2697 srTCM（单速率三色标记器）或RFC 2698 trTCM（双速率三色标记器）。例15-8显示了Catalyst 4500上基于端口的单速率限速示例（基于图13-8），例15-9 显示了用于支持RFC 2698 的双速率三色标记器的策略修订。

例15-8 Catalyst 4500上的（单速率双色）基于端口限速配置示例

! This section configures the single-rate per-port policing policy map

C4500(config)# policy-map PER-PORT-POLICING

C4500(config-pmap)# class VVLAN-VOIP

C4500(config-pmap-c)# set dscp ef

C4500(config-pmap-c)# police 128k bc 8000

C4500(config-pmap-c-police)# conform-action transmit

C4500(config-pmap-c-police)# exceed-action drop

! VoIP is marked EF and policed to drop at 128 kbps

C4500(config-pmap)# class VVLAN-SIGNALING

C4500(config-pmap-c)# set dscp cs3

C4500(config-pmap-c)# police 32k bc 8000

C4500(config-pmap-c-police)# conform-action transmit

C4500(config-pmap-c-police)# exceed-action drop

! (VVLAN) Signaling is marked CS3 and policed to drop at 32 Kbps

C4500(config-pmap)# class MULTIMEDIA-CONFERENCING

C4500(config-pmap-c)# set dscp af41

C4500(config-pmap-c)# police 5m bc 8000

C4500(config-pmap-c-police)# conform-action transmit

C4500(config-pmap-c-police)# exceed-action drop

! Multimedia-conferencing is marked AF41 and policed to drop at 5 Mbps

C4500(config-pmap)# class SIGNALING

C4500(config-pmap-c)# set dscp cs3

C4500(config-pmap-c)# police 32k bc 8000

C4500(config-pmap-c-police)# conform-action transmit

C4500(config-pmap-c-police)# exceed-action drop

! (DVLAN) Signaling is marked CS3 and policed to drop at 32 Kbps

C4500(config-pmap)# class TRANSACTIONAL-DATA

C4500(config-pmap-c)# set dscp af21

C4500(config-pmap-c)# police 10m bc 8000

C4500(config-pmap-c-police)# conform-action transmit

C4500(config-pmap-c-police)# exceed-action set-dscp-transmit af22

! Trans-data is marked AF21 and policed to re-mark (to AF22) at 10 Mbps

C4500(config-pmap)# class BULK-DATA

C4500(config-pmap-c)# set dscp af11

C4500(config-pmap-c)# police 10m bc 8000

C4500(config-pmap-c-police)# conform-action transmit

C4500(config-pmap-c-police)# exceed-action set-dscp-transmit af12

! Bulk-data is marked AF11 and policed to re-mark (to AF12) at 10 Mbps

C4500(config-pmap)# class SCAVENGER

C4500(config-pmap-c)# set dscp cs1

C4500(config-pmap-c)# police 10m bc 8000

C4500(config-pmap-c-police)# conform-action transmit

C4500(config-pmap-c-police)# exceed-action drop

! Scavenger traffic is marked CS1 and policed to drop at 10 Mbps

C4500(config-pmap)# class class-default

C4500(config-pmap-c)# set dscp default

C4500(config-pmap-c)# police 10m bc 8000

C4500(config-pmap-c-police)# conform-action transmit

C4500(config-pmap-c-police)# exceed-action set-dscp-transmit cs1

! The implicit default class marks all other traffic to DF

! and polices all other traffic to re-mark (to CS1) at 10 Mbps

! This section attaches the service-policy to the interface(s)

C4500(config)# interface range GigabitEthernet 2/1-48

C4500(config-if-range)# switchport access vlan 10

C4500(config-if-range)# switchport voice vlan 110

C4500(config-if-range)# spanning-tree portfast

C4500(config-if-range)# qos trust device cisco-phone

! The interface is set to conditionally trust Cisco IP phones

C4500(config-if-range)# service-policy input PER-PORT-POLICING

! Attaches the Per-Port Policing policy to the interface(s)

注释:如例15-8所示，Catalyst 4500的IOS允许通过输入后缀k（千比特）、m（兆比特）、g（吉比特）来设置限速速率。此外，还可将十进制小数点与这些后缀一同使用。例如，10.5Mbit/s的速率可以通过policy map命令police 10.5m来输入。虽然在配置中，这些限速速率都会转换为比特每秒的完整数值，但这种方法让输入这些速率更加方便且不容易出错（否则可能需要输入10个0来定义限速速率）。

可通过如下命令验证例15-8中的配置。

■ show qos interface

■ show class-map

■ show policy-map

■ show policy-map interface

为避免重复，例15-9将一个类（大块数据类）上的限速器由单速率双色标记器修改并扩展为双速率三色标记器。可以在任意的AF（确认转发）类流量上进行相似的修改。

例15-9 Catalyst 4500上的（双速率三色速率双色）基于端口限速配置示例

! This section configures a dual-rate per-port policing policy map

C4500(config)# policy-map TWO-RATE-POLICER

<snip>

C4500(config-pmap)# class BULK-DATA

C4500(config-pmap-c)# set dscp af11

C4500(config-pmap-c)# police 10m bc 8000 pir 15m

! Bulk-data is policed to 10 Mbps rate and 15 Mbps peak rate

C4500(config-pmap-c-police)# conform-action set-dscp-transmit af11

! Bulk data under 10 Mbps will be marked AF11

C4500(config-pmap-c-police)# exceed-action set-dscp-transmit af12

! Bulk data traffic between 10 Mbps and 15 Mbps will be marked AF12

C4500(config-pmap-c-police)# violate-action set-dscp-transmit af13

! Bulk data traffic over 15Mbps will be marked AF13

可通过如下命令验证例15-9中的配置。

■ show qos interface

■ show class-map

■ show policy-map

■ show policy-map interface

15.4.2 每VLAN QoS设计

Catalyst 4500 支持基于VLAN 的QoS。然而，不像Catalyst 3750，Catalyst 4500 并不支持接口命令mls qos vlan-based。此外，service policy是通过VLAN配置模式（而不是接口配置模式）关联到VLAN上的，如例15-10所示。

例15-10 Catalyst 4500上基于VLAN的标记配置示例

! This section configures the interface(s) for conditional trust,

C4500(config)# interface range GigabitEthernet 2/1-48

C4500(config-if-range)# switchport access vlan 10

C4500(config-if-range)# switchport voice vlan 110

C4500(config-if-range)# spanning-tree portfast

C4500(config-if-range)# qos trust device cisco-phone

! The interface is set to conditionally trust Cisco IP phones

! This section attaches a marking policy to the DVLAN

C4500(config)# vlan config 10

C4500(config-vlan-config)# service-policy input DVLAN-MARKING

! This section attaches a marking policy to the VVLAN

C4500(config)# vlan config 110

C4500(config-vlan-config)# service-policy input VVLAN-MARKING

可通过如下命令验证例15-10中的配置。

■ show qos interface

■ show class-map

■ show policy-map

■ show policy-map vlan vlan-number（此命令几乎与show policy map interface命令等同，除了它直接引用VLAN而不是VLAN接口）

注释:不建议基于VLAN部署限速策略，随后章节中将深入讨论。

15.4.3 每端口/每VLAN QoS

虽然从技术上讲，可以在每VLAN的基础上应用（聚合的）限速策略，但并不建议这样做。这是因为在特定VLAN中，终端设备的数量是动态变化的，然而在聚合层面的限速速率却是静态固定的，这就会导致每个终端设备的带宽分配不可预测。

然而，Catalyst 4500 平台上也有一种更灵活且更独立的限速策略部署方式——基于每端口/每VLAN进行部署。在Catalyst 4500上部署每端口/每VLAN策略的配置语法非常简洁，如下:在（Trunk）交换机端口的配置模式中，通过Trunk端口传输的每个VLAN都能有独立的策略，可通过interface-vlan配置模式设置，如例15-11所示。

例15-11 Catalyst 4500上每端口/每VLAN限速配置示例

! This section attaches the policy to the VLANs on a per-port basis

C4500(config)# interface range GigabitEthernet 2/1-48

C4500(config-if-range)# switchport access vlan 10

C4500(config-if-range)# switchport voice vlan 110

C4500(config-if-range)# spanning-tree portfast

C4500(config-if-range)# qos trust device cisco-phone

! The interface is set to conditionally trust Cisco IP phones

C4500(config-if-range)# vlan 10

C4500(config-if-vlan-range)# service-policy input DVLAN-POLICERS

! Attaches the per-port/per-VLAN DVLAN policing policy to the

! DVLAN of the trunked switch port(s)

C4500(config-if-range)# vlan 110

C4500(config-if-vlan-range)# service-policy input VVLAN-POLICERS

! Attaches the per-port/per-VLAN VVLAN policing policy to the

! VVLAN of the trunked switch port(s)

可通过如下命令验证例15-11中的配置。

■ show qos interface

■ show class-map

■ show policy-map

■ show policy-map interface

■ show policy-map interface interface x/y vlan vlan-number

15.4.4 EtherChannel QoS设计

在Catalyst 4500 上部署QoS service policy 时，适用以下规则:

■ 在逻辑端口信道接口上应用分类、标记和限速策略（无论入向或出向）；

■ 在物理端口成员接口上应用队列策略。

对于Catalyst 4500 上配置的EtherChannel 接口来说，入向QoS 策略（包括分类、标记和限速策略）是通过MQC service-policy 命令（在入方向使用input 关键字）关联在逻辑端口信道接口上的。因为基于MQC的平台默认有信任设置，所以不需要配置信任命令。

此外，Catalyst 4500 的出向QoS 策略（包括标记/ 限速策略）可类似地通过MQC service-policy命令（在出方向使用output关键字）关联在逻辑端口信道接口上的。

然而，出向队列策略是通过MQC service-policy 命令（在出方向使用output 关键字）关联在物理端口成员接口上的，如例15-12所示。

例15-12 Catalyst 4500上的EtherChannel QoS设计

! This section configures the logical port channel interface

C4500(config)# interface Port-channel1

C4500(config-if)# description ETHERCHANNEL-LOGICAL-INTERFACE

C4500(config-if)# switchport mode trunk

C4500(config-if)# switchport trunk encapsulation dot1q

C4500(config-if)# switchport trunk allowed vlan 10,110

C4500(config-if)# service-policy input MARKING

! This section configures 1P3Q1T+DBL queuing on physical port-member interfaces

C4500(config)# interface range TenGigabitEthernet1/1-2

C4500(config-if-range)# description PORT-CHANNEL1-PORT-MEMBER

C4500(config-if-range)# switchport mode trunk

C4500(config-if-range)# switchport trunk encapsulation dot1q

C4500(config-if-range)# switchport trunk allowed vlan 10,110

C4500(config-if-range)# channel-group 1 mode auto

C4500(config-if-range)# service-policy output 1P7Q1T-QUEUING

! Applies 1P7Q1T+DBL-QUEUING queuing policy to physical port member

可通过如下命令验证例15-12中的配置。

■ show class-map

■ show policy-map

■ show policy-map interface

注释:如前所述，只有当没有为优先级队列明确配置限速的情况下，队列策略才会关联到EtherChannel端口成员物理接口上。如果要对优先级队列进行限速，就需要构建独立的policy map，并将其关联到逻辑EtherChannel接口的出方向上。

15.4.5 基于流的QoS

设备可以通过基于流的QoS来实施微流限速和标记能力，从而动态地感知流量，并能够为每条流提供独立速率。Catalyst 4500 系列交换机支持基于流的QoS，因为Catalyst 4500 有内置的NetFlow 硬件来提供支持。通过由Flexible NetFlow（FNF）定义的流掩码，将基于流的QoS应用在交换或路由接口的入向流量上。在要求针对每用户执行细粒度的速率限制时，常使用基于流的QoS。基于流的QoS也称为基于用户的速率限制（UBRL）。

流定义的是一连串数据包，当使用FNF流记录中的关键字段来定义这些数据包时，这些数据包拥有相同的属性。当数据包关键字段中的数值与现存的其他流不同时，就创建了新的流。

基于流的QoS 策略由一个或多个与FNF 流记录匹配的class map 构成。这样的class map必须被配置为match-all，来匹配class map 指定的所有规则。当基于流的QoS 策略被关联到一个QoS 目标时，目标的入向流量会首先基于class map 中指定的分类规则被分类。如果分类器使用FNF流记录，在流不存在的情况下，分类器会使用FNF流记录中指定的关键字段来创建新的分类流量。随后将在这些独立的流上应用相应的策略行为（限速和标记）。基于流的限速器（称为微流限速器）会对每一个唯一的流进行速率限制。流是动态创建的，并且设备会定期地将不活跃的流标记为过期。

可基于每端口、每端口/每VLAN来应用基于流的QoS，也可在EtherChannel端口信道接口（入方向）应用基于流的QoS。因此，既可在接入层部署基于流的QoS，也可在分布层部署（此时UBRL将很有价值）。

需要注意的是，基于流的策略将应用到与特定类中匹配的所有流上。例如，如果在默认类上应用了一个基于流的限速器，且在端口或VLAN上关联了这一策略，所有从该端口或VLAN发出的流都将由限速器进行处理。如果这不是你配置的本意，建议进行额外的分类，并有选择地应用基于流的限速器。

例15-13显示了在基于用户的速率限制情境中，怎样配置使用微流限速的基于流的QoS策略。要求将从192.168.10.*子网发出的任意流限速至1Mbit/s。

例15-13 在Catalyst 4500上配置基于流的QoS（UBRL）

! This section defines an ACL to match traffic from subnet

C4500(config)# ip access-list extended USERGROUP-1

C4500(config-ext-nacl)# permit ip 192.168.10.0 0.0.0.255 any

! Traffic sourced from the 1922.168.10.x subnet is matched

! This section defines a flow record with source address as key

C4500(config)# flow record FLOW-RECORD-1

C4500(config-flow-record)# match ipv4 source address

! Source address is defined as the key tuple

! This section defines the class map to match on USERGROUP-1 ACL

! and specify FLOW-RECORD-1 definition for flow creation

C4500(config)# class-map match-all USER-GROUP-1

C4500(config-cmap)# match access-group name USERGROUP-1

C4500(config-cmap)# match flow record FLOW-RECORD-1

! A "match-all" class map binds the ACL and flow-record

! to identify unique flows

! This section defines the microflow policer policy map

C4500(config)# policy-map 1MBS-MICROFLOW-POLICER

C4500(config-pmap)# class USER-GROUP-1

C4500(config-pmap-c)# police cir 1m

C4500(config-pmap-c-police)# conform-action transmit

C4500(config-pmap-c-police)# exceed-action drop

! Specifies each discrete microflow is to be limited to 1Mbs

! This section applies the microflow policer to the interface

C4500(config)# interface gigabitEthernet3/1

C4500(config-if)# service-policy input 1MBS-MICROFLOW-POLICER

可通过如下命令验证例15-13中的配置。

■ show flow record（见例15-14）

■ show class-map

■ show policy-map

■ show policy-map interface

例15-14 在Catalyst 4500上配置基于流的QoS:show flow record

C4500# show flow record

flow record FLOW-RECORD-1:

Description:　　User defined

No.of users:　　1

Total field space:　4 bytes

Fields:

match ipv4 source address

15.4.6 AutoQoS SRND4

CiscoCatalyst4500从CiscoIOSXE3.3.0SG和IOS15.1(1)SG版本开始支持AutoQoSSRND4，详见在线附录A。

15.4.7 控制层面限速

Catalyst 4500 支持控制层面限速（CPP），详见在线附录B。

15.5 小结

本设计章节主要讨论了园区网分布层Cisco Catalyst 4500 (Supervisor 6-E/7-E) 系列交换机的最佳QoS方案设计建议（这与将该系列交换机用于园区网核心层时的QoS设计要求等同）。

因为Catalyst 4500 是基于MQC QoS 平台的，QoS 是默认启用的，DSCP 信任也默认在所有端口上启用。因此，在分布层交换机Catalyst 4500 上配置QoS 只需要一个步骤:配置出向队列策略。

至此，本章介绍了灵活应用Catalyst 4500 的1P7Q1T+DBL 硬件队列，并与相应配置和验证示例一起，详细介绍了4类、8类和12类队列策略。

本章还讨论了其他与平台有关的设计选项和注意事项，包括怎样将Catalyst 4500 部署为访问边界交换机，以及怎样配置每VLANQoS、每端口/ 每VLANQoS 和EtherChannel QoS 设计。

Catalyst 4500 支持AutoQoS SRND4，详见在线附录A；类似地，Catalyst 4500 也支持CPP，详见在线附录B。

15.6 扩展阅读

企业媒体网服务质量设计4.0:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSCampus_40.html

媒体网园区QoS设计一览:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/qoscampusaag.html

媒体网Catalyst 4500 QoS 设计一览:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/qoscampuscat4500aag.html

Cisco Catalyst 4500 系列交换机软件配置指南，IOS XE 3.3.0SG 和 IOS 15.1(1)SG—QoS配置指南:http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/15.1/XE_330SG/configuration/guide/qos_mrg.html

第16章 园区网核心层（Cisco Catalyst 6500）的QoS设计

园区网核心层交换机主要的服务质量（QoS）角色是管理数据包丢失。因此，核心层交换机应该信任入方向上的DSCP（差分服务代码点）标记（因为这些标记是由之前的接入边界交换机设置的），并在入向和出向上进行队列操作，如图16-1所示。

图16-1 园区网核心层交换机端口QoS角色

Cisco Catalyst 6500 Supervisor 2T 适用于园区网核心层，本章将详述其特性。

注释:本章的设计建议应用于Supervisor 2T 系统，不针对特定的Catalyst 6500 系列或Catalyst 6800系列设备。

Catalyst 6500 Supervisor 2T（以下简称Catalyst 6500）作为核心层交换机的QoS 设计需求与其作为园区网分布层交换机时大体等同。

16.1 Cisco Catalyst 6500 QoS架构

Catalyst 6500 上的QoS 同时运行在集中化的PFC（Policy Feature Card，策略特性卡）和独立的模块化线卡上。Catalyst 6500 Supervisor 2T 使用第四代PFC（PFC4）。基于PFC4 的线卡对QoS的操作过程可被分为三步，每一步发生在系统中不同的点上。图16-2说明了这三个步骤。

图16-2 Cisco Catalyst 6500基于PFC4线卡的QoS处理

1.在入向线卡端口执行入向QoS；入向QoS功能包括输入队列调度和拥塞避免。

2.在 PFC4 上执行集中化的 QoS；集中化的 QoS 功能包括端口信任、标记、分类、QoS ACL（接入控制列表）和限速。

3.在出向线卡端口执行出向QoS；出向QoS 功能包括队列调度、拥塞避免和（有些线卡可以提供）整形。

此外，前几代PFC的限制之一是做出决定需要多个周期，这就增加了整体转发过程中的延迟。PFC4尽管仍需一步一步地经过三层和三层组件的处理，但它能够一次性做出大部分决策。执行三层和QoS功能的组件以流水线模式实现，流水线的每一阶段执行一个特定的任务。IFE （Input Forwarding Engine，输入转发引擎）和OFE（Output Forwarding Engine，输出转发引擎）这两个逻辑流水线构成了物理的流水线，如图16-3所示。

图16-3 Cisco Catalyst 6500 IFE和OFE操作流程

除了扩展了功能并提高了操作效率之外，PFC4与之前几代相比，其关键优势是能够支持C3PL（Cisco 通用分类策略语言）配置。这是一种独立于平台的语法，能使MLS QoS 命令看起来更像MQC命令。

举例来说，由于端口ASIC上的队列实施有所不同，在基于PFC3的Catalyst 6500系统上，通过MQC只能配置标记和限速。队列的配置与平台和端口有关。不过PFC4通过支持C3PL消除了这些限制，C3PL是一种受策略驱动的CLI语法，支持标记、限速和队列。因此，要想将一致的队列策略应用到多个端口/接口上时，C3PL极大地简化了最终的QoS配置（因为每个接口只要简单地配置一对service-policy命令，来启用入向和出向队列策略即可，而不需在每个接口上配置几十行的队列策略）。

通过支持C3PL，也影响了PFC4的默认QoS行为。PFC4上默认QoS行为的主要变化（与之前几代PFC相比）大体上总结如下:

■ 默认启用QoS（无需像之前版本的supervisors 一样通过全局命令mls qos 明确启用QoS）；

■ 接口的QoS 总是通过与接口相关联的service policy 来定义的；

■ 默认情况下，数据包通过交换机时，二层数据包或使用二层分类的三层数据包的DSCP、EXP或CoS都保持不变（在之前版本的supervisors上，一旦全局启用了QoS，所有的端口都会被设置为不可信状态）；

■ service policy 标记不依赖于端口的信任状态；

■ 默认情况下，禁用端口级的QoS，端口级的入向队列调度机制和拥塞避免机制都是基于CoS的。

注释:基于PFC3的全局命令mls qos被全局命令auto qos default代替，这条命令用于在端口级别（而不在PFC级别）启用QoS。请勿把此命令与之前讨论过的AutoQoS特性的命令混淆；（在本书写作时）Catalyst 6500不支持媒体网络AutoQoS。

此外，在Catalyst 6500 Supervisor 2T 上，端口的信任状态是定义在PFC4/DFC4 中的，而不是从端口ASIC中获得。三层转发逻辑将会分配6比特的丢弃类别值（第13章中内部DSCP的别名）。这个6比特的丢弃类别值是在交换机内部，只用于进行QoS操作的内部标记。

关于标记，PFC4的行为中有以下重要的改变:

■ 通过C3PL表映射语法定义QoS全局映射；

■ DSCP值默认被保留，并且独立于端口状态；

■ 二层数据包的CoS值默认被保留，并且独立于端口状态；

■ 端口trust dscp 命令被去除。

因此，PFC4在不重写IP数据包的基础上，提供了为数据包划分优先级的能力，可基于策略类别对其进行控制，这也被称为DSCP透传。

16.2 QoS设计步骤

如图16-1所示，核心层交换机有三项QoS策略需求:

■ 入方向上信任DSCP；

■ 入方向上进行队列操作；

■ 出方向上进行队列操作。

然而，因为PFC4有默认的C3PL行为（默认情况下信任DSCP），所以配置园区网核心层的Catalyst 6500 实际上只有两个步骤:

■ 配置入向队列；

■ 配置出向队列。

16.3 队列模型

Catalyst 6500 支持入向和出向队列模型，这因Supervisor 和线卡而异，总结如表16-1 到表16-4所示。

表16-1 Cisco 6500 Supervisor引擎模块QoS队列结构

表16-2 Cisco 6500 40-Gigabit以太网模块QoS队列结构

表16-3 Cisco 6500 10-Gigabit以太网模块QoS队列结构

续表

表16-4 Cisco 6500 10/100/1000 以太网模块QoS队列结构

这些Supervisors和线卡（除了GE和10/100/1000线卡，这些很少在园区网核心层中使用）之中最常见的队列结构是为入向应用8Q4T，为出向应用1P7Q4T。后续章节将讨论怎样调整这些常见的队列结构，使其应用在本书中展示过的4类、8类和12类QoS模型中。

因为C3PL的队列配置语法和MQC相似，不是每个队列都需要定义和预设。换句话说，虽然有8个硬件队列可用，一个4类QoS模型只需要定义4个队列。

此外，因为入向队列的数量刚好和出向队列的数量相同，同时配置入向和出向策略会更高效，对于每个队列policy map，可使用/ 重用class map，如随后的配置示例所示。

16.3.1 4类（4Q4T入向和1P3Q4T出向）队列模型

在（图11-3和图11-4所示的）4类模型中，应用类到队列的映射如下所示。

■ 实时流量（标记为EF）被分配到实时队列，实时队列在入向4Q4T模型中分配30%的带宽，在出向1P3Q4T模型中启用严格优先级队列。

■ 控制流量（标记为CS3）被分配到有10%的带宽/剩余带宽分配的专用非优先级队列。

■ 业务性数据（标记为AF2）被分配到有35%带宽/剩余带宽分配，并启用基于DSCP的WRED的专用非优先级队列。

■ 尽力传输流量（标记为DF）被分配到启用WRED的默认队列（有隐含分配的至少25%的带宽）。

注释:只在业务性数据队列和默认队列上启用WRED（因为永远不该提早丢弃实时流量和控制流量）。

注释:将policy map中的一个类配置为优先级队列时，其他类只能使用bandwidth remaining percent命令（在使用优先级队列后，为其他类保证剩余带宽中的最小带宽分配）。

注释:使用bandwidth percent或bandwidth remaining percent确实会在带宽分配上产生细微的差别。然而，因为差别相对较小，为了保持一致，在随后的示例中将使用相同的数值。可以改变这些值，让分配的带宽保持匹配。

图16-4 显示了Catalyst 6500 的4 类（4Q4T 入向和1P3Q4T 出向）队列模型。

图16-4 Catalyst 6500的4类（4Q4T入向和1P3Q4T出向）队列模型示例

例16-1 显示了Catalyst 6500 上对应的4 类（4Q4T 入向和1P3Q4T 出向）队列模型配置。

例16-1 Catalyst 6500上4类（4Q4T入向和1P3Q4T出向）队列模型配置示例

! This section configures the class maps for the queuing policy maps

! Note both ingress and egress policy maps share these common class maps

C6500(config-cmap)# class-map type lan-queuing REALTIME-QUEUE

C6500(config-cmap)# match dscp ef

! Realtime traffic (EF) is mapped to the REALTIME-QUEUE

C6500(config-cmap)# class-map type lan-queuing CONTROL-QUEUE

C6500(config-cmap)# match dscp cs3

! Signaling (CS3) is mapped to a dedicated nonpriority queue

C6500(config-cmap)# class-map type lan-queuing TRANSACTIONAL-DATA-QUEUE

C6500(config-cmap)# match dscp af21 af22 af23

! Transactional data (AF2) is mapped to a dedicated nonpriority queue

! This section configures the four-class ingress (4Q4T) policy map

C6500(config-pmap)# policy-map type lan-queuing INGRESS-4Q4T

C6500(config-pmap)# class REALTIME-QUEUE

C6500(config-pmap-c)# bandwidth percent 30

! Defines the REALTIME-QUEUE with 30% BW

C6500(config-pmap-c)# class CONTROL-QUEUE

C6500(config-pmap-c)# bandwidth percent 10

! Defines the control queue with 10% BW

C6500(config-pmap-c)# class TRANSACTIONAL-DATA-QUEUE

C6500(config-pmap-c)# bandwidth percent 35

! Defines the transactional data queue with 35% BW

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp af21 percent 80 100

C6500(config-pmap-c)# random-detect dscp af22 percent 70 100

C6500(config-pmap-c)# random-detect dscp af23 percent 60 100

! DSCP-based WRED is enabled and tuned for AF2 PHB

C6500(config-pmap-c)# class class-default

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp default percent 80 100

! DSCP-based WRED is enabled and tuned for default DSCP (0)

! This section configures the four-class egress (1P3Q4T) policy map

C6500(config-pmap)# policy-map type lan-queuing EGRESS-1P3Q4T

C6500(config-pmap)# class REALTIME-QUEUE

C6500(config-pmap-c)# priority

! Enables strict-priority queuing for the real-time queue

C6500(config-pmap-c)# class CONTROL-QUEUE

C6500(config-pmap-c)# bandwidth remaining percent 10

! Defines the control queue with 10% BW remaining

C6500(config-pmap-c)# class TRANSACTIONAL-DATA-QUEUE

C6500(config-pmap-c)# bandwidth remaining percent 35

! Defines the transactional data queue with 35% BW remaining

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp af21 percent 80 100

C6500(config-pmap-c)# random-detect dscp af22 percent 70 100

C6500(config-pmap-c)# random-detect dscp af23 percent 60 100

! DSCP-based WRED is enabled and tuned for AF2 PHB

C6500(config-pmap-c)# class class-default

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp default percent 80 100

! DSCP-based WRED is enabled and tuned for default DSCP (0)

! This section attaches the ingress and egress queuing policies

! to the interface(s)

C6500(config-pmap-c)# interface range TenGigabitEthernet 3/1-8

C6500(config-if-range)# service-policy type lan-queuing input INGRESS-4Q4T

! Attaches the INGRESS-4Q4T queuing policy to the interfaces

C6500(config-if-range)# service-policy type lan-queuing output EGRESS-1P3Q4T

! Attaches the EGRESS-1P3Q4T queuing policy to the interfaces

注释:需要将用于队列策略的class map和policy map明确地定义为type lan-queuing。

注释:无需在默认类上明确地定义带宽百分比。

可通过如下命令验证例16-1中的配置。

■ show class-map

■ show policy-map

■ show queueing interface

16.3.2 8类（8Q4T入向和1P7Q4T出向）队列模型

在（图11-5和图11-6所示的）8类模型中，应用类到队列的映射如下所示。

■ 实时流量（标记为EF）被分配到实时队列，实时队列在入向8Q4T模型中分配10%的带宽，在出向1P7Q4T模型中启用严格优先级队列。

■ 网络控制流量（标记为CS6）被分配到有5%的带宽/剩余带宽分配的专用非优先级队列。

■ 信令流量（标记为CS3）被分配到有2%的带宽/剩余带宽分配的专用非优先级队列。

■ 交互式视频（标记为AF4）被分配到有23%带宽/剩余带宽分配并启用基于DSCP的WRED的专用非优先级队列。

■ 流媒体视频（标记为AF3）被分配到有10%带宽/剩余带宽分配并启用基于DSCP的WRED的专用非优先级队列。

■ 业务性数据（标记为AF2）被分配到有24%带宽/剩余带宽分配并启用基于DSCP的WRED的专用非优先级队列。

■ 清道夫流量（标记为CS1）被限制在有1%的带宽/剩余带宽分配的专用非优先级队列。

■ 尽力传输流量（标记为DF）被分配到启用WRED的默认队列（有隐含分配的至少25%的带宽）。

图16-5 显示了Catalyst 6500 的8 类（8Q4T 入向和1P7Q4T 出向）队列模型。

图16-5 Catalyst 6500的8类（8Q4T入向和1P7Q4T出向）队列模型示例

例16-2 显示了Catalyst 6500 上对应的8 类（8Q4T 入向和1P7Q4T 出向）队列模型配置。

例16-2 Catalyst 6500上8类（8Q4T入向和1P7Q4T出向）队列模型配置示例

! This section configures the class maps for the queuing policy maps

! Note both ingress and egress policy maps share these common class maps

C6500(config-cmap)# class-map type lan-queuing REALTIME-QUEUE

C6500(config-cmap)# match dscp ef

! Realtime traffic (EF) is mapped to the REALTIME-QUEUE

C6500(config-cmap)# class-map type lan-queuing CONTROL-QUEUE

C6500(config-cmap)# match dscp cs6

! Network Control (CS6) is mapped to a dedicated nonpriority queue

C6500(config-cmap)# class-map type lan-queuing SIGNALING-QUEUE

C6500(config-cmap)# match dscp cs3

! Signaling (CS3) is mapped to a dedicated nonpriority queue

C6500(config-cmap)# class-map type lan-queuing INTERACTIVE-VIDEO-QUEUE

C6500(config-cmap)# match dscp af41 af42 af43

! Interactive-Video (AF4) is mapped to a dedicated nonpriority queue

C6500(config-cmap)# class-map type lan-queuing STREAMING-VIDEO-QUEUE

C6500(config-cmap)# match dscp af31 af32 af33

! Streaming-Video (AF3) is mapped to a dedicated nonpriority queue

C6500(config-cmap)# class-map type lan-queuing TRANSACTIONAL-DATA-QUEUE

C6500(config-cmap)# match dscp af21 af22 af23

! Transactional Data (AF2) is mapped to a dedicated nonpriority queue

C6500(config-cmap)# class-map type lan-queuing SCAVENGER-QUEUE

C6500(config-cmap)# match dscp cs1

! Scavenger (CS1) is mapped to a bandwidth-constrained queue

! This section configures the eight-class ingress (8Q4T) policy map

C6500(config-pmap)# policy-map type lan-queuing INGRESS-8Q4T

C6500(config-pmap)# class REALTIME-QUEUE

C6500(config-pmap-c)# bandwidth percent 10

! Defines the real-time queue with 10% BW

C6500(config-pmap-c)# class CONTROL-QUEUE

C6500(config-pmap-c)# bandwidth percent 5

! Defines the control queue with 5% BW

C6500(config-pmap-c)# class SIGNALING-QUEUE

C6500(config-pmap-c)# bandwidth percent 2

! Defines the signaling queue with 2% BW

C6500(config-pmap-c)# class INTERACTIVE-VIDEO-QUEUE

C6500(config-pmap-c)# bandwidth percent 23

! Defines the interactive video queue with 23% BW

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp af41 percent 80 100

C6500(config-pmap-c)# random-detect dscp af42 percent 70 100

C6500(config-pmap-c)# random-detect dscp af43 percent 60 100

! DSCP-based WRED is enabled and tuned for AF4 PHB

C6500(config-pmap-c)# class STREAMING-VIDEO-QUEUE

C6500(config-pmap-c)# bandwidth percent 10

! Defines the streaming video queue with 10% BW

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp af31 percent 80 100

C6500(config-pmap-c)# random-detect dscp af32 percent 70 100

C6500(config-pmap-c)# random-detect dscp af33 percent 60 100

! DSCP-based WRED is enabled and tuned for AF3 PHB

C6500(config-pmap-c)# class TRANSACTIONAL-DATA-QUEUE

C6500(config-pmap-c)# bandwidth percent 24

! Defines the transactional data queue with 24% BW

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp af21 percent 80 100

C6500(config-pmap-c)# random-detect dscp af22 percent 70 100

C6500(config-pmap-c)# random-detect dscp af23 percent 60 100

! DSCP-based WRED is enabled and tuned for AF2 PHB

C6500(config-pmap-c)# class SCAVENGER-QUEUE

C6500(config-pmap-c)# bandwidth percent 1

! Defines the scavenger queue with 1% BW

C6500(config-pmap-c)# class class-default

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp default percent 80 100

! DSCP-based WRED is enabled and tuned for default DSCP (0)

! This section configures the eight-class egress (1P7Q4T) policy map

C6500(config-pmap)# policy-map type lan-queuing EGRESS-1P7Q4T

C6500(config-pmap)# class REALTIME-QUEUE

C6500(config-pmap-c)# priority

! Enables strict-priority queuing on the real-time-queue

C6500(config-pmap-c)# class CONTROL-QUEUE

C6500(config-pmap-c)# bandwidth remaining percent 5

! Defines the control queue with 5% BW remaining

C6500(config-pmap-c)# class SIGNALING-QUEUE

C6500(config-pmap-c)# bandwidth remaining percent 2

! Defines the signaling queue with 2% BW remaining

C6500(config-pmap-c)# class INTERACTIVE-VIDEO-QUEUE

C6500(config-pmap-c)# bandwidth remaining percent 23

! Defines the interactive video queue with 23% BW remaining

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp af41 percent 80 100

C6500(config-pmap-c)# random-detect dscp af42 percent 70 100

C6500(config-pmap-c)# random-detect dscp af43 percent 60 100

! DSCP-based WRED is enabled and tuned for AF4 PHB

C6500(config-pmap-c)# class STREAMING-VIDEO-QUEUE

C6500(config-pmap-c)# bandwidth remaining percent 10

! Defines the streaming video queue with 10% BW remaining

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp af31 percent 80 100

C6500(config-pmap-c)# random-detect dscp af32 percent 70 100

C6500(config-pmap-c)# random-detect dscp af33 percent 60 100

! DSCP-based WRED is enabled and tuned for AF3 PHB

C6500(config-pmap-c)# class TRANSACTIONAL-DATA-QUEUE

C6500(config-pmap-c)# bandwidth remaining percent 24

! Defines the transactional data queue with 24% BW remaining

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp af21 percent 80 100

C6500(config-pmap-c)# random-detect dscp af22 percent 70 100

C6500(config-pmap-c)# random-detect dscp af23 percent 60 100

! DSCP-based WRED is enabled and tuned for AF2 PHB

C6500(config-pmap-c)# class SCAVENGER-QUEUE

C6500(config-pmap-c)# bandwidth remaining percent 1

! Defines the scavenger queue with 1% BW remaining

C6500(config-pmap-c)# class class-default

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp default percent 80 100

! DSCP-based WRED is enabled and tuned for default DSCP (0)

! This section attaches the ingress and egress queuing policies

! to the interface(s)

C6500(config)# interface range TenGigabitEthernet 3/1-8

C6500(config-if-range)# service-policy type lan-queuing input INGRESS-8Q4T

! Attaches the INGRESS-8Q4T queuing policy to the interfaces

C6500(config-if-range)# service-policy type lan-queuing output EGRESS-1P7Q4T

! Attaches the EGRESS-1P7Q4T queuing policy to the interfaces

可通过如下命令验证例16-2中的配置。

■ show class-map

■ show policy-map

■ show queueing interface

16.3.3 12类（8Q4T入向和1P7Q4T出向）队列模型

在（图11-7和图11-8所示的）12类模型中，应用类到队列的映射如下所示。

■ 语音（标记为EF）、广播视频（标记为CS5）和实时交互（标记为CS4）全部被分配到实时队列，实时队列在入向8Q4T模型中分配10%的带宽，在出向1P7Q4T模型中启用严格优先级队列。

■ 网络控制流量（标记为CS6）、信令流量（标记为CS3）和网络管理流量（CS2）全部被分配到有10%的带宽/剩余带宽分配的专用非优先级队列；CS7流量也可被映射到此队列。

■ 多媒体会议（标记为AF4）被分配到有10%带宽/剩余带宽分配并启用基于DSCP的WRED的专用非优先级队列。

■ 多媒体流媒体（标记为AF3）被分配到有10%带宽/剩余带宽分配并启用基于DSCP的WRED的专用非优先级队列。

■ 业务性数据（标记为AF2）被分配到有10%带宽/剩余带宽分配并启用基于DSCP的WRED的专用非优先级队列。

■ 大块数据（标记为AF1）被分配到有4%带宽/剩余带宽分配并启用基于DSCP的WRED的专用非优先级队列。

■ 清道夫流量（标记为CS1）被限制在有1%的带宽/剩余带宽分配的专用非优先级队列。

■ 尽力传输流量（标记为DF）被分配到启用WRED的默认队列（有隐含分配的至少25%的带宽）。

图16-6 显示了Catalyst 6500 的12 类（8Q4T 入向和1P7Q4T 出向）队列模型。

图16-6 Catalyst 6500的12类（8Q4T入向和1P7Q4T出向）队列模型示例

例16-3显示了Catalyst 6500上对应的12类（8Q4T入向和1P7Q4T 出向）队列模型配置。

例16-3 Catalyst 6500上12类（8Q4T入向和1P7Q4T出向）队列模型配置示例

! This section configures the class maps for the queuing policy maps

! Note both ingress and egress policy maps share these common class maps

C6500(config-cmap)# class-map type lan-queuing REALTIME-QUEUE

C6500(config-cmap)# match dscp cs4 cs5 ef

! Real-time interactive (CS4), broadcast video (CS5) and voice (EF)

! are all mapped to the real-time-queue

C6500(config-cmap)# class-map type lan-queuing CONTROL-QUEUE

C6500(config-cmap)# match dscp cs2 cs3 cs6 cs7

! Network management (CS2), signaling (CS3),

! Internetwork control/routing (CS6) and network control (CS7)

! are all mapped to the control queue

C6500(config-cmap)# class-map type lan-queuing MULTIMEDIA-CONFERENCING-QUEUE

C6500(config-cmap)# match dscp af41 af42 af43

! Multimedia conferencing (AF4) is mapped to a nonpriority queue

C6500(config-cmap)# class-map type lan-queuing MULTIMEDIA-STREAMING-QUEUE

C6500(config-cmap)# match dscp af31 af32 af33

! Multimedia streaming (AF3) is mapped to a nonpriority queue

C6500(config-cmap)# class-map type lan-queuing TRANSACTIONAL-DATA-QUEUE

C6500(config-cmap)# match dscp af21 af22 af23

! Transactional data (AF2) is mapped to a dedicated nonpriority queue

C6500(config-cmap)# class-map type lan-queuing BULK-DATA-QUEUE

C6500(config-cmap)# match dscp af11 af12 af13

! Bulk Data (AFa) is mapped to a dedicated nonpriority queue

C6500(config-cmap)# class-map type lan-queuing SCAVENGER-QUEUE

C6500(config-cmap)# match dscp cs1

! Scavenger (CS1) is mapped to a bandwidth-constrained queue

! This section configures the 12-class ingress (8Q4T) policy map

C6500(config-pmap)# policy-map type lan-queuing INGRESS-8Q4T

C6500(config-pmap)# class REALTIME-QUEUE

C6500(config-pmap-c)# bandwidth percent 10

! Defines the real-time queue with 10% BW

C6500(config-pmap-c)# class CONTROL-QUEUE

C6500(config-pmap-c)# bandwidth percent 10

! Defines the control queue with 10% BW

C6500(config-pmap-c)# class MULTIMEDIA-CONFERENCING-QUEUE

C6500(config-pmap-c)# bandwidth percent 10

! Defines the multimedia conferencing queue with 10% BW

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp af41 percent 80 100

C6500(config-pmap-c)# random-detect dscp af42 percent 70 100

C6500(config-pmap-c)# random-detect dscp af43 percent 60 100

! DSCP-based WRED is enabled and tuned for AF4 PHB

C6500(config-pmap-c)# class MULTIMEDIA-STREAMING-QUEUE

C6500(config-pmap-c)# bandwidth percent 10

! Defines the multimedia streaming queue with 10% BW

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp af31 percent 80 100

C6500(config-pmap-c)# random-detect dscp af32 percent 70 100

C6500(config-pmap-c)# random-detect dscp af33 percent 60 100

! DSCP-based WRED is enabled and tuned for AF3 PHB

C6500(config-pmap-c)# class TRANSACTIONAL-DATA-QUEUE

C6500(config-pmap-c)# bandwidth percent 10

! Defines the transactional data queue with 10% BW

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp af21 percent 80 100

C6500(config-pmap-c)# random-detect dscp af22 percent 70 100

C6500(config-pmap-c)# random-detect dscp af23 percent 60 100

! DSCP-based WRED is enabled and tuned for AF2 PHB

C6500(config-pmap-c)# class BULK-DATA-QUEUE

C6500(config-pmap-c)# bandwidth percent 4

! Defines the bulk data queue with 4% BW

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp af11 percent 80 100

C6500(config-pmap-c)# random-detect dscp af12 percent 70 100

C6500(config-pmap-c)# random-detect dscp af13 percent 60 100

! DSCP-based WRED is enabled and tuned for AF1 PHB

C6500(config-pmap-c)# class SCAVENGER-QUEUE

C6500(config-pmap-c)# bandwidth percent 1

! Defines the scavenger queue with 1% BW

C6500(config-pmap-c)# class class-default

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp default percent 80 100

! DSCP-based WRED is enabled and tuned for default DSCP (0)

! This section configures the 12-class egress (1P7Q4T) policy map

C6500(config-pmap)# policy-map type lan-queuing EGRESS-1P7Q4T

C6500(config-pmap)# class REALTIME-QUEUE

C6500(config-pmap-c)# priority

! Enables strict-priority queuing on the real-time queue

C6500(config-pmap-c)# class CONTROL-QUEUE

C6500(config-pmap-c)# bandwidth remaining percent 10

! Defines the control queue with 10% BW remaining

C6500(config-pmap-c)# class MULTIMEDIA-CONFERENCING-QUEUE

C6500(config-pmap-c)# bandwidth remaining percent 10

! Defines the multimedia conferencing queue with 10% BW remaining

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp af41 percent 80 100

C6500(config-pmap-c)# random-detect dscp af42 percent 70 100

C6500(config-pmap-c)# random-detect dscp af43 percent 60 100

! DSCP-based WRED is enabled and tuned for AF4 PHB

C6500(config-pmap-c)# class MULTIMEDIA-STREAMING-QUEUE

C6500(config-pmap-c)# bandwidth remaining percent 10

! Defines the multimedia streaming queue with 10% BW remaining

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp af31 percent 80 100

C6500(config-pmap-c)# random-detect dscp af32 percent 70 100

C6500(config-pmap-c)# random-detect dscp af33 percent 60 100

! DSCP-based WRED is enabled and tuned for AF3 PHB

C6500(config-pmap-c)# class TRANSACTIONAL-DATA-QUEUE

C6500(config-pmap-c)# bandwidth remaining percent 10

! Defines the transactional data queue with 10% BW remaining

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp af21 percent 80 100

C6500(config-pmap-c)# random-detect dscp af22 percent 70 100

C6500(config-pmap-c)# random-detect dscp af23 percent 60 100

! DSCP-based WRED is enabled and tuned for AF2 PHB

C6500(config-pmap-c)# class BULK-DATA-QUEUE

C6500(config-pmap-c)# bandwidth remaining percent 4

! Defines the bulk data queue with 4% BW remaining

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp af11 percent 80 100

C6500(config-pmap-c)# random-detect dscp af12 percent 70 100

C6500(config-pmap-c)# random-detect dscp af13 percent 60 100

! DSCP-based WRED is enabled and tuned for AF1 PHB

C6500(config-pmap-c)# class SCAVENGER-QUEUE

C6500(config-pmap-c)# bandwidth remaining percent 1

! Defines the scavenger queue with 1% BW remaining

C6500(config-pmap-c)# class class-default

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp default percent 80 100

! This section attaches the ingress and egress queuing policies

! to the interface(s)

C6500(config)# interface range TenGigabitEthernet 3/1-8

C6500(config-if-range)# service-policy type lan-queuing input INGRESS-8Q4T

! Attaches the INGRESS-8Q4T queuing policy to the interfaces

C6500(config-if-range)# service-policy type lan-queuing output EGRESS-1P7Q4T

! Attaches the EGRESS-1P7Q4T queuing policy to the interfaces

可通过如下命令验证例16-3中的配置。

■ show class-map

■ show policy-map

■ show queueing interface（详见例16-4）

例16-4 在Catalyst 6500上验证队列策略:show queueing interface

C6500# show queueing interface TenGigabitEthernet 3/8

Interface TenGigabitEthernet3/8 queueing strategy:　Weighted Round-Robin

Port QoS is enabled globally

Queueing on Te3/8:Tx Enabled Rx Enabled

Trust boundary disabled

Trust state:trust DSCP

Trust state in queueing:trust DSCP

Extend trust state:not trusted [COS = 0]

Default COS is 0

Class-map to Queue in Tx direction

Class-map　　　Queue Id

----------------------------

REALTIME-QUEUE　　　8

CONTROL-QUEUE　　　7

MULTIMEDIA-CONFERENC　　6

MULTIMEDIA-STREAMING　　5

TRANSACTIONAL-DATA-Q　　4

BULK-DATA-QUEUE　　　3

SCAVENGER-QUEUE　　　2

class-default　　　1

Queueing Mode In Tx direction:mode-dscp

Transmit queues [type = 1p7q4t]:

Queue Id　Scheduling　Num of thresholds

-----------------------------------------

01　　WRR　　　　04

02　　WRR　　　　04

03　　WRR　　　　04

04　　WRR　　　　04

05　　WRR　　　　04

06　　WRR　　　　04

07　　WRR　　　　04

08　　Priority　　　01

WRR bandwidth ratios:　55[queue 1]　1[queue 2]　4[queue 3]　10[queue 4]10[queue 5] 10[queue 6] 10[queue 7]

queue-limit ratios:　100[queue 1] 100[queue 2] 100[queue 3] 100[queue 4]100[queue 5] 100[queue 6] 100[queue 7] 15[Pri Queue]

<snip>

queue random-detect-min-thresholds

----------------------------------

1　80[1] 70[2] 70[3] 100[4]

2　40[1] 70[2] 70[3] 70[4]

3　80[1] 70[2] 60[3] 70[4]

4　80[1] 70[2] 60[3] 100[4]

5　80[1] 70[2] 60[3] 100[4]

6　80[1] 70[2] 60[3] 100[4]

7　100[1] 100[2] 100[3] 100[4]

queue random-detect-max-thresholds

----------------------------------

1　100[1] 100[2] 100[3] 100[4]

2　70[1] 100[2] 100[3] 100[4]

3　100[1] 100[2] 100[3] 100[4]

4　100[1] 100[2] 100[3] 100[4]

5　100[1] 100[2] 100[3] 100[4]

6　100[1] 100[2] 100[3] 100[4]

7　100[1] 100[2] 100[3] 100[4]

WRED disabled queues:　　2　7

<snip>

queue thresh dscp-map

---------------------------------------

1　1　　0

1　2

1　3

1　4　　1 2 3 4 5 6 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41

42 43 44 45 47 49 50 51 52 53 54 55 57 58 59 60 61 62 63

2　1　　8

2　2

2　3

2　4

3　1　　10

3　2　　12

3　3　　14

3　4

4　1　　18

4　2　　20

4　3　　22

4　4

5　1　　26

5　2　　28

5　3　　30

5　4

6　1　　34

6　2　　36

6　3　　38

6　4

7　1　　16 24 48 56

7　2

7　3

7　4

8　1　　32 40 46

Class-map to Queue in Rx direction

Class-map　　　Queue Id

----------------------------

REALTIME-QUEUE　　　8

CONTROL-QUEUE　　　7

MULTIMEDIA-CONFERENC　　6

MULTIMEDIA-STREAMING　　5

TRANSACTIONAL-DATA-Q　　4

BULK-DATA-QUEUE　　　3

SCAVENGER-QUEUE　　　2

class-default　　　1

Queueing Mode In Rx direction:mode-dscp

Receive queues [type = 8q4t]:

Queue Id　Scheduling　Num of thresholds

-----------------------------------------

01　　WRR　　　　04

02　　WRR　　　　04

03　　WRR　　　　04

04　　WRR　　　　04

05　　WRR　　　　04

06　　WRR　　　　04

07　　WRR　　　　04

08　　WRR　　　　04

WRR bandwidth ratios:　45[queue 1]　1[queue 2]　4[queue 3]　10[queue 4]10[queue 5] 10[queue 6] 10[queue 7] 10[queue 8]

queue-limit ratios:　100[queue 1] 100[queue 2] 100[queue 3] 100[queue 4]100[queue 5] 100[queue 6] 100[queue 7] 100[queue 8]

<snip>

queue random-detect-min-thresholds

----------------------------------

1　80[1] 40[2] 50[3] 100[4]

2　100[1] 100[2] 100[3] 100[4]

3　80[1] 70[2] 60[3] 100[4]

4　80[1] 70[2] 60[3] 100[4]

5　80[1] 70[2] 60[3] 100[4]

6　80[1] 70[2] 60[3] 100[4]

7　100[1] 100[2] 100[3] 100[4]

8　100[1] 100[2] 100[3] 100[4]

queue random-detect-max-thresholds

----------------------------------

1　100[1] 80[2] 90[3] 100[4]

2　100[1] 100[2] 100[3] 100[4]

3　100[1] 100[2] 100[3] 100[4]

4　100[1] 100[2] 100[3] 100[4]

5　100[1] 100[2] 100[3] 100[4]

6　100[1] 100[2] 100[3] 100[4]

7　100[1] 100[2] 100[3] 100[4]

8　100[1] 100[2] 100[3] 100[4]

WRED disabled queues:　　2　7　8

<snip>

queue thresh dscp-map

---------------------------------------

1　1　　0

1　2

1　3

1　4　　1 2 3 4 5 6 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 42 43 44 45 47 49 50 51 52 53 54 55 57 58 59 60 61 62 63

2　1　　8

2　2

2　3

2　4

3　1　　10

3　2　　12

3　3　　14

3　4

4　1　　18

4　2　　20

4　3　　22

4　4

5　1　　26

5　2　　28

5　3　　30

5　4

6　1　　34

6　2　　36

6　3　　38

6　4

7　1　　16 24 48 56

7　2

7　3

7　4

8　1　　32 40 46

8　2

8　3

8　4

Packets dropped on Transmit:

BPDU packets:　0

queue　　　　dropped　[dscp-map]

---------------------------------------------

1　　　　　　0　[0 1 2 3 4 5 6 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 42 43 44 45 47 49 50 51 52 53 54 55 57 58 59 60 61 62 63 ]

2　　　　　　213432　[8 ]

3　　　　　　0　[10 12 14 ]

4　　　　　　0　[18 20 22 ]

5　　　　　　0　[26 28 30 ]

6　　　　　　0　[34 36 38 ]

7　　　　　　0　[16 24 48 56 ]

8　　　　　　0　[32 40 46 ]

Packets dropped on Receive:

BPDU packets:　0

queue　　　　dropped　[dscp-map]

---------------------------------------------

1　　　　　　0　[0 1 2 3 4 5 6 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 42 43 44 45 47 49 50 51 52 53 54 55 57 58 59 60 61 62 63 ]

2　　　　　　0　[8 ]

3　　　　　　0　[10 12 14 ]

4　　　　　　0　[18 20 22 ]

5　　　　　　0　[26 28 30 ]

6　　　　　　0　[34 36 38 ]

7　　　　　　0　[16 24 48 56 ]

8　　　　　　0　[32 40 46 ]

C6500#

例16-4显示了所有12类8Q4T入向和1P7Q4T出向队列策略的静态配置细节（所有非默认的配置均已被标出），以及每条队列的动态丢包情况，包括（传输）清道夫队列上的213,432个队列丢包记录。

需注意不论是怎样通过C3PL配置策略的，它们最终都被翻译成了硬件WRR队列参数（例如，为队列类的名称分配了互相不同的硬件队列编号，为特定的队列/门限值组合指定基于DSCP的WRED门限值，来实现相应功能）。

16.3.4 2P6Q4T入向和出向队列模型

如表16-2 所示，Catalyst 6904 40G 以太网模块既能配置1P7Q4T，也可配置为双PQ 的2P6Q4T设计。

优先级队列根据优先级级别的不同有不同的层级。

■ 优先级级别1:在服务任何其他队列之前获得完全服务。

■ 优先级级别2:只在优先级级别为1的队列被完全服务后才被服务，且在有流量到达优先级级别为1的队列时，它将被中断。

只有在两个优先级队列都获得完全服务后，非优先级队列才能（以WRR方式）获得服务。

之前的队列模型可通过非常简单的修改来使用此特性，如例16-5所示。可在线卡的入向和出向上应用相同的策略。

例16-5 Catalyst 6500上2P6Q4T入向和出向队列策略修订配置示例

! This section configures a dual-PQ (2P6Q4T) ingress/egress policy map

C6500(config-pmap)# policy-map type lan-queuing 2P6Q4T

C6500(config-pmap)# class REALTIME-VOICE-QUEUE

C6500(config-pmap-c)# priority level 1

! Enables strict-priority queuing on the real-time voice queue

C6500(config-pmap)# class REALTIME-VIDEO-QUEUE

C6500(config-pmap-c)# priority level 2

! Enables level-2 priority queuing on the real-time video queue

...

! This section attaches the ingress and egress queuing policies

! to the interface(s)

C6500(config)# interface FortyGigabitEthernet 1/1

C6500(config-if)# service-policy type lan-queuing input 2P6Q4T

! Attaches the 2P6Q4T queuing policy in the ingress direction

C6500(config-if)# service-policy type lan-queuing output 2P6Q4T

! Attaches the 2P6Q4T queuing policy in the egress direction

可通过如下命令验证例16-5中的配置。

■ show class-map

■ show policy-map

■ show queueing interface

16.4 与平台相关的其他QoS设计选项

上述的设计代表了园区网核心层中Catalyst 6500 QoS 的一些通用设计选项。但它们不是唯一可用的设计选项。其他选项和注意事项如下所示:

■ 接入边界设计选项；

■ 微流限速；

■ 每VLAN QoS 设计；

■ EtherChannel QoS 设计；

■ AutoQoS SRND4；

■ 控制层面限速。

每个设计选项都将相继讨论。

16.4.1 接入边界设计选项

本章着重介绍园区网核心层交换机Catalyst 6500 上的QoS 设计（通常与在园区网分布层使用的Catalyst 6500 的QoS 设计等同）。然而，Catalyst 6500 也可作为园区网接入层交换机使用。因此，其作为接入层交换机有一些其他的设计选项，包括如下接入边界模型:

■ 条件信任模型；

■ 分类和标记模型；

■ 分类、标记和限速模型。

每个接入边界设计选项都将相继介绍。

1.条件信任模型

就像之前提到的，基于C3PL 的Catalyst 6500 默认信任二层和三层标记，因此无需明确的命令来执行此功能。

然而，有必要为所有可能部署为接入层交换机的交换机平台提供条件信任的功能。在Catalyst 6500 上就有对应的条件信任命令，即platform qos trust device。

注释:C3PL包含一些与平台相关的语法（如条件trust命令），这与MLS QoS命令十分相似。然而，C3PL中使用platform关键字代替了mls关键字。

注释:在本书写作时，Catalyst 6500条件信任支持的唯一设备是Cisco IP电话，可通过cisco-phone关键字选项配置。

需注意Cisco IP 电话只能（在PC 产生的流量上）重标记CoS 位。因此，在Catalyst 6500上配置条件信任模型时，要求在端口上应用动态的条件信任策略，并使用C3PL策略来明确匹配CoS 5（语音）和CoS 3（信令），并将这些数据包的DSCP 值分别标记为EF 和CS3（实质上也就是执行CoS 到DSCP 的映射）。例16-6 显示了Catalyst 6500 的条件信任模型。

例16-6 在Catalyst 6500上为Cisco IP电话配置（基于CoS的）条件信任

! This section defines the class maps to match voice and signaling

C6500(config-cmap)# class-map match-all VOICE

C6500(config-cmap)# match cos 5

! Matches VoIP traffic on CoS 5

C6500(config-cmap)# class-map match-all SIGNALING

C6500(config-cmap)# match cos 3

! Matches signaling traffic on CoS 3

! This section defines the CoS-to-DSCP re-marking policy map

C6500(config-cmap)# policy-map CISCO-IPPHONE

C6500(config-pmap)# class VOICE

C6500(config-pmap-c)# set dscp ef

! Maps CoS 5 to DSCP EF

C6500(config-pmap-c)# class SIGNALING

C6500(config-pmap-c)# set dscp cs3

! Maps CoS 3 to DSCP CS3

C6500(config-pmap-c)# class class-default

C6500(config-pmap-c)# set dscp default

! All other traffic is set to DSCP DF

! This section applies conditional trust and policy map to the int(s)

C6500(config)# interface range GigabitEthernet 1/1-48

C6500(config-if-range)# switchport

C6500(config-if-range)# switchport access vlan 10

C6500(config-if-range)# switchport voice vlan 110

C6500(config-if-range)# spanning-tree portfast edge

C6500(config-if-range)# platform qos trust device cisco-phone

! Applies conditional-trust/trust-boundary to the switch port

C6500(config-if-range)# service-policy input CISCO-IPPHONE

! Attaches the CoS-to-DSCP mapping policy map

可通过如下命令验证例16-6中的配置。

■ show class-map

■ show policy-map

■ show policy-map interface

■ show queueing interface（详见例16-7）

例16-7 在Catalyst 6500上验证条件信任策略:show queueing interface

C6500# show queueing interface GigabitEthernet 1/48

Interface GigabitEthernet1/40 queueing strategy:Weighted Round-Robin

Port QoS is enabled globally

Queueing on Gi1/40:Tx Enabled Rx Enabled

Trust boundary enabled

Port is trusted

Trust state in queueing:trust COS

Extend trust state:trust CoS

<snip>

例16-7 显示了已在连接Cisco IP 电话的交换机端口上应用了（启用条件信任边界的）条件信任命令，端口的信任状态被设置为信任CoS（因为这是二层交换机端口的默认扩展信任状态）。

2.分类和标记模型

在许多情况下，要想区分端到端QoS战略性模型要求的所有流量类型，信任模型可能不可用或不够用。因此，可能需要在接入边界上明确配置分类和标记策略。

例16-8显示了基于图11-5（8类QoS模型）的配置示例。

注释:如前章所述，不是所有的应用类都会出现在接入边界的入方向上。例如，流媒体视频流量就不太可能出现在接入边界的入方向上（因为这些流不是从园区网终端设备发出的，但可能会发往这些终端设备），网络控制流也不会从园区网终端设备发出。因此，接入边界的分类和标记policy map中并不需要包括这些类。

注释:为简洁起见，略去了策略示例中的接入控制列表。

例16-8 Catalyst 6500上的分类和标记策略示例

! This section configures the class maps

C6500(config-cmap)# class-map match-all VOICE

C6500(config-cmap)# match dscp ef

! Voice is matched on DSCP EF

C6500(config-cmap)# class-map match-all INTERACTIVE-VIDEO

C6500(config-cmap)# match access-group name INTERACTIVE-VIDEO

! Associates interactive-video access list with class map

C6500(config-cmap)# class-map match-all SIGNALING

C6500(config-cmap)# match dscp cs3

! Signaling is matched on DSCP CS3

C6500(config-cmap)# class-map match-all TRANSACTIONAL-DATA

C6500(config-cmap)# match access-group name TRANSACTIONAL-DATA

! Associates transactional data access list with class map

C6500(config-cmap)# class-map match-all SCAVENGER

C6500(config-cmap)# match access-group name SCAVENGER

! Associates scavenger access list with class map

! This section configures the per-port ingress marking policy map

C6500(config-cmap)# policy-map PER-PORT-MARKING

C6500(config-pmap)# class VOICE

C6500(config-pmap-c)# set dscp ef

! VoIP is marked EF

C6500(config-pmap-c)# class INTERACTIVE-VIDEO

C6500(config-pmap-c)# set dscp af41

! Interactive-Video is marked AF41

C6500(config-pmap-c)# class SIGNALING

C6500(config-pmap-c)# set dscp cs3

! Signaling is marked CS3

C6500(config-pmap-c)# class TRANSACTIONAL-DATA

C6500(config-pmap-c)# set dscp af21

! Transactional data is marked AF21

C6500(config-pmap-c)# class SCAVENGER

C6500(config-pmap-c)# set dscp cs1

! Scavenger traffic is marked CS1

C6500(config-pmap-c)# class class-default

C6500(config-pmap-c)# set dscp default

! All other traffic is marked DF

! This section attaches the service policy to the interface(s)

C6500(config)# interface range GigabitEthernet 1/1-48

C6500(config-if-range)# switchport

C6500(config-if-range)# switchport access vlan 10

C6500(config-if-range)# switchport voice vlan 110

C6500(config-if-range)# spanning-tree portfast edge

C6500(config-if-range)# platform qos trust device cisco-phone

! The interface is set to conditionally trust Cisco IP phones

C6500(config-if-range)# service-policy input PER-PORT-MARKING

! Attaches the per-port marking policy to the interface(s)

可通过如下命令验证例16-8中的配置。

■ show class-map

■ show policy-map

■ show policy-map interface（详见例16-9）

■ show queueing interface

例16-9 在Catalyst 6500上验证服务策略:show policy-map interface

C6500# show policy-map interface GigabitEthernet 1/48

GigabitEthernet1/48

Service-policy input:PER-PORT-MARKING

class-map:VOICE (match-all)

Match:ip dscp ef (46)

set dscp 46:

Earl in slot 5:

0 bytes

30 second offered rate 0 bps

aggregate-forwarded 0 bytes

class-map:INTERACTIVE-VIDEO (match-all)

Match:access-group name INTERACTIVE-VIDEO

set dscp 34:

class-map:SIGNALING (match-all)

Match:ip dscp cs3 (24)

set dscp 24:

Earl in slot 5:

0 bytes

30 second offered rate 0 bps

aggregate-forwarded 0 bytes

class-map:TRANSACTIONAL-DATA (match-all)

Match:access-group name TRANSACTIONAL-DATA

set dscp 18:

class-map:SCAVENGER (match-all)

Match:access-group name SCAVENGER

set dscp 8:

class-map:class-default (match-any)

Match:any

set dscp 0:

Earl in slot 5:

3081 bytes

30 second offered rate 720 bps

aggregate-forwarded 3081 bytes

C6500#

3.分类、标记和限速模型

除了分类和标记，接入边界可能也需要实施限速。Catalyst 6500 可进行单速率（双色）限速和三色限速——通过使用RFC 2697 srTCM（单速率三色标记器）或RFC 2698 trTCM（双速率三色标记器）。例16-10显示了Catalyst 6500上的基于端口单速率限速示例（基于图12-8），例16-11 显示了用于支持RFC 2698 双速率三色标记器的策略修订。

例16-10 Catalyst 6500上的（单速率双色）基于端口限速配置示例

! This section configures the discard-class/dscp markdown map

! for traffic exceeding normal burst

C6500(config)# table-map policed-discard-class-normal-burst-map

C6500(config-tablemap)# map from 18 to 20

! AF21 (18) is mapped to AF22 (20) if exceeding normal burst

C6500(config-tablemap)# map from 10 to 12

! AF11 (10) is mapped to AF12 (12) if exceeding normal burst

C6500(config-tablemap)# map from 0 to 8

! DSCP 0 is mapped to CS1 (Scavenger) if exceeding normal burst

! This section configures the class maps

C6500(config-cmap)# class-map VVLAN-VOIP

C6500(config-cmap)# match dscp ef

! Voice from the VVLAN is matched on DSCP EF

C6500(config-cmap)# class-map VVLAN-SIGNALING

C6500(config-cmap)# match dscp cs3

! Signaling from the VVLAN is matched on DSCP CS3

C6500(config-cmap)# class-map MULTIMEDIA-CONFERENCING

C6500(config-cmap)# match access-group name MULTIMEDIA-CONFERENCING

! Multimedia conferencing traffic is matched by an ACL

C6500(config-cmap)# class-map SIGNALING

C6500(config-cmap)# match access-group name SIGNALING

! Signaling from the DVLAN is matched by an ACL

C6500(config-cmap)# class-map TRANSACTIONAL-DATA

C6500(config-cmap)# match access-group name TRANSACTIONAL-DATA

! Transactional data traffic is matched by an ACL

C6500(config-cmap)# class-map BULK-DATA

C6500(config-cmap)# match access-group name BULK-DATA

! Bulk data traffic is matched by an ACL

C6500(config-cmap)# class-map SCAVENGER

C6500(config-cmap)# match access-group name SCAVENGER

! Scavenger traffic is matched by an ACL

! This section configures the single-rate per-port policer policy map

C6500(config-pmap)# policy-map PER-PORT-POLICING

C6500(config-pmap-c)# class VVLAN-VOIP

C6500(config-pmap-c)# police 128k

C6500(config-pmap-c-police)# conform-action transmit

C6500(config-pmap-c-police)# exceed-action drop

! Voice from the VVLAN is policed to drop at 128 kbps

C6500(config-pmap-c)# class VVLAN-SIGNALING

C6500(config-pmap-c)# police 32k

C6500(config-pmap-c-police)# conform-action transmit

C6500(config-pmap-c-police)# exceed-action drop

! Signaling from the VVLAN is policed to drop at 32 kbps

C6500(config-pmap-c)# class MULTIMEDIA-CONFERENCING

C6500(config-pmap-c)# police 5m

C6500(config-pmap-c-police)# conform-action set-dscp-transmit af41

C6500(config-pmap-c-police)# exceed-action drop

! Multimedia conferencing is policed to drop at 5 Mbps

C6500(config-pmap-c)# class SIGNALING

C6500(config-pmap-c)# police 32k

C6500(config-pmap-c-police)# conform-action set-dscp-transmit cs3

C6500(config-pmap-c-police)# exceed-action drop

! Signaling from the DVLAN is policed to drop at 32 Kbps

C6500(config-pmap-c)# class TRANSACTIONAL-DATA

C6500(config-pmap-c)# police 10m

C6500(config-pmap-c-police)# conform-action set-dscp-transmit af21

C6500(config-pmap-c-police)# exceed-action policed-dscp-transmit

! Transactional data is policed to re-mark from AF21 to AF22 at 10 Mbps

C6500(config-pmap-c)# class BULK-DATA

C6500(config-pmap-c)# police 10m

C6500(config-pmap-c-police)# conform-action set-dscp-transmit af11

C6500(config-pmap-c-police)# exceed-action policed-dscp-transmit

! Bulk data is policed to re-mark from AF11 to AF12 at 10 Mbps

C6500(config-pmap-c)# class SCAVENGER

C6500(config-pmap-c)# police 10m

C6500(config-pmap-c-police)# conform-action set-dscp-transmit cs1

C6500(config-pmap-c-police)# exceed-action drop

! Scavenger is policed to drop at 10 Mbps

C6500(config-pmap-c)# class class-default

C6500(config-pmap-c)# police 10m

C6500(config-pmap-c-police)# conform-action set-dscp-transmit default

C6500(config-pmap-c-police)# exceed-action policed-dscp-transmit

! Best effort is policed to re-mark to Scavenger (CS1) at 10 Mbps

! This section applies the service-policy to the interface(s)

C6500(config)# interface range GigabitEthernet 1/1-48

C6500(config-if-range)# switchport

C6500(config-if-range)# switchport access vlan 10

C6500(config-if-range)# switchport voice vlan 110

C6500(config-if-range)# spanning-tree portfast

C6500(config-if-range)# platform qos trust device cisco-phone

! The interface is set to conditionally trust Cisco IP phones

C6500(config-if-range)# service-policy input PER-PORT-POLICING

! Attaches the Per-Port Policing policy to the interface(s)

注释:不能直接在Catalyst 6500上设置需要被重标记的DSCP值，必须通过降级表映射进行设置，如之前的示例所示。

注释:如例16-8所示，Catalyst 4500的IOS允许通过输入后缀k（千比特）、m（兆比特）、g（吉比特）来设置限速速率。此外，还可将十进制小数点与这些后缀一同使用。例如，10.5Mbit/s的速率可以通过policy map命令police 10.5m来输入。虽然在配置中，这些限速速率都会转换为比特每秒的完整数值，但这种方法让输入这些速率更加方便且不容易出错（否则可能需要输入10个0来定义限速速率）。

可通过如下命令验证例16-10中的配置。

■ show class-map

■ show policy-map

■ show policy-map interface

■ show queueing interface

■ show table-map policed-discard-class-normal-burst-map（详见例16-12）

为避免重复，例16-11将一个类（大数据类）上的限速器由单速率双色标记器修改并扩展为双速率三色标记器。可以在任意的AF（确认转发）类流量上进行相似的修改。如前所示，本例也需要配置降级表映射，不仅要配置正常限速速率，也要配置峰值/最大限速速率。

例16-11 Catalyst 6500上的（双速率三色速率双色）基于端口限速配置修订示例

! This section configures the discard-class/dscp markdown map

! for traffic exceeding normal burst

C6500(config)# table-map policed-discard-class-normal-burst-map

C6500(config-tablemap)# map from 18 to 20

! AF21 (18) is mapped to AF22 (20) if exceeding normal burst

C6500(config-tablemap)# map from 10 to 12

! AF11 (10) is mapped to AF12 (12) if exceeding normal burst

C6500(config-tablemap)# map from 0 to 8

! DSCP 0 is mapped to CS1 (Scavenger) if exceeding normal burst

! This section configures the discard-class/dscp markdown map

! for traffic violating maximum burst

C6500(config)# table-map policed-discard-class-max-burst-map

C6500(config-tablemap)# map from 18 to 22

! AF21 (18) is mapped to AF23 (22) if violating max/peak burst

C6500(config-tablemap)# map from 10 to 14

! AF21 (10) is mapped to AF13 (14) if violating max/peak burst

! This section configures a dual-rate per-port policing policy map

C6500(config)# policy-map TWO-RATE-POLICER

<snip>

C6500(config-pmap)# class BULK-DATA

C6500(config-pmap-c)# set dscp af11

C6500(config-pmap-c)# police 10m pir 15m

! Bulk data is policed to 10 Mbps rate and 15 Mbps peak rate

C6500(config-pmap-c-police)# conform-action set-dscp-transmit af11

! Bulk data under 10 Mbps will be marked AF11

C6500(config-pmap-c-police)# exceed-action policed-dscp-transmit

! Bulk data traffic between 10 Mbps and 15 Mbps will be marked AF12

! per policed-discard-class-normal-burst-map table map

C6500(config-pmap-c-police)# violate-action policed-dscp-transmit

! Bulk data traffic over 15 Mbps will be marked AF13

! per policed-discard-class-max-burst-map table map

可通过如下命令验证例16-11中的配置。

■ show class-map

■ show policy-map

■ show policy-map interface

■ show table-map policed-discard-class-normal-burst-map（详见例16-12）

■ show table-map policed-discard-class-max-burst-map（详见例16-13）

例16-12 在Catalyst 6500上验证表映射:show table-map

C6500# show table-map

<snip>

policed-discard-class-normal-burst-map:

(discard-class= d1d2)

d1:　d2 0　1　2　3　4　5　6　7　8　9

-------------------------------------

0:　08 01 02 03 04 05 06 07 08 09

1:　12 11 12 13 14 15 16 17 20 19

2:　20 21 22 23 24 25 26 27 28 29

3:　30 31 32 33 34 35 36 37 38 39

4:　40 41 42 43 44 45 46 47 48 49

5:　50 51 52 53 54 55 56 57 58 59

6:　60 61 62 63

例16-13 在Catalyst 6500上验证表映射:show table-map

C6500# show table-map

<snip>

policed-discard-class-max-burst-map:

(discard-class= d1d2)

d1:　d2 0　1　2　3　4　5　6　7　8　9

-------------------------------------

0:　00 01 02 03 04 05 06 07 08 09

1:　14 11 12 13 14 15 16 17 22 19

2:　20 21 22 23 24 25 26 27 28 29

3:　30 31 32 33 34 35 36 37 38 39

4:　40 41 42 43 44 45 46 47 48 49

5:　50 51 52 53 54 55 56 57 58 59

6:　60 61 62 63

C6500#

在例16-12和例16-13中，限速丢弃类的降级映射显示在两张表中。

■ 第一张表（table-map policed-discard-class-normal-burst-map）定义了数据包超过CIR 时的重标记行为。

■ 第二张表（policed-discard-class-max-burst-map）定义了数据包超过PIR时的重标记行为。

数据包提供给限速器的DSCP值的第1位数字如表中Y轴所示；数据包提供给限速器的DSCP值的第2为数字如表中X轴方向所示。

例如，大数据应用类（AF11/DSCP 10）的DSCP 值可在行d1=1、列d2=0 位置查得。有此DSCP值的数据包都将在超过正常限速速率时被重标记为12（AF12），或在超过峰值/最大限速速率时被重标记为14（AF13）。

DSCP 0 和DSCP 18 也被突出显示出来，DSCP 0 将在超过正常限速速率时被重标记为清道夫（CS1/DSCP 8），DSCP 18（AF21）将在超过正常限速速率时被重标记为DSCP 20（AF22），而在超过峰值限速速率时被重标记为DSCP 22（AF23）。

16.4.2 微流限速

Catalyst 6500 还支持微流限速，不仅是聚合的流，也可监测和限制单独/ 分立的流。通过policy map 命令police flow 可启用微流限速器。

微流限速器非常有用且灵活。例如，可配置微流限速器只使用源地址，这样做可以把微流限速器应用在来自一个源地址的所有流量上，而无视目的地址。这有效地增强了基于用户的速率限制，如在大学园区网环境中，管理员可能希望对单个学生的流量进行限速。

相反地，也可配置微流限速器只使用目的地址，这样做可以把微流限速器应用到发往一个目标地址的所有流量上，而无视源地址。

也可在每个policy map 类中使用聚合限速器和微流限速器，这样可根据流本身的带宽使用情况，以及该流与其他流共同的带宽使用情况来对流进行限速。例如，可以为组中单独的流应用微流限速器，创建合适的带宽限制；也可为整体组应用聚合限速器，创建合适的带宽限制。

注释:如果通过聚合和微流的方式对流量进行限速，聚合和微流限速器必须应用在相同的policy map类中，且对每类限速器都必须使用相同的conform-action和exceed-action关键字选项:drop、set-dscp-transmit或transmit。

例16-14展示了如何配置基于流的QoS策略，在基于用户的速率限制环境中使用了微流限速:将所有源于特定IP地址的流限速为1Mbit/s。

例16-14 （基于用户的速率限制情境中）在Catalyst 6500上配置微流限速

! This section defines the microflow policer policy map

C6500(config)# policy-map 1MBPS-MICROFLOW-POLICER

C6500(config-pmap)# class class-default

C6500(config-pmap-c)# police flow mask src-only 1000000 conform-action transmit

exceed-action drop

! Configures a user-based rate-limiter that meters each discrete

! microflow from a given source and limits these to 1 Mbps

! This section applies the microflow policer to the interface

C6500(config)# interface GigabitEthernet1/1

C6500(config-if)# service-policy input 1MBPS-MICROFLOW-POLICER

! Applies the 1-Mbps microflow policer to the interface

可通过如下命令验证例16-14中的配置。

■ show class-map

■ show policy-map

■ show policy-map interface

16.4.3 每VLAN QoS设计

Catalyst 6500可通过接口命令platform qos vlan-based支持每VLAN QoS，如例16-15所示。

例16-15 Catalyst 6500上每VLAN的标记配置示例

! This section configures the interface(s) for conditional trust,

C6500(config)# interface range GigabitEthernet 1/1-48

C6500(config-if-range)# switchport

C6500(config-if-range)# switchport access vlan 10

C6500(config-if-range)# switchport voice vlan 110

C6500(config-if-range)# spanning-tree portfast edge

C6500(config-if-range)# platform qos vlan-based

! Enables VLAN-based QoS on the interface(s)

! This section attaches the DVLAN policy to the DVLAN interface

C6500(config)# interface Vlan 10

C6500(config-if)# description DVLAN

C6500(config-if)# service-policy input DVLAN-MARKING

! Attaches the DVLAN Per-VLAN Marking policy to the DVLAN interface

! This section attaches the VVLAN policy to the VVLAN interface

C6500(config)# interface Vlan 110

C6500(config-if)# description VVLAN

C6500(config-if)# service-policy input VVLAN-MARKING

! Attaches the VVLAN Per-VLAN Marking policy to the VVLAN interface

可通过如下命令验证例16-15中的配置。

■ show class-map

■ show policy-map

■ show policy-map interface vlan vlan-number

注释:如前所述，不建议基于VLAN来部署（聚合的）限速策略，因为给定VLAN中终端设备的数量可能会发生变化，这就很容易导致每个终端设备的速率限制产生显著波动。

16.4.4 EtherChannel QoS设计

在Catalyst 6500上配置EtherChannel接口需要通过service-policy命令，将入向和出向（非队列）QoS策略（包括分类、标记和限速策略）关联到逻辑端口信道接口上（不需要配置信任状态，因为基于C3PL的平台默认信任）。然而，入向和出向队列策略是通过service-policy命令关联到物理端口成员接口上的。

■ 在逻辑端口信道接口上应用分类、标记和限速策略。

■ 在物理端口成员接口上应用（入向和出向）队列策略。

例16-16 展示了Catalyst 6500 上的EtherChannel QoS 设计。

例16-16 Catalyst 6500上的EtherChannel QoS设计

! This section configures the logical port channel interface

C6500(config)# interface Port-channel1

C6500(config-if)# description ETHERCHANNEL-LOGICAL-INTERFACE

C6500(config-if)# service-policy input MARKING

! Attaches a marking policy to the logical port-channel interface

C6500(config-if)# platform qos channel-consistency

! [Enabled by default] checks if physical member interfaces

! have the same ingress and egress queuing policies

! This section configures queuing on physical port-member interfaces

C6500(config)# interface range TenGigabitEthernet1/1-2

C6500(config-if-range)# description PORT-CHANNEL1-PORT-MEMBER

C6500(config-if-range)# service-policy type lan-queuing input INGRESS-8Q4T

! Attaches the INGRESS-8Q4T queuing policy to the interfaces

C6500(config-if-range)# service-policy type lan-queuing output EGRESS-1P7Q4T

! Attaches the EGRESS-1P7Q4T queuing policy to the interfaces

可通过如下命令验证例16-16中的配置。

■ show class-map

■ show policy-map

■ show policy-map interface

16.4.5 AutoQoS SRND4

在本书写作时，Catalyst6500不支持AutoQoSSRND4（但可以支持用于IP电话的AutoQoS）。

16.4.6 控制层面限速

Catalyst 6500 支持控制层面限速，详见附录B。

16.5 小结

本设计章节主要讨论了用于园区网核心层的Cisco Catalyst 6500（Supervisor 2T）系列交换机的最佳QoS方案设计建议（这与此系列交换机用于园区网分布层时的QoS设计要求大体一致）。

因为Catalyst 6500 是基于C3PL 的QoS 平台，所以QoS 默认启用，所有端口的状态均为信任DSCP。因此，在用于核心层的Catalyst 6500 上配置QoS 只有两个必要的步骤:配置入向队列策略和配置出向队列策略。

至此，本章应用Catalyst 6500 灵活的8Q8T 入向和1P7Q4T 出向硬件队列，详述了4 类、8类和12类（入向和出向）队列策略，并附有对应的配置和验证示例。

本章还讨论了与平台相关的其他设计选项和注意事项，包括怎样将Catalyst 6500 部署为接入边界交换机，以及怎样配置微流限速、每VLAN QoS 和EtherChannel QoS 设计。

（在本书写作时）Catalyst 6500 不支持AutoQoS SRND4。此平台支持控制层限速，详见附录B。

16.6 扩展阅读

企业媒体网服务质量设计4.0:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSCampus_40.html

媒体网园区QoS设计一览:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/qoscampusaag.html

媒体网Catalyst 6500 QoS 设计一览:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/qoscampuscat6500aag.html

Catalyst 6500 Sup2T QoS架构:http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_c11-652042.html

Cisco Catalyst 6500系列交换机IOS15.1SY Supervisor引擎2T软件配置指南:QoS配置指南:http://www.cisco.com/en/US/partner/docs/switches/lan/catalyst6500/ios/15.1SY/config_guide/sup2T/qos_overview.html

第17章 园区网QoS设计的案例研究

在定义了Tifosi Software 公司的战略性8 类端到端QoS 模型（如图12-2 所示）之后，网络团队现在准备以每个平台为基础，把这些策略应用到他们的（有线）园区网网络基础设施上。

Tifosi 的园区网络是多层的，由接入层的Cisco Catalyst 3750-X 交换机组、分布层的Cisco Catalyst 4500-E Supervisor 7-E 交换机组及核心层的Cisco Catalyst 6500-Supervisor 2T 交换机组（包括WS-X6908-10GE模块和WS-X6904-40G-2TXL模块）构成。

连接到Tifosi园区网的终端设备有多种类型，包括:

■ 台式PC、Mac和UNIX/Linux工作站（统称为PC）；

■ Cisco IP 电话；

■ Cisco 无线接入点；

■ Cisco TelePresence 系统；

■ 打印机。

网络团队希望确保所有终端设备都有各自的信任状态，或者对其明确应用分类和标记策略。

此外，Tifosi有供访客（如顾客、合作伙伴及供货商等）在公司时使用的有线和无线访客VLAN。然而，他们注意到连接到访客VLAN的流量总量通常非常庞大，因此他们想要将每个流限制到1Mbit/s。

最后，网络团队想要确保所有端口都应用了8类出向队列策略（以及在所有支持8类入向队列的平台/线卡上应用相应的入向队列策略）。

图17-1显示了将要应用到Tifosi园区网上的QoS策略。

图17-1 Tifosi Software案例研究:园区网络QoS设计

这些园区网QoS策略详述如下。

■ 策略1:不信任的终端设备（Catalyst 3750-X）

■ 禁用信任；

■ 为8类QoS模型启用1P1Q3T入向队列；

■ 为8类QoS模型启用1P3Q3T出向队列。

■ 策略2:受信任的终端设备（Catalyst 3750-X）

■ 启用静态的DSCP信任；

■ 为8类QoS模型启用1P1Q3T入向队列；

■ 为8类QoS模型启用1P3Q3T出向队列。

■ 策略3:条件信任的终端设备——TelePresence（Catalyst 3750-X）

■ 为Cisco TelePresence 系统（CTS）启用条件DSCP 信任；

■ 为8类QoS模型启用1P1Q3T入向队列；

■ 为8类QoS模型启用1P3Q3T出向队列。

■ 策略4:条件信任的终端设备——IP 电话+PC（Catalyst 3750-X）

■ 为Cisco IP 电话启用条件CoS 信任；

■ 将CoS 5 映射为DSCP EF；

■ 根据表17-1分类和标记流量；

■ 为8类QoS模型启用1P1Q3T入向队列；

■ 为8类QoS模型启用1P3Q3T出向队列。

表17-1 Tifosi用于Cisco IP电话+PC终端设备的8类分类和标记策略表

注释:表17-1展示了Tifosi使用的基于TCP/UDP端口的分类示例值。这些值可能改变，无法描述详尽。请参考应用特定的文档以确认用于应用分类的TCP/UDP端口。

■ 策略5:接入层上行链路端口（Catalyst 3750-X）

■ 启用静态DSCP信任；

■ 为8类QoS模型启用1P1Q3T入向队列；

■ 为8类QoS模型启用1P3Q3T出向队列。

■ 策略6:分布层下行链路端口（Catalyst 4500E Supervisor 7-E）

■（默认信任DSCP）；

■ 为访客VLAN的流量启用基于流的限速；

■ 为8类QoS模型启用1P7Q1T+DBL出向队列。

■ 策略7:分布层分布链路/ 核心上行链路端口（Catalyst 4500E Supervisor 7-E）

■（默认信任DSCP）；

■ 为8类QoS模型启用1P7Q1T+DBL出向队列。

■ 策略8:核心层下行链路（10-GE）端口（Catalyst 6500 Supervisor 2T，使用X6908-10GE模块）

■（默认信任DSCP）；

■ 为8类QoS模型启用2P6Q4T入向队列；

■ 为8类QoS模型启用2P6Q4T出向队列。

■ 策略 9:核心层核心链路（40-GE）端口（Catalyst 6500 Supervisor 2T，使用 WS-X6904-40G-2TXL）

■（默认信任DSCP）；

■ 为8类QoS模型启用2P6Q4T入向队列；

■ 为8类QoS模型启用2P6Q4T出向队列。

17.1 Tifosi园区网接入层QoS设计

Tifosi 园区网的接入层由Cisco Catalyst 3750 组成，包括以下策略的组合:

■ 对打印机和类似设备禁用信任；

■ 对无线接入点和类似设备启用静态DSCP；

■ 对Cisco TelePresence 系统启用条件信任；

■ 对Cisco IP 电话和PC 启用条件信任；

■ 为8类QoS模型启用1P1Q3T入向队列；

■ 为8类QoS模型启用1P3Q3T出向队列。

以下将相继展示每一个园区网接入层策略的配置。然而，虽然队列策略可应用于所有园区网接入模块，但为了减少冗余，只将其在最后展示。

17.1.1 策略1:打印机设备的接入边界设计（不信任）

例17-1展示了为连接不受信任终端设备的端口所使用的QoS策略。

例17-1 Tifosi Catalyst 3750不受信任终端设备的接入边界设计（打印机示例）

C3750(config)# interface GigabitEthernet 1/0/46

C3750(config-if)# switchport access vlan 10

C3750(config-if)# no mls qos trust

! Port is configured to be statically untrusted

! Queuing configurations detailed in Examples 17-6 and 17-7

17.1.2 策略2:无线接入点设备的接入边界设计（DSCP信任）

例17-2展示了为连接信任DSCP终端设备的端口所使用的QoS策略。

例17-2 Tifosi案例研究:Catalyst 3750信任终端设备的接入边界设计（无线接入点示例）

C3750(config)# interface GigabitEthernet 1/0/47

C3750(config-if)# switchport access vlan 10

C3750(config-if)# mls qos trust dscp

! Port is configured to statically trust DSCP

! Queuing configurations detailed in Examples 17-6 and 17-7

17.1.3 策略3:Cisco TelePresence 设备的接入边界设计（条件信任）

例17-3 展示了为连接CTS（Cisco TelePresence 系统）的接口所使用的QoS 策略。

例17-3 Tifosi案例研究:Catalyst 3750条件信任终端设备的接入边界设计（CTS示例）

C3750(config)# interface GigabitEthernet 1/0/48

C3750(config-if)# switchport access vlan 10

C3750(config-if)# switchport voice vlan 110

C3750(config-if)# spanning-tree portfast

C3750(config-if)# mls qos trust device cts

! Port is configured to conditionally trust the CTS endpoint

C3750(config-if)# mls qos trust dscp

! Port is configured to statically trust DSCP

! Queuing configurations detailed in Examples 17-6 and 17-7

17.1.4 策略4:Cisco IP电话或PC的接入边界设计（条件信任、分类和标记）

例17-4 展示了为连接Cisco IP 电话+PC 的接口所使用的QoS 策略（基于表17-1）。

例17-4 Tifosi案例研究:Catalyst 3750条件信任终端设备的接入边界设计（Cisco IP电话或PC示例）

! This section configures the classification extended ACLs

C3750(config)# ip access-list extended SIGNALING

C3750(config-ext-nacl)# remark SCCP

C3750(config-ext-nacl)# permit tcp any any eq 2000

C3750(config-ext-nacl)# remark SIP

C3750(config-ext-nacl)# permit tcp any any range 5060 5061

C3750(config)# ip access-list extended MULTIMEDIA-CONFERENCING

C3750(config-ext-nacl)# remark CISCO-JABBER-RTP

C3750(config-ext-nacl)# permit udp any any range 16384 32767

C3750(config-ext-nacl)# remark MICROSOFT-LYNC

C3750(config-ext-nacl)# permit tcp any any range 50000 59999

C3750(config)# ip access-list extended TRANSACTIONAL-DATA

C3750(config-ext-nacl)# remark HTTPS

C3750(config-ext-nacl)# permit tcp any any eq 443

C3750(config-ext-nacl)# remark CITRIX

C3750(config-ext-nacl)# permit tcp any any eq 3389

C3750(config-ext-nacl)# permit tcp any any eq 5985

C3750(config-ext-nacl)# permit tcp any any eq 8080

C3750(config-ext-nacl)# remark ORACLE

C3750(config-ext-nacl)# permit tcp any any eq 1521

C3750(config-ext-nacl)# permit tcp any any eq 1527

C3750(config-ext-nacl)# permit tcp any any eq 1575

C3750(config-ext-nacl)# permit tcp any any eq 1630

C3750(config-ext-nacl)# permit tcp any any eq 6200

C3750(config)# ip access-list extended BULK-DATA

C3750(config-ext-nacl)# remark FTP

C3750(config-ext-nacl)# permit tcp any any eq ftp

C3750(config-ext-nacl)# permit tcp any any eq ftp-data

C3750(config-ext-nacl)# remark SSH/SFTP

C3750(config-ext-nacl)# permit tcp any any eq 22

C3750(config-ext-nacl)# remark SMTP/SECURE SMTP

C3750(config-ext-nacl)# permit tcp any any eq smtp

C3750(config-ext-nacl)# permit tcp any any eq 465

C3750(config-ext-nacl)# remark IMAP/SECURE IMAP

C3750(config-ext-nacl)# permit tcp any any eq 143

C3750(config-ext-nacl)# permit tcp any any eq 993

C3750(config-ext-nacl)# remark POP3/SECURE POP3

C3750(config-ext-nacl)# permit tcp any any eq pop3

C3750(config-ext-nacl)# permit tcp any any eq 995

C3750(config-ext-nacl)# remark CONNECTED PC BACKUP

C3750(config-ext-nacl)# permit tcp any eq 1914 any

C3750(config)# ip access-list extended SCAVENGER

C3750(config-ext-nacl)# remark BITTORRENT

C3750(config-ext-nacl)# permit tcp any any range 6881 6999

C3750(config-ext-nacl)# remark APPLE ITUNES MUSIC SHARING

C3750(config-ext-nacl)# permit tcp any any eq 3689

C3750(config-ext-nacl)# permit udp any any eq 3689

C3750(config-ext-nacl)# remark MICROSOFT DIRECT X GAMING

C3750(config-ext-nacl)# permit tcp any any range 2300 2400

C3750(config-ext-nacl)# permit udp any any range 2300 2400

C3750(config)# ip access-list extended DEFAULT

C3750(config-ext-nacl)# remark EXPLICIT CLASS-DEFAULT

C3750(config-ext-nacl)# permit ip any any

! This section configures the class maps

C3750(config-cmap)# class-map match-all VOICE

C3750(config-cmap)# match dscp ef

! VoIP is trusted (from the VVLAN)

C3750(config-cmap)# class-map match-any SIGNALING

C3750(config-cmap)# match dscp cs3

! Signaling is trusted (from the VVLAN)

C3750(config-cmap)# match access-group name SIGNALING

! Signaling is classified by ACL (from the DVLAN)

C3750(config-cmap)# class-map match-all MULTIMEDIA-CONFERENCING

C3750(config-cmap)# match access-group name MULTIMEDIA-CONFERENCING

! Associates MULTIMEDIA-CONFERENCING access-list with class map

C3750(config-cmap)# class-map match-all TRANSACTIONAL-DATA

C3750(config-cmap)# match access-group name TRANSACTIONAL-DATA

! Associates TRANSACTIONAL-DATA access-list with class map

C3750(config-cmap)# class-map match-all BULK-DATA

C3750(config-cmap)# match access-group name BULK-DATA

! Associates BULK-DATA access-list with class map

C3750(config-cmap)# class-map match-all SCAVENGER

C3750(config-cmap)# match access-group name SCAVENGER

! Associates SCAVENGER access-list with class map

C3750(config-cmap)# class-map match-all DEFAULT

C3750(config-cmap)# match access-group name DEFAULT

! Associates DEFAULT access-list with class map

! This section configures the PC-MARKING policy map

C3750(config-cmap)# policy-map PC-MARKING

C3750(config-pmap-c)# class VOICE

C3750(config-pmap-c)# set dscp ef

! VoIP is marked EF

C3750(config-pmap-c)# class SIGNALING

C3750(config-pmap-c)# set dscp cs3

! Signaling is marked CS3

C3750(config-pmap-c)# class MULTIMEDIA-CONFERENCING

C3750(config-pmap-c)# set dscp af41

! Multimedia-conferencing is marked AF41

C3750(config-pmap-c)# class TRANSACTIONAL-DATA

C3750(config-pmap-c)# set dscp af21

! Transactional Data is marked AF21

C3750(config-pmap-c)# class BULK-DATA

C3750(config-pmap-c)# set dscp af11

! Bulk Data is marked AF11

C3750(config-pmap-c)# class SCAVENGER

C3750(config-pmap-c)# set dscp cs1

! Scavenger traffic is marked CS1

C3750(config-pmap-c)# class DEFAULT

C3750(config-pmap-c)# set dscp default

! An explicit class-default marks all other IP traffic to 0

! This section configures conditional trust on the interfaces

! and applies the PC-MARKING service policy

C3750(config)# interface range GigabitEthernet 1/0/1-45

C3750(config-if-range)# switchport access vlan 10

C3750(config-if-range)# switchport voice vlan 110

C3750(config-if-range)# mls qos trust device cisco-phone

! The interface is set to conditionally trust Cisco IP Phones

C3750(config-if-range)# mls qos trust cos

! CoS trust will be dynamically extended to Cisco IP Phones

C3750(config-if-range)# service-policy input PC-MARKING

! Attaches the PC-MARKING policy to the interface(s)

! Queuing configurations detailed in Examples 17-6 and 17-7

17.1.5 8类1P1Q3T入向队列设计

图17-2说明了Tifosi的8类1P1Q3T入向队列策略。

图17-2 Tifosi案例研究:Catalyst 3750 8类（1P1Q3T）入向队列模型

例17-5详述了8类1P1Q3T入向队列策略的相应配置。

例17-5 Tifosi案例研究:Catalyst 3750 8类 1P1Q3T入向队列

! This section configures the ingress queues

C3750(config)# mls qos srr-queue input priority-queue 2 bandwidth 30

! Q2 is enabled as a strict-priority ingress queue with 30% BW

C3750(config)# mls qos srr-queue input bandwidth 70 30

! Q1 is assigned 70% BW via SRR shared weights

! Q2 SRR shared weight is ignored (as it has been configured as a PQ)

C3750(config)# mls qos srr-queue input buffers 90 10

! Q1 is assigned 90% of queuing buffers and Q2 (PQ) is assigned 10%

C3750(config)# mls qos srr-queue input threshold 1 80 90

! Q1 thresholds are configured at 80% (Q1T1) and 90% (Q1T2)

! Q1T3 is implicitly set at 100% (the tail of the queue)

! Q2 thresholds are all set (by default) to 100% (the tail of Q2)

! This section configures ingress CoS-to-Queue mappings

C3750(config)# mls qos srr-queue input cos-map queue 1 threshold 1 0 1 2

! CoS values 0, 1 and 2 are mapped to Q1T1

C3750(config)# mls qos srr-queue input cos-map queue 1 threshold 2 3

! CoS value 3 is mapped to ingress Q1T2

C3750(config)# mls qos srr-queue input cos-map queue 1 threshold 3 6 7

! CoS values 6 and 7 are mapped to ingress Q1T3

C3750(config)# mls qos srr-queue input cos-map queue 2 threshold 1 4 5

! CoS values 4 and 5 are mapped to ingress Q2 (the PQ)

! This section configures ingress DSCP-to-Queue Mappings

C3750(config)# mls qos srr-queue input dscp-map queue 1 threshold 1 0 8 10 12 14

! DSCP DF, CS1 and AF1 are mapped to ingress Q1T1

C3750(config)# mls qos srr-queue input dscp-map queue 1 threshold 1 16 18 20 22

! DSCP CS2 and AF2 are mapped to ingress Q1T1

C3750(config)# mls qos srr-queue input dscp-map queue 1 threshold 1 26 28 30 34 36 38

! DSCP AF3 and AF4 are mapped to ingress Q1T1

C3750(config)# mls qos srr-queue input dscp-map queue 1 threshold 2 24

! DSCP CS3 is mapped to ingress Q1T2

C3750(config)# mls qos srr-queue input dscp-map queue 1 threshold 3 48 56

! DSCP CS6 and CS7 are mapped to ingress Q1T3 (the tail of Q1)

C3750(config)# mls qos srr-queue input dscp-map queue 2 threshold 3 32 40 46

! DSCP CS4, CS5 and EF are mapped to ingress Q2T3 (the tail of the PQ)

注释:例17-5中的8类1P1Q3T模型配置与例14-12中的8类或12类1P1Q3T模型配置等同。两个模型唯一的（可选的）区别已在例17-5中突出显示出来。这些区别相对次要，但如果配置了将会较大加快未来的类扩展。

17.1.6 8类1P1Q3T出向队列设计

图17-3说明了Tifosi的8类1P1Q3T出向队列策略。

图17-3 Tifosi案例研究:Catalyst 3750 8类（1P1Q3T）出向队列模型

例17-6展示了此8类1P1Q3T出向队列策略的相应配置。

例17-6 Tifosi案例研究:Catalyst 3750 8类 1P1Q3T出向队列

! This section configures buffers and thresholds on Q1 through Q4

C3750(config)# mls qos queue-set output 1 buffers 15 30 35 20

! Queue buffers are allocated

C3750(config)# mls qos queue-set output 1 threshold 1 100 100 100 100

! All Q1 (PQ) Thresholds are set to 100%

C3750(config)# mls qos queue-set output 1 threshold 2 80 90 100 400

! Q2T1 is set to 80%; Q2T2 is set to 90%;

! Q2 Reserve Threshold is set to 100%;

! Q2 Maximum (Overflow) Threshold is set to 400%

C3750(config)# mls qos queue-set output 1 threshold 3 100 100 100 400

! Q3T1 is set to 100%, as all packets are marked the same weight in Q3

! Q3 Reserve Threshold is set to 100%;

! Q3 Maximum (Overflow) Threshold is set to 400%

C3750(config)# mls qos queue-set output 1 threshold 4 60 100 100 400

! Q4T1 is set to 60%; Q4T2 is set to 100%

! Q4 Reserve Threshold is set to 100%;

! Q4 Maximum (Overflow) Threshold is set to 400%

! This section configures egress CoS-to-Queue mappings

C3750(config)# mls qos srr-queue output cos-map queue 1 threshold 3 4 5

! CoS 4 and 5 are mapped to egress Q1T3 (the tail of the PQ)

C3750(config)# mls qos srr-queue output cos-map queue 2 threshold 1 2

! CoS 2 is mapped to egress Q2T1

C3750(config)# mls qos srr-queue output cos-map queue 2 threshold 2 3

! CoS 3 is mapped to egress Q2T2

C3750(config)# mls qos srr-queue output cos-map queue 2 threshold 3 6 7

! CoS 6 and 7 are mapped to Q2T3

C3750(config)# mls qos srr-queue output cos-map queue 3 threshold 3 0

! CoS 0 is mapped to Q3T3 (the tail of the default queue)

C3750(config)# mls qos srr-queue output cos-map queue 4 threshold 3 1

! CoS 1 is mapped to Q4T3 (tail of the less-than-best-effort queue)

! This section configures egress DSCP-to-Queue mappings

C3750(config)# mls qos srr-queue output dscp-map queue 1 threshold 3 32 40 46

! DSCP CS4, CS5 and EF are mapped to egress Q1T3 (tail of the PQ)

C3750(config)# mls qos srr-queue output dscp-map queue 2 threshold 1 16 18 20 22

! DSCP CS2 and AF2 are mapped to egress Q2T1

C3750(config)# mls qos srr-queue output dscp-map queue 2 threshold 1 26 28 30 34 36 38

! DSCP AF3 and AF4 are mapped to egress Q2T1

C3750(config)# mls qos srr-queue output dscp-map queue 2 threshold 2 24

! DSCP CS3 is mapped to egress Q2T2

C3750(config)# mls qos srr-queue output dscp-map queue 2 threshold 3 48 56

! DSCP CS6 and CS7 are mapped to egress Q2T3

C3750(config)# mls qos srr-queue output dscp-map queue 3 threshold 3 0

! DSCP DF is mapped to egress Q3T3 (tail of the best effort queue)

C3750(config)# mls qos srr-queue output dscp-map queue 4 threshold 1 8

! DSCP CS1 is mapped to egress Q4T1

C3750(config)# mls qos srr-queue output dscp-map queue 4 threshold 2 10 12 14

! DSCP AF1 is mapped to Q4T3 (tail of the less-than-best-effort queue)

! This section configures interface egress queuing parameters

C3750(config)# interface range GigabitEthernet1/0/1-48

C3750(config-if-range)# queue-set 1

! The interface(s) is assigned to queue-set 1

C3750(config-if-range)# srr-queue bandwidth share 1 30 35 5

! The SRR sharing weights are set to allocate 30% BW to Q2

! 35% BW to Q3 and 5% BW to Q4

! Q1 SRR sharing weight is ignored, as it will be configured as a PQ

C3750(config-if-range)# priority-queue out

! Q1 is enabled as a strict-priority queue

注释:例17-6中的8类1P1Q3T模型配置与例14-15中的8类或12类1P1Q3T模型配置等同。两个模型唯一的（可选的）区别已在例17-6中突出显示出来。这些区别相对次要，但如果配置了将会较大加快未来的类扩展。

17.1.7 策略5:接入层上行链路设计

例17-7显示了在连接到分布层交换机的所有EtherChannel上行链路端口所应用的QoS策略。除了数据VLAN（10）和语音VLAN（110）外，访客VLAN（99）也经过EtherChannel Trunk，这将在以下例子中介绍。

例17-7 Tifosi Catalyst 3750 接入层EtherChannel上行链路QoS设计

! This section configures EtherChannel source-and-dest load balancing

C3750(config)# port-channel load-balance src-dst-ip

! This section configures the (logical) EtherChannel interface

C3750(config)# interface Port-channel1

C3750(config-if)# description ETHERCHANNEL-TRUNK-TO-DISTRIBUTION-LAYER

C3750(config-if)# switchport mode trunk

C3750(config-if)# switchport trunk encapsulation dot1q

C3750(config-if)# switchport trunk allowed vlan 10,99,110

! This section configures Trust-DSCP and (1P3Q3T) Egress Queuing on

! (physical) EtherChannel member-ports

C3750(config)# interface range TenGigabitEthernet1/0/1-2

C3750(config-if-range)# description PORT-CHANNEL1-PHYSICAL-PORT-MEMBER

C3750(config-if-range)# switchport mode trunk

C3750(config-if-range)# switchport trunk encapsulation dot1q

C3750(config-if-range)# switchport trunk allowed vlan 10,99,110

C3750(config-if-range)# channel-group 1 mode auto

! Associates the physical ports with the logical EtherChannel bundle

C3750(config-if-range)# mls qos trust dscp

! The physical port-member interfaces are set to statically trust DSCP

C3750(config-if-range)# queue-set 1

! The interfaces are assigned to queue-set 1

C3750(config-if-range)# srr-queue bandwidth share 1 30 35 5

! The SRR sharing weights are set to allocate 30% BW to Q2

! 35% BW to Q3 and 5% BW to Q4

! Q1 SRR sharing weight is ignored, as it will be configured as a PQ

C3750(config-if-range)# priority-queue out

! Q1 is enabled as a strict-priority queue

17.2 Tifosi园区网分布层QoS设计

Tifosi 园区网的分布层由Cisco Catalyst 4500-E Supervisor 7-E 组成，包括以下策略的组合:

■ 为访客VLAN流量启用微流限速；

■ 为8类QoS模型启用1P7Q1T+DBL出向队列。

下面将相继介绍以上两个园区网分布层QoS 策略。然而，虽然队列policy map 可被应用到以上两个策略中，但为了减少冗余，只展示一次。

17.2.1 策略6:分布层下行链路端口（Catalyst 4500E Supervisor 7-E）

Tifosi Software 想要对源自访客VLAN 的流量实施基于流的限速（将这些流限速到每个流1Mbit/s）。然而，Catalyst 3750 不支持此特性，最近能实施此策略的交换机是使用Supervisor 7-E 的分布层交换机Catalyst 4500E。本例中访客VLAN（VLAN 99）的IP 子网为192.168.10.0/24。

例17-8详述了在连接到园区网接入层交换机的所有分布层下行链路端口所应用的QoS策略。

注释:此策略将限制源自访客VLAN的流量。然而，如果也希望限制发往访客VLAN的流量，这就需要在分布层交换机或（更有效的）Internet边界反向实施相似的策略。以上两种方案都需要修改ACL，将访客VLAN子网匹配为目的而不是源。

注释:入向限速service policy将应用在下行链路EtherChannel的逻辑端口信道接口上，出向队列策略应用在物理接口上。

例17-8 Tifosi案例研究:Catalyst 4500E-Supervisor 7E分布层下行链路设计

! This section defines an ACL to match traffic from subnet

C4500(config)# ip access-list extended GUEST-VLAN-SUBNET

C4500(config-ext-nacl)# permit ip 192.168.10.0 0.0.0.255 any

! Traffic sourced from the 1922.168.10.x subnet is matched

! This section defines a flow record with source address as key

C4500(config)# flow record FLOW-RECORD-1

C4500(config-flow-record)# match ipv4 source address

! Source address is defined as the key tuple

! This section defines the class map to match on USERGROUP-1 ACL

! and specify FLOW-RECORD-1 definition for flow creation

C4500(config)# class-map match-all GUEST-VLAN-SUBNET

C4500(config-cmap)# match access-group name GUEST-VLAN-SUBNET

C4500(config-cmap)# match flow record FLOW-RECORD-1

! A "match-all" class map binds the ACL and flow-record

! to identify unique flows

! This section defines the microflow policer policy map

C4500(config)# policy-map GUEST-VLAN-1MBS-MICROFLOW-POLICER

C4500(config-pmap)# class GUEST-VLAN-SUBNET

C4500(config-pmap-c)# police cir 1m

C4500(config-pmap-c-police)# conform-action transmit

C4500(config-pmap-c-police)# exceed-action drop

! Specifies each discrete microflow is to be limited to 1 Mbps

! This section configures the logical port channel interface

C4500(config)# interface Port-channel1

C4500(config-if)# description ETHERCHANNEL-LOGICAL-INTERFACE

C4500(config-if)# switchport mode trunk

C4500(config-if)# switchport trunk encapsulation dot1q

C4500(config-if)# switchport trunk allowed vlan 10,99,110

C4500(config-if)# service-policy input GUEST-VLAN-1MBS-MICROFLOW-POLICER

! This section configures 1P3Q1T+DBL queuing on physical port-member interfaces

C4500(config)# interface range TenGigabitEthernet1/1-2

C4500(config-if-range)# description PORT-CHANNEL1-PORT-MEMBER

C4500(config-if-range)# switchport mode trunk

C4500(config-if-range)# switchport trunk encapsulation dot1q

C4500(config-if-range)# switchport trunk allowed vlan 10,99,110

C4500(config-if-range)# channel-group 1 mode auto

C4500(config-if-range)# service-policy output 1P7Q1T-QUEUING

! The 1P7Q1T-QUEUING is detailed in Example 17-10

17.2.2 策略7:分布层分布链路/核心上行链路端口

图17-4说明了Tifosi的8类1P7Q1T+DBL出向队列策略。

图17-4 Tifosi案例研究:Catalyst 4500E-Supervisor 7E 8类（1P7Q1T+DBL）出向队列模型

例17-9中详述了此8类1P7Q1T+DBL出向队列策略的相应配置。

例17-9 Tifosi案例研究:Catalyst 4500 8类1P7Q1T+DBL出向队列

! This section configures the class maps for the egress queuing policy

C4500(config)# class-map match-any PRIORITY-QUEUE

C4500(config-cmap)# match dscp ef

! VoIP (EF) is mapped to the PQ

C4500(config-cmap)# match dscp cs4

! Realtime Interactive (CS4) is also mapped to the PQ

C4500(config)# class-map match-all MULTIMEDIA-CONFERENCING-QUEUE

C4500(config-cmap)# match dscp af41 af42 af43

! Multimedia-Conferencing (AF4) is assigned a dedicated BW queue

C4500(config)# class-map match-all SIGNALING-QUEUE

C4500(config-cmap)# match dscp cs3

! Signaling (CS3) is mapped to a dedicated BW queue

C4500(config)# class-map match-all TRANSACTIONAL-DATA-QUEUE

C4500(config-cmap)# match dscp af21 af22 af23

! Transactional Data (AF2) is assigned a dedicated queue

C4500(config)# class-map match-all BULK-DATA-QUEUE

C4500(config-cmap)# match dscp af11 af12 af13

! Bulk Data (AF1) is assigned a dedicated queue

C4500(config)# class-map match-all SCAVENGER-QUEUE

C4500(config-cmap)# match dscp cs1

! Scavenger (CS1) is assigned a dedicated queue

! This section configures the 1P7Q1T+DBL egress queuing policy map

C4500(config)# policy-map 1P7Q1T+DBL

C4500(config-pmap-c)# class PRIORITY-QUEUE

C4500(config-pmap-c)# priority

! Defines a priority queue

C4500(config-pmap-c)# class MULTIMEDIA-CONFERENCING-QUEUE

C4500(config-pmap-c)# bandwidth remaining percent 10

C4500(config-pmap-c)# dbl

! Defines a multimedia-conferencing queue with 23% BW remaining + DBL

C4500(config-pmap-c)# class SIGNALING-QUEUE

C4500(config-pmap-c)# bandwidth remaining percent 2

! Defines a signaling queue with 2% BW remaining

C4500(config-pmap-c)# class TRANSACTIONAL-DATA-QUEUE

C4500(config-pmap-c)# bandwidth remaining percent 25

C4500(config-pmap-c)# dbl

! Defines a transactional data queue with 25% BW remaining + DBL

C4500(config-pmap-c)# class BULK-DATA-QUEUE

C4500(config-pmap-c)# bandwidth remaining percent 4

C4500(config-pmap-c)# dbl

! Defines a bulk data queue with 4% BW remaining + DBL

C4500(config-pmap-c)# class SCAVENGER-QUEUE

C4500(config-pmap-c)# bandwidth remaining percent 1

! Defines a (minimal) scavenger queue with 1% BW remaining/limit

C4500(config-pmap-c)# class class-default

C4500(config-pmap-c)# bandwidth remaining percent 25

C4500(config-pmap-c)# dbl

! Provisions the default/Best Effort queue with 25% BW remaining + DBL

! This section attaches the egress queuing policy to the interface(s)

C4500(config)# interface range TenGigabitEthernet 1/1-8

C4500(config-if-range)# service-policy output 1P7Q1T+DBL

注释:从技术上说，图17-4和例17-9展示的是一个1P6T1T+DBL模型（其中两个类映射到PQ，剩下的6个类映射到非优先级硬件队列）。然而，为了避免混淆，本文中称其为1P7Q1T+DLB。

17.3 Tifosi园区网核心层QoS设计

Tifosi 的园区网核心层由Cisco Catalyst 6500-Supervisor 2T 交换机组（包括WS-X6908-10GE 模块和WS-X6904-40G-2TXL 模块）构成，包含以下策略:

■ 为8类QoS模型（10GE接口）启用8Q4T/1P7Q4T入向/出向队列；

■ 为8类QoS模型（40GE接口）启用2P6Q4T入向/出向队列。

在此例中，到分布层的下行链路是10GE，核心链路是40GE。

17.3.1 策略8:核心层（10GE）下行链路设计

图17-5 说明了Tifosi 10GE 接口的8 类8Q4T 入向和1P7Q4T 出向队列模型。

图17-5 Tifosi案例研究:Catalyst 6500-Supervisor 2T 10GE接口8类（8Q4T入向和1P7Q4T出向）队列模型

例17-10显示了此8类8Q4T入向和1P7Q4T出向队列策略的相应配置。

例17-10 Tifosi案例研究:Catalyst 6500 8类8Q4T入向和1P7Q4T出向队列

! This section configures the class maps for the queuing policy maps

! Note both ingress and egress policy maps share these common class maps

C6500(config-cmap)# class-map type lan-queuing REALTIME-QUEUE

C6500(config-cmap)# match dscp ef cs4

! Voice (EF) and TelePresence (CS4) are mapped to the REALTIME-QUEUE

C6500(config-cmap)# class-map type lan-queuing SIGNALING-QUEUE

C6500(config-cmap)# match dscp cs3

! Signaling (CS3) is mapped to a dedicated nonpriority queue

C6500(config-cmap)# class-map type lan-queuing MULTIMEDIA-CONF-QUEUE

C6500(config-cmap)# match dscp af41 af42 af43

! Multimedia-Conf (AF4) is mapped to a dedicated nonpriority queue

C6500(config-cmap)# class-map type lan-queuing TRANSACTIONAL-DATA-QUEUE

C6500(config-cmap)# match dscp af21 af22 af23

! Transactional Data (AF2) is mapped to a dedicated nonpriority queue

C6500(config-cmap)# class-map type lan-queuing BULK-DATA-QUEUE

C6500(config-cmap)# match dscp af11 af12 af13

! Bulk Data (AF1) is mapped to a dedicated nonpriority queue

C6500(config-cmap)# class-map type lan-queuing SCAVENGER-QUEUE

C6500(config-cmap)# match dscp cs1

! Scavenger (CS1) is mapped to a bandwidth-constrained queue

! This section configures the eight-class ingress (8Q4T) policy map

C6500(config-pmap)# policy-map type lan-queuing INGRESS-8Q4T

C6500(config-pmap)# class REALTIME-QUEUE

C6500(config-pmap-c)# bandwidth percent 33

! Defines the REALTIME-QUEUE with 33% BW

C6500(config-pmap-c)# class SIGNALING-QUEUE

C6500(config-pmap-c)# bandwidth percent 2

! Defines the Signaling-Queue with 2% BW

C6500(config-pmap-c)# class MULTIMEDIA-CONF-QUEUE

C6500(config-pmap-c)# bandwidth percent 10

! Defines the Multimedia-Conferencing-Queue with 10% BW

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp af41 percent 80 100

C6500(config-pmap-c)# random-detect dscp af42 percent 70 100

C6500(config-pmap-c)# random-detect dscp af43 percent 60 100

! DSCP-based WRED is enabled and tuned for AF4 PHB

C6500(config-pmap-c)# class TRANSACTIONAL-DATA-QUEUE

C6500(config-pmap-c)# bandwidth percent 25

! Defines the Transactional-Data-Queue with 25% BW

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp af21 percent 80 100

C6500(config-pmap-c)# random-detect dscp af22 percent 70 100

C6500(config-pmap-c)# random-detect dscp af23 percent 60 100

! DSCP-based WRED is enabled and tuned for AF2 PHB

C6500(config-pmap-c)# class BULK-DATA-QUEUE

C6500(config-pmap-c)# bandwidth percent 4

! Defines the Bulk-Data-Queue with 4% BW

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp af11 percent 80 100

C6500(config-pmap-c)# random-detect dscp af12 percent 70 100

C6500(config-pmap-c)# random-detect dscp af13 percent 60 100

! DSCP-based WRED is enabled and tuned for AF1 PHB

C6500(config-pmap-c)# class SCAVENGER-QUEUE

C6500(config-pmap-c)# bandwidth percent 1

! Defines the Scavenger-Queue with 1% BW

C6500(config-pmap-c)# class class-default

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp default percent 80 100

! DSCP-based WRED is enabled and tuned for default DSCP (0)

! This section configures the eight-class egress (1P7Q4T) policy map

C6500(config-pmap)# policy-map type lan-queuing EGRESS-1P7Q4T

C6500(config-pmap)# class REALTIME-QUEUE

C6500(config-pmap-c)# priority

! Enables strict-priority queuing on the REALTIME-QUEUE

C6500(config-pmap-c)# class SIGNALING-QUEUE

C6500(config-pmap-c)# bandwidth remaining percent 2

! Defines the Signaling-Queue with 2% BW remaining

C6500(config-pmap-c)# class MULTIMEDIA-CONF-QUEUE

C6500(config-pmap-c)# bandwidth remaining percent 10

! Defines the Multimedia-Conferencing-Queue with 10% BW remaining

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp af41 percent 80 100

C6500(config-pmap-c)# random-detect dscp af42 percent 70 100

C6500(config-pmap-c)# random-detect dscp af43 percent 60 100

! DSCP-based WRED is enabled and tuned for AF4 PHB

C6500(config-pmap-c)# class TRANSACTIONAL-DATA-QUEUE

C6500(config-pmap-c)# bandwidth remaining percent 25

! Defines the Transactional-Data-Queue with 25% BW remaining

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp af21 percent 80 100

C6500(config-pmap-c)# random-detect dscp af22 percent 70 100

C6500(config-pmap-c)# random-detect dscp af23 percent 60 100

! DSCP-based WRED is enabled and tuned for AF2 PHB

C6500(config-pmap-c)# class BULK-DATA-QUEUE

C6500(config-pmap-c)# bandwidth remaining percent 4

! Defines the Transactional-Data-Queue with 4% BW remaining

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp af11 percent 80 100

C6500(config-pmap-c)# random-detect dscp af12 percent 70 100

C6500(config-pmap-c)# random-detect dscp af13 percent 60 100

! DSCP-based WRED is enabled and tuned for AF1 PHB

C6500(config-pmap-c)# class SCAVENGER-QUEUE

C6500(config-pmap-c)# bandwidth remaining percent 1

! Defines the Scavenger-Queue with 1% BW remaining

C6500(config-pmap-c)# class class-default

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp default percent 80 100

! DSCP-based WRED is enabled and tuned for default DSCP (0)

! This section attaches the ingress and egress queuing policies

! to the interface(s)

C6500(config)# interface range TenGigabitEthernet 3/1-8

C6500(config-if-range)# service-policy type lan-queuing input INGRESS-8Q4T

! Attaches the INGRESS-8Q4T queuing policy to the interfaces

C6500(config-if-range)# service-policy type lan-queuing output EGRESS-1P7Q4T

! Attaches the EGRESS-1P7Q4T queuing policy to the interfaces

注释:从技术上说，图17-5和例17-10展示的是一个1P6T4T的出向队列模型（其中两个类映射到PQ，剩下的6个类映射到非优先级硬件队列）。然而，为了避免混淆，本文中称其为1P7Q4T。

17.3.2 策略9:核心层（40GE）核心链路设计

图17-6 说明了Tifosi 40GE 接口的8 类2P6Q4T 入向和出向队列模型。

图17-6 Tifosi案例研究:Catalyst 6500-Supervisor 2T 40GE 8类（2P6Q4T入向和出向）队列模型

例17-11提供了此8类2P6Q4T入向和出向队列策略的相应配置。

例17-11 Tifosi案例研究:Catalyst 6500 8类2P6Q4T入向和出向队列

! This section configures the class maps for the queuing policy map

C6500(config-cmap)# class-map type lan-queuing REALTIME-VOICE-QUEUE

C6500(config-cmap)# match dscp ef

! Voice (EF) is mapped to the REALTIME-VOICE-QUEUE

C6500(config-cmap)# class-map type lan-queuing REATIME-VIDEO-QUEUE

C6500(config-cmap)# match dscp ef cs4

! Realtime-Interactive (CS4) is mapped to the REALTIME-VIDEO-QUEUE

C6500(config-cmap)# class-map type lan-queuing SIGNALING-QUEUE

C6500(config-cmap)# match dscp cs3

! Signaling (CS3) is mapped to a dedicated nonpriority queue

C6500(config-cmap)# class-map type lan-queuing MULTIMEDIA-CONF-QUEUE

C6500(config-cmap)# match dscp af41 af42 af43

! Multimedia-Conf (AF4) is mapped to a dedicated nonpriority queue

C6500(config-cmap)# class-map type lan-queuing TRANSACTIONAL-DATA-QUEUE

C6500(config-cmap)# match dscp af21 af22 af23

! Transactional Data (AF2) is mapped to a dedicated nonpriority queue

C6500(config-cmap)# class-map type lan-queuing BULK-DATA-QUEUE

C6500(config-cmap)# match dscp af11 af12 af13

! Bulk Data (AF1) is mapped to a dedicated nonpriority queue

C6500(config-cmap)# class-map type lan-queuing SCAVENGER-QUEUE

C6500(config-cmap)# match dscp cs1

! Scavenger (CS1) is mapped to a bandwidth-constrained queue

! This section configures the Eight-Class (2P6Q4T) policy map

C6500(config-pmap)# policy-map type lan-queuing 2P6Q4T

C6500(config-pmap)# class REALTIME-VOICE-QUEUE

C6500(config-pmap-c)# priority level 1

! Enables strict-priority queuing on the REALTIME-VOICE-QUEUE

C6500(config-pmap)# class REALTIME-VIDEO-QUEUE

C6500(config-pmap-c)# priority level 2

! Enables level-2 priority queuing on the REALTIME-VIDEO-QUEUE

C6500(config-pmap-c)# class SIGNALING-QUEUE

C6500(config-pmap-c)# bandwidth remaining percent 2

! Defines the Signaling-Queue with 2% BW remaining

C6500(config-pmap-c)# class MULTIMEDIA-CONF-QUEUE

C6500(config-pmap-c)# bandwidth remaining percent 10

! Defines the Multimedia-Conferencing-Queue with 10% BW remaining

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp af41 percent 80 100

C6500(config-pmap-c)# random-detect dscp af42 percent 70 100

C6500(config-pmap-c)# random-detect dscp af43 percent 60 100

! DSCP-based WRED is enabled and tuned for AF4 PHB

C6500(config-pmap-c)# class TRANSACTIONAL-DATA-QUEUE

C6500(config-pmap-c)# bandwidth remaining percent 25

! Defines the Transactional-Data-Queue with 25% BW remaining

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp af21 percent 80 100

C6500(config-pmap-c)# random-detect dscp af22 percent 70 100

C6500(config-pmap-c)# random-detect dscp af23 percent 60 100

! DSCP-based WRED is enabled and tuned for AF2 PHB

C6500(config-pmap-c)# class BULK-DATA-QUEUE

C6500(config-pmap-c)# bandwidth remaining percent 4

! Defines the Transactional-Data-Queue with 4% BW remaining

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp af11 percent 80 100

C6500(config-pmap-c)# random-detect dscp af12 percent 70 100

C6500(config-pmap-c)# random-detect dscp af13 percent 60 100

! DSCP-based WRED is enabled and tuned for AF1 PHB

C6500(config-pmap-c)# class SCAVENGER-QUEUE

C6500(config-pmap-c)# bandwidth remaining percent 1

! Defines the Scavenger-Queue with 1% BW remaining

C6500(config-pmap-c)# class class-default

C6500(config-pmap-c)# random-detect dscp-based

C6500(config-pmap-c)# random-detect dscp default percent 80 100

! DSCP-based WRED is enabled and tuned for default DSCP (0)

! This section attaches the ingress and egress queuing policies

! to the interface(s)

C6500(config)# interface FortyGigabitEthernet 1/1

C6500(config-if)# service-policy type lan-queuing input 2P6Q4T

! Attaches the 2P6Q4T queuing policy in the ingress direction

C6500(config-if)# service-policy type lan-queuing output 2P6Q4T

! Attaches the 2P6Q4T queuing policy in the egress direction

17.4 小结

本章继续了Tifosi Software 的案例研究示例，将他们的战略性8 类端到端QoS 模型应用在其多层企业园区网的多个Catalyst交换平台上。

对于园区网接入层策略，本章展示了用于不受信任、受信任和条件信任终端设备的园区网接入层策略，展示了明确配置分类和标记策略，以及Catalyst 3750 上的入向和出向队列策略。

园区网分布层策略除出向队列策略外，使用了Catalyst 4500 基于流的限速特性。

Catalyst 6500 平台的园区网核心层策略包括10GE 和40GE 入向和出向队列策略。

17.5 扩展阅读

企业媒体网服务质量设计4.0:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSCampus_40.html

媒体网园区QoS设计一览:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/qoscampusaag.html

媒体网Catalyst 3560/3750 QoS设计一览:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/qoscampuscat3xxxaag.html

Cisco Catalyst 3750-X 和 Catalyst 3560-X 交换机软件配置指南，Cisco IOS15.0(2)SE 版本——配置QoS:http://www.cisco.com/en/US/docs/switches/lan/catalyst3750x_3560x/software/release/15.0_2_se/configuration/guide/swqos.html

媒体网Catalyst 4500 QoS 设计一览:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/qoscampuscat4500aag.html

Cisco Catalyst 4500系列交换机软件配置指南，IOS XE 3.3.0SG和IOS 15.1(1)SG版本——QoS配置指南:http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/15.1/XE_330SG/configuration/guide/qos_mrg.html

媒体网Catalyst 6500 QoS 设计一览:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/qoscampuscat6500aag.html

Cisco Catalyst 6500系列交换机IOS15.1SYSupervisor引擎2T软件配置指南:QoS配置指南:http://www.cisco.com/en/US/partner/docs/switches/lan/catalyst6500/ios/15.1SY/config_guide/sup2T/qos_overview.html

第4部分 无线LAN QoS设计

第18章 无线LAN QoS设计的注意事项与建议

在无线网络中，QoS的主要作用是减少实时应用在无线媒介传输中的延迟和抖动。QoS在WLAN中的第二个作用是为源于无线设备的流量提供应用管理，其中包括分类（可能与DPI结合使用）、标记和限速。

因此，结合第11章中讨论的一些战略性QoS 设计原则，在WLAN QoS 的设计中，建议遵从以下原则。

■ 在技术条件和管理条件均可行的条件下，在尽可能靠近源的位置对应用进行分类和标记:无线设备可能已经为其始发的流量正确设置了DSCP标记。你可以根据企业的战略性QoS模型，选择信任或者重标记这些标记。除此之外，你还可以使用DPI（深度数据包检测）引擎——比如AVC（应用可视性控制）——来正确地识别源自或去往WLAN的流量。

■ 在尽量靠近源的地方对不需要的流量进行限速:你可能希望对特定WLAN、特定应用或特定用户（或这三者的任意组合）实施带宽限制。

■ 为了防止发生拥塞，在每个节点都启用队列策略，无论该节点发生拥塞的可能性有多小:要知道无线媒介与有线媒介是不同的，因此需要在传输中优化实时流量。

为了更好地理解如何在无线网络中实施这些战略性QoS规则，让我们先来看看无线网络互联技术。

在设计能够支持实时应用（比如VoIP和视频）的802.11网络时，会面临一些新的挑战，并会使用与传统有线以太网络完全不同的范例。尽管在WLAN QoS 的设计中也包含一些熟悉的用法，比如基于DSCP值来区分流量的优先级，但Wi-Fi网络中使用的底层MAC和PHY层协议与有线网络有着本质区别，因此有必要为无线媒介开发一组全新的QoS工具。

802.11 QoS 工具在近10 年慢慢成熟，其中IEEE 802.11e WG（工作组）做出了重大贡献。2007 年，802.11e WG 提出了WLAN QoS 增强版，并将其纳入802.11 标准更广泛的新定义中——IEEE 802.11-2007，其中定义了当前的无线QoS 标准。2012 年，IEEE 802.11-2012 中又纳入了一系列进一步的修订内容。然而要时刻牢记，即使IEEE 802.11 设置了诸多标准，但他们并不负责保证所有厂商都遵从了这些标准。为了解决这一矛盾，Wi-Fi联盟提出了一个无线QoS兼容性标准（基于802.11e增强版和802.11-2012标准），称为无线多媒体（Wireless Multimedia），或更常被称为WMM。

注释:为了避免混淆，除非特别声明，否则本书将替换使用术语WMM和802.11e。

本章会先介绍IEEE 802.11 MAC 层的基本构成，并阐释数据是如何传输到无线媒介上的。这些概念看起来与QoS 没什么关系，但对它们有个基本的了解，对于理解WLAN QoS 的工作原理至关重要，并且这些概念最终会反映到你的网络设计中。接着本章会介绍802.11e和WMM QoS 标准的工作原理，即如何为不同类型的流量提供不同级别的服务，以及如何将这些标准集成到你的网络中。

最后会介绍一些WMM QoS 设计建议，其中包括在基于控制的无线网络中使用的各种QoS标记和队列机制。这部分内容揭示了本章重要的设计建议。

18.1 对比有线和无线LAN环境中的QoS

建议:

■ 理解有线网络和无线网络的基本区别，尤其是涉及QoS的区别。

尽管多数LAN网络在大部分时间都会远低于满负荷运行，但突发流量有时会导致拥塞，因此需要按照优先级顺序，先处理更为重要的流量。这是在有线网络中众所周知的QoS概念，并且也同样适用于无线网络。无论是在铜缆吉比特以太端口部署QoS，还是在无线AP（访问点）射频接口部署QoS，QoS工具都负责通过某种方式，将数据包可靠地传输到网络中。设计良好的有线网络几乎一定能够为高优先级流量提供可靠的传输服务。但在无线网络中，由于无线网络本身半双工的特点，就无法保证为高优先级流量提供完全可靠的传输服务了。

在Wi-Fi网络中，会有一个特定的AP与每个工作站相关联，并且与该AP相关联的所有工作站必须共享射频（RF，Radio Frequency）。这种环境还有一个物理限制，即在指定时间内，只有一个工作站——包括AP自身——能够传输数据。因此每个工作站必须与其他所有工作站争夺传输时间。WLAN的半双工模式并不是自行选择的。在定义中，无线是一种多访问的广播媒介——也就是说若多个工作站同时传输数据，接收方就无法理解每个发送方发送的内容了。

这种情况跟人类有些相似。你有没有试过同时听两个人说话？虽然我们的大脑能够从环绕在我们身边的所有声音中，分辨出哪怕非常微妙的声音，但它几乎无法同时理解两个及以上的声音（或话音）。大脑边缘系统负责把我们真正想听的声音从所有其他背景音中整理出来。因此当两个及以上的人同时跟我们说话时，他们相互之间的话音干扰通常会导致我们无法理解任何内容！另一种情况是你跟谈话的对象同时说话。这样做并不会使交流效率翻倍，反而会使你无法理解对方说了些什么。这个比喻很好地描绘了半双工通信网络的功能。

你完全可以把无线环境与集线器环境进行比较。集线器不仅是半双工媒介，它还是共享的广播媒介。看起来在集线器上实施QoS是不太可能的，你可能会举出很多原因说明QoS根本不会生效，而这也正是802.11无线网络环境面临的挑战。

为了更好地说明这个问题，让我们把半双工共享的无线媒介与现代的有线以太网络进行对比。运行在全双工模式的有线以太网在每两个工作站之间创建一条点到点链路，并允许双方同时发送和接收以太网数据帧。比如一台服务器通过1 Gbit/s 的全双工链路连接到一台交换机，理论上它们可以1 Gbit/s的速率同时发送和接收数据帧，无需与其他工作站争夺访问媒介的机会。

现在我们来看看无线AP是如何通信的，并对比两种通信模式。由于AP所使用的射频频谱是与其连接的所有工作站共享的，在同一时间内，在特定信道内，只能有一个工作站能够发送数据，这样才不会导致干扰现象。若两个工作站同时传输数据，则它们传输的数据都无法被理解，从而导致冲突。无线媒介的这种物理限制意味着所有工作站——甚至AP自身——都必须争得机会来传输自己的数据。如果无线媒介中没有任何机制来协调接下来该谁发送数据，混乱就会产生，并且Wi-Fi网络将变得完全无法使用。

让我们再把水搅浑一些，有线网络都运行在固定的速率之上（比如1 Gbit/s、10 Gbit/s等），而无线网络则运行在可变的速率之上。无线连接的速率受到多重因素的影响，比如干扰模式、SNR（信噪比）和总信号强度。而让情况变得更为复杂的事实是，单个AP所连接的客户端可能使用完全不同的速率来发送和接收流量。

有线网络中的QoS工具主要负责根据数据包的类别，管理接下来将哪个数据包发送到线路上。Wi-Fi网络中的QoS职责就要复杂许多了。因为无线媒介是共享的，也是半双工的，因此QoS工具必须管理数据包进入RF信道的优先级，使所有终端工作站以有序且可预测的方式发送和接收数据。

18.2 WLAN QoS的基本构成

建议:

■ 理解WLAN QoS 是如何发展到当前状态的。

在802.11初期阶段，并没有基于标准的明文规定来支持无线QoS。如果那时你将IP电话或其他实时应用接入到无线网络中，这些设备会尽可能尝试获得媒介的访问机会。在这种情况下，传输质量通常很差，而且有时关键应用甚至根本无法工作。

下一个小节阐述了802.11 MAC 层的基础知识，并详述了与QoS 相关的技术局限性。虽然802.11 MAC 层在一开始根本无法支持QoS，但了解了它的局限性，使你能够更好地理解802.11e WG 对此做出的修改，即令802.11 MAC 层能够支持WLAN QoS。

18.2.1 分布式协调功能

在IEEE 针对Wi-Fi 网络中的QoS 挑战开发出一套应对措施之前，运行在802.11 MAC 层的DCF（Distributed Coordination Function，分布式协调功能）负责调度以太网数据帧并将其传输到无线媒介上。尽管早期的DCF 已经经历了诸多改变，但在当代802.11 MAC 层的运作中仍保留了DCF的基础。仅这一点就使DCF成为了一个重要的主题；理解DCF也是理解当代802.11 QoS 工具集的基础。

Wi-Fi网络是完全平等的环境，也就是所有无线工作站都可以平等地访问无线媒介。事实上，即使是AP，在访问无线媒介这件事上，也没有比客户端工作站拥有更高的优先级。比如无线IP电话与无线笔记本电脑必须遵从完全相同的准则，即使电话传输的是实时VoIP流量，而电脑传输的有可能是P2P流量。由于在指定时间内，每个工作站（进而可以理解为每个应用）有相等的机会来传输数据帧，这就需要一个有序的系统来协调将数据包传输到无线媒介上的行为。如果没有实施任何控制的话，你一定能想象到这样的场景:一旦当一个客户端想要将数据帧发送到无线媒介上，就有极高的可能性发生冲突。与这个AP相关联的客户端越多，发生更多冲突的可能性也就越高。在每次冲突之后，终端工作站会尝试重传数据帧，这可能会导致更多的冲突；而冲突会像滚雪球一样，越来越严重，直到网络完全瘫痪。

18.2.2 CSMA/CA

在早期常使用半双工链路和集线器的有线以太网中，也遇到过类似的问题。在半双工的有线以太网环境中，当多个工作站同时尝试将数据帧发送到线路上的时候，自然就会导致冲突。为了解决这个问题，CSMA/CD（具有冲突检测的载波监听多路访问）系统应运而生。CSMA/CD是一组传输和重传规则，所有终端工作站都必须按照这个规则在媒介上发送数据帧。CSMA/CD规则规定，发送方工作站必须等到媒介空闲之后，才能发送数据帧；因此工作站会监听媒介，以便发现媒介上是否发生了冲突。如果有冲突，工作站会在重新发送数据帧之前，随机等待一段时间。

在802.11无线网络中可以使用CSMA/CD来解决相同的问题吗？与集线器一样，无线网络本质上也是半双工的。但无线网络拥有自己独特的挑战，并不能通过单纯地应用CSMA/CD来解决这一问题。最重要的一点是，无线工作站无法检测冲突，因为工作站每次都是在开放的无线环境中，以广播的形式发送数据帧的。除此之外，有些客户端可能会遇到“隐藏节点”的问题——在监听媒介是否空闲的时候，两个传输客户端可能无法看到对方（它们之间的距离可能太远，或者它们之间可能存在障碍物）。这样就有可能当媒介变为空闲时，两个工作站同时尝试发送数据帧，从而导致冲突。

为了缓解Wi-Fi网络中的冲突问题，CSMA/CD被修改为CSMA/CA（具有冲突避免的载波监听多路访问）。这两个系统之间的主要区别在于:CSMA/CD负责规范冲突发生之后的行为，而CSMA/CA则会在冲突发生之前采取预防措施；并且两者在冲突发生后的重传行为处理上也有所不同。

为了更好地理解，让我们举个电话会议的例子。如果很多人都参加了电话会议，就很可能在线路安静后，两个人同时开始发言，这会导致其他人听到难以分辨的声音（两个发言人导致了冲突）。如果是使用CSMA/CD的环境，当这两个发言人意识到他们同时讲话了，他们就会随机地等待几秒钟后再开始发言，并期望这次的发言不要再与对方冲突在一起。这两个发言人会一直重复这一流程，直到其中一个人先开始发言为止。

CSMA/CA是一个更为文雅的系统。与会者并不会当线路看似空闲时就直接开始发言（并期望没有其他人与你同时开口），而是会在线路空闲后，所有人都耐心地等待一段随机时长。如果线路一直是空闲的，你就可以在你的随机等待时间超时后开始发言。一旦你开始发言了，其他人必须尊重这一事实，并且不能打断你。

通过电话会议例子的描述，我们知道了CSMA/CA会监听并等待，以便了解当前是否有正在进行的传输行为，并且只有当它自己的随机等待时间超时后，它才会尝试发送数据帧。如果在监听并等待后仍然发生了冲突（因为两个工作站仍有可能同时开始传输数据帧），无线工作站的做法与CSMA/CD类似——再等待一段随机的退让时间，然后重新发送数据帧。

要知道，CSMA/CA永远不能绝对保证不发生冲突；它只是通过尝试避免将要发生的冲突，来降低冲突发生的可能性。CSMA/CA有点儿像是让你在十字路口停下来的机制。尽管你会在进入十字路口之前仔细观察其他方向的车流，并极力避免发生冲突，但你永远无法完全确保其他司机会做什么。如果看起来其他人都让你先走，你就踩了油门，仍有轻微的可能性其他司机也做出了相同的判断；因此发生冲突的可能性并没有完全消除。使用CSMA/CA的WLAN工作站也是这样:尽管工作站会在发送数据帧之前监听网络情况，但永远无法完全确保工作站发送数据帧后不会发生冲突。

那么发送方工作站如何能够知道数据帧的传输是否成功？由于无线媒介具有广播的本质，因此实际上无法检测到冲突，只能通过降低概率的措施来避免冲突；但很明显工作站需要确认数据帧的传输是否成功。DCF解决了这一问题，它确保当接收方工作站成功收到数据帧之后，返回确认消息。举例来说，若一个无线工作站传输数据帧后没有收到确认消息，它就知道必须重传这个数据帧；反之如果收到了确认消息，它就知道可以发送下一个数据帧了。

你可能想到了一个有趣的问题:确认消息帧有没有可能遇到冲突，如何消除这种可能性？为了解决这个问题，DCF规定当一次传输完成后，所有客户端都必须保持安静，因此接收方工作站有机会发送确认消息。这段时间称为 SIFS（短暂帧间隔）。

18.2.3 DCF竞争窗口

为了帮助控制和组织无线媒介上的数据帧传输，DCF使用了一些聪明的规则，比如工作站在将各自的数据帧发送到信道上之前，必须等待一段互不相同的时间。DCF工作原理中的中心且最重要的概念是DIFS（DCF帧间隔）。DIFS是事先确定且固定的等待计时器，所有工作站必须等待这个计时器超时，然后才能尝试将数据帧传输到信道上。

注释:802.11网络中使用了多种IFS（帧间隔），比如SIFS（短暂IFS；前文提到过）和PIFS（点协调IFS）。但这部分着重介绍DIFS，因为它与IEEE 802.11e QoS工具集有着更为直接的关系。

DIFS计时器是如何避免无线网络中的冲突的？前文已经介绍了，CSMA/CA为无线工作站提供了一个“先听再说”的框架。当无线工作站想要传输数据帧时，它首先要做的是等待一段特定的DIFS时间。在DIFS超时后，若媒介还是空闲的，无线工作站就可以发送数据帧了。对于所有希望传输数据帧的工作站来说，DIFS像是一个等级设置。如果所有工作站的传输队列中一排入数据帧，它就发送数据帧的话，冲突将会非常多。通过等待DIFS时间，每个工作站都有机会再次确认信道确实空闲并能够传输数据帧。

当工作站检测到媒介非空闲时会发生什么？在这种情况下，工作站必须等待（专业一点的说法是工作站将会推迟）一段随机的时间，这段随机时间称为竞争窗口（CW，Contention Window）。当工作站第一次需要推迟时，CW退让时间是随机设置的，设置范围是零至最大值（CWmin）。等待一段随机时间段的好处显而易见:如果多个工作站同时尝试传输数据帧，冲突就会持续发生，信道永远无法正常工作。在CW计时器超时后，工作站会再次查看媒介是否空闲。若信道空闲，工作站就会开始发送数据帧。图18-1描绘了这一过程。

图18-1 在CW随机退让时间超时后发送数据帧

那么当CW计时器超时后，媒介仍然繁忙，会发生什么？在这种情况下，发送工作站会做出以下行为。

1.冲突。为了解决这一问题，DCF 工作站首先会再次推迟，直到无线媒介空闲为止。

2.所有工作站必须等待DIFS计时器超时。

3.已经之前使用了双倍CW值，工作站将会再次推迟，这次会使用新的随机时间。

4.如果媒介空闲了，工作站就会发送数据。

如果工作站在等待了一段很长的CW后，发现媒介仍未空闲，它会重复这一行为；并且每次都会加倍等待发送数据帧的退让窗口。工作站会持续这个翻倍行为，直到退让窗口达到最大时间值，即CWmax值；在这个过程中，工作站可能会找到机会传输数据帧，否则就会在TTL（生存时间）超时后丢弃数据帧。CW计时器超时后，若媒介变得空闲，工作站就会发送数据帧。

那么工作站每次倒计时的时长到底是多少呢？其实CW的单位并不是秒，而是以太网时隙（Slot Time）。以太网时隙是根据射频网络的RF 特征，从PHY 中得出的时间值，因此每个网络中的以太网时隙都不一样，不过实际的时间是以微秒为单位的。比如在IEEE 802.11n环境中， CWmin默认是15个以太网时隙，CWmax是1023个以太网时隙。

举个例子来说明以太网时隙是如何工作的。如果工作站的随机退让参数一开始设置为10个以太网时隙，那么第二次退让就是20个以太网时隙。如果信道仍然繁忙，CW退让值就会增加为40、80、160，直到增加为最大值1023个以太网时隙。一旦设置了CW值，工作站就必须等待这个数字倒计时为0，然后才会尝试再次发送数据帧。

图18-2描绘了当工作站想要将数据帧发送到无线媒介时，完整的DCF决策过程。

我们已经知道了DCF传输数据帧的理论过程，现在让我们看一个真实环境中的案例，来了解无线工作站如何发送数据帧。图18-3描绘了这个案例，其中5个工作站关联到同一个AP，并且几乎同时尝试发送数据。

在本例中，工作站A已经开始发送以太网数据帧了。工作站B、C和D也想要发送数据帧，但由于工作站A已经在传输过程中了，其他工作站必须等待并推迟，直到信道变得空闲为止。图18-3所示为当工作站A完成传输行为后，其他工作站也必须先等DIFS超时后，才能尝试发送数据帧。

当DIFS超时后，这三个工作站同时想要传输数据，因此它们必须竞争发送机会。由于三个工作站要争夺接入媒介的机会，它们都要运行一个CW（竞争窗口）随机退让计时器。在本例中，由于工作站B生成的随机退让周期最小，因此它会最先发送数据帧。

在工作站B发送数据的过程中，工作站C和D的退让计时器也超时了。但它们仍需等待工作站B完成传输后，才能再次尝试发送。在DCF“先听后说”的和谐氛围中，工作站C和D会耐心等待工作站B完成传输行为。注意在工作站B的传输过程中，工作站E也突然想要发送数据了，因此这时又变成了三个工作站竞争接入媒介的机会。工作站B传输完成后，三个工作站仍需等待DIFS超时，并且它们都会随机生成一个计时器。在本例中，工作站D争得了发送机会，而工作站C和E必须等待下一轮。

图18-2 DCF决策过程

图18-3 DCF的操作

现在你已经掌握了DCF（分布式协调功能）的基础知识。尽管目前介绍的DCF与QoS没有太大关系，但开发出QoS工具集的基本原则来自于此；下一个小节将介绍这部分内容。

18.3 IEEE 802.11e和WMM

建议:

■ 了解802.11e中对于DCF的增强，以及如何在WLAN中通过WMM模型实现QoS。

从前文对DCF模型的分析中可以看出，针对不同类型的流量并没有特殊的做法，因此使用传统DCF并无法实施QoS。要想在无线网络中支持QoS，面临的挑战确实很多。比如如何能在半双工环境中添加QoS？共享的多访问媒介如何能够将一种流量类型的优先级提高？为了应对这些挑战，802.11e工作任务组增强了原始的802.11定义，针对DCF的操作做出了一些修改，帮助其构建差分服务模型。802.11e针对DCF模型的修改纳入了更广泛的802.11-2012标准中，该标准是对原始802.11定义的更新。

除了修改DCF之外，802.11e还提出了在射频网络中应用CAC（呼叫准入控制）的方法，对客户端提供了省电增强特性，还增强了点协调功能（PCF，Point Coordination Function）——称为混合控制信道接入（HCCA，Hybrid Controlled ChannelAccess）。

注释:DCF从没有得到广泛应用，PCF是它的替代品。

下一小节介绍了DCF操作中微小但重要的改变，通过这种改变增强了QoS的部署。

18.3.1 DCF技术改造:增强型分布式信道接入

802.11e工作任务组为整个802.11定义提出了诸多增强内容，但其主要目的是在无线射频接口上引入一个智能系统来实施流量队列。这个工作任务组提出的最为重要的增强内容之一，是改变了MAC层接入到物理信道的方式。正如上一节提到的，在第一次引入802.11时，DCF掌管着MAC层的流量发送规则。但DCF模型的局限性导致无法针对不同类型的流量实施任何差分服务。为了解决这个问题，802.11e工作任务组开发出了一项新的MAC层协议，即增强型分布式信道接入（EDCA，Enhanced Distributed Channel Access）。

EDCA在DCF的基础上引入了5个主要的增强内容，从而为Wi-Fi网络提供了一组QoS工具集。增强内容如下所示。

■ 建立了4 条优先级队列，或称为接入类别（AC，Access Category）。

■ 为每个AC使用不同的帧间隔，而不是为所有流量使用统一固定的DIFS。

■ 为每个AC使用不同的CW（也就是为每个AC设置不同的CWmin和CWmax）。

■ 传输机会（TXOP，Transmission Opportunity）。

■ 呼叫准入控制（CAC；TSpec）。

EDCA在很多方面都与DCF类似，尤其是它也使用基于竞争的接入模型，这意味着每个工作站负责自己到信道的接入。802.11e工作任务组也提出了HCCA，这是一个由中心负责协调的接入模型，即AP负责告诉每个工作站轮到它发送流量了；但很大一部分市场只采纳了EDCA。在使用EDCA时会区分不同的优先级，即根据每种类型的流量在传输前必须等待的时长，为不同类型的流量分配不同的接入级别。

在无线QoS，尤其是EDCA的学习中，有一点至关重要:有线环境中的严格优先级队列可以使一种类型的流量优于另一种，并确保高优先级流量的传输；但EDCA与此不同，它无法为高优先级流量的传输提供任何保证，它只是为其提供了更大的传输可能性。

接下来的几个小节将会逐一介绍前文列出的5项EDCA的重要增强内容。

1.接入类别

802.11 EDCA 和WMM 指定了4 种不同的接入类别（AC），如表18-1 所示。

表18-1 EDCA/WMM接入类别的定义

接下来的章节主要关注Cisco WLC（无线LAN 控制器）的QoS 设计，但你可能还想知道WLC对这4个接入类别的命名规范。表18-1中列出了Cisco在WLC 5500系列控制器（AireOS控制器）中，为这4个AC设置的贵金属命名规范，其中Platinum（白金）代表WMM语音AC，Gold（金）代表WMM视频AC。

为了区分不同的服务类别，802.11e以太网数据帧的头部包含一个3比特字段，称为802.11e UP（用户优先级）。802.11e UP 类似于在有线的802.1Q 以太网Trunk 链路上使用的802.1p CoS 字段；只是802.11e UP 值仅用于无线工作站之间。

与有线802.1Q Trunk 连接中使用的802.1p CoS 字段类似，802.11e UP 字段的3 个比特也可以表示8个服务类别。现在的问题是如何将这8个服务类别与802.11e/WMM标准中的4个AC关联起来。

表18-2 列出了4 个无线AC 与802.11e/WMM UP 值的对应关系。为了便于参考，表中还列出了这些AC 的名称，这是Cisco AireOS WLC 中的命名方式。再明确一次，Cisco 没有为这4个AC使用一般的WMM命名，而是使用贵金属命名系统，每个名称直接与一个AC相关联。

表18-2 EDCA/WMM接入类别

当每个射频接口收到数据后，它会将数据分配到4条出向队列之一，这4条出向队列与4个AC（见表18-2）相对应。EDCA 机制会根据802.11e UP 值（指出数据类型），将数据帧分配到相应的接入类别中。一旦将数据帧分配到合适的AC后，射频接口就会根据这个AC的优先级，尝试将数据帧发送到媒介上。这样一来，AC实际上就充当了数据队列，等着将自己的流量发送到媒介上。本章后续小节中将介绍处理和传输这4个AC流量的规则。

图18-4展示了数据帧流排队等待传输的过程。

图18-4 应用类和队列

802.11e/WMM AC 模型中有一点容易让人混淆，即语音流量被映射为CoS 6，而不是CoS 5，这与有线网络中使用的标准802.1p有所不同。这一点区别常为想要在整个网络中实施一致QoS的网络工程师带来极大的困惑，因为用于语音流量的一般QoS标记机制在有线和无线网络中是不同的。尽管如此，这种标记确是802.11e和WMM定义的，因此必须这样使用。

注释:导致这种差异的根本原因在于第3层标记标准（DSCP，定义在RFC 2474和4594中）是由IETF定义的，而第2层标记标准（CoS和802.11e UP）是由IEEE定义的。网络工程师要想同时使用L2和L3标记，就必须解决这个令人迷惑且不一致的标记机制。本章稍后内容将对此进行详细介绍。

2.仲裁帧间隔

传统DCF模型的一个重要局限性是，所有流量类型的DIFS值都一样。我们要记住的一个规则是，一旦信道宣称自己可用了，所有想要发送数据的工作站都必须在当前的传输完成后，等待相同的DIFS时间；这就产生了一个问题，如果有多个工作站都想要发送数据，它们全都要等待完全相同的DIFS时间间隔，无论这些数据对于延迟的敏感度如何，都不会区别对待高优先级或低优先级流量。

为了解决这个问题，EDCA为数据和管理数据帧引入了变化的IFS周期，称为仲裁帧间隔数（AIFSN，Arbitration Interframe Spacing Number）。为每个AC 分配不同IFS 值的目的在于，为较高优先级的AC分配较短的IFS，使其等待时间比较低优先级的AC短。这种方法为高优先级流量提供了更大的优先传输可能性。

AIFSN通常是可以配置的，EDCA中定义的默认值（单位是以太网时隙）见表18-3。

表18-3 EDCA/WMM的默认AIFSN

表18-3清晰地显示出语音和视频队列拥有更小的AIFSN，你可以期望这些延迟敏感的数据总是会获得优先传输，从而解决了无线网络中的QoS问题。为不同队列分配不同的IFS值确实为改善QoS做出了很大贡献，但要记住，无线媒介仍是一项多访问技术，在这个环境中仍可能发生冲突。因此AIFSN真正解决的问题其实是:通过为较高优先级流量分配较小的AIFSN，极大地提高了较高优先级流量优先接收服务的可能性。但这种方法仍然无法保证网络中不会出现冲突。

3.竞争窗口的增强

在传统DCF环境中，一旦DIFS超时了，每个工作站都会以随机的CW周期进行退让。正如为所有类型的流量使用一样的DIFS，DCF通常不会在CW期间对高优先级流量提供优先服务，也就是说所有类型的流量在竞争下一个传输机会时，都拥有相同的可能性。

EDCA中引入的最后一项增强内容是为更高优先级的流量分配更短的CW随机退让周期，这使语音或视频数据帧更有可能在尽力而为或背景数据帧之前，获得传输服务。这对于延迟敏感的流量（比如语音和视频）尤其重要，如果让它们等待CWmax，将极大降低这类应用的质量。与为不同的优先级队列分配不同的AIFSN值类似，不同的CW值也使较高优先级流量更有可能在有机会发送数据之前，等待较短的时间周期，同时降低了长CW等待时间对于延迟敏感流量的影响。

表18-4 列出了802.11a/g/n 中定义的的默认EDCA CW 值。

表18-4 EDCA/WMM的默认CW值

表18-4显示出语音流量只需退让3～7个以太网时隙；背景流量的退让范围是15～1023个以太网时隙（这与传统DCF CW退让周期相同）。语音流量生成的CW永远会小于视频流量，视频流量生成的CW永远会小于尽力而为或背景流量。因此在使用EDCA时，较高优先级队列会比较低优先级队列更频繁地获得服务。

把这些修改放到一起，图18-5展示了改进的IFS和CW退让计时器一起工作，提高了高优先级流量整体的操控性。在本例中，语音队列在尝试将数据发送到信道上之前，要等待5个以太网时隙（2个AIFS时隙和随机生成的3个CW时隙），这为语音流量赶在所有其他流量之前被发送到信道上的可能性大大增加了。

图18-5 AIFSN和CW大小

案例中展示了AIFSN和CW值如何通过协同工作，降低较高优先级类型流量的等待发送时间，从而提升QoS性能。

4.传输机会

除了前文提到的三种增强内容外，EDCA还提供了无需竞争的接入周期，称为传输机会（TOXP，Transmission Opportunity）。TXOP 是指一定的时间段，在这段时间内，无线工作站能够尽可能发送更多的数据帧，而无需与其他工作站竞争发送机会。在传统的DCF模型中，一旦一个工作站接入到了媒介中，只要它想，它就可以一直持续发送数据帧。你可以把这种情况想象为小孩刚得到了一个新玩具，这时他才不会把玩具分给别人，会一直到他玩腻了为止。当一个工作在低数据速率的工作站获得了接入媒介的机会，它也会迫使其他所有工作站等到它完成传输为止。

在使用EDCA的TXOP增强特性时，每个工作站都有一个TXOP时间限制，在这段时间内它可以传输数据。当TXOP时间限制超时后，它必须让出接入媒介的机会。

5.802.11e TSpec:呼叫准入控制

这是802.11e引入的最后一个重要增强特性，它使得EDCA能够在拥塞期间很好地维持QoS。在传统有线网络中，这种控制是通过在出向接口上使用严格优先级队列来实现的。不过前文也已经提到了，由于802.11使用的是基于竞争的模型，因此在无线网络中无法实施这类控制行为。在深入了解基于竞争的接入工作方式后，你会发现无线媒介的性能很容易受到拥塞的影响。

为了更好地说明这个问题，假设无线网络中有很多工作站在同时竞争接入网络的机会。随着传输的流量越来越多，也会有越来越多的工作站加入竞争行列，并且所有工作站处于退让状态的时间也会越来越长。以上描述最终导致的结果就是所有工作站的性能都受到了影响。

802.11e通过使用名为传输定义（TSpec，Transmission Specification）的呼叫准入控制（CAC， Call Admission Control）机制解决了这个问题。TSpec会使正在进行中的实时应用（比如语音呼叫）的优先级高于新的呼叫请求。为了使用EDCA的这项特性，必须在AP上配置TSpec，并可选的在客户端工作站上配置TSpec。

强烈建议在部署了实时应用的网络中使用TSpec，因为这样一来客户端工作站能够向AP发送他的流量要求（也就是数据速率、省电模式、帧大小等信息）。客户端在发送特定优先级的流量类型之前（这是由AC负责管理的），必须先通过TSpec机制来请求准入许可。举例来说，WLAN客户端设备想要使用语音AC，它必须首先发出使用AC的请求，来确定网络上是不是有足够的带宽能让它使用。如果AP认为网络中没有足够的带宽，AP就会拒绝客户端工作站的请求，从而保护了当前正在发送数据的工作站的质量。

18.4 QoS设计的注意事项

建议:

■ 明确上游与下游的QoS要求；

■ 认识到IEEE 与IETF QoS 模型之间的差异；

■ 使用L2/L3映射来消除这些差异:

■ 明确上游的QoS标记/映射战略；

■ 明确下游的QoS标记/映射战略。

当管理员配置AP与集中式WLC协同工作时，WLC是通过CAPWAP（无线接入点的控制和部署，Control and Provisioning of Wireless Access Point）协议来控制AP 的，CAPWAP 使用UDP 5246（控制流量）和5247（数据）端口。CAPWAP 定义在RFC 5415 和5416 中。

IEEE 802.11 标准在管理Wi-Fi 网络中重点关注无线媒介的L2 层面，IETF 的RFC 文档关注无线通信的L3层面。无线网络L2和L3标准的结合会带来一系列有趣的结果，但这种工作的最终结果是产生了一个在IP 骨干中通过CAPWAP 传输L2 802.11 无线数据帧的系统。因此CAPWAP实际上的功能有些类似L3隧道技术，802.11无线以太网数据帧通过CAPWAP隧道，在控制器和AP之间传输（CAPWAP隧道只存在于控制器和AP之间，与终端用户的无线设备无关）。

为了在WLAN和传输网络中维持IP数据包的QoS一致性，必须实施端到端的L3 QoS标记。

为此，必须在CAPWAP隧道和有线的基础设施上实施DSCP和CoS值的映射。下一个小节将会介绍上游和下游的QoS标记战略。

18.4.1 明确上游和下游数据流

先来明确一下在无线QoS章节中使用的一些术语。

■ 上游:指的是从移动无线设备向有线网络基础设施发送的数据包流，包括以下内容。

■ 射频上游:描述的是WLAN客户端向AP发送的流量。WMM通过无线媒介，向WLAN客户端提供上游QoS。每个IP数据包都拥有内部DSCP标记，用于在IP网络中划分优先级。

■ 网络上游:描述的是离开AP后去往WLC的流量。这些流量是封装在CAPWAP中的。CAPWAP隧道中的DSCP值可能与数据包的内部DSCP值不同。有线网络的园区QoS策略负责部署上游QoS。

■ 下游:指的是从有线网络基础设施向无线设备发送的数据包流，包括以下内容。

■ 网络下游:描述的是离开WLC后去往AP的流量。这些流量是封装在CAPWAP中的。有线网络的园区QoS策略负责部署上游QoS。

■ 射频下游:描述的是离开AP后去往WLAN客户端的流量。WMM负责向WLAN客户端提供上游QoS。

图18-6展示了本书中使用的上游和下游无线QoS术语。

图18-6 上游和下游QoS

18.4.2 QoS映射和标记的注意事项

在为无线网络实施QoS设计战略时，需要考虑的首要因素是如何将无线网络的QoS模型与有线网络中使用的QoS设计结合到一起。无线网络的工程师面临的一大难题是:建议在无线网络中使用的IETF DSCP 到IEEE 802.11e UP QoS 映射机制，与有线网络中使用的IETF DSCP 到IEEE 802.1p CoS 映射模型之间有着极大区别。在实际应用中，管理员会使IEEE 标记机制与IETF进行同步；但其结果是语音、视频、信令和其他流量最终都使用了不匹配的标记机制。

为了保持无线网络和有线网络中的QoS一致性，为了获得端到端的QoS设计，对于在这两种网络之间传输的数据包，必须慎重考量如何处理和映射它们的QoS标记。

表18-5 中比较了在使用802.11e UP 和802.1q CoS 标记系统时，Cisco WLC 为各种流量类型使用的DSCP 标记。表中还列出了为这些值使用的AireOS WLC QoS 配置文件，便于参考。

表18-5 DSCP到802.11e UP和DSCP到802.1p CoS的QoS映射表

表18-5中显示出了IEEE 802.11e UP值与IEEE 802.1p CoS值之间的区别。举例来说，语音流量被标记为DSCP46，在有线网络中被映射为CoS 5，但在无线网络中被映射为802.11e UP6。

这是在设计中需要着重考虑的一点，只有这样才不会在部署QoS战略时，遇到标记不一致的情况。在调整这两个映射机制时，WLC会自动将DSCP值映射为表18-5中相应的值，这种行为在上游和下游方向上是一样的。

表18-5 中并没有说明IEEE 802.1e UP 的映射机制是如何计算的，其实它使用了DSCP 值的3 个MSB（最高有效位）比特。以DSCP 32（二进制为100 000）为例，与MSB（100）相等的十进制为4，因此DSCP 32 被映射为802.11e UP 4。

表18-5 中除了列出例外情况外，还显示出有些DSCP 到802.11e UP 的映射值与通常用于有线网络的标准802.1p CoS 值完全相等。这就会让人感到混淆，除了表18-5 中列出的众所周知的例外情况外，看起来802.1p CoS 模型和802.11e UP 模型的数值都是按顺序排列的。表18-6 中总结了WLC 中使用的默认映射方式，即将DSCP 值映射为802.1p CoS 值和802.11e UP值。事实上，WLC会当数据包来自或去往无线网络时，自动执行相应的映射，无需你去处理这种复杂的情况；但它仍具有一定的局限性，尤其是在使用基于AireOS的控制器时。更新的基于IOS的控制器允许管理员自定义映射表，但在基于AireOS的控制器上无法修改这些默认的映射关系。

表18-6 默认的DSCP到802.11e UP和802.1p CoS映射（除了表18-4中提到的例外情况）

18.4.3 上游QoS标记战略

在将DSCP 到802.11e UP 和802.1p CoS 映射方式准备就绪后，现在需要解决的问题是在哪里实施这种标记的转换，以及如何实施。

上游QoS的目标是确保所有IP数据包都能够在以下路径中维持自己的QoS标记和服务级别:从无线客户端发出、通过AP、进入CAPWAP隧道、通过WLC并最终进入LAN交换机。尽管这条路径上看起来经过了很多跳，但从全局看来，这条路径上只涉及了以下两个QoS重映射步骤。

1.AP 收到上游数据帧之后，会将该数据帧的802.11e UP 标记转换为CAPWAP 隧道外部的DSCP值。数据帧从源无线设备获得的内部DSCP标记会被保留，并不会被更改。

2.WLC 将CAPWAP 数据包封装后，会使用原始IP 数据包的DSCP 值来生成相应的IEEE 802.1p CoS 值，并将数据包发往有线网络交换机。

图18-7中展示了在IP数据包从无线客户端一路发往有线交换机的全过程中，QoS标记是如何保留的。

现在进一步看看这两个步骤，从无线客户端发出数据包开始。

当数据包从无线客户端设备发出时，应用程序或操作系统会自动为它们标记上适当的DSCP值。当然也有些应用根本不会标记DSCP值，也有时候应用标记的DSCP值会被OS覆盖。不过在这里我们为了简化案例的复杂性，假设无线客户端已经正确标记了数据包的DSCP值。

图18-7 上游QoS映射

当客户端设备的WMM射频接口分类了这些数据包之后，DSCP值会在内部映射为相应的IEEE 802.11e UP 值（参照表18-5），然后会根据802.11e UP 值，通过相应的AC 来发送这个802.11数据帧。

注释:如果客户端不支持WMM，数据包中就不会标记802.11e UP值（因为只有WMM能够支持802.11e UP），那么AP就只好对这种流量应用默认的QoS设置。下一章对会详细介绍这种情况。

AP 接收到802.11 无线网数据帧后，它会查看数据帧的802.11e UP 标记，并自动将其映射为相应的DSCP值，然后将这个DSCP值写入CAPWAP隧道外部的IP包头中。举例来说，如果这个无线网数据帧是语音的话，那么它携带的802.11e UP 值为6，CAPWAP IP 隧道外部的DSCP标记会自动将这个值映射为46（EF），这与IETF标记机制对于语音RTP数据包的标记是相符的。然后数据包会通过IP网络，发往WLC。在这里一定要明白，这个上游CAPWAP DSCP值（这个值最终会被用在IP骨干网络的队列机制中）并不是直接来自于数据包内部的DSCP值，而是从入站的上游UP值得来的。

从底层IP传输网的角度看来，CAPWAP隧道就是一组携带特定DSCP值的UDP数据包流，需要根据IP包头中的DSCP标记来为其提供适当的QoS等级。IP传输网可能会使用标准的4类、8 类或12 类模型，因此它会像处理其他数据包那样，处理这些UDP CAPWAP 数据包。

当WLC收到了通过CAPWAP隧道发来的无线以太网数据帧，它会检查数据包的内部DSCP 值，并自动将其映射为适当的802.1p CoS 值，然后通过802.1Q Trunk 端口将数据包发往直连的有线交换机。举例来说，假设数据包的DSCP 值是46，WLC 就会自动将CoS 5 写入数据包的802.1p头部中。

从这个案例中就可以看出，对于每个穿越网络的语音数据包来说，一开始的QoS标记是DSCP 值46 和802.11e UP 值6，然后在CAPWAP 隧道的外部头部中映射为DSCP 值46，最终在有线端口上映射为802.1p CoS 值5。一个数据包要经历这么多次变化！

注释:别忘了，802.11e UP值只应用于WMM客户端。如果客户端不支持WMM，那么这个WLAN获得的只能是默认QoS行为。

18.4.4 下游QoS标记战略

下游QoS的处理过程与上游的行为非常类似。与上游模型一样，下游QoS的目标是确保所有IP数据包都能够在以下路径中维持自己的QoS标记和服务级别:从有线LAN交换机发出、通过控制器去往AP、最终到达无线客户端。与上游方向一样，这条路径上也涉及了两个QoS重标记步骤。

1.携带802.1p CoS 标记的数据帧到达WLC 有线网络侧的接口。WLC 会检查IP 数据包的内部DSCP值，然后将这个值直接复制到CAPWAP数据包头部的DSCP位（要注意802.1p CoS 值并不用来决定CAPWAP 头部中的DSCP 值）。

2.AP 收到入站的CAPWAP 数据包后，它会检查CAPWAP 头部的DSCP 值，并将其映射为适当的802.11e UP 值，然后将这个值写入802.11 无线以太网数据帧的头部，最后将数据帧发到无线媒介上。

图18-8描绘了下游QoS重标记和映射的过程。

现在来进一步分析一个案例，看看从有线LAN交换机一路发往无线客户端的过程中，数据包的QoS标记是如何变化的。

当下游以太网数据帧离开有线LAN 交换机的802.1Q Trunk 端口时，它们携带着802.1p CoS值，这个值对应着IP数据包的DSCP值（从DSCP值的三位MSB得出，详见表18-4）。当以太网数据帧到达WLC 后，控制器会将802.1Q Trunk 中的不同VLAN 分隔开，将其归入适当的无线SSID（服务集标识符）网络，并将以太网数据帧分配到正确的无线网络中。完成以上操作后，WLC会使用原始IP数据包中的DSCP值，将其复制到CAPWAP隧道的头部中，以确保在IP 传输网中，数据包能够获得正确的QoS 服务。注意802.1p CoS 值并不用于决定CAPWAP DSCP 标记。

图18-8 下游QoS标记

当以太网数据帧通过CAPWAP隧道到达AP后，AP会将CAPWAP IP头部的DSCP值（这个值与内部DSCP 值相同）映射为相应的802.11e UP 值（参照表18-4），然后通过无线媒介将数据帧发送到客户端。这样一来，下游QoS的操作就比上游模型简单很多，因为无线网络中只需（在AP上）进行一次智能映射即可，而上游模型则需要进行两次智能映射，分别在无线客户端和AP上。

18.5 小结

本章一开始介绍了有线网络与无线网络之间的重大区别，这些区别导致两种网络要使用不同的方法来解决QoS 问题。然后讨论了最终使802.11 WLAN 能够部署QoS 的传统协议和基本技术构成，其中包括CSMA/CA和DCF。在802.11早期版本中，DCF提供了一种机会平等的基于竞争的模型，所有无线客户端都能以相同的方式接入无线媒介。这种模型奠定了802.11 WLAN的基础，但这时还没有任何差分服务或QoS的概念。

接着本章详细介绍了IEEE 802.11e 工作任务组提出的重要QoS 增强特性。尤其是对于传统DCF作出的5项内容，即EDCA:

■ 建立接入类别；

■ 根据流量类型调整帧间隔；

■ 根据流量类型调整竞争窗口大小；

■ 传输机会；

■ 通过TSpec实现呼叫准入控制。

之后本章详细介绍了DSCP 到802.11e UP 的QoS 标记机制（以及如何将其与DSCP 到802.1p CoS 标记相关联），讨论了这两种QoS 标记机制之间的不一致性，以及这种不一致的部署会对端到端QoS设计带来何种影响。

最后讨论了上游和下游QoS的处理方式，以及不同的重标记机制如何为无线网络提供了全面的QoS服务。

18.6 扩展阅读

IEEE 802.11标准页面:http://standards.ieee.org/about/get/802/802.11.html

Wi-Fi联盟WMM白皮书:http://www.wi-fi.org/media/press-releases/backgrounder-wi-fi®-quality-service-features-enable-connected-world

IETF CAPWAP页面:http://datatracker.ietf.org/wg/capwap/charter/

Cisco WLC默认QoS标记和转换规则:http://www.cisco.com/en/US/partner/docs/wireless/controller/7.4/configuration/guides/consolidated/b_cg74_CwONSOLIDATED_chapter_01010111.html#ID1534

第19章 集中式（Cisco 5500无线LAN控制器） QoS设计

要想设计一个使用Cisco 集中式WLC（无线局域网控制器，WLAN Controller）来支持语音和视频的无线网络颇为复杂。举例来说，除了在WLAN中实施QoS这种基础设计元素之外，还要考虑适当的射频（RF）要求，以便支持可接受的数据速率并降低干扰。另外还有必要在AP（接入点）之间启用高速漫游，这样语音和视频呼叫才不会由于终端设备到处移动而质量下降甚至通话中断。除此之外，还要考虑如何保障网络中实时应用的安全性。

上述所有主题对于WLAN整体设计来说都至关重要，需要谨慎考量，而且它们也对用户体验的质量贡献良多（尤其在用户使用实时应用时），但本章的重点是QoS。因此，本章假设你已经正确设置了足够的RF覆盖范围、漫游和安全特性，现在需要做的就是考量QoS的组成部分。

本章一上来先全面地介绍了端到端QoS设计，其中包括与有线LAN的集成，接着具体介绍如何设计Cisco WLC 5500 系列来支持不同的服务等级。在这部分，本章将进一步介绍Cisco对于（IEEE和WMM支持的）QoS标准的扩展，其中包括为使用SIP（会话初始化协议）的语音和视频工作站提供特殊处理。在这之后，本章讨论了AVC（应用可视性控制）工具如何能够进一步增强WLAN的QoS设计。本章最后给出了一个全面的QoS模型，并提出了可支持标准4类和8类模型的参考设计。

本章将使用WLC 5500系列来实现集中式无线QoS设计。尽管Cisco也支持其他无线架构，比如自主模式（Autonomous Mode）和FlexConnect（以前称为H-REAP，混合远端边界接入点），但本章并不涉及这部分内容。后面的两章（第20章和第21章）着重介绍使用Catalyst 3850 系列和WLC 5760 来实现无线QoS 设计。

19.1 WLAN中的QoS实施位置

设计WLAN中的QoS必须具有大局观（即端到端）。网络中的无线部分和有线部分必须以一致的方式来支持QoS（尤其是QoS标记机制），要做到无论在网络中的什么位置，都为应用保持相同的QoS等级。

因此需要在WLAN中的以下4个位置实施QoS。

1.连接WLC的网络交换机上:网络交换机的端口通常配置为IEEE 802.1Q Trunk，并关联了802.1p CoS 值。有线网络交换机也会根据网络QoS 策略，负责对去往WLC 的下游流量实施队列机制。

2.WLC本身:WLC本身能够根据每个SSID或根据每个用户来分配不同的QoS策略（但实际上是由AP实施的，而不是WLC）。在下游方向上，WLC会在CAPWAP隧道上标记DSCP 值；在上游方向上，WLC 会在以太网Trunk 上标记802.1p CoS 值。WLC还可以使用AVC特性集，针对每个应用来重标记DSCP值。

3.接入点:AP 是WLAN 中无线QoS 的最后一个实施位置。它无法智能地重标记流量，但在下游方向上，它会将CAPWAP DSCP 值映射为正确的802.11e UP 值，然后根据这个值，将流量分类到正确的WMM AC 中；在上游方向上，AP 负责将802.11e UP 值映射为相应的DSCP值，这个值将在CAPWAP隧道中使用。

4.无线客户端:客户端需要能够在应用层为要发送的数据包标记 DSCP 值。而且，如果客户端支持WMM功能的话，它可以获益于QoS特性，比如标记正确的UP值，使数据包能够以正确的QoS等级接入无线媒介。除了在802.11数据帧上设置UP值之外，WMM客户端还能够使用其他关键特性，比如传输定义（TSpec）和传输机会（TXOP）。

注释:第18章中详细介绍了UP、WMM、TSpec和TXOP。

在前文介绍的4个QoS部署位置中，其中3个都可以由网络工程师进行配置:网络交换机、WLC和客户端。尽管大多数QoS实际上是在AP上执行的，但从WLC的角度来看，AP是WLC自身的扩展。图19-1展示了在有线网络和无线网络中，这4个QoS部署位置。

图19-1 有线和无线网络中的QoS部署位置

19.2 在WLAN控制器中管理QoS配置文件

如果可以的话，最佳做法建议为无线网络中的每个服务类别配置分离的WLAN；比如建议在“语音WLAN/SSID”上部署移动Wi-Fi IP 电话。对于有线网络的工程师而言，这是一个很熟悉的概念；在有线网络中，工程师会为IP电话创建一个单独的语音VLAN，这被看作是一种解决安全问题的做法。尽管在将无线手机隔离到语音SSID的考量中，安全问题是重要的一方面，但还有另一个非常重要的考量，即这样做就可以为整个SSID提供单独的QoS策略。

19.2.1 QoS标记和条件信任边界

你现在可能已经意识到了，在本书的每个设计章节中，QoS标记和信任边界的设计是首个需要考虑的问题。Cisco 5500 系列WLAN 控制器使用的操作系统名为AireOS，它为QoS 标记和信任边界的设计提出了新的挑战。先简单提一下，除了AVC特性（本章稍后介绍）之外， 5500系列WLC实施QoS信任边界的能力有限。

实施信任边界是使用5500系列WLC来设计无线网络时要完成的工作，必须在连接WLC的有线边界上实施信任边界，或者至少必须信任无线客户端。举例来说，如果无线IP电话将数据包标记为EF（快速转发），那么这个标记会被信任，直到数据包到达与WLC相连的交换机。对比一下有线网络中使用的传统信任模型，这无疑是一项重大的变革。

为了解决这个问题，常为实时应用分配专用的WLAN。通过这种做法，保证实时应用只运行在这些WLAN中；比如设置一个语音WLAN和一个视频WLAN。在这个WLAN内部并没有设置信任边界；无线客户端要想接入实时WLAN，必须先通过认证，通过认证后来自这个客户端的所有数据包就都是被信任的了。

注释:在WLC中，SSID代表WLAN，并且通常与有线侧的以太网VLAN一一对应（但也可通过802.1x，来为普通SSID提供基于角色的VLAN分配）。

19.2.2 WLAN QoS配置文件

如果可以的话，最佳做法建议为无线网络中的每个服务类别配置分离的WLAN；比如建议在“语音WLAN/SSID”上部署移动Wi-Fi IP 电话。对于有线网络的工程师而言，这是一个很熟悉的概念；在有线网络中，工程师会为IP电话创建一个单独的语音VLAN，这被看作是一种解决安全问题的做法。尽管在将无线手机隔离到语音SSID的考量中，安全问题是重要的一方面，但还有另一个非常重要的考量，即这样做就可以为整个SSID提供单独的QoS策略。

从很多方面来说，为实时应用分配一个专用的SSID，会使语音和视频的QoS设计工作变得简单。因为这样一来，实时流量就不会与其他类型的尽力而为流量混杂在一起，从而可以将QoS策略应用到整个WLAN中。但话虽如此，AP在接收数据包的时候，仍会希望数据包已经正确设置了UP和DSCP标记。因为不这样的话，即使数据包属于一个专用的SSID，并且这个SSID拥有高QoS级别，AP还是会根据数据包的标记来进行处理。举例来说，如果语音WLAN中收到了一个语音数据包，但它的DSCP值为0；那么即使管理员将这个语音WLAN配置为“Platinum（白金）”QoS级别，AP仍会将其当作尽力而为流量进行处理。如前所述，WLAN中并不设置信任边界，而且不会在收到数据包后修改DSCP标记（除非使用了AVC）。

近些年，想要将语音、视频和数据流量分类到不同的SSID中变得越来越难（比如在平板电脑上使用软电话，或者在台式PC上使用多媒体应用），尽管如此，WLC通过使用简化模型，也能够直接将单一的QoS策略应用到整个WLAN中。

尽管为每个设备类型创建单独SSID的这种设计指导具有一定的局限性，可能并不适用于混合了语音和数据的当代应用（比如智能手机、平板电脑等），但它确实为在WLAN中部署QoS提供了一种简单的方法。在WLAN中部署QoS的第一步是规划:哪类应用应该使用4个QoS配置文件中的哪一个。

5500 系列WLC 支持4 种QoS 策略，每种都直接对应着一个802.11e/WMM AC。Cisco 还沿用前文提到的金属命名法来命名表19-1 中定义的WMM AC。

表19-1 5508 WLC中的4个QoS配置文件

尽管系统中只提供了4个QoS配置文件，但这不代表只能配置4个SSID。WLC允许将QoS配置文件应用到多个SSID。举例来说，可以创建两个内部语音SSID，然后为它们关联相同的Platinum（白金）QoS配置文件，但在系统内部，这两个WLAN是分开管理的。

虽然也可以对这些QoS配置文件做出些许修改，但通常都会将其直接与WMM和IEEE802.11e定义的EDCA（增强型分布式信道接入）接入类别相映射。

那么，WLC中的这些QoS配置文件实际上是如何工作的呢？在下游方向上，通过将入站数据包的DSCP 值映射为CAPWAP DSCP 值，来提供QoS（详见图18-8）。在AP 上， CAPWAP 信道头部的DSCP 值会被映射为相应的802.11e UP 值，并将数据包放入正确的出向AC中。数据包进入WLC后，WLC会用数据包的DSCP标记与数据包所属WLAN中应用的QoS配置文件相对比。如果数据包的DSCP值超出了QoS配置文件所提供的最大DSCP值，WLC就会将数据包的DSCP值降低为QoS配置文件能够提供的最大DSCP。举例来说，如果一个WLAN中应用的是Gold（金）配置文件，说明它允许的最大DSCP值是34。因此如果从有线侧进入WLC 的数据包携带DSCP 46，WLC 就会重写CAPWAP 信道的数据包头部，将DSCP值改为34，而不是使用DSCP 46。另外，Silver（银）配置文件中允许的最大DSCP值是0，因此如果将QoS配置文件设置为Silver（银），则所有CAPWAP数据包头部的DSCP值都会被标记为0。

注释:要记住，AP和控制器中的这些映射行为绝不会影响IP数据包的内部DSCP值。这里提到的DSCP值只应用在CAPWAP信道上。唯一的例外是使用AVC特性，该特性能够重写原始IP数据包的DSCP值。

表19-2 中列出了每个WLC QoS 配置文件的最大DSCP 值。

表19-2 默认的WLC QoS配置文件QoS值

如果数据包从有线侧进入WLC时携带的DSCP值，低于WLAN中应用的QoS配置文件中的默认DSCP最大值，WLC就会将原始数据包的DSCP值复制到CAPWAP头部，之后AP会根据这个DSCP 值来映射802.11e UP 值。

在上游方向上，AP 的行为与WLC 在下游方向上的处理行为非常类似。因为802.11e UP值是由客户端设置的，AP只需要将其与WLAN上应用的QoS配置文件中允许的最大UP值相比较，从而将正确的DSCP值映射到CAPWAP数据包中。

注释:第18章中介绍了802.11e UP到DSCP的映射，详见表18-5。

再次强调，QoS 配置文件中为每个WLAN 设置了最大802.11e UP 值。尽管WLC 为4 个配置文件都设置了默认值，但管理员也可以为每个配置文件自定义最大802.11e UP 值。举例来说，Silver（银）的默认DSCP值是0，如果你愿意的话，也可以为它设置其他值。AP会在将数据包发送到射频接口之前，自动将DSCP值映射为UP值。

考虑以下场景:如果将QoS配置文件设置为Gold（金），则它在SSID中允许的最大UP值就是5。如果接收到了一个UP值为6的无线数据帧，AP会自动在上游CAPWAP数据包中，将UP 值映射为DSCP 值34（DSCP 34 对应着UP 5）——这会从根本上降低这个数据包在IP传输网络中的QoS级别。反之，如果WLAN收到了一个UP值（1～5）较低的数据包， AP会按照表18-5中的定义来映射DSCP值，也就是没有更改数据包的QoS级别。尽管这并不真的等同于信任模型，但也确实在AP和WLC上建立了每个WLAN能够接受的最高QoS级别。

如果无线客户端不支持WMM，意味着802.11 数据帧上没有802.11e UP 标记，也就是在上游映射中会使用该WLAN 的默认802.11e UP 值（见表19-2）。举例来说，如果不支持WMM的客户端向上游发送802.11数据帧到AP，且AP使用Platinum（白金）配置文件，AP会自动在上游CAPWAP头部中写入46，因为Platinum（白金）配置文件所允许的DSCP上限就是46。对于支持WMM的客户端来说，AP会将数据包携带的UP值映射为DSCP值，并写入上游CAPWAP信道的头部。因为不支持WMM的客户端无法标记UP值，因此对于这些客户端所能提供的QoS功能非常有限。

现在来考虑另一个案例，在这个案例中我们可以看到QoS策略将流量降级为尽力而为的做法。访客无线SSID可能需要这种做法，因为在这个SSID中所有流量都是不可信的，都必须重标记DSCP 值为0。虽然你无法控制客户端设备原始标记的DSCP 和802.11e UP 值，但你可以为AP 应用 Silver（银）QoS 配置文件，因为它的默认DSCP 最大值是0。无论原始的DSCP或UP值是多少，Silver（银）QoS配置文件都会在上游CAPWAP数据包中，将所有入站UP 值映射为DSCP 0。当然了，AP 并无法重标记数据包真实的内部DSCP 值；它只会修改CAPWAP信道中的DSCP值。也就是说，数据包在上游方向上离开WLC，向有线网络发送时仍携带原始的DSCP值，这个WLAN中的流量只有在AP和WLC之间穿越IP骨干网的过程中，才会被当作尽力而为流量。

一定要注意，表18-5和表19-2中列出的映射关系是不可自定义的。这意味着如果AP从UP值映射过来的DSCP值不符合园区网的QoS策略，就可能出现一些问题，从而影响CAPWAP数据包在IP骨干网中的传输过程。在基于更新IOS的5760控制器中，管理员可以自定义这个映射列表，增强了管理员的控制粒度。

要想在WLC 5500 系列中配置QoS 策略，首先选择Wireless（无线），然后选择QoS，之后点击QoS Profiles（QoS 配置文件）。图19-2 使用WLC GUI（图形用户界面）展示了4 个QoS配置文件。

注释:尽管5508 WLC能够通过AireOS支持CLI（命令行界面），但GUI仍是最常使用且推荐使用的配置方式。本章的所有配置都使用WLC GUI。第20章主要介绍5760控制器，它是基于IOS的设备，因此使用CLI进行配置更为灵活。

因为这些QoS配置文件必须应用到整个SSID中，因此配置步骤中的第一步是为每个应用类创建一个WLAN SSID。首先从最上面的标签中选择WLANs，然后按照GUI 显示的内容来创建新的WLAN。图19-3 展示了为VoIP 流量创建专用WLAN SSID 的案例。

图19-2 4个WLAN QoS配置文件

图19-3 为语音创建专用WLAN

在图19-3 中，管理员创建并启用了语音WLAN。Radio Policy（射频策略）设置为All，表示能够兼容802.11b/g/n和802.11a/n客户端。通常建议让语音工作站使用802.11a/n射频（5.8 GHz 频段），而不使用802.11b/g/n（2.4 GHz 频段），因为前者提供更高的信道速率，从而使客户端能够更好地接入网络中。

在为语音应用类创建了WLAN后，现在只需将正确的QoS配置文件应用到这个SSID就行了。图19-4展示了如何为语音WLAN应用Platinum（白金）QoS策略。

图19-4 为语音WLAN应用Platinum（白金）QoS策略

从图19-4可以看出，管理员已经为语音WLAN应用了Platinum（白金）QoS配置文件。在这个配置页面中，还可以为每个关联到该WLAN的用户设置基于每用户的带宽限制。通常带宽限制是在QoS配置文件的配置部分完成的，但这个页面允许你覆盖QoS配置文件（即本例中的Platinum）中配置的默认限制。

在这个WLC GUI 页面靠下的部分（图19-4 中没有显示出来，往下滚动鼠标就能看到），可以在QoS 配置文件中实施WMM 策略。举例来说，如果将WMM Policy（WMM 策略）设置为Allowed，这表示WMM客户端和非WMM客户端都能够接入这个WLAN。

要注意，所有新建的WLAN中默认应用的是Silver（银）QoS配置文件。这意味着除非手动配置了其他QoS配置文件，否则WLAN中的所有流量都会被当作尽力而为流量来处理——也就是为所有CAPWAP 数据包分配DSCP 0，而且会相应地为所有下游802.11e 数据帧分配UP 0。

WMM策略有以下三个配置选项。

■ Disabled:禁用WMM。

■ Allowed:这是默认设置。如果将WMM策略设置为Allowed，表示如果WMM客户端请求支持WMM的话，WLAN能够提供WMM支持。但如果客户端并没有明确地请求WMM支持，WMM就不会启用。

■ Required:这个选项要求这个WLAN中的所有客户端必须支持WMM。

要记住，WMM 支持特性关系着客户端能否使用802.11e UP QoS 标记。如果客户端不支持WMM，或者QoS配置文件中禁用了WMM，则所有QoS标记都会被设置为默认值，详见表19-2。

按顺序点击Wireless（无线）、QoS、Profiles（配置文件），可以查看这4个“贵金属”QoS策略中可以配置的参数，详见图19-5。

图19-5 编辑QoS策略

如图19-5所示，可以为每个类别配置多种QoS配置文件参数。举例来说，图中所示页面可以让你在上游和下游方向上，基于每个用户建立带宽控制。比如对于语音WLAN来说，可以将每用户的带宽限制设置为希望G.711编码使用的带宽量。要注意，尽管可以将G.711呼叫计算为87.2kbit/s，但最佳做法的建议是将每用户的带宽限制设置为不小于128kbit/s。

类似地，对于多目的WLAN来说，最好为系统中的每个用户建立一个基线带宽，保证不会出现一个用户消耗掉所有可用带宽，并饿死其他用户的情况。

还可以配置基于每SSID的带宽限制，这也是个很有用的选项，可以在上游和下游方向上，限制这个配置文件所关联的整个WLAN中的带宽速率。如果在一个无线网络中建立了多个SSID，这种设置就很有用，因为所有这些SSID都在争夺可用带宽。

尽管根据环境的不同，针对每用户和每SSID带宽控制的设计指南也有所不同，但在拥有大量用户的环境（比如大学校园网）中应该考虑使用这个特性，或者当AP的有线侧连接的带宽有限时（比如远端站点），也应该考虑使用这个特性。

在每用户和每SSID带宽限制的配置部分，可以选择配置平均数据速率和平均实时数据速率。这个平均实时速率会应用到所有UDP流量上。如果你的SSID中混合了多种应用，并且没有为实时应用保留带宽时，这个配置会很有用。

QoS 配置文件中一个比较有趣的参数是WLAN QoS Parameters（WLAN QoS 参数），如图19-5 所示。如前所述，QoS 配置文件的一个主要作用是限制DSCP 和802.11e UP 值的最高级别。在这部分的配置中，你可以设置配置文件的最大和默认QoS属性。以Silver（银）配置文件为例，如果你希望的话，可以将默认设置从best effort（尽力而为）更改为video（视频；有时建议这样做）。图19-5 显示的Maximum Priority（最高优先级）配置部分控制的是允许从WMM 客户端接收到最大UP 值。Unicast Default Priority（单播默认优先级）控制的是允许从非WMM 客户端收到的最大CAPWAP DSCP 值。

现在来看看修改这些参数对于配置文件的QoS行为有什么影响。当Silver（银）的配置保留默认，即best effort（尽力而为）时，WLC 和AP 会确保在上游和下游方向上，所有QoS 标记都设置为0。也就是说所有上游UP 值都会被映射为DSCP 0，没有例外。如果把配置更改为video（视频），意味着配置文件允许所有不大于5的入站UP值或者不大于34的DSCP值保留原样，但如果接收到UP值为6的数据包，QoS配置文件会将其降级为5，因为这是视频配置文件允许的最大UP值。

QoS 配置文件的另一个重要配置是将WLAN QoS 标记映射为网络有线侧的802.1p CoS值。前文已经提到了，无线环境中使用的IEEE 和WMM QoS 标记标准与有线网络中使用的标准标记并不是完全按照数值大小对应的。举例来说，在有线环境中，语音应用总被映射为CoS 5（对应的DSCP 值是46），但在WLAN 环境中，IEEE 标准是将语音应用标记为802.11e UP值6（仍对应着DSCP 46），因此要将每个WLAN的CoS值正确地映射到有线侧。为了简便操作，WLC默认就会自动将数据包的内部DSCP值映射为正确的802.1p CoS值（详见表18-5）；但在图19-5所示配置页面中，你也可以修改从控制器发往网络有线侧的数据帧的CoS映射。

表19-3展示了这个配置页面中几个重要的QoS配置文件参数。

表19-3 QoS配置文件参数描述

19.2.3 建立访客QoS配置文件

前文介绍的4个基本QoS配置文件可以与经典的4类QoS模型相对应。可以将特定的应用（比如语音和视频）映射到4个不同的配置文件中。不过，相对于有线网络，无线网络有一个独特的特点，即支持访客用户。

随着无线网络的使用变得越来越广泛，人们开始希望走到哪里都能使用Wi-Fi连接。当你来到咖啡厅、快餐外卖站、博物馆、地铁站，或者作为合作伙伴到访另一家公司，Wi-Fi访客网络几乎随处可用，如果有的公司不提供访客无线接入，则有可能会对业务造成潜在影响。这时问题来了:应该为访客用户应用哪个QoS配置文件呢？

你可以使用5500系列WLC创建自定义角色，将特殊的QoS策略应用到特定的一组访客用户上。WLC软件允许创建多达10个访客用户角色，它们可以分别应用到不同的访客组中。你可以按照以下路径来为Guest Users（访客用户）创建或配置QoS Roles（QoS角色）:Wireless > QoS > Roles。图 19-6 展示了如何添加一个新的访客用户 QoS 配置文件。

图19-6 添加访客用户QoS配置文件

一旦创建好角色，就可以通过选择角色名称来进行编辑了，还可以设置基于每用户的带宽限制。这种配制方法可以限制每个访客用户在连入你的无线网络时，能够使用的带宽量。尽管有时并不需要提供带宽限制，但仍建议实施一定的限制，以防访客用户消耗掉公司用户所需的宝贵带宽。图19-7展示了这部分配置步骤。

可以在控制器本地来配置访客用户，也可以通过外部AAA（认证、授权和审计）服务器来连接访客用户。创建这种用户角色的方法超出了本书的范围。

为了在每用户的基础上，为TCP 流量定义平均数据速率，要在Average Data Rate（平均数据速率）部分输入一个速率，范围是0 ～60 000，单位是kbit/s。0 表示不为这个QoS 角色限制带宽。举例来说，如果你希望为客户配置文件中的每个客户端设置的速率限制为3Mbit/s，就在这里配置3000。

为了在每用户的基础上，为TCP 流量定义峰值数据速率，要在Burst Data Rate（峰值数据速率）部分输入一个速率，范围是0～60 000，单位是kbit/s。0表示不为这个QoS角色限制带宽。峰值数据速率应该大于或者等于平均数据速率。如果没有正确地配置，QoS策略可能会阻塞从这个无线客户端发出或去往这个无线客户端的流量。

图19-7 创建访客用户QoS配置文件

为了在每用户的基础上，为UDP流量定义平均实时速率，要在Average Real-Time Rate（平均实时速率）部分输入一个速率，单位是kbit/s。这个配置是定义语音和视频流量的，因此与非实时流量的配置是分开的。还是像前文的配置一样，你可以在这里输入一个0 ～60 000 范围内的值，0表示不为这个QoS角色限制带宽。

为了在每用户的基础上，为UDP 流量定义峰值实时速率，要在Burst Real-Time Rate（峰值实时速率）部分输入一个速率，单位是kbit/s。你可以在这里输入一个0～60 000范围内的值， 0表示不为这个QoS角色限制带宽。

注释:你在这里为每用户设置的带宽限制只会影响去往下游的带宽量（从AP去往无线客户端），并不会影响上游流量（从客户端去往AP）。有趣的是，WLC 5500不允许为访客用户定义上游速率限制。不过对于SSID中的非访客用户来说，WLC可以对其实施双向的速率限制。

19.3 VoIP应用的QoS设计

一旦配置好QoS 配置文件，并将其应用到正确的WLAN SSID 后，你就可以开始考虑修改一些参数，来优化承载着实时流量的WLAN中的QoS了。

优化配置可以被分为以下两个部分:

■ EDCA优化；

■ CAC（呼叫准入控制）。

下面按顺序介绍这两个部分。

19.3.1 调整EDCA配置

第18章讲到，EDCA（增强型分布式信道接入）是一种控制标准，专用于指导无线媒介中的QoS功能。EDCA管理无线传输的诸多方面，比如CW（竞争窗口）大小、每个AC（接入类别）使用的帧间隔大小等。Cisco 5500 系列WAN 控制器中的特性支持基于标准WMM EDCA模型，还包含三个其他的EDCA配置文件，以便用于控制不同的流量类。这4个EDCA配置文件如下所示。

■ WMM（默认设置）:启用WMM（Wi-Fi多媒体）默认参数。若你的网络中没有部署语音或视频服务，就使用这个选项。

■ Spectralink Voice Priority:启用Spectralink 语音优先级参数。为了提高呼叫质量，当你的网络中部署了Spectralink电话时，就使用这个选项。

■ Voice Optimized:启用EDCA 优化语音配置文件参数。当你的网络中部署了除Spectralink之外的语音服务时，就使用这个选项。

■ Voice and Video Optimized:启用EDCA 优化语音和视频配置文件参数。当你的网络中同时部署了语音和视频服务时，就使用这个选项。

这些配置文件之间的区别在于:针对特定的流量类优化了各种EDCA参数。这些配置文件中调整的EDCA值包括如下内容:

■ CWmin；

■ CWmax；

■ 固定的以太网时隙值；

■ TXOP值。

最佳做法的建议是这样的:若你计划在无线网络中启用语音服务，要确保选择使用Voice Optimized配置文件。一定要记住，EDCA管理的是无线媒介上的数据帧传输行为，因此你需要将EDCA 应用到整个AP 射频接口，而不是具体的WLAN SSID。

为了配置EDCA优化，打开Wireless（无线）窗口，选择一个射频接口（802.11a/n或802.11b/g/n），并选择EDCA Parameters（EDCA 参数）。图19-8 展示了如何为特定的无线网络配置EDCA配置文件。除此之外，针对特定的轻量AP，必须分别在801.11g/b/n射频接口和802.11a/n射频接口上配置EDCA参数。

这个配置窗口里还有一个非常有用的特性:Enable Low Latency MAC（启用低延迟MAC）。这是一个可选的特性，它可以提高RTP数据包的ACK（确认）响应速度，从而有助于提高语音和视频流的整体QoS操控性。

图19-8 自定义EDCA参数

举例来说，假设现在有一个语音数据包排在队列中，等待通过无线接口发送出去，但它的发送被延迟了，因为媒介繁忙。经过了几次尝试后，最终语音数据包被发送出去；但它被接受客户端丢弃了，原因是太过时了，因此它花费在等待传输上的时间，其实是对AP资源的浪费。Enable Low Latency MAC 特性通过控制数据包的传输行为，并适当地将轻量AP 上的过时语音数据包设为超时，增强了语音性能，提高了每个AP所服务的语音呼叫数量。

但使用这个特性还需要注意一些内容。你应该只在WLAN接受WMM客户端的环境中启用低延迟MAC特性。还要注意图19-8中出现的系统警告消息，在启用盖特性前，必须正确设置RTP数据包的DSCP标记。

从设计的角度看来，可以配置AP接受多个工作站以不同的数据速率进行传输。尽管维持较低的数据速率能够当工作站远离AP时，增强工作站的能力，但低速率并不适用于语音应用。工作站以较低数据速率进行传输的缺点在于，它需要花费更长的时间来传输特定大小的数据帧。这将会带来更多延迟，并降低整个无线媒介的吞吐量——最终导致AP只能支持更少的并发语音呼叫。为了解决这个问题，建议在支持语音流量的WLAN中禁用较低的数据速率，以避免潜在问题。

19.3.2 无线网络上的呼叫准入控制

Cisco WLC 支持VoIP 电话的能力取决于以下两个重要特性:

■ 为语音启用Platinum（白金）QoS配置文件；

■ CAC（呼叫准入控制）。

在这种情况下，CAC代表的是WLC的能力，即在每AP的基础上，限制呼叫的数量。尽管一般来说CAC超出了本书的范围，但在无线网络的环境中为了合理支持VoIP应用，强烈建议使用CAC特性。

与WLAN中的其他功能类似，CAC是在WLC上集中管理的。但它是在AP上实施的。CAC通过控制一个AP上同一时间允许并发的语音呼叫数量，来增强WLAN中的语音可靠性。为了理解CAC的必要性，请考虑WMM EDCA是如何处理Platinum（白金）配置文件中的数据包，以及如何处理其他配置文件中的非实时流量。如果有太多的VoIP电话同时竞争接入媒介的机会，再想通过Platinum（白金）配置文件来确保语音质量就有些强人所难了，因为每个无线电话使用射频接口的机会是相等的。最终的结果是使得AP上的QoS行为回到了“尽力而为”模式。语音呼叫的最终结果是所有VoIP呼叫质量都会下降，没有例外。

19.4 在WLAN上启用WMM QoS策略

WLC 上的WMM CAC 应用并不是限制关联的无线IP 电话数量（也就是:这个AP 只允许连接最多“X”个VoIP电话）。而是CAC会评估几个变量，比如AP所使用的带宽量、AP的负载以及干扰模式。举例来说，WLC能够监控每个AP的负载，并且能够以此判断这个AP是否还能够为另一个VoIP呼叫提供足够的空闲带宽。如果不行的话，新呼叫就会被拒绝，然后将无线电话漫游到另一个AP，或者向电话提供快速忙音信号。这看起来像是“先到先得”规则，但这样做能够避免网络变得超载，并能够持续地为每个人提供相对较高质量的服务。

为了在WLC 中配置VoIP CAC，首先打开WLAN 页面（如图19-4 所示），从侧面面板中选择WLANs，然后点击你想要编辑的WLAN ID。在WLAN 配置页面中，选择QoS 标签。在这里必须将WMM参数设置为Allowed或Required，才能启用基于WMM的CAC。注意，要是将参数设置为Required，表示不允许非WMM客户端连接到该WLAN。

如果你使用的是较早的Cisco 7920 VoIP 电话（早于WMM），有以下两种方法可以实施CAC:

■ 基于AP（带宽）；

■ 基于客户端（负载）。

如果你使用的是较新的Cisco无线VoIP电话，可以直接使用WMM来启用CAC和WMM QoS。

19.5 在WLAN上启用WMM QoS策略

EDCA引入的一个重要增强特性是，允许无线客户端在传输高优先级流量之前，向AP发送流量要求。在802.11e标准中，这称为TSpec（传输定义）。在客户端与AP的TSpec通信过程中，客户端会获得特定的TXOP（传输机会），或者专用的时间窗口（只有它可以接入媒介），从而使它可以发送高优先级流量。

较新的客户端（遵从802.11e EDCA 定义的客户端）会使用ADDTS（增加流量）TSpec 请求功能，来请求接入AP。TSpec设备会告知AP几个重要的参数，其中包括数据速率、数据帧大小和它的带宽要求。AP可以根据这些信息为这个客户端计算出TXOP，从而优化它接入无线媒介的行为。在这个过程中，WLC还能够计算出AP上是否有TSpec设备所请求的足够资源。Cisco 792XG 家族VoIP 电话就能够支持这个特性。

按照以下路径为TSpec语音客户端配置CAC设置:Wireless > 2801.11a/n（或802.11b/g/n）> Media。这个配置页面中的语音和视频标签中都可以配置CAC。在这个配置页面中实施CAC配置参数时，你要首先为AP启用ACM（准入控制）。这个配置是在每射频接口上实施的，而不是在每WLAN上实施的，因此必须同时配置在802.11a/n射频接口和802.11b/g/n射频接口上。这个配置窗口中可以配置两种CAC方式。

■ Load Based:仅用于非网状的无线部署环境。

■ Static:仅用于网状的无线部署环境。

下一个参数定义了射频接口可以使用，且仍能够初始化WLAN语音呼叫的最大FR（射频）带宽。Reserved Roaming Bandwidth（预留漫游带宽）参数定义的是在关联和重关联过程中，为响应ADDTS请求所设置的带宽能力，还能够识别想要尝试漫游到AP的正在通话中的WLAN语音客户端。

Expedited Bandwidth（快速带宽）请求特性允许客户端向WLAN 表明WMM TSpec 请求的紧急程度（比如911紧急呼叫）。当控制器收到这个请求后，它会尝试在不影响其他正在通话中的TSpec呼叫的质量的前提下，尽可能处理这个紧急呼叫。

你还能在这个配置页面中以kbit/s为单位，配置为网络中每个SIP呼叫所分配的带宽。只有当用户定义了SIP编码后，才可以配置这个参数。还要注意的是，只有为这个WLAN配置了媒体会话侦听（Media Session Snooping；也称为SIP侦听）后，基于SIP的CAC才会工作。下一小节将更为详细地介绍媒体会话侦听。

Metrics Collection 选项决定了Cisco Prime Infrastructure 是否能够使用在语音或视频呼叫上收集的数据，这是Cisco无线网络使用的主要网络管理工具。

图19-9展示了如何在WLC上配置各种CAC特性。

图19-9 为TSpec客户端配置CAC

19.6 媒体会话侦听（也称为SIP侦听）

截止到目前，介绍的WLAN QoS 设计都着重关注为整个WLAN SSID 分配一个特定的QoS配置文件。若使用VoIP电话，则为WLAN分配Platinum（白金）QoS配置文件。Platinum（白金）或Gold（金）配置文件（通常分别用于语音和视频WLAN）是信任UP值的（不能超过配置文件中默认UP值的上限）。不过在很多案例中，SIP兼容设备上的应用或OS并无法正确标记语音和视频数据包。从而导致即使WLAN配置了Platinum（白金）配置文件，语音在无线网络中也只能获得尽力而为服务。

为了应对这一缺陷，AireOS 6.0 版本中引入了一项新特性，称为媒体会话侦听（也称为SIP 侦听）。媒体会话侦听特性允许WLC 检测与RFC 3216（SIP）相符的语音和视频流量，并为其提供高优先级服务。要想配置媒体会话侦听，必须将WLAN QoS 配置文件设置为Platinum（白金）或Gold（金；如果使用了Silver或Bronze配置文件，则该特性不会启用）。

这项特性实际是如何工作的呢？在启用了媒体会话侦听特性后，它允许AP检查指定WLAN/SSID中的每个会话，以确定该会话是否为SIP。它通过查看数据包的目的或源UDP端口号来确定，若端口号为5060（标准的SIP信令端口），则数据包为SIP。在识别出了SIP数据包后，AP会进一步检查数据包，以确定该SIP会话为RTP流所使用的端口号。

如果在一个设置了Platinum（白金）QoS配置文件的WLAN中识别出了SIP会话，下游802.11e 数据帧得到的802.11e UP 值是6，无论这个数据包的内部DSCP 值是多少。这样可以确保数据包由语音AC进行处理，从而确保了WLAN中的服务质量。

AP通过使用这个特性可以检测SIP语音呼叫的建立、终结和失败，并将这些状态报告给控制器和Cisco Prime Infrastructure。管理员可以针对每个WLAN启用或禁用VoIP侦听和报告。

注释:尽管默认情况下AP会查找UDP端口5060来确定SIP会话，但也可以将SIP侦听配置到其他自定义端口上，或者配置在一组端口上。

由于这一特性主要用于将语音SIP数据包的QoS提升到适当级别，因此只能够在Gold（金）和Platinum（白金）QoS配置文件上启用该特性。WLC不允许你在Silver（银）和Bronze（铜）配置文件上启用该特性。

要想启用VoIP SIP 侦听特性，打开WLAN 页面，选择你希望启用该特性的WLAN。然后选择Advanced（高级）标签，最后在Voice 配置部分勾选Media Session Snooping 复选框。图19-10显示出了SIP侦听特性的配置方法。

图19-10 启用SIP媒体会话侦听特性

媒体会话侦听是一个很有用的QoS工具，能够帮助SIP流量在无线网络中获得需要的服务级别，但它无法为非SIP流量提供每会话或每用户的QoS服务。举例来说，媒体会话侦听无法识别SCCP（Skinny）流量。也就是说如果网络中使用的是传统无线VoIP电话，那就无法为这类流量提供相应的QoS级别。

尽管媒体会话侦听特性有其局限性，但Cisco WLC 技术的另一个增强特性提供了一些新的无线QoS设计选项。这个新特性称为AVC（应用可视性控制），详见下一小节。

19.7 WLC中的应用可视性控制

第9章中讲到，AVC是一项使用了多种技术的解决方案，其中包括NBAR2（基于网络的应用识别版本2）、FNF（Flexible NetFlow）和管理工具，这些技术协同工作，基于状态化DPI（深度数据包检测）提供了强大的应用可视性和控制能力。

从AireOS 7.4 开始，无线控制器上可支持Cisco AVC 解决方案，从而它能够从混合的数据流中使用DPI来识别不同应用，并为不同应用分配适当的DSCP值。根据AVC特性的DPI结果， WLC能够识别不同应用并将它们分别映射到WLC提供的4个QoS策略中，以确保在无线网络中为流量提供正确的QoS级别。因为无线也是网络的接入层，AVC允许WLC实施QoS信任规则，这在之前是无法实现的，但也仅限WLC（在AireOS 7.4 中，AVC 功能只能应用在WLC上，不能应用在AP上）。通过在WLC上启用AVC特性集，会同时在WLC的上游和下游方向上启用DPI和DSCP标记行为——也就是说，AVC特性集并没有上游或下游的概念。

启用了AVC后，WLC能够识别上千种应用，并将它们的DSCP值按照管理员的配置进行重标记。与前文介绍的WLAN QoS的配置不同，AVC不仅能够标记CAPWAP信道的DSCP值，它还能够标记原始IP数据包的DSCP值。与本书通篇强调的一样，应该在尽量靠近网络的位置部署信任边界，而不是把信任边界部署在数据包从有线网络进入WLC的位置。如果因为任何原因，数据包没有在边界上获得正确的标记，WLC中的AVC功能可以轻松实现这种标记。而且，源于无线网络的数据包，也可以在进入有线网络之前，由WLC分类并正确地标记。在WLC上标记上游数据包，然后将其发送到有线网络中，是很实用的做法。虽然WCL很难被当作是网络的边界，但它确实比当今的边界交换机更能够深入检测数据包，从而提供了更强大且粒度更精细的应用分类工具。

由于具备了DSCP重标记功能，AP上的下游QoS处理可以变得更加有条不紊，使不同应用分别接入AP 上正确的WMM AC 中。由于AVC 只工作在WCL 上（这与能够同时工作在WLC 和AP 上的其他WLAN QoS 策略特性不同），它只会影响进入无线网络下游方向上的流量（若WLC收到了一个上游数据包，并由AVC对其进行处理，这时数据包已经进入了无线网络中，因此从严格的无线网角度看来，它只能影响下游流量）。

虽然前文已经提过了，但还是有必要再次回顾这一根本的事实:WLC上的AVC重标记行为是没有方向概念的——也就是说无论数据包是向上游去往有线LAN的，还是向下游去往AP的，AVC都会对它们进行重标记。

接下来总结一下WLC中的AVC和QoS对于上游和下游方向的影响。

上游方向（从无线客户端去往有线网络）。

1.无线客户端开始传输流量。

2.客户端自行设置DSCP 和802.11e UP 值，然后通过AP 将数据传输到正确的AC。

3.AP 将UP 值映射为DSCP 值，并用在CAPWAP 信道上，但并不修改数据包的内部DSCP标记。

4.WLC通过CAPWAP接收到入站数据包。

5.WLC 使用NBAR2 检查数据包的应用层，并对其实施AVC 策略，根据策略重标记DSCP值。

6.数据包携带着新的DSCP值，并发往有线网络。

下游方向（从有线网络去往无线客户端）。

1.数据包从有线网络发往WLC。

2.WLC 使用NBAR2 检查数据包的应用层，并对其实施AVC 策略，根据策略重标记原始数据包头部的DSCP值。

3.WLC 将新的DSCP 值与WLAN QoS 配置文件进行比较，然后将新的DSCP 值映射为CAPWAP DSCP值。AVC DSCP标记的优先级高于QoS配置文件中建立的DSCP上限。

4.AP 接收到CAPWAP 数据包后，它会将DSCP 值映射为相应的802.11 UP 值。

5.AP通过正确的AC，将数据包传输到无线客户端。

从可视性和监控性的角度考虑，WLC可以收集并显示各种无线性能测量值，比如单个客户端的带宽使用情况和应用。这些报告信息可以显示在控制器本地，也可以通过FNF导出到管理工具中。

AVC 使用与IOS 相同的NBAR2 DPI 引擎，通过使用这种技术，WLC 能够识别超过1000种应用，其中包括Oracle、SAP、Citrix、BitTorrent、Microsoft Exchange、Skype、Facebook和其他很多应用。要想查看支持的AVC 应用，可以使用以下路径:Wireless > Application Visibility and Control >AVC Applications。图19-11展示了WLC中的AVC所支持的部分应用列表。

IOS也支持AVC特性集，在应用组中汇集各种应用。如果你熟悉IOS中的AVC特性（第9章中详细介绍了AVC），你就会发现WLC 中可用的应用在很大程度上与Cisco ISR G2 和ASR 1000 路由器中的应用列表相同。

在应用组中，你可以匹配单个应用。图19-12展示了AVC使用NBAR2来发现和控制语音和视频应用的案例。

现在来看看WLC上使用AVC的案例。假设你已经配置了一个名为Enterprise（公司）的WLAN。这个无线WLAN对大量客户端提供服务，其中包括很多实时应用，包括平板PC、智能手机和笔记本电脑。由于Enterprise WLAN 是一个集成了多种服务的WLAN，因此为它分配的全局QoS策略是Platinum（白金）。这意味着在默认情况下，QoS标记为46及以下的所有DSCP值都会被信任，无论内部IP数据包的设置是什么。

图19-11 查看AVC应用列表

图19-12 AVC应用

从本质上来说，信任所有从有线网络收到的标记是有一个问题的，那就是你不知道这些DSCP值的设置是不是真的正确。举例来说，很多语音或视频设备可能甚至无法设置DSCP值，而被当作尽力而为流量进行处理。类似地，真正的尽力而为应用可能也会在无线网络中引发麻烦，比如它们将所有流量都标记为EF，但它们实际上需要降级为Silver（银）或Bronze（铜）配置文件，即使它们所在的WLAN配置为Platinum（白金）。

只要记住了上述问题，你就可以使用AVC来保护各种语音和视频应用，即提升它们的QoS级别，确保为这些应用分配正确的DSCP值，以及在下游方向上为它们分配正确的802.11e UP 值。

一个有趣的设计概念可以使你在WLC上设置信任边界:让有线交换机将所有下游流量重标记为DSCP 0，然后再将流量发送到WLC。这时可以使用AVC 来有选择地识别应用并将其重标记为正确的DSCP值，然后将其发送到无线客户端（这并不是实际上的设计建议，只是展示一下AVC的用途）。

AVC甚至还可以丢弃无用类型的流量，也就是网络管理员认为会危害到网络的那些流量。举例来说，如果你的网络将Hulu流量认定为是问题流量，并决定这种流量根本不应该出现在Enterprise WLAN中的话，可使用AVC来轻松识别Hulu，然后为这个类型的流量设置“Drop（丢弃）”行为。

为了在WLC上配置AVC，先要在Wireless标签下创建一个新的AVC配置文件，然后打开Application Visibility and Control页面，最后点击AVC Profiles（AVC配置文件）。点击New（新建）并输入AVC 配置文件的名称。本例中使用的名称是Protect Real Time Apps。

注释:在WLC中一共可以创建16个AVC策略，每个策略中最多包含32条规则。

图19-13 展示了创建新规则的简单案例，本例将重标记Microsoft Lync 流量。这个应用列在语音和视频应用组的类别中。在本例中，重标记行为会将Lync的DSCP标记为Gold（金；也就是重标记为DSCP 34）。

如果选择了Mark（标记）选项，WLC给出了以下5种标记选择:

■ Platinum（白金；默认将数据包重标记为DSCP 46）；

■ Gold（金；默认将数据包重标记为DSCP 34）；

■ Silver（银；默认将数据包重标记为DSCP 0）；

■ Bronze（铜；默认将数据包重标记为DSCP 10）；

■ Custom（自定义；你可以自行设置重标记的DSCP值）。

如果以贵金属配置文件来重标记数据包，则数据包的DSCP值会像前文介绍的那样映射为相应的802.11e UP 值。如果你选择自定义DSCP 值的话，这个值会同时标记在原始IP 数据包头和下游CAPWAP信道中，并根据表18-5和表18-6中的信息，将这个DSCP值映射为相应的802.11e UP 值。

图19-13 使用AVC重标记DSCP

图19-14展示了一个更为全面的AVC策略，其中涉及了多种可能出现在移动设备上的应用。

在本例中，IP电话的流量被标记为EF（46），其他实时应用被标记为AF41（34），信令流量被标记为CS3（24）。

创建好AVC 规则后，现在可以将策略添加到用于Enterprise WLAN 的QoS 策略中。首先需要为WLAN 启用AVC。AVC 默认是禁用的（因为在流量高峰期，NBAR2 DPI 引擎会消耗大量CPU资源）。打开WLAN配置页面，然后选择你希望编辑的WLAN，之后选择QoS标签。

虽然已经为Enterprise WLAN 配置了Silver（银）QoS 策略，但AVC 策略总是优先于WLAN QoS 策略的。

图19-15 展示了如何在WLAN QoS 策略中添加AVC 策略。

图19-14 综合的AVC案例

图19-15 为Enterprise WLAN应用AVC QoS策略

一定要知道，AVC监控和控制是在WLC上进行的，不是在AP上。也就是说如果一个数据包始发于无线侧，AVC重标记只会在数据包离开控制器并进入网络有线侧的时候生效。反之，如果流量始发于网络的有线侧并传输到无线侧，那么AVC重标记会在流量进入CAPWAP信道去往AP之前生效（当然了，实际上的数据包队列是发生在AP上的，不是在控制器上）。

WLC还基于AVC提供了一些特殊的可视性功能。图19-16展示的信息来自于AVC特性集。在本例中，AVC能够发现并报告上游和下游方向上的应用统计信息，并将信息汇总在一起。图19-16展示了AVC的报告功能。

图19-16 查看AVC应用统计信息报告

19.8 为WLAN部署QoS规划

本书介绍了3种通用的QoS类模型:4类、8类和12类模型。在第18章介绍过，802.11e和WMM最多提供4个AC，或最多使用4条队列。因为这些模型不太容易与现有的接入分类相匹配，因此在设计一个QoS策略，使其融合有线和无线QoS设计的时候，无线网络提出了特殊的挑战。本节将介绍如何为这3个通用类模型创建统一的QoS策略。

19.8.1 4类模型设计

基于WMM 标准，5500 系列WLC 最多支持4 个QoS 类（对应着4 个WMM AC）。表面上看起来这与本书介绍的标准4类QoS模型完全匹配。但实际上若部署了4类模型，还需要考虑如何设计其与4 个WMM AC 的1:1 映射。如果细想4 类模型使用的标准DSCP，以及DSCP 到802.11e UP 值的映射，就会发现结果并不理想。

图19-17展示了标准的4类模型与无线WMM模型。

图19-17 基于4类模型的设计

如图19-17所示，默认的映射结果很出人意料。EF流量可以轻松地映射到Platinum（白金）队列中；在下游方向上，网络控制DSCP（CS3 = DSCP 24）被映射为UP 3（见表18-6），最终进入了尽力而为AC。这是默认的映射关系，并且无法在AireOS WLC 中更改（5760 是基于IOS的控制器，能够修改映射表）。实际效果是园区网中的4类模型到了无线媒介中变成了2类模型。

1.调整下游的QoS分类

尽管这个默认的映射确保为语音流量提供正确的处理方式，但无线QoS中其他的重要应用却最终成为了Silver（银）WMM AC 中的尽力而为流量。特别是语音控制和信令流量没有得到应有的级别，也被当作Silver（银）WMM AC 流量进行处理。

考虑另一种重标记的方法:在连接无线AP的LAN接入交换机上执行重标记行为。在去往PA 的出向接口的出方向上，你可以重标记CAPWAP DSCP 值，比如将控制/ 信令应用类重标记为另一个DSCP值，使其能够在映射到UP值的时候，被分配到Gold（金）WMM AC中。类似地，也可以将尽力而为流量重标记为另一个DSCP值，使其能够在映射到UP值的时候，被分配到Bronze（铜）WMM AC 中。

这种重映射的方法使得Silver（银）WMM AC 仅用于服务业务性数据应用，这也反映出与原始模型相同的优先级级别。

你可能会想到这个问题:与其在与AP相连的接入交换机上配置映射策略，为什么不干脆在WLC上配置AVC策略，使其识别出控制/信令流量并将其重标记为能够映射到Gold（金） WMM AC 的DSCP 值呢？比如可以把信令流量从CS3 重标记为CS4/DSCP 32，这样能确保它获得正确的UP值并进入Gold（金）AC。要时时牢记WLC上的AVC标记策略是同时应用在上游和下游方向上的，它会影响到有线网络中其他部分（其中包括上游网络、WLC和AP之间的传输网络）的QoS策略。举例来说，如果在WLC上将语音控制数据包从CS3重标记为CS4，那么当它到达AP时，它会被放入Gold（金）AC；但WLC与AP之间的（CAPWAP信道经过的）所有路由器和交换机上却有着不一致的分类机制。因此这种方法可能会将数据包在AP上放入正确的下游AC中，但却会破坏传输网络中的QoS。

其实有一个更为简单的方法可以实现相同的效果，也就是在连接AP的接入交换机上设置出方向上的重标记策略。不过，与其将信令流量重标记为一个用于其他应用的DSCP值，不如重标记为一个非标准的DSCP 值，比如DSCP 33。DSCP 33（默认）映射到Gold（金）WMM AC中，还可以唯一地表示重映射的信令流量。这个方法即确保了信令流量在AP上由正确的AC进行处理，还遵守了传输网络中的QoS规划。

类似地，可以在网络接入交换机上，将尽力而为类重映射为非标准的DSCP，使其能够被分配到Bronze（铜）WMM AC 中，比如使用DSCP 9。但是有些平台（比如Catalyst 3750）不支持出向标记策略，只能在入方向上支持标记/ 重标记/DSCP 变化（DSCP Mutation）策略。在这种情况下，在接入交换机的入方向上重标记尽力而为流量将会影响到所有接口的BE标记——并不只影响连接AP的那个接口。

值得一提的是，将默认类分配到Background（背景）WMM类别中，会稍稍延迟尽力而为流量。但这正是QoS的本质，即总要在各种流量之间权衡。在这种环境中，有必要为信令和业务性数据应用类提供更高级别的服务，从而提供4个服务级别，来满足战略性QoS需求。

图19-18展示了修改后的4类QoS模型与WMM的映射。

如前所述，为了实现这个QoS分类模型，需要在数据包进入AP之前，修改CAPWAP头部的DSCP值；需要在AP连接的交换机上进行配置。本质上，每个交换机平台的配置方法都有些许不同。下面以Catalyst 3750X 交换机的配置为例，展示配置结果。

前文已经提过，Catalyst 3750X 不支持出向重标记；只支持在入方向上实施标记或在入方向上实施DSCP变化特性，如图19-19所示。

Catalyst 3750 部署了MLS QoS，有以下两种方式来配置DSCP 重标记策略:

■ 基于类的标记策略（见例19-1）；

■ DSCP变化（见例19-2）。

图19-18 修改后的4类企业模型映射到WMM

图19-19 修改CAPWAP DSCP来匹配QoS分类模型

例19-1 使用基于类的标记，Catalyst 3750下游4类企业模型映射策略到WMM

! This section configures the class-map

C3750-X(config-cmap)# class-map match-all SIGNALING

C3750-X(config-cmap)# match ip dscp cs3

! Signaling traffic is matched on DSCP CS3

! This section configures the Network Downstream Remarking policy map

C3750-X(config-cmap)# policy-map DOWNSTREAM-WMM-REMARKING

C3750-X(config-pmap-c)# class SIGNALING

C3750-X(config-pmap-c)# set dscp 33

! Signaling is re-marked DSCP 33 to map into WMM Gold downstream

! This section attaches the policy to the campus-side interface

C3750-X(config)# interface TenGigabitEthernet2/1/1

C3750-X(config-if)# mls qos trust dscp

! Configures the port to statically trust DSCP on ingress

C3750-X(config-if)# service-policy input DOWNSTREAM-WMM-REMARKING

! Attaches the Downstream DSCP re-marking policy to the interface on ingress

使用下列命令来检查上述配置。

■ show mls qos interface

■ show class-map

■ show policy-map

■ show policy-map interface

例19-2 使用DSCP变化特性，Catalyst 3750下游4类企业模型映射策略到WMM

! This section configures the Downstream DSCP Mutation map

C3750-X(config)# mls qos map dscp-mutation DOWNSTREAM-WMM-MUTATION 24 to 33

! This section attaches the Downstream policy to the campus-side interface

C3750-X(config)# interface TenGigabitEthernet2/1/1

C3750-X(config-if)# mls qos trust dscp

! Configures the port to statically trust DSCP on ingress

C3750-X(config-if)# mls qos dscp-mutation DOWNSTREAM-WMM-MUTATION

! Attaches the Downstream DSCP mutation map to the interface on ingress

使用下列命令来检查上述配置。

■ show mls qos interface

■ show mls qos maps dscp-mutation

2.调整上游的QoS分类

上一小节讨论过的DSCP映射问题在反方向上也存在，而且还具有一个有趣的现象。在上游方向上，802.11e UP 值在CAPWAP 头部被映射为DSCP 值（详见表18-5 和表18-6）。这为语音信令和控制流量带来了一个有趣的问题。大部分移动应用会自动为语音信令使用UP 4（对照着标准的DSCP 值CS3/DSCP 24）。但根据AP 上的UP 到DSCP 映射关系，UP 4 会映射为DSCP 26（AF31），而不是你希望的DSCP 24（CS3）。这种转换DSCP 值导致的不匹配，意味着CAPWAP数据包途径的底层IP传输网络会因为DSCP值变化了，而无法识别出这是语音控制流量。

与下游方向上的问题类似，可以手动配置连接AP的LAN交换机，在入向端口上配置重标记策略。在本例中，可以把QoS 策略配置为将所有DSCP AF31 流量转换为DSCP CS3。这样做可以确保IP传输网络正确地管理CAPWAP信道中的语音控制流量。

例19-3 以Catalyst 3750 为例，展示了上游入向配置，将信令流量从AF31 重映射为企业标记CS3。

例19-3 Catalyst 3750上游信令标记恢复

! This section configures the class map

C3750-X(config-cmap)# class-map match-all AP-SIGNALING

C3750-X(config-cmap)# match ip dscp af31

! Signaling traffic from the AP is matched on DSCP AF31

! This section configures the Network Upstream Remarking policy map

C3750-X(config-cmap)# policy-map UPSTREAM-WMM-REMARKING

C3750-X(config-pmap-c)# class AP-SIGNALING

C3750-X(config-pmap-c)# set dscp cs3

! Signaling is re-marked to DSCP 24 to align to enterprise QoS model

! This section attaches the upstream policy to the AP-connected interface

C3750-X(config)# interface GigabitEthernet1/0/10

C3750-X(config-if)# mls qos trust dscp

! Configures the port to statically trust DSCP on ingress

C3750-X(config-if)# service-policy input UPSTREAM-WMM-REMARKING

! Attaches the upstream DSCP re-marking policy to the AP interface on ingress

使用下列命令来检查上述配置。

■ show mls qos interface

■ show class-map

■ show policy-map

■ show policy-map interface

19.8.2 8类模型设计

如果园区网使用的是8 类模型，那么在无线网络上使用4 WMM AC 模型就更灵活了。图19-20 展示了AP 上使用的DSCP 到802.11e UP 值的映射。

与4类模型类似，实时语音流量被映射到Platinum（白金）策略中；但这次还增加了视频流量，并为其使用Gold（金）策略。在8类模型中，并没有使用网络控制（也就是OSPF、BGP、OAM [Operations, Administration, and Maintenance] 等），因此可以忽略这类流量。与4类模型一样，信令（CS3）、业务性数据（AF21）和尽力而为流量最终会被映射到Silver（银） AC中。再强调一遍，这种映射对于语音控制流量来说并不是最好的，但这是不可避免的，因为IETF 和IEEE 802.11e 的QoS 映射关系本身就不是很一致。

图19-20 基于8类模型的设计

EF、AF41、AF31 和AF21 在802.11e UP 到DSCP 的映射表中是一一映射的，因此上游数据包在底层IP传输网络中是按照预期处理的。只有CS3流量的映射不正确，映射为AF31（DSCP 26）。与4类模型中介绍的方法相同，可以在连接AP的接入交换机上使用DSCP变化特性，将信令流量修改到正确的AC中。

19.8.3 12类模型设计

如果园区网使用的是12类模型，就为无线接口提供了更细粒度的应用管理。图19-21展示了如何将12 类模型映射为802.11e UP 值。

在12类模型中，不需要使用网络控制（CS6）或OAM（CS2）类，因为这些流量通常并不会通过无线网络进行发送。如图19-21所示，所有视频应用都正确地映射到了Gold（金）AC中，与4类和8类模型一样的那些类映射到Silver（银）AC中。这里涉及的新内容是将大数据应用映射到Bronze（铜）AC中。

图19-21 基于12类模型的设计

19.9 小结

本章讨论了企业WLAN 中的QoS 角色，使用WLC 5500 系列控制器和Cisco 无线AP。介绍了WLAN基础设施中的各个QoS实施位置，还分别介绍了应用在不同位置的QoS工具。

接着详细介绍了WLC 5500 系列控制器的QoS 设计，其中包括4 个QoS 配置文件，以及它们是如何在WLC中工作的。本章讨论了QoS设计的多个方面，其中包括将语音和视频WLAN分隔开来，并对其实施相应的QoS策略。还讨论了一些重要的QoS特性，其中包括如何限制每个无线客户端的速率，以及如何为访客用户部署QoS策略。

下一节讨论了在WLAN中支持实时应用时，最佳做法建议的设计原则，其中包括调整WLAN中EDCA的性能，以及如何实施CAC——这是部署无线网络时必须且建议使用的QoS特性。

下一节讨论了如何使用媒体会话侦听策略，检测SIP流量并对其应用特殊的QoS策略。AP和WLC上都可以应用该特性，可以为SIP数据包提供正确的QoS处理方式，即使源设备并没有正确地标记SIP流量。本节还介绍了在混合流量的WLAN中使用语音应用时，应该在Platinum（白金）配置文件的基础上，使用媒体会话侦听特性，这也是最佳做法的建议。

尽管媒体会话侦听是一项很有用的特性，但AVC 特性能够利用Cisco NBAR2 技术，识别出上千种应用并为其应用自定义的QoS策略。本节通过一个详细的案例，说明了当混合应用WLAN中应用了实时服务时，如何使用AVC特性。

最后一节介绍了如何与园区有线网络使用的4类、8类和12类模型相集成。其中IETF和IEEE DSCP 的映射不匹配带来了一些问题。本节提出的解决方案建议能够使受到不匹配影响的应用获得正确的QoS级别。

19.10 扩展阅读

WLAN语音设计指南4.1:http://www.cisco.com/en/US/partner/docs/solutions/Enterprise/Mobility/vowlan/41dg/vowlan41dg-book.html

WLAN控制器配置指南7.3:http://www.cisco.com/en/US/partner/docs/wireless/controller/7.3/configuration/guide/b_cg73.html

Cisco统一无线IP电话7921部署指南:http://www.cisco.com/en/US/products/hw/phones/ps379/prod_installation_guides_list.html

Cisco兼容扩展项目:whttp://www.cisco.com/go/ccx

第20章 融合接入（Cisco Catalyst 3850和Cisco 5760无线LAN控制器）QoS设计

到目前为止，本书的第4部分已经涵盖了如今部署的无线覆盖模型，以及当前基于5508 WLAN控制器的CUWN（Cisco统一无线网络互联）无线解决方案。这个解决方案提供了一个集中式的无线控制器，能够通过集中式GUI（图形用户界面）对AP（接入点）应用QoS策略。这个解决方案中的应用分类是基于接入边界上的端点设备设置的WMM（Wi-Fi多媒体）值进行的，或者是在WLC（WLAN 控制器）上使用DPI（深度数据包检测；比如Cisco 的AVC [ 应用可视性控制]）技术实现的。还可以使用第18章和第19章介绍的多种特性，在保持整体架构不变的基础上，增强这个解决方案。

本章为有线和无线应用定义了一个新的范式，称为融合接入（Converged Access）。这个称号将它设置在了接入PIN（网络中的位置），事实上，融合接入解决方案中涵盖Catalyst 3850 接入交换机和Cisco 5760 WLC，它们是Cisco 于2013 年初发布的产品。本章讨论的设计也可应用于3650和3850。

当前的CUWN 集中式控制器架构已经可以由Cisco 5760 来提供支持了，其中的些许区别会在本章后文中详述。最主要的区别在于QoS的配置。举例来说，在集中式控制器模式中， Cisco 5760 提供完全符合MQC CLI QoS 的部署方式，并且与WLC 5508 使用的方式相同， Cisco 5760 针对每个SSID 来部署QoS 策略，并与AP 之间协商建立CAPWAP 协议信道，并通过CAPWAP信道向AP推送上游策略。由AP来实施控制器向它应用的上游重标记策略。从QoS 的角度看来，这个模型类似于WLC 5508，只是Cisco 5760 的QoS 是通过MQC CLI 进行配置的。

融合接入架构还提供了一个分布式模式，Catalyst 3850 交换机在这里充当了主要角色。作为分布式架构的一部分，Catalyst 3850 通过ACL 提供了应用可视性，以及其他常用的分类技术。它是通过终结CAPWAP信道来提供上述功能的，因为这样它就可以查看第2层到第7层的数据包信息了。正因为这一点，Catalyst 3850 可以为有线和无线流量建立信任边界，这一点与Catalyst 3750 为有线流量建立信任边界是一样的。

图20-1 展示了这个新的分布式架构，Cisco 5760 控制器加上边界上的Catalyst 3850 交换机，共同提供了移动性。在这个场景中，可以将Catalyst 3850 放入SPG（交换机对等体组）中。SPG就是一组交换机，它们可以在客户端之间提供本地漫游服务，这一点与前文介绍的CUWN 架构不同，前者所有流量都终结在Cisco 5508 WLC 上。你可以把Catalyst 3850 或者Catalyst 3850 堆叠定义为MA（移动代理）。在一个SPG 中，Catalyst 3850 在MA 之间构建出全网状的CAPWAP信道。在SPG技术中，以下两个术语描述了客户端漫游。

■ PoP（存在点，Point of Presence）:有线架构在网络中第一次看到无线流量的位置。

■ PoA（附着点，Point of Attachment）:用户加入或漫游的AP。

图20-1 融合接入架构

当客户端在一个SPG中的交换机之间漫游时，流量由PoA（也称为Foreign Controller）发出，通过CAPWAP 信道回到PoP（也称为Anchor Controller）。始发流量的交换机是PoP，它将流量发送到它的目的地。不过如果SPG之间发生了漫游，流量将会穿越被定义为MC（漫游控制器）的Cisco 5760 控制器，这与流量在使用5508 WLC 的CUWN 中的做法相同。由于流量行为是这样的，因此当拥有一个较大的SPG 时，若流量必须发送到Cisco 5760 控制器，最好对实例做出一定的限制。

注释:在较大的部署环境中，Cisco 5760被用作MC，Catalyst 3850也可以被配置为MC。

注释:网络管理员应该平衡理想的SPG大小和SPG内部全互联带来的隧道数量，并且要在设计中谨慎考量交换机为多个漫游客户端提供服务的情况。在大厦的一层进行部署，或者在一栋建筑内的小型部署都属于上述情况。

这个新架构有一点需要重点强调一下，就是它提供了与其他基于MQC的平台（Catalyst 4500 Sup 6/7、Catalyst 6500 Sup2T、ISRG2、ASR1000）相同的有线和无线QoS 分类/ 标记/ 限速策略。Cisco 5760 WLC 和Catalyst 3850 以相同的方法执行QoS。由于它们位于不同的PIN，因此可以说它们可能会拥有不同的QoS角色。第21章通过详细的配置强调了角色上的差异性。

注释:Cisco 5760和Catalyst 3850的QoS配置是相同的，因此本章将基本上重点关注QoS，可能通过配置来描述Catalyst 3850上的QoS，Cisco 5760的配置完全一样。

注释:WMM UP标记是根据各种流量类型对于网络的需求作出的。WMM UP标记并不会考虑客户的业务优先级，也不会为特定移动设备上的指定应用提供特殊标记。能否在无线媒介上正确实施QoS标记，取决于以下厂商的协同工作:应用程序供应商、移动设备OS开发商以及移动设备硬件生产商。因此，仅仅依赖于WMM来分类流量，有时可能会出现错误标记的DSCP值，从而导致将流量放入错误的队列中。要记住5508 WLC依赖WMM来实施流量分类。融合接入控制器在接入边界提供了更强的分类能力，有时可以解决将流量放入错误队列的问题。

20.1 融合接入

园区网接入交换机的QoS角色是在边界区分并管理流量，以及管理丢包。正如第14章讨论的，Cisco Catalyst 3750 的角色是接入交换机，主要为有线接入的客户端提供服务。设计章节扩展了接入交换机的角色范围，因为这里将有线和无线客户端都作为融合接入的一部分来考虑。图20-2展示了融合园区网接入交换机与端口相关的QoS角色。

融合接入交换机添加了无线端口角色，在功能上超越了Cisco Catalyst 3750 交换机。它在有线客户端角色和无线客户端角色之间建立起参照物，从而促进了有线和无线QoS的统一。不过在配置每个媒介中的目标（即为无线客户端配置SSID策略，为有线客户端配置基于端口的策略）时，这个界限会变得模糊。

图20-2 融合接入交换机的端口QoS角色

接下来的内容将先介绍平台的体系结构，尤其是与QoS相关的部分。

20.2 Cisco Catalyst 3850 QoS体系结构

从QoS的角度看来，Cisco Catalyst 3850（后文简称Catalyst 3850）是接入交换机的新产品。它属于2k/3k家族，通过内部无线控制模块（称为WCM）来为无线客户端提供支持。它的硬件架构与Cisco Catalyst 3750 类似，即Catalyst 3850 也能够堆叠，也能够提供共享的缓存池。表20-1总结了这两个平台上的主要区别。

表20-1 Cisco Catalyst 3750-X、3850:主要特性和功能列表

图20-3和图20-4展示了这一平台的QoS架构，分为两个部分，分别是有线到无线，以及无线到有线。由于无线和有线技术本质上的区别，这里也强调了在两个模型中实施QoS的位置。要知道本节提到的实施位置并不是必需的，只是为了更好地理解架构而介绍所有可以实施的位置。

图20-3 Cisco Catalyst 3850 QoS架构模型:有线到无线

从有线去往无线端口（连接到AP）的流量是根据class map 来分类的。可以在物理交换机端口上，或者在SVI（交换机虚拟接口）上应用标记或限速策略，但在本书写作时，还不支持使用每端口/ 每VLAN 的策略。Catalyst 3750 提供入向队列，目前Catalyst 3850 还无法配置入向队列，因为内部堆叠环（Internal Stack Ring）的规模增加了。

当流量离开无线端口后，有多个QoS接触点需要考虑。无线端口是指直接连接AP的任意端口。客户端级别的流量是通过class map，在出方向上进行分类的，并为两个不同类型的流量提供了严格优先级队列。针对每个客户端还要考虑的是对优先级流量和默认流量应用的出向标记和策略。优先级流量会绕过所有整形策略，并直接发到物理端口，由物理端口进行调度。

SSID 级别的流量也是使用class map，在出方向上进行分类的。在这一级别除了可以使用限速和标记外，还可以使用整形命令来限制每射频SSID上的流量速率（bssid）。虽然这项功能被认定为整形器，但它是将队列限制设置为0，这意味着它不能缓存流量，因此只能用它限制SSID级别的流量。也可以为SSID配置带宽，来限制共享射频的多个SSID使用的带宽百分比。这种配置在以下环境中非常实用:访客SSID中的多个访客消耗大量射频带宽，同时企业用户连接在另一个SSID上，这两个SSID共享相同的射频带宽。

注释:如何配置Catalyst 3850 和Cisco 5760 取决于Cisco 5760 的使用位置。如果将Cisco 5760 作为集中式控制器（像Cisco 5508 无线控制器那样），那么SSID 级别的QoS 策略通常是推送到AP 的一项常规配置。这与Cisco 5508 的配置是类似的。如果将Cisco 5760 与Catalyst 3850结合使用，Cisco 5760在SSID级别设置的QoS策略并不会推送到AP，而是由Catalyst 3850的配置来管理接入边界的QoS。

注释:SSID级别的优先级限速器只对单播优先级流量有效。物理级别的优先级限速器只对组播优先级流量有效。

在本书写作时，无法配置射频级别的QoS。但有必要对此进行一些说明。射频级别能够对去往无线端口的出向流量实施整形。射频接口会与相关联的AP协商出最大速率，并以此限制发往AP的流量。每个AP都会与AP内部的每个射频接口进行速率协商，然后由WCM为所有无线端口实施协商后的策略。

端口级别的流量归属于4条出向队列，其中两条是严格优先级队列。非实时流量队列是默认类，组播非实时队列用于所有非实时的组播流量。根据class map 来实施分类，并且这个级别提供限速服务。端口整形器不可配置，它是基于射频级别的整形器协商生成的。这个整形器为AP自己接收到的流量提供最大速率限制。AP的速率协商完成后，端口整形器将所有射频速率汇总在一起，接着WCM将这些策略应用到无线接口。

队列调度机制是结合了优先级队列的CBWFQ；带宽管理算法是AFD（近似公平丢弃），在用户之间提供了公平服务；本章后续内容将详细介绍这两种机制。

图20-4展示了反向的数据流，即从无线端口去往有线端口，网络架构保持不变。

图20-4 Cisco Catalyst 3850 QoS架构模型:无线到有线

对于从无线客户端通过AP 进入Catalyst 3850 的流量，在入方向上实施分类。标记或限速策略可以应用到每个客户端上，或者应用在整个SSID上。

在入方向上分类的流量也可以在SSID级别限速或标记。在本书写作时，这个级别没有与客户端级别关联（Chained）在一起，它与基于VLAN的策略类似。你可能决定为用户和组同时实施客户端级别的策略和SSID级别的策略。

注释:Chaining的意思是提供一个覆盖或汇聚点。举例来说，客户端级别的限速器不能超过SSID级别的汇聚限速器。如果单个客户端的限速器设置为12Mbit/s，SSID限速器设置为10Mbit/s，客户端限速器允许以12Mbit/s的速率传输数据。通过使用Chaining，SSID级别的限速器会在客户端级别发送12Mbit/s流量后，把超额的2Mbit/s流量丢弃。同理，如果在客户端级别和SSID级别都实施了标记，SSID级别的标记策略优先生效。

流量通过有线端口离开Catalyst 3850 交换机时，分类还是通过class map 完成的。标记和限速策略可以配置在物理交换机端口上，也可以配置在SVI接口上。

队列调度机制使用的是CBWFQ和双LLQ，丢弃算法使用的是WTD（加权尾部丢弃）。

可以配置出向分层整形，将端口整形为特定的速率。

20.3 QoS设计步骤

Cisco Catalyst 3850 系列交换机上的QoS 配置可以支持多种设备类型，其中包括有线设备和无线设备。由于这种万能的支持属性，类似条件信任的特性只能应用到特定设备上（Cisco IP电话、数字媒体播放器、TelePresence系统等），这些设备通常是连接在有线端口上的。应用到无线端口类型的出向队列需遵从WMM的定义，即包含4条队列；这与遵从其他网络交换机定义的有线端口有些不同。在考虑以下设计步骤时，上述内容都要考虑进来。

1.配置入向QoS模型，包括以下内容。

■ 有线端口客户端或无线客户端:服务策略模型；

■ 仅用于有线端口:条件信任。

2.配置出向队列。

接下来将依次介绍这些设计步骤。

20.3.1 启用QoS

Catalyst 3750 使用的是基于MLS 的QoS 配置平台，而Catalyst 3850 使用的是基于MQC的配置平台。也就是说Catalyst 3850 默认就是启用了QoS 的，并且默认QoS 标记在穿越平台时是不会被重标记的。在本书写作时，Catalyst 3850 对上述规则添加了一种例外情况。如果流量从无线端口去往有线端口，或者反过来，QoS值会被重标记为默认值（0）。不过这条规则并不影响从有线端口去往有线端口的流量。要想取消这一限制，可以在全局配置模式下禁用默认的untrust命令，这样Catalyst 3850就会与其他基于MQC的设备一样，遵从相同的信任行为。了解这一点很重要，因为这个边界会重写QoS标记策略。例20-1展示了要想规避不信任的行为，在SSID级别需要配置的命令；以及在未来部署信任规则所需的配置。

例20-1 在Catalyst 3850上启用信任行为

! This section enables default DSCP-to-DSCP copying

C3850(config)# table-map dscp2dscp

C3850(config-tablemap)# default copy

! Incoming DSCP values will be preserved 1:1

! This section enables default DSCP-to-UP copying

C3850(config)# table-map dscp2up

C3850(config-tablemap)# default copy

! DSCP values will be mapped to WMM UP values

! This section configures the downstream trust policy map

C3850(config)# policy-map TRUST-DOWN

C3850(config-pmap)# class class-default

C3850(config-pmap-c)# set dscp dscp table dscp2dscp

! DSCP values will be preserved in the downstream policy

C3850(config-pmap-c)# set wlan user-priority dscp table dscp2up

! WMM UP values will be set based on DSCP in the downstream policy

! This section configures the upstream trust policy map

C3850(config)# policy-map TRUST-UP

C3850(config-pmap)# class class-default

C3850(config-pmap-c)# set wlan user-priority dscp table dscp2up

! WMM UP values will be set based on DSCP in the upstream policy

! This section attaches the policies to the WLAN

C3850(config)# wlan BRILEY-1

C3850(config-wlan)# service-policy out TRUST-UP

! Applies upstream trust policy to the WLAN

C3850(config-wlan)# service-policy out TRUST-DOWN

! Applies downstream trust policy to the WLAN

为了使Catalyst 3850 遵从与其他MQC 平台相同的信任行为，需要使用例20-2 所示命令。

例20-2 在Catalyst 3850上启用信任行为

! This section enables global trust

C3850(config)# no qos wireless-default-untrust

使用下列命令来检查上述配置。

■ show run

■ show policy-map interface wireless（见例20-3）

注释:为了减少重复，通常只会展示一条show命令的输入内容。

例20-3 检查Catalyst 3850上应用的策略:show policy-map interface

C3850# show policy-map interface wireless ssid name BRILEY-1

Remote SSID BRILEY-1 iifid:0x0100B9C00000003B.0x00E2F44000000006.0x00F6208000000009

Service-policy input:TRUST-UP

Class-map:class-default (match-any)

Match:any

QoS Set

dscp dscp table dscp2dscp

20.3.2 入向QoS模型

入向QoS模型包括以下内容:

■ 只用于有线端口的条件信任模型；

■ 有线端口和无线客户端模型:

■ 分类和标记模型；

■ 可选的限速模型。

接下来将依次介绍入向QoS模型中包含的内容。

1.只用于有线端口的条件信任模型

在基于MQC的平台上（比如Catalyst 3850）没有明确信任的概念（因为信任都是隐含的）。但“明确信任”这个术语现在也泛指分类和标记QoS值，这与经典的MLS平台上实施信任的做法类似。条件信任特性本身能够动态地检查下列类型的设备。

■ cisco-phone:对Cisco IP 电话实施条件信任。

■ cts:对Cisco TelePresence 系统实施条件信任。

■ ip-camera:对Cisco IP 视频监控摄像头实施条件信任。

■ media-player:对Cisco数字媒体播放器实施条件信任。

Catalyst 3850通过CDP（Cisco发现协议）来检查上述设备，并将信任边界扩展到设备上。可以使用接口命令trust device 来配置条件信任，可以使用上述关键字（cisco-phone、cts 等）来针对特定的设备类型启用条件信任，一旦通过CDP协商证实了所连设备的类型，Catalyst 3850就会将信任边界扩展到设备上。Cisco电话在从与其相连的终端设备那里收到流量后，并不会重标记流量的DSCP值，因此建议使用信任CoS特性。没有这种限制的设备应该配置信任DSCP特性。这种类型的信任必须通过基于MQC的策略来指明，例20-4给出了相关配置。例20-5展示了如何检查条件信任的状态。

注释:目前并不提供扩展到无线设备的信任特性。

例20-4 在Catalyst 3850上启用条件（CoS模式）信任

! This section configures the class maps

C3850(config-cmap)# class-map match-all VOICE

C3850(config-cmap)# match cos 5

C3850(config-cmap)# class-map match-all SIGNALING

C3850(config-cmap)# match cos 3

! This section defines the CoS-to-DSCP remarking policy map

C3850(config-cmap)# policy-map CISCO-IPPHONE

C3850(config-pmap)# class VOICE

C3850(config-pmap-c)# set dscp ef

! Maps CoS 5 to DSCP EF

C3850(config-pmap-c)# class SIGNALING

C3850(config-pmap-c)# set dscp cs3

! Maps CoS 3 to DSCP CS3

C3850(config-pmap-c)# class class-default

C3850(config-pmap-c)# set dscp default

! This section attaches the policy to the interface(s)

C3850(config)# interface GigabitEthernet 1/0/13

C3850(config-if)# trust device cisco-phone

! This provides CDP-negotiation of device in question

C3850(config-if)# service-policy input CISCO-IPPHONE

! Attaches the CoS-to-DSCP mapping policy-map

例20-5 检查Catalyst 3850上的条件信任:show platform qosadvanced qsb gigabitEthernet 1/0/13

C3850# show platform qos advanced qsb gigabitEthernet 1/0/13

QoS Subblock contents...

def_cos = 0, def_cos_enable = 0, def_qos_label = 0

def_priority = 13, trust_enabled = 1

input_trans_index = 0, output_trans_index = 0

def_queuing = 1, trust_type = TRUST_DSCP, client_handle = 0

policy_trust = TRUST_DSCP

...

2.分类和标记模型

在很多场景中，可能无法使用信任模型，或者不足以满足端到端QoS战略模型分类所有类型流量的需求。因此接入边界可能需要应用明确的分类和标记策略。

融合接入的一个目标是通过协调无线和有线客户端之间的CLI，来简化QoS的部署。有线和无线客户端可以共享基本的入向分类和标记策略，这会使部署便得更为简单，并且使策略管理变得更加轻松。为了简单明了，例20-6根据图11-5（8类QoS模型），给出了应用于有线和无线客户端的配置案例。

注释:如前所述，并不是所有应用类都会出现在接入边界的入方向上。比如流媒体视频就很可能不会出现在接入边界的入方向上（因为这些流量并不源于园区网中的终端设备，而是去往这些设备），源于园区网终端设备的网络控制流量也不会出现在接入边界的入方向上。因此不需要在接入边界的分类和标记policy map中包含这些类。

注释:为了简化配置，策略案例中省略了ACL的配置。

例20-6 Catalyst 3850上的分类和标记策略案例

! This section configures the class maps

C3850(config-cmap)# class-map match-all VOICE

C3850(config-cmap)# match dscp ef

! Voice is matched on DSCP EF

C3850(config-cmap)# class-map match-all INTERACTIVE-VIDEO

C3850(config-cmap)# match access-group name INTERACTIVE-VIDEO

! Associates INTERACTIVE-VIDEO access-list with class map

C3850(config-cmap)# class-map match-all SIGNALING

C3850(config-cmap)# match dscp cs3

! Signaling is matched on DSCP CS3

C3850(config-cmap)# class-map match-all TRANSACTIONAL-DATA

C3850(config-cmap)# match access-group name TRANSACTIONAL-DATA

! Associates TRANSACTIONAL-DATA access-list with class map

C3850(config-cmap)# class-map match-all SCAVENGER

C3850(config-cmap)# match access-group name SCAVENGER

! Associates SCAVENGER access-list with class map

! This section configures the ingress marking policy map

C3850(config-cmap)# policy-map MARKING

C3850(config-pmap)# class VOICE

C3850(config-pmap-c)# set dscp ef

! VoIP is marked EF

C3850(config-pmap-c)# class SIGNALING

C3850(config-pmap-c)# set dscp cs3

! Signaling is marked CS3

C3850(config-pmap-c)# class INTERACTIVE-VIDEO

C3850(config-pmap-c)# set dscp af41

! Interactive-Video is marked AF41

C3850(config-pmap-c)# class TRANSACTIONAL-DATA

C3850(config-pmap-c)# set dscp af21

! Transactional Data is marked AF21

C3850(config-pmap-c)# class SCAVENGER

C3850(config-pmap-c)# set dscp cs1

! Scavenger traffic is marked CS1

C3850(config-pmap-c)# class class-default

C3850(config-pmap-c)# set dscp default

! This section attaches the service policy to the wired interface(s)

C3850(config)# interface range GigabitEthernet 1/0/1-48

C3850(config-if-range)# switchport access vlan 10

C3850(config-if-range)# switchport voice vlan 110

C3850(config-if-range)# spanning-tree portfast

C3850(config-if-range)# service-policy input MARKING

! Attaches the per-port marking policy to the wired interface(s)

! This section attaches the service policy to the wireless client(s)

C3850(config)# wlan BRILEY-1

C3850(config-wlan)# service-policy client input MARKING

Catalyst 3850 交换机上提供的无线功能，可以在WLAN SSID 下使用关键字client，将策略关联到指定客户端。在使用了关键字client时，策略是应用在授权进入SSID的每个无线客户端上的，并且是独立地应用在每个客户端上，详见例20-6。在使用service-policy命令时若不使用关键字client，策略将会应用到整个SSID中，并会影响所有客户端。

在将策略应用到SSID后，它在BSSID上生效，也就是针对每AP或每SSID生效。举例来说，若将同一个SSID 应用到Catalyst 3850 所连接的多个AP 上，策略是分别应用到每个AP/SSID对上的。

注释:对于有线端口来说，可以在每端口的基础上，或在每VLAN的基础上部署分类和标记模型；对于无线端口，可以在每客户端的基础上，或在每SSID的基础上部署分类和标记模型（详见第21章）。

使用下列命令来检查相关配置:

■ show class-map

■ show policy-map

■ show policy-map interface

■ show policy-map interface wireless ssid

■ show policy-map interface wireless client

■ show platform qos dscp-cos counters

注释:Catalyst 3850中的show policy-map interface命令并不会显示分类计数（在其他设备上使用这条命令会显示）。show platform qos dscp-cos counters命令通过冗长且繁杂的命令输出，提供了一些统计信息，这些统计信息与Catalyst 3750中show mls qos interface statistics命令的输出内容差不多。为了简洁起见，本章并没有给出这些命令的输出案例。

3.分类、标记和限速模型

在园区网接入边界也可以（可选地）部署限速策略，来管理应用流量并丢弃无用流量。

在例20-7中，12类战略QoS模型（基于图11-7）经修改适应了融合接入边界（从策略中删除了不会出现在园区网接入边界的应用类，比如网络控制和流媒体视频），此外还将源于语音VLAN和源于数据VLAN的流量分隔开来。这种区分只能应用在有线端口上，不能应用在无线端口上，因为可能并没有为无线客户端区分语音和数据VLAN。使用相同的class map 名称来展示为有线设备和无线设备应用相同的policy map 和class map。

在本例中，为从语音VLAN发来的VoIP和信令流量进行限速，分别使用丢弃门限值128kbit/s和32kbit/s（如果有过多的流量匹配了这个类别，意味着网络中有滥用行为）。类似地，可以为从数据VLAN发来的多媒体会议、信令和清道夫流量进行限速并丢弃。相对而言，可以为业务性、大数据和尽力而为数据流量应用数据层面的限速策略，如果这些流量严重超出配置文件的限制，会被重新标记（但并不会在入向边界丢弃）。通过使用全局配置命令table-map MARKDOWN-TABLE，可以配置重标记行为，可以配置从哪个DSCP 值重标记为哪个DSCP值，为超出配置文件限制的流量重新标记DSCP值（在本例中，数据层面限速/清道夫类QoS 策略使用的DSCP 值是CS1/DSCP 8）。

注释:为了简化配置并减少重复，本例并没有给出应用在策略中的class map配置。还要注意， VVLAN-* class map只根据DSCP值来分类流量，并不使用其他class map调用的ACL。本例将这些class map同时应用于有线策略和无线策略，减少了所需的class map数量，但实际上无线网络可能并不会区分语音和数据VLAN。

例20-7 Catalyst 3850上的分类、标记和限速策略案例

! This section configures the global DSCP markdown table map

C3850(config)# table-map MARKDOWN-TABLE

C3850(config-tablemap)# map from 0 to 8

C3850(config-tablemap)# map from 10 to 8

C3850(config-tablemap)# map from 18 to 8

! This section configures the policing policy map

C3850(config)# policy-map POLICING

C3850(config-pmap)# class VVLAN-VOIP

C3850(config-pmap-c)# set dscp ef

C3850(config-pmap-c)# police 128k conform-action transmit exceed-action drop

! VoIP is marked EF and policed to drop at 128 Kbps

C3850(config-pmap-c)# class VVLAN-SIGNALING

C3850(config-pmap-c)# set dscp cs3

C3850(config-pmap-c)# police 32k conform-action transmit exceed-action drop

! (VVLAN) Signaling is marked CS3 and policed to drop at 32 Kbps

C3850(config-pmap-c)# class MULTIMEDIA-CONFERENCING

C3850(config-pmap-c)# set dscp af41

C3850(config-pmap-c)# police 5m conform-action transmit exceed-action drop

! Multimedia-conferencing is marked AF41 and policed to drop at 5 Mbps

C3850(config-pmap-c)# class SIGNALING

C3850(config-pmap-c)# set dscp cs3

C3850(config-pmap-c)# police 32k conform-action transmit exceed-action drop

! (DVLAN) Signaling is marked CS3 and policed to drop at 32 Kbps

C3850(config-pmap-c)# class TRANSACTIONAL-DATA

C3850(config-pmap-c)# set dscp af21

C3850(config-pmap-c)# police 10m conform-action transmit exceed-action set-dscp-

transmit dscp table MARKDOWN-TABLE

! Trans-data is marked AF21 and policed to remark (to CS1) at 10 Mbps

C3850(config-pmap-c)# class BULK-DATA

C3850(config-pmap-c)# set dscp af11

C3850(config-pmap-c)# police 10m conform-action transmit exceed-action set-dscp-

transmit dscp table MARKDOWN-TABLE

! Bulk-data is marked AF11 and policed to remark (to CS1) at 10 Mbps

C3850(config-pmap-c)# class SCAVENGER

C3850(config-pmap-c)# set dscp cs1

C3850(config-pmap-c)# police 10m conform-action transmit exceed-action drop

! Scavenger traffic is marked CS1 and policed to drop at 10 Mbps

C3850(config-pmap-c)# class class-default

C3850(config-pmap-c)# set dscp default

C3850(config-pmap-c)# police 10m conform-action transmit exceed-action set-dscp-

transmit dscp table MARKDOWN-TABLE

! All other traffic is marked 0 and policed to drop at 10 Mbps

! This section attaches the service policy to the wired interface(s)

C3850(config)# interface range GigabitEthernet 1/0/1-48

C3850(config-if-range)# switchport access vlan 10

C3850(config-if-range)# switchport voice vlan 110

C3850(config-if-range)# spanning-tree portfast

C3850(config-if-range)# service-policy input POLICING

! Attaches the per-port policing policy to the wired interface(s)

! This section attaches the service-policy to the wireless client(s)

C3850(config)# wlan BRILEY-1

C3850(config-wlan)# service-policy client input POLICING

注释:Catalyst 3850 IOS 软件允许在设置限速速率时使用后缀k（千比特）、m（兆比特）和g（吉比特），详见例20-7。除此之外，在限速速率设置中还能使用小数点。举例来说，要想将速率限制为10.5 Mbit/s，可以在policy map中使用命令police 10.5m。尽管这些限速速率在配置中会转换成比特每秒为单位的完整数值，但这种配置语法提供了更为友好且不容易出错的配置方式（要是在定义限速速率时一连输入10个0，出错的几率就大多了）。

注释:尽管在技术层面上，可以在每VLAN的基础上应用一个聚合的限速策略（比如上述策略），但并不建议这么做。这是因为每个VLAN中的端点设备数量可能会有很大差别，而限速速率又是静态地固定在一个汇聚层面上，最终会导致无法预测为每个端点设备分配的带宽。以访客接入为例，每VLAN限速有助于汇聚并限制这些流量对于共享的企业WAN带来的影响。这时，要受保护的流量是企业流量，而并不是某个访客的流量。

注释:基于每客户端的无线策略可能需要更为严格的限速策略，这是由可用带宽的本质决定的。当基于每客户端的策略无法满足需求时（访客接入），还要考虑在SSID上使用汇聚级别的策略。尽管无线客户端的数量也像VLAN中的客户端数量一样，每个SSID之间可能会差别很大，但无线媒介可以使用汇聚的SSID策略，因为这个策略是与每用户AFD（公平算法）协同工作的，后文将详细介绍AFD。

使用下列命令检查例20-7中的配置。

■ show class-map

■ show policy-map

■ show table-map（详见例20-8）

■ show platform qos policy target（详见例20-9）

■ show platform qos policy hw_state target（详见例20-10）

■ show policy-map interface brief（详见例20-11）

■ show policy-map interface（详见例20-12）

例20-8 检查Catalyst 3850上的全局限速降级表:show table-map

C3850# show table-map

Table Map MARKDOWN-TABLE

from 0 to 8

from 10 to 8

from 18 to 8

default copy

例20-8 显示了降级表。from 描述的是入站值，to 描述的是降级后的值。default copy 表示信任，或保留数据包的入向标记。SSID 级别的table map 专门用作降级工具来重标记流量；其他级别的table map 还提供了set 命令。

例20-9 检查Catalyst 3850上的接口限速器:show platform qospolicy target gigabitEthernet 1/0/10

C3850# show platform qos policy target gi 1/0/10

Input policy:

--------------

POLICY:POLICING Num Classes:8 Targets:0

...

Target:Gi1/0/10 DIR:IN STATE:SET IN HW LE_LABEL:2, client_policy_type:LE

IF:0x010351800000001f TCCGs:8 TCG:0x4a54adfc Next:(nil) Prev:(nil)

CLASS:VVLAN-VOIP

Action flags:0x5

AG Policer Action Num:0

Rate:128000 Peak:0

Limit:0 ExtLimit:0

BC:4000 Peak:0

Color Mode:Color Blind Type:1R2C

Mark DSCP Action:46

CLASS:VVLAN-SIGNALING

Action flags:0x5

AG Policer Action Num:1

Rate:32000 Peak:0

Limit:0 ExtLimit:0

BC:1500 Peak:0

Color Mode:Color Blind Type:1R2C

Mark DSCP Action:24

CLASS:MULTIMEDIA-CONFERENCING

Action flags:0x5

AG Policer Action Num:2

Rate:5000000 Peak:0

Limit:0 ExtLimit:0

BC:156250 Peak:0

Color Mode:Color Blind Type:1R2C

Mark DSCP Action:34

...

Additional details for policy:POLICING

Number of targets attached to:1

Number of targets policy successfully programmed in HW:1

例20-9更为详细地显示了策略的内容。需要注意的是策略所关联的目标数量，以及这个策略是否成功在硬件中调用。

例20-10 在Catalyst 3850中检查安装在硬件中的policy-map:showplatform qos policy hw_state target gigabitEthernet 1/0/10

C3850# show platform qos policy hw_state target gi 1/0/10

Input policy:POLICING

H/W programming State:INSTALLED IN HW

Output policy:Not attached

例20-10显示出接口G1/0/10的QoS策略已经安装在硬件中了。在某些情况中，策略可能无法正确安装（比如应用了错误的类编号，或者使用了错误的标记方法）。虽然在这些情况中，你会收到一条提示消息，但还是建议使用这条命令确认策略已安装。

例20-11 检查Catalyst 3850上接口调用的policy-map:show policy-map interface brief

C3850# show policy-map interface brief

Service-policy output:def-11gn

Radio dot11b iifid:0x0100B9C00000003B.0x00E2F44000000006

...

Service-policy input:POLICING

GigabitEthernet1/0/10

例20-11显示出策略都关联到了哪些接口上。在排查QoS的问题前，以及在确认策略是否已被调用时，可以使用这条命令，它可以显示出哪个策略关联在了多个端口上。

例20-12 检查Catalyst 3850上的policy-map配置:show policy-map interface

C3850# show policy-map interface gi 1/0/10

GigabitEthernet1/0/10

Service-policy input:POLICING

Class-map:VVLAN-VOIP (match-any)

Match:ip dscp ef (46)

QoS Set

dscp ef

police:

cir 128000 bps, bc 4000 bytes

conformed 0 bytes; actions:

transmit

exceeded 0 bytes; actions:

drop

conformed 0000 bps, exceed 0000 bps

Class-map:VVLAN-SIGNALING (match-any)

Match:ip dscp cs3 (24)

QoS Set

dscp cs3

police:

cir 32000 bps, bc 1500 bytes

conformed 0 bytes; actions:

transmit

exceeded 0 bytes; actions:

drop

conformed 0000 bps, exceed 0000 bps

例20-12显示出接口G1/0/10调用的QoS策略，但要注意这里没有显示出分类计数。Catalyst 3850 只在入方向上提供限速的统计信息。还要注意show policy-map interface 命令下用于wireless和ssid的关键字。通过MAC地址或SSID，使用这些关键字可以显示某个无线客户端调用的策略。

20.3.3 队列模型

由于融合接入的本质，用于有线端口和无线端口的队列模型是相互分开的。无线端口是指Catlayst 3850 上连接Cisco AP 的交换机端口，这种端口提供4 条独立的队列。为了更好地使用这些队列，Catalyst 3850 内部的无线控制模块如果确定一个端口是无线端口的话，这个端口就会使用4队列模型来传输流量。反之，有线端口提供8条队列，这与其他园区网交换机使用的队列模型相匹配，因此可以轻松地适应QoS策略。本章后续将分别介绍这两类队列模型。

入向队列是在内部堆叠接口上提供的，但在本书写作时还无法配置入向队列，并且看起来也没有必要配置。平台的基础架构为每个ASIC到12Gbit/s堆栈连接提供24个1Gbit/s接入端口和2个10Gbit/s上行链路端口。这个架构在堆栈环网上提供两条内部队列，分别用来传输优先级流量和非优先级流量。

1.有线队列

有线队列模型使用的是8队列架构，其中可以将两条队列配置为严格优先级队列。优先级队列的配置是可选的，但使用单/双优先级队列模型是有好处的。如果每个设备的队列模型必须相互匹配，Catalyst 4500 和Catalyst 6500 都使用1P7Q 模型，可以轻松地与Catalyst 3850 的1P7Q3T模型相匹配。但这个模型并不会把语音和视频优先级流量分开。2P6Q3T模型会将语音和视频优先级流量分开，但这种策略与Catalyst 4500 的兼容性不是很好。

为有线流量定义的优先级队列与前文介绍的无线队列一样。提供了2条队列:priority level 1优先于prioritylevel2。也就是说虽然两条队列都是低延迟队列，但level 1也总是优先于level2的。

可以在出方向上配置分层的整形特性，来限制链路上的全部带宽，同时提供流量管理粒度。在物理端口使用整形特性时，整形流量占用的带宽不会超过管理员分配的带宽，即使链路空闲时也是如此。整形特性在传输过程中会提供更为平缓的流量，并减缓突发流量的波峰值和波谷值。在配置整形特性时，可以使用精确的数值或加权百分比，来计算每条队列的可用带宽。使用命令shape average 或命令shape average percent 来配置整形特性。

说到Catalyst 3850 上的调度机制，优先级队列会优先于其他有线队列得到服务，之后由CBWFQ来执行调度。为每个类配置的加权百分比表示最小的带宽保证，流量可以超出这个配置的速率，这在一定程度上有效利用了可用带宽。这些队列是通过最小带宽保证进行调度的，并且可以在带宽可用时超出这一速率。

Catalyst 3850 也支持WTD（加权尾部丢弃）拥塞避免机制。WTD 是实施在队列上的队列长度管理工具，为每个流量类别设置了一个丢弃优先级。当数据包排入了一条出向队列中， WTD会利用数据帧的DSCP值为其设置不同的丢弃门限值。如果超出了某个DSCP值的丢弃门限值（也就是说，目的地队列中的可用空间小于数据包的长度），交换机就会丢弃数据包。每条队列有三个门限值，Catalyst 3850 使用标准的MQC 分类特性，将数据包映射到队列并应用门限值。可以使用的分类参数包括（但不局限于）:DSCP、CoS、access-group和QoS组。根据这个分类，数据包会被发送到正确的队列，并由正确的门限值进行处理。

一般来说，在针对每个平台的设计章节中，会分别展示第11章中介绍的4类、8类和12类战略端到端QoS 模型。但由于Catalyst 3850 分别提供有线和无线队列模型，这些模型都是12类模型，并且可选地在有线侧使用单/双优先级队列。

2.有线1P7Q3T出向队列模型

Catalyst 3850 家族交换机上的出向优先队列可以配置为8Q3T、1P7Q3T 或2P6Q3T，后两个是推荐的配置（因为能够支持RFC 3246 EF PHB）。

Catalyst 3850 上的出向队列、分类、标记和其他功能都是通过MQC 进行部署的。这与使用MLS 的Catalyst 3750 有很大不同，但这两个交换机之间还是有些类似的。

与Catalyst 3750 一样，Catalyst 3850 能够为硬件队列灵活分配缓存（也称为DTS[ 动态阈值和范围]），即动态地（按需）借出或借入。但在两台设备上部署这个额外缓存空间的方法却完全不同。第一个区别是:硬件的缓存分配只能提供给有线和无线队列中的优先级队列。其他队列按需分配缓存，这种方式可以使拥有多条队列的系统具有更多的灵活性。每条队列（每个类）可以根据queue-buffers ratio 命令的配置，使用共享缓存池中的额外缓存空间。这条命令设置了这个类接收的缓存比例，并且缓存是按需分配的。一般来说，一个类的最大速率是配置值的4 倍。queue-buffers ratio 命令根据分配给队列的全部缓存百分比来修改这些值。默认对于有线端口来说，这个比例是1:1:1……，对于无线端口来说，这个比例是10:20:50:20。推荐为有线接口分配的缓存比例是:从队列7到队列1分别为10%、10%、10%、10%、10%、10% 和25%，推荐为无线端口使用默认比例。与Catalyst 3750 不同的是，Catalyst 3850 并没有提供预留的门限值，并且最大（超载）门限值是由非优先级队列的队列缓存比例设定的。

在1P7Q3T出向队列中设定了优先级队列后，可以为Q2到Q6设置WTD门限值，来提供队列内的QoS。具体说来，可以为Q2T1明确设置80%队列深度，为Q2T2明确设置90%队列深度，为Q2T3明确设置100%队列深度。上述案例是根据AF编号机制设置的门限值。AFx1拥有最低的丢弃可能性，AFx3拥有最高的丢弃可能性。此外还可以使用命令queue-buffers ratio来配置共享缓存。这个设置允许多数队列使用平台上的扩展缓存空间。在设置大数据类和清道夫类使用扩展缓存时要格外留心。因为这样一来，这些缓存将被用到最不希望占用缓存的流量上，并且可能还会被占用一段时间。

图20-5 展示了1P7Q3T 出向队列与Catalyst 3850 上8 队列模型的映射。

图20-5 Catalyst 3850 8队列（1P7Q3T）出向队列模型

例20-13 展示了在Catalyst 3850 上配置8 类1P7Q3T 出向队列的相关配置。

例20-13 Catalyst 3850 8类（1P7Q3T）出向队列配置案例

! This section configures buffers, thresholds, and a single priority

! queue

C3850(config-pmap-c)# policy-map 1P7Q3T

C3850(config-pmap)# class REALTIME-QUEUE

C3850(config-pmap-c)# priority level 1

C3850(config-pmap-c)# police rate percent 10

! REALTIME is enabled as a strict priority queue and policed to drop at

! 10 percent of physical rate

C3850(config-pmap-c-police)# class CONTROL-QUEUE

C3850(config-pmap-c)# bandwidth remaining percent 5

C3850(config-pmap-c)# queue-buffers ratio 10

! CONTROL is allocated 5 percent of bandwidth not allocated to the

! priority queue and allowed to consume 10% of additional buffers from

! global buffer pool

C3850(config-pmap)# class SIGNALING-QUEUE

C3850(config-pmap-c)# bandwidth remaining percent 2

! SIGNALING is allocated 2 percent of bandwidth not allocated to the

! priority queue

C3850(config-pmap-c)# class INTERACTIVE-VIDEO-QUEUE

C3850(config-pmap-c)# bandwidth remaining percent 23

C3850(config-pmap-c)# queue-buffers ratio 10

C3850(config-pmap-c)# queue-limit dscp af43 percent 80

C3850(config-pmap-c)# queue-limit dscp af42 percent 90

C3850(config-pmap-c)# queue-limit dscp af41 percent 100

! INTERACTIVE is allocated 23 percent of bandwidth not allocated to the

! priority queue, allowed to consume 10% of additional buffers from

! global buffer pool, and provided Tail Drop thresholds for 3 AF

! classes at rates 80,90,100

C3850(config-pmap-c)# class STREAMING-VIDEO-QUEUE

C3850(config-pmap-c)# bandwidth remaining percent 10

C3850(config-pmap-c)# queue-buffers ratio 10

C3850(config-pmap-c)# queue-limit dscp af33 percent 80

C3850(config-pmap-c)# queue-limit dscp af32 percent 90

C3850(config-pmap-c)# queue-limit dscp af31 percent 100

! STREAMING is allotted 10 percent of the bandwidth and

! allowed to consume 10 percent of additional buffers from the

! global buffer pool, and provided Tail Drop thresholds for 3 AF

! classes at rates 80,90,100

C3850(config-pmap-c)# class TRANSACTIONAL-DATA-QUEUE

C3850(config-pmap-c)# bandwidth remaining percent 24

C3850(config-pmap-c)# queue-buffers ratio 10

C3850(config-pmap-c)# queue-limit dscp af23 percent 80

C3850(config-pmap-c)# queue-limit dscp af22 percent 90

C3850(config-pmap-c)# queue-limit dscp af21 percent 100

! TRANSACTIONAL is allotted 24 percent of the bandwidth and

! allowed to consume 10 percent of additional buffers from the

! global buffer pool, and provided tail drop thresholds for three AF

! classes at rates 80,90,100

C3850(config-pmap-c)# class SCAVENGER-QUEUE

C3850(config-pmap-c)# bandwidth remaining percent 1

C3850(config-pmap-c)# queue-buffers ratio 10

! SCAVENGER is allotted 1 percent of the bandwidth and

! allowed to consume 10 percent of additional buffers from the

! global buffer pool

C3850(config-pmap-c)# class class-default

C3850(config-pmap-c)# bandwidth remaining percent 25

C3850(config-pmap-c)# queue-buffers ratio 25

! class-default is allotted 25 percent of the bandwidth and

! allowed to consume 25 percent of additional buffers from the

! global buffer pool

! This section configures interface egress queuing parameters

C3850(config)# interface gigabitethernet 1/0/13

C3850(config-if)# service-policy out 1P7Q3T

使用下列命令来检查例20-13中的配置（本例的命令输出信息将在后文中给出）。

■ show platform qos hw_state target gigabit x/y

■ show platform qos policy target gigabit x/y

■ show policy-map interface

■ show platform qos queue stats

■ show platform dscp-cos counters

■ show policy-map interface wireless

■ show platform qos queue config

3.有线2Q6Q3T出向队列模型

2P6Q3T出向队列模型与1P7Q3T出向队列模型的区别很小，跟扩展为12类模型差不多。多出的另一条优先级队列可以把语音和视频流量分开，仍然提供大部分AF类。在12类模型中使用这个队列战略时，唯一缺失的是单独的清道夫类队列，这个类别与大数据类一起属于最低门限值1QT3，使用AF13。

图20-6 展示了Catalyst 3850 中的2P6Q3T 出向队列映射。

例20-14 展示了Catalyst 3850 中12 类2P6Q3T 出向队列的相关配置。

图20-6 Catalyst 3850 12类（2P6Q3T）出向队列模型

例20-14 Catalyst 3850 12类（2P6Q3T）出向队列配置

! This section configures buffers, thresholds and a single PQ

C3850(config-cmap)# policy-map 2P6Q3T

C3850(config-pmap)# class PRIORITY-QUEUE

C3850(config-pmap-c)# priority level 1

C3850(config-pmap-c)# police rate percent 10

! PRIORITY is set to level 1 and serviced before any other class

! It is policed to 10 percent of the physical interface rate

C3850(config-pmap-c-police)# class REAL-TIME-VIDEO-QUEUE

C3850(config-pmap-c)# priority level 2

C3850(config-pmap-c)# police rate percent 20

! REAL-TIME is set to priority level 2 and serviced before any other

! class, it is policed to 20 percent of the physical interface rate

C3850(config-pmap-c-police)# class CONTROL-MGMT-QUEUE

C3850(config-pmap-c)# bandwidth remaining percent 10

C3850(config-pmap-c)# queue-buffers ratio 10

! CONTROL is allotted 10 percent of the bandwidth and

! allowed to consume 10 percent of additional buffers from the

! global buffer pool

C3850(config-pmap-c)# class MULTIMEDIA-CONFERENCING-QUEUE

C3850(config-pmap-c)# bandwidth remaining percent 10

C3850(config-pmap-c)# queue-buffers ratio 10

C3850(config-pmap-c)# queue-limit dscp af43 percent 80

C3850(config-pmap-c)# queue-limit dscp af42 percent 90

C3850(config-pmap-c)# queue-limit dscp af41 percent 100

! MULTIMEDIA is allotted 10 percent of the bandwidth,

! allowed to consume 10 percent of additional buffers from the

! global buffer pool and provided tail drop thresholds for three AF

! classes at rates 80,90,100

C3850(config-pmap-c)# class MULTIMEDIA-STREAMING-QUEUE

C3850(config-pmap-c)# bandwidth remaining percent 10

C3850(config-pmap-c)# queue-buffers ratio 10

C3850(config-pmap-c)# queue-limit dscp af33 percent 80

C3850(config-pmap-c)# queue-limit dscp af32 percent 90

C3850(config-pmap-c)# queue-limit dscp af31 percent 100

! TRANSACTIONAL is allotted 10 percent of the bandwidth,

! allowed to consume 10 percent of additional buffers from the

! global buffer pool, and provided tail drop thresholds for three AF

! classes at rates 80,90,100

C3850(config-pmap-c)# class TRANSACTIONAL-DATA-QUEUE

C3850(config-pmap-c)# bandwidth remaining percent 10

C3850(config-pmap-c)# queue-buffers ratio 10

C3850(config-pmap-c)# queue-limit dscp af23 percent 80

C3850(config-pmap-c)# queue-limit dscp af22 percent 90

C3850(config-pmap-c)# queue-limit dscp af21 percent 100

! TRANSACTIONAL is allotted 10 percent of the bandwidth,

! allowed to consume 10 percent of additional buffers from the

! global buffer pool, and provided tail drop thresholds for three AF

! classes at rates 80,90,100

C3850(config-pmap-c)# class BULK-SCAVENGER-DATA-QUEUE

C3850(config-pmap-c)# bandwidth remaining percent 5

C3850(config-pmap-c)# queue-buffers ratio 10

C3850(config-pmap-c)# queue-limit dscp values af13 cs1 percent 80

C3850(config-pmap-c)# queue-limit dscp values af12 percent 90

C3850(config-pmap-c)# queue-limit dscp values af11 percent 100

! TRANSACTIONAL is allotted 5 percent of the bandwidth and

! allowed to consume 10 percent of additional buffers from the

! global buffer pool, and provided tail drop thresholds for three AF

! classes at rates 80,90,100

C3850(config-pmap-c)# class class-default

C3850(config-pmap-c)# bandwidth remaining percent 25

C3850(config-pmap-c)# queue-buffers ratio 25

! class-default is allotted 25 percent of the bandwidth and

! allowed to consume 25 percent of additional buffers from the

! global buffer pool

! This section configures interface egress queuing parameters

C3850(config)# int gi 1/0/13

C3850(config-if)# service-policy out 2P6Q3T

注释:前文案例中的队列缓存比例都设置得非常宽松，需要根据流量的内容以及特定网络中期望的延迟进行调整。案例中并没有为大块数据-清道夫队列分配太多缓存，它可能会请求额外的缓存，因为为其分配的带宽量也很低。

使用以下命令来检查例20-14中的配置。

■ show platform qos hw_state target gigabit x/y（详见例20-15）

■ show platform qos policy target gigabit x/y（详见例20-16）

■ show policy-map interface（详见例20-17）

■ show platform qos queue stats（详见例20-18）

■ show platform dscp-cos counters（详见例20-19）

■ show policy-map interface wireless

■ show platform qos queue config（详见例20-20）

例20-15 检查Catalyst 3850上出向队列策略的应用:show platform qos hw_state target

C3850# show platform qos policy hw_state target gigabitethernet 1/0/2

Input policy:Not attached

Output policy:2P6Q3T

H/W programming State:INSTALLED IN HW

例20-15展示了与接口关联的策略描述。这个检查步骤在排查特定的配置警告时非常有用，如果策略关联到了接口上，但没有安装到硬件中，就会导致容量问题，或者导致策略本身不可用。

例20-16 检查Catalyst 3850上的出向队列:show platform qospolicy target gigabit x/y

C3850# show platform qos policy target gi 1/0/2

Input policy:

--------------

Not attached

Output policy:

--------------

POLICY:2P6Q3T Num Classes:8 Targets:1

PMAP:0x120724b8 NextPMAP:0x120998d0 PrevPMAP:(nil)

UP Mask:0, Lookup Type:216

COS Mask:0, dscp mask:72410903774319872

Filter flags:0x2, Action Flags:0x14, num_classmaps 8 policy_type:Invalid nfl_req_

pending_cnt:0 pmap_qsize:0

CLASS:PRIORITY-QUEUE

CMAP:0x4a54c88c Next:0x4a5447fc Prev:(nil)

Masks:- UP:0, CoS:0, Dscp:70368744177664

Filter flags 0x2

Match DSCP:46

Negate:NO Next:(nil)

CLASS:REAL-TIME-VIDEO-QUEUE

CMAP:0x4a5447fc Next:0x4a54a604 Prev:0x4a54c88c

Masks:- UP:0, CoS:0, Dscp:1103806595072

Filter flags 0x2

Match DSCP:32 40

Negate:NO Next:(nil)

CLASS:CONTROL-MGMT-QUEUE

CMAP:0x4a54a604 Next:0x4a544664 Prev:0x4a5447fc

Masks:- UP:0, CoS:0, Dscp:72339069031481344

Filter flags 0x2

Match DSCP:16 24 48 56

Negate:NO Next:(nil)

CLASS:MULTIMEDIA-CONFERENCING-QUEUE

CMAP:0x4a544664 Next:0x4a5453ac Prev:0x4a54a604

Masks:- UP:0, CoS:0, Dscp:360777252864

Filter flags 0x2

Match DSCP:34 36 38

Negate:NO Next:(nil)

CLASS:MULTIMEDIA-STREAMING-QUEUE

CMAP:0x4a5453ac Next:0x4a54aacc Prev:0x4a544664

Masks:- UP:0, CoS:0, Dscp:1409286144

Filter flags 0x2

Match DSCP:26 28 30

Negate:NO Next:(nil)

CLASS:TRANSACTIONAL-DATA-QUEUE

CMAP:0x4a54aacc Next:0x4a54ae84 Prev:0x4a5453ac

Masks:- UP:0, CoS:0, Dscp:5505024

Filter flags 0x2

Match DSCP:18 20 22

Negate:NO Next:(nil)

CLASS:BULK-SCAVENGER-DATA-QUEUE

CMAP:0x4a54ae84 Next:0x4a545874 Prev:0x4a54aacc

Masks:- UP:0, CoS:0, Dscp:21760

Filter flags 0x2

Match DSCP:8 10 12 14

Negate:NO Next:(nil)

CLASS:class-default

CMAP:0x4a545874 Next:(nil) Prev:0x4a54ae84

Masks:- UP:0, CoS:0, Dscp:0

Filter flags 0

Not Supported

Negate:NO Next:(nil)

Target:Gi1/0/2 DIR:OUT STATE:SET IN HW LE_LABEL:1, client_policy_type:LE

IF:0x01047d800000000a TCCGs:8 TCG:0x4a544dd4 Next:(nil) Prev:(nil)

CLASS:PRIORITY-QUEUE

Action flags:0x14

AG Policer Action Num:0

Rate:10000000 Peak:0

Limit:0 ExtLimit:0

BC:312500 Peak:0

Color Mode:Color Blind Type:1R2C

Queue Action

Buffer ratio:0 Limit Type:Queue Limit Single

CLASS:REAL-TIME-VIDEO-QUEUE

Action flags:0x14

AG Policer Action Num:1

Rate:20000000 Peak:0

Limit:0 ExtLimit:0

BC:625000 Peak:0

Color Mode:Color Blind Type:1R2C

Queue Action

Buffer ratio:0 Limit Type:Queue Limit Single

CLASS:CONTROL-MGMT-QUEUE

Action flags:0x10

Queue Action

Buffer ratio:10 Limit Type:Queue Limit Single

CLASS:MULTIMEDIA-CONFERENCING-QUEUE

Action flags:0x10

Queue Action

Buffer ratio:10 Limit Type:Queue Limit DSCP

CLASS:MULTIMEDIA-STREAMING-QUEUE

Action flags:0x10

Queue Action

Buffer ratio:10 Limit Type:Queue Limit DSCP

CLASS:TRANSACTIONAL-DATA-QUEUE

Action flags:0x10

Queue Action

Buffer ratio:10 Limit Type:Queue Limit DSCP

CLASS:BULK-SCAVENGER-DATA-QUEUE

Action flags:0x10

Queue Action

Buffer ratio:10 Limit Type:Queue Limit DSCP

CLASS:class-default

Action flags:0x10

Queue Action

Buffer ratio:25 Limit Type:Queue Limit Single

Hardware States ****************

MAC LE Label:1

IPV4 LE Label:1

Priority:13

Translation Index:0

Trust:TRUST_DSCP

STATS ARE IN BYTE_COUNT FORMAT...

PORT 20 RT1 Policer Accept Stats 0

PORT 20 RT2 Policer Accept Stats 0

PORT 20 RT1 Policer Drop Stats 0

PORT 20 RT2 Policer Drop Stats 0

Additional details for policy:2P6Q3T

Number of targets attached to:1

Number of targets policy successfully programmed in HW:1

例20-16显示出策略关联到接口后，硬件中的安装细节。输出信息中显示了策略所关联的接口数量和类数量，以及有多少已成功编程在系统的硬件中。这条命令与命令show policy-map interface类似，但它提供了有关接口实际编程的更多信息。

例20-17 检查Catalyst 3850上的出向队列:show policy-map interface

C3850# show policy-map int gi 1/0/25

GigabitEthernet1/0/25

Service-policy output:1P7Q3T

queue stats for all priority classes:

Queueing

priority level 1

(total drops) 0

(bytes output) 9243213

Class-map:PRIORITY-QUEUE (match-any)

Match:dscp ef (46)

Priority:Strict,

Priority Level:1

police:

rate 30 %

rate 300000000 bps, burst 9375000 bytes

conformed 8892522 bytes; actions:

transmit

exceeded 0 bytes; actions:

drop

conformed 86000 bps, exceeded 0 bps

Class-map:CONTROL-MGMT-QUEUE (match-any)

Match:dscp cs2 (16) cs3 (24) cs6 (48) cs7 (56)

Queueing

(total drops) 0

(bytes output) 11333

bandwidth remaining 10%

queue-buffers ratio 10

Class-map:MULTIMEDIA-CONFERENCING-QUEUE (match-any)

Match:dscp af41 (34) af42 (36) af43 (38)

Queueing

queue-limit dscp 34 percent 100

queue-limit dscp 36 percent 90

queue-limit dscp 38 percent 80

(total drops) 0

(bytes output) 0

bandwidth remaining 10%

queue-buffers ratio 10

Class-map:MULTIMEDIA-STREAMING-QUEUE (match-any)

Match:dscp af31 (26) af32 (28) af33 (30)

Queueing

queue-limit dscp 26 percent 100

queue-limit dscp 28 percent 90

queue-limit dscp 30 percent 80

(total drops) 0

(bytes output) 0

bandwidth remaining 10%

queue-buffers ratio 10

Class-map:TRANSACTIONAL-DATA-QUEUE (match-any)

Match:dscp af21 (18) af22 (20) af23 (22)

Queueing

queue-limit dscp 18 percent 100

queue-limit dscp 20 percent 90

queue-limit dscp 22 percent 80

(total drops) 0

(bytes output) 46844266

bandwidth remaining 10%

queue-buffers ratio 10

Class-map:BULK-DATA-QUEUE (match-any)

Match:dscp af11 (10) af12 (12) af13 (14)

Queueing

queue-limit dscp 10 percent 100

queue-limit dscp 12 percent 90

queue-limit dscp 14 percent 80

(total drops) 0

(bytes output) 0

bandwidth remaining 4%

queue-buffers ratio 10

Class-map:SCAVENGER-QUEUE (match-any)

Match:dscp cs1 (8)

Queueing

(total drops) 0

(bytes output) 0

bandwidth remaining 1%

queue-buffers ratio 10

Class-map:class-default (match-any)

Match:any

Queueing

(total drops) 0

(bytes output) 64193461

bandwidth remaining 25%

queue-buffers ratio 25

例20-18 检查Catalyst 3850上的出向队列:show platform qos queue stats

C3850# show platform qos queue stats gi 1/0/25

DATA Port:21 Enqueue Counters

-------------------------------

Queue Buffers Enqueue-TH0 Enqueue-TH1 Enqueue-TH2

----- ------- ----------- ----------- -----------

0　　0　　　0　　　0　8452618

1　　0　　　0　　　0　　11333

2　　0　　　0　　　0　　　0

3　　0　　　0　　　0　　　0

4　　0　　　45844266　0　　　0

5　　0　　　0　　　0　　　0

6　　0　　　0　　　0　　　0

7　　0　　　0　　　0　64193115

DATA Port:21 Drop Counters

-------------------------------

Queue Drop-TH0　Drop-TH1　Drop-TH2　SBufDrop　QebDrop

----- ----------- ----------- ----------- ----------- -----------

0　　　0　　　0　　　0　　　0　　　0

1　　　0　　　0　　　0　　　0　　　0

2　　　0　　　0　　　0　　　0　　　0

3　　　0　　　0　　　0　　　0　　　0

4　　　0　　　0　　　0　　　0　　　0

5　　　0　　　0　　　0　　　0　　　0

6　　　0　　　0　　　0　　　0　　　0

7　　　0　　　0　　　0　　　0　　　0

AQM Broadcast Early WTD COUNTERS(In terms of Bytes)

--------------------------------------------------

PORT TYPE　　　ENQUEUE　　　DROP

--------------------------------------------------

UPLINK PORT-0　　N/A　　　　0

UPLINK PORT-1　　N/A　　　　0

UPLINK PORT-2　　N/A　　　　0

UPLINK PORT-3　　N/A　　　　0

NETWORK PORTS　　　0　　　　0

RCP PORTS　　　　0　　　　0

CPU PORT　　　　0　　　　0

! Note:Queuing stats are in bytes

可以把例20-17和例20-18中的命令结合使用，用来查看流量到队列的映射和门限值。从例20-17 中可以看出，CONTROL-MGMT-QUEUE 有11 333 个数据包。从例20-18 中可以看出，相同数量的数据包排在了（Q1T2）队尾。另一个接入端口收到的流量也被标记为AF23，见Q4T0或TRANSACTIONAL-QUEUE。

例20-19 检查Catalyst 3850上的出向队列:show platform qosdscp-cos counters

C3850# show platform qos dscp-cos counters gigabitethernet 1/0/25

Ingress DSCP0 504638　　0

Ingress DSCP1 0　　　0

Ingress DSCP2 0　　　0

Ingress DSCP3 0　　　0

Ingress DSCP4 0　　　0

Ingress DSCP5 0　　　0

Ingress DSCP6 0　　　0

Ingress DSCP7 0　　　0

Ingress DSCP8 0　　　0

Ingress DSCP9 0　　　0

Ingress DSCP10 0　　　0

Ingress DSCP11 0　　　0

Ingress DSCP12 0　　　0

Ingress DSCP13 0　　　0

...

例20-19展示了流量的入向/出向QoS值。这个命令可以帮助你了解一个接口可能会收到的QoS值。

例20-20 检查Catalyst 3850上的出向队列:show platform qos queue config

C3850# show platform qos queue config gi 1/0/12

DATA Port:6 GPN:12 AFD:Disabled QoSMap:1 HW Queues:48 - 55

DrainFast:Disabled PortSoftStart:1 - 600

----------------------------------------------------------

DTS Hardmax　Softmax　PortSMin GlblSMin　PortStEnd

--- --------　-------- -------- --------- ---------

0　1　6　30 11　120　0　80　0　0　0　800

1　1　4　0 10　360　5　240　5　90　5　800

2　1　4　0 11　120　6　80　6　30　6　800

3　1　4　0 11　120　6　80　6　30　6　800

4　1　4　0 11　120　6　80　6　30　6　800

5　1　4　0 11　120　6　80　6　30　6　800

6　1　4　0 11　120　6　80　6　30　6　800

7　1　4　0 11　120　6　80　6　30　6　800

Priority　Shaped/shared　weight　shaping_step

--------　------------　------　------------

0　　1　Shared　　　50　　　0

1　　7　Shared　　　50　　　0

2　　7　Shared　　　100　　　0

3　　7　Shared　　　100　　　0

4　　7　Shared　　　100　　　0

5　　7　Shared　　　100　　　0

6　　7　Shared　　　50　　　0

7　　7　Shared　　　100　　　0

Weight0 Max_Th0 Min_Th0 Weigth1 Max_Th1 Min_Th1 Weight2 Max_Th2 Min_Th2

------- -------　------　------　------　------　------　------ ------

0　0　119　　0　　0　133　　0　　0　150　　0

1　0　286　　0　　0　320　　0　　0　360　　0

2　0　　95　　0　　0　106　　0　　0　120　　0

3　0　　95　　0　　0　106　　0　　0　120　　0

4　0　　95　　0　　0　106　　0　　0　120　　0

5　0　　95　　0　　0　106　　0　　0　120　　0

6　0　　95　　0　　0　106　　0　　0　120　　0

7　0　　95　　0　　0　106　　0　　0　120　　0

例20-20展示了基于端口的缓存配置。案例给出了单一优先级队列（Q0），硬件缓存设置为30，第1条CBWFQ队列设置为queue-buffers ratio 30，为这个类分配最多360的软件缓存。因为不能为非优先级队列分配硬件缓存，因此这些值来自于公用池。

4.无线队列

无线队列模型使用的是四队列架构，其中包含两条严格优先级队列。这两条优先级队列分别用于语音和视频，并限速为特定的速率。其他队列定义为class-default“包罗万象的”队列，和静态定义的non-client-nrt-class队列。non-client-nrt-class队列专门用于未匹配实时或优先级队列的组播流量。尽管被标记为CS5（属于优先级队列）的组播流量将会去往优先级队列，但若组播流量没有标记为实时流量，它就会去往non-client-nrt-class队列。

无线端口的调度机制如图20-7所示，是由CBWFQ完成的，但4条队列中只有2条使用CBWFQ，因为另2条使用严格优先级调度机制。

图20-7 Catalyst 3850出向无线队列模型（2P2Q）

严格优先级队列会优先于所有其他队列获得服务，严格优先级队列传输完成后，其他队列才会获得服务。当配置了多条优先级队列时，两条队列区分为级别1和级别2，优先级队列之间的调度机制是严格的。举例来说，第1条优先级队列传输完成后，调度程序会去服务第2条优先级队列，然后再按照CBWFQ 的原则服务非优先级队列。可以使用接口命令priority level x来启用严格优先级队列，还可以部署限速器来限制流量。

注释:优先级队列这个级别使用的限速器只对组播实时流量起作用。若组播数据包被标记为具有优先级的DSCP值（也就是EF、CS5），则数据包会被放入一条优先级队列中。如果组播数据包没有被标记为这样一个DSCP值，它会被放入non-client-nrt-class中，最终进入专门的组播non-real-time队列中。

AFD（近似公平丢弃）是一种带宽控制算法，用来控制多个类之间的带宽分配，这些类共享无线接口的class-default队列。AFD通过在射频、SSID和客户端级别计算虚拟队列长度，来为客户端提供公平的机制。当客户端消耗的带宽超出了公平的共享带宽量，这个虚拟队列长度会触发客户端级别的丢弃可能性。这种算法类似于每用户的限速器功能。AFD和限速器都会在数据包到达后丢弃数据包，但限速器的丢包行为是确切的，而AFD的丢弃行为是根据可能性进行的，并且使用变量来计算公平的结果。因此AFD的丢包行为对于TCP来说更为友好， TCP的滑动窗口可以协助AFD进行带宽控制。

图20-8描绘了AFD的工作原理。分配给默认类（数据队列）的带宽量，是队列参照计算的基础，通过计算结果为多个客户端提供公平的环境。使用射频带宽量、SSID数量、客户端数量，动态地计算出客户端级别的公平共享情况。一旦认定客户端达到了参照门限值，就会使用丢弃可能性计算来强制该客户端的数据流丢包。

图20-8 Cisco Catalyst 3850 AFD

从图20-8 中可以推导出一个简单的案例。在射频级别，如果有120 Mbit/s 带宽可用，配置了2 个SSID，每个SSID 分配60 Mbit/s 带宽，为客户端提供更公平的带宽共享。如果在SSID级别应用一个策略，改变了为SSID分配的带宽剩余比例，那么参照值的计算就会基于SSID级别的配置进行。假设没有为SSID 应用任何策略，那么60 Mbit/s 的带宽就会根据客户端的数量进行分配。会根据可用带宽来为每个客户端分配公平带宽，还要考虑客户端发送优先级流量到物理端口的情况。优先级队列会绕过AFD区域，但在SSID级别的计算中还是要考虑优先级队列。在从SSID级别减去优先级队列分配的带宽后，剩余的可用带宽会在每个客户端之间平分。

5.无线2P2Q出向队列模型

Catalyst 3850 家族交换机上的出向无线队列可以配置为2P2Q。

无线侧的缓存与有线侧相同。区别在于默认比例和队列的数量限制，详见前文内容。不建议修改无线侧的缓存，因为队列数量和默认值都是按照最佳做法调整的。

通过使用2P2Q出向队列的默认队列参数，需要处理一下组播NRT和class-default队列之间的带宽分配问题。具体说来，首先无线端口级别的限速器会将组播流量放到优先级队列中。根据“33% LLQ 的原则”，优先级级别1 是语音类，限制为10%；优先级级别2 是视频类，限制为20%；这时，物理限速器只会限制组播流量，不会限制单播流量。因此为了限制单播流量，必须在SSID的下游方向应用一个策略。因为这并不是队列策略的一部分，因此不再赘述。

接着根据剩余的70%可用带宽，为剩下的2个类（non-client-nrt-class和class-default）分配带宽。class-default可以获得最大的一部分63%，non-client-nrt-class则获得剩余的7%。这种分配既在拥塞时限制了NRT组播流量，又为默认类中的其他应用提供了带宽。这个队列模型中不能使用门限值，因为每个客户端之间的公平性是由AFD提供的。在class-default中，每个遵从AFD的无线客户端都根据AFD计算出的可能性来丢包，这样可以建立每客户端的公平环境，上一节在介绍AFD的部分详细阐述了这一情况。

图20-9 展示了Catalyst 3850 无线端口的2P2Q 出向队列映射。

例20-21 展示了Catalyst 3850 8 类2P2Q 无线出向队列的相关配置。

图20-9 Catalyst 3850 8类（2P2Q）无线出向队列模型

例20-21 Catalyst 3850 8类（2P2Q）无线出向队列配置案例

! This section configures egress wireless queuing and a dual PQ

C3850(config)# policy-map port_child_policy

C3850(config-pmap)# class non-client-nrt-class

C3850(config-pmap-c)# bandwidth remaining ratio 7

! non-client-nrt-class is a static class for multicast non-real-time

! traffic allocated 7 percent of bandwidth not allocated to the

! priority queue

C3850(config-pmap-c)# class RT1

C3850(config-pmap-c)# priority level 1

C3850(config-pmap-c) police rate percent 10 conform-action transmit　exceedaction drop

! RT1 is set to level 1 and serviced before any other class

! Multicast traffic in this queue is policed to 10 percent of the

! physical interface rate

C3850(config-pmap-c-police)# class RT2

C3850(config-pmap-c)# priority level 2

C3850(config-pmap-c) police rate percent 20 conform-action transmit exceed-action

drop

! RT2 is set to level 2 and serviced before any other class

! Multicast traffic in this queue is policed to 20 percent of the

! physical interface rate

C3850(config-pmap-c-police)# class class-default

C3850(config-pmap-c)# bandwidth remaining ratio 63

! This section configures wireless interface egress queuing parameters

C3850(config)# This policy is applied automatically by the WCM to all wireless ports

– no policy attachment necessary

注释:WCM会根据无线端口协商的结果，自动应用出向无线队列配置。当它认定一个端口是无线端口，就会应用静态的policy map:port_child_policy，以及射频级别的整形器。如果没有在无线端口级别打开优先级级别，就不能将其用于SSID级别或客户端级别的策略中。

使用以下命令来检查例20-21中的配置。

■ show platform qos hw_state target gigabit x/y

■ show platform qos policy target gigabit x/y

■ show policy-map interface

■ show policy-map interface wireless

20.4 小结

本章详细介绍了使用Cisco Catalyst 3850 系列交换机作为园区网接入层交换机，并同时支持有线和无线网络连接时的最佳做法建议。这些设计中的绝大部分都可以与Catalyst 4500 Sup6/7交换机家族作为接入层的设计进行比较。

在这个平台上部署QoS的第一步是在全局启用信任特性（如果可以应用的话）。如果没有执行这简单但重要的一步，则所有配置的QoS标记都会变得无效。一旦禁用了untrusted命令，就无需在SSID级别应用信任策略了。

本章接着讨论了如何定义入向QoS策略，其中可能包括条件信任（用于Cisco设备）、分类和标记（还有可选的限速策略）。

之后详细介绍了有线和无线类型端口的出向队列策略，8类和12类战略模型都可以应用在这个平台上；还详细介绍了有线和无线队列模型的区别。

下一章将继续介绍与平台相关的设计选项和考量因素，其中包括如何配置每SSID和每客户端QoS。

20.5 扩展阅读

Cisco企业媒体网园区QoS设计4.0:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSCampus_40.html

媒体网园区QoS设计一览:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/qoscampusaag.html

媒体网Catalyst 3560/3750 QoS设计一览:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/qoscampuscat3xxxaag.html

媒体网园区AutoQoS一览:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/autoqosmediacampus.pdf

Cisco Catalyst 3750和Catalyst 3650-X交换机软件配置指南，Cisco IOS 15.0(2)SE:QoS配置指南:http://www.cisco.com/en/US/docs/switches/lan/catalyst3750x_3560x/software/release/15.0_2_se/configuration/guide/swqos.html

第21章 融合接入QoS设计的案例研究

第12章已经定义了Tifosi Software 的战略8 类端到端QoS 模型（详见图12-2），网络部门现在要在特定的平台上将这些策略应用到他们的融合接入园区网基础设施中。

Tifosi拥有一个多层园区网络，详见第17章的定义。除了这个设计之外，还通过Cisco Catalyst 3850 接入交换机和CT5760 WLC（无线局域网控制器）提供有线和无线融合。

Tifosi网络中有多种终端设备连接到园区网的接入层，其中包括:

■ 桌面PC和Mac，还有UNIX/Linux工作站（也简称为PC）；

■ Cisco IP 电话；

■ Cisco无线接入点；

■ Cisco TelePresence 系统；

■ 打印机；

■ 移动无线设备。

网络团队希望确保所有终端设备都有各自的信任状态，或者对其明确应用分类和标记策略。他们还希望以最少的策略配置变更，将这些策略扩展到移动无线客户端。

Tifosi园区网中使用2个主要的SSID，分别用于访客和企业。网络团队经常注意到访客SSID中有庞大的数据流量，这影响了企业SSID中内部用户的网络使用。因此他们想要缓解这个问题，将可用带宽的70%分配给企业用户，将可用带宽的30%分配给访客用户。同时，网络团队还想要确保一个SSID中的每个用户公平地享用带宽资源，并且对每个用户实施双方向的1 Mbit/s 限制。

无线用户的认证是通过Cisco的ISE（身份服务引擎）实现的。作为这个平台的一部分，用户证书可以在用户授权进入网络后，修改为用户提供的QoS策略。根据这些证书，ISE会将相应QoS 策略的名称信息发送给Catalyst 3850，这就提供了基于用户的QoS。

最后，网络团队想要确保在所有有线和上行链路端口都应用8类出向队列策略，并将其映射到AP的4队列模型中。

图21-1 展示了Tifosi 接入网络中应用的QoS 策略。Catalyst 3850 为无线设备提供逻辑策略。

图21-1 Tifosi Software案例研究:园区网络QoS设计

这些园区网QoS策略如下所示。

有线策略

■ 策略1:不信任的有线终端设备（Catalyst 3850）

■ 将QoS数据包标记重设为0；

■ 为Tifosi 8 类QoS 模型启用1P7Q3T 出向队列。

■ 策略2:受信任的有线终端设备（Catalyst 3850）

■ 信任DSCP；

■ 为Tifosi 8 类QoS 模型启用1P7Q3T 出向队列。

■ 策略3:条件信任的有线终端设备:TelePresence（Catalyst 3850）

■ 为Cisco TelePresence 系统启用条件DSCP 信任；

■ 为Tifosi 8 类QoS 模型启用1P7Q3T 出向队列。

■ 策略4:条件信任的有线终端设备:IP 电话+ PC（Catalyst 3850）

■ 为Cisco IP 电话启用条件CoS 信任；

■ 将CoS 5 映射为DSCP EF；

■ 根据表21-1对流量进行分类和标记；

■ 为Tifosi 8 类QoS 模型启用1P7Q3T 出向队列。

■ 策略5:有线端口的队列（有线3850）

■ 信任DSCP；

■ 为Tifosi 8 类QoS 模型启用1P7Q3T 出向队列。

无线策略

■ 策略6:授权的无线终端设备——每客户端QoS（Catalyst 3850）

■ 启用DOT1X认证；

■ 根据表21-1对流量进行分类和标记；

■ 从RADIUS 向Catalyst 3850 推送授权客户端的QoS 策略名称；

■ 为Tifosi 8 类QoS 模型启用2P2Q 出向队列。

■ 策略7:无线端口的队列（无线3850）

■ 信任DSCP；

■ 为Tifosi 8 类QoS 模型启用2P2Q 出向队列。

■ 策略8:SSID之间的带宽区分

■ 信任DSCP（禁用untrusted命令后就不需要信任了）；

■ 在SSID级别修改带宽比例。

■ 策略9:CT 5760 WLC 上行链路端口

■ 信任DSCP（默认为有线到无线的流量启用信任）；

■ 为Tifosi 8 类QoS 模型启用1P7Q3T 出向队列。

注释:表21-1展示了Tifosi使用的基于TCP/UDP端口的分类示例。请参考与应用相关的文档来确认用于应用分类的TCP/UDP端口号。

表21-1 Tifosi的8类分类和标记策略表:用于Cisco IP电话+PC终端

续表

21.1 Tifosi融合接入QoS设计:有线

Tifosi 的接入层由有线的Cisco Catalyst 3750 和融合的Cisco Catalyst 3850 构成。下面列出的策略适用于Catalyst 3850 的有线端口，包含以下策略:

■ 对打印机等设备禁用信任特性；

■ 为安全的设备启用信任特性；

■ 为Cisco TelePresence 系统启用条件信任；

■ 为Cisco IP 电话+PC 启用条件信任；

■ 为Tifosi 8 类QoS 模型启用1P7Q3T 出向队列。

接下来按顺序介绍这些园区网接入策略。为了更好地区分有线配置和无线配置，第一部分先介绍有线客户端，然后再介绍无线客户端。记住，客户端策略对于有线和无线来说都是一样的，有区别的是队列技术。

21.1.1 策略1:有线打印机终端设备的接入边界设计（不信任）

例21-1展示了为连接不受信任终端设备的端口所使用的QoS策略。

例21-1 在Catalyst 3850上部署Tifosi不受信任终端设备的接入边界设计（以打印机为例）

C3850(config-cmap)# policy-map client-default

C3850(config-pmap-c)# class class-default

C3850(config-pmap-c)# set dscp default

C3850(config)# interface GigabitEthernet 1/0/46

C3850(config-if)# switchport access vlan 10

C3850(config-if)# service-policy in client-default

! Port is configured to be statically untrusted!

Queuing configurations detailed in Examples 21-6 and 21-7

21.1.2 策略2:有线接入终端设备的接入边界设计（信任DSCP）

例21-2展示了为连接信任DSCP的终端设备的接口所使用的QoS策略。

例21-2 Tifosi案例研究:在Catalyst 3850上部署受信任终端设备的接入边界设计（以安全的PC或IP会议工作站为例）

C3850(config)# interface GigabitEthernet 1/0/47

C3850(config-if)# switchport access vlan 10

C3850(config-if)# [NO ADDITIONAL CONFIGURATION NECESSARY]

! The Catalyst 3850 trusts DSCP by default without configuration

! Wired Queuing configurations detailed in Examples 21-5

21.1.3 策略3:Cisco TelePresence终端设备的接入边界设计（条件信任）

例21-3 展示了为连接CTS（Cisco TelePresence 系统）的接口所使用的QoS 策略。

例21-3 Tifosi案例研究:在Catalyst 3850上部署条件信任终端设备的接入边界设计（以Cisco TelePresence系统终端设备为例）

C3850(config)# interface GigabitEthernet 1/0/48

C3850(config-if)# switchport access vlan 10

C3850(config-if)# switchport voice vlan 110

C3850(config-if)# spanning-tree portfast

C3850(config-if)# trust device cts

! Port is configured to conditionally trust the CTS endpoint

! The Catalyst 3850 trusts DSCP by default without configuration

! Queuing configurations detailed in Examples 21-5

21.1.4 策略4:Cisco IP电话和PC的接入边界设计（条件信任、分类和标记）

例21-4 展示了为连接Cisco IP 电话+PC 的接口所使用的QoS 策略（参考表21-1）。

例21-4 Tifosi案例研究:在Catalyst 3850上部署条件信任终端设备的接入边界设计（以Cisco IP电话和PC为例）

! This section configures the classification extended ACLs

C3850(config)# ip access-list extended SIGNALING

C3850(config-ext-nacl)# remark SCCP

C3850(config-ext-nacl)# permit tcp any any eq 2000

C3850(config-ext-nacl)# remark SIP

C3850(config-ext-nacl)# permit tcp any any range 5060 5061

C3850(config)# ip access-list extended MULTIMEDIA-CONFERENCING

C3850(config-ext-nacl)# remark CISCO-JABBER-RTP

C3850(config-ext-nacl)# permit udp any any range 16384 32767

C3850(config-ext-nacl)# remark MICROSOFT-LYNC

C3850(config-ext-nacl)# permit tcp any any range 50000 59999

C3850(config)# ip access-list extended TRANSACTIONAL-DATA

C3850(config-ext-nacl)# remark HTTPS

C3850(config-ext-nacl)# permit tcp any any eq 443

C3850(config-ext-nacl)# remark CITRIX

C3850(config-ext-nacl)# permit tcp any any eq 3389

C3850(config-ext-nacl)# permit tcp any any eq 5985

C3850(config-ext-nacl)# permit tcp any any eq 8080

C3850(config-ext-nacl)# remark ORACLE

C3850(config-ext-nacl)# permit tcp any any eq 1521

C3850(config-ext-nacl)# permit tcp any any eq 1527

C3850(config-ext-nacl)# permit tcp any any eq 1575

C3850(config-ext-nacl)# permit tcp any any eq 1630

C3850(config-ext-nacl)# permit tcp any any eq 6200

C3850(config)# ip access-list extended BULK-DATA

C3850(config-ext-nacl)# remark FTP

C3850(config-ext-nacl)# permit tcp any any eq ftp

C3850(config-ext-nacl)# permit tcp any any eq ftp-data

C3850(config-ext-nacl)# remark SSH/SFTP

C3850(config-ext-nacl)# permit tcp any any eq 22

C3850(config-ext-nacl)# remark SMTP/SECURE SMTP

C3850(config-ext-nacl)# permit tcp any any eq smtp

C3850(config-ext-nacl)# permit tcp any any eq 465

C3850(config-ext-nacl)# remark IMAP/SECURE IMAP

C3850(config-ext-nacl)# permit tcp any any eq 143

C3850(config-ext-nacl)# permit tcp any any eq 993

C3850(config-ext-nacl)# remark POP3/SECURE POP3

C3850(config-ext-nacl)# permit tcp any any eq pop3

C3850(config-ext-nacl)# permit tcp any any eq 995

C3850(config-ext-nacl)# remark CONNECTED PC BACKUP

C3850(config-ext-nacl)# permit tcp any eq 1914 any

C3850(config)# ip access-list extended SCAVENGER

C3850(config-ext-nacl)# remark BITTORRENT

C3850(config-ext-nacl)# permit tcp any any range 6881 6999

C3850(config-ext-nacl)# remark APPLE ITUNES MUSIC SHARING

C3850(config-ext-nacl)# permit tcp any any eq 3689

C3850(config-ext-nacl)# permit udp any any eq 3689

C3850(config-ext-nacl)# remark MICROSOFT DIRECT X GAMING

C3850(config-ext-nacl)# permit tcp any any range 2300 2400

C3850(config-ext-nacl)# permit udp any any range 2300 2400

C3850(config)# ip access-list extended DEFAULT

C3850(config-ext-nacl)# remark EXPLICIT CLASS-DEFAULT

C3850(config-ext-nacl)# permit ip any any

! This section configures the class maps

C3850(config-cmap)# class-map match-all VOICE

C3850(config-cmap)# match cos 5

! VoIP is trusted (from the VVLAN)- cos classification for IP phone

C3850(config-cmap)# class-map match-any SIGNALING

C3850(config-cmap)# match cos 3

! Signaling is trusted (from the VVLAN) - cos classification for IP phone

C3850(config-cmap)# match access-group name SIGNALING

! Signaling is classified by ACL (from the DVLAN)

C3850(config-cmap)# class-map match-all MULTIMEDIA-CONFERENCING

C3850(config-cmap)# match access-group name MULTIMEDIA-CONFERENCING

! Associates MULTIMEDIA-CONFERENCING access list with class map

C3850(config-cmap)# class-map match-all TRANSACTIONAL-DATA

C3850(config-cmap)# match access-group name TRANSACTIONAL-DATA

! Associates TRANSACTIONAL-DATA access list with class map

C3850(config-cmap)# class-map match-all BULK-DATA

C3850(config-cmap)# match access-group name BULK-DATA

! Associates BULK-DATA access list with class map

C3850(config-cmap)# class-map match-all SCAVENGER

C3850(config-cmap)# match access-group name SCAVENGER

! Associates SCAVENGER access list with class map

! This section configures the PC-MARKING policy map

C3850(config-cmap)# policy-map PC-MARKING

C3850(config-pmap-c)# class VOICE

C3850(config-pmap-c)# set dscp ef

! VoIP is marked EF

C3850(config-pmap-c)# class SIGNALING

C3850(config-pmap-c)# set dscp cs3

! Signaling is marked CS3

C3850(config-pmap-c)# class MULTIMEDIA-CONFERENCING

C3850(config-pmap-c)# set dscp af41

! Multimedia conferencing is marked AF41

C3850(config-pmap-c)# class TRANSACTIONAL-DATA

C3850(config-pmap-c)# set dscp af21

! Transactional data is marked AF21

C3850(config-pmap-c)# class BULK-DATA

C3850(config-pmap-c)# set dscp af11

! Bulk data is marked AF11

C3850(config-pmap-c)# class SCAVENGER

C3850(config-pmap-c)# set dscp cs1

! Scavenger traffic is marked CS1

C3850(config-pmap-c)# class class-default

C3850(config-pmap-c)# set dscp default

! class-default marks all other IP traffic to 0

! This section configures conditional trust on the interfaces

! and applies the PC-MARKING service policy

C3850(config)# interface range GigabitEthernet 1/0/1-45

C3850(config-if-range)# switchport access vlan 10

C3850(config-if-range)# switchport voice vlan 110

C3850(config-if-range)# trust device cisco-phone

! The interface is set to conditionally-trust Cisco IP Phones

C3850(config-if-range)# service-policy input PC-MARKING

! Attaches the PC-MARKING policy to the interface(s)

! Queuing configurations detailed in Examples 21-5

21.1.5 策略5:接入边界有线队列设计

例21-5详细展示了应用在所有有线端口上的QoS策略（参考表21-1）。图21-2展示了所有有线端口上使用的1P7Q3T队列模型。

例21-5 展示了Catalyst 3850 上相应的1P7Q3T 出向队列配置。

注释:例21-5中展示的8类模型1P7Q3T配置可以轻松地扩展为支持2条优先级队列，详见第20章。主要的区别在于将语音和视频流量区分开，以及对大数据和清道夫类的处理方法。但只需很少的修改就可以完成。

图21-2 Tifosi案例研究:Catalyst 3850 8类（1P7Q3T）出向队列模型

例21-5 Tifosi案例研究:Catalyst 3850上的1P7Q3T出向有线队列配置案例

! This section configures buffers, thresholds, and a single PQ

C3850(config-pmap-c)# policy-map 1P7Q3T

C3850(config-pmap)# class REALTIME-QUEUE

C3850(config-pmap-c)# priority level 1

C3850(config-pmap-c)# police rate percent 10

! PRIORITY is assigned strict priority with a policer rate set to 10

! percent of line rate

C3850(config-pmap-c-police)# class CONTROL-QUEUE

C3850(config-pmap-c)# bandwidth remaining percent 5

C3850(config-pmap-c)# queue-buffers ratio 10

! CONTROL is assigned 5 percent bandwidth remaining after the

! priority queue is serviced, and allowed up to an additional 1/10th of

! buffer pool

C3850(config-pmap)# class SIGNALING-QUEUE

C3850(config-pmap-c)# bandwidth remaining percent 2

! SIGNALING is assigned 2 percent bandwidth remaining after the

! priority queue is serviced

C3850(config-pmap-c)# class INTERACTIVE-VIDEO-QUEUE

C3850(config-pmap-c)# bandwidth remaining percent 23

C3850(config-pmap-c)# queue-buffers ratio 10

C3850(config-pmap-c)# queue-limit dscp af43 percent 80

C3850(config-pmap-c)# queue-limit dscp af42 percent 90

C3850(config-pmap-c)# queue-limit dscp af41 percent 100

! INTERACTIVE is assigned 23 percent bandwidth remaining after the

! priority queue is serviced, allowed up to an additional 1/10th of

! buffer pool, and provides for three thresholds for three DSCP values

C3850(config-pmap-c)# class STREAMING-VIDEO-QUEUE

C3850(config-pmap-c)# bandwidth remaining percent 10

C3850(config-pmap-c)# queue-buffers ratio 10

C3850(config-pmap-c)# queue-limit dscp af33 percent 80

C3850(config-pmap-c)# queue-limit dscp af32 percent 90

C3850(config-pmap-c)# queue-limit dscp af31 percent 100

! STREAMING is assigned 10 percent bandwidth remaining after the

! priority queue is serviced, allowed up to an additional 1/10th of

! buffer pool, and provides for three thresholds for three DSCP values

C3850(config-pmap-c)# class TRANSACTIONAL-DATA-QUEUE

C3850(config-pmap-c)# bandwidth remaining percent 24

C3850(config-pmap-c)# queue-buffers ratio 10

C3850(config-pmap-c)# queue-limit dscp af23 percent 80

C3850(config-pmap-c)# queue-limit dscp af22 percent 90

C3850(config-pmap-c)# queue-limit dscp af21 percent 100

! TRANSACTIONAL is assigned 24 percent bandwidth remaining after the

! priority queue is serviced, allowed up to an additional 1/10th of

! buffer pool, and provides for three thresholds for three DSCP values

C3850(config-pmap-c)# class SCAVENGER-QUEUE

C3850(config-pmap-c)# bandwidth remaining percent 1

C3850(config-pmap-c)# queue-buffers ratio 10

! SCAVENGER is assigned 1 percent bandwidth remaining after the

! priority queue is serviced, and allowed up to an additional 1/10th of

! buffer pool

C3850(config-pmap-c)# class class-default

C3850(config-pmap-c)# bandwidth remaining percent 25

C3850(config-pmap-c)# queue-buffers ratio 25

! DEFAULT is assigned 25 percent bandwidth remaining after the

! priority queue is serviced, and is allowed up to an additional 1/4th

! of the buffer pool

! This section configures interface egress queuing parameters

C3850(config)# interface gigabitEthernet 1/0/13

C3850(config-if)# service-policy out 1P7Q3T

注释:前文案例中，在命令queue-buffer ratio中使用的数值可能有一定的误导性。这个数值并不是数字分母，而是一个比例。比如队列缓存为1/4或25%，那么命令就是queue-bufferratio25。

21.2 Tifosi融合接入QoS设计:无线

Tifosi的移动园区网接入层由CiscoCatalyst3850交换机、CT5760WLC和一些无线客户端构成。

无线客户端遵从应用给所有无线客户端的标记/限速策略。当无线客户端在AP之间漫游时，策略是跟随无线客户端走的；但如果客户端漫游到它所属的SPG（交换机对等体组，也就是区域或大楼）之外，客户端的流量就会定向到MC（移动性控制器，也就是CT5760），MC提供SPG之间的漫游。换句话说，如果客户端漫游出了SPG，那它的流量总是会发往MC；也就是流量会回到客户端初始的附着点，就好像客户端还在那里一样。

由于存在这种流量，需要在CT5760上配置额外的队列策略，来维持这类流量的优先级。

在本节中，无线客户端和无线控制器将使用以下混合策略:

■ 为客户端动态启用分类、标记和限速策略；

■ 为Tifosi的8类QoS模型启用2P2Q+AFD出向队列；

■ 在访客SSID和企业SSID之间实现带宽分离；

■ 在CT 5760 上为Tifosi 的8 类QoS 模型启用1P7Q3T 出向队列；

■ 启用AAA（ISE）来认证无线客户端。

下面按顺序介绍这些接入QoS策略的具体配置；同时也给出ISE的配置描述，只不过不那么具体。设置Cisco ISE 的更多信息请参考以下网址:http://www.cisco.com/en/US/products/ps11640/index.html。

图21-3 显示出在Tifosi 接入网络中使用的无线QoS 设计，图中标记出了Catalyst 3850、CT 5760 和ISE 的部署位置。

图21-3 Tifosi Software案例研究:移动网络QoS设计

21.2.1 策略6:移动无线客户端的接入边界设计（通过动态策略应用分类和标记）

通过ISE向无线客户端动态应用QoS策略（参考表21-1），详见例21-6。

例21-6 Tifosi案例研究:在Catalyst 3850上为移动无线客户端部署接入边界设计（以无线PC或访客自带设备为例）

C3850(config-cmap)# class-map match-all VOICE

C3850(config-cmap)# match dscp ef

! VoIP is trusted (from the VVLAN)

C3850(config-cmap)# class-map match-any SIGNALING

C3850(config-cmap)# match dscp cs3

! Signaling is trusted (from the VVLAN)

C3850(config-cmap)# match access-group name SIGNALING

! Signaling is classified by ACL (from the DVLAN)

C3850(config-cmap)# class-map match-all MULTIMEDIA-CONFERENCING

C3850(config-cmap)# match access-group name MULTIMEDIA-CONFERENCING

! Associates MULTIMEDIA-CONFERENCING access list with class map

C3850(config-cmap)# class-map match-all TRANSACTIONAL-DATA

C3850(config-cmap)# match access-group name TRANSACTIONAL-DATA

! Associates TRANSACTIONAL-DATA access list with class map

C3850(config-cmap)# class-map match-all BULK-DATA

C3850(config-cmap)# match access-group name BULK-DATA

! Associates BULK-DATA access list with class map

C3850(config-cmap)# class-map match-all SCAVENGER

C3850(config-cmap)# match access-group name SCAVENGER

! Associates SCAVENGER access list with class map

! This section configures the PC-MARKING policy-map

C3850(config-cmap)# policy-map PC-MARKING

C3850(config-pmap-c)# class VOICE

C3850(config-pmap-c)# set dscp ef

! VoIP is marked EF

C3850(config-pmap-c)# class SIGNALING

C3850(config-pmap-c)# set dscp cs3

! Signaling is marked CS3

C3850(config-pmap-c)# class MULTIMEDIA-CONFERENCING

C3850(config-pmap-c)# set dscp af41

! Multimedia-conferencing is marked AF41

C3850(config-pmap-c)# class TRANSACTIONAL-DATA

C3850(config-pmap-c)# set dscp af21

! Transactional Data is marked AF21

C3850(config-pmap-c)# class BULK-DATA

C3850(config-pmap-c)# set dscp af11

! Bulk Data is marked AF11

C3850(config-pmap-c)# class SCAVENGER

C3850(config-pmap-c)# set dscp cs1

! Scavenger traffic is marked CS1

C3850(config-pmap-c)# class class-default

C3850(config-pmap-c)# set dscp default

! class-default marks all other IP traffic to 0

21.2.2 策略7:接入边界无线队列设计

在跟据表21-1修改了全局策略后，WCM会将QoS策略动态地应用到无线客户端，详见例21-7。图21-4展示了在所有无线端口动态应用的无线2P2Q模型。

图21-4 Catalyst 3850出向无线2P2Q队列模型

例21-7 展示了Catalyst 3850 上2P2Q 出向队列的相关配置。

例21-7 Catalyst上的2P2Q出向无线队列配置案例

! This section configures egress wireless queuing and a dual priority queue

C3850-2(config)# policy-map port_child_policy

C3850-2(config-pmap)# class non-client-nrt-class

C3850-2(config-pmap-c)# bandwidth remaining ratio 7

! Non-real-time multicast traffic receives 7 percent of the remaining

! bandwidth after the priority queue has been serviced

C3850-2(config-pmap-c)# class RT1

C3850-2(config-pmap-c)# priority level 1

C3850-2(config-pmap-c) police rate percent 10 conform-action transmit　exceed-action drop

! RT1 is set to priority level 1 and policed to drop at 10 percent C3850-2(config-pmap-c-police)# class RT2

C3850-2(config-pmap-c)# priority level 2

C3850-2(config-pmap-c)# police rate percent 20 conform-action transmit exceed-action drop

! RT1 is set to priority level 2 and policed to drop at 20 percent

C3850-2(config-pmap-c-police)# class class-default

C3850-2(config-pmap-c)# bandwidth remaining ratio 63

! DEFAULT receives 63 percent of the remaining

! bandwidth after the priority queue has been serviced

注释:WCM会根据无线端口的协商结果，动态地应用出向无线队列配置。当它确定一个端口是无线端口时，会应用系统静态定义的policy-map port_child_policy（作为non-client-nrt-class的系统policy map）和射频级别的整形器。如果无线端口级别没有开启优先级级别，就无法在SSID级别或客户端级别应用策略。

21.2.3 策略8:访客SSID和企业SSID之间的带宽分配（分离带宽的SSID策略）

在SSID级别，在下游方向上应用QoS策略，详见例21-8。

例21-8 Tifosi案例研究:分离带宽的接入边界设计

! This section configures a bandwidth ratio of 30 for the guest SSID

C3850(config)# Policy-map TRUST-BW-GUEST

C3850(config-pmap)# class class-default

! This configures TRUST of DSCP and marks UP toward the AP – only necessary if

global trust has not been enabled

C3850(config-pmap-c)# set dscp dscp table dscp2dscp

C3850(config-pmap-c)# set wlan user-priority dscp table dscp2up

C3850(config-pmap-c)# bandwidth remaining ratio 30

! This section configures a bandwidth ratio of 70 for the enterprise SSID

C3850(config)#Policy-map TRUST-BW-ENTERPRISE

C3850(config-pmap)# class class-default

! This configures TRUST of DSCP and marks UP toward the AP – only necessary if

global trust has not been enabled

C3850(config-pmap-c)# set dscp dscp table dscp2dscp

C3850(config-pmap-c)# set wlan user-priority dscp table dscp2up

C3850(config-pmap-c)# bandwidth remaining ratio 70

! Applies policy to wireless lan guest

C3850(config)# wlan guest 33

C3850(config-wlan)# service-policy out TRUST-BW-GUEST

! Applies policy to wireless lan enterprise

C3850(config)# wlan enterprise 34

C3850(config-wlan)# service-policy out TRUST-BW-ENTERPRISE

21.2.4 策略9:CT 5760 WLC上行链路端口

在CT 5760 无线端口应用QoS 策略，详见例21-9。图21-5 展示了无线8 类队列模型。

图21-5 Tifosi案例研究:CT 5760 8类（1P7Q3T）出向队列模型

例21-9 给出了Cisco 5760 WLC 上1P7Q3T 出向队列的相关配置。

例21-9 Cisco 5760 WLC上的1P7Q3T出向有线队列

! This section configures buffers, thresholds and a single priority queue

CT5760(config-pmap-c)# policy-map 1P7Q3T

CT5760(config-pmap)# class REALTIME-QUEUE

CT5760(config-pmap-c)# priority level 1

CT5760(config-pmap-c)# police rate percent 10

! PRIORITY is assigned strict priority with a policer rate set to 10

! percent of line rate

CT5760(config-pmap-c-police)# class CONTROL-QUEUE

CT5760(config-pmap-c)# bandwidth remaining percent 5

CT5760(config-pmap-c)# queue-buffers ratio 10

! CONTROL is assigned 5 percent bandwidth remaining after the

! priority queue is serviced, and allowed up to an additional 1/10th of

! buffer pool

CT5760(config-pmap)# class SIGNALING-QUEUE

CT5760(config-pmap-c)# bandwidth remaining percent 2

! SIGNALING is assigned 2 percent bandwidth remaining after the

! priority queue is serviced

CT5760(config-pmap-c)# class INTERACTIVE-VIDEO-QUEUE

CT5760(config-pmap-c)# bandwidth remaining percent 23

CT5760(config-pmap-c)# queue-buffers ratio 10

CT5760(config-pmap-c)# queue-limit dscp af43 percent 80

CT5760(config-pmap-c)# queue-limit dscp af42 percent 90

CT5760(config-pmap-c)# queue-limit dscp af41 percent 100

! INTERACTIVE is assigned 23 percent bandwidth remaining after the

! priority queue is serviced, allowed up to an additional 1/10th of

! buffer pool, and provides for 3 thresholds for 3 DSCP values

CT5760(config-pmap-c)# class STREAMING-VIDEO-QUEUE

CT5760(config-pmap-c)# bandwidth remaining percent 10

CT5760(config-pmap-c)# queue-buffers ratio 10

CT5760(config-pmap-c)# queue-limit dscp af33 percent 80

CT5760(config-pmap-c)# queue-limit dscp af32 percent 90

CT5760(config-pmap-c)# queue-limit dscp af31 percent 100

! STREAMING is assigned 10 percent bandwidth remaining after the

! priority queue is serviced, allowed up to an additional 1/10th of

! buffer pool, and provides for 3 thresholds for 3 DSCP values

CT5760(config-pmap-c)# class TRANSACTIONAL-DATA-QUEUE

CT5760(config-pmap-c)# bandwidth remaining percent 24

CT5760(config-pmap-c)# queue-buffers ratio 10

CT5760(config-pmap-c)# queue-limit dscp af23 percent 80

CT5760(config-pmap-c)# queue-limit dscp af22 percent 90

CT5760(config-pmap-c)# queue-limit dscp af21 percent 100

! TRANSACTIONAL is assigned 24 percent bandwidth remaining after the

! priority queue is serviced, allowed up to an additional 1/10th of

! buffer pool, and provides for 3 thresholds for 3 DSCP values

CT5760(config-pmap-c)# class SCAVENGER-QUEUE

CT5760(config-pmap-c)# bandwidth remaining percent 1

CT5760(config-pmap-c)# queue-buffers ratio 10

! SCAVENGER is assigned 1 percent bandwidth remaining after the

! priority queue is serviced, and allowed up to an additional 1/10th of

! buffer pool

CT5760(config-pmap-c)# class class-default

CT5760(config-pmap-c)# bandwidth remaining percent 25

CT5760(config-pmap-c)# queue-buffers ratio 25

! DEFAULT is assigned 25 percent bandwidth remaining after the

! priority queue is serviced, and is allowed up to an additional 1/4th

! of the buffer pool

! This section configures interface egress queuing parameters

CT5760(config)# interface gigabitEthernet 1/0/13

CT5760(config-if)# service-policy out 1P7Q3T

注释:例21-9中展示的8类模型1P7Q3T配置可以轻松地扩展为支持2条优先级队列，详见第20章。主要的区别在于将语音和视频流量区分开，以及对大数据和清道夫类的处理方法。但只需很少的修改就可以完成。

注释:5760上的有线上行链路并没有限制只使用4条队列，因为它们没有直接与无线AP相关联。为了简化配置，本例中使用的有线队列策略与Catalyst 3850上的有线端口队列策略相同。

21.3 Cisco身份服务引擎

Tifosi 选择使用的管理工具是Cisco ISE。如图21-6 所示，你可以使用cisco-av-pair:ip:sub-qos-policy-in/out=<policy name> 来为每个授权用户提供QoS 策略。完整的QoS 策略通过全局CLI 命令配置在Catalyst 3850 中。RADIUS 服务器（ISE）只会把策略名称推送到Catalyst 3850，表明应该为特定客户端应用哪个策略。图21-6显示出ISE的GUI管理页面，展示了如何配置Cisco-av-pair，将特定用户或用户组的MQC 策略名称推送到Catalyst 3850。

图21-6 Tifosi案例研究:ISE QoS策略名称页面截屏

如果客户端想要漫游，并且配置了移动性特性，策略就会跟随客户端移动。这种迁移是通过将客户端使用的策略名称信息传输到客户端漫游到的融合接入设备上实现的。

21.4 小结

本章继续介绍Tifosi Software 公司的案例，在他们的多层企业园区网络中，通过融合接入交换平台（Catalyst 3850 和CT 5760）应用战略8 类端到端QoS 模型。

园区网接入层策略实施的对象包括不信任、信任和条件信任的终端设备，除了明确的分类和标记策略外，还在Catalyst 3850 和CT 5760 上实施了出向队列策略。

21.5 扩展阅读

Cisco企业媒体网园区QoS设计4.0:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSCampus_40.html

媒体网园区QoS设计一览:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/qoscampusaag.html

媒体网Catalyst 3560/3850 QoS设计一览:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/qoscampuscat3xxxaag.html

Cisco Catalyst 3850 和 Catalyst 3650-X 交换机软件配置指南，Cisco IOS 15.0(2)SE:QoS配置指南:http://www.cisco.com/en/US/docs/switches/lan/catalyst3850x_3560x/software/release/15.0_2_se/configuration/guide/swqos.html

媒体网Catalyst 4500 QoS 设计一览:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/qoscampuscat4500aag.html

Cisco Catalyst 4500系列交换机软件配置指南，IOS XE 3.3.0SG和IOS 15.1(1)SG:QoS配置指南:http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/15.1/XE_330SG/configuration/guide/qos_mrg.html

媒体网Catalyst 6500 QoS 设计一览:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/qoscampuscat6500aag.html

CiscoCatalyst6500系列交换机IOS15.1SYSupervisorEngine2T软件配置指南:QoS配置指南:http://www.cisco.com/en/US/partner/docs/switches/lan/catalyst6500/ios/15.1SY/config_guide/sup2T/qos_overvwiew.html

第5部分 数据中心QoS设计

第22章 数据中心QoS设计的注意事项与建议

在数据中心网络中，服务质量（QoS）的主要任务——重中之重——是管理数据包丢失。在GE（吉比特以太网）/10GE/40GE/100GE数据中心网络中，几毫秒的拥塞就会瞬时导致缓存溢出，从而使设备大量丢弃数据包。此外，仅仅使用硬件缓存和队列，无法满足某些数据中心协议的需求——比如RoCE（融合以太网中的远程直接数据存储，Remote Direct Memory Access over Converged Ethernet）或FCoE（以太网光纤通道，Fibre Channel over Ethernet）——它们要求获得零丢包/无损服务。为了满足这种需求，在数据中心QoS的设计中还必须使用其他DCB（数据中心桥接，Data Center Bridging）技术。

QoS在数据中心网络中的第二个任务是在物理/虚拟接入边界上，分类、标记和管理应用协议。

第11章中讨论了战略性QoS设计的原则，其中一些就可以应用到数据中心的QoS设计中。

■ 优先选择在硬件上实施QoS，别无他选时再实施软件QoS:除了Nexus 1000V 虚拟交换机以外，其他Cisco Nexus 交换机都是在专用的硬件ASIC（专用集成电路， Application Specific Integrated Circuit）上实施QoS 的；因此执行QoS 策略并不会对这些设备的主CPU带来额外负担。因此你可以在这些硬件平台上以GE/10GE/40GE和100GE的线速，应用并高效率地实现复杂的QoS策略。

■ 在技术条件和管理条件均可行的条件下，在尽可能靠近源的位置对应用进行分类和标记:这一规则促成了端到端差分服务/逐跳行为。有些应用服务器会在它们的网卡（NIC，Network Interface Card）上实施CoS（服务类别）或DSCP（差分服务代码点）标记，因此（多数情况中）这些标记是可以被信任的。尤其当IT部门已经将这些应用服务器在物理上放置在数据中心内部，这种信任关系便更确定无疑了。但有时候这些服务器的标记与网络中实施的战略性端到端QoS模型不符，因此需要重新标记。

■ 在尽量靠近源的地方对不需要的流量进行限速:网络部门可能想要对某些应用的流量进行限速，那么就要在靠近源的地方实施限速——根据标准规则重新标记流量，或者干脆丢弃流量。

■ 为了防止发生拥塞，在每个节点都启用队列策略，无论该节点发生拥塞的可能性有多小:在数据中心设计中应用该规则是为了防止超额预定带来瞬时拥塞。由于数据中心网络使用数吉比特速率，几乎瞬间就可能填满队列缓存，因此建议在数据中心的设计中，为每个节点都启用入向和出向队列策略。

■ 启用控制层面限速来保护控制层面:这是QoS工具中的可选功能，用来增强数据中心网络基础设施的安全性。

22.1 数据中心体系结构

建议:

■ 理解各种数据中心体系结构及其相应的QoS需求。

在数据中心设计中没有万金油，而且数据中心的体系结构会在极大程度上影响与之相关的QoS设计。我们来看几个类型的数据中心体系结构及其相应的QoS需求，如下所示:

■ 高性能（HPT）数据中心体系结构；

■ 大数据数据中心体系结构，包括高性能计算（HPC）、高吞吐量计算（HTC）和Grid数据中心体系结构；

■ 虚拟化多服务数据中心（VMDC）体系结构；

■ 安全多租户数据中心（SMDC）体系结构；

■ 大规模可扩展数据中心（MSDC）体系结构。

接下来简要概述每种体系结构，并针对每种体系结构的数据中心，着重强调QoS设计的重点。

22.1.1 高性能数据中心体系结构

建议:

■ 了解为什么HPT数据中心体系结构拥有最少的QoS需求。

HPT（High-Performance Trading）数据中心用于金融企业，因为这些企业关注的是如何提高订单执行速度，只有这样，他们才能在市场波动期间获得竞争优势并把握机会。HPT环境中的性能不是以毫秒计算的，而是以微秒和纳秒计算的。

因此，HPT 数据中心常使用能够提供低延迟的硬件平台，比如Cisco Nexus 3000 系列数据中心交换机，并且HPT数据中心的整体构建目标着重于最小化或消除超载现象。图22-1展示了HPT数据中心体系结构的案例。

图22-1 HPT数据中心体系结构

在低阻塞/非阻塞的HPT数据中心体系结构中，QoS所扮演的角色无足轻重（因为这种体系结构的设计目标就是为了提供一个无需QoS的环境）。

22.1.2 大数据（HPC/HTC/Grid）体系结构

建议:

■ 了解为什么大数据体系结构使用的QoS工具与园区网体系结构类似。

大数据体系结构的目标是处理庞大且复杂的数据集，使用传统的数据处理方法实在难以处理如此庞大的数据集。

这类数据中心解决的问题包括实现海量数据集的捕捉、索引、存储、搜索、共享、传输和分析。这种数据集逐渐增大的趋势是通过对单一大数据集的相关数据进行分析，衍生出更多其他信息；从而能够发现数据之间的相关性，并有助于预防疾病、打击犯罪、预测道路交通状况或预测市场趋势等。因此，这类数据中心多用于大学、研究和开发机构、政府部门和私人机构。

大数据体系结构可以被进一步分为如下任务类别。

■ 高性能计算（HPC）:HPC任务的特征是在短时间内应用大量计算资源。HPC环境通常以FLOPS（每秒浮点运算，Floating-Point Operations per Second）来衡量。

■ 高吞吐量计算（HTC）:与HPC类似，HTC任务也需要大量计算能力，但需要更长的运算时间（需要几个月甚至几年，而不是几小时和几天）；因此它更关注——不是每秒的运算——而是每月或每年的运算。

■ Grid:Grid计算是指多个位置的计算机资源联合起来完成一个共同的目标。可以把Grid想象成一个分布式系统，这个系统能够完成涉及大量文件的非交互式工作。Grid计算与传统HPC系统的区别在于，Grid的结构更加松散、分布不均匀并且在地理位置上分布得也很广泛。尽管一个单独的Grid可以专用于一项特定的应用，但一般Grid会同时用于多个目的。

对于需要处理海量数据的工作任务来说，“分步解决”思想能够提高工作效率。举例来说，一个庞大的工作任务可以被分解或划分为几个较小的子任务，通过将这些子任务的结论进行合并、精简及还原，就能够得到最终的结果。这种方法适用于大数据分析，Google的专利技术MapReduce就使用了这种方法。

这种方法还被引入到了Apache的开源技术Hadoop中，但这里的重点在于使用大量廉价节点集群，配置通用的硬件，来处理多项子任务。

无论使用哪种方法，要想处理海量数据，首先需要存储海量数据；因此要使用基于集群的分布式文件系统来实现数据存储。

图22-2描绘了大数据数据中心体系结构，并着重突出了基于集群的设计。

图22-2 （基于集群的）大数据数据中心体系结构

在实施基于集群的大数据体系结构时，分别使用独立的服务器来提供计算和存储，然后这些服务器构成集群。因此从QoS的角度看来，支持大数据体系结构所需的工具和设计，与园区网络类似——因为它们都会信任每个节点，并在每个节点上使用硬件队列。

另外，大数据数据中心的另一个优势是对吞吐量的优化，这部分内容将在22.2.2节中进行介绍。

22.1.3 虚拟多服务数据中心体系结构

建议:

■ 理解计算和存储虚拟化的唯一QoS需求，包括提供无损的以太网服务。

图22-3 虚拟多服务数据中心体系结构

虚拟化和云技术改变了数据中心的整体结构，主要体现在以下几个方面:

■ 应用不再与硬件服务器（或服务器集群）相关联；

■ 存储不再与硬件硬盘（或阵列）相关联；

■ 网络基础设施不再与硬件设备相关联。

正如上述列表指出的，在利用计算机池、存储和网络互联资源来优化底层基础设施时，虚拟化往往是第一步。进而，可以利用云技术来提供基础设施和平台等服务。

虚拟多服务数据中心（VMDC，Virtualized Multiservice Data Center）体系结构利用这些基于云的技术，将计算、存储、网络互联、虚拟化和管理资源统一到基于矩阵（Fabric-Based）的单一平台中，这个平台能够提高运行效率，简化操作并提供业务灵活性。

VMDC体系结构的QoS设计呈现出一大转变:既要支持无损计算和存储虚拟化协议——比如 RoCE 和 FCoE，也要支持服务器虚拟化协议——比如动态迁移（Live Migration）/vMotion。

在数据中心的QoS设计中，VMDC是最新、最严苛且部署最广泛的数据中心体系结构，本书的QoS设计章节将围绕这种体系结构进行介绍。除此之外，VMDC还是接下来介绍的数据中心体系结构（即SMDC和MSDC）的基础。

22.1.4 安全多租户数据中心体系结构

建议:

■ 了解如何在单一的基础设施上利用虚拟化来支持多租户，了解这种做法对QoS设计的影响。

安全多租户数据中心（SMDC，Secure Multitenant Data Center）体系结构使用了虚拟化技术，其目的是为了在单一的底层计算、存储和网络基础设施上，支持多项业务。

在企业环境中，每个部门都可以是一项业务，并作为一个私有云来运作。每个部门还可能会有各种计算需求、应用或存储需求；所有部门需要在统一的操作域中进行管理和维护。

在运营商环境中，每个企业都可以是一个租户，这些企业在共享的公共云环境中，租用或使用运营商的云基础设施。在使用私有云的案例中，每个企业可能都会有独特的计算、应用和存储需求。此外，还需要对每个租户执行严格的安全和SLA（服务等级协议）协定，这样既可以满足企业的租用需求，也可以满足运营商的商业需求。

图22-4展示了SMDC体系结构的案例。

SMDC的QoS设计需求在很大程度上与VMDC相同，它们最主要的区别是使用的标记模型:SMDC标记模型不仅会识别各种应用/流量类，还会识别客户的服务等级（比如金/银/铜），详见本章后续内容。

图22-4 安全多租户数据中心体系结构

22.1.5 大规模可扩展数据中心体系结构

建议:

■ 理解虚拟数据中心如何扩展，理解这种做法对于提高整体数据传输效率起到了什么作用。

Cisco 的大规模可扩展数据中心（MSDC，Massively Scalable Data Center）是一个框架，数据中心设计师可以使用这个框架来构建一个灵活的数据中心:数据中心提供少量应用，但这些应用分布在上千台服务器上；数据中心的规模可以局限于一个部门，也可以扩展到Internet规模。传统数据中心是在集群内部署应用的，MSDC数据中心与此不同，它的特征是提供少量的庞大应用，这些应用分布在不同地理位置，并且分布于同一个计算和存储池中。其实，与其说这些数据中心是托管环境，不如说它们更像是高度优化的计算机。

图22-5展示了MSDC体系结构的案例。

MSDC是基于云的体系结构，因此它与VMDC具有相同的QoS需求；此外它还要求将吞吐量最大化，因为这方面的问题会随着数据中心的（庞大）规模等比变化。

本章22.2.2节将详细讨论吞吐量——更贴切的说法是“实际吞吐量”。

图22-5 大规模可扩展数据中心体系结构

22.2 数据中心QoS工具

建议:

■ 理解数据中心QoS工具集，使你可以在数据中心QoS设计中高效地使用这些工具集。

与园区网交换机一样，数据中心交换机也要执行QoS操作——其中包括分类、标记、列队和丢弃——在硬件中，以数据中心速率来执行上述操作。

除此之外，虚拟数据中心模型也有它独特的挑战:将SAN（存储区域网络，Storage Area Network）与以太网LAN融合到单一矩阵中。这种融合的网络体系结构可以从以下几个方面节省成本:

■ 减少了所需交换机的数量，使交换机能够同时支持这两类网络流量；

■ 减少了所需接口的数量；

■ 降低了线缆的部署复杂性；

■ 降低了管理、操作复杂性和所需的活动行为。

有些SAN 协议，尤其是光纤通道（Fibre Channel），需要无损传输。尽管硬件QoS 机制对于减少由瞬时缓存拥塞导致的丢包（在本书第3部分中介绍）大有裨益，但标准以太网仍无法确保提供纯粹的无损传输。为了应对这个独特的挑战，IEEE将以太网进行了扩展，开发出DCB（数据中心桥接）工具集，下面将一一介绍。

继DCB工具集后，本章将讨论一种新兴的实际吞吐量/吞吐量优化算法，该算法利用了IP ECN（显式拥塞通知）QoS 机制；最后介绍DCTCP（数据中心传输控制协议），它在大数据和MSDC环境中的重要性越来越强。

22.2.1 数据中心桥接工具集

建议:

■ 熟悉DCB工具，比如PFC、ETS、拥塞通知和DCBX，使你可以高效地利用这些工具，将SAN和LAN矩阵融合在数据中心网络中。

IEEE 成立了一个特殊的工作组，称为（IEEE 802.1）数据中心桥接任务组，他们的任务是定义以太网的增强功能，以便以太网能够支持融合的数据中心网络的各种需求。这些增强功能包括如下内容:

■ 优先级流控制（IEEE 802.1Qbb）；

■ 增强型传输选择（IEEE 802.1Qaz）；

■ 拥塞通知（IEEE 802.1Qau）；

■ DCB 交换（DCBX）（IEEE 802.1Qaz 结合802.1AB）。

接下来按顺序介绍这些DCB工具。但在此之前，有必要先提供一点与传统流控制机制相关的背景知识:以太网流控制（IEEE 802.3x）。

1.以太网流控制:IEEE 802.3x

建议:

■ 理解EFC（以太网流控制）是如何提供无损以太网服务的，并理解它的局限性。

IEEE 802.3x EFC 定义于1997 年，它引入了暂停帧（PAUSE Frame）的概念，从而实现以太网中的无损传输。

EFC的工作原理是:如果发送方设备（可以是服务器或网络交换机）的传输速度大于接收方设备的接收速度，接收方设备就会向发送方设备返回一个暂停帧，从而强制发送方设备在一小段时间内暂停传输数据。

图22-6展示了EFC的运作案例，以及该机制的局限性。

在图22-6中发生了以下事件。

1.服务器A 向服务器B 发送流量。在本例中，假设流量被标记为CoS 3（这是FCoE 的默认CoS值）。

2.在某一时刻，服务器B 变得拥塞，并向网络交换机返回了一个暂停帧。假设本例中的网络交换机不具备任何缓存空间（这种假设简化了案例，并且在后续案例中，能够突出DCB网络中交换机缓存的临界值）。

图22-6 EFC的运作案例

3.在本例中，由于网络交换机不具备缓存空间，因此网络交换机会立即向服务器A 发送自己的暂停帧。

4.服务器A 必须暂时停止所有传输。届时，假设服务器A 还有其他流量需要传输，其中包括:

■ 标记为CoS 3 的数据帧，发送到服务器B；

■ 标记为CoS 5 的高优先级数据帧，发送到服务器B；

■ 标记为CoS 2 的数据帧，发送到服务器C（完全有能力接收流量）；

■ 标记为CoS 3 的数据帧，发送到服务器C（完全有能力接收流量）。

然而，由于要遵守暂停帧的要求，在暂停计时器超时之前，这些流量都不会被传输——即使这里有被标记为高优先级CoS值的流量，或者有发往其他（可接收流量的）工作站的流量。这种导致其他流量也被延迟发送的结果称为HoL（线头，Head of Line）阻塞，这也表现了EFC在功能性方面严重的局限性。

2.优先级流控制:IEEE 802.1Qbb

建议:

■ 对比EFC，体会PFC（优先级流控制）的改进，理解如何使用PFC来为存储协议提供无损服务。

在2008年，数据中心桥接工作任务组对EFC引入了一项增强功能:优先级流控制。

PFC提供了链路层面的流控制机制，可以根据不同的（802.1p）CoS优先级进行独立控制。这个机制的目标是确保不会因为DCB网络中的拥塞而导致数据帧丢失，同时缓解了EFC带来的HoL阻塞问题。

在使用PFC时，暂停帧中包含（并与之关联）明确的CoS值。发送方和接收方为每个CoS值提供接收和传输缓存/队列。这些传输和接收队列构成了“虚拟通道（Virtual Lane）”（或虚拟链路[Virtual Link]），一个CoS 值对应一条虚拟通道。PFC 可以独立控制每条虚拟通道暂停或重新开始发送流量。在网络中使用这种方法时，可以通过独立的虚拟通道创建一个无丢包CoS值，同时接口上还可以承载其他类型的流量。可以有多个CoS值获得无丢包服务。

如果一个工作站（由于接收缓存已满）无法接收标记为某个CoS值的流量，它可以逆着数据发来的方向，针对这个CoS值发送暂停帧，如图22-7所示。

图22-7 PFC传输队列和接收缓存

从下面的案例中可以看出来PFC针对HoL阻塞问题的缓解效果，如图22-8所示。

图22-8 PFC运作案例

在图22-8中发生了以下事件。

1.服务器A 向服务器B 发送标记为CoS 3 的流量。

2.某一时刻，服务器B 的CoS 3 接收缓存空间被填满，它需要向网络交换机返回PFC 暂停帧（CoS 3）。与前文案例一样，我们也假设网络交换机上没有缓存空间。

3.由于网络交换机不具备缓存空间，因此网络交换机会立即向服务器A 发送自己的暂停帧（CoS 3）。

4.服务器A 必须暂时停止传输CoS 3 数据帧。届时，在传输停止期间，假设服务器A 还有其他流量需要传输。

前文案例中的服务器A将所有出站流量排进一个FIFO（先进先出）传输队列中，与此不同的是，本例中的服务器A拥有8条不同的传输队列；每条队列对应一个CoS值。因此服务器A 仍可以向服务器B 发送CoS 5 数据帧，可以向服务器C 发送CoS 2 数据帧。事实上，本例中被HoL 阻塞影响的数据流只有发往服务器C 的CoS 3 数据帧（在停止向服务器B 发送CoS 3 数据帧后，也同时阻塞了发往服务器C 的CoS 3 数据帧）。

如前所述，PFC不仅提供了基于CoS的无损服务，还在极大程度上降低了HoL阻塞带来的影响。但在后续技术的发展中，仍可以通过交换机缓存架构对此做出一定改善，详见后文内容。

在NX-OS平台中，使用pause命令启用PFC。

注释:Cisco UCS（统一计算系统）平台和VMware ESX/ESXi平台也支持PFC。

3.滑动缓存和虚拟输出队列

建议:

■ 理解为什么需要滑动缓存；

■ 理解虚拟输出队列如何提高了效率，如何有效地管理了数据中心环境中的交换机缓存。

尽管严格说来滑动缓存（Skid Buffer）和虚拟输出队列（VOQ，Virtual Output Queuing）并不是DCB工具集的一部分，但它们是在DCB网络中实现无损传输的必要组成部分，并且它们还将HoL阻塞的影响降到了最低。因此我们有必要在这里介绍这两个概念。

缓存管理对于PFC的操作来说至关重要。举例来说，如果允许传输或接收缓存溢出，那么传输将不再是无损的。除了要在接收和发送双方向上管理每条虚拟通道的缓存，网络交换机还要有足够的缓存空间来完成以下工作:

■ 当网络中两台工作站之间发送了PFC暂停帧，需要缓存空间来存储这段时间之内发送的数据帧；

■ 当发送方收到了PFC暂停帧，需要缓存空间来存储已经开始传输的数据帧。

用来存储以上两种数据帧的缓存空间称为滑动缓存，这种缓存通常用于入站方向，在硬件的基础上应用于每个接口。

除此之外，在数据中心环境中，由于传输而导致终端工作站（服务器）变得过载的首要原因并不是速率不匹配，而是多到一的数据流，也称为聚播（Incast）流。聚播流常见于大数据和MSDC体系结构中。

各类网络流量的描述如下所示:

■ 单播描述的是一到一的数据流；

■ 广播描述的是一到所有的数据流；

■ 组播描述的是一到多的数据流；

■ 聚播描述的是多到一的数据流。

图22-9描绘了一个聚播流，展示了交换机缓存是如何缓解HoL阻塞的。

图22-9 聚播案例以及PFC和交换机出站接口缓存

在图22-9 中，服务器A ～D 正在向服务器E 发送标记为CoS 3 的单播数据流，当服务器E 变得过载，它会生成PFC 暂停帧（CoS 3），并将其发往网络交换机。本例中的网络交换机具有缓存能力，它能够（至少在短时间内）接收过载的流量。当交换机接口上的出站缓存空间被占满，它必须（相应地）向发送方工作站发送PFC 暂停帧（CoS 3）。

图22-9还显示出，在聚播场景中，网络交换机的出向接口成为了聚合节点。因此为了处理这些流量，该节点就要有足够大的出站队列缓存空间（以便处理n条聚播流）。

然而，更高效地应用数据中心交换机缓存的方法是:在入向流量到达交换矩阵之前，执行拥塞/队列机制（每个接口上并不需要非常大的输出缓存）。这种方法称为虚拟输出队列（VOQ， Virtual Output Queuing）。

通过使用VOQ，在拥塞流量到达交换矩阵之前，人为地在交换系统中将其缓解（优先行为，但并没有指向性），详见图22-10。

注释:别把VOQ和入向队列弄混。入向队列处理的是真实的拥塞，这种拥塞是由于背板/交换矩阵的超额预定导致的（也就是总入向带宽超出了背板/交换矩阵的性能），入向队列是由入向队列策略管理的；而VOQ是在交换矩阵之前的节点上处理虚拟的拥塞，它是由出向队列策略管理的。

相比较于每接口上的物理出向缓存，VOQ提供的优势在于能够用少得多的缓存来处理聚播，详见图22-10。

图22-10 VOQ缓存与出站接口缓存

如图22-10所示，如果出站缓存实际占用的空间与图中所示的VOQ相同，那么随着聚播流的增多，交换机缓存空间的总容量也会急速增大（比如2:1聚播流，需要两倍于VOQ的缓存空间；8:1聚播流，需要8倍于VOQ的缓存空间）。

在每一个会导致出向拥塞变得更严重的入向接口上，VOQ硬件架构能够缓解拥塞，从而优化交换机缓存空间，使其能够承受聚播流。与此同时，VOQ超载流量并不会消耗矩阵带宽，设备会在出向接口丢弃这部分流量。

Cisco Nexus 数据中心交换平台就使用了VOQ 架构，在设计章节中会更加详细地针对每个平台进行介绍。

4.增强型传输选择:IEEE 802.1Qaz

建议:

■ 理解ETS（增强型传输选择）如何提高DCB网络中的整体带宽性能。

增强型传输选择是数据中心桥接任务组提出的另一种以太网改善方案，它提供了一种通用管理框架，来为虚拟通道分配和管理带宽。

为了扩展虚拟通道的概念，启用了DCB的NIC（也称为融合网络适配器[CNA，Converged Network Adaptor]）使用ETS 来配置虚拟接口队列——每个虚拟通道一条队列。每条虚拟接口队列负责为其流量组分配带宽，每个组在其内部可以动态管理流量带宽。举例来说，如果一个虚拟通道当前并没有使用分配给它的带宽，ETS就可以将这些未使用的带宽进行动态重分配，将其分配给另一个需要这些带宽的虚拟通道。

ETS虚拟接口队列可以提供如下服务。

■ 优先级:可以为一个虚拟通道分配严格优先级服务。

■ 有保障的带宽:可以为一个虚拟通道分配物理链路带宽的百分之几。

■ 尽力而为:这是默认的虚拟通道服务。

图22-11展示了ETS的工作原理，10GE接口上有三个虚拟通道，分别用于存储流量（CoS3）、HPC流量（CoS 2）和LAN流量（CoS 0）。管理员为每个虚拟通道都分配了特定的带宽百分比。然而在t3时隙中，LAN流量可以使用空闲/未使用的带宽，这部分带宽来自于服务器集群的虚拟通道。

图22-11 ETS工作原理示例

5.拥塞通知:IEEE 802.1Qau

建议:

■ 熟悉802.1Qau拥塞通知的能力和工作原理。

IEEE 802.1Qau 拥塞通知是第2 层流量管理系统，它通过速率限制器来对导致拥塞的流量进行整形，从而将拥塞控制在网络边缘。

在拥塞点测量拥塞情况，若发生了拥塞，响应点会通过实施速率限制或反向压力，来对流量进行整形，以减少拥塞对网络其他部分造成的影响。在这种体系结构中，汇聚层交换机（作为拥塞点）可以向两个接入层交换机（作为响应点）发送控制帧，要求它们限制各自的流量，详见图22-12。

图22-12 拥塞通知工作原理案例

6.数据中心桥接交换:IEEE 802.1Qaz + 802.1AB

建议:

■ 了解DCBX（数据中心桥接交换）协议在DCB网络中所扮演的角色。

DCBX与ETS定义在同一个IEEE协议簇（802.1Qaz）中。

DCBX是一项提供发现功能和能力交换功能的协议，用于发现对等体，并在具有DCB能力的网桥之间交换配置信息。DCBX 使用了IEEE 802.1AB（LLDP [ 链路层发现协议]）中提供的功能。

DCBX包含以下能力:

■ DCB对等体发现；

■ 不匹配配置检测；

■ 对等体的DCB链路配置。

以下DCB参数可以经由DCBX进行交换:

■ PFC；

■ ETS；

■ 拥塞通知；

■ 应用；

■ 逻辑链路断开；

■ 网络接口虚拟化。

除了能够在交换机和端点之间提供发现功能外，DCBX还能够自动交换以太网和DCB参数，详见图22-13。

图22-13 DCBX工作原理案例

22.2.2 数据中心传输控制协议

建议:

■ 熟悉数据中心传输控制协议（DCTCP），了解它与IP ECN 的交互方式，了解它如何提高了数据中心的总实际吞吐量。

除了为存储协议提供无损服务外，数据中心QoS的另一个重要设计目标是将实际吞吐量最大化。实际吞吐量（Goodput）是由应用层吞吐量进行定义的，它将传输数据包中的协议开销排除在外。因此实际吞吐量总是低于吞吐量（物理传输的总比特率），也可以说实际吞吐量总是低于物理链路带宽（因为链路几乎不可能总是维持在100%占用的状态）。

其中一项会严重降低实际吞吐量的因素是传输层流控制和拥塞避免机制。尤其是TCP的慢启动特性，它会严重降低实际吞吐量。

为了解决这个问题，斯坦福大学和微软联合研究并开发出了TCP拥塞控制的增强特性——使用IP ECN。标准的TCP 拥塞控制算法只能够检测拥塞的发生，DCTCP（使用IP ECN）却能够测量拥塞的程度。

注释:第5章介绍了IP ECN。

CDTCP的基础是以下两个重要概念:

■ 根据拥塞程度（而不是根据是否发生了拥塞），以百分比进行响应:降低了发送速率的变化程度。

■ 根据瞬时队列长度来标记ECN:可以实现快速反馈，并能够根据不同情况调整窗口大小，更好地处理突发。

为了理解DCTCP的工作原理，请考虑以下两个场景——每个场景都将DCTCP与标准的TCP进行比较——详见表22-1中的总结。在每个场景中都发送了10个数据包，有些数据包的IP ECN CE（经历拥塞）位设置为1，有些未设置。

表22-1 TCP工作原理对比DCTCP工作原理

在第1个场景中，80%数据包的CE位都被设置为1（表示传输过程中经历了拥塞）。TCP的慢启动将对此做出响应，即将TCP窗口大小缩小50%。DCTCP会根据比例将窗口大小缩小40%（经历拥塞百分比的一半）。在这个场景中，标准TCP和DCTCP的差别不那么明显。

但在第2个场景中，只有10%的数据包被设置了CE位（CE位为1）。TCP的慢启动机制仍会将窗口大小缩小50%。TCP对此场景的响应与前一场景相同，它并不关注拥塞的程度，只对拥塞的发生做出响应。DCTCP还是根据比例缩小窗口大小，这次只缩小5%（仍然是所经历拥塞百分比的一半）。在第2个场景中，TCP和DCTCP之间的差别显而易见。

因此，DCTCP不仅能够很好地控制突发（因为它能够对瞬时ECN标记做出快速响应），它还能够保持队列的低延迟（因为它能够保持流量的平稳）——这两者结合在一起就可以实现高实际吞吐量。实现这两点只需对TCP行为做些许改变。

注释:本书的设计部分并不涵盖DCTCP，因为在本书写作时，该特性（在本书讨论的设备型号上）暂无法使用。

22.3 NX-OS QoS框架

建议:

■ 知道Nexus OS（NX-OS）QoS——尽管与MQC 类似——有其独特的配置元素；

■ 理解 NX-OS 中不同类型的 QoS 对象，其中包括 type qos、type queuing 和 type network-qos，以及它们的任务；

■ 理解system qos 在应用全局QoS 参数时的任务，以及如何覆盖这些参数。

Nexus OS 使用 MQC 的变体来部署 QoS。NX-OS 仍使用 MQC 中的对象（比如 class map、policy map 和service policy），但它添加了以下独特的策略type（类型）定义。

■ type qos:定义的是用来实现标记和限速的MQC 对象。

■ type queuing:定义的是用来实现队列和调度机制的MQC 对象，此外还有一些标记对象。

■ type network-qos:定义的是DCB 网络范围内QoS 属性的特征，应该在网络中的所有交换机上实现一致的QoS属性。

■ control-plane:定义的是控制层面限速所使用的MQC对象。

除此之外，NX-OS的策略还可以应用到以下目标上:接口和VLAN（以及控制层面）。NX-OS还有一个独特的目标:system qos。所有应用在system qos的策略都在交换机全局有效，但当接口或VLAN上应用了不同的策略时，后者将代替全局策略。

具体设备型号的指导方针和NX-OS QoS 的注意事项将在设计章节中进行相应的介绍。

22.4 数据中心QoS模型

建议:

■ 按照以下常用的五个步骤，在数据中心网络中部署QoS。

一般来说，在数据中心部署QoS需要五个主要的步骤。

1.修正/详述企业的战略QoS标记模型，使其适合数据中心环境。

2.应用各种数据中心入向QoS模型（必要的话），其中包含以下模型:

■ 信任服务器模型；

■ 不信任服务器模型；

■ 单应用服务器模型；

■ 多应用服务器模型；

■ 服务器限速模型；

■ 无损传输模型。

3.配置入向队列。

4.配置出向队列。

5.（可选）配置控制层面限速。

下面详细介绍每个步骤。

22.4.1 数据中心标记模型

建议:

■ 修正/详述企业的战略QoS标记模型，使其适合数据中心环境。

基于RFC 4594 的4、8 或12 类战略模型几乎适用于所有其他网络（PIN），数据中心拥有独特的流量特征、应用和限制，这些独特性会影响数据中心使用的标记模型。因此需要改编、扩展或修改战略QoS标记模型，以适应这个独特的环境。

对数据中心所使用的标记模型造成影响的因素如下:

■ 数据中心的应用和协议；

■ CoS/DSCP标记；

■ CoS 3 覆盖考量；

■ 基于应用的标记模型；

■ 基于应用和基于租户的标记模型。

下面按顺序详细介绍这些注意事项。

1.数据中心的应用和协议

建议:

■ 想一想企业QoS模型中没有考虑到数据中心所使用的那些应用/协议，如何将它们集成到企业QoS模型中；

■ 想一想数据中心没有使用（或使用率大大降低）哪些应用/协议。

有些应用和协议是数据中心独有的（或占主要地位），其中包括:

■ 计算虚拟化协议:

■ RoCE（融合以太网中的远程直接数据存取[RDMA]）协议能够使一台计算机——通过融合以太（即DCB）网络——直接访问另一台计算机的内存，这其中的工作不涉及两台计算机的操作系统。这样做可以实现高吞吐量和低延迟的网络传输，尤其适用于大规模的并行计算机集群。RoCE是一个链路层协议，因此它能够实现同一以太网广播域内的任意两台主机之间的通信。需要注意的是，RoCE需要通过PFC提供无损服务。当与FCoE结合使用时，需要为RoCE指定它自己的无丢包类/虚拟通道，比如CoS 4。这时，要将其他标记为CoS 4的应用（比如视频）重新指定CoS值，以便提高RoCE的性能。

■ iWARP（Inernet广域RDMA协议）扩展了RDMA在IP网络中的应用。需要注意的是，iWARP并不需要无损服务，因为它运行在TCP或SCTP（流控制传输协议）之上，这些协议提供了可靠传输。因此可以把它标记为未使用的DSCP/CoS（或已有的值，根据使用的战略QoS模型而定）——或将其标记为网间控制流量（CS6/CoS6）或网络控制流量（CS7/CoS7），或者甚至可以将其标记为其他非控制类流量——只需将额外带宽分配到相应的类中即可。

■ 虚拟机控制和迁移协议（VM控制）:虚拟机（VM）需要在虚拟控制层之间传输控制流量；这些流量可能被标记为默认值，或者可以参照控制层面流量，为其明确指定标记。需要注意的是，VM控制流量是VM的控制层面流量，根据所使用的QoS 模型，该流量可能会被标记为CoS 6 或CoS 7。

■ 迁移:指的是能够在不同的物理设备之间，无需断开客户端或应用，而迁移运行中的VM（或应用）的协议。VM的内存、存储和网络连通性，都从源主机迁移到了目的主机。

VMware vMotion 是最常见的迁移协议，可以将运行中的VM 从一台物理服务器迁移到另一台，支持零宕机时间、连续的服务可用性以及业务的完整性。

需要注意的是，迁移协议（包括vMotion）为VM基础设施提供了控制功能（因此可以将其视为控制层面的协议）。但是由于它们的流量模式（即大型VM文件传输），通常并不将其归类为网间控制类（CoS 6），因为迁移协议的流量可以轻易地淹没这个类。最好将迁移协议归类为一个单独且专用的类（或已有的类，根据使用的战略QoS模型而定），或者可以将其归类为另一个流量类，比如CoS 4、CoS 2，甚至CoS 1。

注释:可以根据Cisco UCS管理器定义的QoS策略，在计算机硬件平台（比如Cisco UCS平台）上对vMotion流量进行标记。这部分策略的配置内容超出了本书范围，本书着重关注网络QoS 设计。该特性的用法可以参考以下文档:http://www.cisco.com/en/US/docs/unified_computing/ucs/sw/gui/config/guide/2.1/b_UCSM_GUI_Configuration_Guide_2_1_chapter_010100.html。

■ 存储虚拟化协议:

■ FCoE（以太网光纤通道）是一项在以太网络上封装光纤通道（FC）的计算机网络技术。FCoE需要无损传输服务，它是第2层协议，本质上是不可路由的（除非在IP隧道中，比如IP光纤通道[FCIP]）。需要注意的是，FCoE需要PFC来提供无损服务，并且通常需要被标记为CoS 3（NX-OS中的默认设置）。只要有可能，尽量让FCoE专用这个类/虚拟通道。

■ iSCSI（Internet小型计算机系统接口）将SCSI命令封装在IP中，以此实现数据传输。iSCSI可以用来在LAN、WAN或Interne上传输数据，它能够实现与位置无关的数据存储和读取。需要注意的是，iSCSI并不需要无损服务，因为它通常使用TCP来获得可靠传输。因此可以将它放到单独且专用的类中（或已有的类，根据使用的战略QoS 模型而定），或者可以将其归类为其他流量类，比如CoS 2或CoS 1。

这些协议——其中一些为第2层协议——需要被放入DC标记模型中。

除此之外，要知道并不是所有企业应用也都存在于数据中心网络中——或者有些在数据中心网络中存在，但应用率却大大下降。举例来说，数据中心网络在很大程度上是没有语音和交互式视频流量的，因为这类终端通常位于DC外（尽管数据中心网络中可能会有一些媒体流，去往会议服务器/网关，或从服务器/网关发出）。类似地，数据中心网络中也很少会有清道夫应用，因为企业的IT部门会对这类PIN的物理接入和管理做出严格限制。DC中的这类应用流量模式也应该同样地包含在DC标记和部署模型中。

2.CoS/DSCP标记

建议:

■ 要知道数据中心内的某些（第2层）协议需要使用基于CoS的分类；

■ 了解仅使用CoS的标记模型的局限性，考虑如何实现混合的CoS和DSCP标记模型（若支持的话）。

前文建议使用基于DSCP的标记模型（因为这种方式是端到端的），但在数据中心内，通常无需使用这种推荐方案，因为数据中心使用的一些重要协议是第2层的，因此无法支持DSCP标记，只能使用CoS。

尽管考虑使用只有CoS的模型很吸引人，但却可能无法满足要求，表22-2总结了IEEE 802.1Q-2005提出的CoS使用建议。

表22-2 IEEE 802.1Q-2005 CoS使用建议

深入了解这些建议，可以发现一些重要的使用限制。

■ CoS 7 为网络控制预留。

■ CoS 6 为网间控制预留。

■ CoS 5 建议用于语音（但如前所述，DC 中可能并没有很多语音流量）。

■ CoS 4 建议用于视频（但如前所述，DC 中可能并没有很多交互式视频流量）。DC 中可能会有广播视频（CS5）和流媒体视频（AF3）流量，但默认情况下它们的标记都不是CoS 4。

■ CoS 3 通常为FCoE 预留，且只用于FCoE。

到目前为止，只为管理员留出了三个自定义类:CoS 2（卓越努力）、CoS 1（背景）或默认的CoS 0（尽力而为）。

因此为了保持分类和标记的粒度，可以在数据中心内使用混合的CoS和DSCP标记模型（前提是平台支持），详见下文。

3.CoS 3覆盖技术的考量和战术选项

建议:

■ 了解在使用FCoE时，信令（和多媒体流）标记的覆盖行为；

■ 选择一个战术选项来解决覆盖问题。

在有关数据中心QoS注意事项的争论中，最有争议的是如何在数据中心内调和信令和FCoE。

Cisco 建议将信令流量的标记（默认）映射为CoS 3，这一建议已持续了20 年，因此已有庞大的客户群在按照这个建议设计他们的企业网络QoS。尽管如此，2009和2010年的FCoE行业标准也建议将FCoE 流量标记为CoS 3。

由于FCoE 要求使用唯一且严格的服务级别，因此有些数据中心管理员倾向于将CoS 3专用于FCoE。但是这样一来，对于数据中心内信令流量的处理就变得复杂了——比如去往CUCM或从CUCM发来的信令流。

另外，这里涉及的问题并不仅仅是信令与FCoE之间的问题，而是扩展到了多媒体流——RFC 4594 建议将其标记为AF3，默认映射为CoS 3。而且如前所述，多媒体流是一种类型的视频流，并且确实存在于大多数数据中心网络中。

有一些战略选项可以用来解决这种标记覆盖的问题，其中包括如下做法:

■ 硬件隔离；

■ 第2层与第3层分类；

■ 非对等的CoS/DSCP标记；

■ DC/园区DSCP转变；

■ 共存。

下面按顺序详细介绍这些选项。

硬件隔离

有些平台和接口模块并不支持FCoE。比如Cisco Nexus 7000 上的M 系列模块就不支持FCoE，但F 系列模块可以支持。因此在这类平台上避免CoS 3 覆盖最简单的方法就是使用M系列模块连接CUCM 和多媒体流服务器；同时使用F 系列模块连接DCB FEX（扩展矩阵）模块，以支持FCoE。

第2层与第3层分类

有些Nexus平台既支持CoS到队列的映射，也支持DSCP到队列的映射。比如Nexus 5000就可以将CoS值映射到（QoS组，然后映射到）队列，同时也可以将DSCP值映射到（QoS组，然后映射到）队列。因此可以使用DSCP值来分类信令和多媒体流，分别标记为CS3和AF3，然后为它们指定相应的队列——与FCoE分离且不同的队列；FCoE可以被单独标记为CoS 3，并且映射到专用队列中。

注释:有些平台可能会根据以太类型或CoS 3标记来识别FCoE。

非对等的CoS/DSCP标记

另一个能够区分信令和FCoE的标记战略是使用非对等的CoS/DSCP标记。在这里，非对等表示使用不同的数值，来构成CoS值的前3位比特和DSCP值的前3位比特（两者默认是相同的）。比如可以将信令标记为CoS 4（二进制100）和DSCP CS3（二进制011000）。

DC/园区DSCP转变

有些网络管理员选择使用回避方针来应对覆盖问题，即在数据中心到园区的链路上，实施入向和出向DSCP转变。使用这种方法，管理员可以一对一地重新指定信令和多媒体流的DSCP 标记，将其映射为唯一且非标准的DSCP 值，比如人为地将其默认映射为CoS 4（而不是CoS 3）。图22-14 展示了这种双向DSCP 转变的案例。

图22-14 DC/园区DSCP转变案例

共存

这是一种很少提及的方法，有些管理员在其数据中心网络中，使FCoE和信令共存——都标记为CoS 3。由此可以推断出，即使当CUCM 安装在拥有CNA 的服务器上——CNA（融合网络适配器）可同时支持DCB和DCBX——然后将这些流量类型都放入同一个虚拟通道/队列中，最后得到的结果也是将无损服务同时提供给了信令和FCoE。

4.基于数据中心应用的标记模型

建议:

■ 了解仅使用CoS的标记模型的局限性，考虑如何实现混合的CoS和DSCP标记模型（若支持的话）。

前文已经讨论过，有些第2层数据中心协议无法由DSCP进行标记，只能由CoS标记。而且在某些情况下，将CoS和DSCP结合使用（若支持的话），可以获得更好的分类粒度。图22-15展示了混合的CoS和DSCP分类、标记和队列映射模型。

图22-15 混合CoS和DSCP基于应用的数据中心标记和映射案例

注释:图22-15中展示的队列结构并不等同于具体的Nexus队列模型，它呈现的逻辑概念来自于Nexus队列模型。这些概念包括选择将CoS映射到队列，或者将DSCP映射到队列（借鉴于Nexus 5500），以及选择将CoS值映射到具体的队列（借鉴于Nexus 7000）。后文设计章节将涉及与平台和模块相关的具体队列模型建议。

5.基于数据中心应用/租户的标记模型

建议:

■ 通过使用标记选项，不仅要能够识别应用，还要反映出多租户数据中心标记模型中的客户级别。

基于应用的标记不仅能够识别应用，还能够反映用户/组成员关系，比如将客户与多租户数据中心模型中的服务绑定在一起，详见表22-3。

表22-3 基于数据中心应用/租户的数据中心标记模型案例

22.4.2 数据中心QoS模型

建议:

■ 部署符合你的数据中心网络设计QoS需求的最佳模型。

从以下数据中心入向QoS模型中选择合适的——可以在一个数据中心内部署一个或多个模型。

■ 信任服务器模型:在大多数数据中心内，你能够信任应用服务器上设置的L2/L3标记，尤其是服务器已物理地放置在数据中心内部，并且为其实施了某个级别的管理控制。Nexus平台默认信任CoS和DSCP，因此在连接信任应用服务器的接口上无需进行明确配置。

■ 不信任服务器模型:如果你无法信任一台服务器（或服务器的管理团队，有可能遇到这种情况）的话，你可能需要在连接该服务器的接口上，将CoS和DSCP重新标记为0。

■ 单应用服务器模型:单应用服务器模型实际上与不信任服务器模型相同，区别在于所有源于该服务器的流量，都会在其连接的接口上，被重新标记为一个非零的值。

■ 多应用服务器模型:在多应用服务器模型中，使用访问列表来实现流量分类，并且将流量标记为多代码点（Multiple Codepoint）。这是因为应用服务器根本不标记流量，或者它标记流量所使用的代码点与企业QoS模型不一致。

■ 服务器限速模型:在服务器限速模型中，通过单速或双速限速器，测定一个（或多个）应用类，并将遵从流量、超出流量和（可选）违反流量分别标记为不同的DSCP值。

■ 无损传输模型:在一些Nexus平台/模块上默认启用network-qos，为FCoE提供无损服务。可以将这个模型与其他QoS模型结合使用。

在选择并配置好一个（或多个）入向QoS模型后，还应该配置入向和出向队列策略。最后（可选）还可以配置控制层面限速。

图22-16展示了这些数据中心QoS模型。

图22-16 数据中心QoS模型

22.5 数据中心接口QoS角色

建议:

■ 为所有数据中心QoS模型定义一致的入向和出向QoS策略，其中包括以下内容:

■ 信任服务器/网络连接模型；

■ 不信任服务器模型；

■ 单应用服务器模型；

■ 多应用服务器模型；

■ 服务器限速模型；

■ 无损传输模型。

到目前为止讨论的所有QoS策略元素都可以汇总到各种交换机接口角色中，总结如下。

■ 信任服务器/网络连接模型:

■ 这种模型是为连接受信任的服务器和/或连接受信任的网络设备的接口准备的；

■ 不需要明确配置入向QoS策略——因为默认在入方向上就启用了CoS和DSCP信任；

■ 应该在这类接口（或全局）配置入向type queuing 策略；

■ 应该在这类接口（或全局）配置出向type queuing 策略。

■ 不信任服务器模型:

■ 这种模型是为连接不受信任的服务器的接口准备的；

■ 需要明确配置入向type qos 重标记策略，将CoS 和/ 或DSCP 值重新标记为0；

■ 应该在这类接口（或全局）配置入向type queuing 策略；

■ 应该在这类接口（或全局）配置出向type queuing 策略。

■ 单应用服务器模型:

■ 这种模型是为连接不受信任的单应用服务器的接口准备的；

■ 需要明确配置入向type qos 重标记策略，将CoS 和/ 或DSCP 值重新标记为非零的值；

■ 应该在这类接口（或全局）配置入向type queuing 策略；

■ 应该在这类接口（或全局）配置出向type queuing 策略。

■ 多应用服务器模型:

■ 这种模型是为连接不受信任的多应用服务器的接口准备的；

■ 需要明确配置入向type qos，使用基于ACL 的应用和重标记策略，将CoS 和/ 或DSCP值重新标记为非零的值；

■ 应该在这类接口（或全局）配置入向type queuing 策略；

■ 应该在这类接口（或全局）配置出向type queuing 策略。

■ 服务器限速模型:

■ 使用这种模型的接口所连接的服务器，其流量需要根据测量结果，被丢弃或被重新标记；

■ 需要明确配置入向typeqos限速策略，丢弃流量，或者重新标记CoS和/或DSCP值；

■ 应该在这类接口（或全局）配置入向type queuing 策略；

■ 应该在这类接口（或全局）配置出向type queuing 策略。

■ 无损传输模型:

■ 这种模型是为需要无损服务的DCB接口准备的；

■ 必须在system qos（有些平台/ 模块默认启用）中应用type network-qos 策略，来提供无损服务——通常是为FCoE 提供的，通过以太类型和/ 或CoS 3 来识别FCoE流量；可以将这个模型与其他QoS模型结合使用；

■ 应该在这类接口（或全局）配置入向type queuing 策略；

■ 应该在这类接口（或全局）配置出向type queuing 策略。

图22-17展示了这些数据中心接口角色。

注释:在Nexus 1000V上，面向VM的接口不支持入向/出向队列，面向网络的接口只支持出向队列。

图22-17 数据中心QoS角色

22.6 小结

本章讨论了数据中心网络QoS设计的考量和建议。数据中心网络中最重要的QoS任务是管理数据包丢失——即使对于启用了DCB技术来提供无损传输（也就是无丢包服务）的环境也是如此。数据中心网络中QoS的第2项任务是对应用流量进行分类、标记和（可选）限速。

本章回顾了能够应用在数据中心内的一些战略QoS设计原则，其中包括如下内容:

■ 优先选择在硬件上实施QoS，别无他选时再实施软件QoS；

■ 在技术条件和管理条件均可行的条件下，在尽可能靠近源的位置对应用进行分类和标记；

■ 在尽量靠近源的地方对不需要的流量进行限速；

■ 在每个有可能发生拥塞的节点启用队列策略；

■（可选）启用控制层面限速来保护控制层面。

在这之后，本章介绍了一些数据中心体系结构及其相应的QoS需求，其中包括如下内容:

■ 高性能数据中心，有很少或没有QoS需求；

■ 大数据数据中心，与园区网络的QoS需求相似，可以获益于DCTCP；

■ 虚拟多服务数据中心，在常规以太网功能之外，还拥有更多QoS需求，其中包括提供无损传输。因此这些虚拟数据中心不仅需要应用传统QoS工具，还要在其设计中应用DCB工具；

■ 安全多租户数据中心，它虽然是VMDC的变体，但它使用不同的标记模型，不仅基于应用进行分类，还能够将共享基础设施的租户与其应用绑定起来；

■ 大规模可扩展数据中心，它是（从名字可以看出）大规模可扩展的虚拟数据中心（共享相同的QoS/DCB需求），由于拥有大量数据流，因此可以获益于DCTCP。

接着介绍了数据中心桥接工具集，其中包括以下内容:

■ 优先级流控制（PFC），通过针对每个CoS应用的暂停帧提供了无损服务；

■ 增强型传输选择（ETS），优化了DCB带宽；

■ 数据中心桥接交换（DCBX），在对等体之间发现并共享DCB能力。

除此之外还简要介绍了DCTCP，展示了使用IP ECN 标记来增强标准TCP 的操作，极大提高了实际吞吐量。

然后总结了NX-OS QoS 与MQC 的共性与区别。

在这之后讨论了不同数据中心的标记注意事项，其中包括将信令与FCoE区分开的战略选项——两者（默认）共享相同的CoS值（CoS 3）。接着讨论了用于数据中心内的基于应用的和基于应用/租户的标记模型。最后总结了数据中心QoS模型，并定义了与接口相关的数据中心角色。

22.7 扩展阅读

Cisco设计地带:数据中心:http://www.cisco.com/en/US/netsol/ns743/networking_solutions_program_home.html

Cisco数据中心桥接和虚拟化:IEEE 802.1数据中心桥接概述:https://www.cisco.com/en/US/netsol/ns783/index.html

Cisco数据中心解决方案:优先级流控制:建立可靠的第2层基础设施白皮书:http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/white_paper_c11-542809_ns783_Networking_Solutions_White_Paper.html

IEEE DCB工作任务组:http://www.ieee802.org/1/pages/dcbridges.html

优先级流控制（PFC；IEEE 802.1Qbb）:http://www.ieee802.org/1/pages/802.1bb.html

增强型传输选择（ETS；IEEE 802.1Qaz）:http://www.ieee802.org/1/pages/802.1az.html

拥塞通知（IEEE 802.1Qau）:http://www.ieee802.org/1/pages/802.1au.html

数据中心传输控制协议（DCTCP）:http://simula.stanford.edu/～alizade/Site/DCTCP_files/dctcp-final.pdf

DCTCP概述:http://www.ietf.org/proceedings/80/slides/iccrg-3.pdf

第23章 数据中心虚拟接入层（Nexus 1000V）的QoS设计

一个新的范例融入了数据中心网络中，改变了服务器接入层的定义和角色。在过去的几年中，服务器一直是直接连接到物理的接入层交换机上，这也使服务器和网络的界限分明。随着虚拟机（VM）的流行（比如VMware ESX/ESXi 和微软Hyper-V），现在单独一台物理服务器上能够运行许多虚拟服务器。

这种方法可以将多个提供单一服务且未被充分利用的服务器合并到较少的几个物理服务器中，物理服务器在同一硬件上运行多个虚拟操作系统。如今，这种模型的普及所带来的结果已经不仅仅是大量减少数据中心所需的物理硬件那么单一了，它还减少了电能消耗、空调消耗、机架空间，以及运行多台服务器所需的所有成本。为了更上一层楼，集中管理工具出现了，比如VMware 的vCenter（虚拟中心，Virtual Center），它使虚拟服务器变得比分离的单机服务器更好管理。不过这种在管理上的便利性，对于连接这些虚拟服务器的网络来说，就不是这么简单了。

在过去，网络工程师的工作比较简单——由于服务器和网络之间存在明显的界限，因此对于明显属于网络工作组内部的设备，网络工程师能够在其上实施所有第2层访问策略（包括QoS和安全特性等）。如今，多个VM运行在一个虚拟控制层上（即Hypervisor，它是主机软件，作用是使多个VM和操作系统能够运行在单独的物理服务器上），从而接入层也从物理的L2交换机转移到了虚拟交换机上，这个虚拟交换机就像是虚拟控制层内的软件层。

尽管使用VM能够获得很多好处，而且多年来VM已经成为了数据中心的支柱，但它仍然（尤其是为网络团队）带来了一些新的挑战。举例来说，如果一个组织机构为了在数据中心网络内物理的交换基础设施上实施QoS，而清晰地定义了一组QoS策略，那么这些策略的受控程度现在已经大大降低了，因为绝大多数服务器的接入点是在虚拟交换机上，这些虚拟交换机是由虚拟控制层进行控制的。显然，除非你能够按照相同的标准，实施一系列从服务器到主机的QoS策略，否则所有QoS设计的实用性都会大大降低。举例来说，若一个虚拟控制层的默认虚拟交换机无法使用与当前整体QoS设计相同的标准实施QoS策略，那么在整个数据中心网络中实施QoS就变得困难重重了。

为了解决这一问题，Cisco 推出了Nexus 1000V 虚拟接入层交换机，它使用NX-OS 系统。将它安装到VM环境中后，这个交换机会代替虚拟控制层通常会使用的默认虚拟交换机，从而推动在数据中心网络中实施一致的QoS特性的工作。

这个虚拟接入交换机的运作与物理L2交换机一模一样，只是它运行于虚拟控制层的软件中。它并不是直接运行在VM中的；它位于虚拟控制层，并与以下两者有着密切的关联:连接VM的虚拟接口和服务器使用的pNIC（物理网络接口卡）。与数据中心网络中的其他L2接入交换机一样，虚拟接入交换机的主要工作也是在网络和服务器之间建立信任边界，并根据类（class），管理上行链路的流量。

图23-1展示了虚拟接入层中的QoS角色。

图23-1 数据中心虚拟接入交换机接口QoS角色

本章主要介绍虚拟接入层的QoS 设计，尤其是针对Nexus 1000V。本章先回顾Nexus 1000V的系统体系结构，然后详细阐述针对该平台的QoS设计建议。

23.1 Cisco Nexus 1000系统体系结构

Nexus 1000V由两个主要部分构成:VEM（虚拟以太网模块）和VSM（虚拟引擎模块）。

VSM 是Nexus 1000V 的控制层面，它为VEM 提供所有配置、管理和控制功能。VEM 针对真实数据转发做出响应，并且它绝不会将非控制流量发送给VSM，这也就是说VSM永远不用处理数据层面的流量。从这里可以看出，VSM 和VEM 之间的关系与Nexus 5000 交换机和Nexus 2000 FEX（矩阵扩展）模块之间的互动关系类似；FEX是由Nexus 5000控制的远程线卡， VEM也可以看作是由VSM控制的远程线卡。

举例来说，在配置多个运行在不同物理服务器上的VEM时，所有配置工作都是通过VSM完成的，而不是由VEM完成。VEM位于虚拟控制层，而VSM是运行在真实服务器上（安装在独立服务器上或者是VM上）的一个应用。从一个简单的远程线卡例子就可以明白VSM与VEM之间的关系:如果VSM故障了，或由于某种原因不可用了，VEM还可以继续正常工作。

每个VSM能够管理最多64个远程VEM，因此可以把一个VSM理解为拥有64个远程线卡的交换机。如果多个VEM位于相同的L2域，它们能够像分布式交换机那样工作，提供诸如vMotion之类的特性。通过使用vMotion技术，VMware的vCenter（虚拟中心）能够将已安装的VM 从一个物理服务器迁移到位于同一L2 网段的另一个物理服务器上。Nexus 1000V 系统体系结构所具有的一项喜人的功能是:与通过vMotion将VM在物理服务器之间迁移一样，针对某个VM配置的QoS策略，也可以在这个VM与其他VM之间完美迁移。

注释:在本书写作时，Nexus 1000V同时支持VMware ESX/ESXi和微软Hyper-V。但本书提供的案例专注于在VMware环境中使用Nexus 1000V。

在单个虚拟控制层中，每个VM 与Nexus 1000V 中的一个vEthernet（虚拟以太网）接口相连接。从网络管理员的角度看来，这个vEthernet接口就像是L2接入交换机上的物理以太网接口。你可以在这些接口上配置QoS特性，并建立信任边界。

图23-2 展示了Nexus 1000V 的系统体系结构。

如图23-2所示，VEM位于虚拟控制层和VM之间。尽管图中只展示了一个VM（通过vEthernet接口）连接到VEM，但实际上最多可以有216个vEthernet接口，也就是说单独一个VEM可以连接216个VM。VMware管理员会将VEM下面的Ethernet（以太网）接口映射到服务器的物理NIC（网卡）。图23-2所示的上行链路是单个以太网接口，它连接着CNA（融合网络适配器）。上行链路还可以是捆绑为10GE 链路的Port Channel。

从图23-2能够获得的另一个重要信息是:没有FCoE（以太网光纤通道）流量穿越VEM。所有SCSI数据连接都是通过另一个虚拟HBA（主机总线适配器）进行连接的，接着虚拟HBA将FCoE流量传输到CNA，然后CNA使用与传输IP流量相同的10GE链路来传输FCoE流量。从QoS的角度看来理解这一流程很重要，因为当其他NX-OS平台（比如Nexus 5000 和7000 系列）有能力分类并管理FCoE 流量时，Nexus 1000V 就无需使用CNA 管理流量的方式（即通过服务器管理程序进行配置）来管理这类流量了。

图23-2 Nexus 1000V系统体系结构概述

从图23-2中可以看出，CNA在QoS中扮演了重要角色。它通过ETS（增强型传输选择）完成了每个组的流量分配工作。举例来说，若CNA在物理上与拥有ETS功能的交换机（比如Nexus 5500）相连，两台设备会就每个类所需的带宽进行沟通。然后当Nexus 5500 的无丢弃类遭遇了拥塞，它就会向CNA发送一个PFC暂停信号，通知对方暂停发送这个类中的流量，这时其他以太网流量将会正常传输。这种做法对FCoE流量尤其有用，因为SCSI负载无法重传丢失数据。而TCP/IP流量对丢失数据包具有较好的复原能力，因为TCP具有面向连接的本质，因此将这类流量放入无丢弃类，所获得的好处非常有限。

注释:上游交换机也需要支持DCBE（数据中心桥接交换）协议，比如Nexus 5500或Nexus 7000 F2/F2e模块。

尽管在端到端QoS设计中，CNA是一个非常重要的角色，尤其是当网络中有FCoE这类需要无损传输的流量时；但本章的重点内容是Nexus 1000V，尤其是对VM 和上链接口应用的QoS特性，详见图23-2。

23.2 Nexus 1000V配置注意事项

与其他NX-OS 交换平台不同，在Nexus 1000V 上，你无需直接配置每个vEthernet、Ethernet 或Port Channel 接口。你需要配置的是接口配置文件（Port Profile）。接口配置文件是一组网络配置设置，描述了一个接口的全部特征。其中可能包括接口上应用的ACL（访问控制列表）、QoS服务策略、VLAN的分配以及NetFlow收集配置等。在配置并启用了这些接口配置文件后，VSM会动态地将接口配置文件推送到vCenter；在vCenter里，这些接口配置文件显示为接口组（Port Group）。然后VMware 管理员将这些接口组分配给每个VM 或pNIC。这时，VEM中的接口就继承了接口配置文件中定义的能力，这些配置是由VSM推送到VEM的。

举例来说，假设你需要创建一个接口配置文件，使其为CUCM提供服务。如果不深入讨论细节的话，你创建的接口配置文件要包含以下属性。

■ VLAN号:为语音协议分配的VLAN。

■ 安全:只放行SIP的ACL。

■ QoS配置文件:支持CUCM的QoS配置文件。

■ 管理:启用NetFlow。

一旦在VSM中创建了接口配置文件，接口配置文件就会自动出现在vCenter中。VMware管理员现在需要做的全部工作就是为CUCM创建一个VM，然后将这个接口组连接到CUCM VM，以便vEthernet接口能够继承接口配置文件中配置的所有能力。

因此你会发现，本章中的所有配置案例都将QoS策略应用于接口配置文件中，而不是应用在接口上。

Nexus 1000V 与其他NX-OS 平台有所区别的一点很重要，即能够配置的class map 和policy map 类型。其他 NX-OS 平台有 3 种类型的 class map 和 policy map，分别是 qos、network-qos 和queuing。但Nexus 1000V 只能配置qos 和queuing 类型的class map 和policy map。

与其他NX-OS平台相同，qos和queuing类型的QoS策略用于以下目的。

■ qos:定义MQC对象，实现标记和限速。

■ queuing:定义MQC对象，实现队列和调度机制。与某些其他NX-OS平台不同， queuing类型的策略不能用于实现分类。

在本书写作时，与其他NX-OS 平台不同，Nexus 1000V 并不支持CoPP（控制层面限速）QoS配置。

监控QoS状态

在监控Nexus 1000V 上的QoS 性能时，最重要的一点是确保启用了QoS 状态特性（QoS statistics）。这使你能够查看到与各个QoS策略所关联的每个流量类的数据包和字节数统计。可以使用例23-1所示的全局NX-OS命令来启用QoS状态特性。

例23-1 启用QoS状态特性

N1KV(config)# qos statistics

! globally enables qos statistics

23.3 入向QoS模型

Nexus 1000V 上的入向QoS 主要应用于vEthernet 接口——与VM 相连的接口。尽管理论上可以在上行链路接口的入向策略中应用重新标记和限速，但由于上行链路是受信任网络的一部分，因此这种做法没多大意义。本节为以下涉及数据中心的章节建立了一个提纲。首先分析各种服务器信任模型，然后在单应用和多应用服务器模型中考虑分类和标记，接着分析入向限速服务器模型。

23.3.1 信任模型

在数据中心网络中，信任服务器的QoS标记是很平常的做法。但在有些情况中可以将服务器视为不受信任的设备，比如托管了由第三方管理的应用；或者在基于云的模型中，多个客户共享数据中心基础设施。接下来的内容将分别讨论这两种情况:受信任的服务器模型和不受信任的服务器模型。

1.受信任的服务器模型

在多数案例中，VM 环境中运行的服务器所标记的CoS 和DSCP QoS 标记是被信任的。默认情况下，当数据包进入Nexus 1000V 的上行链路接口和vEthernet 接口时，所有数据包的CoS和DSCP标记都是被信任的。通常vEthernet接口不是Trunk（聚合链路）接口，因此只能使用DSCP标记。

2.不受信任的服务器模型

在有些案例中，应用服务器可能不信任服务器上的应用所标记的DSCP值，它可能希望将其重新标记为另一个值。最常见的做法是将不受信任的服务器的DSCP值重新标记为0。

配置不受信任的服务器策略具有以下4个步骤。

1.创建ACL，匹配所有从该服务器发来的流量。

2.创建qos 类型的class map，调用刚创建的ACL 来匹配所有源于该服务器的流量。

3.配置qos 类型的policy map，将DSCP 值重写为0。

4.将qos 类型的policy map 添加到该服务器的接口配置文件中，使VMware 管理员能够将其映射到适当的VM。

例23-2给出了接口配置文件的配置，可以将这个配置文件应用到不受信任的服务器接口。注意步骤2中可以用来匹配流量的各种选项。尽管可以使用的选项很多，但只有access-group选项可以正确识别从特定服务器发出的流量。

例23-2 为不受信任的服务器配置接口配置文件

! Step 1 – Create the matching ACL

N1KV(config)# ip access-list UNTRUSTED

N1KV(config-acl)# permit ip any any

! Step 2 – Create the qos type class map

N1KV(config)# class-map UNTRUSTED-SERVER

N1KV(config-cmap-qos)# match ?

access-group　Access group

class-map　　Class map

cos　　　IEEE 802.1Q class of service

discard-class　Discard class

dscp　　　DSCP in IP(v4) and IPv6 packets

ip　　　IP

not　　　Negate this match result

packet　　Packet

precedence　Precedence in IP(v4) and IPv6 packets

qos-group　　Qos-group

N1KV(config-cmap-qos)# match access-group name UNTRUSTED

! Create a class map that matches on the ACL

! Step 3 – Create the qos type policy map

N1KV(config)# policy-map UNTRUSTED-SERVER-POLICY

N1KV(config-pmap-qos)# class UNTRUSTED-SERVER

N1KV(config-pmap-c-qos)# set ?

cos　　　IEEE 802.1Q class of service

discard-class　Discard class

dscp　　　DSCP in IP(v4) and IPv6 packets

precedence　Precedence in IP(v4) and IPv6 packets

qos-group　　Qos-group

N1KV(config-pmap-c-qos)# set dscp 0

! Set the DSCP to 0

! Step 4 – Attach the service-policy to the correct port profile

N1KV(config)# port-profile type vethernet APPLICATION-X

N1KV(config-port-prof)# service-policy type qos input UNTRUSTED-SERVER-POLICY

! Attach the policy map to a vethernet port profile – in this case, "APPLICATION-X"

注意例23-2，在class map 和policy map 中没有明确指定qos 这个策略类型，因为qos 类型是默认选项。本例中使用了一个名为APPLICATION-X的接口配置文件。这个接口配置文件只是一个通用案例，用来指明service policy 的应用位置。你所使用的接口配置文件中还可以定义其他用于一组VM的特征。

注释:从例 23-2 中可以看出，Nexus 1000V 在 qos 类型的 class map 中有多种方法可以分类流量，比如使用丢弃类（discard-class）、数据包长度（packet）、IP优先级（precedence）和QoS组（qos-group）。尽管有如此多选项可以用来分类流量，但本章中并没有使用它们。

你可以使用以下命令来检查例23-2中的配置。

■ show class-map type qos

■ show policy-map type qos

■ show port-profile name

■ show policy-map interface vethernet[ interface number ]

例23-3 展示了如何检查class map 和policy map 的配置是否正确。

例23-3 检查qos类型的QoS策略

N1KV# show class-map UNTRUSTED-SERVER

Type qos class-maps

====================

class-map type qos match-all UNTRUSTED-SERVER

match access-group name UNTRUSTED

N1KV# show policy-map UNTRUSTED-SERVER-POLICY

Type qos policy-maps

====================

policy-map type qos UNTRUSTED-SERVER-POLICY

class UNTRUSTED-SERVER

set dscp 0

注意由于policy map 已经（通过vCenter）被应用到接口配置文件中，因此现在可以在相应接口上检查policy map 的配置。举例来说，若VMware 管理员将例23-2 中创建的接口配置文件应用在接口vEthernet 10 上，就可以使用例23-4 所示方法来检查配置。

例23-4 检查qos类型的QoS策略

N1KV# show policy-map interface vethernet 10

Global statistics status:enabled

Vethernet1

Service-policy (qos) input:UNTRUSTED-SERVER-POLICY

policy statistics status:enabled

Class-map (qos):UNTRUSTED-SERVER (match-all)

114 packets

Match:access-group UNTRUSTED

set dscp 0

23.3.2 分类和标记

尽管Nexus 1000V 能够在出方向上分类和标记流量，但这些行为实际上主要发生在入方向上，并且只定义在vEthernet接口的接口配置文件中。由于所有来自于上游网络的流量都是受信任的，因此在上行链路接口上没有必要实施重新标记行为。

下面总结了如何为以下服务器模型分类并重新标记VM流量:

■ 单服务器应用模型；

■ 多服务器应用模型。

理解以下内容十分关键:在vEthernet接口重新标记入向流量时，你需要同时设置DSCP值和CoS 值。尽管IP 网络中的主流分类工具是DSCP，但Nexus 1000V 只支持CoS 到队列的映射。也就是说，只有在VM上正确设置了入向CoS值，出向队列策略才会正确地分类流量，否则出向队列策略会将这些流量分配到默认队列中（CoS 0）。

1.单应用服务器模型

单应用服务器模型与例23-2到例23-4所示的不受信任的服务器模型非常类似。两者唯一的区别是:单应用服务器模型会将DSCP值设置为一个非零的值，并将CoS设置为相应的值。例23-2不是必须设置CoS值，因为从VM来的所有（去往相连网络的）入站流量都是不受信任的，默认会获得CoS 0。例23-5 展示了如何为媒体服务器重新标记DSCP 值和CoS 值。

例23-5 配置单应用服务器QoS策略

N1KV(config)# class-map type qos SINGLE-SERVER

N1KV(config-cmap-qos)# match access-group name MEDIA-SERVER

! Match on the ACL defining the MEDIA-SERVER

N1KV(config)# policy-map type qos REMARK

N1KV(config-pmap-qos)# class SINGLE-SERVER

N1KV(config-pmap-c-qos)# set dscp af41

! This line marks the DSCP

N1KV(config-pmap-c-qos)# set cos 4

! This line marks the CoS – necessary for egress queuing used later

! Attach the service-policy to the correct port profile

N1KV(config)# port-profile type vethernet APPLICATION-Y

N1KV(config-port-prof)# service-policy type qos input REMARK

配置完policy map 之后，需要将policy map 添加到相应的接口配置文件中。

添加完成后，可以使用以下命令检查是否正确设置了DSCP值和CoS值。

■ show class-map [ type qos]

■ show policy-map [ type qos]（详见例23-6）

■ show port-profile name

■ show policy-map interface

例23-6 检查policy map

N1KV# show policy-map type qos

policy-map type qos REMARK

class SINGLE-SERVER

set dscp af41

set cos 4

! Verifies that *both* DSCP and CoS are set correctly

2.多应用服务器模型

现在假设单个VM上运行了多个应用，或者有一个应用需要使用多种通信协议，这些通信协议需要被标记为不同的DSCP值。与前文案例一样，使用ACL来进行分类，再使用policy map来正确标记DSCP值和相应的CoS值。

请考虑这样一个案例，网络团队要明确标记多媒体应用服务器发出的流量，比如将媒体流量识别并标记为DSCP AF41，将信令流量识别并标记为CS3，将会议数据流（业务性数据）标记为AF21，将所有其他流量标记为默认类（DSCP 0 和CoS 0）。例23-7 给出了相应配置。需要注意的是本例中调用了多个ACL，但为了简化配置，这些ACL的配置并没有出现在案例中。

例23-7 配置多应用服务器模型

! Step 1 - configure the class maps

N1KV(config)# class-map type qos MEDIA-FLOWS

N1KV(config-cmap-qos)# match access-group name MEDIA-FLOWS

! Media flows are identified via MEDIA-FLOWS ACL

N1KV(config-cmap-qos)# class-map type qos SIGNALING

N1KV(config-cmap-qos)# match access-group name SIGNALING

! Signaling traffic is identified via the SIGNALING ACL

N1KV(config-cmap-qos)# class-map type qos CONFERENCING-DATA

N1KV(config-cmap-qos)# match access-group name CONFERENCING-DATA

! Conferencing data traffic is identified via a CONFERENCING-DATA ACL

! Step 2 - configures the policy maps

N1KV(config)# policy-map type qos MULTI-APP-SERVER

N1KV(config-pmap-qos)# class type qos MEDIA-FLOWS

N1KV(config-pmap-c-qos)# set dscp af41

N1KV(config-pmap-c-qos)# set cos 4

! Media flows data flows are marked DSCP AF41 and CoS 4

N1KV(config-pmap-c-qos)# class type qos SIGNALING

N1KV(config-pmap-c-qos)# set dscp cs3

N1KV(config-pmap-c-qos)# set cos 3

! Signaling data flows are marked DSCP CS3 and CoS 3

N1KV(config-pmap-c-qos)# class type qos CONFERENCING-DATA

N1KV(config-pmap-c-qos)# set dscp af21

N1KV(config-pmap-c-qos)# set cos 2

! Conferencing data flows are marked DSCP AF21 and CoS 2

N1KV(config-pmap-c-qos)# class class-default

N1KV(config-pmap-c-qos)# set dscp 0

N1KV(config-pmap-c-qos)# set cos 0

! Configures the default class to set DSCP and CoS to 0

! Step 3 - Attach the policy map to the correct port profile

N1KV(config)# port-profile type vethernet MULTI-APP-SERVER

N1KV(config-port-prof)# service-policy type qos input MULTI-APP-SERVER

这个配置中有趣的一点是:信令流量在上行链路802.1Q Trunk 上标记为了CoS 3，这是对呼叫信令流量最常用的CoS标记方法，但这也是识别FCoE流量所使用的CoS值。在图23-2中， FCoE 流量并不是由Nexus 1000V 直接处理的；而是由CNA 和上游L2 交换机之间的DCBX通信进行设置的，比如Nexus 5000。因此如果使用了FCoE 流量，最终结果就是呼叫信令和FCoE流量都会被上游交换机分类为相同类型，并以相同方式进行处理。

举例来说，DCBX的一个重要特性就是:将FCoE分类到无丢包类别中，若这个类别中的流量遭遇了拥塞，发生拥塞的交换机就会向直连设备反向发送暂停信号，告诉对方暂停发送流量，直到拥塞缓解。由于在本例中信令流量也被标记为CoS 3，因此它也被当作无丢弃流量进行处理。这倒是不会带来严重的负面影响，因为信令流量通常非常小，并且是基于TCP的，也就是说它可以恢复暂停发送的流。

你可以使用以下命令来检查例23-7中的配置。

■ show class-map [ type qos]

■ show policy-map [ type qos]

■ show port-profile name

■ show policy-map interface

23.3.3 服务器限速模型

Nexus 1000V 所支持的限速特性非常齐全，其中包括单速率限速器和双速率限速器。单速率限速器会监控流量的CIR（承诺信息速率），双速率限速器会监控流量的CIR和PIR（峰值信息速率），限速器定义在RFC 2697、RFC 2698 和RFC 4115 中。

Nexus 1000V支持三个流量限速条件（三色）:遵从（绿色）、超出（黄色）或违反（红色）。当数据速率超出CIR或PIR值，数据包的速率会降低或被丢弃。表23-1总结了不同限速器的超出或违反行为。

表23-1 Nexus 1000V限速器行为——超出或违反

尽管确实可以在vEthernet接口和上行链路接口同时应用限速器，但最常见的做法是在vEthernet 接口应用入方向的限速器。这样做可以让Nexus 1000V 在流量进入VM 时，监控并控制每个应用消耗的带宽。

在例23-8中，管理员使用双速三色标记来测量多媒体会议服务器的媒体流，并针对AF41 DSCP 值进行限速。遵从标记是直接在命令中配置的，超出和违反重标记是通过名为cir-markdown-map 和pir-markdown-map 的table map 配置的（默认的设置遵从RFC 2597 中的降级规则）。

例23-8 检查policy map

! This section configures the policing policy map

N1KV(config)# policy-map type qos SERVER-POLICING

N1KV(config-pmap-qos)# class class-default

N1KV(config-pmap-c-qos)# police cir percent 50 pir percent 75 conform set-dscp-

transmit af41 exceed set dscp dscp table cir-markdown-map violate set dscp dscp

table pir-markdown-map

! Traffic is policed to a CIR of 50% and a PIR of 75%

! Conforming traffic is marked AF41

! Exceeding traffic is re-marked per the cir-markdown-map

! Violating traffic is re-marked per the pir-markdown-map

N1KV(config)# port-profile type vethernet MEDIA-SERVER

N1KV(config-port-prof)# service-policy input SERVER-POLICING

! Attach the policing service policy to the correct port profile

你可以使用以下命令来检查例23-8中的配置。

■ show table-map [ cir-markdown-map ]（详见例23-9）

■ show table-map [ pir-markdown-map ]（详见例23-10）

■ show class-map [ type qos]

■ show policy-map [ type qos]

■ show port-profile name

■ show policy-map interface

例23-9 显示出若流量超出了CIR 的限制，AF41（DSCP 34）和AF42（DSCP 36）就会被重新标记为AF42（DSCP 36）。

例23-9 检查CIR降级规则:show table-map cir-markdown-map

N1KV# show table-map cir-markdown-map

Table-map cir-markdown-map

default copy

from 10,12 to 12

from 18,20 to 20

from 26,28 to 28

from 34,36 to 36

例23-10 显示出若流量违反了PIR 的限制，AF41（DSCP 34）和AF42（DSCP 36）就会被重新标记为AF43（DSCP 38）。

例23-10 检查PIR降级规则:show table-map pir-markdown-map

N1KV# show table-map pir-markdown-map

Table-map pir-markdown-map

default copy

from 10,12 to 14

from 18,20 to 22

from 26,28 to 30

from 34,36 to 38

23.4 出向QoS模型

Nexus 1000V 只在上行链路接口的出方向（outbound）上支持CBWFQ。在vEthernet 接口上，数据包的处理规则是FIFO，该接口不支持CBWFQ。与其他NX-OS交换平台不同， Nexus 1000V是基于软件的交换平台，这意味着它不受接口ASIC和物理内存带来的硬件限制。Nexus 1000V 最多支持56 条软件定义的客户队列和8 条系统定义的队列。

注释:与本书中涉及的其他平台一样，数据中心网络内着重使用4类和8类通用出向队列模型。尽管本书也讨论了12类模型，但由于其他Nexus交换平台的队列体系只支持4类和8类模型，因此本节也只讨论这两种模型。

队列策略由以下对象构成:

■ queuing 类型的class map，用来分类流量；

■ queuing 类型的policy map，用来定义队列行为；

■ service policy，用来将策略应用到接口配置文件。

正如表23-2 所描述的，Nexus 1000V 支持8 个预定义协议，可以用于queuing 类型的class map，有助于识别各类VMware/vMotion和VSM/VEM控制流量。

表23-2 Nexus 1000V上的8个预定义类

续表

例23-11展示了如何在队列策略中使用预定义协议。

例23-11 在queuing类型的class map中使用预定义协议

N1KV(config)# class-map type queuing match-any EGRESS-QUEUE

N1KV(config-cmap-que)# match protocol ?

n1k_control　N1K control traffic

n1k_mgmt　N1K management traffic

n1k_packet　N1K inband traffic

vmw_ft　　VMware fault tolerance traffic

vmw_iscsi　VMware iSCSI traffic

vmw_mgmt　VMware management traffic

vmw_nfs　　VMware NFS traffic

vmw_vmotion　VMware vmotion traffic

除了这8个预定义类之外，你还可以根据CoS值来分类流量。但与其他NX-OS交换平台不同，Nexus 1000V 只能根据协议（详见例23-11）或CoS 值进行分类。这也就是为什么一定要在vEthernet接口正确地同时设置DSCP值和CoS值。

注意，例23-11 中列出的协议只可用于queuing 类型的class map，不适用于qos 类型的class map。这意味着无法相应地调整这些协议的CoS 标记，也就是说，系统会自动将所有控制流量都标记为CoS 6。

下面介绍如何为4 类和8 类通用模型配置Nexus 1000V 出向队列策略。

23.4.1 4类出向队列模型

本书使用的通用4类参考模型由以下类别构成:

■ 实时；

■ 控制；

■ 业务性数据；

■ 尽力而为。

在数据中心网络内，尤其是在使用Nexus 1000V 和VMware 的环境中，有些其他流量需要特别处理。至少需要考虑到用于Nexus 1000V 控制、VMware 控制和vMotion 的类别。因此为了支持通用的4类模型，需要在Nexus 1000V上共配置7条出向队列。图23-3展示了这7个类别，以及与其相关联的CoS标记和DSCP标记。

尽管你可能希望在图23-3所示的QoS设计中只看到4个类别，但在虚拟数据中心环境中还需要考虑3个控制类，因此实际的QoS模型其实是7类模型。

图23-3 所示Nexus 1000V 控制类中包含以下三个协议:

■ Nexus 1000V 控制；

■ Nexus 1000V 管理；

■ Nexus 1000V 数据包。

Nexus 1000V 会自动将这些控制数据包标记为CS6/CoS 6。

图23-3 在Nexus 1000V上部署4类出向队列模型

系统不会标记两个与VMware相关的类别——vMotion和VMware控制。尽管Nexus 1000V能够在出方向上对这些协议进行分类和列队，但它无法分类和标记这些协议。因此这些流量被发送到上游交换机时，标记的是CoS 0。但是这样一来，默认行为就会将这些协议分类到默认类中，因此在这里必须采取一些特殊的行为，尤其是对于vMotion流量来说。vMotion被看作是关键任务应用，而且它还会占用数据中心内大量带宽，因此仅仅将它当作尽力而为流量进行处理是完全无法接受的。处理这种问题最好的做法，是在下一跳上游交换机（比如Nexus 5000）上，将这些协议重新标记为一个指定的QoS 类。

图23-3中提供的带宽百分比不是绝对意义上的解决方案建议，仅供参考。数据中心环境中的实际流量类型，影响着最佳带宽分配的结果。举例来说，你的数据中心内可能绝不会出现实时流量，因此可以取消这个分类，并将这部分流量分给其他类别。

与其他控制流量相同，VMware 控制和Nexus 1000V 控制类并不需要太多带宽。但vMotion需要消耗大量带宽，并使用大数据包，这种行为会很快填满出向队列。因此，要根据数据中心内有可能出现的vMotion流量的总量，有针对性地为其分配带宽。

要记住的是，Nexus 1000V 位于虚拟控制层——处于VM 和pNIC 之间。配置中使用的带宽百分比实际上决定的是:将数据包从Nexus 1000V 放入pNIC 上的输出接口队列所依据的调度机制。数据包是通过pNIC输出接口队列，实际传输到物理网络中的。

例23-12 展示了在Nexus 1000V 上配置4 类QoS 模型的方法。

例23-12 在Nexus 1000V上配置4类QoS模型

! The first step is to create the class maps

N1KV(config)# class-map type queuing match-any N1KV-CONTROL

N1KV(config-cmap-que)# match protocol n1k_control

N1KV(config-cmap-que)# match protocol n1k_packet

N1KV(config-cmap-que)# match protocol n1k_mgmt

! This combines the three N1K control protocols into a single class

N1KV(config-cmap-que)# class-map type queuing match-all VMOTION

N1KV(config-cmap-que)# match protocol vmw_vmotion

! Configures the VMware vMotion class

N1KV(config-cmap-que)# class-map type queuing match-all VMW-CONTROL

N1KV(config-cmap-que)# match protocol vmw_mgmt

! Configures the VMware management class

N1KV(config-cmap-que)# class-map type queuing match-all REALTIME

N1KV(config-cmap-que)# match cos 5

! Creates the Real-Time class

N1KV(config-cmap-que)# class-map type queuing match-all CONTROL

N1KV(config-cmap-que)# match cos 3

! Creates the Control class

N1KV(config-cmap-que)# class-map type queuing match-all TRANSACTIONAL-DATA

N1KV(config-cmap-que)# match cos 2

! Creates the Transactional Data class

! The second step is to define the queuing policy maps

N1KV(config)# policy-map type queuing 4-CLASS-QUEUING-POLICY

N1KV(config-pmap-que)# class type queuing N1KV-CONTROL

N1KV(config-pmap-c-que)# bandwidth percent 5

! Assigns 5% to the Nexus 1K control class

N1KV(config-pmap-c-que)# class type queuing VMOTION

N1KV(config-pmap-c-que)# bandwidth percent 20

! Assigns 20% to the vMotion class

N1KV(config-pmap-c-que)# class type queuing VMW-CONTROL

N1KV(config-pmap-c-que)# bandwidth percent 5

! Assigns 5% to the VMware Management class

N1KV(config-pmap-c-que)# class type queuing REALTIME

N1KV(config-pmap-c-que)# bandwidth percent 10

! Assigns 10% to the Real-Time class

N1KV(config-pmap-c-que)# class type queuing CONTROL

N1KV(config-pmap-c-que)# bandwidth percent 5

! Assigns 5% to Control

N1KV(config-pmap-c-que)# class type queuing TRANSACTIONAL-DATA

N1KV(config-pmap-c-que)# bandwidth percent 35

! Assigns BW to the Transactional Data class, leaving 20% for default

! The final step is to attach the policy to the uplink port profile

N1KV(config)# port-profile type ethernet UPLINK

N1KV(config-port-prof)# service-policy output 4-CLASS-QUEUING-POLICY

你可以使用以下命令来检查例23-12中的配置。

■ show class-map [ type queuing ]

■ show policy-map [ type queuing ]

■ show port-profile name

■ show policy-map interface

在使用Nexus 1000V 时，还可以查看每个VEM 上的队列行为。首先使用以下命令检查是否在VEM上正确配置了队列:

module vem [module-number] execute vemcmd show qos node

这条命令的输出内容中列出了所有管理员定义的流量类别，每个流量类拥有唯一的识别符（称为NodeID）。例23-13给出了这条命令的输出内容。

例23-13 显示VEM上配置的队列

还可以使用以下命令检查模块上行链路的出方向上匹配的流量类别:

module vem [module-number] execute vemcmd show qos pinst [uplink LTL]

注释:LTL是本地识别符，与每个接口相关。例23-14检查VEM4上的上行链路接口Ethernet 1（以太网接口4/1）。可以使用以下命令事先为每个接口定义LTL:

module vem [module-number] execute vemcmd show port

例23-14的命令输出内容中列出了Egress_q类（出向队列）中定义的所有流量类别。type（类别）号码对应流量类的NodeID，可以与例23-13中的输出内容相对应。比如本例中Egress_q类别2表示vMotion协议。

例23-14 显示VEM上所有队列的数据包和字节数

N1KV# module vem 4 execute vemcmd show qos pinst 17

id　　type

-------- --------

17 Egress_q

class　　bytes matched　　pkts matched

-------- -------------------- --------------------

1　　　　342342　　　　　684

2　　　144903523　　　　85803

3　　　　2223112　　　　3028

4　　　43223340　　　　13543

5　　　　223234　　　　　463

6　　　23423223　　　　8545

23.4.2 8类出向队列模型

8类QoS模型是由4类模型扩展而来，增加了多媒体会议和多媒体流，并将控制流分为两个新的类别:信令控制和网络控制。因为数据中心是一个可控的环境，因此在典型的8类模型中并没有其他网络中常用的清道夫类别。因此在数据中心网络中，8类模型实际只需要支持7个类别。

与4类模型相同，使用3个系统类别来支持Nexus 1000V控制、VMware控制和vMotion。因此把所有类别加在一起，再加上默认类别，这个模型总共有10个类别（8类模型中的7个类别加上3个控制类别）。

图23-4展示了这10个类别以及与它们相关联的DSCP标记和CoS标记。

图23-4 在Nexus 1000V上部署8类出向队列模型

这里有一点需要注意:尽管多媒体流在这里被标记为DSCPAF31，但建议将其标记为CoS 4（根据最高的3 位二进制数值，AF31 默认映射为CoS 3）。如果将多媒体流标记为CoS 3，那它最终会被放入与FCoE流量相同的类别中。由于多媒体流往往会消耗大量带宽，因此最好在上游交换机上，将其与FCoE流量区分对待。

实际的数据中心网络中可能并没有实时语音或视频流量，因此可以将这两个类别进行重新分配。例23-15给出了启用这个QoS模型的所需步骤。

例23-15 在Nexus 1000V上配置8类QoS模型

! The first step is to create the class maps

N1KV(config)# class-map type queuing match-any N1KV-CONTROL

N1KV(config-cmap-que)# match protocol n1k_control

N1KV(config-cmap-que)# match protocol n1k_packet

N1KV(config-cmap-que)# match protocol n1k_mgmt

! Combine the three N1K control protocols into a single class

N1KV(config-cmap-que)# class-map type queuing match-all VMOTION

N1KV(config-cmap-que)# match protocol vmw_vmotion

! Configures the VMware vMotion class

N1KV(config-cmap-que)# class-map type queuing match-all VMW-CONTROL

N1KV(config-cmap-que)# match protocol vmw_mgmt

! Configures the VMware management class

N1KV(config-cmap-que)# class-map type queuing match-all NETWORK-CONTROL

N1KV(config-cmap-que)# match cos 6

! Creates the Control class

N1KV(config-cmap-que)# class-map type queuing match-all VOICE

N1KV(config-cmap-que)# match cos 5

! Creates the Real-Time class

N1KV(config-cmap-que)# class-map type queuing match-all MULTIMEDIA-CONFERENCING

N1KV(config-cmap-que)# match cos 4

! Creates the Multimedia Conferencing class

N1KV(config-cmap-que)# class-map type queuing match-all MULTIMEDIA-STREAMING

N1KV(config-cmap-que)# match cos 4

! Creates the Multimedia Streaming class

N1KV(config-cmap-que)# class-map type queuing match-all SIGNALING

N1KV(config-cmap-que)# match cos 3

! Creates the Signaling class

N1KV(config-cmap-que)# class-map type queuing match-all TRANSACTIONAL-DATA

N1KV(config-cmap-que)# match cos 2

! Creates the Transactional Data class

! The second step is to define the queuing policy maps

N1KV(config)# policy-map type queuing 8-CLASS-QUEUING-POLICY

N1KV(config-pmap-que)# class type queuing N1KV-CONTROL

N1KV(config-pmap-c-que)# bandwidth percent 2

! Assigns 2% to the Nexus 1K control class

N1KV(config-pmap-c-que)# class type queuing VMOTION

N1KV(config-pmap-c-que)# bandwidth percent 20

! Assigns 20% to the vMotion class

N1KV(config-pmap-c-que)# class type queuing VMW-CONTROL

N1KV(config-pmap-c-que)# bandwidth percent 3

! Assigns 3% to the VMware Management class

N1KV(config-pmap-c-que)# class type queuing NETWORK-CONTROL

N1KV(config-pmap-c-que)# bandwidth percent 2

! Assigns 2% to the Network Control class

N1KV(config-pmap-c-que)# class type queuing VOICE

N1KV(config-pmap-c-que)# bandwidth percent 5

! Assigns 5% to the Voice class

N1KV(config-pmap-c-que)# class type queuing MULTIMEDIA-CONFERENCING

N1KV(config-pmap-c-que)# bandwidth percent 10

! Assigns 10% to Multimedia Conferencing

N1KV(config-pmap-c-que)# class type queuing MULTIMEDIA-STREAMING

N1KV(config-pmap-c-que)# bandwidth percent 13

! Assigns 13% to Multimedia Streaming

N1KV(config-pmap-c-que)# class type queuing SIGNALING

N1KV(config-pmap-c-que)# bandwidth percent 5

! Assigns 5% to Signaling

N1KV(config-pmap-c-que)# class type queuing TRANSACTIONAL-DATA

N1KV(config-pmap-c-que)# bandwidth percent 25

! Assigns 25% of BW to the Transactional Data class

! The final step is to attach the policy to the uplink port profile

N1KV(config)# port-profile type ethernet UPLINK

N1KV(config-port-prof)# service-policy output 8-CLASS-QUEUING-POLICY

你可以使用以下命令来检查例23-15中的配置。

■ show class-map [ type queuing ]

■ show policy-map [ type queuing ]

■ show port-profile name

■ show policy-map interface

■ module vem[ module-number ] execute vemcmd show qos node

■ module vem[ module-number ] execute vemcmd show qospinst[ uplink LTL ]

23.5 小结

本章着重介绍虚拟接入层的QoS 设计，使用的设备是Nexus 1000V 交换平台。本章一开始先讨论了多功能交换平台的需求，该平台位于虚拟控制层。并且有针对性地介绍了Nexus1000V，它可以提供一系列网络特性，尤其是在数据中心网络中实施一致的QoS设计策略的各种工具。市场上还有其他VM虚拟控制层环境，但本章只讨论VMware环境。

本章介绍了Nexus 1000V 系统的体系结构，并且详细介绍了VSM 控制模块和VEM 交换模块之间的联系。本章还讨论了Nexus 1000V如何与VM、虚拟控制层和物理上行链路进行互动。

接着给出了一些Nexus 1000V的配置，尤其强调了它与其他NX-OS交换机之间细微的差别。考虑到Nexus 1000V 在虚拟接入层所充当的角色，本章还讨论了一些特性上的区别，尤其是该平台是基于软件的，而无需依赖于硬件ASIC来提供交换和队列。

本章在介绍入向QoS模型时提到了各种信任模型。由于数据中心内的服务器通常是受信任的，因此介绍了如何信任入站DSCP标记，并将其映射为相应的CoS值，以便在出向队列中使用。在介绍分类和重新标记设计时提到了如何使用双速三色限速器。

最后介绍了出向队列设计，Nexus 1000V 有8 个预设的队列类别，分别用于各种控制和管理功能，以及用于vMotion。详细介绍了4类和8类出向QoS模型，其中包括如何将Nexus 1000V和VMware控制类别，以及vMotion流量合并到这些队列模型中。

23.6 扩展阅读

Nexus 1000V QoS主页:http://www.cisco.com/go/nexus1000

对比Nexus 1000V和VMwar虚拟交换机:http://www.vmware.com/files/pdf/technology/cisco_vmware_virtualizing_the_datacenter.pdf

Nexus 1000V 部署ss 指南:http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9902/guide_c07-556626.html

Nexus 1000V QoS配置指南:http://www.cisco.com/en/US/products/ps9902/products_installation_and_configuration_guides_list.html

第24章 数据中心接入层/汇聚层（Nexus 5500/2000）的QoS设计

在当今的虚拟化数据中心网络中，网络的边界变得越来越模糊。比如虚拟服务器系统（比如VMware和Hyper-V）可以将网络边界——从而将QoS信任边界——设置在VM的虚拟控制层内。随着信任边界扩展到虚拟控制层，传统的数据中心接入/汇聚交换机需要扮演更多的角色。

举例来说，在作为接入层交换机使用时，交换机必须为数据中心建立信任边界，并且可能需要重新标记不受信任的流量。在提供第2层汇聚功能时，交换机必须在信任DSCP标记和CoS标记的同时，通过队列机制来管理数据包丢失。

本章中介绍的Nexus 5500家族交换机扮演两个角色:数据中心接入交换机和汇聚交换机， Nexus 2000 FEX（矩阵扩展）模块只扮演服务器接入交换机的角色。

图24-1 描绘了Nexus 5500 和Nexus 2000 上与接口相关的QoS 角色。从图中可以看出，数据中心网络中的第2层接入交换机除了会信任源自服务器的流量外，通常还会信任从网络外传输进来的流量。信任边界可以建立在这一层，同时在这里也可以实施DSCP标记，但在多数案例中，服务器应该能够正确地标记自己的应用流量，这样一来交换机只要信任标记，并相应地对流量进行分类即可。

如图24-1所示，每个Nexus数据中心接入和汇聚平台都根据流量的属性来对流量实施分类和队列。

注释:尽管Nexus 7000上也支持Nexus 2000 FEX，但Nexus 2000 FEX将在本章进行详细介绍，第25章不涉及这部分内容。

由于Nexus 5500 可以在数据中心内充当各种角色，因此它的QoS 能力也必须能够适应数据中心内的多种角色。让我们先来看看Nexus 5500 的体系结构，然后再讨论如何在这个平台的NX-OS中配置QoS策略。

图24-1 数据中心接入/汇聚层接口QoS角色

24.1 Cisco Nexus 5500系统体系结构

Nexus 5500 支持一组新的QoS 能力集合，旨在基于每个系统类别提供流量控制。这些新特性包含以下内容。

■ 无损以太网:优先级流控制（IEEE 802.1Qbb）。

■ 流量保护:带宽管理（IEEE 802.1Qaz）。

■ 为端点配置信令:DCBX（IEEE 802.1Qaz 的一部分）。

为了更好地理解这些特性是如何工作的，先来了解一下Nexus 5500 的硬件体系结构。

24.1.1 体系结构概述

Nexus 5500 系列建立在以下三层交换矩阵上:

■ 入向UPC（统一接口控制器）；

■ 交叉矩阵；

■ 出向UPC。

每个UPC负责一个接口组（即8个1/10GE接口）的流量管理工作，其中包括数据包的缓存、交叉矩阵的仲裁和提供与接口相关特性的主机。图24-2高度概述了Nexus 5500的体系结构，并描绘了入向和出向UPC 与交叉矩阵的连接方式。与其他Cisco 交换平台一样，Nexus 5000和Nexus 5500 家族在硬件ASIC 中完成所有数据包处理工作——也就是说控制层面CPU 并不会直接管理数据包。

注释:当前的Nexus 5500交换机与旧版本的Nexus 5010和5020交换机相比，有些核心QoS特性有所不同，本章着重介绍Nexus 5500家族，因此本章介绍的很多特性并无法在旧版本的5010和5020交换机上应用。

图24-2 Nexus 5500系统体系结构

从QoS的角度看来，所有分类、标记、队列、限速和其他流量管理特性都是在硬件中完成的——在入向UPC、交叉矩阵或出向UPC 中完成。当你开始考虑如何在Nexus 5500 中实际配置QoS，你会发现上述事实开始变得有趣了。

Nexus 5500 支持下列类型的QoS 策略。

■ qos:定义MQC对象，实现标记和限速。

■ network-qos:定义全网范围内的QoS属性特征（比如用于DCB网络的QoS属性），应该在网络中所有交换机上实施一致的QoS属性。

■ queuing:定义MQC对象，实现队列和调度机制，以及一部分标记对象。

■ control-plane:定义MQC对象，实现CoPP（控制层面限速）。

qos、network-qos和queuing类型的策略与交换矩阵中的三个层级相关，详见图24-2。举例来说，qos类型的策略可以应用在入向接口（实际在入向UPC上进行处理）或应用在系统（交叉矩阵）上。network-qos类型的策略只能应用在系统上——交叉矩阵。queuing类型的策略可以应用在入向接口（入向UPC）、出向接口（出向UPC）或系统（交叉矩阵）上。

24.1.2 虚拟输出队列

Nexus 5500 体系结构中与QoS 相关的最重要的一个方面是:它是建立在VOQ（虚拟输出队列）架构上的。从本书前文内容中你可能已经意识到了，每个Cisco交换平台的建立方式都不同。交换机的体系结构往往能够反映出交换机在网络中的用途，以及交换机在网络中有可能遭遇的拥塞情况。比如Catalyst 4500（主要用于园区网接入和汇聚交换机）使用基于出向的队列设计，数据包进入交换机并在传输前，在出方向上排入队列；为了支持这种结构，Catalyst 4500的线卡能够支持大出向缓存。

Nexus 5500 在缓存中排列数据包的方法与此不同。它不是将数据包在大出向缓存中排队，它的出向接口会反向告知入向接口，现在发生了拥塞。因此它并不是在出向接口存储和缓存数据包，而是在向拥塞接口发送流量的入向接口缓存数据包。要知道在多数数据中心的设计中，通常是多个入向服务器接入接口向少量——或一个——出向接口传输流量（这就是聚播流量模式），上述模型适用于这种流量模式。

尽管Nexus 5500 接口的缓存相对较小（只有640 KB），VOQ 可以有效地吸收数据中心内拥塞点的流量负载。举例来说，基于出向的队列结构（比如Catalyst 6500）要求每个出向接口都拥有大量缓存空间，但仍有可能在数据包经过背板的传输之后，丢弃数据包。但在VOQ结构中，实施大量分布的缓存池来管理拥塞，并在背板传输数据之前，丢弃过多的流量。

用数学方法计算一下看看，出向接口的总可用队列大小等于入向接口的总数量乘以每个接口队列的深度。举例来说，假设有10个服务器接口将这些汇聚流量发往单条上行链路。不依赖于单一的上行链路接口来缓存如此庞大的流量负载，而是在10个入向接口上添加缓存空间，就可以获得10 倍于单条上行链路的缓存空间，也就是拥塞接口的缓存空间变为10×640 KB =6.4 MB。

统计数据表明，VOQ与共享缓存架构提供了相同的好处。

图24-3描绘了一个案例场景，3个入向接口向单个出向接口发送数据包，同时出向接口遭遇了拥塞。数据包会被缓存在入向接口的缓存中，直到出向队列空闲出来。

注释:Nexus 7000 M系列和F系列模块也使用VOQ体系结构，第25章将进行详细介绍。

图24-3 Nexus 5500虚拟输出队列

Nexus 5500 使用8 队列QoS 模型来管理单播流量。因此在Nexus 5500 上，每个入向接口都会为出向接口提供8条虚拟输出队列——每条队列对应一个CoS值。举例来说，若服务器连接在Ethernet接口1/8上，目的地在接口1/20和1/23上；Ethernt接口1/8上使用2条VOQ，每个出向接口一条。NX-OS支持的每个/所有入向接口共1024条入向VOQ（8个类别 ×128 个目的地= 1024）。

注释:128 个目的地是这样计算出来的:Nexus 5596 有96 个以太网接口，以及2 个可选的第3层子卡（Daughter Card），每个子卡与交叉矩阵之间有16条连接，因此96 + 16 + 16 =128。

VOQ 系统的管理是由集中仲裁（Centralized Arbitration）进行处理的。集中仲裁负责管理每个接口上的队列，并将入向接口上的数据包接入交叉矩阵，从而创建去往出向接口的交换路径。举例来说，图24-3所示案例中出向接口上的队列0排满了，但其他7条队列未遭遇拥塞。集中仲裁能够感知这种情形，并告知3个发送接口，在入方向上缓存流量，直到拥塞清除为止。

使用这种方法时，基于每个CoS进行VOQ集中仲裁，避免了HoL阻塞的情况。举例来说，若一个特定的CoS值在其目的地出向接口遭遇了拥塞，集中仲裁会告知入向接口，在这个CoS的VOQ中排列流量，并不影响标记着其他CoS的流量传输到矩阵。其他CoS值仍会经由它们各自的VOQ，接入到矩阵中。

支持VOQ 的平台（比如Nexus 5500 和Nexus 7000 线卡）拥有一个独特的概念，如果拥塞程度达到了需要丢弃数据包的程度，它们会在入向接口丢弃数据包，而不是在出向接口丢弃。这是一种思考模式的转变，尤其当你已习惯于设备在出向接口丢弃数据包，比如Catalyst交换家族。

你可以使用命令show queuing interface ethernet x/y 查看Nexus 5500 上的丢包情况。例24-1 展示了如何查看Nexus 5500 上入向数据包的丢弃情况。

例24-1 查看Nexus 5500上的丢包情况

N5K# show queuing interface ethernet 1/22

Interface Ethernet1/39 TX Queuing

qos-group　sched-type　oper-bandwidth

0　　WRR　　　50

1　　WRR　　　50

Interface Ethernet1/22 RX Queuing

qos-group　0

q-size:243200, HW MTU:1600 (1500 configured)

drop-type:drop, xon:0, xoff:1520

Statistics:

Pkts received over the port　　　:85257

Ucast pkts sent to the cross-bar　　:930

Mcast pkts sent to the cross-bar　　:84327

Ucast pkts received from the cross-bar　:249

Pkts sent to the port　　　　　:133878

Pkts discarded on ingress　　　　:543

Per-priority-pause status　　　　:Rx (Inactive), Tx

从例24-1中可以看出，数据包是在入方向上丢弃的，而不是在出方向上丢弃。数据包会被丢弃是因为出向接口遭遇了拥塞。这次拥塞导致入向VOQ中堆积了过多数据包，因此UPC强制丢弃多出的数据包。

24.1.3 QoS组和系统类别

在多数IOS 平台中，policy map 是应用在接口上的。但在NX-OS 中，policy map 还可以直接应用在系统本身；这时需要使用system qos 类型的MQC 对象。从体系结构的角度看来，system qos 对象就是交叉矩阵本身。你可以使用service-policy 语句将policy map 关联到system qos 对象上。system qos 策略会应用到交换机的所有接口，除非接口上配置了更具体的service policy。system qos 策略中定义了系统类别、穿越整个交换机的流量类别及其属性。

为了确保QoS 的一致性（同时为了简化配置），交换机使用DCBX 协议，将system qos参数分发到所有与其相连的CNA。

若接口上配置了service policy，接口上的策略总是优先于系统类别中的配置或默认策略。

在Cisco Nexus 5500系列交换机上，每个系统类别是通过qos group（QoS组）唯一标识的，总共支持6个系统类别。类别0为默认类别，其他5个系统类别（类别1～5）可以由管理员创建，并将其分配给不同类型的流量。若使用了FCoE，为FCoE流量预留的类别是1，其余4个类别可以自定义。

默认的系统类别如下所述。

■ 丢弃系统类别:默认情况下，软件会将所有单播和组播以太网流量分类到默认的丢弃系统类别中。这个类别识别为QoS组0。这个类别是在系统启动时自动创建的（在CLI中，这个类别名为class-default）。你可以删除这个类别，或者更改默认类别中的匹配条件。这个类别也是所有流量的默认类别（class-default），所有未匹配其他类别的流量最终都属于QoS组0。

■ FCoE系统类别:所有FC和FCoE的控制和数据流量都自动被分类到FCoE系统类别中，这个类别提供无损服务。这个类别是在FCoE特性启用时自动创建的（在CLI中，这个类别名为class-fcoe）。与丢弃系统类别一样，你可以删除这个类别，或者修改这个类别中关联的CoS值。这个类别总被标识为QoS组1。

■ 网间控制:这个类别是内建在系统中的，并且不能被删除。它负责SNMP流量和路由协议流量等。网间控制流量被标记为CoS 6。

■ 网络控制:这个类别也是内建在系统中的，并且不能被删除。它负责与Nexus 2000FEX 通信的流量等。网络控制类流量被标记为CoS 6。

注释:在旧版本的Nexus 5010 和5020 交换机中，FCoE流量默认被分类到QoS 组1 中，并且为它分配50%的可用带宽。但在Nexus 5500系列中，这个类别只在启用了FCoE特性后，才会自动创建。

例24-2展示了网络管理员可以配置的QoS组。要注意QoS组0无法配置，因为这是预留的系统丢弃类别。

例24-2 设置qos-group值

N5K(config-pmap-c-qos)# set qos-group ?

<1-5> QoS-group value

在Nexus 5500 中，QoS 组的真正作用是什么？QoS 组其实是用来识别流量的内部标签，以便不同的QoS机制可以正确地管理流量。管理员可以在这些QoS组中配置不同的QoS特征，然后将QoS应用到队列中。

QoS组本质上是一组特征，用来在系统内部处理流量。用来定义QoS组的属性包括（针对流量类定义的）MTU、组中的流量带宽和CoS值。首先使用QoS class map来匹配流量模式，然后根据policy map 中的定义，为与之相匹配的流量赋予相应QoS 组的属性。每个QoS 组中的特征是通过network-qos 类型的policy map 进行配置的，具体配置见本章配置部分。

在Nexus 5500中，没有默认的CoS或DSCP到QoS组的映射关系（除了启用feature fcoe后， FCoE流量的CoS 3会被映射到QoS组1）。在NX-OS中，CoS或DSCP值是映射到QoS组的，不是直接映射到队列。

要知道在没有指定策略时，交换机的默认行为是将所有流量都分类到QoS组0（默认类别）中。除此之外，由于NX-OS 默认是根据CoS 值来分类流量的，因此所有未标记802.1p CoS 值的数据帧都会被分类到默认的丢弃系统类别中。如果直连服务器没有使用802.1p Trunk，这就会带来一些问题，因为这意味着数据包不会携带CoS值。有一些方法可以解决这个问题，比如设置一个匹配所有入站DSCP值的分类策略，或者使用ACL设置一个分类策略。

与其他Cisco交换平台相同，尽量依据DSCP值来分类流量。

接下来详细介绍这些配置的组成部分。

24.1.4 QoS设计步骤

在NX-OS中，QoS是默认启用的；事实上，甚至无法禁用QoS。所有Nexus交换平台上都广泛使用MQC框架，几乎所有QoS配置都是通过MQC完成的。甚至系统级别和接口级别的QoS特性都是通过MQC启用的。这种方法带来的一个好处是:不用在每个接口重复配置相同的配置命令，因为所有特性都是通过policy map 应用的，管理员只需将policy map 关联到接口或系统即可。

在数据中心网络中，将Nexus 5500 作为接入/ 汇聚交换机，可以按照以下步骤配置QoS。

1.配置入向QoS模型，其中包括以下内容:

a.信任模型；

b.分类和标记模型；

c.入向限速模型。

2.配置出向/VOQ队列模型。

3.配置QoS来支持可选设计。

接下来详细介绍这些配置步骤。

24.2 入向QoS模型

入向QoS模型包含以下内容:

■ 信任；

■ 分类和标记；

■ 限速（可选）。

下面按顺序介绍这些入向QoS模型。

24.2.1 信任模型

与多数接入网络不同，数据中心网络中的接入接口（连接服务器的接口）通常是受信任的。当建立新的服务器或动态生成新的VM时，我们希望服务器上的应用能够将其流量标记上正确的DSCP值。这样就可以直接建立信任关系了。但有时候应用并不会为其流量标记DSCP值或CoS值，或者它使用的标记方法与数据中心内的战略QoS模型不一致。

本章会介绍受信任的QoS服务器模型的配置，同时也会介绍不受信任的QoS服务器模型的配置。

1.受信任的服务器模型

默认情况下，所有Ethernet接口都是受信任的。也就是说流量携带的DSCP值和CoS值会得到保留，除非明确配置了重新标记QoS值的策略。因此，如果服务器是受信任的，就不用明确实施任何配置。

2.不受信任的服务器模型

当服务器不受信任时，管理员需要将QoS标记重设为0，以确保将这台服务器的所有流量分类到默认类别中。以Nexus 5500 为例，用NX-OS 术语描述，就是将所有从不受信任的服务器发来的流量映射到QoS组0中，并且不管原始数据包中的QoS标记是什么，都将其重新标记为DSCP 0。

在这种情形下，最终目的就是匹配所有流量。也就是说就算没有使用具体的class map，所有流量也会落入class-default类别中。class-default的默认行为是将所有与其匹配的流量分配到QoS组0中，这也正是我们希望的结果。因为class-default总是存在的，因此无需创建新的class map。例24-3 展示了如何创建qos 类型的policy map，并使用class-default 将所有入站流量重新标记为DSCP 0，并将其分配到QoS 组0 中。

例24-3 为不受信任的服务器配置policy-map

N5K(config)# policy-map type qos NO-TRUST

N5K(config-pmap-qos)# class type qos class-default

N5K(config-pmap-c-qos)# set dscp 0

! For matched traffic (all traffic), the DSCP is to 0

在使用qos 类型的policy map 时，无法重新标记CoS 值（这些CoS 值用于内部队列）。network-qos 类型的policy map 可以设置/ 重新设置CoS 值。

下一个配置步骤是将QoS 策略应用到一个对象上。Nexus 5500 允许将QoS 策略应用到系统类别上，也可以应用到一组接口上；前者能够对所有接口生效。例24-4展示了如何应用qos类型的策略。

例24-4 将QoS类型的policy-map关联到不同的对象

! This section applies the NO-TRUST policy to the system (globally)

N5K(config)# system qos

! This command enables system qos (global) configuration mode

N5K(config-sys-qos)# service-policy type qos input NO-TRUST

! Applies the NO-TRUST policy globally

! This section applies the NO-TRUST policy to an interface

N5K(config)# interface ethernet 1/1-15

N5K(config-if-range)# service-policy type qos input NO-TRUST

ERROR:policy already attached at system level

! This is a redundant configuration and is prevented in NX-OS

例24-4先展示了如何将qos类型的策略关联到整个系统类别中，接着展示了如何将它关联到一组接口上。从例24-4中可以看出，将qos策略关联到系统后，NX-OS就不允许你再将它关联到一组接口了（因为这是重复配置）。你还可以把qos类型的策略应用到VLAN上，但本例没有给出相应配置。

有一点很重要，若在Nexus 5500 上配置了多个不同的qos 策略，那么接口级别policy map的优先级总是高于system qos 类型的policy map。

你可以使用以下命令来检查policy map。

■ show policy-map [ name ]（详见例24-5）

■ show policy-map interface Ethernet x/y（详见例24-6）

例24-5 检查policy-map

N5K# show policy-map NO-TRUST

Type qos policy-maps

====================

policy-map type qos NO-TRUST

class type qos class-default

set qos-group 0

set dscp 0

! Note how the QoS group is set to zero by the default class map

例24-6 检查接口policy map

N5K# show policy-map interface ethernet1/13

Global statistics status:disabled

Ethernet1/13

Service-policy (qos) input:NO-TRUST

policy statistics status:disabled

Class-map (qos):class-default (match-any)

Match:any

set qos-group 0

set dscp 0

24.2.2 分类和标记模型

Nexus 5500 上的分类工作是在入向接口完成的，它可以根据多种度量值来执行分类；然后它会使用CoS，将分类后的流量映射到每个接口的8 条VOQ 中。Nexus 5500 将CoS 6 预留为网间控制，将CoS 7 预留为穿越FEX 的控制流量。若系统上启用了FCoE，它将使用CoS 3。

表24-1总结了系统中使用的8个CoS值。

表24-1 Nexus 5500中的CoS值

与其他流量类型不同，FCoE 只存在于数据链路层，也就是说IP DSCP 值无法与FCoE 流量相关联。在Nexus 产品线中，FCoE 流量是根据CoS 3 进行识别和分类的。

注释:Nexus 5000可以根据以太类型（Ethertype）来识别FCoE流量。但出于QoS分类的目的，只使用CoS值来进行识别。Nexus 7000可以在QoS策略中，使用以太类型或CoS来分类FCoE流量。

在Nexus 5548中使用基于CoS的分类时要小心谨慎，因为信令流量（默认）也使用CoS 3。如果将信令流量与FCoE 分为相同的类别（因为都使用了CoS 3），那么信令将被当作FCoE流量进行处理，并最终获得无损服务。为了将这两种应用区分开，使无损队列专门为FCoE提供服务，最好根据DSCP值进行流量分类，本章接下来的案例将使用这种分类模型。但如果Nexus 5500 中没有启用FCoE，那么就可以将CoS 3 指定给其他应用，比如信令流量。

接下来看看如何将服务器应用流量分类为不同的QoS组，以便为其提供不同级别的服务。

1.单应用服务器模型

单应用服务器模型与不受信任的服务器模型类似，只有以下两点区别:

■ 所有流量都被标记为非零的DSCP值；

■ 不能使用class-default，因为这个类别只对应Nexus 5500 中的丢弃类别（这个类别的QoS组会自动被设置为0）。

举例来说，假设一个服务器上运行着基于Web的CRM（客户关系管理）应用（被分类为业务性数据）。这种流量对应着DSCP AF21 和CoS 2。因为所有入站数据都是同一种类型，因此使用匹配子网的ACL，就可以正确地分类流量，并将流量分类到自定义QoS组中。

尽管使用class-default来管理单应用服务器流量看似没有什么问题，但却会带来一些限制，最主要的是这个类别的丢包率高于其他类别。而且管理员无法更改class-default所关联的QoS组，也就是说它总是被分配给QoS组0和CoS 0。若需要应用任何特殊的QoS处理行为，或者交换机上连接了不同类型的应用服务器，就应该把每种类型的流量映射到它们各自的QoS组中。

在例24-7 中，使用IP ACL 匹配从服务器发出的流量，这个ACL 非常具体。你还可以使用ACL 匹配所有流量（permit ip any any），但若在系统类别上应用policy map，这种匹配方式的灵活性就降低了。

例24-7 配置QoSclass-map

N5K(config)# ip access-list CRM-SERVER

N5K(config-acl)# permit ip 50.1.1.0/24 any

! Define an ACL to match traffic

N5K(config)# class-map type qos CRM-CLASS

N5K(config-cmap-qos)# match access-group name CRM-SERVER

! Use the ACL as the match criteria

下一步是将匹配流量分配到指定QoS组中。这里没有硬性规定必须将某种类型的流量分配到哪个QoS组，只要记得只能够使用5个自定义组（组1～5）就可以了。在本章稍后的出向队列模型部分，将会介绍如何将4类和8类通用QoS模型映射到5个QoS组中。

注释:管理员可以配置的QoS组数量取决于是否启用了FCoE。若启用了，则只能使用组2～5。若没有启用，则能够使用组1～5。

例24-8 展示了如何配置policy map，匹配所有源于这些服务器的流量，并将其QoS 组设置为2，将DSCP设置为AF21。

例24-8 配置qos类型的policy map

N5K(config)# policy-map type qos CRM-POLICY

N5K(config-pmap-qos)# class type qos CRM-CLASS

N5K(config-pmap-c-qos)# set qos-group 2

! Map all matched traffic to QoS group 2

N5K(config-pmap-c-qos)# set dscp af21

! Set the DSCP value to AF21

这时，建议你检查一下qos 类型的class map 和policy map 的配置是否正确，可以使用以下命令:

■ show class-map type qos

■ show policy-map type qos

例24-9给出了这些命令的输出内容。

例24-9 检查qos类型的class map和policy map的配置

N5K# show class-map type qos

Type qos class-maps

===================

class-map type qos match-all CRM-CLASS

match access-group name CRM-SERVER

class-map type qos match-any class-fcoe

match cos 3

class-map type qos match-any class-default

match any

N5K# show policy-map type qos

Type qos policy-maps

====================

policy-map type qos CRM-POLICY

class type qos CRM-CLASS

set qos-group 2

set dscp af21

class type qos class-default

set qos-group 0

policy-map type qos fcoe-default-in-policy

class type qos class-fcoe

set qos-group 1

class type qos class-default

set qos-group 0

从例24-9的命令输出中可以看出，即使并没有进行明确配置，但输出内容中仍列出了class-fcoe。在Nexus 5010 和5020 交换机中，fcoe 类别总是默认就存在，并且总被映射到QoS组1（在启用了FCoE 特性后，这一配置是无法更改的）。在Nexus 5500 系列中，class-fcoe是可选配置，因此在没有启用FCoE特性时，管理员可以将QoS组1用于其他目的。另外，若启用了feature fcoe，那么设备会自动为FCoE 创建qos、network-qos 和queuing 类型的class map，这些信息也会出现在配置输出中。

一旦配置了qos类型的策略，下一步就是将它应用到接口。例24-10显示出如何将policy map应用到一组接口。

例24-10 将qos类型的policy map应用到一组接口

N5K(config)# interface ethernet 1/15-18

N5K(config-if-range)# service-policy type qos input CRM-POLICY

! Attaches the policy map to the range of interfaces

现在，分类和标记的配置已经完成了，下一步是启用流量所属的QoS组。如果忽略了这一步，意味着没有为这个流量类启用队列，QoS也不会生效。在能够使用一个新的QoS组之前，必须先激活并配置这个QoS组。例24-11中展示了这一过程。

例24-11 配置network-qos类型的class map和policy map

! Step 1 – configure the network-qos class map

N5K(config)# class-map type network-qos CLASS-2

N5K(config-cmap-nq)# match qos-group 2

! Match on all traffic mapped to QoS group 2

! Step 2 – configure the network-qos policy map

N5K(config)# policy-map type network-qos NQ-POLICY

N5K(config-pmap-nq)# class type network-qos CLASS-2

! Enable the class – essentially turning on the queue

N5K(config-pmap-nq)# set cos 2

! Manually set the cos value for this class

! Step 3 – attach the policy map to the system class

N5K(config-pmap-nq-c)# system qos

N5K(config-sys-qos)# service-policy type network-qos NQ-POLICY

一旦将某个QoS 组的policy map 应用到系统类别中，这个QoS 组也就被激活了。本例中的policy map 仅仅激活了这个流量类，并设置了CoS 值；但network-qos 类型的policy map 还可以用来设置其他特性，比如设置MTU、入向缓存大小和无丢弃行为等。

需要注意的是，只有在network-qos 类型的policy map 中，才可以设置出向802.1Q 数据帧中的CoS 值。Nexus 5500 并不支持默认的DSCP 到CoS 映射机制，因此必须为自定义队列手动设置CoS 值，否则所有数据帧都将被标记为CoS 0。

你可以使用以下命令来检查例24-11中的配置。

■ show class-map type network-qos

■ show policy-map type network-qos

■ show policy-map [ interface | system ]

2.多应用服务器模型

现在来考虑一下数据中心网络中，一台服务器上运行了多个应用的情况。在本例中，多媒体服务器使用两种类型的流量，这两种流量需要由不同的服务级别提供服务。表24-2总结了Nexus 5500 上的QoS 标记和对应的QoS 组成员。

表24-2 多应用服务器QoS管理案例

例24-12 展示了qos 类型的class map 和policy map 的配置步骤。

例24-12 配置qos类型的class map和policy map

! This section configures the class maps

N5K(config-cmap-qos)# class-map type qos MEDIA-FLOWS

N5K(config-cmap-qos)# match access-group name MEDIA-FLOWS

! Media flows are identified via MEDIA-FLOWS ACL

! (not shown here for simplicity)

N5K(config-cmap-qos)# class-map type qos SIGNALING

N5K(config-cmap-qos)# match access-group name SIGNALING

! Signaling traffic is identified via SIGNALING ACL

N5K(config-cmap-qos)# class-map type qos TRANSACTIONAL-DATA

N5K(config-cmap-qos)# match access-group name TRANSACTIONAL-DATA

! Transactional data is identified via TRANSACTIONAL-DATA ACL

! This section configures the classification and marking policy map

N5K(config-cmap-qos)# policy-map type qos MULTI-APP-SERVER

N5K(config-pmap-qos)# class type qos MEDIA-FLOWS

N5K(config-pmap-c-qos)# set qos-group 4

! Media flows are mapped to QoS group 4

N5K(config-pmap-c-qos)# set dscp af41

! Media flows are marked DSCP AF41

N5K(config-pmap-c-qos)# class type qos SIGNALING

N5K(config-pmap-c-qos)# set qos-group 3

! Signaling traffic is mapped to QoS group 3

N5K(config-pmap-c-qos)# set dscp cs3

! Signaling flows are marked DSCP CS3

N5K(config-pmap-c-qos)# class TRANSACTIONAL-DATA

N5K(config-pmap-c-qos)# set qos-group 2

! Transactional data is mapped to QoS group 2

N5K(config-pmap-c-qos)# set dscp af21

! Transactional data is mapped DSCP AF21

N5K(config-pmap-c-qos)# class type qos class-default

N5K(config-pmap-c-qos)# set dscp 0

! For matched traffic (all traffic), set the DSCP to 0

! This section attaches the policy map to the correct interface

N5K(config)# interface ethernet 1/5

N5K(config-if-range)# service-policy type qos input MULTI-APP-SERVER

! Attaches the marking and QoS group policy to the correct interface

你可以使用以下命令来检查例24-12中的配置。

■ show class-map type qos

■ show policy-map type qos

■ show policy-map interface

与前文案例一样，下一步是配置network-qos类型的class map和policy map，详见例24-13。

例24-13 配置network-qos类型的class map和policy map

! Step 1 – configure the class maps

N5K(config)# class-map type network-qos CLASS-2

N5K(config-cmap-nq)# match qos-group 2

! Matches all traffic in QoS group 2

N5K(config-cmap-nq)# class-map type network-qos CLASS-3

N5K(config-cmap-nq)# match qos-group 3

! Matches all traffic in QoS group 3

N5K(config-cmap-nq)# class-map type network-qos CLASS-4

N5K(config-cmap-nq)# match qos-group 4

! Matches all traffic in QoS group 4

! Step 2 – configure the network-qos policy map

N5K(config)# policy-map type network-qos NQ-POLICY

N5K(config-pmap-nq)# class type network-qos CLASS-2

! Enables CLASS-2

N5K(config-pmap-nq)# class type network-qos CLASS-3

! Enables CLASS-2

N5K(config-pmap-nq)# class type network-qos CLASS-4

! Enables CLASS-4

! Step 3 – attach the policy map to the system class

N5K(config)# system qos

N5K(config-sys-qos)# service-policy type network-qos NQ-POLICY

! Attaches the network-qos policy to the system class

你可以使用下列命令来检查例24-13中的配置。

■ show class-map type network-qos

■ show policy-map network-qos

■ show policy-map system

24.2.3 应用限速服务器模型

有时候需要在接口上配置入向限速器。需要注意的是，在基于IOS的系统中，和在Nexus 7000系列中，都可以在检测到违反规则的流量时，将这些流量重新标记为另一个DSCP值；但Nexus 5500 并不支持这种处理方法。在本书写作时，若流量超出了限速速率，Nexus 5500唯一的做法是丢弃流量。

你可以按照以下步骤来配置入向限速。

1.配置qos 类型的class map。

2.配置qos 类型的policy map 并设置限速选项。

3.将qos 类型的policy map 应用到入向接口。

与IOS 类似，先由class map 匹配流量，再由policy map 对匹配的流量进行限速。但在使用Nexus 5500 时有一个明显的区别:只能在入方向上实施限速，不能在出方向上实施。因为Nexus 5500 使用基于入向的缓存系统，有助于保护上游缓存。

例24-14 给出了配置policy map 来支持入向限速的案例。

例24-14 入向限速policy map

N5K(config)# policy-map type qos POLICE

N5K(config-pmap-qos)# class class-default

! Match traffic in the default-class

N5K(config-pmap-c-qos)# police cir percent 50 bc 20 mbytes conform transmit violate drop

! Police traffic in this class to 50% of bandwidth

N5K(config)# interface ethernet 1/10

N5K(config-if)# service-policy type qos input POLICE-MAP

! Attach the policy map to an interface

在本例中，限速后的流量可使用50% 的可用带宽，承诺突发速率为20 MB/s。本例中的conform（遵守）行为是transmit（传输），violate（违反）行为是drop（丢弃）。

你可以使用以下命令来检查例24-14中的配置。

■ show policy-map [ policy-map-name ]

■ show policy-map interface Ethernet x/y

例24-15给出了检查入向限速器的方法。

例24-15 检查入向policy-map

N5K# show policy-map POLICE

Type qos policy-maps

====================

policy-map type qos POLICE

class type qos CLASS-2

set qos-group 4

police cir percent 15 bc 20 mbytes conform transmit violate drop

class type qos class-default

set qos-group 0

N5K# show policy-map interface ethernet 1/10

Global statistics status:disabled

Ethernet1/10

Service-policy (qos) input:POLICE

policy statistics status:disabled

Class-map (qos):POLICE (match-all)

0 packets

Match:cos 4-6

police cir percent 100 bc 200 ms

conformed 0 bytes, 0 bps action:transmit

violated 0 bytes, 0 bps action:drop

24.2.4 更改入向缓存大小

在默认的QoS 配置中，全部可用的入向缓存（470 KB）都分配给了class-default。当你创建一个新的QoS组时，这个新的QoS组所需的缓存是从class-default中获得的。class-default中所剩的内存可以使用以下公式计算:

■ 470KB –Σ[28.6KB + B] * N

其中:

■ B =管理员为每个流量类别配置的入向缓存大小（详见表24-3）；

■ N =系统中的QoS 组数量。

表24-3总结了系统中默认的入向缓存分配方式（受队列限制）。

表24-3 Nexus 5500上默认的入向缓存分配

通常情况下，队列限制（缓存分配）是由出向队列模型中的带宽分配决定的。换句话说，若一个类别获得了25%的带宽，它也会获得25%的缓存空间。但PQ（优先级队列）的缓存分配比例与此相反，因为PQ用于服务实时流量，需要较少的缓存空间；因此可以将空闲的缓存重新分配给其他低优先级队列，这些队列不会那么频繁地获得服务，这样可以使它们的队列空间大一些。

例24-16展示了如何调整两个类别的输入缓存大小。在本例中，业务性数据类别获得系统范围内的入向缓存大小:85000字节，实时类别获得30000字节。

例24-16 调整入向缓存大小

! Step 1 – Define a QoS class map

N5K(config)# class-map type qos TRANSACTIONAL-DATA

N5K(config-cmap-qos)# match af21

! Transactional Data is matched with AF21

N5K(config-cmap-qos)# class-map type qos REALTIME

N5K(config-cmap-qos)# match dscp ef

! Realtime traffic is matched with EF

! Step 2 – Define a QoS Policy Map

N5K(config)# policy-map type qos POLICY-QOS

N5K(config-pmap-qos)# class type qos TRANSACTIONAL-DATA

N5K(config-pmap-c-qos)# set qos-group 2

! Set transactional data to QoS group 2

N5K(config-pmap-c-qos)# class type qos REALTIME

N5K(config-pmap-c-qos)# set qos-group 5

! Map Realtime traffic to QoS group 5

! Step 3 – Apply the QoS policy map to the system target

N5K(config)# system qos

N5K(config-sys-qos)# service-policy type qos input POLICY-QOS

! Attaches the policy map to the system

! Step 4 – Define a network-qos Class Map

N5K(config)# class-map type network-qos TRANSACTIONAL-DATA

N5K(config-cmap-nq)# match qos-group 2

! Match traffic belonging to QoS group 2 (transactional data)

N5K(config-cmap-nq)# class-map type network-qos REALTIME

N5K(config-cmap-nq)# match qos-group 5

! Match traffic belonging to QoS group 5 (real-time traffic)

! Step 5 – Define a network-qos policy map

N5K(config)# policy-map type network-qos POLICY-NQ

N5K(config-pmap-nq)# class type network-qos TRANSACTIONAL-DATA

N5K(config-pmap-nq-c) queue-limit 85000 bytes

! This is an arbitrary value, for demonstration purposes only

N5K(config-pmap-nq-c)# class type network-qos REALTIME

N5K(config-pmap-nq-c) queue-limit 30000 bytes

! Lower the queue-limit for real-time traffic

! Step 6 – Apply the network-qos policy map to the system target

N5K(config)# system qos

N5K(config-sys-qos)# service-policy type network-qos POLICY-NQ

! Applies the policy map system-wide (to all interfaces)

24.3 出向队列模型

本书一直在提到3 个QoS 参考分类模型:4 类、8 类和12 类模型。但由于Nexus 5500 只支持4条非系统队列（再加上FCoE和默认类别），因此这里只涉及4类和（修改的）8类模型。

接下来的两小节将分别介绍这两个参考模型在出向队列上的用法。

24.3.1 4类模型

Nexus 5000家族支持4条用户定义的队列，再加上一条用于FCoE和一条用于默认的队列，因此很容易将4 类模型整合到这个平台中。图24-4 展示了在Nexus 5500 中，推荐使用的流量类别与QoS组的映射关系。每个QoS组对应一条出向队列。

要记住，QoS组中的成员是可以自定义的，除了QoS组0和组1，这两个组是强制与默认类别和FCoE类别关联的。不过可以尝试着在这种映射机制中引入一些逻辑规则。

注意图24-4实际显示出了7个类别，其中包括4个普通类别和FCoE，以及2个预留类别。FCoE是特殊案例，并且它只存在于数据中心环境中（因为只有主机与SAN[存储区域网络]之间的链路上才会有FC流量）。如果FCoE特性没有启用，最终只有4个类别。

图24-4中展示了3个用户定义的队列和4个系统定义的队列是如何被映射为相应的QoS组的。最上面的两个类别:网间控制和网络控制，分别被识别为CoS 6 和7，这两个是系统预留的队列，用于控制层面的流量类型。举例来说，类别6用于LACP（链路汇聚控制协议）和IGMP（Internet组管理协议）等控制流量。类别7用于FSPF（光纤最短路径优先）、STP（生成树协议）和FEX通信等控制流量。

图24-4 在Nexus 5500上部署4类模型

类别7是严格优先级队列；类别6是DRR队列，占有50%带宽。其余用户定义的队列以DWRR（赤字加权轮循）的方式获得服务。尽管这里一共列出了7 条队列，但Nexus 5500 上实际有8条出向队列。在使用4类模型时，有7条队列就够了，有一条（QoS组4）没有使用。

下面的案例给出了在Nexus 5500 上支持4 类设计模型的配置。QoS 配置可以总结为以下4个步骤。

1.配置qos 类型的class map 和policy map。

2.配置network-qos 类型的class map 和policy map。

3.配置queuing 类型的class map 和policy map。

4.将所有service policy 应用到系统QoS 类别中。

例24-17 展示了qos 类型的class map 和policy map 的配置。

例24-17 配置qos类型的class map和policy map来支持4类QoS模型

! Configure the qos class maps

N5K(config)# class-map type qos match-any REALTIME

N5K(config-cmap-qos)# match dscp ef

! Real-time traffic is matched by DSCP EF

N5K(config-cmap-qos)# class-map type qos match-any CONTROL

N5K(config-cmap-qos)# match dscp cs3

! Control traffic is matched by DSCP CS3

N5K(config-cmap-qos)# class-map type qos match-any TRANSACTIONAL-DATA

N5K(config-cmap-qos)# match dscp af21 af22 af23

! Transactional data is matched by DSCP AF2

! Configure the qos policy map

N5K(config)# policy-map type qos 4-CLASS-QOS-POLICY

N5K(config-pmap-qos)# class REALTIME

N5K(config-pmap-c-qos)# set qos-group 5

! Maps real-time traffic to QoS group 5

N5K(config-pmap-c-qos)# class CONTROL

N5K(config-pmap-c-qos)# set qos-group 3

! Maps control traffic to QoS group 3

N5K(config-pmap-c-qos)# class TRANSACTIONAL-DATA

N5K(config-pmap-c-qos)# set qos-group 2

! Maps transactional data traffic to QoS group 2

N5K(config-pmap-c-qos)# class class-fcoe

N5K(config-pmap-c-qos)# set qos-group 1

! Maps FCoE traffic to QoS group 1

! Note – you don't need to configure a class map for FCoE

注释:从Cisco NX-OS 5.0(2)N1(1)版本开始，在Cisco Nexus 5500家族交换机的配置中有4个预定义的policy map专用于FCoE；必须在系统QoS类别中启用这4个policy map，FCoE QoS才能正常工作。这4个policy map如下所示:

service-policy type qos input fcoe-default-in-policy

service-policy type queuing input fcoe-default-in-policy

service-policy type queuing output fcoe-default-out-policy

service-policy type network-qos fcoe-default-nq-policy

在Nexus 5548 交换机上启用FCoE 之前，必须在全部3 个类型的QoS 策略中启用class-fcoe。

需要注意的是，即使本例中使用了FCoE，也没有为它定义任何class map。当启用了FCoE 特性后，Nexus 5500 不需要明确的class map 就可以自动分类FCoE 流量，因此也就无需配置了。对于network-qos 和queuing 类型的分类步骤也是如此。至于policy map，管理员可以轻松调用为FCoE 流量预定义的class map。

配置了qos 类型的class map 和policy map 后，下一步是配置network-qos 类型的class map 和policy map。

例24-18给出了如何为每种流量类别启用相应的QoS组。

例24-18 配置network-qos类型的class map和policy map来支持4类QoS模型

! Configure the network-qos class maps

N5K(config)# class-map type network-qos REALTIME

N5K(config-cmap-nq)# match qos-group 5

! Matches traffic in QoS group 5

N5K(config-cmap-nq)# class-map type network-qos CONTROL

N5K(config-cmap-nq)# match qos-group 3

! Matches traffic in QoS group 3

N5K(config-cmap-nq)# class-map type network-qos TRANSACTIONAL-DATA

N5K(config-cmap-nq)# match qos-group 2

! Matches traffic in QoS group 2

! Configure the network-qos policy map

N5K(config)# policy-map type network-qos 4-CLASS-NQ-POLICY

N5K(config-pmap-nq)# class type network-qos REALTIME

! Enable the Real-Time class

N5K(config-pmap-nq-c)# class type network-qos CONTROL

! Enable the Control class

N5K(config-pmap-nq-c)# class type network-qos TRANSACTIONAL-DATA

! Enable the Transactional Data class

N5K(config-pmap-nq-c)# class type network-qos class-fcoe

N5K(config-pmap-nq-c)# pause no-drop

N5K(config-pmap-nq-c)# mtu 2158

! This last policy creates a PFC class with the correct MTU for FCoE

注释:在这个策略中，FCoE的MTU被设置为2158字节。要知道虽然FC和FCoE负载的MTU是2112字节，但加上FCoE头部、CRC和EOF字段，总MTU就变成了2158字节。

在配置完qos和network-qos类型的策略后，下一步是为每个流量类别配置队列策略，详见例24-19。

例24-19 配置queuing类型的class map和policy map来支持4类QoS模型

! Configure the queuing class maps

N5K(config-cmap-que)# class-map type queuing TRANSACTIONAL-DATA

N5K(config-cmap-que)# match qos-group 2

! Matches traffic in QoS group 2

N5K(config-cmap-que)# class-map type queuing CONTROL

N5K(config-cmap-que)# match qos-group 3

! Matches traffic in QoS group 3

N5K(config-cmap-que)# class-map type queuing REALTIME

N5K(config-cmap-que)# match qos-group 5

! Matches traffic in QoS group 5

! Configure the queuing policy map

N5K(config)# policy-map type queuing 4-CLASS-GLOBAL-QUEUING-POLICY

N5K(config-pmap-que)# class type queuing REALTIME

N5K(config-pmap-c-que)# priority

! Assign EF traffic to the strict-priority queue

N5K(config-pmap-c-que)# class type queuing CONTROL

N5K(config-pmap-c-que)# bandwidth percent 10

! Assign 10% of bandwidth to control

N5K(config-pmap-c-que)# class type queuing TRANSACTIONAL-DATA

N5K(config-pmap-c-que)# bandwidth percent 35

! Assign 35% of bandwidth to transactional data

N5K(config-pmap-c-que)# class type queuing class-fcoe

N5K(config-pmap-c-que)# bandwidth percent 30

! Here FCoE is given 30% of the available bandwidth

N5K(config-pmap-c-que)# class type queuing class-default

N5K(config-pmap-c-que)# bandwidth percent 25

! Assign 25% of bandwidth to the default queue

在前文案例中，实时流量被分配到严格优先级队列中。在这个平台中，可以只将一个类别分配到PQ 中，然后以DWRR 的方式服务其他所有类别。你会注意到在Nexus 5500 系列中， PQ是无限制队列，也就是对于该队列能够消耗的带宽并无上限。这会为管理员带来一系列顾虑，如果高优先级流量过多，可能会完全“饿死”其他队列。因此必须慎重决定将多少流量映射到这个类别中。

注意在前文案例中，FCoE 类别被明确分配了30% 带宽。默认情况下，Nexus 5500 会为FCoE分配50%可用带宽，因此在这里需要调整这个参数。

最后一个配置步骤是将这三个policy map 应用到系统上。这样做会为Nexus 5500 上的所有接口启用这些策略。例24-20给出了配置步骤。

例24-20 在系统类别中应用QoS策略

N5K(config)# system qos

N5K(config -sys-qos)# service-policy type qos input 4-CLASS-QOS-POLICY

! Attaches the qos policy to the system class

N5K(config -sys-qos)# service-policy type queuing output 4-CLASS-GLOBAL-QUEUING-POLICY

! Attaches the queuing policy on the output direction

N5K(config -sys-qos)# service-policy type network-qos 4-CLASS-NQ-POLICY

! Attaches the network-qos policy map to the system

注意service policy 同时应用在了入向和出向上。应用在入向（input）的队列策略为具有DCBX能力的设备（比如FEX或CNA）定义了ETS队列策略。应用在出向（output）的队列策略激活了VOQ中的调度机制。

你可以使用以下命令来检查例24-20中的配置。

■ show policy-map type [ qos | network-qos | queuing ]

■ show policy-map system

24.3.2 8类模型

尽管Nexus 5500 最多只提供6 条自定义队列（包括FCoE 和默认类别），但它仍旧能够很好地将8类参考模型与你的QoS设计对应起来。为了实现这种模型，你需要做一些配置修改。

图24-5 展示了在Nexus 5500 中实施8 类QoS 参考模型的建议。

假设案例中使用了FCoE，那么只有4条自定义队列可用（QoS组0和组1是预留的，可以使用的是QoS组2～5）。在数据中心网络中，服务器通常是受信任的，还可以假设网络中不存在清道夫流量，因此可以把这个类别从参考模型中删除。网络控制流量自然被映射到系统预留的PQ中。因此为了合理利用4条自定义队列，其余7个类别中需要有某几个类别共用一个QoS组。比较合理的设计是将交互式视频和流媒体视频放入一个共用的QoS组中（详见图24-5中的QoS组4）。

图24-5 在Nexus 5500上部署8类模型

8类模型的QoS配置可以总结为以下4个步骤。

1.配置qos 类型的class map 和policy map。

2.配置network-qos 类型的class map 和policy map。

3.配置queuing 类型的class map 和policy map。

4.将所有service-policy应用到系统QoS类别中。

例24-21 展示了qos 类型的class map 和policy map 的配置。注意本例中定义了5 个class map，因为FCoE 和class default 是预定义在Nexus 的操作系统中的。

例24-21 配置qos类型的class-map和policy-map来支持8类QoS模型

! Configure the qos class maps

N5K(config-cmap-qos)# class-map type qos match-any VOICE

N5K(config-cmap-qos)# match dscp ef

! Match voice traffic with DSCP EF

N5K(config-cmap-qos)# class-map type qos match-any SIGNALING

N5K(config-cmap-qos)# match dscp cs3

! Match signaling traffic with DSCP CS3

N5K(config-cmap-qos)# class-map type qos match-any INTERACTIVE-VIDEO

N5K(config-cmap-qos)# match dscp af41 af42 af43

! Match interactive video traffic with DSCP AF4

N5K(config-cmap-qos)# class-map type qos match-any STREAMING-VIDEO

N5K(config-cmap-qos)# match dscp af31 af32 af33 ! Match streaming video traffic

with DSCP AF3

N5K(config-cmap-qos)# class-map type qos match-any TRANSACTINOAL-DATA

N5K(config-cmap-qos)# match dscp af21 af22 af23

! Match transactional data with DSCP AF2

! Configure the qos policy map

N5K(config)# policy-map type qos 8-CLASS-QOS-POLICY

N5K(config-pmap-qos)# class VOICE

N5K(config-pmap-c-qos)# set qos-group 5

! Map voice traffic to QoS group 5

N5K(config-pmap-c-qos)# class INTERACTIVE-VIDEO

N5K(config-pmap-c-qos)# set qos-group 4

! Map interactive video traffic to QoS group 4

N5K(config-pmap-c-qos)# class STREAMING-VIDEO

N5K(config-pmap-c-qos)# set qos-group 4

! Map streaming video to QoS group 4 (same as INTERACTIVE-VIDEO)

N5K(config-pmap-c-qos)# class SIGNALING

N5K(config-pmap-c-qos)# set qos-group 3

! Map signaling traffic to QoS group 3

N5K(config-pmap-c-qos)# class TRANSACTIONAL-DATA

N5K(config-pmap-c-qos)# set qos-group 2

! Map transactional data to QoS group 2

N5K(config-pmap-c-qos)# class class-fcoe

N5K(config-pmap-c-qos)# set qos-group 1

! Map FCoE to QoS group 1

配置了qos 类型的class map 和policy map 后，下一步是配置network-qos 类型的class map 和policy map。因为只能使用4 个自定义的QoS 组，因此network-qos 类型的class map必须将这些类别中的两个结合在一起。可以将互动式视频和流媒体视频这两个类别结合到一个类别中，可以将这个类别称为Video（视频）。例24-22给出了这些步骤的具体配置。

例24-22 配置network-qos类型的class-map和policy-map来支持8类QoS模型

! Configure the network-qos class maps

N5K(config)# class-map type network-qos VOICE

N5K(config-cmap-nq)# match qos-group 5

! Matches traffic in QoS group 5

N5K(config)# class-map type network-qos VIDEO

N5K(config-cmap-nq)# match qos-group 4

! Matches traffic in QoS group 4

N5K(config)# class-map type network-qos SIGNALING

N5K(config-cmap-nq)# match qos-group 3

! Matches traffic in QoS group 3

! This is the consolidate class for the two video classes

N5K(config)# class-map type network-qos TRANSACTIONAL-DATA

N5K(config-cmap-nq)# match qos-group 2

! Matches traffic in QoS group 2

! Configure the network-qos policy map

N5K(config)# policy-map type network-qos 8-CLASS-NQ-POLICY

N5K(config-pmap-nq)# class type network-qos VOICE

! Activates the Voice network-qos class

N5K(config-pmap-nq-c)# class type network-qos SIGNALING

! Activates the Signaling network-qos class

N5K(config-pmap-nq-c)# class type network-qos VIDEO

! Activates the Video network-qos class

N5K(config-pmap-nq-c)# class type network-qos TRANSACTIONAL-DATA

! Activates the Transactional Data class

N5K(config-pmap-nq-c)# class type network-qos class-fcoe

N5K(config-pmap-nq-c)# pause no-drop

N5K(config-pmap-nq-c)# mtu 2158

! Activates the FCoE class and establishes the class as no-drop

在配置完qos和network-qos类型的策略后，下一步是为每个流量类别配置队列策略，详见例24-23。

例24-23 配置queuing类型的class map和policy map来支持8类QoS模型

! Configure the queuing class maps

N5K(config-cmap-que)# class-map type queuing VOICE

N5K(config-cmap-que)# match qos-group 5

! Matches traffic in QoS group 5

N5K(config-cmap-que)# class-map type queuing VIDEO

N5K(config-cmap-que)# match qos-group 4

! Matches traffic in QoS group 4

N5K(config-cmap-que)# class-map type queuing SIGNALING

N5K(config-cmap-que)# match qos-group 3

! Matches traffic in QoS group 3

N5K(config-cmap-que)# class-map type queuing TRANSACTIONAL-DATA

N5K(config-cmap-que)# match qos-group 2

! Matches traffic in QoS group 2

! Configure the queuing policy map

N5K(config)# policy-map type queuing 8-CLASS-GLOBAL-QUEUING-POLICY

N5K(config-pmap-que)# class type queuing VOICE

N5K(config-pmap-c-que)# priority

! Gives voice the priority queue

N5K(config-pmap-c-que)# class type queuing SIGNALING

N5K(config-pmap-c-que)# bandwidth percent 10

! Signaling is given 10% of available BW

N5K(config-pmap-c-que)# class type queuing VIDEO

N5K(config-pmap-c-que)# bandwidth percent 25

! Video is given 25% of available BW

N5K(config-pmap-c-que)# class type queuing TRANSACTIONAL-DATA

N5K(config-pmap-c-que)# bandwidth percent 20

! Transactional Data is given 20% of available BW

N5K(config-pmap-c-que)# class type queuing class-fcoe

N5K(config-pmap-c-que)# bandwidth percent 20

! FCoE is given 20% of available BW

N5K(config-pmap-c-que)# class type queuing class-default

N5K(config-pmap-c-que)# bandwidth percent 25

! The default class is given 25% of available BW

这里的带宽是随意设置的，只是为了展示都可以配置哪些参数。真实的带宽设置要能反映出数据中心网络中的流量模式。

最后一步是将这些policy map 应用到系统中，详见例24-24。这样做会为Nexus 5500 上所有接口启用该策略。

例24-24 在系统类别中应用QoS策略

N5K(config)# system qos

N5K(config -sys-qos)# service-policy type qos input 8-CLASS-QOS-POLICY

! Attach the qos policy to the system class

N5K(config -sys-qos)# service-policy type queuing output 8-CLASS-GLOBAL-QUEUING-POLICY

! Attach the queuing policy in the output direction

N5K(config -sys-qos)# service-policy type network-qos 8-CLASS-NQ-POLICY

! Attaches the network-qos policy to the system

你可以使用以下命令来检查案例中的配置。

■ show policy-map type [ qos | network-qos | queuing ]

■ show policy-map system

■ show queuing interface ethernet x/y

24.4 更多QoS设计选项

除了刚讨论过的入向和出向队列模型，Nexus 5500 还支持下列重要的QoS 设计元素:

■ 针对L3子卡配置QoS；

■ 在Nexus 2000 FEX 上启用QoS；

■ 为不同流量类别设置MTU。

24.4.1 Nexus 5500 L3 QoS配置

在基本配置中，Nexus 5500 交换机只支持第2 层转发。但通过使用第3 层子卡，交换机就具备了IP路由能力。

使用了第3 层子卡后，要留意几个QoS 设计特征。当Nexus 5500 将L2 数据帧分类后，它会根据已知的QoS信息，来对数据帧执行后续的QoS行为。可一旦将数据帧发送到L3子卡，相应的QoS 信息无法一并发送。与Nexus L2 UPC 支持QoS 类似，L3 子卡需要根据QoS 组来做出QoS决策。因此，所有发送到L3子卡的流量都必须正确标记QoS组，这是通过qos类型的策略进行标记的。

图24-6展示了数据流从UPC去往L3子卡，然后再回到另一个出向UPC。

图24-6 穿越L3子卡的数据流

如图24-6所示，L3转发引擎与Nexus 5500相连，就好像它们是通过16个10GE接口相连的。有可能在两个地方遇到拥塞:流量从UPC去往L3转发引擎的出方向上；以及流量离开L3转发引擎返回UPC时。举例来说，如果流量在去往L3引擎的出方向上发生了拥塞，那么根据数据帧携带的QoS组内部标签，流量会在UPC上进行排队。

为了正确配置与L3子卡相关的QoS设计，你应该遵从以下建议:

■ 在流量路径中，在L3和L2接口上应用qos和network-qos类型的策略，以实现分类（或者只在整个系统中应用服务策略）；

■ 在系统中应用出方向（output）的queuing类型的策略。

24.4.2 Nexus 2000 FEX QoS

Nexus 5500 能够支持Nexus 2000 系列矩阵扩展模块（称为FEX），为面向服务器的接口提供了极大的可扩展性。对于Cisco Nexus父系交换机（包括Nexus 5500和Nexus 7000）来说， Nexus 2000 FEX 就像是远程线卡。FEX 和父系交换机构成了分布式模块交换系统。FEX 完全由父系交换机进行控制，所有配置和软件控制都在父系交换机上完成。

FEX有以下两种类型的接口。

■ FEX主机接口（HIF）:面向服务器的接口。

■ FEX网络接口（NIF）:FEX连接上游父系交换机的接口。

图24-7 描绘了在与Nexus 5500 相连时，FEX 的QoS 机制。

如图24-7所示，FEX的队列和缓存系统以如下的方式工作。

1.根据CoS分类入站流量。

2.在出向NIF上对流量实施排队和调度机制。

3.Nexus 5500入向接口（入向UPC）负责分类流量、分配缓存、检查MTU和标记CoS。

4.流量在Nexus 5500 出向接口（出向UPC）进行排队和调度机制。

5.FEX在入向NIF接口执行基于CoS的分类。

6.FEX在出向HIF接口对流量实施排队和调度机制；HIF为每接口执行出向尾部丢弃。

Nexus 5500 与FEX 的通信中有一点很重要:所有流量都是802.1Q Trunk 的一部分。这意味着5500与FEX上的队列机制（双方向）都依赖于CoS。这一事实强调了必须在network-qos 类型的policy map 中正确地设置CoS 标记。

与普通Nexus 5500 接口所使用的共享入向缓存模型不同，FEX 的运作就像是线卡，意味着出向队列是在线卡上实施的，并且这些出向队列并不是Nexus 5500 上的共享入向缓存系统的一部分。这是因为FEX的运作与基于出向队列机制的设备相同，而这种设备的行为与Nexus 5500不同。

图24-7 Nexus 5500/2000 FEX QoS体系结构

每个FEX都有本地接口缓存，可以调整这些缓存，以防止一个被阻塞的接收方影响到那些发往无拥塞接收方的流量。同样地，将队列限制调高能够更好地应对突发，但会减少对HoL阻塞的保护。

例24-25给出了调整FEX队列限制的案例。

例24-25 调整FEX缓存

N5K(config)# system qos

N5K(config-sys-qos)# no fex queue-limit

! Disabling the per-port tail-drop threshold

N5K(config)# fex 100

N5K(config-fex)# hardware N2248T queue-limit 356000

N5K(config-fex)# hardware N2248T queue-limit ?

<CR>

<2560-652800> Queue limit in bytes

! Changing the FEX queue limit on an HIF port

你可以使用以下命令来检查例24-25中的配置。

■ show fex detail

■ show queuing interface ethernet fex/x/y

FEX队列架构中有趣的一点是:有些FEX模块能够支持整个FEX范围内的共享内存（Shared Memory）缓存，但有些FEX模块只能支持以组为单位（4接口或8接口）的缓存。

表24-4对比了不同FEX的缓存能力。

表24-4 Cisco Nexus 2000 FEX缓存对比

以这种情况为例:Nexus 2248TP-E 连接在Nexus 5548 交换机上。在本例中，数据中心内部署了一台10GE NAS（网络连接式服务器），它向一台1GE服务器发送大量突发数据（Hadoop也是一项能够生成突发流量的技术）。图24-8展示了本例的环境。

图24-8 为突发NAS流量调整Nexus 2248TP-E的缓存

由于2248TP-E FEX 模型使用32 MB 共享内存（Shared Memory）缓存架构，它能够很好地处理大量突发流量。NAS与服务器之间速率的不匹配（10GE与1GE）很明显会导致拥塞，拥塞会发生在FEX 面向服务器的出向接口。因为2248TP-E 在整个FEX 中共享32 MB 缓存，那么这种速率不匹配带来的后果是仅仅为了服务一个出向接口，而占用了整个交换机的缓存空间！这个拥塞接口会影响到所有其他未发生拥塞的接口，因为它消耗的是整个共享的缓存。如果降低了FEX上队列限制的值，很容易可以管理这种HoL阻塞的情况。

例24-26 展示了如何在Nexus 2248TP-E FEX 上降低队列限制。

例24-26 调整Nexus 2248TP-E的缓存

N5K(config)# fex 110

N5K(config-fex)# hardware N2248TPE queue-limit 4000000 rx

N5K(config-fex)# hardware N2248TPE queue-limit 4000000 tx

N5K(config)# interface e110/1/1

N5K(config-if)# hardware N2348TP queue-limit 4096000 tx

! Reduce the queue limit for the server speaking to the NAS

你可以使用以下命令来检查例24-26中的配置。

■ show fex detail

■ show queuing interface ethernet fex/x/y

24.4.3 使用network-qos策略设置MTU

IOS MQC 与NX-OS MQC 的一个主要区别在于:在NX-OS 中，接口级别的特性是配置在policy map 中的。以设置MTU 为例:IOS 是在接口上设置MTU，NX-OS 是在network-qos 类型的策略中设置MTU，然后将其关联到系统对象上。比如当输入了feature fcoe 命令后（即启用FCoE），需要通过network-qos策略为FCoE指定2158字节的MTU，这样才能够正确地传输FCoE流量。

在例24-27中，默认类别中的MTU是为传输巨型数据帧设置的，因此需要将MTU设置为9216字节。

在本例中并没有定义class map，这是因为这个策略调用的是默认类别，这个类别会匹配所有未分类的流量。

例24-27 使用policy map设置MTU

N5K(config)# policy-map type network-qos SET-MTU

N5K(config-pmap-nq)# class type network-qos class-default

N5K(config-pmap-nq-c)# mtu 9216

! Sets the MTU for the default class

N5K(config)# system qos

N5K(config-sys-qos)# service-policy type network-qos SET-MTU

! Attaches the policy to the system QoS class

你可以使用命令show policy-map type network-qos 来检查例24-27 中的配置。

24.5 小结

本章详细介绍了将Nexus 5500 数据中心交换机作为第2 层接入/ 汇聚服务器，甚至作为第3层分布交换机，在其上实施QoS设计的最佳做法建议。

本章先回顾了Nexus 5500 系统的体系结构，尤其是VOQ 架构。这一机制利用共享内存模型和虚拟输出队列，在入方向上缓存数据包。因为Nexus 5500使用内部CoS值进行流量分类，因此也展示了如何将8个CoS值用于系统中的VOQ。

接着介绍了入向QoS模型，其中包括各种信任和标记机制。为了将这些QoS策略应用到系统中，本章还分析了三种类型的class map 和policy map。

在这之后介绍了出向队列模型，其中包括如何在Nexus 5500 平台上配置出向队列。该平台支持4 类和8 类QoS 模型。由于Nexus 5500 预留了2 个CoS 值（6 和7），本章还展示了如何使用4个自定义QoS类别来实施8类QoS模型，同时还要支持FCoE类。由于Nexus 5500仅支持4个（如果不使用FCoE的话就是5个）自定义QoS类别，因此它不支持12类QoS模型。

最后介绍了其他QoS 选项，其中包括如何设计并配置L3 子卡、Nexus 2000 FEX，以及如何调整指定流量类的MTU。

24.6 扩展阅读

Nexus 5500 QoS配置指南，NX-OS 6.0(2)N1(2)版本:http://www.cisco.com/en/US/docs/switches/datacenter/nexus5500/sw/qos/602_N1_2/b_5500_QoS_Config_602N12.html

Nexus 5500 L3子卡配置:http://www.cisco.com/en/US/docs/switches/datacenter/nexus5500/sw/unicast/ 602_N1_2/cisco_n5500_layer3_ucast_cfg_rel_602_N1_2.html

NX-OS and Cisco Nexus Switching:Next Generation Data Center Architectures, Second Edition，Fuller, Jansen, McPherson 著（2013 年Cisco Press 出版）

数据中心配置文件——智能商务体系结构:http://www.cisco.com/en/US/docs/solutions/SBA/February2013/Cisco_SBA_DC_DataCenterConfigurationFilesGuide-Feb2013.pdf

第25章 数据中心核心层（Nexus 7000）的QoS设计

数据中心核心交换机的首要QoS任务是管理数据包丢失。在数据中心的接入层或虚拟接入层已经正确标记了CoS值或DSCP值，因此核心层往往不再需要明确配置分类、标记和限速策略。数据中心核心交换机应该信任入向的CoS值和DSCP值（NX-OS的默认设置），并且执行入向和出向队列，如图25-1所示。

Cisco Nexus 7000 是作为数据中心核心交换机设计开发的，本章将介绍它的相关特性。

数据中心的设计中有很多选项，但本章仅在第2 层/ 第3 层核心使用Nexus M2 模块（详见本章后文内容），来实现路由互联、园区/WAN互联和OTV（覆盖传输虚拟化）边界——以及一些用于直连服务器的设计选项。

F2/F2e 模块（详见本章后文内容）通过在接入层连接Nexus 5500 设备，将DCB（数据中心桥接）交换架构扩展到了核心层。

图25-1 数据中心核心交换机接口QoS角色

25.1 Nexus 7000概述

Cisco Nexus 7000 系列数据中心交换机支持超过17Tbit/s 的汇聚交换能力，使其有能力成为数据中心核心交换机。Nexus 7000 系列交换机是模块化的设备，分别有4 插槽、9 插槽、10插槽和18插槽机框。这些机框中可以安置以下类型的模块。

■ 引擎模块:引擎模块为交换机提供了可扩展的控制平台和管理功能。引擎负责控制第2层和第3层服务、冗余性能、配置管理、状态监控、电源和环境管理，以及透明地升级到I/O和矩阵模块。

■ 矩阵模块:矩阵模块负责在I/O模块上为完全分布式转发提供集中交换功能。每个矩阵（Fabric）模块可以为系统中的所有模块插槽增加带宽，同时可以使用5个矩阵模块；使用Cisco Nexus 7000系列矩阵2（Fabric-2）模块能够为每个插槽带来550 Gbit/s带宽。

■ M2系列I/O模块:M2系列模块是功能全面的高性能模块，它能够支持高密度10、40 和100Gbit/s 以太网接口。可以启用大转发表来支持完整的IPv4 和IPv6 Internet 路由表。而且M2 系列模块还支持丰富的特性集，其中包括Cisco OTV（覆盖传输虚拟化）、Cisco LISP（定位编号分离协议）、MPLS（多协议标签交换）、完整的Cisco NetFlow和VPLS（虚拟专用局域网服务）。除此之外，这些模块还能够在使用Cisco Catalyst 6500 系列交换机的环境中维持架构的一致性。

■ F2/F2e系列I/O模块:F2系列模块是建立在SoC（单片交换，Switch-on-a-Chip）架构之上的，这种架构能够在增强性能的同时，降低模块对于电源、延迟和制冷的需求。模块上的每个接口可以提供1Gbit/s或10Gbit/s的以太网速率。F2系列模块能够支持第3层功能，还能支持统一交换架构（Unified Fabric）能力，比如Cisco FabricPath（光纤路径）、FCoE（以太网光纤通道），以及与Cisco Nexus 2000系列FEX（矩阵扩展）模块结合使用。除此之外，增强型F2e模块能够启用完整的第2层和第3层功能，并且能够在同一个VDC（虚拟交换机）中，与M2系列模块一同工作。

图25-2描绘了M2系列和F2系列模块的常用软件特性与不同。

图25-2 Cisco Nexus 7000 M2和F2系列模块对比

尽管M2和F2系列模块都支持QoS特性，但它们在架构和能力上有很大区别，本章会分别讨论这两个模块家族的QoS设计建议，还会简要介绍两个模块家族都支持的QoS特性和功能。

与前文介绍的Nexus 交换机相同，Nexus 7000 支持以下类型的QoS 策略。

■ qos:定义MQC对象，实现标记和限速。

■ network-qos（只有F系列模块需要）:定义全网范围内的QoS属性特征（比如用于DCB网络的QoS属性），应该在网络中所有交换机上实施一致的QoS属性。

■ queuing:定义MQC对象，实现队列和调度机制，以及一部分标记对象。

■ control-plane:定义MQC对象，实现CoPP（控制层面限速）。

表25-1 总结了在Neuxs 7000 的入方向上和出方向上，应用QoS 策略的顺序。

表25-1 Cisco Nexus 7000双方向上的QoS行为的操作顺序

Nexus 7000 默认会根据表25-2 中总结的规则来信任流量。

表25-2 Cisco Nexus 7000默认信任状态

1.在对流量进行路由时，（默认）会使用DSCP 值来决定使用哪条出向队列。若出向接口是Trunk接口，会从被路由数据包的DSCP值中提出CoS值

2.若二层接口是Access 接口，默认认为它没有CoS。并且对于Trunk 接口上的桥接流量，即使携带DSCP值，也会将它的CoS值设置为0

Nexus 7000 的默认信任行为有以下重点需要注意。

■ 对于（L2）桥接流量来说，QoS会使用CoS进行入向队列选择；但从QoS的角度看来， DSCP——收到并不加修改地传输——是被忽略的；QoS会使用收到的CoS标记进行出向队列选择，并且会不加修改地将CoS从出向桥接接口发送出去。

■ 对于（L3）路由流量来说，QoS会使用CoS进行入向队列选择；DSCP标记不会被修改，但会用于生成新的CoS标记，即将DSCP的3个MSB（最高有效位）提取出来；然后将这个新生成的CoS 标记用于出向队列选择，即使出向接口并不是802.1Q Trunk接口，也不在数据帧中承载CoS标记。

当然这些默认的行为还是可以根据管理员的配置策略进行改变的。

举例来说，假设桥接流量的IP头部已经标记了DSCP值，而且你希望使用这些DSCP标记来生成出向CoS标记。你可以使用例25-1中呈现的策略来实现这一目的。

例25-1 Nexus 7000 table map策略:在出方向上为桥接流量生成基于DSCP的CoS

! This section configures a DSCP-to-CoS table map

N7K(config)# table-map DSCP-TO-COS-BRIDGED

N7K(config-tmap)# default copy

! By default the 3 MSBs of the DSCP will be copied to CoS

! This section configures the policy map to apply the table-map

N7K(config-tmap)# policy-map type qos DSCP-TO-COS-BRIDGED-PMAP

N7K(config-pmap-qos)# class class-default

N7K(config-pmap-c-qos)# set dscp dscp table DSCP-TO-COS-BRIDGED

! All traffic will have the DSCP-to-CoS table map applied

! This section applies the policy map to an Ethernet interface

N7K(config)# interface Ethernet 2/10

N7K(config-if)# service-policy type qos input DSCP-TO-COS-BRIDGED-PMAP

! This section applies the policy map to a VLAN interface

N7K(config-if)# vlan configuration 110

N7K(config-vlan-config)# service-policy type qos input DSCP-TO-COS-BRIDGED-PMAP

注释:当你在type qos策略中使用set dscp命令（无论是直接配置一个值，还是像例25-1那样通过table map间接配置）时，会发生以下事件:

■ 在set dscp中设置的值将会设置DSCP；

■ 在set dscp中设置的值将会用于重新标记CoS值，也就是当需要生成新的CoS值时，会从这个新的DSCP中提取3个MSB；这个新生成的CoS标记将用于出向队列选择，即使出向接口并不是802.1Q Trunk接口，也不在数据帧中承载CoS标记；

■ 对于（L2）桥接流量和（L3）路由流量一视同仁。

注释:type qos 策略可以应用在物理接口（或一组接口）或逻辑接口，比如VLAN——例25-1中展示了两种应用案例。

你可以使用以下命令来检查例25-1中的配置。

■ show table-map

■ show policy-map

■ show policy-map interface

25.2 Nexus 7000 M2模块:体系结构和QoS设计

图25-3 描绘了Nexus 7000 交换机和M2 系列模块的硬件体系结构，突出强调了QoS 策略的应用位置。如图所示，M2的体系结构中将物理接口队列与虚拟输出队列结合在了一起。

你可以在M2模块以下位置应用QoS策略。

1.在入向物理接口上应用入向（type queuing）策略。

2.在转发引擎内实施分类、标记和限速（type qos）策略。

3.在数据包到达三级交换矩阵之前，在VOQ中应用矩阵QoS策略。

4.在数据包到达三级交换矩阵之后，在VOQ 中应用出向（type queuing）策略。

5.在出向物理接口应用出向（type queuing）策略。

出向和入向队列策略即可使使用默认配置，也可以自定义，比如使用type qos 策略。但矩阵QoS策略是无法自定义的。

矩阵QoS策略决定了入向VOQ（虚拟输出队列）的调度机制，因为这些规则是用于访问三级交换矩阵的。对矩阵QoS调度机制的仲裁是由引擎上的中心仲裁器进行控制的（如图25-3所示）。中心仲裁器通过考虑以下两点因素，来放行入向VOQ去往交换矩阵的访问:

■ 出向模块的VOI（虚拟队列索引）；

■ 流量优先级（CoS）。

图25-3 Cisco Nexus 7000 M2模块硬件体系结构和QoS执行点

VQI 是出向模块上的逻辑地址（并依赖于模块）。每个VQI 代表10 ～12 Gbit/s 流量，因此与出向接口的要求相符:一个10 GE 接口会被分配1 个VQI，一个40 GE 接口会被分配4个VQI，一个100 GE 接口会被分配10 个VQI。中心仲裁器继而会在其调度机制的决策中，使用出口模块的带宽容量来进行衡量，确保出向VOQ和出向物理接口队列不会不堪重负。

除此之外，中心矩阵仲裁器还会考虑VOQ中数据包的流量优先级（CoS）值。以M2模块为例，矩阵VOQ的CoS到队列映射与接口队列的CoS到队列映射是相互独立的（矩阵队列策略是不可配置的，接口队列策略可以自定义，并且可以与矩阵队列策略不同）。表25-3总结了M1/M2模块上的CoS到矩阵VOQ映射。

表25-3 Nexus 7000 M1/M2矩阵VOQ CoS映射

Q1（PQ1）是严格优先级队列；Q2～Q4的加权相同，使用DWRR的方法进行轮循。矩阵VOQ使用的映射和加权是固定的，并且（在本书写作时）无法自定义与其相关的行为。但当管理员在考虑他们的队列设计时，了解这些内部矩阵队列的机制还是有好处的。

这看起来数据包在传输过程中需要执行几次重复的队列策略，但每一级的队列机制（无论是物理队列还是虚拟队列）都有其独特的功能，详见图25-4。

图25-4 Cisco Nexus 7000 M2模块:物理和虚拟队列缓存

如图25-4所示，各种M2队列缓存及其相应功能如下所示。

1.入向接口缓存:为入向转发/复制引擎管理拥塞。

2.入向VOQ缓存（矩阵队列）:管理去往交换矩阵的拥塞。

3.出向VOQ缓存:接收矩阵发来的数据帧，管理去往多目的地数据帧的拥塞。

4.出向接口缓存:在出向接口管理拥塞。

了解了Nexus 7000 及其M2 模块的体系结构后，接着来看看在其上如何应用QoS。

25.2.1 M2模块的QoS设计步骤

如图25-1所示，数据中心核心交换机最重要的三个QoS需求为:

■ 在入方向上信任CoS和DSCP；

■ 入方向上的队列；

■ 出方向上的队列。

由于Nexus 7000 的默认行为就是信任入向CoS 和DSCP，因此在将Nexus 7000 和M2 系列模块作为数据中心核心交换机时，真正需要配置的QoS步骤只有两步:

■ 配置入向队列；

■ 配置出向队列。

此外，M2模块还可能被用作OTV边界，这时涉及另一个设计选项，稍后详述。

25.2.2 M2模块的队列模型

每个M2系列模块都支持8Q2T入向队列结构和1P7Q4T出向队列结构。在本书写作时，这两种队列结构都使用CoS到队列的映射；因此最多只支持8个队列类别（因此接下来的小节只涉及4类和8类战略企业QoS模型）。

注释:10GE M1模块也支持8Q2T入向和1P7Q4T出向队列模型，因此后续内容中介绍的设计建议也可用于这些模块。

Nexus 7000 中queuing 类型的class map 的名称是预定义的，详见表25-4（用于8Q2T 入向队列模型）和表25-5（用于1P7Q4T出向队列模型）。

表25-4 Nexus 7000 M2系列模块预定义queuing class map名称和描述:8Q2T入向模型

表25-5 Nexus 7000 M2系列模块预定义queuing class map名称和描述:1P7Q4T出向模型

1.M2默认队列模型

Nexus 7000 上的队列特性是默认启用的，并通过系统定义的queuing 类型的policy map应用到每个接口和每个Port Channel。图25-5 描绘了默认的8Q2T 入向队列模型和默认的1P7Q4T出向队列模型。

图25-5 Cisco Nexus 7000 M2默认（8Q2T入向/1P7Q4T出向）队列模型

你可以使用命令show policy-map interface 来检查接口应用的策略，例25-2 中的接口未应用任何策略。

例25-2 检查默认系统队列策略:show policy-map interface

N7K# show policy-map interface ethernet 1/2

Global statistics status:enabled

Ethernet1/24

Service-policy (queuing) input:default-in-policy

policy statistics status:enabled (current status:enabled)

Class-map (queuing):in-q1 (match-any)

queue-limit percent 50

bandwidth percent 80

queue dropped pkts:0

Class-map (queuing):in-q-default (match-any)

queue-limit percent 50

bandwidth percent 20

queue dropped pkts:0

Service-policy (queuing) output:default-out-policy

policy statistics status:enabled (current status:enabled)

Class-map (queuing):out-pq1 (match-any)

priority level 1

queue-limit percent 16

queue dropped pkts:0

Class-map (queuing):out-q2 (match-any)

queue-limit percent 1

queue dropped pkts:0

Class-map (queuing):out-q3 (match-any)

queue-limit percent 1

queue dropped pkts:0

Class-map (queuing):out-q-default (match-any)

queue-limit percent 82

bandwidth remaining percent 25

queue dropped pkts:0

N7K#

将任何明确定义的队列策略（详见后文案例）应用到接口后，该策略会——当然会——覆盖默认系统定义的队列策略。

你可以通过修改预定义queuing class map 中的CoS 值，以及修改policy map 中对于每个队列类别的行为，来更改队列策略，详见后文案例。

注释:一旦修改了队列策略，即为入向和出向队列2～7指定了自定义的CoS值，一定要记得为这些队列分配适当的缓存（使用queue-limit这个policy map行为命令）；否则流量可能会因为缓存不足而被丢弃。要记得默认为这些队列分配的缓存是0%（除了出向队列2和3，它们分别获得1%）。

注释:你应该在主/管理VDC中修改系统定义的queuing class map中CoS到队列的映射方式，因为对于一个特定类型的队列模型来说，这里的设置会影响（任意/所有VDC中）所有接口的CoS到队列分配方式。

注释:一定要记住，在Nexus 7000上修改队列策略会对业务造成影响，因此在生产网络中，必须在非工作时间进行修改。

2.M2模块的4类（4Q2T入向/1P3Q4T出向）队列模型

在4类模型中（详见图11-3，适应数据中心网络），应用类与队列的映射关系如下所示。

■ 实时流量（标记为EF，默认映射为CoS 5）在入向4Q2T 模型中获得25% 带宽，但在出向1P3Q4T 模型中，为其启用了严格优先级队列。此外，标记为CoS 6 和7 的流量也会被映射到实时队列中，以保护数据中心网络控制流量。

注释:默认情况下，标记为CoS 6的流量会被分配到PQ中（详见图25-5），从而对数据中心内的网间控制流量提供QoS服务。当你创建了一个策略，只将CoS 5分配到PQ时，要谨慎处理，因为这种行为带来的不良后果是将CoS 6重新分配到默认类中。在这种情况中，建议明确将CoS 6映射到一个（最好是专用的）非默认队列中。Nexus 7000引擎将网间控制协议——比如BGP（边界网关协议）、OSPF（开放式最短路径优先）、PIM（与协议无关的组播）、LDP（标签分发协议）和OTV（覆盖传输虚拟化）——标记为CS6（对应着CoS 6）。此外，Nexus 1000V默认将其控制层面的流量——以及VM控制流量——标记为CS6。

注释:默认情况下，标记为CoS 7的流量也会被分配到PQ中。这个CoS标记有时会被用来标记数据中心网络中的网络或VM控制层面的协议。因此建议将CoS 7映射到PQ中，以保护这些协议。

■ 信令流量（标记为CS3，默认映射为CoS 3）在入向4Q2T 模型中会被分配到专用的非优先级队列中，并获得25%带宽，在出向1P3Q4T模型中会获得35%的剩余带宽。

注释:M2模块中并没有体现出FCoE流量的分配方式，因为该模块不支持FCoE。

注释:当数据中心环境中有FCoE流量时，建议使用M系列模块来连接CUCM（Cisco统一通信管理器）。这样一来，F系列模块就可以将CoS 3专用与FCoE流量，确保其获得无损服务（详见后续内容）。

■ 业务性数据流量（标记为AF2，默认映射为CoS 2）在入向4Q2T 模型中会被分配到另一个专用的非优先级队列中，并获得25%带宽，在出向1P3Q4T模型中会获得35%的剩余带宽。

■ 尽力而为流量（标记为DF，默认映射为CoS 0）在入向4Q2T 模型中会被分配到默认队列中，并获得25%带宽，在出向1P3Q4T模型中会获得30%的剩余带宽。

根据数据中心流量配置文件的不同，带宽的分配也随之发生变化；为了简便，只（粗略地）为所有类别配分相同的带宽（除了PQ和出向默认类之外）。

队列限制（缓存分配）的分配要与入向队列模型中的带宽分配成正比，但要与出向队列模型中的PQ/默认队列成反比。使用这样的分配逻辑是因为PQ服务实时流量，因此它需要较少的缓存（而默认队列——被分配了最少的带宽——可以通过获得更多缓存来防止丢包）。

为了简化设计，这个模型中并没有启用（基于CoS的）WRED（加权随机早期检测），但下一个模型（8类8Q2T/1P7Q4T）中启用了该特性。

图25-6中描绘了4个类映射关系及其带宽和缓存的分配。

图25-6 Cisco Nexus 7000 M2 4类（4Q2T入向/1P3Q4T出向）

例25-3中给出了4类（4Q2T入向/1P3Q4T出向）队列的相关配置。

例25-3 Nexus 7000 M2 4类（4Q2T入向/1P3Q4T出向）队列模型案例

! This section configures the ingress queuing class maps

N7K(config-cmap-que)# class-map type queuing match-any 8q2t-in-q1

N7K(config-cmap-que)# match cos 5-7

! Realtime traffic (DSCP EF/CoS 5) is mapped to ingress Q1

N7K(config-cmap-que)# class-map type queuing match-any 8q2t-in-q2

N7K(config-cmap-que)# match cos 3

! Signaling (DSCP CS3/CoS3) is mapped to ingress Q2

N7K(config-cmap-que)# class-map type queuing match-any 8q2t-in-q3

N7K(config-cmap-que)# match cos 2

! Transactional Data (DSCP AF2/CoS2) is mapped to ingress Q3

! This section configures the egress queuing class maps

N7K(config-cmap-que)# class-map type queuing match-any 1p7q4t-out-pq1

N7K(config-cmap-que)# match cos 5-7

! Realtime traffic (DSCP EF/CoS 5) is mapped to egress PQ

N7K(config-cmap-que)# class-map type queuing match-any 1p7q4t-out-q2

N7K(config-cmap-que)# match cos 3

! Signaling (DSCP CS3/CoS3) is mapped to egress Q2

N7K(config-cmap-que)# class-map type queuing match-any 1p7q4t-out-q3

N7K(config-cmap-que)# match cos 2

! Transactional Data (DSCP AF2/CoS2) is mapped to egress Q3

! This section configures the 4Q2T ingress queuing policy map

N7K(config-cmap-que)# policy-map type queuing 4Q2T-INGRESS

N7K(config-pmap-que)# class type queuing 8q2t-in-q1

N7K(config-pmap-c-que)# bandwidth percent 25

N7K(config-pmap-c-que)# queue-limit percent 25

! Ingress Q1 (Realtime) is allocated 25% bandwidth and 25% buffers

N7K(config-pmap-c-que)# class type queuing 8q2t-in-q2

N7K(config-pmap-c-que)# bandwidth percent 25

N7K(config-pmap-c-que)# queue-limit percent 25

! Ingress Q2 (Signaling) is allocated 25% bandwidth and 25% buffers

N7K(config-pmap-c-que)# class type queuing 8q2t-in-q3

N7K(config-pmap-c-que)# bandwidth percent 25

N7K(config-pmap-c-que)# queue-limit percent 25

! Ingress Q3 (Trans-Data) is allocated 25% bandwidth and 25% buffers

N7K(config-pmap-c-que)# class type queuing 8q2t-in-q-default

N7K(config-pmap-c-que)# bandwidth percent 25

N7K(config-pmap-c-que)# queue-limit percent 25

! Ingress default queue is allocated 25% bandwidth and 25% buffers

! This section configures the 1P3Q4T egress queuing policy map

N7K(config-cmap-que)# policy-map type queuing 1P3Q4T-EGRESS

N7K(config-pmap-que)# class type queuing 1p7q4t-out-pq1

N7K(config-pmap-c-que)# priority

! Strict priority is enabled on egress PQ1

N7K(config-pmap-c-que)# queue-limit percent 10

! Egress PQ (Realtime) is allocated 10% of buffers

N7K(config-pmap-c-que)# class type queuing 1p7q4t-out-q2

N7K(config-pmap-c-que)# bandwidth remaining percent 35

N7K(config-pmap-c-que)# queue-limit percent 25

! Egress Q2 (Signaling) is allocated 35% BWR and 25% buffers

N7K(config-pmap-c-que)# class type queuing 1p7q4t-out-q3

N7K(config-pmap-c-que)# bandwidth remaining percent 35

N7K(config-pmap-c-que)# queue-limit percent 25

! Egress Q3 (Trans-Data) is allocated 35% BWR and 25% buffers

N7K(config-pmap-c-que)# class type queuing 1p7q4t-out-q-default

N7K(config-pmap-c-que)# bandwidth remaining percent 30

N7K(config-pmap-c-que)# queue-limit percent 40

! Egress default queue is allocated 30% BWR and 40% buffers

! This section applies the queuing policies to the interface(s)

N7K(config)# interface Ethernet 1/20

N7K(config-if)# service-policy type queuing input 4Q2T-INGRESS

! 4Q2T ingress queuing policy is attached to the interface (s)

N7K(config-if)# service-policy type queuing output 1P3Q4T-EGRESS

! 1P3Q4T egress queuing policy is attached to the interface (s)

你可以使用下列命令来检查例25-3中的配置。

■ show class-map [ type queuing ]

■ show policy-map [ type queuing ]

■ show policy-map interface

注释:M2模块只支持单一级别的优先级（在本书写作时）。此外，当启用了priority命令后，严格优先级队列是无限制的。但可以在优先级队列类别中，将shape命令作为policy map的行为，来对优先级队列进行限制——这将会按照给定的速率，对优先级流量进行SRR（整形的轮循）整形。

注释:若在这个（1p7q4t-out-pq1）类的policy map行为中没有应用priority关键字，这个队列将作为非优先级队列获得服务。

注释:当配置了优先级队列后，其他类别能接受的配置只有bandwidth remaining percent（确保其他类别可以从剩余带宽中获得最少带宽，剩余带宽是指总带宽减去优先级队列占用的带宽）。

注释:32接口10GE M1模块（N7K-M132XP-12L）不支持配置入向队列限制。

3.M2模块的8类（8Q2T入向/1P7Q4T出向）队列模型

在8类模型中（详见图11-5，适应数据中心网络），应用类与队列的映射关系如下所示。

■ 实时流量（标记为EF，默认映射为CoS 5）在入向8Q2T 模型中获得10% 带宽，在出向1P7Q4T模型中，为其启用了严格优先级队列。

■ 网络控制流量（标记为CoS 7）在入向8Q2T 模型中获得5% 带宽，在出向1P7Q4T 模型中获得5%剩余带宽。

■ 网间控制流量（标记为CS6，默认映射为CoS 6）在入向8Q2T 模型中获得5% 带宽，在出向1P7Q4T模型中获得5%剩余带宽。

■ 视频流量（标记为AF41，默认映射为CoS 4；或者标记为AF31，明确映射为CoS 4）在入向8Q2T模型中获得25%带宽，在出向1P7Q4T模型中获得25%剩余带宽。

■ 信令流量（标记为CS3，默认映射为CoS 3）被分配到专用的非优先级队列中，在入向8Q2T模型中获得10%带宽，在出向1P7Q4T模型中获得10%剩余带宽。

注释:M2模块中并没有体现出FCoE流量的分配方式，因为该模块不支持FCoE。但在本章F2模块的设计中包含了FCoE。

■ 业务性数据流量（标记为AF2，默认映射为CoS 2）被分配到专用的非优先级队列中，在入向8Q2T模型中获得10%带宽，在出向1P7Q4T模型中获得10%剩余带宽。

■ 大数据流量（标记为AF1，默认映射为CoS 1）被分配到专用的非优先级队列中，在入向8Q2T模型中获得10%带宽，在出向1P7Q4T模型中获得10%剩余带宽。

■ 尽力而为流量（标记为DF，默认映射为CoS 0）被分配到默认队列中，在入向8Q2T模型中获得25%带宽，在出向1P7Q4T模型中获得35%剩余带宽。

根据数据中心流量配置文件的不同，带宽的分配也随之发生变化；为了简便，只（粗略地）为所有类别配分相同的带宽（除了PQ和出向默认类之外）。

在前文模型中，队列限制（缓存分配）的分配与入向队列模型中的带宽分配成正比，但要与出向队列模型中的PQ/默认队列成反比。

只在非优先级和非控制队列上启用基于CoS的WRED，即视频队列、业务性数据队列、大数据队列和尽力而为队列。在这些队列上，最低WRED门限值设置为80%，最高WRED门限值设置为100%（队列的尾部）。

图25-7中描绘了8个类映射关系、带宽和缓存的分配，以及拥塞避免策略。

图25-7 Cisco Nexus 7000 M2 8类（8Q2T入向/1P7Q4T出向）队列模型

注释:该模型假设管理员已明确将多媒体流视频映射为CoS 4，可以在入向type qos策略中，使多媒体流视频匹配DSCPAF31/AF32/AF33，并将CoS设置为4。

例25-4中给出了8类（8Q2T入向/1P7Q4T出向）队列的相关配置。

例25-4 Nexus 7000 M2 8类（8Q2T入向/1P7Q4T出向）队列模型案例

! This section configures the ingress queuing class maps

N7K(config-cmap-que)# class-map type queuing match-any 8q2t-in-q1

N7K(config-cmap-que)# match cos 5

! Voice traffic (DSCP EF/CoS 5) is mapped to ingress Q1

N7K(config-cmap-que)# class-map type queuing match-any 8q2t-in-q2

N7K(config-cmap-que)# match cos 7

! Network Control traffic (CoS 7) is mapped in ingress Q2

N7K(config-cmap-que)# class-map type queuing match-any 8q2t-in-q3

N7K(config-cmap-que)# match cos 6

! Network control traffic (DSCP CS6/CoS 6) is mapped in ingress Q3

N7K(config-cmap-que)# class-map type queuing match-any 8q2t-in-q4

N7K(config-cmap-que)# match cos 4

! Video traffic (DSCP AF4/CoS 4) is mapped in ingress Q4

N7K(config-cmap-que)# class-map type queuing match-any 8q2t-in-q5

N7K(config-cmap-que)# match cos 3

! Signaling (DSCP CS3/CoS 3) is mapped to ingress Q5

N7K(config-cmap-que)# class-map type queuing match-any 8q2t-in-q6

N7K(config-cmap-que)# match cos 2

! Transactional-Data (DSCP AF2/CoS 2) is mapped to ingress Q6

N7K(config-cmap-que)# class-map type queuing match-any 8q2t-in-q7

N7K(config-cmap-que)# match cos 1

! Bulk-Data (DSCP AF1/CoS 1) is mapped to ingress Q7

! This section configures the egress queuing class maps

N7K(config-cmap-que)# class-map type queuing match-any 1p7q4t-out-pq1

N7K(config-cmap-que)# match cos 5

! Voice traffic (DSCP EF/CoS 5) is mapped to egress PQ1

N7K(config-cmap-que)# class-map type queuing match-any 1p7q4t-out-q2

N7K(config-cmap-que)# match cos 7

! Network Control traffic (CoS 7) is mapped in egress Q2

N7K(config-cmap-que)# class-map type queuing match-any 1p7q4t-out-q3

N7K(config-cmap-que)# match cos 6

! Network control traffic (DSCP CS6/CoS 6) is mapped in egress Q3

N7K(config-cmap-que)# class-map type queuing match-any 1p7q4t-out-q4

N7K(config-cmap-que)# match cos 4

! Video traffic (DSCP AF4/CoS 3) is mapped in egress Q4

N7K(config-cmap-que)# class-map type queuing match-any 1p7q4t-out-q5

N7K(config-cmap-que)# match cos 3

! Signaling (DSCP CS3/CoS 3) is mapped to egress Q5

N7K(config-cmap-que)# class-map type queuing match-any 1p7q4t-out-q6

N7K(config-cmap-que)# match cos 2

! Transactional-Data (DSCP AF2/CoS 2) is mapped to egress Q6

N7K(config-cmap-que)# class-map type queuing match-any 1p7q4t-out-q7

N7K(config-cmap-que)# match cos 1

! Bulk-Data (DSCP AF1/CoS 1) is mapped to egress Q7

! This section configures the 8Q2T ingress queuing policy map

N7K(config)# policy-map type queuing 8Q2T-INGRESS

N7K(config-pmap-que)# class type queuing 8q2t-in-q1

N7K(config-pmap-c-que)# bandwidth percent 10

N7K(config-pmap-c-que)# queue-limit percent 10

! Ingress Q1 (Voice) is allocated 10% bandwidth and 10% queue-limit

N7K(config-pmap-c-que)# class type queuing 8q2t-in-q2

N7K(config-pmap-c-que)# bandwidth percent 5

N7K(config-pmap-c-que)# queue-limit percent 5

! Ingress Q2 (OAM) is allocated 5% bandwidth and 5% queue-limit

N7K(config-pmap-c-que)# class type queuing 8q2t-in-q3

N7K(config-pmap-c-que)# bandwidth percent 5

N7K(config-pmap-c-que)# queue-limit percent 5

! Ingress Q3 (Routing) is allocated 5% bandwidth and 5% queue-limit

N7K(config-pmap-c-que)# class type queuing 8q2t-in-q4

N7K(config-pmap-c-que)# bandwidth percent 25

N7K(config-pmap-c-que)# queue-limit percent 25

! Ingress Q4 (Video) is allocated 25% bandwidth and 25% queue-limit

N7K(config-pmap-c-que)# random-detect cos-based

N7K(config-pmap-c-que)# random-detect cos 4 minimum-threshold percent 80 maximum-threshold percent 100

! CoS-Based WRED is enabled and tuned on video queue (Q4)

N7K(config-pmap-c-que)# class type queuing 8q2t-in-q5

N7K(config-pmap-c-que)# bandwidth percent 10

N7K(config-pmap-c-que)# queue-limit percent 10

! Ingress Q5 (Signaling) gets 10% bandwidth and 10% queue-limit

N7K(config-pmap-c-que)# class type queuing 8q2t-in-q6

N7K(config-pmap-c-que)# bandwidth percent 10

N7K(config-pmap-c-que)# queue-limit percent 10

! Ingress Q6 (Trans-Data) gets 10% bandwidth and 10% queue-limit

N7K(config-pmap-c-que)# random-detect cos-based

N7K(config-pmap-c-que)# random-detect cos 2 minimum-threshold percent 80 maximum-threshold percent 100

! CoS-Based WRED is enabled and tuned on Trans-Data queue (Q6)

N7K(config-pmap-c-que)# class type queuing 8q2t-in-q7

N7K(config-pmap-c-que)# bandwidth percent 10

N7K(config-pmap-c-que)# queue-limit percent 10

! Ingress Q7 (Bulk-Data) gets 10% bandwidth and 10% queue-limit

N7K(config-pmap-c-que)# random-detect cos-based

N7K(config-pmap-c-que)# random-detect cos 1 minimum-threshold percent 80 maximum-threshold percent 100

! CoS-Based WRED is enabled and tuned on Bulk-Data queue (Q7)

N7K(config-pmap-c-que)# class type queuing 8q2t-in-q-default

N7K(config-pmap-c-que)# bandwidth percent 25

N7K(config-pmap-c-que)# queue-limit percent 25

! Default Ingress Queue is allocated 25% bandwidth and 25% queue-limit

N7K(config-pmap-c-que)# random-detect cos-based

N7K(config-pmap-c-que)# random-detect cos 0 minimum-threshold percent 80 maximum-threshold percent 100

! CoS-Based WRED is enabled and tuned on default queue

! This section configures the 1P7Q4T egress queuing policy map

N7K(config)# policy-map type queuing 1P7Q4T-EGRESS

N7K(config-pmap-que)# class type queuing 1p7q4t-out-pq1

N7K(config-pmap-c-que)# priority

! Strict priority is enabled on egress PQ1

N7K(config-pmap-c-que)# queue-limit percent 10

! Egress PQ (Realtime) is allocated 10% of buffers

N7K(config-pmap-c-que)# class type queuing 1p7q4t-out-q2

N7K(config-pmap-c-que)# bandwidth remaining percent 5

N7K(config-pmap-c-que)# queue-limit percent 5

! Egress Q2 (OAM) is allocated 5% BWR and 5% queue-limit

N7K(config-pmap-c-que)# class type queuing 1p7q4t-out-q3

N7K(config-pmap-c-que)# bandwidth remaining percent 5

N7K(config-pmap-c-que)# queue-limit percent 5

! Egress Q3 (Routing) is allocated 5% BWR and 5% queue-limit

N7K(config-pmap-c-que)# class type queuing 1p7q4t-out-q4

N7K(config-pmap-c-que)# bandwidth remaining percent 25

N7K(config-pmap-c-que)# queue-limit percent 25

! Egress Q4 (Video) is allocated 25% BWR and 25% queue-limit

N7K(config-pmap-c-que)# random-detect cos-based

N7K(config-pmap-c-que)# random-detect cos 4 minimum-threshold percent 80 maximum-

threshold percent 100

! CoS-Based WRED is enabled and tuned on video queue (Q4)

N7K(config-pmap-c-que)# class type queuing 1p7q4t-out-q5

N7K(config-pmap-c-que)# bandwidth remaining percent 10

N7K(config-pmap-c-que)# queue-limit percent 10

! Egress Q5 (Signaling) gets 10% BWR and 10% queue-limit

N7K(config-pmap-c-que)# class type queuing 1p7q4t-out-q6

N7K(config-pmap-c-que)# bandwidth remaining percent 10

N7K(config-pmap-c-que)# queue-limit percent 10

! Egress Q6 (Trans-Data) gets 10% BWR and 10% queue-limit

N7K(config-pmap-c-que)# random-detect cos-based

N7K(config-pmap-c-que)# random-detect cos 2 minimum-threshold percent 80 maximum-threshold percent 100

! CoS-Based WRED is enabled and tuned on Trans-Data queue (Q6)

N7K(config-pmap-c-que)# class type queuing 1p7q4t-out-q7

N7K(config-pmap-c-que)# bandwidth remaining percent 10

N7K(config-pmap-c-que)# queue-limit percent 10

! Egress Q7 (Bulk-Data) gets 10% BWR and 10% queue-limit

N7K(config-pmap-c-que)# random-detect cos-based

N7K(config-pmap-c-que)# random-detect cos 1 minimum-threshold percent 80 maximum-threshold percent 100

! CoS-Based WRED is enabled and tuned on Bulk-Data queue (Q7)

N7K(config-pmap-c-que)# class type queuing 1p7q4t-out-q-default

N7K(config-pmap-c-que)# bandwidth remaining percent 35

N7K(config-pmap-c-que)# queue-limit percent 25

! Default Egress Queue is allocated 35% BWR and 25% queue-limit

N7K(config-pmap-c-que)# random-detect cos-based

N7K(config-pmap-c-que)# random-detect cos 0 minimum-threshold percent 80 maximum-threshold percent 100

! CoS-Based WRED is enabled and tuned on default queue

! This section applies the queuing policies to the interface(s)

N7K(config)# interface Ethernet 1/20

N7K(config-if)# service-policy type queuing input 8Q2T-INGRESS

! 8Q2T ingress queuing policy is attached to the interface (s)

N7K(config-if)# service-policy type queuing output 1P7Q4T-EGRESS

! 1P7Q4T egress queuing policy is attached to the interface (s)

你可以使用下列命令来检查例25-4中的配置。

■ show class-map [ type queuing ]

■ show policy-map [ type queuing ]

■ show policy-map interface

注释:M1系列48接口10/100/1000模块也支持M2入向和出向队列模型；M1 10/100/1000模块使用2Q4T和1P3Q4T队列架构。为了实现这些架构，2Q4T可以使用默认配置（与图25-5中展示的模型几乎相同），可以应用4类1P3Q4T出向队列模型，详见图25-6和例25-3——只是queuing类型的class map名称要相应地变为1p3q4t-out-（替换例25-4中使用的1p7q4t-out-）。

注释:32 接口10GE M1 模块（N7K-M132XP-12L）不支持配置入向队列限制，也不支持配置入向WRED。

25.2.3 M2 OTV边界设备QoS设计

通过使用Cisco OTV（覆盖传输虚拟化）技术，两个站点在建立DCI（数据中心互联）时，无需更改或重新配置现有的网络设计。OTV所提供的覆盖技术会通过IP隧道，实现两个分离的二层域之间的二层连接。这种做法维持了二层域的独立性——保留了分离广播域的故障隔离和恢复能力——同时通过基于IP 的互联，获得了扩展和负载均衡能力。Cisco Nexus 7000 平台是最早引入OTV 的设备，ASR 1000 家族现在也支持OTV。

OTV引入了“MAC路由”的概念，也就是使用一个控制层面的协议，在网络设备之间交换MAC可达性信息，从而提供LAN扩展功能。

OTV还引入了动态封装的概念，即将需要被发送到远端目的地的二层流进行动态封装。每个以太网帧都会被单独地封装今一个IP数据包——在IP包头和原始的以太网帧之间插入OTV“垫片（Shim）”——然后在传输网络中传递这个IP数据包。这样做就无需在数据中心不同站点之间建立虚拟电路（VC）了。

Nexus 7000 系列交换机可以作为OTV 边界设备（位于分离的广播域/ 数据中心之间），它可以接收二层流量（来自于所有需要扩展到远端站点的VLAN），动态地将以太网帧封装到IP数据包中，然后利用传输基础设施来传递这些数据包。

从QoS的角度看来，理解封装过程非常重要，尤其是如何关联CoS和DSCP值，具体步骤如下所示。

1.在封装二层数据帧之前，OTV 边界设备会从原始二层头部中复制CoS 位（802.1p），并将其放入OTV垫片头部中。如果原始数据帧承载的是IP数据包，那么原始的（内部） DSCP值也会被复制到外部DSCP中。这样做就可以为穿越传输基础设施的OTV流量应用一致的QoS策略了。

注释:对于未标记的数据包（即没有设置802.1p CoS值的数据包）来说，其OTV数据包的外部DSCP值会被设置为0，但被封装数据包的内部DSCP值会得到保留。

2.远端OTV 边界设备在接收并解封装数据包后，会将OTV 垫片中的CoS 值恢复到802.1Q头部中，从而保留了原始的CoS和DSCP值。

注释:如果外部IP头部中的DSCP值在传输过程中被修改了，这些修改并不会影响到内部DSCP值，内部DSCP值只有在解封装之后才可看到。

图25-8描绘了通过OTV保留DSCP和CoS值的过程。

图25-8 Cisco Nexus 7000 OTV保留CoS和DSCP值

除了上述功能外，还可以通过应用指定的policy map，使用原始数据帧中的CoS 值来映射OTV数据包外部IP头部中的DSCP值。这样做就可以唯一地标记和识别OTV数据包，并为其应用相应的QoS策略。

注释:通过OVT覆盖技术保留CoS和DSCP值的行为是在NX-OS 5.2(1)版本中引入的。

OTV 边界设备向另一台OTV 边界设备发送的控制流量，被默认标记为DSCP CS6。在部署OTV时，强烈建议使用以下两种方式之一，来保护这类控制层面的流量。

■ 将控制层面的流量标记为CoS 6，并映射到出向优先级队列中（这是Nexus 7000 出向队列架构的默认做法）；顺便一提，M2模块中的4类队列模型正是使用了这种做法，详见前文内容。

■ 将CoS 6 映射到专用队列中（如果该队列专用于控制层面的流量，那么使用非优先级队列就可以了）；M2模块中的8类队列模型正是使用了这种做法。

注释:除此之外，建议使用与OTV设计中服务CoS 6流量相同的方法来服务网络或VM控制流量——被标记为CoS 7，在M2模块的4类和8类模型中也应用这种行为。

本节介绍的M2模块4类和M2模块8类队列模型中都包含对OTV的支持。

25.3 Nexus 7000 F2模块:体系结构和QoS设计

Neuxs 7000 F2/F2e 模块（后文简称F2 模块）可以将数据中心交换架构扩展到核心层，它的体系结构与M2模块不同，详见图25-9。

图25-9 Cisco Nexus 7000 F2模块硬件体系结构和QoS执行点

你可以在F2模块以下位置应用QoS策略。

1.在转发引擎内实施分类、标记和限速（type qos）策略。

2.在数据包到达三级交换矩阵之前，在VOQ 中应用入向和出向（type queuing）策略；入向队列策略中定义了分配给每条VOQ的缓存，出向队列策略中定义了这些VOQ的调度机制。

3.在数据包到达三级交换矩阵之后，在VOQ 中应用出向（type queuing）策略。

如前所述，F2 模块上的出向type queuing 策略控制了VOQ 用来访问交换矩阵的调度机制（而不是像M2模块那样，由不可自定义的矩阵QoS策略来控制）。

另一个重要的不同点在于:F2模块没有任何物理接口队列缓存，对比图25-10（F2虚拟队列）和图25-4（M2物理和虚拟队列）可以注意到。

图25-10 Cisco Nexus 7000 M2模块:虚拟队列缓存

如图25-10所示，F2虚拟队列缓存及其相应功能如下所示。

1.入向暂停延迟（“滑动”）缓存:在实施了外部流控机制后缓存无法立即被发送的数据包，并为入向转发/复制引擎管理拥塞。

2.入向VOQ缓存（矩阵队列）:管理去往交换矩阵的拥塞。

3.出向VOQ缓存:接收矩阵发来的数据帧，管理去往多目的地数据帧的拥塞。

25.3.1 F2模块的QoS设计步骤

在Nexus 7000 核心数据中心交换机上部署了F2 模块后——而且信任DSCP 并配置了入向/出向队列——为了将DCB网络扩展到核心层，还有一些其他要求。比如F2模块上配置的network-qos参数要与所有DCB网络中的设备相同；还要在系统中配置入向和出向队列策略，这些策略取决于network-qos策略。在定义队列策略前，必须先执行第一个步骤。

因此在将Nexus 7000 和F2 系列模块作为数据中心核心交换机时，需要配置的QoS 步骤有三步:

■ 为系统应用正确的network-qos策略。

■ 配置入向队列。

■ 配置出向队列。

25.3.2 F2模块的网络QoS策略设计

当F系列模块被插入并可运行后，系统中会自动添加5个network-qos策略模板，详见表25-6。default-nq-7e-policy用阴影突出显示，这是接下来的设计中会用到的网络QoS模板。

表25-6 默认的网络QoS策略模板

网络QoS策略模板名称中包含的nq代表network-qos；数字4、6、7、8指明了在策略模板中定义的丢弃CoS值（在遭遇拥塞时有可能被丢弃的CoS值）的数量，后面的e代表以太网。default-nq-8e-4q4q-policy中的4Q4T表示入向和出向队列架构都使用4条队列（与default-nq-8e-policy模板不同，该模版会使用4条出向队列和2条入向队列）。

默认情况下，系统中应用的是default-nq-8e-policy。这些模板可以被复制和修改，也可是使用system qos 命令，在全局中进行应用。

注释:与Nexus 5000不同，Nexus 7000只能在system qos中应用network-qos类型的策略。

注释:应该只在主/管理VDC中，将network-qos策略应用到system qos，因为这些更改会影响所有VDC中的所有接口，并会对业务造成影响。

在设计章节并没有将所有network-qos模板都应用到4类和8类队列模型中，只使用了名为default-nq-7e-policy 的network qos 模板，因为它满足了启用FCoE 的最低要求。在例25-5中，在全局应用了network qos 模板default-nq-7e-policy（也就是在system qos 中应用），这个策略为FCoE自动配置了无损服务。

例25-5 Nexus 7000 F2模块FCoE（7e）网络QoS策略模板应用案例

! This section applies the default-nq-7e-policy to system qos

N7K(config)# system qos

N7K(config-sys-qos)# service-policy type network-qos default-nq-7e-policy

! Applies the default-nq-7e-policy globally

2013 May 30 09:47:02 N7K -QOS %$ VDC-3 %$ %IPQOSMGR-2-QOSMGR_NETWORK_QOS_POLICY_

CHANGE:Policy default-nq-7e-policy is now active

2013 May 30 09:47:02 N7K%$ VDC-1 %$ %IPQOSMGR-2-QOSMGR_NETWORK_QOS_POLICY_CHANGE:

Policy default-nq-7e-policy is now active

N7K (config-sys-qos)#

你可以使用下列命令来检查例25-5中的配置。

■ show class-map type network-qos [ c-nq-7e-drop | c-nq-7e-ndrop-fcoe ]（详见例25-6）

■ show policy-map type network-qos [ default-nq-7e-policy ]（详见例25-7）

■ show policy-map system（详见例25-8）

例25-6 检查FCoE class map配置:show class-map type network-qos[ c-nq-7e-drop | c-nq-7e-ndrop-fcoe ]

N7K# show class-map type network-qos c-nq-7e-drop

Type network-qos class-maps

===========================

class-map type network-qos match-any c-nq-7e-drop

Description:7E Drop CoS map

match cos 0-2,4-7

N7K# show class-map type network-qos c-nq-7e-ndrop-fcoe

Type network-qos class-maps

=============================================

class-map type network-qos match-any c-nq-7e-ndrop-fcoe

Description:7E No-Drop FCoE CoS map

match cos 3

match protocol fcoe

在例25-6 中，除了CoS 3 之外的所有CoS 值都被分配到了丢弃类（c-nq-7e-drop）中；FCoE由protocol fcoe进行匹配，获得CoS 3，被分配到无损类（c-nq-7e-ndrop-fcoe）中。另外， match protocol fcoe 命令也用于在DCBX（DCB 交换）中通告fcoe。

例25-7 检查网络QoS policy map配置:show policy-map type network-qos[ default-nq-7e-policy ]

N7K# show policy-map type network-qos default-nq-7e-policy

Type network-qos policy-maps

============================

policy-map type network-qos default-nq-7e-policy

class type network-qos c-nq-7e-drop

congestion-control tail-drop

mtu 1500

class type network-qos c-nq-7e-ndrop-fcoe

pause

mtu 2112

例25-7通过pause命令，为FCoE配置了无损（IEEE 802.1Qbb）PFC（优先级流控制）服务，而且为了满足FCoE的需要，自动将MTU设置为2112。

注释:有些细心的读者可能发现了，Nexus 5500默认为FCoE设定的MTU是2158字节，而Nexus 7000默认为FCoE设定的MTU是2112字节。这种区别取决于系统对MTU的计算方式:Nexus 5500将FC（光纤通道）需要的46字节以太网开销加在了2112字节上，而Nexus 7000在MTU的定义中忽略以太网开销，在之后再将其计入其中。

例25-8 检查系统网络QoS策略:show policy-map system

N7K# show policy-map system

N7K (config-sys-qos)# show policy-map system

Type network-qos policy-maps

============================

policy-map type network-qos default-nq-7e-policy

class type network-qos c-nq-7e-drop

match cos 0-2,4-7

congestion-control tail-drop

mtu 1500

class type network-qos c-nq-7e-ndrop-fcoe

match cos 3

match protocol fcoe

pause

mtu 2112

Service-policy (queuing) input:default-4q-7e-in-policy

policy statistics status:disabled (current status:disabled)

Class-map (queuing):c-4q-7e-drop-in (match-any)

Match:class-map type queuing match-any 4q4t-7e-in-q1

Match:class-map type queuing match-any 4q4t-7e-in-q-default

Match:class-map type queuing match-any 4q4t-7e-in-q3

service-policy type queuing default-4q-7e-drop-in-policy

Service-policy (queuing) input:default-4q-7e-drop-in-policy

policy statistics status:disabled (current status:disabled)

Class-map (queuing):4q4t-7e-in-q1 (match-any)

queue-limit percent 10

bandwidth percent 25

Class-map (queuing):4q4t-7e-in-q-default (match-any)

queue-limit percent 45

bandwidth percent 25

Class-map (queuing):4q4t-7e-in-q3 (match-any)

queue-limit percent 45

bandwidth percent 25

queue-limit percent 70

Class-map (queuing):c-4q-7e-ndrop-in (match-any)

Match:class-map type queuing match-any 4q4t-7e-in-q4

service-policy type queuing default-4q-7e-ndrop-in-policy

Service-policy (queuing) input:default-4q-7e-ndrop-in-policy

policy statistics status:disabled (current status:disabled)

Class-map (queuing):4q4t-7e-in-q4 (match-any)

queue-limit percent 100

bandwidth percent 25

queue-limit percent 30

Service-policy (queuing) output:default-4q-7e-out-policy

policy statistics status:disabled (current status:disabled)

Class-map (queuing):c-4q-7e-drop-out (match-any)

Match:class-map type queuing match-any 1p3q1t-7e-out-pq1

Match:class-map type queuing match-any 1p3q1t-7e-out-q3

Match:class-map type queuing match-any 1p3q1t-7e-out-q-default

service-policy type queuing default-4q-7e-drop-out-policy

Service-policy (queuing) output:default-4q-7e-drop-out-policy

policy statistics status:disabled (current status:disabled)

Class-map (queuing):1p3q1t-7e-out-pq1 (match-any)

priority level 1

Class-map (queuing):1p3q1t-7e-out-q3 (match-any)

bandwidth remaining percent 50

Class-map (queuing):1p3q1t-7e-out-q-default (match-any)

bandwidth remaining percent 50

bandwidth remaining percent 80

Class-map (queuing):c-4q-7e-ndrop-out (match-any)

Match:class-map type queuing match-any 1p3q1t-7e-out-q2

service-policy type queuing default-4q-7e-ndrop-out-policy

Service-policy (queuing) output:default-4q-7e-ndrop-out-policy

policy statistics status:disabled (current status:disabled)

Class-map (queuing):1p3q1t-7e-out-q2 (match-any)

bandwidth remaining percent 100

bandwidth remaining percent 20

N7K(config-sys-qos)#

在例25-8中，在系统（全局）中应用了default-nq-7e-policy策略，并使用了默认的入向和出向队列策略。

有意思的一点是，入向和出向队列策略实际上是分层的QoS策略（在队列策略中嵌套队列策略）。具体来说:default-4q-7e-drop-in-policy和default-4q-7e-ndrop-in-policy嵌套在入向 default-4q-7e-in-policy 中，default-4q-7e-drop-out-policy 和 default-4q-7e-ndrop-out-policy嵌套在出向default-4q-7e-out-policy中。图25-13展示了出向分层队列策略。

25.3.3 F2模块的队列模型

每个network-qos策略模板中都包含预配置的默认入向和出向队列模型。每个模型都可以被复制和修改，详见后续内容。

表25-7总结了network-qos策略模板中默认的入向和出向队列模型。

表25-7 F2模块network-qos策略模板默认的入向和出向队列模型

每个默认的入向和出向队列策略都有着相应的系统定义的class map名称，详见表25-8（入向队列策略）和表25-9（出向队列策略）。

表25-8 F2模块默认的入向队列策略class map名称

注释:尽管有些class map 的名称暗示着为每条非优先级入向队列使用4 个门限值（比如2q4t-/4q4t-），但这其实是使用不当的命名方式。在本书写作时，所有F2模块的入向队列架构都只支持每队列单一的丢弃门限值（也就是尾部丢弃）。因此在后续的图标和文字中，将所有F2模块的入向队列架构更名为更确切的描述:2Q1T或4Q1T。

注释:你可能会注意到，在最新的policy map 模板中，这些不适宜的命名已经被修正了（default-8e-4q4q-in-policy，在NX-OS 6.1(3) 版本中引入），所有的class map 都被命名为4q1t-。

表25-9 F2模块默认的出向队列策略class map名称

1.F2模块默认的队列模型

图25-11到图25-13描绘了F2模块默认的入向和出向队列模型。

图25-11 Cisco Nexus 7000 F2模块网络QoS策略模板中默认的入向队列模型

入向队列策略控制着分配给每条矩阵VOQ的缓存，详见图25-9和图25-10。在这些入向策略中分配的bandwidth值都不会真正影响内部交换的调度机制（因为这些队列的内部调度机制是由出向队列策略决定的），但这些值会被用在向对等体发出的DCBX通告中，来实现ETS（增强型传输选择）。

注释:从Cisco NX-OS 6.1版本开始，F2模块开始在（IPv4流量）入方向上，支持DSCP到队列的映射；这种功能可以通过在以下两个class map中使用match dscp命令实现:2q4t-8e-in-q1和2q4t-8e-in-q-default。

此外，从NX-OS 6.1(2) 版本开始，F2 模块能够为IPv6 流量提供入向队列的DSCP 到队列映射。

但是为了与本章介绍的其他队列模型保持一致，接下来的案例中仍将使用CoS到队列的映射。

出向队列的缓存分配是固定的且无法配置。图25-12中总结了各种模板中的出向队列策略。

图25-12 Cisco Nexus 7000 F2模块网络QoS策略模板中默认的出向队列模型

注释:对于图25-11和图25-12中描绘的分层QoS（HQoS）策略来说，队列限制和剩余带宽值是根据以下因子计算出来的:内部（子系）策略带宽或队列限制值除以外部（父系）策略值。

图25-13展示了调度机制的策略——突出显示了7e、6e和4e出向队列策略的分层调度机制策略。

图25-13 Cisco Nexus 7000 F2模块网络QoS策略模板的默认出向调度机制策略

注释:NX-OS 6.1(3)版本中可以使用上述总结及展示的入向和出向队列配置。不过这些默认的CoS到队列的映射、带宽的分配和缓存的分配，会根据软件版本不同而有所区别。建议使用命令show policy-map type queuing default-policy-map-name来检查当前的队列设置。

2.F2模块的4类（4Q1T入向/1P3Q1T出向）队列模型

为了使4类功能类到队列的映射功能能够与本章前文介绍的4类模型（详见图25-6）相匹配，你所需要做的就是将nq-7e 策略模板（default-nq-7e-policy）应用到system qos——详见例25-10所示。nq-7e策略模板中的默认入向和出向队列设置（详见图25-11、图25-12和图25-13）自动满足了该模型对于映射和部署的要求。

你可以使用以下命令来检查上述配置。

■ show policy-map system（详见例25-8）

■ show class-map type queuing [ 4q4t-7e-in-q1 | 4q4t-7e-in-q3 | 4q4t-7e-in-q4 | 4q4t-7e-in-q-default | 1p3q1t-7e-out-pq1 | 1p3q1t-7e-out-q2 | 1p3q1t-7e-out-q3 | 1p3q1t-7e-out-q-default ]

■ show policy-map type queuing [ default-4q-7e-in-policy | default-4q-7e-drop-in-policy|default-4q-7e-ndrop-in-policy | default-4q-7e-out-policy | default-4q-7e-dropout-policy |default-4q-7e-ndrop-out-policy ]

■ show policy-map interface

3.F2模块的8类（4Q1T入向/1P3Q1T出向）队列模型

与4类模型一样，nq-7e策略模板还能够很好地适应8类模型——无需额外配置。图25-14描绘了8类模型与默认nq-7e策略模版的映射关系。

图25-14 Cisco Nexus 7000 F2模块8类（nq-7e:4Q1T入向/1P3Q1T出向）默认队列模型

注释:该模型假设管理员已明确将多媒体流视频映射为CoS 4，可以在入向type qos策略中，使多媒体流视频匹配DSCPAF31/AF32/AF33，并将CoS设置为4。

为了更好地讲解，现在假设我们需要修改这个nq-7e策略模板，以便能够使其更好地符合特定需求和环境。

首先需要复制默认的队列策略——既可以在前面添加一个前缀（使用关键字prefix），也可以在后面添加一个后缀（使用关键字suffix）。例25-9 中展示了在默认策略前添加前缀MODIFIED-。

例25-9 Nexus 7000 F2模块8类（7e:4Q1T入向/1P3Q1T出向）修改队列模型案例:第1部分，复制默认策略

! This section clones the default 7e policy-template

N7K# qos copy policy-map type queuing default-4q-7e-in-policy prefix MODIFIED-

复制策略并添加了前缀之后，在配置中就可以看到新的内容了，详见例25-10。

例25-10 Nexus 7000 F2模块8类（7e:4Q1T入向/1P3Q1T出向）修改队列模型案例:第2部分，修改复制的策略

N7K# show run | begin MODIFIED

policy-map type queuing MODIFIED-4q-7e-drop-in

class type queuing 4q4t-7e-in-q1

queue-limit percent 10

bandwidth percent 25

class type queuing 4q4t-7e-in-q-default

queue-limit percent 45

bandwidth percent 25

class type queuing 4q4t-7e-in-q3

queue-limit percent 45

bandwidth percent 25

policy-map type queuing MODIFIED-4q-7e-ndrop-in

class type queuing 4q4t-7e-in-q4

queue-limit percent 100

bandwidth percent 25

policy-map type queuing MODIFIED-4q-7e-in

class type queuing c-4q-7e-drop-in

service-policy type queuing MODIFIED-4q-7e-drop-in

queue-limit percent 70

class type queuing c-4q-7e-ndrop-in

service-policy type queuing MODIFIED-4q-7e-ndrop-in

queue-limit percent 30

你可能已经注意到了，入向队列限制的分配在三条丢弃队列之间并不是平衡的——Q1、Q2/默认和Q3，详见例25-10。这三条队列的限制分别是10%、45%和45%，并会受到父系策略中的队列限制70%的影响（有效的队列限制分别为7%、31.5%和31.5%）。

假设你希望将队列限制分配得更平均一些，就需要实现例25-11 中的策略修改。

例25-11 Nexus 7000 F2模块8类（7e:4Q1T入向/1P3Q1T出向）修改队列模型案例:第3部分，修改策略

! This section modifies the cloned ingress queuing policy

N7K(config)# policy-map type queuing MODIFIED-4q-7e-drop-in

N7K(config-pmap-que)# class type queuing 4q4t-7e-in-q1

N7K(config-pmap-c-que)# queue-limit percent 33

! Changes queue-limit for In-Q1 to 33% (of 70%) ≈ 23%

N7K(config-pmap-c-que)# class type queuing 4q4t-7e-in-q-default

N7K(config-pmap-c-que)# queue-limit percent 34

! Changes queue-limit for the default queue to 34% (of 70%) ≈ 24%

N7K(config-pmap-c-que)# class type queuing 4q4t-7e-in-q3

N7K(config-pmap-c-que)# queue-limit percent 33

! Changes queue-limit for In-Q3 to 33% (of 70%) ≈ 23%

修改完成后，你可以检查修改后的策略，详见例25-12。

例25-12 Nexus 7000 F2模块8类（7e:4Q1T入向/1P3Q1T出向）修改队列模型案例:第4部分，检查修改后的策略

N7K# show run | begin MODIFIED

policy-map type queuing MODIFIED-4q-7e-drop-in

class type queuing 4q4t-7e-in-q1

queue-limit percent 33

bandwidth percent 25

class type queuing 4q4t-7e-in-q-default

queue-limit percent 34

bandwidth percent 25

class type queuing 4q4t-7e-in-q3

queue-limit percent 33

bandwidth percent 25

policy-map type queuing MODIFIED-4q-7e-ndrop-in

class type queuing 4q4t-7e-in-q4

queue-limit percent 100

bandwidth percent 25

policy-map type queuing MODIFIED-4q-7e-in

class type queuing c-4q-7e-drop-in

service-policy type queuing MODIFIED-4q-7e-drop-in

queue-limit percent 70

class type queuing c-4q-7e-ndrop-in

service-policy type queuing MODIFIED-4q-7e-ndrop-in

queue-limit percent 30

从例25-12中可以看出，在默认入向队列策略的基础上已经做出了相应修改。这时可以将策略应用到接口（或一组接口）上，这样就覆盖了接口上的默认入向队列策略，详见例25-13。在应用策略时，要确保应用的是父系队列策略（本里中即为MODIFIED-4q-7e-in），而不是子系策略（本里中即为MODIFIED-4q-7e-drop-in和MODIFIED-4q-7e-ndrop-in）。

例25-13 Nexus 7000 F2模块8类（7e:4Q1T入向/1P3Q1T出向）修改队列模型案例:第5部分，在接口应用修改后的（HQoS父系）入向队列策略

N7K(config)# interface Ethernet3/44

N7K(config-if)# service-policy type queuing input MODIFIED-4q-7e-in

! Attaches the modified parent ingress queuing policy to the int(s)

你可以使用以下命令来检查上述配置。

■ show policy-map type queuing [ MODIFIED-4q-7e-in | MODIFIED-4q-7e-drop-in |MODIFIED-4q-7e-ndrop-in ]

■ show policy-map interface

按照同样的步骤——详见例25-10到例25-13，你也可以对出向队列策略做出自定义修改。

25.3.4 FEX QoS设计

Cisco Nexus 2000 系列FEX（矩阵扩展模块）是一种远程线卡，你可以将其与Cisco Nexus 7000系列交换机相连，来扩展交换矩阵。FEX提供48个1G面向服务的接口（卫星接口），以及4 个上行链路接口，你可以通过这4 个接口来连接Cisco Nexus 7000 系列交换机。在Cisco Nexus 7000 系列交换机上与这4 个上行链路接口相连的接口是矩阵接口（Fabric Port）。在面向服务的FEX接口上只能配置QoS策略，当前并不支持在FEX接口上配置队列。前面的章节已经详细介绍了Nexus 2000 FEX 的QoS 设计。

25.4 M2/F2模块的其他QoS设计选项

上述QoS 设计只是为作为数据中心核心交换机的Nexus 7000 提供了通用架构，而绝不是唯一可用的设计选项。比如Nexus 7000 可能会直接连接服务器——扮演数据中心接入交换机的角色。因此接下来介绍一些其他的设计模型:

■ 受信任的服务器模型；

■ 不受信任的服务器模型；

■ 单应用服务器模型；

■ 多应用服务器模型；

■ 应用限速服务器模型。

下面按顺序介绍这些QoS 设计选项。由于多数模型都使用type qos 策略，因此在M2 和F2模块上的应用相同。若有与模块相关的区别，也会在后文中明确指出。

25.4.1 受信任的服务器模型

在很多数据中心网络案例中，管理员可以信任应用服务器上设置的L2和L3标记，尤其是当服务器已经物理地安置在数据中心内部，并对其实施了一定级别的管理控制时。

Nexus 7000 默认信任CoS 和DSCP。因此在连接受信任的应用服务器时，无需在接口做任何配置。

25.4.2 不受信任的服务器模型

如果网络团队并不信任应用服务器（或者服务器的管理团队——这是有可能的），可以按照本节配置的策略，禁用入向接口上的信任行为。

不受信任的服务器策略可能由以下两部分构成。

1.第一个策略是入向队列（type queuing）策略，将CoS 改写为0；但（在本书写作时）队列策略中无法重新标记DSCP值，只能重新标记CoS值。而且在配置入向队列策略时，只能改写默认类中的CoS值。

注释:只有当接口为802.1Q Trunk时，才需要这个策略。

2.第二个策略是type qos 策略，将DSCP 改写为0。

例25-14中结合使用了这两个策略。为了涵盖更多的知识，本例中的应用连接在M1系列10/100/1000 线卡上——通过在queuing 类型的policy map 中调用名为2q4t-in-q-default 的class map实现配置。

注释:要在M2系列模块上应用这个策略，调用的默认类将不再是2q4t-in-q-default，而是8q2t-in-q-default。

例25-14 Nexus 7000不受信任的服务器模型:M1 10/100/1000模块案例

! This section configures the Untrusted Server Queuing policy map

N7K(config)# policy-map type queuing M1-UNTRUSTED-SERVER-QUEUING-POLICY

N7K(config-pmap-que)# class type queuing 2q4t-in-q-default

! Applies the policy map actions that follow

! to the M1 10/100/1000 2Q4T default ingress queue class map

N7K(config-pmap-c-que)# bandwidth percent 100

N7K(config-pmap-c-que)# queue-limit percent 100

! All bandwidth and buffers are assigned to the default queue

N7K(config-pmap-c-que)# set cos 0

! CoS is set to 0 on ingress

! This section configures the Untrusted Server QoS policy map

N7K(config)# policy-map type qos UNTRUSTED-SERVER-QOS-POLICY

N7K(config-pmap-qos)# class class-default

N7K(config-pmap-c-qos)# set dscp 0

! All traffic is re-marked to DSCP 0

! This section applies both policies to the Untrusted Server port

N7K(config)# interface ethernet 2/40

N7K(config-if)# service-policy type queuing input M1-UNTRUSTED-SERVER-QUEUING-POLICY

! Attaches the Untrusted Server Queuing policy to the port

N7K(config-if)# service-policy type qos input UNTRUSTED-SERVER-QOS-POLICY

! Attaches the Untrusted Server QoS policy to the port

你可以使用以下命令来检查例25-14中的配置。

■ show class-map [ type { qos | queuing } ]

■ show policy-map [ type { qos | queuing } ]

■ show policy-map interface

例25-14 给出了将Nexus 7000 上的接口设置为不信任状态的推荐模型。但有些高级用户想要了解该策略的逻辑，因为看起来这个策略只重新标记了CoS 0 和1。看起来好像是这样的，因为——默认情况下——只有CoS 0 和1 会被映射到2q4t-in-q-default 默认类中（而且再次强调，在入向队列策略中，只有默认类才支持重新标记行为）。你可以使用内部show命令（show system internal qos queuing config interface）来检查CoS 到队列的映射关系，详见例25-15。

例25-15 检查内部CoS到队列的映射

N7K# show system internal qos queuing config interface e 2/40 | begin COS2Q

<snip>

COS2Q Config

Direction:ingress

COS 0 Queue:2q4t-in-q-default

COS 1 Queue:2q4t-in-q-default

COS 2 Queue:2q4t-in-q1

COS 3 Queue:2q4t-in-q1

COS 4 Queue:2q4t-in-q1

COS 5 Queue:2q4t-in-q1

COS 6 Queue:2q4t-in-q1

COS 7 Queue:2q4t-in-q1

<snip>

N7K#

从例25-15 可以看出，好像看起来只有CoS 0 和1 会服从入向队列策略中的CoS 重新标记策略（CoS 2 ～7 逃过了这个策略，因为它们被映射到非默认队列类中[ 本例中即为2q4t-in-q1]）。

但为了更好地理解这个策略的工作方式，有必要解释一下这里涉及的隐含逻辑。这就是重新标记行为对所有入站数据包生效，并且发生在CoS到队列的映射之前。这也就是为什么只有默认类别支持重新标记（作为入向队列策略的一部分）；因此重新标记行为会应用到所有入向数据包上。只有在重新标记之后，才会进行CoS到队列的映射。因此——在本例中——只有当所有入站数据包都被重新标记为CoS 0，这些数据包才会被映射到2q4t-in-q-default 入向队列中，管理员为这个入向队列分配了所有入向带宽和缓存。

这个不受信任的模型——需要注意的内容相同——也可以应用在F2系列模块上。重要的是管理员需要先复制入向队列策略，然后再修改它，例25-16展示的配置基于F2模块的默认（default-4q-8e-in-policy）策略模板。

例25-16 Nexus 7000不受信任的服务器模型:F2模块案例（基于默认策略模板）

! This section clones the F2 default ingress policy map

N7K(config)# qos copy policy-map type queuing default-4q-8e-in-policy prefix UNTRUSTED-

! Clones the default ingress queuing policy and prepends a prefix

! This section configures the ingress queuing policy map

N7K(config)# policy-map type queuing UNTRUSTED-4q-8e-in

N7K(config-pmap-que)# class type queuing 2q4t-8e-in-q1

N7K(config-pmap-c-que)# bandwidth percent 1

N7K(config-pmap-c-que)# queue-limit percent 1

! F2 modules require BW and QL for all queuing classes

! Therefore 1% BW and 1% QL represent the minimum provisions

N7K(config-pmap-c-que)# class type queuing 2q4t-8e-in-q-default

N7K(config-pmap-c-que)# bandwidth percent 99

N7K(config-pmap-c-que)# queue-limit percent 99

! All remaining BW and buffers are assigned to the default class

N7K(config-pmap-c-que)# set cos 0

! CoS is re-marked for all traffic hitting the default class

! This section configures the type qos re-marking policy map

N7K(config)# policy-map type qos UNTRUSTED-SERVER-QOS-POLICY

N7K(config-pmap-qos)# class class-default

N7K(config-pmap-c-qos)# set dscp 0

! All traffic is re-marked to DSCP 0

! Both re-marking policies are applied to the untrusted interface(s)

N7K(config)# interface ethernet 3/45

N7K(config-if)# service-policy type queuing input UNTRUSTED-4q-8e-in

N7K(config-if)# service-policy type qos input UNTRUSTED-SERVER-QOS-POLICY

注释:这个网络QoS模板需要为2q4t-8e-in-q1队列分配带宽和队列限制。为了满足这个配置需求，为其分配了最小值。但实际上这条队列是禁用的，所有流量都由默认的出向队列提供服务。

你可以使用以下命令来检查例25-16中的配置。

■ show class-map [ type { qos | queuing } ]

■ show policy-map [ type { qos | queuing } ]

■ show policy-map interface

25.4.3 单应用服务器标记模型

单应用服务器模型与不受信任的服务器模型相同，只是所有流量都会被重新标记为非零的CoS/DSCP值。

注释:如果在入向队列策略中重新标记了CoS值，并将其映射到非默认的入向队列中，要确保为这条入向队列分配适当的带宽和缓存。或者你也可以选择更简单的做法，干脆跳过入向队列中的重新标记CoS策略，通过type qos策略只重新标记DSCP。

25.4.4 多应用服务器分类和标记模型

在多应用服务器的分类和标记模型中，使用ACL来实现分类，并为流量标记DSCP值。这可能是因为应用服务器不标记流量，也可能是因为它用来标记流量的DSCP值与企业的QoS模型不相匹配。

让我们来看一个通用案例。假设网络团队要明确标记多媒体应用服务器的流量，将媒体流量识别并标记为AF41，将信令流量识别并标记为CS3，将会议数据（业务性数据）流量识别并标记为AF21，将所有其他流量标记为DSCP 0，详见例25-17。

例25-17 Nexus 7000 M2/F2模块多应用服务器分类和标记模型

! This section configures the class maps

N7K(config-cmap-qos)# class-map type qos MEDIA-FLOWS

N7K(config-cmap-qos)# match access-group name MEDIA-FLOWS

! Media flows are identified via MEDIA-FLOWS ACL

N7K(config-cmap-qos)# class-map type qos SIGNALING

N7K(config-cmap-qos)# match access-group name SIGNALING

! Signaling traffic is identified via SIGNALING ACL

N7K(config-cmap-qos)# class-map type qos CONFERENCING-DATA

N7K(config-cmap-qos)# match access-group name CONFERENCING-DATA

! Conferencing data traffic is identified via CONFERENCING-DATA ACL

! This section configures the classification and marking policy map

N7K(config-cmap-qos)# policy-map type qos MULTI-APP-SERVER

N7K(config-pmap-qos)# class type qos MEDIA-FLOWS

N7K(config-pmap-c-qos)# set dscp af41

! Media flows are marked DSCP AF41

N7K(config-pmap-c-qos)# class type qos SIGNALING

N7K(config-pmap-c-qos)# set dscp cs3

! Signaling flows are marked DSCP CS3

N7K(config-pmap-c-qos)# class type qos CONFERENCING-DATA

N7K(config-pmap-c-qos)# set dscp af21

! Conferencing data flows are marked DSCP AF21

N7K(config-pmap-c-qos)# class class-default

N7K(config-pmap-c-qos)# set dscp default

! This section applies the marking policy to the multi-app server int

N7K(config)# interface Ethernet 2/40

N7K(config-if)# service-policy type qos input MULTI-APP-SERVER

! Attaches the marking policy to the interface

你可以使用以下命令来检查例25-17中的配置。

■ show class-map [ type qos ]

■ show policy-map [ type qos ]

■ show policy-map interface

25.4.5 服务器限速模型

Nexus 7000 能够为M1、M2 和F2 模块提供丰富的限速特性，并在转发引擎中执行限速。这些模块可以支持以下限速:

■ 单速双色和双速三色汇聚限速；

■ 共享的限速器；

■ 感知门限值的限速。

注释:F1模块不支持任何限速功能。

在服务器限速模型中，可以测量一个或多个应用类，通过单速或双速限速器，根据遵守、超出和（可选）违反规则，将流量标记为不同的DSCP值。

在例25-18 中，使用RFC 2698 双速三色限速器来测量多媒体会议服务器上的媒体流量，并根据RFC 2597 中的降级规则，将其标记为DSCP AF4。遵守标记可以直接在命令中设置，但超出和违反重新标记值需要通过名为cir-markdown-map 和pir-markdown-map 的table map进行设置（默认根据RFC 2597 中的降级规则设置）。

例25-18 Nexus 7000 M2/F2模块的服务器限速模型

! This section configures the policing policy map

N7K(config)# policy-map type qos SERVER-POLICING

N7K(config-pmap-qos)# class class-default

N7K(config-pmap-c-qos)# police cir percent 50 pir percent 75 conform set-dscp

-transmit af41 exceed set dscp dscp table cir-markdown-map violate set dscp dscp table pir-markdown-map

! Traffic is policed a CIR of 50% and a PIR of 75%

! Conforming traffic is marked AF41

! Exceeding traffic is re-marked per the cir-markdown-map

! Violating traffic is re-marked per the pir-markdown-map

! This section applies the policing policy to the server int

N7K(config)# interface Ethernet 2/40

N7K(config-if)# service-policy type qos input SERVER-POLICING

! Attaches the marking policy to the interface

你可以使用以下命令来检查例25-18中的配置。

■ show table-map [ cir-markdown-map ]（详见例25-19）

■ show table-map [pir-markdown-map]（详见例25-20）

■ show class-map [type qos]

■ show policy-map [type qos]

■ show policy-map interface

例25-19 检查CIR降级值:show table-map cir-markdown-map

N7K# show table-map cir-markdown-map

Table-map cir-markdown-map

default copy

from 10,12 to 12

from 18,20 to 20

from 26,28 to 28

from 34,36 to 36

N7K#

注意例25-19 中的阴影部分，若流量超出CIR，AF41（DSCP 34）/AF42（DSCP 36）就会被重新标记为AF42（DSCP 36）。

例25-20 检查PIR降级值:show table-map pir-markdown-map

N7K# show table-map pir-markdown-map

Table-map pir-markdown-map

default copy

from 10,12 to 14

from 18,20 to 22

from 26,28 to 30

from 34,36 to 38

N7K#

注意例25-20 中的阴影部分，若流量违反PIR，AF41（DSCP 34）/AF42（DSCP 36）就会被重新标记为AF43（DSCP 38）。

25.4.6 DSCP变化模型

为了回避标记冲突的问题:信令（CS3/CoS 3）、多媒体流（AF3/CoS 3）和FCoE（CoS 3），你可能希望只在信令和多媒体流量在进入和离开数据中心网络时，针对这些流量改变DSCP标记；比如将CS3 和AF3 映射为CoS 4，并一对一地映射为非标准的DSCP 值。你可以通过一对互补的table-map命令来实现这一需求，详见例25-21。应该在数据中心与园区网相连的（比如M2模块的）接口上，在双方向上相应地应用这些策略。

注释:如果使用这种方法，你应该在服务器接口的入方向上，将DC发来流量中的信令和多媒体流量标记为这些非标准的DSCP值。

例25-21 Nexus 7000 DSCP变化策略去往/来自园区网络

! This section configures the DC-FROM-CAMPUS DSCP-mutation table map

N7K(config)# table-map DC-FROM-CAMPUS-TABLE-MAP

N7K(config-tmap)# default copy

! All DSCP values are copied 1:1 to themselves

! with the following modifications made:

N7K(config-tmap)# from 24 to 33

! CS3 (24) is coped to nonstandard DSCP 33 (that will map to CoS 4)

N7K(config-tmap)# from 26 to 35

! AF31 (26) is coped to nonstandard DSCP 35 (that will map to CoS 4)

N7K(config-tmap)# from 28 to 37

! AF32 (28) is coped to nonstandard DSCP 37 (that will map to CoS 4)

N7K(config-tmap)# from 30 to 39

! AF33 (30) is coped to nonstandard DSCP 39 (that will map to CoS 4)

! This section configures the DC-TO-CAMPUS DSCP-mutation table map

N7K(config)# table-map DC-TO-CAMPUS-TABLE-MAP

N7K(config-tmap)# default copy

! All DSCP values are copied 1:1 to themselves

! with the following modifications made:

N7K(config-tmap)# from 33 to 24

! CS3 (24) is restored from nonstandard DSCP 33

N7K(config-tmap)# from 35 to 26

! AF31 (26) is restored from nonstandard DSCP 35

N7K(config-tmap)# from 37 to 28

! AF32 (28) is restored from nonstandard DSCP 37

N7K(config-tmap)# from 39 to 30

! AF33 (30) is restored from nonstandard DSCP 39

! This section configures the DC-FROM-CAMPUS policy map

N7K(config)# policy-map type qos DC-FROM-CAMPUS-POLICY-MAP

N7K(config-pmap-qos)# class class-default

N7K(config-pmap-c-qos)# set dscp dscp table DC-FROM-CAMPUS-TABLE-MAP

! All DSCPs from campus are mutated by DC-FROM-CAMPUS-TABLE-MAP

! This section configures the DC-TO-CAMPUS policy map

N7K(config-pmap)# policy-map type qos DC-TO-CAMPUS-POLICY-MAP

N7K(config-pmap-qos)# class class-default

N7K(config-pmap-c-qos)# set dscp dscp table DC-TO-CAMPUS-TABLE-MAP

! All DSCPs to campus are mutated by DC-TO-CAMPUS-TABLE-MAP

! This section attaches the policy maps to DC-to-Campus interface(s)

N7K(config)# interface ethernet 1/32

N7K(config-if)# service-policy type qos input EQ82-DC-FROM-CAMPUS-POLICY-MAP

N7K(config-if)# service-policy type qos output EQ82-DC-TO-CAMPUS-POLICY-MAP

可以使用以下命令来检查例25-21中的配置。

■ show table-map

■ show policy-map [ type qos ]

■ show policy-map interface

■ show system internal ipqos table-map（详见例25-22）

例25-22 检查table map值:show system internal ipqos table-map

N7K# show system internal ipqos table-map

=======================================================

table-map:DC-TO-CAMPUS-TABLE-MAP (len:27)

default copy

ppf node id:0x4500333

ref_count:1

Bit array:33,35,37,39

Values set:

0　1　2　3　4　5　6　7

8　9 10 11 12 13 14 15

16 17 18 19 20 21 22 23

24 25 26 27 28 29 30 31

32 24 34 26 36 28 38 30

40 41 42 43 44 45 46 47

48 49 50 51 52 53 54 55

56 57 58 59 60 61 62 63

=======================================================

table-map:DC-FROM-CAMPUS-TABLE-MAP (len:29)

default copy

ppf node id:0x4500332

ref_count:1

Bit array:24,26,28,30

Values set:

0 1 2 3 4 5 6 7

8 9 10 11 12 13 14 15

16 17 18 19 20 21 22 23

33 25 35 27 37 29 39 31

32 33 34 35 36 37 38 39

40 41 42 43 44 45 46 47

48 49 50 51 52 53 54 55

56 57 58 59 60 61 62 63

=======================================================

N7K#

例25-22以列表的格式展示了DSCP到DSCP的映射，每行8个DSCP值且以升序排列。表示from的DSCP值是由表中的相应位置表示的；表示to的DSCP值是直接以数字的形式列在表中的。举例来说，在第一个表中，第5 行比较有趣（列出了所有映射为CoS 4 的DSCP值，因为这些值的3 MSB 都是4）:这一行的第1 个位置对应着DSCP 32，第2 个位置对应着DSCP 33，以此类推。正如阴影部分强调的，DSCP 33 并没有映射到自己，而是映射到24 （CS3）；DSCP 35、37 和39 相应地映射为26（AF31）、28（AF32）和30（AF33）。此外在第二个表（DC-FROM-CAMPUS-TABLE-MAP）中，第4行比较有趣:第24个位置（CS3）映射为33，AF31（26）、AF32（28）和AF33（30）分别映射到35、37和39。

25.5 CoPP设计

Nexus 7000 支持控制层面限速。控制层面限速设计的最佳做法请参考附录B。

注释:更多与平台相关的配置CoPP细节内容，请参考以下网址:http://www.cisco.com/en/US/docs/switches/datacenter/sw/6_x/nx-os/security/configuration/guide/b_Cisco_Nexus_7000_NX-OS_Security_Configuration_Guide__Release_6.x_chapter_011001.html。

25.6 小结

本章详细介绍了将Nexus 7000 系列交换机作为数据中心核心交换机，在其上实施QoS 设计的最佳做法建议。一上来先概述了Nexus 7000 的系统、M2 和F2 系列模块之间的区别、QoS执行的顺序，以及默认的信任状态。由于M2和F2系列模块上存在着架构和能力上的区别，因此QoS设计也是分别介绍的。

接下来的一部分讨论了M2模块的QoS设计，先介绍了M2模块的体系结构和QoS能力。M2模块支持4类和8类队列模型，而且建议使用M系列的模块（不支持FCoE）来连接CUCM——CUCM 使用CoS 3 来标记信令流量（这样支持FCoE 的F 系列模块就可以将CoS 3专用于FCoE流量了）。这部分还介绍了OTV，并且介绍了支持该服务的QoS设计建议。

接下来讨论了F2系列模块，概述并与M2模块对比了硬件体系结构。这部分详细介绍了网络QoS策略模版及其相应的默认队列模型；展示了在存在FCoE的环境中，启用4类和8类队列模型的案例。

之后讨论了两个系列模块都可以使用的其他QoS设计，其中包括受信任的/不受信任的服务器模型、服务器标记和限速模型。最后介绍了DSCP变化模型，可以以此来回避标记冲突问题:信令、多媒体流和FCoE 流量——这些流量默认都映射为CoS 3。

25.7 扩展阅读

Cisco Nexus 7000系列NX-OS QoS配置指南，6.x版本:http://www.cisco.com/en/US/docs/switches/datacenter/sw/6_x/nx-os/qos/configuration/guide/nx-os_qos_book.html

MSDC（大规模可扩展数据中心）设计和实施指南:http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/MSDC/1.0/MSDC1_C.html

Cisco OTV（覆盖传输虚拟化）技术的介绍和实施考量:http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/DCI/whitepaper/DCI3_OTV_Intro.html

NX-OS and Cisco Nexus Switching:Next-Generation Data Center Architectures (Second Edition) (Fuller, Jansen, McPherson; Cisco Press, 2013)

第26章 数据中心QoS设计的案例研究

Tifosi Software 公司已经根据战略8 类端到端QoS 模型，实施了园区网和WLAN 的QoS网络设计（详见第12章，图12-2展示了这一设计），现在网络团队要使这些策略适应并扩展到的多服务数据中心网络中。

Tifosi意识到，他们需要改良已有的战略8类模型（在每平台的基础上），使其能够适应数据中心环境，其中包括支持以下类型的流量:

■ VM控制协议；

■ vMotion；

■ FCoE。

为了处理这些多出来的流量类，并向其映射到固定的8队列硬件队列模型中，Tifosi的网络团队选择从数据中心内的队列模型中删除清道夫类。

Tifosi的多层数据中心网络构成如下所示:

■ Cisco Nexus 1000V 交换机作为虚拟访问边界；

■ Cisco Nexus 5500 系列交换机结合Nexus 2000 FEX 作为接入/ 汇聚层；

■ Cisco Nexus 7000 系列交换机结合M2 和F2 系列模块作为核心层。

Tifosi考虑了各种不同的服务器模型，并最终确定使用以下模型:

■ 受信任的服务器模型，大多数服务器（和所有交换机之间的链路）使用该模型；

■ 单应用服务器模型，只会为一小部分单应用服务器使用这种模型，这些单应用服务器无法标记CoS/DSCP值，或者标记的值不符合他们的战略QoS模型；

■ 多应用服务器模型，只会为一小部分多应用服务器使用这种模型，理由同上。

他们决定不使用无差别的不受信任的服务器模型，因为他们对数据中心的访问实施了严格的控制，只允许经核准的服务器安置在数据中心内；因此，经核准的服务器必须对应着一个（或多个）战略应用类别。

除此之外，他们还决定不使用限速服务器模型，因为限速是基于集合（Aggregate）实施的，而不像园区网是基于微流（Microflow）实施的。因此受到降级处罚的流是随机的，而并不是超出了预定限制的那一条流。他们准备在未来再重新考虑这个策略，尤其当Nexus交换家族能够支持微流限速之后。

Tifosi 在他们的数据中心内支持FCoE 流量——默认为其分配CoS 3，而且他们决定将CoS 3虚拟通道专用于FCoE。他们要使用以下方式来实现这种流量分隔。

■ Cisco CUCM 服务器、多媒体会议服务器（比如他们使用的微软Lync 服务器）和其他使用信令的VM，都会将信令流标记为DSCP CS3，这种标记会被信任。

■ Nexus 1000V 的入向策略会以不对称的方式将信令流量标记为CoS 4，然后将信令流量和多媒体会议流量放到同一条队列中。

■ Nexus 5500/2000的队列策略会根据DSCP（CS3）来对服务器发来的信令流量进行分类，并将信令流量分配到qos-group 4，然后将这个QoS 组映射到视频队列（这些流量会依照network-qos 策略被标记为CoS 4）。FCoE 流量会根据CoS 3 来进行分类，并会在专用的系统队列中接受服务。

■ Nexus 7000 上的数据中心/ 园区网边界策略会将园区网发来的CS3 流量重新标记为非标准的DSCP 33，这样向南传输的信令流量一旦通过F2 系列模块进入DCB 网络，就会被映射为CoS 4。

最后，Tifosi会通过OTV来连接他们的两个重要数据中心，并希望由OVT来支持他们的QoS策略。

图26-1展示了Tifosi综合的数据中心QoS策略。

下面将详细介绍这些数据中心QoS策略。

数据中心虚拟访问边界QoS策略

■ 策略1:受信任的VM（Nexus 1000V）:启用CoS 和DSCP 信任特性（默认设置）。

■ 策略2:单应用VM（Nexus 1000V）:明确配置CoS/DSCP 值。

■ 策略3:多应用VM（Nexus 1000V）:通过ACL 来分类流量，并根据应用类别来明确设置CoS/DSCP值。

■ 策略4:网络边界队列（Nexus 1000V）:为Tifosi 修改后的8 类战略模型启用出方向上基于协议或基于CoS的CBWFQ策略。

数据中心接入/汇聚层QoS策略

■ 策略5:受信任的服务器（Nexus 5500/2000）:

■ 启用CoS和DSCP信任特性（默认设置）；

图26-1 Tifosi Software案例研究:数据中心网络QoS设计

■ 为FCoE流量启用无损服务（默认）；

■ 为Tifosi修改后的8类战略模型启用入向队列；

■ 为Tifosi修改后的8类战略模型启用出向队列。

■ 策略6:单应用服务器（Nexus 5500/2000）:

■ 明确设置CoS和DSCP值；

■ 为FCoE流量启用无损服务（默认）；

■ 为Tifosi修改后的8类战略模型启用入向队列；

■ 为Tifosi修改后的8类战略模型启用出向队列。

■ 策略7:多应用服务器（Nexus 5500/2000）:

■ 通过ACL来分类流量，并根据应用类别来明确设置CoS/DSCP值；

■ 为FCoE流量启用无损服务（默认）；

■ 为Tifosi修改后的8类战略模型启用入向队列；

■ 为Tifosi修改后的8类战略模型启用出向队列。

■ 策略8:网络边界队列（Nexus 5500/2000）:

■ 启用CoS和DSCP信任特性（默认设置）；

■ 为FCoE流量启用无损服务（默认）；

■ 为Tifosi修改后的8类战略模型启用入向队列；

■ 为Tifosi修改后的8类战略模型启用出向队列。

数据中心核心层QoS策略

■ 策略9:网络边界队列（Nexus 7000 F2模块）:

■ 启用CoS和DSCP信任特性（默认设置）；

■ 为FCoE流量启用无损服务；

■ 为Tifosi修改后的8类战略模型启用入向队列；

■ 为Tifosi修改后的8类战略模型启用出向队列。

■ 策略10:网络边界队列（包括OTV边界）（Nexus 7000 M2模块）:

■ 启用CoS和DSCP信任特性（默认设置）；

■ 为Tifosi修改后的8类战略模型启用入向队列；

■ 为Tifosi修改后的8类战略模型启用出向队列。

■ 策略11:数据中心和园区网之间的DSCP变化（Nexus 7000 M2模块）:

■ 将园区网发来的DSCP CS3 流量在数据中心内映射为DSCP 33；

■ 为Tifosi修改后的8类战略模型启用入向队列；

■ 为Tifosi修改后的8类战略模型启用出向队列。

26.1 Tifosi数据中心虚拟接入层Nexus 1000V QoS设计

Tifosi 的数据中心虚拟接入层由Cisco Nexus 1000V 构成，并且应用了以下策略:

■ 受信任的VM策略；

■ 单应用VM策略；

■ 多应用VM策略；

■ 网络边界队列策略。

下面按顺序介绍这些虚拟接入层策略的配置。

26.1.1 策略1:受信任的VM

受信任的VM模型会信任VM设置的CoS/DSCP标记。不需要明确配置任何策略就可以启用这个模型，因为Nexus 1000V 默认就会同时信任CoS 和DSCP 值。但要注意的是，vEthernet接口不常是Trunk接口，因此这里只有DSCP标记。

26.1.2 策略2:单应用VM

使用单应用VM策略需要为源于VM的所有流量明确设置CoS/DSCP值，详见例26-1。

例26-1 Tifosi案例研究:虚拟访问边界设计，在Nexus 1000V上实施单应用VM策略

! This section configures a match-any IP ACL

N1KV(config)# ip access-list MATCH-ANY-ACL

N1KV(config-acl)# permit ip any any

! This section configures a match-any class map

N1KV(config)# class-map type qos MATCH-ANY

N1KV(config-cmap-qos)# match access-group name MATCH-ANY-ACL

! This section configures the policy map

N1KV(config)# policy-map type qos SINGLE-APP-VM

N1KV(config-pmap-qos)# class MATCH-ANY

N1KV(config-pmap-c-qos)# set dscp af21

N1KV(config-pmap-c-qos)# set cos 2

! This section applies the policy to a vEthernet port profile

N1KV(config)# port-profile type vethernet SINGLE-APP-VM

N1KV(config-port-prof)# service-policy type qos input SINGLE-APP-VM

你可以使用以下命令来检查例26-1中的配置。

■ show class-map type qos

■ show policy-map type qos

■ show port-profile name

■ show policy-map interface vethernet[ interface number ]

26.1.3 策略3:多应用VM

多应用VM策略通过ACL来分类流量，并根据应用类别来明确设置CoS/DSCP值，详见例26-2。本例中为多媒体会议、数据和尽力而为类别设置的CoS值都默认对应着它们的DSCP值；但为信令类别设置的CoS 值（CoS 4）却与它的DSCP 值不一致，这是为了避免与DCB网络中的FCoE流量相冲突。

例26-2 Tifosi案例研究:虚拟访问边界设计，在Nexus 1000V上实施多应用VM策略

! IP ACLs are assumed to be configured to identify

! media, signaling, and data flows

! This section configures the class maps

N1KV(config-cmap-qos)# class-map type qos MEDIA-FLOWS

N1KV(config-cmap-qos)# match access-group name MEDIA-FLOWS

N1KV(config-cmap-qos)# class-map type qos SIGNALING

N1KV(config-cmap-qos)# match access-group name SIGNALING

N1KV(config-cmap-qos)# class-map type qos CONFERENCING-DATA

N1KV(config-cmap-qos)# match access-group name CONFERENCING-DATA

! This section configures the policy map

N1KV(config)# policy-map type qos MULTI-APP-VM

N1KV(config-pmap-qos)# class type qos MEDIA-FLOWS

N1KV(config-pmap-c-qos)# set dscp af41

N1KV(config-pmap-c-qos)# set cos 4

N1KV(config-pmap-c-qos)# class type qos SIGNALING

N1KV(config-pmap-c-qos)# set dscp cs3

N1KV(config-pmap-c-qos)# set cos 4

N1KV(config-pmap-c-qos)# class type qos CONFERENCING-DATA

N1KV(config-pmap-c-qos)# set dscp af21

N1KV(config-pmap-c-qos)# set cos 2

N1KV(config-pmap-c-qos)# class class-default

N1KV(config-pmap-c-qos)# set dscp 0

N1KV(config-pmap-c-qos)# set cos 0

! This section applies the policy to a vEthernet port profile

N1KV(config)# port-profile type vethernet MULTI-APP-VM

N1KV(config-port-prof)# service-policy type qos input MULTI-APP-VM

你可以使用以下命令来检查例26-2中的配置。

■ show class-map type qos

■ show policy-map type qos

■ show port-profile name

■ show policy-map interface vethernet[ interface number ]

26.1.4 策略4:网络边界队列

虚拟接入层网络边界队列策略为Tifosi修改后的8类战略模型启用了CBWFQ，以此满足以下流量的需求:

■ Nexus 1000V 控制流量；

■ VM控制和管理流量；

■ vMotion；

■ Tifosi的战略性应用类别。

如前所述，网络团队从Tifosi的数据中心队列模型中删除了清道夫类；并且在这种情况下，添加了实时交互性流量类，这个类别只为去往/ 来自Cisco TelePresence 会议服务器的流量提供服务（这类服务器安装在物理服务器上，位于接入/汇聚层）。

在本例中，信令流量（在之前的策略中已经被标记为CoS 4）会与多媒体会议流量（被标记为CoS 4）一同被分配到相同的出向队列中（因为在本书写作时，Nexus 1000V 不支持DSCP到队列的映射）。

图26-2展示了Tifosi的虚拟接入层网络边界队列策略的配置。

图26-2 Tifosi Software案例研究:Nexus 1000V出向CBWFQ模型

例26-3中给出了虚拟接入层网络边界队列策略的配置。

例26-3 Tifosi案例研究:虚拟接入层，Nexus 1000V上的网络边界队列策略

! This section configures the class maps

N1KV(config)# class-map type queuing match-any N1KV-CONTROL

N1KV(config-cmap-que)# match protocol n1k_control

N1KV(config-cmap-que)# match protocol n1k_packet

N1KV(config-cmap-que)# match protocol n1k_mgmt

N1KV(config-cmap-que)# class-map type queuing match-all VM-CONTROL

N1KV(config-cmap-que)# match protocol vmw_mgmt

N1KV(config-cmap-que)# class-map type queuing match-all VMOTION

N1KV(config-cmap-que)# match protocol vmw_vmotion

N1KV(config-cmap-que)# class-map type queuing match-all NETWORK-CONTROL

N1KV(config-cmap-que)# match cos 6

N1KV(config-cmap-que)# class-map type queuing match-all VOICE

N1KV(config-cmap-que)# match cos 5

N1KV(config-cmap-que)# class-map type queuing match-all MULTIMEDIA-CONFERENCING-SIGNALING

N1KV(config-cmap-que)# match cos 4

N1KV(config-cmap-que)# class-map type queuing match-all TRANSACTIONAL-DATA

N1KV(config-cmap-que)# match cos 2

N1KV(config-cmap-que)# class-map type queuing match-all BULK-DATA

N1KV(config-cmap-que)# match cos 1

! This section configures the CBWFQ policy map

N1KV(config)# policy-map type queuing N1KV-CBWFQ

N1KV(config-pmap-que)# class type queuing N1KV-CONTROL

N1KV(config-pmap-c-que)# bandwidth percent 3

N1KV(config-pmap-c-que)# class type queuing VM-CONTROL

N1KV(config-pmap-c-que)# bandwidth percent 4

N1KV(config-pmap-c-que)# class type queuing VMOTION

N1KV(config-pmap-c-que)# bandwidth percent 20

N1KV(config-pmap-c-que)# class type queuing NETWORK-CONTROL

N1KV(config-pmap-c-que)# bandwidth percent 3

N1KV(config-pmap-c-que)# class type queuing VOICE

N1KV(config-pmap-c-que)# bandwidth percent 5

N1KV(config-pmap-c-que)# class type queuing MULTIMEDIA-CONFERENCING-SIGNALING

N1KV(config-pmap-c-que)# bandwidth percent 20

N1KV(config-pmap-c-que)# class type queuing TRANSACTIONAL-DATA

N1KV(config-pmap-c-que)# bandwidth percent 15

N1KV(config-pmap-c-que)# class type queuing BULK-DATA

N1KV(config-pmap-c-que)# bandwidth percent 15

! This section attaches the policy to the uplink port profile

N1KV(config)# port-profile type ethernet UPLINK

N1KV(config-port-prof)# service-policy output N1KV-CBWFQ

你可以使用以下命令来检查例26-3中的配置。

■ show class-map [ type queuing ]

■ show policy-map [ type queuing ]

■ show port-profile name

■ show policy-map interface

■ module vem[ module-number ] execute vemcmd show qos node

■ module vem[ module-number ] execute vemcmd show qospinst[ uplink LTL ]

26.2 Tifosi数据中心接入/汇聚层Nexus 5500/2000 QoS设计

Tifosi 的数据中心接入/ 汇聚层由Cisco Nexus 5500 交换机和Nexus 2000 FEX 构成，并且应用了以下策略:

■ 受信任的服务器；

■ 单应用服务器；

■ 多应用服务器；

■ 网络边界队列。

下面按顺序介绍这些接入/汇聚层策略的配置。

26.2.1 策略5:受信任的服务器

受信任的服务器策略启用了CoS和DSCP信任特性，并为FCoE流量提供无损服务（这些功能在Nexus 5500 上都是默认启用的）。这个策略中唯一需要明确配置的元素是队列策略，这将在策略8中进行介绍（策略5～8中的队列策略不仅相同且篇幅较长，为了减少内容重复此处不作详述）。

26.2.2 策略6:单应用服务器

单应用服务器策略为所有源于服务器的流量都明确设置了CoS和DSCP标记，为FCoE流量提供无损服务（默认启用），需要配置队列策略（详见策略8），详见例26-4。

例26-4 Tifosi案例研究:接入/汇聚边界设计，在Nexus 5500/2000上实施单应用服务器策略

! This section configures a match-any IP ACL

N5K(config)# ip access-list MATCH-ANY-ACL

N5K(config-acl)# permit ip any any

! This section configures a type qos match-any class map

N5K(config)# class-map type qos MATCH-ANY

N5K(config-cmap-qos)# match access-group name MATCH-ANY-ACL

! This section configures the marking policy map

N5K(config)# policy-map type qos SINGLE-APP-SERVER

N5K(config-pmap-qos)# class type qos MATCH-ANY

N5K(config-pmap-c-qos)# set qos-group 2

N5K(config-pmap-c-qos)# set dscp af21

! This section attaches the type qos policy to the interface(s)

N5K(config)# interface ethernet 1/15-18

N5K(config-if-range)# service-policy type qos input SINGLE-APP-SERVER

! This section configures the network-qos class map

N5K(config)# class-map type network-qos CLASS-2

N5K(config-cmap-nq)# match qos-group 2

! This section configures the network-qos policy map

N5K(config)# policy-map type network-qos NETWORK-QOS-POLICY

N5K(config-pmap-nq)# class type network-qos CLASS-2

N5K(config-pmap-nq)# set cos 2

! This section applies the network-qos policy map to system qos

N5K(config)# system qos

N5K(config-sys-qos)# service-policy type network-qos NETWORK-QOS-POLICY

你可以使用以下命令来检查例26-4中的配置。

■ show class-map type [ qos| network-qos]

■ show policy-map type [ qos| network-qos]

■ show policy-map [ interface | system ]

26.2.3 策略7:多应用服务器

多应用服务器策略通过ACL来分类流量，并根据流量类别来明确设置CoS/DSCP值；为FCoE流量提供无损服务（默认），需要配置队列策略（详见策略8），详见例26-5。

需要注意的是，尽管信令流量被标记为DSCP CS3，但它的CoS 值却被不对称地映射为CoS 4，这样就不会与针对FCoE 流量实施的上游策略冲突了。

例26-5 Tifosi案例研究:接入/汇聚边界设计，在Nexus 5500/2000上实施多应用服务器策略

! IP ACLs are assumed to be configured to identify

! media, signaling and data flows

! This section configures the type qos class-maps

N5K(config-cmap-qos)# class-map type qos MEDIA-FLOWS

N5K(config-cmap-qos)# match access-group name MEDIA-FLOWS

N5K(config-cmap-qos)# class-map type qos SIGNALING

N5K(config-cmap-qos)# match access-group name SIGNALING

N5K(config-cmap-qos)# class-map type qos TRANSACTIONAL-DATA

N5K(config-cmap-qos)# match access-group name TRANSACTIONAL-DATA

! This section configures the type qos marking policy map

N5K(config)# policy-map type qos MULTI-APP-SERVER

N5K(config-pmap-qos)# class type qos MEDIA-FLOWS

N5K(config-pmap-c-qos)# set qos-group 4

N5K(config-pmap-c-qos)# set dscp af41

N5K(config-pmap-c-qos)# class type qos SIGNALING

N5K(config-pmap-c-qos)# set qos-group 3

N5K(config-pmap-c-qos)# set dscp cs3

N5K(config-pmap-c-qos)# class TRANSACTIONAL-DATA

N5K(config-pmap-c-qos)# set qos-group 2

N5K(config-pmap-c-qos)# set dscp af21

N5K(config-pmap-c-qos)# class type qos class-default

N5K(config-pmap-c-qos)# set dscp 0

! This section attaches the policy map to the interface(s)

N5K(config)# interface ethernet 1/1-4

N5K(config-if-range)# service-policy type qos input MULTI-APP-SERVER

! This section configures the network-qos class-maps

N5K(config-cmap-nq)# class-map type network-qos CLASS-2

N5K(config-cmap-nq)# match qos-group 2

N5K(config-cmap-nq)# class-map type network-qos CLASS-3

N5K(config-cmap-nq)# match qos-group 3

N5K(config-cmap-nq)# class-map type network-qos CLASS-4

N5K(config-cmap-nq)# match qos-group 4

! This section configures the network-qos policy map

N5K(config)# policy-map type network-qos NETWORK-QOS-POLICY

N5K(config-pmap-nq)# class type network-qos CLASS-2

N5K(config-pmap-nq-c)# set cos 2

N5K(config-pmap-nq-c)# class type network-qos CLASS-3

N5K(config-pmap-nq-c)# set cos 4

N5K(config-pmap-nq-c)# class type network-qos CLASS-4

N5K(config-pmap-nq-c)# set cos 4

! This section applies the network-qos policy map to system qos

N5K(config)# system qos

N5K(config-sys-qos)# service-policy type network-qos NETWORK-QOS-POLICY

你可以使用以下命令来检查例26-5中的配置。

■ show class-map type [ qos| network-qos]

■ show policy-map type [ qos| network-qos]

■ show policy-map [ interface | system ]

26.2.4 策略8:网络边界队列策略

接入/汇聚层网络边界队列策略会对网络控制流量、无损FCoE流量、vMotion流量和Tifosi的战略性应用类别（没有清道夫类）提供入向和出向队列。图26-3展示了最终的队列策略。

图26-3 Tifosi Software案例研究:Nexus 5500入向/出向队列模型

在本例中，使用CS3（向北传输的信令）或DSCP 33（向南传输的信令）来匹配信令流量，并将信令流量分配到视频/多媒体会议队列中。

除此之外，所有应用流量类别都会遵从network-qos策略，被标记为它们对应的CoS值，只有以下两个类别例外:

■ 实时交互流量（CS4）会被标记为CoS 5，从而获得优先级服务；

■ 信令流量（CS3）会被标记为CoS 4，从而避免针对FCoE 流量实施的上游策略冲突。

注释:假设已经通过Cisco UCS管理器上的QoS策略，将vMotion流量标记为CoS 1。

例26-6给出了接入/汇聚层网络边界队列策略的配置。

例26-6 Tifosi案例研究:接入/汇聚层，在Nexus 5500上实施网络边界队列策略

! This section configures the type qos class maps

N5K(config-cmap-qos)# class-map type qos match-any VOICE

N5K(config-cmap-qos)# match dscp ef

N5K(config-cmap-qos)# class-map type qos match-any REALTIME-INTERACTIVE

N5K(config-cmap-qos)# match dscp cs4

N5K(config-cmap-qos)# class-map type qos match-any MULTIMEDIA-CONFERENCING

N5K(config-cmap-qos)# match dscp af41 af42 af43

N5K(config-cmap-qos)# class-map type qos match-any SIGNALING

N5K(config-cmap-qos)# match dscp cs3 33

N5K(config-cmap-qos)# class-map type qos match-any TRANSACTINOAL-DATA

N5K(config-cmap-qos)# match dscp af21 af22 af23

N5K(config-cmap-qos)# class-map type qos match-any BULK-DATA

N5K(config-cmap-qos)# match dscp af11 af12 af13

N5K(config-cmap-qos)# class-map type qos match-any VMOTION

N5K(config-cmap-qos)# match cos 1

! This section configures the type qos policy map

N5K(config)# policy-map type qos MODIFIED-EIGHT-CLASS-QOS-POLICY

N5K(config-pmap-qos)# class VOICE

N5K(config-pmap-c-qos)# set qos-group 5

N5K(config-pmap-c-qos)# class REALTIME-INTERACTIVE

N5K(config-pmap-c-qos)# set qos-group 5

N5K(config-pmap-c-qos)# class MULTIMEDIA-CONFERENCING

N5K(config-pmap-c-qos)# set qos-group 4

N5K(config-pmap-c-qos)# class SIGNALING

N5K(config-pmap-c-qos)# set qos-group 4

N5K(config-pmap-c-qos)# class TRANSACTIONAL-DATA

N5K(config-pmap-c-qos)# set qos-group 3

N5K(config-pmap-c-qos)# class BULK-DATA

N5K(config-pmap-c-qos)# set qos-group 2

N5K(config-pmap-c-qos)# class VMOTION

N5K(config-pmap-c-qos)# set qos-group 2

N5K(config-pmap-c-qos)# class class-fcoe

N5K(config-pmap-c-qos)# set qos-group 1

! This section configures the network-qos class maps

N5K(config-cmap-nq)# class-map type network-qos PRIORITY-CLASS

N5K(config-cmap-nq)# match qos-group 5

N5K(config-cmap-nq)# class-map type network-qos VIDEO-CLASS

N5K(config-cmap-nq)# match qos-group 4

N5K(config-cmap-nq)# class-map type network-qos TRANS-DATA-CLASS

N5K(config-cmap-nq)# match qos-group 3

N5K(config-cmap-nq)# class-map type network-qos BULK-DATA-CLASS

N5K(config-cmap-nq)# match qos-group 2

! This section configures the network-qos policy map

N5K(config)# policy-map type network-qos MODIFIED-EIGHT-CLASS-NETWORK-QOS-POLICY

N5K(config-pmap-nq)# class type network-qos PRIORITY-CLASS

N5K(config-pmap-nq-c)# set cos 5

N5K(config-pmap-nq-c)# class type network-qos VIDEO-CLASS

N5K(config-pmap-nq-c)# set cos 4

N5K(config-pmap-nq-c)# class type network-qos TRANS-DATA-CLASS

N5K(config-pmap-nq-c)# set cos 2

N5K(config-pmap-nq-c)# class type network-qos BULK-DATA-CLASS

N5K(config-pmap-nq-c)# set cos 1

N5K(config-pmap-nq-c)# class type network-qos class-fcoe

N5K(config-pmap-nq-c)# pause no-drop

N5K(config-pmap-nq-c)# mtu 2158

! This section configures the queuing class maps

N5K(config-cmap-que)# class-map type queuing PRIORITY-QUEUE

N5K(config-cmap-que)# match qos-group 5

N5K(config-cmap-que)# class-map type queuing VIDEO-QUEUE

N5K(config-cmap-que)# match qos-group 4

N5K(config-cmap-que)# class-map type queuing TRANS-DATA-QUEUE

N5K(config-cmap-que)# match qos-group 3

N5K(config-cmap-que)# class-map type queuing BULK-DATA-QUEUE

N5K(config-cmap-que)# match qos-group 2

! This section configures the queuing policy map

N5K(config)# policy-map type queuing MODIFIED-EIGHT-CLASS-QUEUING-POLICY

N5K(config-pmap-que)# class type queuing PRIORITY-QUEUE

N5K(config-pmap-c-que)# priority

N5K(config-pmap-c-que)# class type queuing VIDEO-QUEUE

N5K(config-pmap-c-que)# bandwidth percent 25

N5K(config-pmap-c-que)# class type queuing TRANS-DATA-QUEUE

N5K(config-pmap-c-que)# bandwidth percent 15

N5K(config-pmap-c-que)# class type queuing BULK-DATA-QUEUE

N5K(config-pmap-c-que)# bandwidth percent 25

N5K(config-pmap-c-que)# class type queuing class-fcoe

N5K(config-pmap-c-que)# bandwidth percent 20

N5K(config-pmap-c-que)# class type queuing class-default

N5K(config-pmap-c-que)# bandwidth percent 15

! This section applies the network-qos and queuing policies

! to system qos

N5K(config)# system qos

N5K(config-sys-qos)# service-policy type network-qos MODIFIED-EIGHT-CLASS-NETWORK-QOS-POLICY

N5K(config-sys-qos)# service-policy type qos input MODIFIED-EIGHT-CLASS-QUEUING-POLICY

N5K(config-sys-qos)# service-policy type queuing output MODIFIED-EIGHT-CLASS-QUEUING-POLICY

你可以使用以下命令来检查例26-6中的配置。

■ show class-map type [ qos| network-qos| queuing ]

■ show policy-map type [ qos| network-qos| queuing ]

■ show policy-map [ interface | system ]

26.3 Tifosi数据中心核心层Nexus 7000 QoS设计

Tifosi 数据中心核心层由Cisco Nexus 7000 交换机、F2 模块和M2 模块构成；F2 模块负责将DCB网络扩展到核心层，M2模块提供第3层功能，负责连接园区网和OTV对等体。核心层包含如下QoS策略:

■ 网络边界队列（F2模块）；

■ 网络边界队列（M2模块）；

■ 园区网与数据中心之间针对信令流量的DSCP变化。

下面按顺序介绍这些核心层策略的配置。

26.3.1 策略9:网络边界队列（F2模块）

在针对F2模块实施的网络边界队列策略中，必须启用CoS和DSCP信任特性（默认就是启用的）。此外还要针对FCoE 流量提供无损服务，这可以通过在system qos 中应用default-nq-7e-policy模板来实现，之前的例26-6已经给出了相关配置。图26-4展示了这个策略模板所使用的应用到队列的映射。

注释:图26-4所示内容假设信令流量已经被标记为CoS 4（与前文案例的配置相符），假设vMotion流量已经被标记为CoS 1（比如通过Cisco UCS上的QoS策略）。

例26-7 中不仅给出了将nq-7e 策略模板应用到system qos 的配置，还针对默认队列策略做出了一些更改（尤其是将丢弃队列的入向缓存调整得更为平均）。

图26-4 Tifosi Software案例研究:Cisco Nexus 7000 F2模块（nq-7e:4Q1T入向/1P3Q1T出向）队列模型

例26-7 Tifosi案例研究:核心网络边界队列，在Nexus 7000 F2模块上实施（nq-7e 4Q1T入向/1P3Q1T出向）队列模型

! This section applies the default-nq-7e-policy to system qos

N7K(config)# system qos

N7K(config-sys-qos)# service-policy type network-qos default-nq-7e-policy

! This section clones the default 7e policy template

N7K# qos copy policy-map type queuing default-4q-7e-in-policy prefix MODIFIED-

! This section modifies the cloned ingress queuing policy

N7K(config)# policy-map type queuing MODIFIED-4q-7e-drop-in

N7K(config-pmap-que)# class type queuing 4q4t-7e-in-q1

N7K(config-pmap-c-que)# queue-limit percent 33

N7K(config-pmap-c-que)# class type queuing 4q4t-7e-in-q-default

N7K(config-pmap-c-que)# queue-limit percent 34

N7K(config-pmap-c-que)# class type queuing 4q4t-7e-in-q3

N7K(config-pmap-c-que)# queue-limit percent 33

! This section applies the modified queuing policy to the interface(s)

N7K(config)# interface Ethernet3/1-8

N7K(config-if-range)# service-policy type queuing input MODIFIED-4q-7e-in

你可以使用以下命令来检查例26-7中的配置。

■ show class-map type network-qos[ c-nq-7e-drop | c-nq-7e-ndrop-fcoe ]

■ show policy-map type network-qos[ default-nq-7e-policy ]

■ show policy-map system

■ show policy-map type queuing [ MODIFIED-4q-7e-in | MODIFIED-4q-7e-drop-in |MODIFIED-4q-7e-ndrop-in ]（假设使用的前缀是MODIFIED-）

■ show policy-map interface

26.3.2 策略10:网络边界队列（M2模块）

在针对M2模块实施的网络边界队列策略中，必须启用CoS和DSCP信任特性（默认就是启用的）。无需针对vMotion流量实施任何配置（因为假设这些模块工作在第3层），也无需针对FCoE 流量实施任何配置（反正这些模块也不支持FCoE），因此也就不存在CoS 3 冲突的问题了。与此同时，由于信令流量被映射为CoS 4（向北传输的流量是在虚拟接入层或接入/汇聚层被标记的，向南传输的流量是在DC与园区网互联的位置被标记的，详见策略11）， Tifosi 对该模型的修改导致这里不存在CoS 3 的流量。因此可以将所有分配给CoS 3 队列的带宽和缓存都重新分配给CoS 4 队列（信令流量属于这条队列），如图26-5 所示。

除此之外，由于这个服务策略通过一个专用的类别对网络控制和网间控制流量提供保护，那么这个策略也支持OTV互联流量。

例26-8 给出了Tifosi M2 模块上的入向和出向队列模型配置。

例26-8 Tifosi案例研究:核心层网络边界队列，在Nexus 7000 M2模块上实施（8Q2T入向/1P7Q4T出向）队列模型

! This section configures the ingress queuing class maps

N7K(config-cmap-que)# class-map type queuing match-any 8q2t-in-q1

N7K(config-cmap-que)# match cos 5

N7K(config-cmap-que)# class-map type queuing match-any 8q2t-in-q2

N7K(config-cmap-que)# match cos 7

N7K(config-cmap-que)# class-map type queuing match-any 8q2t-in-q3

N7K(config-cmap-que)# match cos 6

N7K(config-cmap-que)# class-map type queuing match-any 8q2t-in-q4

N7K(config-cmap-que)# match cos 4

N7K(config-cmap-que)# class-map type queuing match-any 8q2t-in-q5

N7K(config-cmap-que)# match cos 3

N7K(config-cmap-que)# class-map type queuing match-any 8q2t-in-q6

N7K(config-cmap-que)# match cos 2

N7K(config-cmap-que)# class-map type queuing match-any 8q2t-in-q7

N7K(config-cmap-que)# match cos 1

! This section configures the egress queuing class maps

N7K(config-cmap-que)# class-map type queuing match-any 1p7q4t-out-pq1

N7K(config-cmap-que)# match cos 5

N7K(config-cmap-que)# class-map type queuing match-any 1p7q4t-out-q2

N7K(config-cmap-que)# match cos 7

N7K(config-cmap-que)# class-map type queuing match-any 1p7q4t-out-q3

N7K(config-cmap-que)# match cos 6

N7K(config-cmap-que)# class-map type queuing match-any 1p7q4t-out-q4

N7K(config-cmap-que)# match cos 4

N7K(config-cmap-que)# class-map type queuing match-any 1p7q4t-out-q5

N7K(config-cmap-que)# match cos 3

N7K(config-cmap-que)# class-map type queuing match-any 1p7q4t-out-q6

N7K(config-cmap-que)# match cos 2

N7K(config-cmap-que)# class-map type queuing match-any 1p7q4t-out-q7

N7K(config-cmap-que)# match cos 1

! This section configures the 8Q2T ingress queuing policy map

N7K(config)# policy-map type queuing 8Q2T-INGRESS

N7K(config-pmap-que)# class type queuing 8q2t-in-q1

N7K(config-pmap-c-que)# bandwidth percent 10

N7K(config-pmap-c-que)# queue-limit percent 10

N7K(config-pmap-c-que)# class type queuing 8q2t-in-q2

N7K(config-pmap-c-que)# bandwidth percent 5

N7K(config-pmap-c-que)# queue-limit percent 5

N7K(config-pmap-c-que)# class type queuing 8q2t-in-q3

N7K(config-pmap-c-que)# bandwidth percent 5

N7K(config-pmap-c-que)# queue-limit percent 5

N7K(config-pmap-c-que)# class type queuing 8q2t-in-q4

N7K(config-pmap-c-que)# bandwidth percent 35

N7K(config-pmap-c-que)# queue-limit percent 35

N7K(config-pmap-c-que)# random-detect cos-based

N7K(config-pmap-c-que)# random-detect cos 4 minimum-threshold percent 80 maximum-threshold percent 100

N7K(config-pmap-c-que)# class type queuing 8q2t-in-q5

N7K(config-pmap-c-que)# class type queuing 8q2t-in-q6

N7K(config-pmap-c-que)# bandwidth percent 10

N7K(config-pmap-c-que)# queue-limit percent 10

N7K(config-pmap-c-que)# random-detect cos-based

N7K(config-pmap-c-que)# random-detect cos 2 minimum-threshold percent 80 maximum-threshold percent 100

N7K(config-pmap-c-que)# class type queuing 8q2t-in-q7

N7K(config-pmap-c-que)# bandwidth percent 10

N7K(config-pmap-c-que)# queue-limit percent 10

N7K(config-pmap-c-que)# random-detect cos-based

N7K(config-pmap-c-que)# random-detect cos 1 minimum-threshold percent 80 maximum-threshold percent 100

N7K(config-pmap-c-que)# class type queuing 8q2t-in-q-default

N7K(config-pmap-c-que)# bandwidth percent 25

N7K(config-pmap-c-que)# queue-limit percent 25

N7K(config-pmap-c-que)# random-detect cos-based

N7K(config-pmap-c-que)# random-detect cos 0 minimum-threshold percent 80 maximum-threshold percent 100

! This section configures the 1P7Q4T egress queuing policy map

N7K(config)# policy-map type queuing 1P7Q4T-EGRESS

N7K(config-pmap-que)# class type queuing 1p7q4t-out-pq1

N7K(config-pmap-c-que)# priority

N7K(config-pmap-c-que)# queue-limit percent 10

N7K(config-pmap-c-que)# class type queuing 1p7q4t-out-q2

N7K(config-pmap-c-que)# bandwidth remaining percent 5

N7K(config-pmap-c-que)# queue-limit percent 5

N7K(config-pmap-c-que)# class type queuing 1p7q4t-out-q3

N7K(config-pmap-c-que)# bandwidth remaining percent 5

N7K(config-pmap-c-que)# queue-limit percent 5

N7K(config-pmap-c-que)# class type queuing 1p7q4t-out-q4

N7K(config-pmap-c-que)# bandwidth remaining percent 35

N7K(config-pmap-c-que)# queue-limit percent 35

N7K(config-pmap-c-que)# random-detect cos-based

N7K(config-pmap-c-que)# random-detect cos 4 minimum-threshold percent 80 maximum-threshold percent 100

N7K(config-pmap-c-que)# class type queuing 1p7q4t-out-q5

N7K(config-pmap-c-que)# class type queuing 1p7q4t-out-q6

N7K(config-pmap-c-que)# bandwidth remaining percent 10

N7K(config-pmap-c-que)# queue-limit percent 10

N7K(config-pmap-c-que)# random-detect cos-based

N7K(config-pmap-c-que)# random-detect cos 2 minimum-threshold percent 80 maximum-threshold percent 100

N7K(config-pmap-c-que)# class type queuing 1p7q4t-out-q7

N7K(config-pmap-c-que)# bandwidth remaining percent 10

N7K(config-pmap-c-que)# queue-limit percent 10

N7K(config-pmap-c-que)# random-detect cos-based

N7K(config-pmap-c-que)# random-detect cos 1 minimum-threshold percent 80 maximum-threshold percent 100

N7K(config-pmap-c-que)# class type queuing 1p7q4t-out-q-default

N7K(config-pmap-c-que)# bandwidth remaining percent 35

N7K(config-pmap-c-que)# queue-limit percent 25

N7K(config-pmap-c-que)# random-detect cos-based

N7K(config-pmap-c-que)# random-detect cos 0 minimum-threshold percent 80 maximum-threshold percent 100

! This section applies the queuing policies to the interface(s)

N7K(config)# interface Ethernet 1/1-4

N7K(config-if-range)# service-policy type queuing input 8Q2T-INGRESS

N7K(config-if-range)# service-policy type queuing output 1P7Q4T-EGRESS

图26-5 Tifosi Software案例研究:Cisco Nexus 7000 M2模块（8Q2T入向/1P7Q4T出向）队列模型

你可以使用以下命令来检查例26-8中的配置。

■ show class-map [ type queuing ]

■ show policy-map [ type queuing ]

■ show policy-map interface

26.3.3 策略11:园区网与数据中心之间针对信令流量的DSCP变化

Tifosi选择在DCB网络中将信令流量和FCoE流量区分开来。因此他们选择将从园区网收到的向南传输的信令流量映射为非标准的DSCP 33（这个DSCP值默认是由CoS 4映射过来的），详见例26-9。

例26-9 Tifosi案例研究:园区网与数据中心之间针对信令流量的DSCP变化

! This section configures the type qos class map

N7K(config)# class-map type qos match-any CAMPUS-SIGNALING

N7K(config-cmap-qos)# match dscp cs3

! This section configures the type qos re-marking policy map

N7K(config-cmap-qos)# policy-map type qos CAMPUS-CS3-TO-DC-DSCP33

N7K(config-pmap-qos)# class CAMPUS-SIGNALING

N7K(config-pmap-c-qos)# set dscp 33

! This section applies the re-marking policies to the int(s)

! And the queuing policies to the interface(s)

N7K(config)# interface Ethernet 1/5-6

N7K(config-if-range)# service-policy type qos input CAMPUS-CS3-TO-DC-DSCP33

N7K(config-if-range)# service-policy type queuing input 8Q2T-INGRESS

N7K(config-if-range)# service-policy type queuing output 1P7Q4T-EGRESS

你可以使用以下命令来检查例26-9中的配置。

■ show class-map

■ show policy-map

■ show policy-map interface

26.4 小结

本章继续使用Tifosi Software 公司的案例进行学习，在其数据中心环境中应用了战略8 类端到端QoS模型，其中要求在QoS策略中包含数据中心协议，比如VM控制协议、vMotion和FCoE（它需要无损服务）。

在Nexus 1000V 交换机上实施虚拟接入层策略，提供了受信任的VM 策略、单应用VM策略和多应用VM策略，并实施了CBWFQ出向（上行链路）队列模型。

此外，在Nexus 5500 交换机和Nexus 2000 FEX 模块上实施接入/ 汇聚层策略，提供了相同的入向模型（受信任的服务器策略、单应用服务器策略和多应用服务器策略），结合使用了network-qos策略，以及入向和出向队列策略。

之后在Nexus 7000 交换机上实施核心层策略，给出了F2 模块和M2 模块上的队列配置。

与此同时，这些设计之间还涉及一个战略:在DCB网络中分离信令流量和FCoE流量，使CoS 3虚拟通道专用于FCoE流量。实现这一需求的方法中包括使用非对称的DSCP/CoS标记、DSCP到队列的映射（如果支持的话）以及在园区网/DC互联的位置实施DSCP变化特性。

26.5 扩展阅读

Nexus 1000V QoS 配置指南，NX-OS 4.2(1)SV2(1.1) 版本:http://www.cisco.com/en/US/docs/switches/datacenter/nexus1000/sw/4_2_1_s_v_2_1_1/qos/configuration/guide/b_Quality_of_Service_Configuration_Guide_Release_4_2_1SV2_1_1.html

Nexus 5500 QoS 配置指南，NX-OS 6.0(2)N1(2) 版本:http://www.cisco.com/en/US/docs/switches/datacenter/nexus5500/sw/qos/602_N1_2/b_5500_QoS_Config_602N12.html

Cisco Nexus 7000系列NX-OS QoS配置指南，6.x版本:http://www.cisco.com/en/US/docs/switches/datacenter/sw/6_x/nx-os/qos/configuration/guide/nx-os_qos_book.html

第6部分 WAN和分支QoS设计

第27章 WAN和分支QoS设计的注意事项与建议

富媒体WAN和分支网络中的QoS有以下两个角色:

■ 通过队列策略来管理数据包丢失（和抖动）；

■ 通过深层数据包检测引擎来增强分类粒度。

本书前面的内容中已经详细讨论了丢包会对实时应用造成的影响。然而数据包抖动（多发生在WAN/分支边界，因为在这里链路速率会大幅下降）也会对语音和视频质量带来类似的影响。

抖动是指在相同的数据流中，一个数据包遭遇的延迟与另一个数据包遭遇的延迟有所变化。过多的数据包抖动会对实时应用的质量带来负面影响。在一些情况中，极度延迟的数据包所来的影响与被丢弃的数据包带来的影响完全相同（极度延迟最终会由于接收方的去抖动缓存溢出，而成为丢包）。RFC 3393（IP 性能度量中的IP 数据包延迟变化的度量）中详细解释了抖动。

数据包丢失和数据包抖动都可以通过在WAN和分支上实施QoS来得到缓解和管理。

除此之外，由于Cisco IOS 提供了更细致的分类粒度——多亏了这些工具:媒体网应用元数据（MedianetApplication Metadata）和AVC NBAR2（应用可视性和控制，基于网络的应用识别2）分类——你可以在WAN和分支边界上使用这些工具，来增强应用分类策略。

有以下战略QoS设计准则（详见第11章）能够应用在WAN和分支QoS设计中。

■ 优先选择在硬件上实施QoS，别无他选时再实施软件QoS:很多分类、标记和限速策略都可以在园区网/无线网边界平台的硬件中实施，这样做能够在执行QoS时，降低对（基于软件的）Cisco IOS 路由器（比如Cisco ISR G2）的处理负载要求。

■ 在技术条件和管理条件均可行的条件下，在尽可能靠近源的位置对应用进行分类和标记:有些分类策略可能会要求获得第7层感知的支持，继而可能无法在园区或分支Catalyst交换机上实施这些策略。因此WAN或分支路由器的入向边界可能是满足技术条件且最靠近源的精细分类实施位置。

■ 为了防止发生拥塞，在每个节点都启用队列策略，无论该节点发生拥塞的可能性有多小:按照战略业务重点，在所有WAN边界都启用队列策略。而且在某些罕见的情况下，在LAN边界也要启用队列策略。

■（可选）启用控制层面限速来保护控制层面和数据层面:增强数据中心网络架构的安全性，使用数据层面限速（清道夫类QoS）能够消除并抑制网络攻击。

在能够将这些战略QoS设计准则翻译成与平台相关的配置建议前，你需要考虑以下与WAN和分支相关的因素:

■ WAN和分支的体系结构；

■ 硬件与IOS软件的QoS；

■ 延迟和抖动；

■ Tx-Ring；

■ CBWFQ；

■ LLQ；

■ WRED；

■ RSVP；

■ 媒体网；

■ AVC；

■ AutoQoS；

■ CPP（控制层面限速）；

■ 链路类型和速率；

■ WAN和分支的QoS模型；

■ WAN和分支的接口QoS角色。

接下来按顺序讨论这些与WAN和分支相关的注意事项。

27.1 WAN和分支的体系结构

为了将企业园区网扩展到更广的范围中，并与其他园区/分支网络建立相互连接，通常需要部署一下两种类型的路由器:

■ WAN汇聚路由器；

■ 分支路由器。

WAN汇聚路由器能够将大型园区网络连接到WAN/VPN，分支路由器能够将小型分支LAN连接到WAN/VPN。图27-1展示了两类主要的WAN路由器。

图27-1 WAN和分支的体系结构和路由器角色

这一部分将分别介绍WAN汇聚路由器和分支路由器的QoS设计。

注释:本书的这一部分（“WAN和分支的QoS设计”）将介绍关于范围内QoS设计的基础内容，并会利用私有WAN媒介（串行/ATM/POS）；下面一部分（第7部分，“MPLS VPN设计”）会将以太网作为WAN/MAN的接入媒介；最后一部分（第8部分，“IPSec VPN设计”）能够建立更进一步的连接，可以在任何接入媒介上实施。

27.2 硬件与IOS软件的QoS

建议:

■ 要留意在IOS路由器中部署QoS策略所需的最低CPU开销；

■ 选择能够满足性能要求的路由器平台。

与媒体网络（Medianet）园区中使用的Cisco Catalyst 交换机不同（它能够在专用的硬件中实施QoS），多数Cisco 路由器（比如ISR/ISR G2）都在IOS 软件中执行QoS 操作；还有些平台（比如Cisco Catalyst 6500/7600 和Cisco ASR）同时在软件和硬件中执行QoS 操作。

IOS QoS 提供了如下优势。

■ 跨越平台获得一致的QoS特性:举例来说，使用与硬件相关的队列架构能够用在每平台或每线卡的基础上构建队列（比如在使用Cisco Catalyst 交换机的情况下），标准的软件队列特性（比如LLQ[低延迟队列]和CBWFQ[基于类的加权公平队列]）与此不同，你可以在跨越WAN和分支路由器平台的基础上使用这些特性。

■ 一致的QoS配置语法:在这些WAN和分支路由器平台上，基于IOS的QoS配置都使用MQC（模块化QoS CLI），这些命令的语法是一致的（也有极个别的例外）。

■ 丰富的QoS 特性:多数Catalyst 硬件平台上都无法支持多种IOS QoS 特性，比如NBAR/NBAR2和HQoS（分层的QoS）。

但是，尽管基于软件的QoS策略可以提供如此多的优势，在使用时你一定要记住以下警告:执行软件QoS策略所需的最低CPU负载。增加一个QoS策略所带来的CPU负载提升取决于多方面因素，其中包括路由器平台（比如有无硬件加速特性）、链路速率、策略复杂性、流量的模式以及数据包速率/大小。

表27-1总结了WAN和分支路由器通用的可扩展性指导数据（来自各自的产品一览表）。然而有一点无论如何强调都不为过:没有一种测试方法可以确保指定路由器的性能能够满足角色的需要。Cisco建议在WAN或分支路由器正常运行期间（包含所有QoS策略的运行），确保其CPU资源的消耗不超过75%，这是为了确保CPU总是有能力高效率地对网络事件做出响应。如果WAN汇聚或分支路由器在正常运行期间超出了75%的CPU利用率，那么升级硬件平台可能是个明智的选择。

表27-1 Cisco WAN和分支路由器平台一览表性能容量

27.3 延迟和抖动

建议:

■ 选择运营商来满足150毫秒的单向延迟。若无法满足这个目标，那么200毫秒通常也是可以接受的；

■ 要理解只有队列延迟是可以通过WAN QoS 策略进行管理的。

实时应用的延迟预算是固定的。举例来说，ITU G.114 规范将实时语音/ 视频会话的单向延迟设置为150毫秒。为了满足这一目标，管理员首先应该了解网络延迟的组成部分，这样才能知道哪些因素可以通过网络和QoS策略进行控制，哪些因素无法控制。网络延迟可以分为固定延迟和变化延迟:

■ 串行化延迟（固定）；

■ 传输延迟（固定）；

■ 队列延迟（变化）。

串行化是指设备将二层数据帧在传输媒介上转换为一层电/光脉冲所花费的时间。因此串行化延迟是固定的，取决于线路速率（也就是链路的时钟速率）。比如T1线路（1.544 Mbit/s）需要花费8毫秒，将1500字节的以太网数据帧串行到链路上；OC-192/STM-64线路（9.953 Gbit/s）仅需要花费1.2微秒，就能将相同大小的数据帧串行到链路上。

通常情况下，要想在WAN链路上满足延迟要求，最重要的网络因素是传输延迟，它要占用超过95%的网络延迟预算。传输延迟也是固定的，它取决于从源端点到目的端点之间，信号需要传输的物理距离。在传输延迟的计算中，额定系数是光速:真空中300 000 千米/ 秒，或186 000 英里/ 秒。因此大多数光纤线路上的传输延迟大概是6.3 微秒/ 千米，或8.2 微秒/英里。

在计算传输延迟时还有一点需要考虑:在两个地理位置之间物理部署的光纤链路并不总是这两个位置之间的最短物理路径，尤其是穿越大洋的链路。为了便于安装，实际的链路长度可能比理论需求长出几百甚至上千英里。而且路径中的中继器和放大器也会带来额外的延迟。因此，终端客户可能根本无法获知链路的路径和具体信息因此网络管理员必须了解SLA（服务等级协定），尤其要了解以下术语:最小、最大和平均端到端延迟。

尽管如此，G.114 规定的150 毫秒实时通信网络延迟预算还是包含了将近24 000 千米或15 000英里的传输延迟（这几乎是地球周长的60%）；理论上最差的环境（地球周长的整一半）也只需要126毫秒的延迟。因此，通常在任意两个位置之间通过相对直接的（陆地上的）路径都可以实现150毫秒的延迟目标。但是在有些环境中可能根本就无法实现这一延迟目标，这与地理距离以及传输路径的距离密不可分。在这种环境中，若由于距离导致无法实现G.114定义的150毫秒单向延迟目标，管理员应该要意识到，ITU和Cisco技术市场部门都指出当单向延迟超出了200 毫秒，实时通信质量才会大幅下降。图27-2 为ITU G.14 描绘的实施通话质量与绝对延迟之间的关系。

图27-2 ITU G.114描绘的实施通话质量与延迟

注释:到目前为止讨论的环境都是穿越陆地路径的WAN链路；对于卫星链路来说，延迟期望应该在250～900毫秒之间。以通过对地同步卫星来为信号实现中继为例，信号需要被发送到（赤道）海平面以上35 786千米（22 236英里）的太空中，然后再返回地球。管理员没有任何办法能够降低这种情况下的延迟，因为没什么办法能够提升光速和无线电波的速率。为了缓解这种情况下延迟带来的影响，唯一能做的只有培训用户，让他们对质量的期望变得现实一些。

最后一个需要考虑的网络延迟组成部分是队列延迟，它是可以发生变化的（变化的延迟也称作抖动）。队列延迟与网络节点是否拥塞息息相关，在拥塞发送时，设备会应用调度机制中的策略来解决拥塞问题。对于实时应用来说，它们通常对于抖动带来的影响更为敏感，而不是延迟；因为接收方在播放语音之前，会先将数据包放入去抖动缓存中。如果在去抖动缓存提供的时间窗口之内还未收到数据包，那么该数据包与被丢弃一样，都会对整体语音或视频呼叫质量造成影响。

考虑到导致网络延迟的大部分因素是固定的，更要谨慎对待队列延迟，因为这是管理员唯一能够（通过队列策略）直接控制的延迟因素。因此理解IOS的队列系统——其中包括Tx-Ring和LLQ/CBWFQ的工作原理——将有助于帮助网络管理员优化重要的策略。

27.4 Tx-Ring

建议:

■ 关注Tx-Ring的功能和深度；只在必要时调整。

Tx-Ring是WAN接口上最后的IOS输出缓存（相对较小的FIFO队列），WAN接口为了最大化物理链路的带宽利用率，按照物理接口速率来调整路由器上的出向数据包速率，并使两者相等。第5章已经介绍了Tx-Ring的工作原理，详见图5-4。

在某些平台上管理员可以使用接口命令tx-ring-limit来配置Tx-Ring，可以设置的值范围是1～32 767个数据包。默认的Tx-Ring值随着平台和链路类型及链路速率的不同，而有所变化。你可以使用命令show controllers interface |include tx 来查看Rx-Ring 的大小，详见例27-1。

例27-1 查看Tx-Ring的大小:show controllers | include tx_limited

Router# show controllers Serial 1/0 | include tx_limited

tx_underrun_err=0, tx_soft_underrun_err=0, tx_limited=1(64)

Router#

在例27-1中，Tx-Ring的默认值允许接口上排列64个数据包。

在Cisco技术市场部门对设计进行验证的阶段，一些接口上默认的Tx-Ring限制显然会为一些实时应用类流量带来更高的抖动，尤其是对基于HD（高清）视频的实时应用，比如Cisco TelePresence流量；这个结果是由HD视频流量的突发特性决定的。举例来说，假设在一条非常拥塞的T3 WAN链路上应用了LLQ/CBWFQ策略。本例中默认的Tx-Ring深度为64个数据包，详见例27-1。即使通过LLQ提升了TelePresence流量的优先级，若当前并没有TelePresence数据包等待发送，FIFO Tx-Ring 会被其他流量填满，即排入64 个其他数据包。假设这时到达了一个新的TelePresence数据包，即使它通过第3层LLQ/CBWFQ队列系统获得了优先享受服务的特权，也得等FIFO Tx-Ring 中有可用空间后，TelePresence 数据包才能排列进去。但是根据默认的设置，在TxRing中，会有63个数据包排列在TelePresence数据包之前。在这种最糟糕的情况下，设备需要话费17 毫秒，才能将这些非实时流量数据包发送出（45 Mbit/s）T3 接口。这个瞬时变化的17毫秒延迟（抖动）对TelePresence的视频质量带来的影响，已经足以让终端用户意识到了。

一方面，降低这条链路上的Tx-Ring值，能够强制IOS软件更快且更频繁地调用拥塞管理策略，并最终降低实时应用（比如TelePresence）的整体延迟值。另一方面，若将Tx-Ring值设置得过低，会导致CPU利用率急剧上升，因为处理器常常需要处理队列策略，即使导致拥塞的速率只是一次突发，并不是持续的高速率。因此在调整Tx-Ring值的时候，要权衡降低抖动和消耗CPU利用率之间的关系。

27.5 CBWFQ

建议:

■ 理解CBWFQ（基于类的加权公平队列）的工作原理和设计选项。

CBWFQ是一种IOS队列算法，它既能够为队列获得的带宽提供保障，又可以为一个流量类中的其他流量提供动态的公平服务。在第5章的图5-2中已经详细解释了CBWFQ的工作原理。

对于分配给CBWFQ类的带宽有一点很重要:分配的带宽值并不是固定的带宽预留值，而是当该类有需要传输的数据包时，确保该类可以获得的最少带宽量。如果该类没有需要传输的数据包，调度程序就可以服务下一条队列，并在必要时将空闲带宽动态地分配给其他队列。

除此之外，还可以使用fair-queue policy-map class 命令来为特定的CBWFQ 队列应用公平队列预选器。要注意的是，这条命令启用的是基于流的公平队列预选器，而不是特性名称暗示的加权公平队列预选器（也就是说公平队列预选器并不会根据IP优先级值将数据包分到指定类中）。举例来说，若为CBWFQ 队列分配了1 Mbit/s 带宽，而该类中包含4 条流，那么公平队列预选器就会确保每条流都获得带宽的（1/ 流的数量），在本例中也就是（1 Mbit/s 的1/4）250 Kbit/s 带宽。

注释:在IOS 12.4(20)T版本之前，公平队列预选器只能应用在默认类别（class-default）中。随着这个IOS版本的推出，能够支持HQF（分层的队列框架）的IOS允许将公平队列预选器应用到任意CBWFQ类中，并且还增强了其他QoS特性。

CBWFQ的深度是由它的队列限制定义的，队列限制的变化取决于链路速率和平台。你可以使用queue-limit policy-map class 命令来修改这个队列限制。这个队列限制通常是以数据包数量为单位的，但在有些平台上，也可能以字节数或毫秒为单位。有时候你可能希望增加队列限制，比如为突发应用实施了CBWFQ，但这个类中有大量丢包。

27.6 LLQ

建议:

■ 理解LLQ的工作原理和设计选项；

■ 在部署语音和实时视频应用时，使用双LLQ设计；

■ 限制所有LLQ使用33%带宽；

■ 在需要时调整突发参数。

LLQ（低延迟队列）实际上是CBWFQ队列结合一条严格优先级队列。如第5章讨论过的， IOS的LLQ中隐含一个限速器，能够提取并表现为“多条LLQ”，来为不同的流量类提供服务；但实际上只有单条LLQ。隐含LLQ限速器提供的功能可以用来保护多种类型的实时流量之间的相互干扰（比如保护语音流量免受突发实时视频流量的影响）。

注释:例5-3中展示了多LLQ的配置，图5-3中描绘了它的工作原理。

争抢严格优先级队列资源的流量，是按照先进先出的原则接受服务的，按照流量各自的限速器来放行数据包。因此LLQ类的配置顺序并不会带来其他好处或坏处。换句话说——回想例5-3——VoIP类并没有在广播视频或实时交互类之前获得服务，而是根据先进先出的原则接受服务，直到到达了限速器的限制为止。

在LLQ的配置中，最后一个需要考虑的因素是配置隐含LLQ限速器的突发参数，这个配置是优先级命令policy-map class 中的一个可选参数。由于流量速率不是稳定不变的，尤其是视频等应用，因此在LLQ隐含限速器看来，流量是呈次秒级突发的。举例来说，若为实时交互流配置了5 Mbit/s 流量，那么——假设流量速率是稳定的——限速器会期望每毫秒收到625字节流量（50 Mbit/s/1000 毫秒/8 比特）。但是对于突发的实时交互应用来说——比如Cisco Telepresence——这个稳定的次秒级流量速率并不普遍，反倒是次秒级突发流量比较常见。具体地说，一个Cisco TelePresence 摄像头可以在33 毫秒视频帧传输窗口期间带来高达64 KB的突发。因此为了适应这类应用，可能需要调整隐含LLQ限速器的突发参数。默认情况下， LLQ突发参数是按照200毫秒内流量可使用的配置带宽来计算的，当没有具体指定突发参数时就使用这种计算方法。突发参数的配置范围是32～2000000字节。

27.7 WRED

建议:

■ 理解基于DSCP的WRED的工作原理和优势；

■ 根据需要调整WRED门限值；

■ 根据需要启用ECN。

当使用诸如LLQ/CBWFQ的拥塞管理机制来管理队首时，可以使用诸如WRED（加权随机早期检测）的拥塞避免机制来管理队尾。拥塞避免机制可以很好地作用于基于TCP的应用，因为有选择地丢弃数据包，可以导致TCP滑动窗口机制“回缩”并将流速率调整至可控范围。

注释:图5-6展示了WRED的工作原理。

为了更好地与AF（确认转发）PHB（逐跳行为，定义在RFC 2597 中）相匹配，可以试用以下方法来明确调整基于DSCP的WRED门限值:

■ 将AFx3的最低WRED门限值设置为队列深度的60%；

■ 将AFx2的最低WRED门限值设置为队列深度的70%；

■ 将AFx1的最低WRED门限值设置为队列深度的80%；

■ 将所有最高WRED门限值设置为100%。

还可以使用WRED来设置RFC 3168 IP ECN（显式拥塞通知）位，来指示传输中遭遇了拥塞。可以通过在policy map 类中配置ecn 和random-detect 来启用ECN 功能。

27.8 RSVP

建议:

■ 为动态感知网络的准入控制需求启用RSVP；

■ 使用IntServ/DiffServ RSVP 模型来提高效率并增强可扩展性；

■ 使用应用识别RSVP策略来提升策略粒度。

第6章详细介绍了RSVP（资源预留协议）的功能和工作原理，并且强调了RSVP是目前唯一可用的可感知网络的准入控制机制。因此若需要这项功能，就必须在WAN和分支路由器上启用Cisco IOS RSVP 代理功能。

为了提高效率并增强可扩展性，建议通过IntServ/DiffServ（集成服务/差分服务）模型来部署RSVP，这样做时，RSVP只用来实现准入控制决定，DiffServ机制用来实现分类、标记、限速和调度机制功能。你可以通过接口命令ip rsvp data-packet classification none 和ip rsvp resource-provider none 来启用RSVP IntServ/DiffServ 模型。

除此之外，你还可以用更为精细的粒度来部署RSVP准入控制策略，即在预留请求（基于RFC 2872）中集成应用ID。在使用这项功能时，你可以配置不同的本地（每接口）RSVP策略，以每应用为基础来管理带宽请求，而不是在汇聚级别统一管理。

对于RSVP再说最后一句:它为网络管理员提供的最主要功能是动态且能够感知网络的准入控制，语音/视频网络更需要这项功能，单一的准入决定（比如决定是否允许发起Cisco TelePresence 呼叫）可以立即在链路上添加20 Mbit/s 甚至更多（潜在的）实时流量。

27.9 媒体网络

建议:

■（可以应用的话）使用媒体网元数据感知特性，在WAN上支持富媒体应用。

第8章中讨论了媒体网络工具，媒体网络技术集中包含以下工具:

■ 自动配置工具；

■ 媒体监控工具；

■ 媒体感知工具；

■ 媒体服务接口和代理。

可以在WAN和分支路由器上有效地部署媒体网络应用程序元数据分类引擎，来识别并分类WAN上传输的富媒体应用。

注释:还可以在WAN和分支路由器上应用其他媒体网络工具，比如媒体服务代理和媒体监控工具（其中包括媒体路径追踪、性能监控器和IP SLA视频操作）。由于本书着重于介绍QoS设计，因此并不会详细介绍这些管理和监控工具。

27.10 AVC

建议:

■ 按照需要使用NBAR2实现第7层分类。

第9章中介绍了AVC（应用可视控制）工具集，其中包含以下技术:

■ NBAR2；

■ FNF（灵活的NetFlow）；

■ 管理和报告应用。

在这些AVC工具中，与WAN和分支QoS设计关系最紧密的是NBAR2。如前所述，由于有太多的应用都运行在HTTP 上，因此使用简单的第4 层访问列表来匹配TCP 80 端口，常常无法满足基于应用程序的分类需求。这就需要实施更深的数据包检测，但由于Cisco Catalyst交换机不支持NBAR2（在本书写作时），因此实施这种深层检测的最近位置也许是WAN汇聚或分支路由器（LAN边界的入方向上）。

27.11 AutoQoS

Cisco AutoQoS 是WAN 和分支中的一项管理选项；第2章和附录A 中都对此进行了详细介绍。

27.12 控制层面限速

Cisco IOS 支持控制层面限速（CPP），附录B 中对该特性进行了详细介绍。

27.13 链路类型和速率

建议:

■ 富媒体WAN需要足够的带宽来支持基于视频的应用对于带宽的需求。

表27-2总结了WAN和分支平台所支持的链路类型和速率，本部分和第7部分都使用了这些平台。

表27-2 支持的链路类型和速率

注释:本书的这部分内容介绍了广域范围内设计的基础，因此会涉及私有WAN媒介（串行/ATM/POS）。在第7部分会涉及以太网，作为WAN/MAN的接入媒介。

注释:尽管这些平台可以支持串行链路DS0（链路速率64 kbit/s），但对于支持富媒体应用来说这个速率太慢了。因此在WAN和分支设计环境中，将只使用最低10 Mbit/s的速率。

注释:第8部分中介绍了宽频环境中低速链路的QoS设计。

注释:由于建议了最低链路速率，使用（密集计算）链路有效性机制不但变得不必要，而且还造成了浪费；链路有效性机制包括IP cRTP（RTP头部压缩）和LFI（链路分片和交叉）。因此这部分的设计中不包含这些工具。

27.14 WAN和分支QoS模型

建议:

■ 启用入向和出向QoS模型；

■ 有选择地启用CPP。

一般来说，在WAN和分支上配置QoS可以遵照以下两个主要（和一个可选）步骤。

1.应用入向QoS模型（如果需要的话）。

2.应用出向QoS模型。

3.（可选）启用CPP。

下面按顺序回顾这些模型。

27.14.1 入向QoS模型

建议:

■ IOS默认信任DSCP；

■ 根据需要在LAN边界启用入向NBAR2分类；

■ 根据需要启用入向/内部队列。

默认情况下，无论是第2 层CoS、第2.5 层MPLS EXP 还是第3 层DSCP，IOS 都会信任这些数据包标记。因此如果所有数据包都已经分类并标记好了，就无需在WAN和分支入向边界上明确配置QoS策略。

在需要使用深层数据包检测（NBAR2）来实现分类的情况下，可以在LAN边界应用这些策略，即WAN和分支路由器的入方向上。

在使用WAN和分支路由器环境中，造成拥塞的瓶颈一般不是路由器背板。但在结合使用ASR/ESP的环境中，路由器背板就可能是导致拥塞的瓶颈。因此为了解决特定环境中的问题，第28章介绍了入向/内部QoS建议和设计。

27.14.2 出向QoS模型

建议:

■ 在所有WAN边界接口部署出向队列策略；

■ LAN边界接口可能并不需要出向队列策略。

如前所述在第11章中，当为富媒体应用实施QoS时，应该在所有平台上实施以下基于标准的队列行为:

■ 实时队列（为了提供RFC 3246 EF PHB 服务）；

■ 保证带宽的队列（为了提供RFC 2579 AF PHB 服务）；

■ 默认队列（为了提供RFC 2474 DF 服务）；

■ 带宽约束队列（为了提供RFC 3663 清道夫服务）。

注释:与Cisco Catalyst交换机不同，IOS中的QoS并不受限于固定的队列数量，大多数平台都支持多达256条软件队列，远远超出管理员的需要了。

Cisco为这些队列类型提出了设计建议。

■ 对于实时队列来说，如前所述，经过广泛测试和客户部署，得出的最佳队列做法是限制严格优先级队列使用33%的链路带宽容量。在融合了实时应用和数据应用的网络中，这条严格优先级队列规则是保守且安全的设计系数。而且，任何被分配到严格优先级队列的流量都应该由准入控制机制进行管理。

注释:严格优先级队列规则仅仅是设计的最佳做法建议，并不是强制要求。可能对于某些案例来说，这个建议并无法满足业务的需求。这样的话，企业必须根据他们详细的需求和制约因素来部署队列机制。但是一定要了解与为严格优先级队列分配更多带宽相关的折中考虑，以及有可能为其他实施流量以及为其他非实时应用带来的负面影响（响应时间）。

■ 应该使用独立的CBWFQ来实施保证带宽的队列。可以为多媒体类和数据应用类启用公平队列预选器，来确保类别内的各个流之间的公平。除此之外，还可以启用（并在必要时调整）基于DSCP的WRED，将TCP全局同步问题最小化。在将CBWFQ 用于控制流量时，不建议启用公平队列预选器，也不建议启用基于DSCP的WRED（因为这些类中的流量不应该被重新排序，也不应该被丢弃）。

■ 建议为无用流量队列（比如清道夫队列）分配最少带宽。而且不应该为这种队列启用公平队列预选器或WRED（节省CPU资源，使其不用管理一开始就不提供服务保证的队列）。

■ 对于所有未被明确分配到另一个应用类队列的流量，它们的默认类别就是默认类/尽力而为类。只有为一个应用选择了优先/无保证服务，它才会被移出默认类。因为大多数企业在他们的网络中运行了上千个服务，为了让为数众多的默认就属于默认类的应用得到服务，必须为这个类分配足够的带宽。因此建议为默认/尽力而为类至少分配25%的链路带宽。建议为默认/尽力而为类启用公平队列预选器，比如WRED。

以上队列建议可以总结如下。

■ LLQ

■ 限制所有LLQ的总和占用33%带宽；

■ 使用准入控制机制对LLQ实施准入控制；

■ 不要在（对丢包敏感的）LLQ上启用WRED。

■ 多媒体/数据CBWFQ

■ 根据应用的需求，为其分配有保证的带宽；

■ 启用公平队列预选器；

■ 启用基于DSCP的WRED（必要时调整）。

■ 控制CBWFQ

■ 根据控制流量的需求，为其分配有保证的带宽；

■ 不要启用公平队列预选器；

■ 不要启用WRED。

■ 清道夫CBWFQ

■ 分配最少带宽（比如1%）；

■ 不要启用公平队列预选器；

■ 不要启用WRED。

■ 默认/尽力而为CBWFQ

■ 为默认/尽力而为队列分配至少25%带宽；

■ 在默认/尽力而为队列上启用公平队列预选器；

■ 在默认/尽力而为队列上启用WRED（必要时调整）。

在前文设计章节，为WAN和分支介绍了4类、8类和12类队列模型。

最后的注释:主要是WAN边界需要队列策略。但有时LAN边界可能也需要队列策略（比如WAN汇聚路由器上的WAN带宽超出了园区汇聚网络LAN链路的容量）。举例来说， WAN 汇聚路由器为110 个分支提供服务，每个分支10 Mbit/s（总吞吐量为1.1 Gbit/s），但它使用GE（吉比特以太网）链路连接园区网络。尽管上述情况比较罕见，但还是有这样的案例；LAN边界上还需要在出方向上部署出向队列策略，来提供服务级别保证，以防所有分支链路都以带宽容量速率向园区传输流量。

27.14.3 控制层面限速

建议:

■ 理解控制层面限速（CPP）特性的目标和用法，作为可选的QoS安全工具来加固网络基础设施。

附录B中提供了CPP的设计建议和配置。

27.15 WAN和分支接口QoS角色

建议:

■ 为所有路由器接口角色定义一致的入向和出向QoS策略。

到目前为止所讨论的QoS策略元素可以总结为以下角色，在WAN和分支架构中的不同路由器接口分别以这些角色提供服务，如图27-3所示。

图27-3 WAN和分支接口QoS角色

为这些角色应用的具体QoS策略如下所示。

1.WAN汇聚入向/内部QoS（仅限ASR）:可能会（按需）应用内部QoS策略。

2.WAN汇聚LAN边界:

■ 应该启用入向DSCP信任策略（默认启用）；

■ 可能应用入向NBAR2分类和标记策略；

■ 可能应用入向媒体网元数据分类和标记策略；

■ 可能（按需）应用出向LLQ/CBWFQ/WRED策略。

3.WAN汇聚WAN边界:

■ 应该启用入向DSCP信任策略（默认启用）；

■ 应该应用出向LLQ/CBWFQ/WRED策略；

■ 可能应用RSVP策略；

■ 可能应用其他与VPN相关的策略。

4.分支WAN边界（与WAN汇聚WAN边界可能相同也可能不同）:

■ 应该启用入向DSCP信任策略（默认启用）；

■ 应该应用入向LLQ/CBWFQ/WRED策略；

■ 可能应用RSVP策略；

■ 可能应用其他与VPN相关的策略。

5.分支LAN边界（与WAN汇聚LAN边界可能相同也可能不同）:

■ 应该启用入向DSCP信任策略（默认启用）；

■ 可能应用入向NBAR2分类和标记策略；

■ 可能应用入向媒体网元数据分类和标记策略；

■ 可能（按需）应用出向LLQ/CBWFQ/WRED策略。

27.16 小结

本章讨论了企业WAN和分支网络的QoS设计注意事项与建议。WAN和分支环境的两个QoS角色是管理数据包丢失和管理数据包抖动。

在WAN和分支网络中应用的战略QoS设计准则包含如下内容:

■ 优先选择在硬件上实施QoS，别无他选时再实施软件QoS；

■ 在技术条件和管理条件均可行的条件下，在尽可能靠近源的位置对应用进行分类和标记；

■ 了防止发生拥塞，在每个节点都启用队列策略，无论该节点发生拥塞的可能性有多小；

■（可选）启用控制层面限速来保护控制层面和数据层面。

本章概述了WAN和分支的体系结构，强调了这个结构中两个重要的路由器类型:WAN汇聚路由器和分支路由器。讨论了IOS软件QoS的优势和限制。除此之外，还总结了不同WAN汇聚和分支路由器的性能容量。

回顾了与延迟和抖动相关的设计考量，还介绍了与WAN 和分支设计相关的多种IOS QoS工具集，包括如下内容:

■ Tx-Ring；

■ CBWFQ；

■ LLQ；

■ WRED；

■ RSVP；

■ AVC；

■ 媒体网络；

■ AutoQoS；

■ CPP。

接着介绍了入向和出向WAN和分支策略的最佳做法建议。

最后将所有这些建议汇总为不同具体的接口QoS角色，其中包括如下内容:

■ WAN汇聚LAN边界；

■ WAN汇聚入向/内部QoS（仅限ASR）；

■ WAN汇聚WAN边界；

■ 分支WAN边界；

■ 分支LAN边界。

27.17 扩展阅读

Cisco媒体网WAN汇聚QoS设计4.0:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSWAN_40.html

Cisco媒体网WAN/VPN QoS设计一览:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/qoswanvpnaag.html

Cisco ASR 1000 系列内置服务处理器一览表:http://www.cisco.com/en/US/prod/collateral/routers/ps9343/data_sheet_c78-450070.html

Cisco 3900系列集成服务路由器一览表:http://www.cisco.com/en/US/prod/collateral/routers/ps10536/data_sheet_c78_553924.html

Cisco 2900系列集成服务路由器一览表:http://www.cisco.com/en/US/prod/collateral/routers/ps10537/data_sheet_c78_553896.html

Cisco 1941系列集成服务路由器一览表:http://www.cisco.com/en/US/prod/collateral/routers/ps10538/data_sheet_c78_556319.html

Cisco 1921系列集成服务路由器一览表:http://www.cisco.com/en/US/prod/collateral/voicesw/ps6789/ps7290/ps10589/data_sheet_c78-598389.html

第28章 WAN 汇聚服务路由器（Cisco ASR 1000）的QoS设计

WAN汇聚服务路由器最主要的QoS角色是管理由LAN到WAN链路速率骤减而引发的拥塞，同时最小化丢包和抖动。这类路由器第二个QoS角色是为入向应用分类执行DPI（深度数据包检测）。

WAN 汇聚服务路由器不仅连接着私有WAN 网络，还连接着MPLS 或IPSec VPN。WAN汇聚服务路由器的接口QoS角色如图28-1所示。

注释:本章重点介绍私有WAN连接，并且本章会为VPN设计章节提供知识基础。因此后续章节中会介绍与VPN相关的涉及考量和策略，其中包括总线速率电路设计（比如基于以太网的WAN环境）。

在本章中，WAN 汇聚服务路由器将以Cisco ASR 1000 系列路由器为例。因此一开始我们会先介绍该平台的体系结构，尤其是与QoS相关的部分。

图28-1 WAN汇聚服务路由器接口QoS角色

28.1 Cisco ASR 1000 QoS体系结构

从高层次看，Cisco ASR 1000 系列路由器的体系结构可以被分为以下三个主要部分。

■ 网络控制层面:由主用和备用路由处理器（RP）构成。

■ 数据层面转发:由主用和备用内置服务处理器（ESP）构成。

■ 网络输入/输出:由多个共享端口适配器（SPA）构成，它们受一个或多个SPA接口处理器（SIP）控制。

图28-2 展示了一个冗余的Cisco ASR 1000 路由器，它拥有两个路由处理器、两个ESP 和三个SIP。

QoS是在ESP中执行的，ESP的主要QoS组成部分是Cisco量子流处理器（QFP）及其两个芯片。

■ Cisco QFP引擎:负责MQC 分类、标记、限速和WRED。

■ Cisco QFP流量管理器:负责整形、LLQ 和CBWFQ 调度机制。

图28-3展示了这些芯片，以及ESP中针对数据包流实施的QoS行为。

图28-2 Cisco ASR 1000硬件体系结构

图28-3 Cisco ASR 1000 ESP体系结构和QoS流

ASR 1000 体系结构中最重要的优势是:Cisco QFP 引擎需要处理的任何特性都不会对Cisco QFP 流量管理器造成影响。因此Cisco ASR 1000 中的QoS 整形和队列配置对于性能的影响非常小。即使ASR上的QoS性能取决于QoS配置以及其他启用的特性，ASR还是非常具有可扩展性的。

28.2 QoS设计步骤

将CiscoASR1000路由器作为WAN汇聚服务路由器，需要使用以下三个主要步骤来配置QoS。

1.按需启用内部QoS。

2.配置入向QoS模型，其中包含以下内容:

■ 信任DSCP（在IOS中默认启用）；

■ 媒体网元数据分类和标记；

■ NBAR分类和标记。

3.配置出向QoS策略。

下面按顺序介绍这些设计步骤。

28.3 ASR 1000内部QoS

根据Cisco ASR 1000 的内部硬件体系结构，ESP 和SIP 有多种组合方式，能够创建出内部超额预订能力，如图28-4 所示，图中展示的Cisco ASR 1000 配置了两个ESP-10 和三个SIP-10，每个SIP-10 配置四个10-GE SPA。

图28-4 Cisco ASR 1000可能的内部拥塞点

图28-4 中的每个注释框代表一个ASR 1000 内部可能的拥塞点。这些拥塞点详述如下。

1.SIP-10入向分类和调度机制:这个位置可能是4:1 超额预订的拥塞点（最高40 Gbit/s的SPA 接口争夺10 Gbit/s 连接）。

2.SEP-10 互联调度机制:这个位置可能是3:1 超额预订的拥塞点（3 个SIP-10 争夺10 Gbit/s 连接）。

3.ESP-10出向QoS:这个位置可能是3:1 超额预订的拥塞点（QFP 的30 Gbit/s 流量争夺10 Gbit/s 连接）。

4.SIP-10缓存和出向QoS:这个位置可能是1:1+ 超额预订的拥塞点（10 Gbit/s 连接争夺10 Gbit/s SPA 接口，并用1.2Gbit/s 来处理复制IP 组播数据包的请求，因此最大吞吐量为11.2Gbit/s）。

为了应对这种潜在的超额预订情况，Cisco ASR 1000 使用两条队列的内部带宽调度程序来为数据包设定优先级:一条队列作为严格优先级队列；另一条作为低优先级队列。

图28-5中描绘了这个内部队列系统是如何在入方向上工作的，以及系统如何能够不断地感知队列状态。正因为有了针对内部队列状态的通信，高优先级数据包才总是能够优先得到处理，即使是当内部互联变得超载时；这是因为内部互联会使用从Cisco QFP 获得的背压来延迟低优先级数据包，这样就能使高优先级数据包持续获得服务了。

图28-5 Cisco ASR 1000内部入向调度机制的工作原理

图28-6 展示了反方向上，即出方向上的调度机制是如何实施的。在Cisco QFP 中，QFP流量管理器调度程序根据MQC策略来执行数据包调度决策。然后内部带宽调度程序在SIP之间分配（来自QFP的）出向数据包，并选出第一个内部指定的高优先级数据包。超出带宽——在服务了内部指定的高优先级数据包之后，所剩余的带宽——会在SIP之间共享（除非管理员调整了内部调度机制的权重，或者为每个SIP设置了内部调度机制的最小带宽保证）。最后， SIP和SPA上的小缓存能够用来实现多个端口同时传输数据包。

图28-6 Cisco ASR 1000内部出向调度机制的工作原理

要知道，并不是所有SIP和ESP的组合方式都会导致潜在的超额预订问题。比如表28-1就详细列出了SIP-10的各种超额预订情况。

即使ASR 1000 平台上会出现超额预订的情况，但仍可以配置内部调度程序，来为应用类别赋予不同的优先级。

尽管ASR 1000的内部QoS架构看起来颇为复杂，但所需的内部硬件队列配置却相对简单:主要的要求就是（或者在SPA上，或者在SIP上）识别出那些需要被分配到严格优先级内部队列中的数据包。

表28-1 Cisco ASR 1000 SIP-10超额预订情况

注释:可选地，也可以在每个SIP或SPA的基础上，为低优先级数据包的调度机制提高加权或保证。但本章的设计原则是基于应用的优先级（可从DSCP看出），而不是基于接口的优先级。因此本章并不涉及这类低优先级调度机制的调试，如需了解可查看以下文档:http://www.cisco.com/en/US/partner/docs/interfaces_modules/shared_port_adapters/configuration/ASR1000/ASRimpqos.html#wp1292478。

以太网SPA 和ATM SPA 要求在SPA 上实施内部优先级分类。但POS SPA、通道化SPA和纯通道SPA要求在SIP上实施内部优先级分类。表28-2根据内部分类机制汇总了SPA。

表28-2 Cisco ASR SPA汇总表，在SIP或SPA上实施入向分类

无论是SPA还是SIP上的内部调度机制分类，都是在PLIM（物理层接口模块）上实现的。接下来按顺序进行介绍。

28.3.1 基于SPA的PLIM

以太网SPA 和ATM SPA 是在SPA 上执行分类的。在基于SPA 的分类模型中，SPA 会执行第2层和第3层分类，并决定数据包的内部优先级。在将数据包分类为高优先级和低优先级后， SPA为每个优先级提供单独的通道:所有高优先级数据包和低优先级数据包分别通过不同的通道进行发送。在这种环境中，SPA会将高通道的数据包排入高优先级缓存，将低通道的数据包排入低优先级缓存。在将数据包分类为高优先级和低优先级后，数据包会被发送到ESP等待后续处理。

可以根据DSCP、IPv5 流量类别、MPLS EXP 或802.1Q/p CoS 来进行内部分类。接下来的案例使用基于DSCP的分类方式（为了保持策略的一致性）。

在ASR的CLI中，启用基于SPA的内部调度机制分类特性的命令是plim qos input map，这是接口配置命令，详见例28-1。默认情况下，EF（确认转发）流量映射到严格优先级内部队列中，所有其他DSCP值映射到低优先级内部队列中。因此对于这些默认设置所需的更改只有将CS4（实时交互）和CS5（广播视频）映射到严格优先级内部队列中。

例28-1 Cisco ASR 1000基于SPA的内部调度机制分类案例

ASR(config)# interface GigabitEthernet0/0/0

ASR(config-if)# plim qos input map ip dscp-based

! Designates that internal scheduling is to be DSCP-based

ASR(config-if)# plim qos input map ip dscp cs4 cs5 ef queue strict-priority

! Maps CS4 (real-time interactive) and

! CS5 (broadcast video) to the internal PQ

! (EF is already mapped to the internal PQ by default)

注释:在ASR的配置中，CS4和CS5相应地转换为DSCP 32和40。除此之外，EF和46都不会出现在配置中，因为DSCP EF/46默认被映射到内部优先级队列中。在例28-1中之所以这样配置，只是为了保持与前文设计案例的一致性，因此将这三个值都映射到严格优先级队列中。

你可以使用命令show platform hardware interface type sip/spa/interface plim qos input map 来检查例28-1中的配置，命令输出详见例28-2。

例28-2 检查ASR上基于SPA的入向调度机制的分类:showplatform hardware interface plim qos input map

ASR# show platform hardware interface Gig 0/0/0 plim qos input map

Interface GigabitEthernet0/0/0

Low Latency Queue(High Priority):

IP DSCP, 32, 40, 46

IPv6 TC, 46

MPLS EXP, 6, 7

例28-2中显示出DSCP 32（CS4）、40（CS5）和EF（46）都被映射到内部优先级队列中。

28.3.2 基于SIP的PLIM

POS（SONET上的数据包）、通道化SPA和纯通道SPA是在SIP上执行分类的。在基于SIP的分类模型中，SIP为SPA执行分类，并将数据包分类为高优先级或低优先级。

高优先级数据包的分类是通过模板定义的，使用命令ingress-class map 调用。分类的细节内容定义在模板中，然后使用接口命令plim qos class-map 将模板关联到接口。

与基于SPA的内部调度机制分类案例相似，在基于SIP的案例中也使用了基于DSCP的分类方式。默认情况下，EF（确认转发）流量映射到严格优先级内部队列中，所有其他DSCP值映射到低优先级内部队列中。因此对于这些默认设置所需的更改只有将CS4（实时交互）和CS5（广播视频）映射到严格优先级内部队列中，要使用ingress-class map 命令，详见例28-3。

例28-3 Cisco ASR 1000基于SIP的内部调度机制分类案例

! This section defines the ingress scheduling classification template

ASR(config)# ingress-class-map 1

ASR(config-ing-class-map)# map ip dscp-based

! Designates that internal scheduling is to be DSCP-based

ASR(config-ing-class-map)# map ip dscp 32 40 queue strict-priority

! Maps DSCP 32 (CS4 / real-time interactive) and

! DSCP 40 (CS5 / broadcast video) to the internal PQ

! (EF is already mapped to the internal PQ by default)

! This section attaches the ingress scheduling classification template ! to the

interface(s)

ASR(config)# interface POS0/1/0

ASR(config-if)# plim qos input class-map 1

! Attaches the ingress scheduling classification template

! to the interface

你可以使用命令how platform hardware interface type sip/spa/interface plim qos input map来检查例28-3中的配置，命令输出详见例28-4。

例28-4 检查ASR上基于SIP的入向调度机制的分类:showplatform hardware interface plim qos input map

ASR# show platform hardware interface pos 0/1/0 plim qos input map

Interface POS0/1/0 uses

Ingress-class-map 1

High-priority queue settings:

IPv4 DSCP:32 40 46

IPv6 TC:46

MPLS EXP:6 7

例28-4 中显示出接口POS 0/1/0 调用了入向class map 1（与这个SIP 相关联），DSCP 32 （CS4）、40（CS5）和EF（46）都被映射到内部优先级队列中。

28.4 入向QoS模型

如前所述，应该在尽可能靠近边界的位置实施分类和标记。但Catalyst交换机在执行DPI（深度数据包检测）方面能力有限（如果具备这种能力的话），比如媒体网络元数据或NBAR2流识别。因此需要在LAN边界，即WAN汇聚路由器上配置入向DPI分类策略。

但是这种DPI策略会与分支路由器LAN边界的策略相同，且更多时候会部署在分支路由器LAN边界上。因此为了减少赘述，入向DPI QoS策略（尽管也适用于WAN汇聚服务路由器）将在第29章中详细介绍。

28.5 出向QoS模型

尽管Cisco ASR 1000 在硬件中执行队列机制，但它与Cisco Catalyst 交换机一样，并不会受限于4 条或8 条物理队列架构。Cisco ASR 1000 支持每接口多达16 000 条队列，并使用三级分层结构。因此它可以轻松地支持4类、8类甚至12类战略QoS模型，并为每类使用专用的硬件队列，接下来将进行详细介绍。

28.5.1 4类模型

在4类模型（详见图11-3和图11-4）中，应用类到队列的映射关系如下所示。

■ 实时（标记为EF）:分配到LLQ，并获得33%的严格优先级带宽。

■ 控制（标记为CS3）:分配到CBWFQ，并获得7%的带宽保证。

■ 业务性数据（标记为AF2）:分配到CBWFQ，并获得35%的带宽保证；启用了公平队列预选器和基于DSCP的WRED。

■ 尽力而为（标记为DF）:分配到默认CBWFQ，并获得25%的带宽保证；启用了公平队列预选器和WRED。

例28-5给出了4类出向队列策略的配置，将该策略应用到T3串行接口。

例28-5 Cisco ASR 1000 4类出向队列模型案例

! This section configures the class maps for the

! Four-class egress queuing policy

ASR(config-cmap)# class-map match-all REALTIME

ASR(config-cmap)# match dscp ef

! Matches Realtime traffic on DSCP EF (IPv4/IPv6)

ASR(config-cmap)# class-map match-all CONTROL

ASR(config-cmap)# match dscp cs3

! Matches Control traffic on DSCP CS3 (IPv4/IPv6)

ASR(config-cmap)# class-map match-any TRANSACTIONAL-DATA

ASR(config-cmap)# match dscp af21

ASR(config-cmap)# match dscp af22

ASR(config-cmap)# match dscp af23

! Matches Transactional Data traffic on AF2 (IPv4/IPv6)

! This section defines the four-class egress queuing policy

ASR(config)# policy-map FOUR-CLASS-WAN-EDGE

ASR(config-pmap)# class REALTIME

ASR(config-pmap-c)# priority percent 33

! Provisions the REALTIME class with 33% LLQ

ASR(config-pmap)# class CONTROL

ASR(config-pmap-c)# bandwidth percent 7

! Provisions the CONTROL class with 7% CBWFQ

ASR(config-pmap)# class TRANSACTIONAL-DATA

ASR(config-pmap-c)# bandwidth percent 35

! Provisions the TRANSACTIONAL-DATA class with 35% CBWFQ

ASR(config-pmap-c)# fair-queue

! Enables a fair-queuing presorter

ASR(config-pmap-c)# random-detect dscp-based

! Enables DSCP-based WRED

ASR(config-pmap)# class class-default

ASR(config-pmap-c)# bandwidth percent 25

! Provisions the default/Best Effort class with 25% CBWFQ

ASR(config-pmap-c)# fair-queue

! Enables a fair-queuing presorter

ASR(config-pmap-c)# random-detect

! Enables WRED

! This section applies the queuing policy to a serial (T3) interface

! And tunes the Tx-Ring

ASR(config)# interface Serial2/1/0

ASR(config-if)# tx-ring-limit 10

! Optimizes the Tx-Ring for the serial (T3) interface

ASR(config-if)# service-policy output FOUR-CLASS-WAN-EDGE

! Attaches egress queuing service policy to serial T3 interface

注释:设计章节的所有class map案例中都使用了match dscp命令，而不是match ip dscp。这是因为match ip dscp 是旧语法，只匹配IPv4 数据包的DSCP 值，而match dscp 会匹配IPv4/IPv6数据包的DSCP值。

注释:可以在一行命令中匹配多个DSCP值（比如match af21 af22 af23），也可以分别使用多条命令来匹配多个DSCP值（详见例28-5）。使用哪种方法极大程度上取决于管理员的习惯。在后文内容中，将会通过show policy-map interface检查命令和相应的基于类的QoS MIB统计数据，来说明其中一种配置方法带来的唯一优势。

注释:只匹配一个代码点的class map既可以使用（默认）match-all的操作逻辑，也可以使用match-any的操作逻辑。但若在class map中使用多条命令来匹配DSCP值，就必须为这个class map使用match-any的操作逻辑；否则将不会有数据包与这个class map相匹配（因为没有数据包会同时拥有DSCP x和DSCP y）。

注释:只有在业务性数据队列和默认队列中才启用WRED（因为实时流量和控制流量不应该在早期被丢弃）。而且只有默认类别需要WRED（而不是基于DSCP的WRED），因为这个类别中的所有流量应该被标记为DF（默认转发）。

注释:与T3串行接口相关的一个考量因素是可能需要调试Tx-Ring值。Cisco技术市场部门发现在T3（在E3上也是这样）串行接口上将Tx-Ring调整为10，更有助于支持基于HD的富媒体应用，比如Cisco TelePresence。

你可以使用以下命令来检查这些配置。

■ show class-map（详见例28-6）

■ show policy-map（详见例28-7）

■ show policy-map interface

■ show controllers interface type sip/spa/interface | include tx_limited（详见第27章例27-1）

例28-6 检查class map:show class map

ASR# show class-map

Class Map match-all REALTIME (id 17)

Match　dscp ef (46)

Class Map match-all CONTROL (id 18)

Match　dscp cs3 (24)

Class Map match-any TRANSACTIONAL-DATA (id 19)

Match　dscp af21 (18)

Match　dscp af22 (20)

Match　dscp af23 (22)

ASR#

例28-7 检查policy map:show policy-map

ASR# show policy-map FOUR-CLASS-WAN-EDGE

Policy Map FOUR-CLASS-WAN-EDGE

Class REALTIME

priority 33 (%)

Class CONTROL

bandwidth 7 (%)

Class TRANSACTIONAL-DATA

bandwidth 35 (%)

fair-queue

wred, exponential weight 4

dscp　min-threshold　max-threshold　mark-probability

----------------------------------------------------------

default (0)　-　　　　-　　　　1/10

Class class-default

bandwidth 25 (%)

fair-queue

wred, exponential weight 4

class　min-threshold　max-threshold　mark-probability

----------------------------------------------------------

0　　-　　　　-　　　　1/10

1　　-　　　　-　　　　1/10

2　　-　　　　-　　　　1/10

3　　-　　　　-　　　　1/10

4　　-　　　　-　　　　1/10

5　　-　　　　-　　　　1/10

6　　-　　　　-　　　　1/10

7　　-　　　　-　　　　1/10

ASR#

28.5.2 8类模型

在8类模型中（详见图11-5和图11-6），应用类到队列的映射关系如下所示。

■ 语音（标记为EF）:分配到LLQ，并获得10%的严格优先级带宽。

■ 多媒体会议（标记为AF4）:分配到LLQ，并获得23%的严格优先级带宽。

■ 网络控制（标记为CS6）:分配到CBWFQ，并获得5%的带宽保证。

■ 信令（标记为CS3）:分配到CBWFQ，并获得2%的带宽保证。

■ 多媒体流（标记为AF3）:分配到CBWFQ，并获得10%的带宽保证；启用了公平队列预选器和基于DSCP的WRED。

■ 业务性数据（标记为AF2）:分配到CBWFQ，并获得24%的带宽保证；启用了公平队列预选器和基于DSCP的WRED。

■ 清道夫（标记为CS1）:分配到约束带宽CWFQ，并获得1%约束带宽。

■ 尽力而为（标记为DF）:分配到CBWFQ，并获得25%的带宽保证；启用了公平队列预选器和WRED。

例28-8 给出了8 类出向队列策略的配置，将该策略应用到OC-3 ATM PVC 接口。

例28-8 Cisco ASR 1000 8类出向队列模型案例

! This section configures the class maps for the

! eight-class egress queuing policy

ASR(config)# class-map match-all VOICE

ASR(config-cmap)# match dscp ef

! Matches Voice traffic on EF (IPv4/IPv6)

ASR(config-cmap)# class-map match-any MULTIMEDIA-CONFERENCING

ASR(config-cmap)# match dscp af41

ASR(config-cmap)# match dscp af42

ASR(config-cmap)# match dscp af43

! Matches MM-Conferencing traffic on AF4 (IPv4/IPv6)

ASR(config-cmap)# class-map match-all NETWORK-CONTROL

ASR(config-cmap)# match dscp cs6

! Matches Network Control traffic on CS6 (IPv4/IPv6)

ASR(config-cmap)# class-map match-all SIGNALING

ASR(config-cmap)# match dscp cs3

! Matches Signaling traffic on CS3 (IPv4/IPv6)

ASR(config-cmap)# class-map match-any MULTIMEDIA-STREAMING

ASR(config-cmap)# match dscp af31

ASR(config-cmap)# match dscp af32

ASR(config-cmap)# match dscp af33

! Matches MM-streaming traffic on AF3 (IPv4/IPv6)

ASR(config-cmap)# class-map match-any TRANSACTIONAL-DATA

ASR(config-cmap)# match dscp af21

ASR(config-cmap)# match dscp af22

ASR(config-cmap)# match dscp af23

! Matches transactional data on AF2 (IPv4/IPv6)

ASR(config-cmap)# class-map match-all SCAVENGER

ASR(config-cmap)# match dscp cs1

! Matches scavenger traffic on CS1 (IPv4/IPv6)

! This section defines the eight-class egress queuing policy

ASR(config-cmap)# policy-map EIGHT-CLASS-WAN-EDGE

ASR(config-pmap)# class VOICE

ASR(config-pmap-c)# priority percent 10

! Provisions the Voice class with 10% LLQ

ASR(config-pmap-c)# class MULTIMEDIA-CONFERENCING

ASR(config-pmap-c)# priority percent 23

! Provisions the Multimedia Conferencing class with 23% LLQ

ASR(config-pmap-c)# class NETWORK-CONTROL

ASR(config-pmap-c)# bandwidth percent 5

! Provisions the Network Control class with 5% CBWFQ

ASR(config-pmap-c)# class SIGNALING

ASR(config-pmap-c)# bandwidth percent 2

! Provisions the Signaling class with 2% CBWFQ

ASR(config-pmap-c)# class MULTIMEDIA-STREAMING

ASR(config-pmap-c)# bandwidth percent 10

! Provisions the Multimedia Streaming class with 10% CBWFQ

ASR(config-pmap-c)# fair-queue

! Enables a fair-queuing presorter

ASR(config-pmap-c)# random-detect dscp-based

! Enables DSCP-based WRED

ASR(config-pmap-c)# class TRANSACTIONAL-DATA

ASR(config-pmap-c)# bandwidth percent 24

! Provisions the Transactional Data class with 24% CBWFQ

ASR(config-pmap-c)# fair-queue

! Enables a fair-queuing presorter

ASR(config-pmap-c)# random-detect dscp-based

! Enables DSCP-based WRED

ASR(config-pmap-c)# class SCAVENGER

ASR(config-pmap-c)# bandwidth percent 1

! Constrains the Scavenger class to 1% CBWFQ

ASR(config-pmap-c)# class class-default

ASR(config-pmap-c)# bandwidth percent 25

! Provisions the default/Best Effort class with 25% CBWFQ

ASR(config-pmap-c)# fair-queue

! Enables a fair-queuing presorter

ASR(config-pmap-c)# random-detect

! Enables WRED

! This section applies the queuing policy to an OC-3 ATM PVC

ASR(config)# interface ATM4/1/0.1 point-to-point

ASR(config-if-atm)# pvc 0/112

ASR(config-if-atm-pvc)# vbr-rt 149760 149760

! Defines the ATM traffic contract:

! Variable Bit Rate – Realtime (OC-3)

ASR(config-if-atm-pvc)# service-policy output EIGHT-CLASS-WAN-EDGE

! Attaches egress queuing service policy to the ATM PVC

注释:8类模型使用双LLQ设计（一条用于语音，另一条用于多媒体会议）。这种双LLQ设计能够突发的视频流对语音流量造成影响。但最佳做法建议这两条LLQ使用33%之内的带宽。

你可以使用以下命令来检查例28-8中的配置。

■ show class-map

■ show policy-map

■ show policy-map interface

28.5.3 12类模型

在12类模型中（详见图11-7和图11-8），应用类到队列的映射关系如下所示。

■ 语音（标记为EF）:分配到LLQ，并获得10%的严格优先级带宽。

■ 广播视频（标记为CS5）:分配到LLQ，并获得10%的严格优先级带宽。

■ 实时交互（标记为CS4）:分配到LLQ，并获得3%的严格优先级带宽。

■ 网络控制（标记为CS6）:分配到CBWFQ，并获得2%的带宽保证。

■ 信令（标记为CS3）:分配到CBWFQ，并获得2%的带宽保证。

■ 网络管理（标记为CS2）:分配到CBWFQ，并获得3%的带宽保证。

■ 多媒体会议（标记为AF4）:分配到CBWFQ，并获得10%的带宽保证；启用了公平队列预选器和基于DSCP的WRED。

■ 多媒体流（标记为AF3）:分配到CBWFQ，并获得10%的带宽保证；启用了公平队列预选器和基于DSCP的WRED。

■ 业务性数据（标记为AF2）:分配到CBWFQ，并获得10%的带宽保证；启用了公平队列预选器和基于DSCP的WRED。

■ 大数据（标记为AF1）:分配到CBWFQ，并获得4%的带宽保证；启用了公平队列预选器和基于DSCP的WRED。

■ 清道夫（标记为CS1）:分配到约束带宽CWFQ，并获得1%约束带宽。

■ 尽力而为（标记为DF）:分配到CBWFQ，并获得25%的带宽保证；启用了公平队列预选器和WRED。

例28-9给出了123类出向队列策略的配置——还（可选）调整了WRED门限值——将该策略应用到OC-48 POS 接口。

例28-9 Cisco ASR 1000 12类出向队列模型案例

! This section configures the class maps for the

! 12-class egress queuing policy

ASR(config-cmap)# class-map match-all VOICE

ASR(config-cmap)# match dscp ef

! Matches voice traffic on EF (IPv4/IPv6)

ASR(config-cmap)# class-map match-all BROADCAST-VIDEO

ASR(config-cmap)# match dscp cs5

! Matches broadcast video traffic on CS5 (IPv4/IPv6)

ASR(config-cmap)# class-map match-all REALTIME-INTERACTIVE

ASR(config-cmap)# match dscp cs4

! Matches real-time interactive traffic on CS4 (IPv4/IPv6)

ASR(config-cmap)# class-map match-all NETWORK-CONTROL

ASR(config-cmap)# match dscp cs6

! Matches network control traffic on CS6 (IPv4/IPv6)

ASR(config-cmap)# class-map match-all SIGNALING

ASR(config-cmap)# match dscp cs3

! Matches signaling traffic on CS3 (IPv4/IPv6)

ASR(config-cmap)# class-map match-all NETWORK-MANAGEMENT

ASR(config-cmap)# match dscp cs2

! Matches network management traffic on CS2 (IPv4/IPv6)

ASR(config-cmap)# class-map match-any MULTIMEDIA-CONFERENCING

ASR(config-cmap)# match dscp af41

ASR(config-cmap)# match dscp af42

ASR(config-cmap)# match dscp af43

! Matches multimedia conferencing traffic on AF4 (IPv4/IPv6)

ASR(config-cmap)# class-map match-any MULTIMEDIA-STREAMING

ASR(config-cmap)# match dscp af31

ASR(config-cmap)# match dscp af32

ASR(config-cmap)# match dscp af33

! Matches multimedia streaming traffic on AF3 (IPv4/IPv6)

ASR(config-cmap)# class-map match-any TRANSACTIONAL-DATA

ASR(config-cmap)# match dscp af21

ASR(config-cmap)# match dscp af22

ASR(config-cmap)# match dscp af23

! Matches transactional data traffic on AF2 (IPv4/IPv6)

ASR(config-cmap)# class-map match-any BULK-DATA

ASR(config-cmap)# match dscp af11

ASR(config-cmap)# match dscp af12

ASR(config-cmap)# match dscp af13

! Matches bulk data traffic on AF1 (IPv4/IPv6)

ASR(config-cmap)# class-map match-all SCAVENGER

ASR(config-cmap)# match dscp cs1

! Matches scavenger traffic on CS1 (IPv4/IPv6)

! This section defines the 12-class egress queuing policy

! with tuned WRED thresholds

ASR(config-cmap)# policy-map TWELVE-CLASS-WAN-EDGE

ASR(config-pmap)# class VOICE

ASR(config-pmap-c)# priority percent 10

! Provisions the Voice class with 10% LLQ

ASR(config-pmap-c)# class BROADCAST-VIDEO

ASR(config-pmap-c)# priority percent 10

! Provisions the Broadcast Video class with 10% LLQ

ASR(config-pmap-c)# class REALTIME-INTERACTIVE

ASR(config-pmap-c)# priority percent 13

! Provisions the Real-Time Interactive class with 13% LLQ

ASR(config-pmap-c)# class NETWORK-CONTROL

ASR(config-pmap-c)# bandwidth percent 2

! Provisions the Network Control class with 2% CBWFQ

ASR(config-pmap-c)# class SIGNALING

ASR(config-pmap-c)# bandwidth percent 2

! Provisions the Signaling class with 2% CBWFQ

ASR(config-pmap-c)# class NETWORK-MANAGEMENT

ASR(config-pmap-c)# bandwidth percent 3

! Provisions the Network Management class with 3% CBWFQ

ASR(config-pmap-c)# class MULTIMEDIA-CONFERENCING

ASR(config-pmap-c)# bandwidth percent 10

! Provisions the Multimedia Conferencing class with 10% CBWFQ

ASR(config-pmap-c)# fair-queue

! Enables a fair-queuing presorter

ASR(config-pmap-c)# queue-limit 350

! Sets the maximum queue depth to 350 packets

ASR(config-pmap-c)# random-detect dscp-based

! Enables DSCP-based WRED

ASR(config-pmap-c)# random-detect dscp af43 210 350

! Tunes minimum DSCP-WRED threshold for AF43 to 60% queue depth

ASR(config-pmap-c)# random-detect dscp af42 245 350

! Tunes minimum DSCP-WRED threshold for AF42 to 70% queue depth

ASR(config-pmap-c)# random-detect dscp af41 280 350

! Tunes minimum DSCP-WRED threshold for AF41 to 80% queue depth

ASR(config-pmap-c)# class MULTIMEDIA-STREAMING

ASR(config-pmap-c)# bandwidth percent 10

! Provisions the Multimedia Streaming class with 10% CBWFQ

ASR(config-pmap-c)# fair-queue

! Enables a fair-queuing presorter

ASR(config-pmap-c)# queue-limit 350

! Sets the maximum queue depth to 350 packets

ASR(config-pmap-c)# random-detect dscp-based

! Enables DSCP-based WRED

ASR(config-pmap-c)# random-detect dscp af33 210 350

! Tunes minimum DSCP-WRED threshold for AF33 to 60% queue depth

ASR(config-pmap-c)# random-detect dscp af32 245 350

! Tunes minimum DSCP-WRED threshold for AF32 to 70% queue depth

ASR(config-pmap-c)# random-detect dscp af31 280 350

! Tunes minimum DSCP-WRED threshold for AF31 to 80% queue depth

ASR(config-pmap-c)# class TRANSACTIONAL-DATA

ASR(config-pmap-c)# bandwidth percent 10

! Provisions the Transactional Data class with 10% CBWFQ

ASR(config-pmap-c)# fair-queue

! Enables a fair-queuing presorter

ASR(config-pmap-c)# queue-limit 350

! Sets the maximum queue depth to 350 packets

ASR(config-pmap-c)# random-detect dscp-based

! Enables DSCP-based WRED

ASR(config-pmap-c)# random-detect dscp af23 210 350

! Tunes minimum DSCP-WRED threshold for AF23 to 60% queue depth

ASR(config-pmap-c)# random-detect dscp af22 245 350

! Tunes minimum DSCP-WRED threshold for AF22 to 70% queue depth

ASR(config-pmap-c)# random-detect dscp af21 280 350

! Tunes minimum DSCP-WRED threshold for AF21 to 80% queue depth

ASR(config-pmap-c)# class BULK-DATA

! Provisions the Bulk Data class with 10% CBWFQ

ASR(config-pmap-c)# bandwidth percent 4

ASR(config-pmap-c)# fair-queue

! Enables a fair-queuing presorter

ASR(config-pmap-c)# queue-limit 150

! Sets the maximum queue depth to 150 packets

ASR(config-pmap-c)# random-detect dscp-based

! Enables DSCP-based WRED

ASR(config-pmap-c)# random-detect dscp af13 90 150

! Tunes minimum DSCP-WRED threshold for AF13 to 60% queue depth

ASR(config-pmap-c)# random-detect dscp af12 105 150

! Tunes minimum DSCP-WRED threshold for AF12 to 70% queue depth

ASR(config-pmap-c)# random-detect dscp af11 120 150

! Tunes minimum DSCP-WRED threshold for AF11 to 80% queue depth

ASR(config-pmap-c)# class SCAVENGER

ASR(config-pmap-c)# bandwidth percent 1

! Constrains the Scavenger class to 1% CBWFQ

ASR(config-pmap-c)# class class-default

ASR(config-pmap-c)# bandwidth percent 25

! Provisions the default/Best Effort class with 25% CBWFQ

ASR(config-pmap-c)# fair-queue

! Enables a fair-queuing presorter

ASR(config-pmap-c)# queue-limit 3500

! Sets the maximum queue depth to 3500 packets

ASR(config-pmap-c)# random-detect dscp-based

! Enables DSCP-based WRED

ASR(config-pmap-c)# random-detect dscp default 2800 3500

! Tunes minimum DSCP-WRED threshold for DF to 80% queue depth

! This section applies the queuing policy to a (OC-48) POS interface

ASR(config)#interface pos 1/1/1

ASR(config-if)# service-policy output TWELVE-CLASS-WAN-EDGE

! Attaches egress queuing service policy to the POS interface

! This section applies the queuing policy to the LAN GE interface

ASR(config)#interface Gigabit 0/0/1

ASR(config-if)# service-policy output TWELVE-CLASS-WAN-EDGE

! Attaches egress queuing service policy to the GE interface

注释:（默认在OC-48 POS 接口）多媒体会议、多媒体流和业务性数据队列的队列限制由IOS软件设置为347个数据包；本例将这个值调整为了350个数据包。类似地，大数据和尽力而为队列默认的队列限制被设置为139和3478个数据包，本里将其调整为150和2500个数据包。

注释:本例调整了基于DSCP的WRED，AFx3数据包会在队列深度到达60%时随机丢弃， AFx2数据包是70%，AFx1数据包是80%。在默认队列中，数据包都被标记为DF/DSCP 0，并在80%时开始丢弃。

注释:在这个案例中，（OC-48）WAN边界带宽超出了（GE）LAN边界带宽；因此也在LAN边界应用了相同的12类队列策略，以防止在WAN到LAN方向上由于超额预订而导致的丢包。这的确是一个并不常见（或者甚至可以说极端）的案例，但它很好地强调了管理员需要注意的设计考量因素。

你可以使用以下命令来检查例28-9中的配置。

■ show class-map

■ show policy-map

■ show policy-map interface（详见例28-10）

例28-10 检查service policy:show policy-map interface

ASR# show policy-map interface pos 1/1/1

POS1/1/1

Service-policy output:TWELVE-CLASS-WAN-EDGE

queue stats for all priority classes:

Queueing

queue limit 512 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 4627164/2984695008

Class-map:VOICE (match-all)

2955876 packets, 567528192 bytes

30 second offered rate 14147000 bps, drop rate 0 bps

Match:dscp ef (46)

Priority:10% (248800 kbps), burst bytes 6220000, b/w exceed drops:0

Class-map:BROADCAST-VIDEO (match-all)

738967 packets, 1058200744 bytes

30 second offered rate 11457000 bps, drop rate 0 bps

Match:dscp cs5 (40)

Priority:10% (248800 kbps), burst bytes 6220000, b/w exceed drops:0

Class-map:REALTIME-INTERACTIVE (match-all)

923708 packets, 1322749856 bytes

30 second offered rate 14322000 bps, drop rate 0 bps

Match:dscp cs4 (32)

Priority:13% (323440 kbps), burst bytes 8086000, b/w exceed drops:0

Class-map:NETWORK-CONTROL (match-all)

796 packets, 49092 bytes

30 second offered rate 0 bps, drop rate 0 bps

Match:dscp cs6 (48)

Queueing

queue limit 69 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 0/0

bandwidth 2% (49760 kbps)

Class-map:SIGNALING (match-all)

73894 packets, 105816208 bytes

30 second offered rate 1143000 bps, drop rate 0 bps

Match:dscp cs3 (24)

Queueing

queue limit 69 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 0/0

bandwidth 2% (49760 kbps)

Class-map:NETWORK-MANAGEMENT (match-all)

147792 packets, 211638144 bytes

30 second offered rate 2290000 bps, drop rate 0 bps

Match:dscp cs2 (16)

Queueing

queue limit 104 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 0/0

bandwidth 3% (74640 kbps)

Class-map:MULTIMEDIA-CONFERENCING (match-any)

1477932 packets, 2116398624 bytes

30 second offered rate 22914000 bps, drop rate 3862000 bps

Match:dscp af41 (34)

640540 packets, 917253280 bytes

30 second rate 9932000 bps

Match:dscp af42 (36)

320270 packets, 458626640 bytes

30 second rate 4967000 bps

Match:dscp af43 (38)

517122 packets, 740518704 bytes

30 second rate 8014000 bps

Queueing

queue limit 350 packets

(queue depth/total drops/no-buffer drops/flowdrops) 67/249090/0/0

(pkts output/bytes output) 1228842/1759701744

bandwidth 10% (248800 kbps)

Fair-queue:per-flow queue limit 87 packets

Exp-weight-constant:4 (1/16)

Mean queue depth:64 packets

dscp　Transmitted　　Random drop　　Tail/Flow drop MinimumMaximum Mark

pkts/bytes　　pkts/bytes　　pkts/bytes　thresh　thresh　prob

af41　533437/763881784　53344/76388608　60142/86123344　280　350　1/10

af42　277738/397720816　27774/39772368　17949/25702968　245　350　1/10

af43　429912/615633984　42992/61564544　49375/70705000　210　350　1/10

Class-map:MULTIMEDIA-STREAMING (match-any)

1477935 packets, 2116402920 bytes

30 second offered rate 22915000 bps, drop rate 3861000 bps

Match:dscp af31 (26)

640539 packets, 917251848 bytes

30 second rate 9931000 bps

Match:dscp af32 (28)

320271 packets, 458628072 bytes

30 second rate 4967000 bps

Match:dscp af33 (30)

517125 packets, 740523000 bytes

30 second rate 8016000 bps

Queueing

queue limit 350 packets

(queue depth/total drops/no-buffer drops/flowdrops) 71/249093/0/0

(pkts output/bytes output) 1228842/1759701744

bandwidth 10% (248800 kbps)

Fair-queue:per-flow queue limit 87 packets

Exp-weight-constant:4 (1/16)

Mean queue depth:78 packets

dscp　Transmitted　　Random drop　　Tail/Flow drop Minimum Maximum Mark

pkts/bytes　　pkts/bytes　　pkts/bytes　thresh　thresh　prob

af31　534072/764791104　53407/76478824　59443/85122376　280　350　1/10

af32　278117/398263544　27812/39826784　17532/25105824　245　350　1/10

af33　428903/614189096　42890/61418480　50486/72295952　210　350　1/10

Class-map:TRANSACTIONAL-DATA (match-any)

1477932 packets, 2116398624 bytes

30 second offered rate 22915000 bps, drop rate 3856000 bps

Match:　dscp af21 (18)

640540 packets, 917253280 bytes

30 second rate 9932000 bps

Match:　dscp af22 (20)

320269 packets, 458625208 bytes

30 second rate 4967000 bps

Match:　dscp af23 (22)

517123 packets, 740520136 bytes

30 second rate 8016000 bps

Queueing

queue limit 350 packets

(queue depth/total drops/no-buffer drops/flowdrops) 65/249097/0/0

(pkts output/bytes output) 1228835/1759691720

bandwidth 10% (248800 kbps)

Fair-queue:per-flow queue limit 87 packets

Exp-weight-constant:4 (1/16)

Mean queue depth:65 packets

dscp　Transmitted　　Random drop　　Tail/Flow drop Minimum Maximum Mark

pkts/bytes　　pkts/bytes　　pkts/bytes　thresh　thresh　prob

af21　533571/764073672　53357/76407224　59995/85912840　280　350　1/10

af22　277641/397581912　27764/39758048　18056/25856192　245　350　1/10

af23　429877/615583864　42988/61558816　49409/70753688　210　350　1/10

Class-map:BULK-DATA (match-any)

2216901 packets, 3174602232 bytes

30 second offered rate 34373000 bps, drop rate 26751000 bps

Match:　dscp af11 (10)

640541 packets, 917254712 bytes

30 second rate 9931000 bps

Match:　dscp af12 (12)

320270 packets, 458626640 bytes

30 second rate 4966000 bps

Match:　dscp af13 (14)

1256090 packets, 1798720880 bytes

30 second rate 19475000 bps

Queueing

queue limit 150 packets

(queue depth/total drops/no-buffer drops/flowdrops) 69/1725401/0/0

(pkts output/bytes output) 491500/703828000

bandwidth 4% (99520 kbps)

Fair-queue:per-flow queue limit 37 packets

Exp-weight-constant:84 (1/16)

Mean queue depth:0 packets

dscp　Transmitted　　Random drop　　Tail/Flow drop Minimum Maximum Mark

pkts/bytes　　pkts/bytes　　pkts/bytes　thresh　thresh　prob

af11　139388/199603616　13938/19959216　493599/706833768　280　350　1/10

af12　90683/129858056　9068/12985376　223710/320352720　245　350　1/10

af13　266331/381385992　26633/38138456　975647/1397126504 210　350　1/10

Class-map:SCAVENGER (match-all)

738968 packets, 1058202176 bytes

30 second offered rate 11459000 bps, drop rate 9552000 bps

Match:　dscp cs1 (8)

Queueing

queue limit 64 packets

(queue depth/total drops/no-buffer drops) 64/616084/0

(pkts output/bytes output) 122884/175969888

bandwidth 1% (24880 kbps)

Class-map:class-default (match-any)

3325441 packets, 4761914000 bytes

30 second offered rate 51560000 bps, drop rate 3921000 bps

Match:any

Queueing

queue limit 3500 packets

(queue depth/total drops/no-buffer drops/flowdrops) 0/0/0/0

(pkts output/bytes output) 0/0

bandwidth 25% (622000 kbps)

Fair-queue:per-flow queue limit 875 packets

Exp-weight-constant:4 (1/16)

Mean queue depth:1005 packets

dscp　Transmitted　　Random drop　　Tail/Flow drop Minimum Maximum Mark

pkts/bytes　　pkts/bytes　　pkts/bytes　thresh　thresh　prob

default 3102802/4443096062 255783/366280146　0/0　　　2800　3500　1/10

ASR#

如例28-10 所示，show policy-map interface 命令显示出任何优先级（LLQ）类别都没有出现丢包现象，其中包括语音类、广播视频类和实时交互类。网络控制类和信令类也没有发生丢包。除此之外，命令还显示出基于DSCP的WRED正在管理多媒体会议类、多媒体流类、业务性数据类和大数据类中的拥塞。而且还能看出清道夫类中有大量丢包，默认类中使用基于DSCP的WRED来管理拥塞，因此尾部丢弃很少。

28.6 其他与平台相关的QoS设计选项

这些设计展示了WAN汇聚路由器QoS设计的基本元素，但这绝不是仅有的设计选项。其他涉及选项和考量因素如下所示:

■ RSVP；

■ AutoQoS；

■ 控制层面限速。

接下来按顺序简要介绍这些QoS设计选项和考量因素。

28.6.1 RSVP

在接口上启用RSVP（资源预留协议）之前，必须现在路由器上启用IOS RSVP代理功能。Cisco RSVP 代理功能是一项Cisco IOS 特性，它能够允许CUCM 执行基于RSVP 的呼叫准入控制。Cisco RSVP 代理特性是在Cisco IOS 12.4(6)T 版本中引入的。

注释:IOS RSVP代理特性的具体配置指南和最佳做法建议超出了本章范围，因为这是一项面向CUCM的特性。IOS RSVP代理的设计指南详见第11章Cisco统一通信系统8.x SRND:http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/cac.html。

在正确配置IOS RSVP代理与CUCM通信后，CUCM能够对语音/视频策略实施准入控制，管理员这时可以关注与接口相关的RSVP设计。本章将介绍两个RSVP模型:一个基本模型和一个启用了应用ID功能的高级模型。

1.基本RSVP模型

在配置好IOS RSVP 代理后，可以使用接口配置命令ip rsvp bandwidth 来启用基本RSVP功能，这条命令明确指明了为RSVP请求所预留的带宽量（默认为链路带宽的75%）。

如果所有PQ流量都是基于RSVP的，一旦优先级队列的第2层开销也计入带宽中，那么命令ip rsvp bandwidth 和优先级LLQ 命令中指定的带宽值应该相匹配。但如果有些PQ 流量没有启用RSVP，那么就要确保命令ip rsvp bandwidth 中指定的带宽与带外呼叫准入控制机制所使用的带宽总和，不超过priority命令中指定的带宽值。

还有，如果在路由器的一个或多个接口启用了RSVP，还要确保在传输RSVP信令的所有接口上也启用RSVP，这样RSVP消息才不会被丢弃。

应该在网络边界启用RSVP特性，其中包括WAN链路两端的路由器WAN接口、所有可能发生拥塞的WAN拥塞点，其中包括不同速率的冗余链路。

在IP WAN 中部署RSVP 时，建议使用IntServ/DiffServ（集成/ 差分服务）模型，以确保只使用RSVP来实施准入控制，使用DiffServ策略来执行分类、标记、限速和调度机制。而且这种模型的扩展性更强（因为RSVP并不会维护所有流的状态信息），也能够更好地与设计章节介绍的DiffServ策略相集成。配置IntServ/DiffServ模型需要额外的两条接口配置命令:ip rsvp resource provider none 和ip rsvp data-packet classification none。这两条命令告诉RSVP不要执行QoS操作，这些操作会由DiffServ策略在数据层面中执行。

建议使用接口配置命令ip rsvp signaling dscp 来确保将RSVP 数据包标记为CS3/24，与其他信令流一致（默认这些数据包会被标记为63）。

例28-11 给出了基本的IntServ/DiffServ RSVP 模型。

例28-11 Cisco ASR 1000基本RSVP模型案例

! This section configures basic IntServ/DiffServ RSVP

! on a WAN interface

ASR(config)# interface Serial2/1/0

ASR(config-if)# description CAMPUS-TO-BRANCH-SERIAL-T3-WITH-RSVP

ASR(config-if)# bandwidth 44210

ASR(config-if)# ip address 10.0.12.5 255.255.255.252

ASR(config-if)# load-interval 30

! Minimizes the interface-statistics sampling-period (optional)

ASR(config-if)# tx-ring-limit 10

! Optimizes the T3 Tx-Ring for rich media applications

ASR(config-if)# service-policy output WAN-EDGE-DIFFSERV-POLICY

! Attaches the DiffServ MQC policy to the interface

ASR(config-if)# ip rsvp bandwidth 15000

! Specifies the amount of reservable BW (should match LLQ BW)

ASR(config-if)# ip rsvp signalling dscp 24

! Marks RSVP signaling traffic to CS3

ASR(config-if)# ip rsvp data-packet classification none

! Enables the IntServ/DiffServ model by disabling RSVP for classification

ASR(config-if)# ip rsvp resource-provider none

! Enables the IntServ/DiffServ model by disabling RSVP for scheduling

你可以使用以下命令来检查相关配置。

■ show class-map

■ show policy-map

■ show policy-map interface

■ show interface

■ show ip rsvp interface（详见例28-12）

■ show ip rsvp interface detail（详见例28-13）

■ show ip rsvp installed（详见例28-14）

例28-12 检查RSVP策略:show ip rsvp interface

ASR# show ip rsvp interface serial 2/1/0

interface　rsvp　allocated　i/f max　flow max sub max　VRF

Se2/1/0　　ena　9996k　　15M　　15M　　0

如例28-12所示，通过RSVP为这个接口分配了15 Mbit/s带宽，当前已经占用了9996 kbit/s。

例28-13 检查RSVP策略:show ip rsvp interface detail

ASR# show ip rsvp interface detail serial 2/1/0

Se2/1/0:

RSVP:Enabled

Interface State:Up

Bandwidth:

Curr allocated:9996k bits/sec

Max.allowed (total):15M bits/sec

Max.allowed (per flow):15M bits/sec

Max.allowed for LSP tunnels using sub-pools:0 bits/sec

Set aside by policy (total):0 bits/sec

Admission Control:

Header Compression methods supported:

rtp (36 bytes-saved), udp (20 bytes-saved)

Traffic Control:

RSVP Data Packet Classification is OFF

RSVP resource provider is:none

Signalling:

DSCP value used in RSVP msgs:0x18

Number of refresh intervals to enforce blockade state:4

Authentication:disabled

Key chain:　<none>

Type:　　md5

Window size:1

Challenge:　disabled

Hello Extension:

State:Disabled

如例28-13 所示，就像show ip rsvp interface detail 这条命令后面添加的关键字所暗示的，使用这条命令可以获得更多有关基本RSVP策略的详细信息。案例中显示出预留带宽共15 Mbit/s，当前已经有9996 kbit/s 预留并分配给了媒体流。而且这里显示的信息也确认了， RSVP并没有执行任何数据分类或资源提供功能（因为本例中的RSVP使用IntServ/DiffServ模型）。最后还显示出RSVP数据包被标记为CS3/24（十六进制表示为0x18）。

例28-14 检查RSVP策略:show ip rsvp installed

ASR# show ip rsvp installed

80K　10.17.100.101　10.16.255.101　UDP　31257　26645

80K　10.17.100.102　10.16.255.102　UDP　16773　21718

80K　10.17.100.103　10.16.255.103　UDP　26470　16878

80K　10.17.100.104　10.16.255.104　UDP　18115　17845

80K　10.17.100.105　10.16.255.105　UDP　25294　22658

80K　10.17.100.106　10.16.255.106　UDP　24613　26904

80K　10.17.100.107　10.16.255.107　UDP　23175　26733

80K　10.17.100.108　10.16.255.108　UDP　22139　23492

80K　10.17.100.109　10.16.255.109　UDP　25590　29755

80K　10.17.100.110　10.16.255.110　UDP　27854　32460

80K　10.17.100.111　10.16.255.111　UDP　24189　29516

80K　10.17.100.112　10.16.255.112　UDP　22395　17433

753K　10.17.100.101　10.16.255.101　UDP　21502　28165

753K　10.17.100.102　10.16.255.102　UDP　17781　30069

753K　10.17.100.103　10.16.255.103　UDP　29918　25300

753K　10.17.100.104　10.16.255.104　UDP　29707　28284

753K　10.17.100.105　10.16.255.105　UDP　17780　19823

753K　10.17.100.106　10.16.255.106　UDP　28301　20751

753K　10.17.100.107　10.16.255.107　UDP　31230　19925

753K　10.17.100.108　10.16.255.108　UDP　20067　32170

753K　10.17.100.109　10.16.255.109　UDP　30677　17868

753K　10.17.100.110　10.16.255.110　UDP　22281　20874

753K　10.17.100.111　10.16.255.111　UDP　24056　16900

753K　10.17.100.112　10.16.255.112　UDP　22203　32146

例28-14 将当前预留并分配给媒体流的9996 kbit/s 带宽拆分显示出来，可以清楚地看出当前该接口有12路活跃的语音呼叫（每路80 kbit/s）和12路活跃的视频呼叫（每路753 kbit/s）。

2.高级RSVP模型与应用ID

RSVP本地策略特性允许管理员根据应用ID来控制带宽的预留，需要通过使用命令ip rsvp policy identity 将应用ID 映射到RSVP 本地策略中。RSVP 本地策略的标识是定义在全局中的，并且每个启用了该策略的接口都可以使用这些标识。每个标识都有一个策略定位器，这个定位器与一个应用ID相匹配。

在将应用策略定位器与本地策略相匹配时，为了给用户提供足够的灵活性，RSVP本地策略CLI 能够使用UNIX 正则表达式来表示应用ID，并以此与策略定位器进行匹配。Cisco IOS CLI中已经使用过正则表达式，比如在配置BGP时。

注释:如何在Cisco IOS中使用正则表达式，详见以下网址:http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094a92.shtml

如前所述，CUCM 可以为语音和视频流设置符合RFC 2872 的应用ID，并将其作为集群范围内的服务参数。默认情况下，CUCM使用的应用ID为AudioStream表示语音流， VideoStream表示视频流（用于音频和视频部分）。

因此在全局定义IOS RSVP 策略标识时，如需匹配这些CUCM 应用ID 的话，语音和视频分别如下配置:

■ ip rsvp policy identity rsvp-voice policy-locator.*AudioStream.*

■ ip rsvp policy identity rsvp-video policy-locator.*VideoStream.*

相应地，需要使用接口配置命令ip rsvp policy local identity，在接口启用基于应用ID 的本地策略。在预留策略匹配了策略定位器值之后，本地策略有能力执行以下功能:

■ 定义预留策略能够为一组或单个发送者预留的最大带宽；

■ 转发或不转发RSVP消息；

■ 接受或不接受RSVP消息；

■ 定义组或发送者能够预留的最大带宽。

默认有一个匹配所有的本地策略，称为默认本地策略。这个本地策略会匹配链路上所有未与其他RSVP本地策略配置相匹配的RSVP预留策略。默认本地策略可以用来匹配如下预留策略:未标记应用ID的预留策略，或标记了应用ID，但却会被当作未标记流量处理的预留策略。

例28-15给出了高级RSVP模型，它使用本地策略来匹配语音和视频的应用ID。

例28-15 Cisco ASR 1000高级（应用ID）RSVP模型案例

! This section defines the regular expressions to match RSVP

! application IDs

ASR(config)# ip rsvp policy identity RSVP-VIDEO policy-locator.*VideoStream.*

! RSVP AppIDs with the string "VideoStream" will be

! Associated with the RSVP-VIDEO local RSVP policy

ASR(config)# ip rsvp policy identity RSVP-VOICE policy-locator.*AudioStream.*

! RSVP AppIDs with the string "AudioStream" will be

! Associated with the RSVP-VIDEO local RSVP policy

! This section configures advanced AppID RSVP on a WAN interface

ASR(config)# interface Serial2/1/0

ASR(config-if)# description CAMPUS-TO-BRANCH-SERIAL-T3-WITH-RSVP

ASR(config-if)# bandwidth 44210

ASR(config-if)# load-interval 30

! Minimizes the interface-statistics sampling-period (optional)

ASR(config-if)# tx-ring-limit 10

! Optimizes the T3 Tx-Ring for rich media applications

ASR(config-if)# service-policy output WAN-EDGE-DIFFSERV-POLICY

! Attaches the DiffServ MQC policy to the interface

ASR(config-if)# ip rsvp policy local identity RSVP-VIDEO

ASR(config-rsvp-local-if-policy)# maximum bandwidth group 12500

ASR(config-rsvp-local-if-policy)# forward all

! Defines a local RSVP policy to admit up to 12.5 Mbps of video flows

ASR(config-if)# ip rsvp policy local identity RSVP-VOICE

ASR(config-rsvp-local-if-policy)# maximum bandwidth group 2500

ASR(config-rsvp-local-if-policy)# forward all

! Defines a local RSVP policy to admit up to 2.5 Mbps of voice flows

ASR(config-if)# ip rsvp bandwidth 15000

! Specifies the amount of reservable BW (should match LLQ BW)

ASR(config-if)# ip rsvp signalling dscp 24

! Marks RSVP signaling traffic to CS3

ASR(config-if)# ip rsvp data-packet classification none

! Enables the IntServ/DiffServ model by disabling RSVP for

! classification

ASR(config-if)# ip rsvp resource-provider none

! Enables the IntServ/DiffServ model by disabling RSVP for scheduling

你可以使用以下命令来检查例28-15中的配置。

■ show class-map

■ show policy-map

■ show policy-map interface

■ show interface

■ show ip rsvp interface

■ show ip rsvp interface detail

■ show ip rsvp installed

■ show ip rsvp policy local（详见例28-16）

■ show ip rsvp policy local detail（详见例28-17）

例28-16 检查RSVP策略:show ip rsvp policy local

ASR# show ip rsvp policy local

A=Accept　F=Forward

Serial2/1/0:

Path:AF Resv:AF PathErr:AF ResvErr:AF ID(s):RSVP-VIDEO

Path:AF Resv:AF PathErr:AF ResvErr:AF ID(s):RSVP-VOICE

Generic policy settings:

Default policy:Accept all

Preemption:　Disabled

例28-17策略检查命令显示出，当应用ID与定义在RSVP-VIDEO和RSVP-VOICE策略标识中的应用ID 相匹配时，本地RSVP 策略将接受并转发S 2/1/0 接口预留流量。除此之外，命令的输出内容中还显示出默认策略将接受所有其他RSVP请求，并且抢占是被禁用的。

例28-17 检查RSVP策略:show ip rsvp policy local detail

例28-17展示了每个本地策略的更多细节，阴影部分显示出当前有12条视频流（每条753 kbit/s）和12 条语音流（每条80 kbit/s）分配到视频和音频池。

28.6.2 AutoQoS SRND4

正如前文章节提到的，（在本书写作时）ASR 1000 路由器的Cisco IOS 不支持AutoQoS SRND4。但该平台支持AutoQoS-VoIP和AutoQoS-Enterprise。

28.6.3 控制层面限速

Cisco IOS 支持控制层面限速，附录B 中详细介绍了该特性的设计建议。

28.7 小结

本章介绍了WAN 汇聚服务路由器的QoS 角色，并阐述了Cisco ASR 1000 是如何适合这个角色的。

本章概述了Cisco ASR 1000 的硬件体系结构，尤其是与QoS 相关的部分——强调了内部系统中可能会超额预订的情况。通过介绍内部（PLIM QoS）机制，阐述了如何在该平台上管理潜在的内部超额预订的情况。

本章顺便提到了入向QoS设计（因为这种设计更常用于分支，因此会在后续章节中进行详细介绍），在WAN汇聚LAN边界的部署方法是相同的。

接着介绍了出向QoS设计，着重介绍了4类、8类和12类队列模型。这些设计可以获益于诸多Cisco IOS QoS 特性，比如LLQ、CBWFQ、基于DSCP 的WRED 以及公平队列预选机制。

本章最后还讨论了其他QoS 设计选项，比如RSVP，其中分别介绍了基本和高级RSVP设计。

28.8 扩展阅读

媒体网WAN汇聚QoS设计4.0:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSWAN_40.html

ASR 1000 QoS体系结构:http://www.cisco.com/en/US/prod/collateral/routers/ps9343/solution_overview_c22-449961_ps9343_Product_Solution_Overview.html

ASR 1000系列的数据包分类和调度机制:http://www.cisco.com/en/US/partner/docs/interfaces_modules/shared_port_adapters/configuration/ASR1000/ASRimpqos.html（需要Cisco.com账户）

Cisco IOS QoS 解决方案配置指南:Cisco IOS 15M&T 版本:http://www.cisco.com/en/US/docs/ios-xml/ios/qos/config_library/15-mt/qos-15-mt-library.html

Cisco统一通信系统8.x SRND:http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/cac.html

第29章 分支路由器（Cisco ISR G2）的QoS设计

与WAN汇聚路由器一样，分支路由器的主要QoS角色是管理由LAN到WAN链路速率骤减而引发的不可避免的拥塞，同时还要最小化丢包和抖动。

这些路由器的第2个角色是执行DPI（深度数据包检测），为后续的入向应用分类提供基础。DPI与当今的网络关系越来越密切，因为如今有数以千计的应用运行在HTTP之上，从第4层的角度看来，这些应用全都一样（都是使用80端口的TCP流量）。只有深入查看这些数据包，识别第7层参数，才能够识别出这些数据包的区别。但管理员应该知道使用DPI进行分类的局限性，比如无法辨别通过HTTPS加密的流量或者隧道化的流量（比如CAPWAP[无线访问点的控制和部署]）。分支路由器不仅连接着私有WAN网络，还可能与MPLS或基于IPSec的VPN网络相连。图29-1展示了分支路由器与接口相关的QoS角色。

Cisco ISR G2 系列路由器是专门设计为扮演分支路由器角色的设备。因此先简要介绍一下该平台的体系结构。

图29-1 分支路由器的接口QoS角色

29.1 Cisco ISR G2 QoS体系结构

Cisco ISR G2 系列路由器在第一代ISR（集成服务路由器）的基础上大大提升了性能（有些型号对比第一代设备提升了7倍性能）。这种提升不仅仅是因为使用了更快的处理器并配备了更多内存，更是将交换功能从单核处理器设计发展为多核处理器设计。除此之外，更是围绕MGF（吉比特级交换架构）重新设计了系统体系结构，详见图29-2。

尽管ISR G2 在其体系结构中拥有强大的硬件阵列，但不得不说，它还是在软件中执行QoS 操作的（并不使用专用的硬件ASIC[ 专用集成电路]）。因此在为特定分支选择ISR G2路由器的型号时，应该参考表27-1中列出的性能参数（参考Cisco.com更好）。

因为所有QoS操作都是在IOS软件中执行的，那么了解这些操作的执行顺序对管理员颇有助益。图29-3描绘了执行顺序，其中不仅包括QoS特性，还显示了其他通用IOS特性及其相互之间的关系。

图29-2 Cisco ISR G2硬件体系结构

注释:图29-3中并没有显示出所有IOS特性。

图29-3 Cisco IOS的执行顺序

29.2 QoS设计步骤

将Cisco ISR G2 路由器作为分支路由器，需要使用以下两个主要步骤来配置QoS。

1.配置入向QoS模型，其中包含以下内容:

■ 信任DSCP（在IOS中默认启用）；

■ 媒体网元数据分类和标记；

■ NBAR2分类和标记。

2.配置出向QoS策略。

下面按顺序介绍这些设计步骤。

29.3 入向QoS模型

如前所述，应该在尽可能靠近边界的位置实施分类和标记。但Catalyst交换机在执行DPI方面能力有限（如果具备这种能力的话），比如媒体网元数据或NBAR2流识别。因此需要在LAN边界，即分支路由器上配置入向DPI分类策略。

注释:正如前文章节提到的，这些DPI策略也可以（使用相同的配置）部署在LAN边界的WAN汇聚服务路由器上。

下面按顺序介绍媒体网和NBAR2分类模型。

29.3.1 媒体网分类模型

Cisco IOS可以使用媒体网流中的元数据（Metadata）或者集成媒体网NBAR2来执行DPI（详见第8章）。

媒体网元数据的分类可以通过以下三种方式实现。

■ 基于应用的分类:在每条match application 命令中调用要匹配的具体应用；

■ 基于应用组的分类:在每条match application 命令中结合application-group 关键字，能够在单一match语句中调用某个应用的子组件；

■ 基于属性的分类:在每条match application 命令中结合attribute 关键字，能够在单一match语句中调用具有相似特征（属性）的多个应用。

下面将详细介绍每个媒体网元数据分类选项。

1.媒体网基于应用的分类和标记模型

在基于应用的分类模型中，必须在每条match application 语句中指定每个应用的名称（这样做可以有效地借助于NBAR2来实现分类）。基于应用的分类模型的粒度更细致也更精确，但它会需要较长且较庞大的策略配置（与基于应用组或基于属性的分类模型相比，后续将详细介绍这两种模型）。

例29-1给出了媒体网元数据基于应用的分类和标记策略的案例，这种方案可能会被部署在分支路由器的入方向LAN边界上。

例29-1 Cisco ISR G2媒体网元数据（基于应用的）入向分类和标记模型

! This section globally enables Medianet metadata

ISR-G2(config)# metadata flow

! Globally enables Medianet metadata

! This section configures the metadata application-based class maps

ISR-G2(config-cmap)# class-map match-any MEDIANET-VOICE

ISR-G2(config-cmap)# match application cisco-phone

! Identifies Cisco IP and Softphone voice flows via metadata

ISR-G2(config-cmap)# class-map match-all MEDIANET-REALTIME-INTERACTIVE

ISR-G2(config-cmap)# match application telepresence-media

! Identifies TelePresence media flows via metadata

ISR-G2(config-cmap)# class-map match-any MEDIANET-MULTIMEDIA-CONFERENCING

ISR-G2(config-cmap)# match application webex-voice

! Identifies WebEx voice flows via application metadata

ISR-G2(config-cmap)# match application webex-video

! Identifies WebEx video flows via application metadata

ISR-G2(config-cmap)# match application webex-meeting

! Identifies WebEx data flows via application metadata

ISR-G2(config-cmap)# class-map match-any MEDIANET-SIGNALING

ISR-G2(config-cmap)# match application sip

! Identifies SIP signaling flows via application metadata

ISR-G2(config-cmap)# match application telepresence-control

! Identifies TelePresence signaling flows via application metadata

ISR-G2(config-cmap)# match application h323

! Identifies H.323 signaling flows via application metadata

ISR-G2(config-cmap)# match application rtsp

! Identifies RTSP signaling flows via application metadata

ISR-G2(config-cmap)# class-map match-any MEDIANET-TRANSACTIONAL-DATA

ISR-G2(config-cmap)# match application citrix

! Identifies Citrix flows via application metadata

ISR-G2(config-cmap)# match application vmware-view

! Identifies VMware View flows via application metadata

ISR-G2(config-cmap)# match application wyze-zero-client

! Identifies WYZE Zero Client flows via application metadata

! This section configures the ingress marking policy map

ISR-G2(config-cmap)# policy-map MEDIANET-MARKING

ISR-G2(config-pmap)# class MEDIANET-VOICE

ISR-G2(config-pmap-c)# set dscp ef

! Marks IPv4/IPv6 DSCP values to EF for voice

ISR-G2(config-pmap-c)# class MEDIANET-REALTIME-INTERACTIVE

ISR-G2(config-pmap-c)# set dscp cs4

! Marks IPv4/IPv6 DSCP values to CS4 for TelePresence

ISR-G2(config-pmap-c)# class MEDIANET-MULTIMEDIA-CONFERENCING

ISR-G2(config-pmap-c)# set dscp af41

! Marks IPv4/IPv6 DSCP values to AF41 for multimedia conferencing

ISR-G2(config-pmap-c)# class MEDIANET-SIGNALING

ISR-G2(config-pmap-c)# set dscp cs3

! Marks IPv4/IPv6 DSCP values to CS3 for Signaling class

ISR-G2(config-pmap-c)# class MEDIANET-TRANSACTIONAL-DATA

ISR-G2(config-pmap-c)# set dscp af21

! Marks IPv4/IPv6 DSCP values to AF21 for transactional data

ISR-G2(config-pmap-c)# class class-default

ISR-G2(config-pmap-c)# set dscp default

! Marks IPv4/IPv6 DSCP values to DF/DSCP0 for everything else

! This section applies the ingress (application-based)

! Medianet metadata marking policy to the interface(s)

ISR-G2(config)# interface GigabitEthernet0/1

ISR-G2(config-if)# service-policy input MEDIANET-MARKING

注释:对于通过媒体网络应用元数据来匹配应用类的class map（与之不同的是WAN 边界class map——前文章节和本章后续内容中都会再次使用——它们使用DSCP标记来匹配应用类），有必要为其配置唯一的名称；否则有时可能会覆盖一个或一组class map。为此，这部分的案例将使用MEDIANET-前缀。

你可以使用以下命令来检查例29-1中的配置。

■ show metadata application table（详见例29-2）

■ show metadata flow classification table（详见例29-3）

■ show metadata flow statistics（详见例29-4）

■ show metadata flow table（详见例29-5）

■ show class-map

■ show policy-map

■ show policy-map interface

例29-2展示出当前IOS软件能够使用媒体网络元数据分类技术支持的各种应用。

例29-2 检查元数据应用:show metadata application table

ISR-G2# show metadata application table

ID　Name　　　　　Vendor　　Version

--------------------------------------------------------------------------------

218103921　telepresence-media　-　　　-

218103922　telepresence-contr$　-　　　-

218104286　telepresence-data　-　　　-

218104220　webex-voice　　　-　　　-

218104221　webex-video　　　-　　　-

218104222　webex-meeting　　-　　　-

218103864　citrix　　　　-　　　-

218103889　cisco-phone　　　-　　　-

218104284　vmware-view　　　-　　　-

218104281　wyze-zero-client　　-　　　-

218103869　rtp　　　　　-　　　-

218103872　h323　　　　　-　　　-

218108868　sip　　　　　-　　　-

218104362　rtsp　　　　　-　　　-

例29-3 检查元数据流分类:show metadata flowclassification table

例29-3展示出通过媒体网络元数据分类的多条动态流，在本例中这些流中有一些是Cisco WebEx流。

例29-4 检查元数据流状态统计:show metadata flow statistics

ISR-G2# show metadata flow statistics

Interface specific report:

GigabitEthernet0/0:Ingress flows 2, Egress flows 2

GigabitEthernet0/1:Ingress flows 0, Egress flows 1

GigabitEthernet0/2:Ingress flows 1, Egress flows 0

Chunk statistics:

Type　　　　Allocated　　Returned　　Failed

IPV4 Flow　　　3　　　　0　　　　0

Flow Key　　　3　　　　1　　　　0

Source List　　1　　　　0　　　　0

Flow Info　　　3　　　　3　　　　0

Attribute Data　　3　　　　3　　　　0

Feature Object　　0　　　　0　　　　0

Event Statistics:

Add Flow　　　　:3　　Delete Flow　　　　:0

Received　　　　:3　　Rejected　　　　:0

Transient　　　　:0　　Posted　　　　　:3

Ingress Change　　　:0　　Egress Change　　　:0

Unknown　　　　　:0　　Source Limit Exceeded　:0

例29-4展示出各种动态流，以及与媒体网络应用相关的事件计数器。

例29-5 检查元数据流状态统计:show metadata flow statistics

ISR-G2# show metadata flow table

Flow　To　　　　From　　　Protocol DPort SPort Ingress I/F Egress I/F

SSRC

2　209.165.202.129　209.165.202.150　UDP　　49152 5060　Gi0/0　　0

1　209.165.202.150　209.165.202.129　UDP　　5060　49152 Gi0/0　　0

3　209.165.202.150　209.165.202.129　UDP　　5062　49154 Gi0/1　　0

4　209.165.202.129　209.165.202.150　UDP　　49154 5062　Gi0/2　　0

例29-5提供了媒体网络流的具体流信息，其中包括源和目的IP地址对、第4层协议和端口，以及流的入向接口。

2.媒体网络基于应用组的分类模型

在基于应用组的分类模型中，使用命令match application结合application-group关键字，这样做可以在单一match语句中调用一组应用的子组件。

例29-6所示案例展示了为多媒体会议类使用媒体网络元数据基于应用组的分类class map。在前文配置案例中（例29-1），需要分别使用三条match 语句来匹配Cisco WebEx 应用的语音、视频和数据这三个子组件；这种配置方式可以被简化为使用一条match application application-group语句执行匹配，详见例29-6。

注释:为了减少重复，在后续基于应用组和基于属性的分类模型案例中只展示一个class map。

例29-6 Cisco ISR G2媒体网络元数据（基于应用组的）入向分类模型

ISR-G2(config)# class-map match-all MEDIANET-MULTIMEDIA-CONFERENCING

ISR-G2(config-cmap)# match application application-group webex-group

你可以使用命令show class-map 来检查例29-6 中的配置。

3.媒体网络基于属性的分类模型

在基于属性的分类模型中，使用命令match application 结合attribute 关键字，这样做可以在单一match语句中调用拥有相似特征/属性的多个应用。

例29-7 所示案例展示了为业务性数据类使用媒体网元数据基于属性的分类class map。在前文配置案例中（例29-1），需要分别使用三条match语句来匹配Citrix、VMware和Wyse虚拟桌面协议；这种配置方式可以被简化为使用一条match application attribute语句执行匹配，详见例29-7。

例29-7 Cisco ISR G2媒体网元数据（基于属性的）入向分类模型

ISR-G2(config)# class-map match-all MEDIANET-TRANSACTIONAL-DATA

ISR-G2(config-cmap)# match application attribute category business-and-productivity-tools

你可以使用命令show class-map 来检查例29-7 中的配置。

29.3.2 NBAR2分类模型

如前所述，NBAR在SCE（服务控制引擎）的基础上重新构建出NBAR2，增强了分类技术、提高了准确度并带来更多特征。目前，NBAR2可以为上千应用和子分类提供支持。除此之外， Cisco还通过每月发布的协议包提供新特征（和特征更新）。

与媒体网元数据分类类似，NBAR2分类可以通过以下三种方式实现。

■ 基于应用的分类:在每条match protocol 命令中调用要匹配的具体应用。

■ 基于应用组的分类:在每条match protocol 命令中结合application-group 关键字，能够在单一match语句中调用应用组。

■ 基于属性的分类:在每条match protocol 命令中结合attribute 关键字，能够在单一match语句中调用具有相似特征（属性）的多个应用。

下面将详细介绍每个NBAR2分类选项。

1.NBAR2基于应用的分类和标记模型

在基于应用的分类模型中，必须在每条match protocol 语句中指定每个应用的名称。基于应用的分类模型的粒度更细致也更精确，但它会需要较长且较庞大的策略配置（与基于应用组或基于属性的分类模型相比，后续将详细介绍这两种模型）。

例29-8给出了NBAR2基于应用的分类和标记策略的案例，这种方案可能会被部署在分支路由器的入方向LAN边界上。

例29-8 Cisco ISR G2 NBAR2（基于应用的）分类和标记模型

! This section configures the NBAR2 application-based class maps

ISR-G2(config-cmap)# class-map match-all NBAR2-VOICE

ISR-G2(config-cmap)# match protocol cisco-phone

! Identifies Cisco IP Phone VoIP traffic via NBAR2

ISR-G2(config-cmap)# class-map match-all NBAR2-REALTIME-INTERACTIVE

ISR-G2(config-cmap)# match protocol telepresence-media

! Identifies TelePresence audio/video traffic via NBAR2

ISR-G2(config-cmap)# class-map match-any NBAR2-MULTIMEDIA-CONFERENCING

ISR-G2(config-cmap)# match protocol webex-media

! Identifies Cisco WebEx audio/video traffic via NBAR2

ISR-G2(config-cmap)# match protocol webex-meeting

! Identifies Cisco WebEx meeting traffic via NBAR2

ISR-G2(config-cmap)# match protocol webex-app-sharing

! Identifies Cisco WebEx application-sharing traffic via NBAR2

ISR-G2(config-cmap)# class-map match-any NBAR2-SIGNALING

ISR-G2(config-cmap)# match protocol skinny

! Identifies Skinny Call Control Protocol (SCCP) via NBAR2

ISR-G2(config-cmap)# match protocol telepresence-control

! Identifies TelePresence control protocols via NBAR2

ISR-G2(config-cmap)# match protocol sip

! Identifies Session Initiation Protocol (SIP) via NBAR2

ISR-G2(config-cmap)# match protocol h323

! Identifies H.323 protocol via NBAR2

ISR-G2(config-cmap)# class-map match-any NBAR2-TRANSACTIONAL-DATA

ISR-G2(config-cmap)# match protocol salesforce

! Identifies Salesforce.com traffic via NBAR2

ISR-G2(config-cmap)# match protocol citrix

! Identifies Citrix traffic via NBAR2

ISR-G2(config-cmap)# match protocol sap

! Identifies SAP traffic via NBAR2

ISR-G2(config-cmap)# match protocol oracle-bi

! Identifies Oracle traffic via NBAR2

ISR-G2(config-cmap)# class-map match-any NBAR2-BULK-DATA

ISR-G2(config-cmap)# match protocol ftp

ISR-G2(config-cmap)# match protocol ftp-data

ISR-G2(config-cmap)# match protocol ftps-data

! Identifies FTP/SFTP traffic via NBAR2

ISR-G2(config-cmap)# match protocol cifs

! Identifies Common Internet File System traffic via NBAR2

ISR-G2(config-cmap)# match protocol exchange

! Identifies Microsoft Exchange traffic via NBAR2

ISR-G2(config-cmap)# match protocol netapp-snapmirror

! Identifies NetApp Backup traffic via NBAR2

ISR-G2(config-cmap)# class-map match-any NBAR2-SCAVENGER

ISR-G2(config-cmap)# match protocol netflix

! Identifies Netflix traffic via NBAR2

ISR-G2(config-cmap)# match protocol facebook

! Identifies Facebook traffic via NBAR2

ISR-G2(config-cmap)# match protocol hulu

! Identifies Hulu traffic via NBAR2

ISR-G2(config-cmap)# match protocol itunes

! Identifies Apple iTunes traffic via NBAR2

ISR-G2(config-cmap)# match protocol bittorrent

ISR-G2(config-cmap)# match protocol encrypted-bittorrent

! Identifies (regular and encrypted) BitTorrent traffic via NBAR2

! This section configures the ingress NBAR2 marking policy map

ISR-G2(config-cmap)# policy-map NBAR2-MARKING

ISR-G2(config-pmap)# class NBAR2-VOICE

ISR-G2(config-pmap-c)# set dscp ef

! Marks IPv4/IPv6 DSCP values to EF for voice

ISR-G2(config-pmap-c)# class NBAR2-REALTIME-INTERACTIVE

ISR-G2(config-pmap-c)# set dscp cs4

! Marks IPv4/IPv6 DSCP values to CS4 for TelePresence

ISR-G2(config-pmap-c)# class NBAR2-MULTIMEDIA-CONFERENCING

ISR-G2(config-pmap-c)# set dscp af41

! Marks IPv4/IPv6 DSCP values to AF41 for multimedia conferencing

ISR-G2(config-pmap-c)# class NBAR2-SIGNALING

ISR-G2(config-pmap-c)# set dscp cs3

! Marks IPv4/IPv6 DSCP values to CS3 for signaling

ISR-G2(config-pmap-c)# class NBAR2-TRANSACTIONAL-DATA

ISR-G2(config-pmap-c)# set dscp af21

! Marks IPv4/IPv6 DSCP values to AF21 for transactional data

ISR-G2(config-pmap-c)# class NBAR2-BULK-DATA

ISR-G2(config-pmap-c)# set dscp af11

! Marks IPv4/IPv6 DSCP values to AF11 for bulk data

ISR-G2(config-pmap-c)# class NBAR2-SCAVENGER

ISR-G2(config-pmap-c)# set dscp cs1

! Marks IPv4/IPv6 DSCP values to CS1 for scavenger

ISR-G2(config-pmap-c)# class class-default

ISR-G2(config-pmap-c)# set dscp default

! Marks IPv4/IPv6 DSCP values to DF/DSCP0 for everything else

! This section applies the ingress (application-based)

! NBAR2 marking policy to the interface(s)

ISR-G2(config)# interface GigabitEthernet0/1

ISR-G2(config-if)# service-policy input NBAR2-MARKING

注释:对于通过NBAR2 来匹配应用类的class map（与之不同的是WAN 边界class map——前文章节和本章后续内容中都会再次使用——它们使用DSCP标记来匹配应用类），有必要为其配置唯一的名称；否则有时可能会覆盖一个或一组class map。为此，这部分的案例将使用NBAR2-前缀。

你可以使用以下命令来检查例29-8中的配置。

■ show class-map

■ show policy-map

■ show policy-map interface

2.NBAR基于应用组的分类模型

在基于应用组的分类模型中，使用命令match protocol 结合application-group 关键字，这样做可以在单一match语句中调用一组应用的子组件。

注释:你可以使用命令show ipnbar attribute application-group来查看共享特定应用组的多个应用子组件。

例29-6 所示案例展示了为多媒体会议类使用NBAR2 基于应用组的分类class map。在前文配置案例中（见例29-8），需要分别使用三条match 语句来匹配Cisco WebEx 应用的语音、会议和应用共享流量这三个子组件；这种配置方式可以被简化为使用一条match protocol application-group语句执行匹配，详见例29-9。

例29-9 Cisco ISR G2 NBAR2（基于应用组的）入向分类模型

ISR-G2(config)# class-map match-all NBAR2-MULTIMEDIA-CONFERENCING

ISR-G2(config-cmap)# match protocol application-group webex-group

你可以使用命令show class-map 来检查例29-9 中的配置。

3.NBAR2基于属性的分类模型

在基于属性的分类模型中，使用命令match protocol 结合attribute 关键字，这样做可以在单一match语句中调用拥有相似特征/属性的多个应用。如前所述，由于NBAR2支持上千个应用特征，那么如果使用每条match语句明确配置特定的应用，那么策略将会很快变得庞大且难以维护。

注释:你可以使用命令show ip nbar attribute category 和show ip nbar attribute subcategory来查看共享特定属性分类和子属性分类的多个应用。

例29-10所示案例展示了NBAR2基于应用和基于属性的分类案例，突出展示了通过IOS MQC和NBAR2能够获得的诸多分类选项。有些class map使用match-all（与逻辑）匹配逻辑，有些使用match-any（或逻辑）匹配逻辑，还有些使用match-not（否逻辑）匹配逻辑。按照需求通过类别或子类别来进行属性匹配。而且还在class map 中同时使用或逻辑和与逻辑分类方式。

例29-10 Cisco ISR G2 NBAR2（基于应用和基于属性的）入向分类模型

! This section configures the NBAR2 class maps

ISR-G2(config-cmap)# class-map match-all NBAR2-VOICE

ISR-G2(config-cmap)# match protocol cisco-phone

! Voice is matched by application-based NBAR2

ISR-G2(config-cmap)# class-map match-all NBAR2-REALTIME-INTERACTIVE

ISR-G2(config-cmap)# match protocol telepresence-media

! TelePresence is matched by application-based NBAR2

ISR-G2(config-cmap)# class-map match-all NBAR2-MULTIMEDIA-CONFERENCING

ISR-G2(config-cmap)# match protocol attribute category voice-and-video

ISR-G2(config-cmap)# match protocol attribute sub-category voice-video-chat-collab-oration

! Multimedia-Conferencing is matched by attribute-based NBAR2

! This class is matched by the voice-and-video category AND

! the voice-video-chat-collaboration subcategory attributes

ISR-G2(config-cmap)# class-map match-all NBAR2-MULTIMEDIA-STREAMING

ISR-G2(config-cmap)# match protocol attribute category voice-and-video

ISR-G2(config-cmap)# match protocol attribute sub-category streaming

ISR-G2(config-cmap)# match not protocol youtube

ISR-G2(config-cmap)# match not protocol netflix

! Multimedia-Streaming is matched by attribute-based NBAR2

! This class is matched by the voice-and-video category AND

! the streaming subcategory attributes AND

! both youtube AND netflix are excluded (via match-not)

! from this class (as these are later included to the Scavenger class)

ISR-G2(config-cmap)# class-map match-any NBAR2-TRANSACTIONAL-DATA

ISR-G2(config-cmap)# match protocol attribute category business-and-productivity-tools

ISR-G2(config-cmap)# match protocol attribute category instant-messaging

! Transactional-Data is matched by attribute-based NBAR2

! This class is matched by EITHER the business-and-productivity-tools

! OR the instant-messaging category

ISR-G2(config-cmap)# class-map match-all NBAR2-CLIENT-SERVER-FILE-SHARING

ISR-G2(config-cmap)# match protocol attribute category file-sharing

ISR-G2(config-cmap)# match protocol attribute sub-category client-server

! This special class map matches by attribute-based NBAR2

! This class is matched by the file-sharing category AND

! the client-server subcategory attributes

ISR-G2(config-cmap)# class-map match-any NBAR2-BULK-DATA

ISR-G2(config-cmap)# match protocol attribute category email

ISR-G2(config-cmap)# match class CLIENT-SERVER-FILE-SHARING

ISR-G2(config-cmap)# match protocol attribute sub-category backup-systems

! Bulk Data is matched by attribute-based NBAR2

! This class is matched by EITHER the email category OR

! the (nested) class map that matches

! (file-sharing AND client-server applications) OR

! the backup-systems subcategory attributes

ISR-G2(config-cmap)# class-map match-all NBAR2-SIGNALING

ISR-G2(config-cmap)# match protocol attribute category voice-and-video

ISR-G2(config-cmap)# match protocol attribute sub-category control-and-signaling

! Signaling is matched by attribute-based NBAR2

! This class is matched by the voice-and-video category AND

! the control-and-signaling subcategory attributes

ISR-G2(config-cmap)# class-map match-all NBAR2-MANAGEMENT

ISR-G2(config-cmap)# match protocol attribute category net-admin

ISR-G2(config-cmap)# match protocol attribute sub-category network-management

! Management is matched by attribute-based NBAR2

! This class is matched by the net-admin category AND

! the network-management subcategory attributes

ISR-G2(config-cmap)# class-map match-any NBAR2-SCAVENGER

ISR-G2(config-cmap)# match protocol youtube

ISR-G2(config-cmap)# match protocol netflix

ISR-G2(config-cmap)# match protocol hulu

ISR-G2(config-cmap)# match protocol attribute category social-networking

ISR-G2(config-cmap)# match protocol attribute category gaming

ISR-G2(config-cmap)# match protocol attribute sub-category p2p-file-transfer

ISR-G2(config-cmap)# match protocol attribute sub-category p2p-networking

! The Scavenger class is matched by both application-

! and attribute-based NBAR2

! This class matches youtube OR netflix OR hulu OR

! the social-networking category OR the gaming category OR

! the p2p-file-transfer subcategory OR the p2p-networking

! subcategory attributes

! This section configures the ingress NBAR2 marking policy map

ISR-G2(config-cmap)# policy-map NBAR2-MARKING

ISR-G2(config-pmap)# class NBAR2-VOICE

ISR-G2(config-pmap-c)# set dscp ef

! Marks IPv4/IPv6 DSCP values to EF for voice

ISR-G2(config-pmap-c)# class NBAR2-REALTIME-INTERACTIVE

ISR-G2(config-pmap-c)# set dscp cs4

! Marks IPv4/IPv6 DSCP values to CS4 for TelePresence

ISR-G2(config-pmap-c)# class NBAR2-MULTIMEDIA-CONFERENCING

ISR-G2(config-pmap-c)# set dscp af41

! Marks IPv4/IPv6 DSCP values to AF41 for multimedia-conferencing

ISR-G2(config-pmap-c)# class NBAR2-MULTIMEDIA-STREAMING

ISR-G2(config-pmap-c)# set dscp af31

! Marks IPv4/IPv6 DSCP values to AF31 for multimedia-streaming

ISR-G2(config-pmap-c)# class NBAR2-TRANSACTIONAL-DATA

ISR-G2(config-pmap-c)# set dscp af21

! Marks IPv4/IPv6 DSCP values to AF21 for transactional-data

ISR-G2(config-pmap-c)# class NBAR2-BULK-DATA

ISR-G2(config-pmap-c)# set dscp af11

! Marks IPv4/IPv6 DSCP values to AF11 for bulk-data

ISR-G2(config-pmap-c)# class NBAR2-SIGNALING

ISR-G2(config-pmap-c)# set dscp cs3

! Marks IPv4/IPv6 DSCP values to CS3 for signaling

ISR-G2(config-pmap-c)# class NBAR2-MANAGEMENT

ISR-G2(config-pmap-c)# set dscp cs2

! Marks IPv4/IPv6 DSCP values to CS2 for management

ISR-G2(config-pmap-c)# class NBAR2-SCAVENGER

ISR-G2(config-pmap-c)# set dscp cs1

! Marks IPv4/IPv6 DSCP values to CS1 for scavenger

ISR-G2(config-pmap-c)# class class-default

ISR-G2(config-pmap-c)# set dscp default

! Marks IPv4/IPv6 DSCP values to DF/DSCP0 for everything else

! This section applies the ingress (application- and

! attribute-based) NBAR2 marking policy to the interface(s)

ISR-G2(config)# interface GigabitEthernet0/2

ISR-G2(config-if)# service-policy input NBAR2-MARKING

你可以使用以下命令来检查例29-10中的配置。

■ show class-map

■ show policy-map

■ show policy-map interface

4.自定义协议NBAR2分类

除了NBAR2已经支持的上千个协议之外，你还能定义自己的自定义协议，来匹配相应的应用，详见以下案例所示。

在例29-11中，自定义协议SALES_APP用来识别源端口为4567的TCP数据包，同时在第一个负载数据包中包含（ASCII）术语SALES。

例29-11 Cisco ISR G2 NBAR2自定义协议案例

ISR-G2(config)# ip nbar custom SALES_APP 5 ascii SALES source tcp 4567

ISR-G2(config)# class-map match-all MATCH-SALES_APP

ISR-G2(config-cmap)# match protocol SALES_APP

你可以使用以下命令来检查例29-11中的配置。

■ show ip nbar port-map（详见例29-12）

■ show class-map

例29-12 检查自定义NBAR2协议:showipnbar port-map

ISR-G2# show ip nbar port-map SALES_APP

port-map SALES_APP　　　　tcp 4567

ISR-G2#

在例29-13中，自定义协议NEW_VIRUS用来识别目的端口为3000的UDP数据包，同时在第一个负载数据包的第7字节中包含（十六进制值）0x56。

例29-13 Cisco ISR G2 NBAR2自定义协议案例

ISR-G2(config)# ip nbar custom NEW_VIRUS 7 hex 56 destination udp 3000

ISR-G2(config)# class-map match-all MATCH-NEW_VIRUS

ISR-G2(config-cmap)# match protocol NEW_VIRUS

你可以使用以下命令来检查例29-13中的配置。

■ show ip nbar port-map

■ show class-map

在例29-14中，自定义协议NEW_MEDIA用来识别目的端口或源端口在4500～4510（包含）之间的TCP数据包，同时在负载的第6字节中包含（十进制值）90。只有第一个数据包要在偏移量6的位置检查十进制值90。

例29-14 Cisco ISR G2 NBAR2自定义协议案例

ISR-G2(config-cmap)# ip nbar custom NEW_MEDIA 6 decimal 90 tcp range 4500 4510

ISR-G2(config)# class-map match-all MATCH-NEW_MEDIA

ISR-G2(config-cmap)# match protocol NEW_MEDIA

你可以使用以下命令来检查例29-14中的配置。

■ show ip nbar port-map

■ show class-map

29.4 出向QoS模型

一般来说，WAN边界的出向QoS模型要与那些配置在WAN汇聚WAN边界的QoS模型（详见第28章）相匹配。但这些策略中仍有一些微小的例外/差别。

举例来说，有些应用类是单向的，这种流通常是从园区流向分支的（比如广播视频类和多媒体流应用类）。有些分支的WAN边界设计中可能会有选择地忽略这些应用类。但你一定要牢记，IOS软件会自动将这些类中未使用的带宽重新分配给需要带宽的其他类中——因此从分支WAN边界路由器中删除这些类也并不会带来太多好处。除此之外，为了保持策略的简洁、一致，并且易于排错，你最好在分支WAN边界和WAN汇聚WAN边界实施相同的策略。

在调试WRED 时可能有点小区别。WAN 汇聚平台（比如Cisco ASR 1000）的默认队列深度很可能与分支路由器平台（比如Cisco ISR G2）的默认队列深度不一样。这时，两台设备上的策略中需要反映出队列深度的区别以及WRED门限值的区别。

通常人们会说分支WAN边界出向QoS模型与WAN汇聚WAN边界出向QoS模型几乎相同。

29.4.1 4类模型

分支路由器上的4类WAN边界出向QoS模型与WAN汇聚路由器上的4类WAN边界出向QoS模型相同，详见例29-5。

29.4.2 8类模型

分支路由器上的8类WAN边界出向QoS模型与WAN汇聚路由器上的8类WAN边界出向QoS模型相同，详见例29-8。

29.4.3 12类模型

分支路由器上的12类WAN边界出向QoS模型与WAN汇聚路由器上的12类WAN边界出向QoS模型几乎相同，详见例29-9。唯一的区别是要按照Cisco ISR G2的默认队列深度（64个数据包）来调整WRED门限值，详见例29-15。

注释:在例29-15中，所有应用类（包括从园区到分支的单向流）都与WAN汇聚WAN边界上的应用类相同，保持了一致性。

注释:为了减少重复，没有重复class map的配置（详见例29-9）。

注释:本例中调整了基于DSCP的WRED值，AFx3数据包会在到达（大概）60%默认队列深度（64个数据包）时开始随即丢弃，AFx2数据包是70%，AFx1数据包是80%。在默认队列中，数据包都被标记为DF/DSCP 0，并只在80%时开始被丢弃。

例29-15 Cisco ISR G2 12类出向队列模型案例

! This section defines the Twelve-Class egress queuing policy

! with tuned WRED thresholds (for the ISR G2)

ISR-G2(config-cmap)# policy-map ISR-TWELVE-CLASS-WAN-EDGE

ISR-G2(config-pmap)# class VOICE

ISR-G2(config-pmap-c)# priority percent 10

! Provisions the VOICE class with 10% LLQ

ISR-G2(config-pmap-c)# class BROADCAST-VIDEO

ISR-G2(config-pmap-c)# priority percent 10

! Provisions the BROADCAST-VIDEO class with 10% LLQ

ISR-G2(config-pmap-c)# class REALTIME-INTERACTIVE

ISR-G2(config-pmap-c)# priority percent 13

! Provisions the REALTIME-INTERACTIVE class with 13% LLQ

ISR-G2(config-pmap-c)# class NETWORK-CONTROL

ISR-G2(config-pmap-c)# bandwidth percent 2

! Provisions the NETWORK-CONTROL class with 2% CBWFQ

ISR-G2(config-pmap-c)# class SIGNALING

ISR-G2(config-pmap-c)# bandwidth percent 2

! Provisions the SIGNALING class with 2% CBWFQ

ISR-G2(config-pmap-c)# class NETWORK-MANAGEMENT

ISR-G2(config-pmap-c)# bandwidth percent 3

! Provisions the NETWORK-MANAGEMENT class with 3% CBWFQ

ISR-G2(config-pmap-c)# class MULTIMEDIA-CONFERENCING

ISR-G2(config-pmap-c)# bandwidth percent 10

! Provisions the MULTIMEDIA-CONFERENCING class with 10% CBWFQ

ISR-G2(config-pmap-c)# fair-queue

! Enables a fair-queuing pre-sorter

ISR-G2(config-pmap-c)# random-detect dscp-based

! Enables DSCP-based WRED

ISR-G2(config-pmap-c)# random-detect dscp af43 40 64

! Tunes minimum DSCP-WRED threshold for AF43 to 60% queue-depth

ISR-G2(config-pmap-c)# random-detect dscp af42 45 64

! Tunes minimum DSCP-WRED threshold for AF42 to 70% queue-depth

ISR-G2(config-pmap-c)# random-detect dscp af41 50 64

! Tunes minimum DSCP-WRED threshold for AF41 to 80% queue-depth

ISR-G2(config-pmap-c)# class MULTIMEDIA-STREAMING

ISR-G2(config-pmap-c)# bandwidth percent 10

! Provisions the MULTIMEDIA-STREAMING class with 10% CBWFQ

ISR-G2(config-pmap-c)# fair-queue

! Enables a fair-queuing pre-sorter

ISR-G2(config-pmap-c)# random-detect dscp-based

! Enables DSCP-based WRED

ISR-G2(config-pmap-c)# random-detect dscp af33 40 64

! Tunes minimum DSCP-WRED threshold for AF33 to 60% queue-depth

ISR-G2(config-pmap-c)# random-detect dscp af32 45 64

! Tunes minimum DSCP-WRED threshold for AF32 to 70% queue-depth

ISR-G2(config-pmap-c)# random-detect dscp af31 50 64

! Tunes minimum DSCP-WRED threshold for AF31 to 80% queue-depth

ISR-G2(config-pmap-c)# class TRANSACTIONAL-DATA

ISR-G2(config-pmap-c)# bandwidth percent 10

! Provisions the TRANSACTIONAL-DATA class with 10% CBWFQ

ISR-G2(config-pmap-c)# fair-queue

! Enables a fair-queuing pre-sorter

ISR-G2(config-pmap-c)# random-detect dscp-based

! Enables DSCP-based WRED

ISR-G2(config-pmap-c)# random-detect dscp af23 40 64

! Tunes minimum DSCP-WRED threshold for AF23 to 60% queue-depth

ISR-G2(config-pmap-c)# random-detect dscp af22 45 64

! Tunes minimum DSCP-WRED threshold for AF22 to 70% queue-depth

ISR-G2(config-pmap-c)# random-detect dscp af21 50 64

! Tunes minimum DSCP-WRED threshold for AF21 to 80% queue-depth

ISR-G2(config-pmap-c)# class BULK-DATA

ISR-G2(config-pmap-c)# bandwidth percent 4

! Provisions the BULK-DATA class with 4% CBWFQ

ISR-G2(config-pmap-c)# fair-queue

! Enables a fair-queuing pre-sorter

ISR-G2(config-pmap-c)# random-detect dscp-based

! Enables DSCP-based WRED

ISR-G2(config-pmap-c)# random-detect dscp af13 40 64

! Tunes minimum DSCP-WRED threshold for AF13 to 60% queue-depth

ISR-G2(config-pmap-c)# random-detect dscp af12 45 64

! Tunes minimum DSCP-WRED threshold for AF12 to 70% queue-depth

ISR-G2(config-pmap-c)# random-detect dscp af11 50 64

! Tunes minimum DSCP-WRED threshold for AF11 to 80% queue-depth

ISR-G2(config-pmap-c)# class SCAVENGER

ISR-G2(config-pmap-c)# bandwidth percent 1

! Constrains the SCAVENGER class to 1% CBWFQ

ISR-G2(config-pmap-c)# class class-default

ISR-G2(config-pmap-c)# bandwidth percent 25

! Provisions the default/Best-Effort class with 25% CBWFQ

ISR-G2(config-pmap-c)# fair-queue

! Enables a fair-queuing pre-sorter

ISR-G2(config-pmap-c)# random-detect dscp-based

! Enables DSCP-based WRED

ISR-G2(config-pmap-c)# random-detect dscp default 50 64

! Tunes minimum DSCP-WRED threshold for DF to 80% queue-depth

! This section applies the queuing policy to a DS3 Serial interface

ISR-G2(config)#interface Serial1/0

ISR-G2(config-if)# service-policy output ISR-TWELVE-CLASS-WAN-EDGE

! Attaches egress queuing service policy to the interface

你可以使用以下命令来检查例29-15中的配置。

■ show class-map

■ show policy-map

■ show policy-map interface

29.5 其他与平台相关的QoS设计选项

这些设计展示了分支路由器QoS设计的基本元素，但这绝不是仅有的设计选项。其他涉及选项和考量因素如下所示:

■ RSVP；

■ AutoQoS；

■ 控制层面限速。

接下来按顺序简要介绍这些QoS设计选项和考量因素。

29.5.1 RSVP

分支路由器上的RSVP（资源预留协议）设计与WAN汇聚服务路由器上的RSVP设计相同。前一章已经详述了相关设计，本章不再赘述。

29.5.2 AutoQoS SRND4

正如第28章提到的，（在本书写作时）ISR G2 路由器的Cisco IOS 不支持AutoQoS SRND4。但该平台支持AutoQoS-VoIP和AutoQoS-Enterprise。

29.5.3 控制层面限速

Cisco IOS 支持控制层面限速（CPP），附录B 中详细介绍了该特性的设计建议。

29.6 小结

本章介绍了分支路由器的QoS角色，并阐述了Cisco ISR G2家族是如何适合这个角色的。

本章详细介绍了入向QoS 设计，重点关注Cisco IOS 的DPI 功能，其中包括媒体网络元数据分类和NBAR2分类。此外展示了这些分类方法如何基于应用、基于应用组和基于属性来实施。本章还讨论了如何将自定义协议映射到NBAR2分类引擎，来实现企业自定义的应用分类。

接着概述了出向QoS设计，大部分内容都与前一章中的4类、8类和12类队列模型相同。但本章还展示了在ISR G2 上调整12 类队列模型的案例。

本章最后还讨论了其他QoS设计选项，其中包括RSVP、AutoQoS和CPP。

29.7 扩展阅读

媒体网WAN汇聚QoS设计4.0:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSWAN_40.html

Cisco IOS 15M&T版本—QoS配置指南:http://www.cisco.com/en/US/docs/ios-xml/ios/qos/config_library/15-mt/qos-15-mt-library.html

Cisco IOS 15M&T 版本—媒体网元数据配置指南:http://www.cisco.com/en/US/docs/ios-xml/ios/mdata/configuration/15-mt/metadataframework.html

Cisco IOS 15M&T版本—媒体网NBAR集成配置指南:http://www.cisco.com/en/US/docs/ios-xml/ios/mdata/configuration/15-mt/mdatanbar-intgrtn.html

Cisco IOS 15M&T 版本—NBAR 配置指南:http://www.cisco.com/en/US/docs/ios-xml/ios/qos_nbar/configuration/15-mt/qos-nbar-15-mt-book.html

Cisco NBAR2 协议图书馆:http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6558/ps6616/product_bulletin_c25-627831.html

第30章 WAN和分支QoS设计的案例研究

Tifosi的（有线和无线）园区网络已经准备就绪，网络团队准备将QoS部署扩展到更大范围中。他们部署WAN QoS 的第一步要关注他们的私有WAN 基础设施。

Tifosi使用Cisco ASR 1000系列路由器（使用ESP20和SIP10）作为WAN汇聚服务路由器，使用Cisco 3925E ISR G2 或Cisco 3945E ISR G2 作为分支路由器（取决于分支的规模）。

Tifosi使用混合的链路类型来实现WAN连通性，其中包括直连串行和POS链路，以及ATM 链路。链路速率从T3/DS3（45 Mbit/s）到OC3（155 Mbit/s）不等。

Tifosi的网络团队在其WAN和分支的QoS设计中有以下两个主要目标:

1.部署他们的战略8类QoS模型（详见第12章）；

2.通过使用ASR和ISR路由器上的DPI（深度数据包检测）功能，提高应用分类的粒度。

图30-1展示了Tifosi（私有）WAN和分支网络中实施的QoS策略。

Tifosi希望尽可能将他们的QoS策略简化并模块化。为此，他们要部署带宽使用百分比（这样，单独的队列策略可以受到全部链路速率的影响）。除此之外，他们决定在WAN汇聚和分支路由器上使用相同的LAN边界和WAN边界策略。

这样一来，Tifosi的WAN和分支QoS策略如下所述。

■ 策略1:ASR 1000的内部（PLIM）QoS

■ 启用基于SIP的PLIM；

■ 启用基于SPA的PLIM。

■ 策略2:LAN边界QoS策略

■ 在入方向上信任DSCP（Cisco IOS 默认设置）；

■ 参照表30-1，在入方向上执行NBAR2协议分类；

■ 在出方向上部署8类队列模型（只有Tifosi的WAN汇聚路由器需要，因为这里存在WAN到LAN的超额预订，后文详述）。

图30-1 Tifosi Software案例研究:WAN和分支网络QoS设计

表30-1 Tifosi的8类DPI分类和标记策略表

■ 策略3:WAN边界QoS策略

■ 信任DSCP（Cisco IOS 默认）；

■ 在出方向上部署8类队列模型。

30.1 策略1:ASR 1000的内部（PLIM）QoS

Tifosi的WAN汇聚路由器上存在着潜在的内部拥塞，这种拥塞是由于ESP20和SIP10G这种硬件组合方式导致的（表28-1中已指明）。因此这些路由器上需要启用PLIM（物理层接口模块）QoS，来防止实时语音和TelePresence流量受到内部超额预订的影响。

串行接口和POS接口需要启用基于SIP的PLIM，GE接口和ATM接口需要启用基于SPA的PLIM。下面将按顺序介绍每个选项。

30.1.1 策略1a:基于SIP的PLIM QoS

串行接口和POS接口需要启用基于SIP的PLIM，详见例30-1。

例30-1 Tifosi的WAN汇聚设计:Cisco ASR 1000上基于SIP的内部调度机制分类案例

! This section defines the ingress scheduling classification template

ASR(config)# ingress-class-map 1

ASR(config-ing-class-map)# map ip dscp-based

ASR(config-ing-class-map)# map ip dscp 32 queue strict-priority

! Maps DSCP 32/CS4 (Realtime Interactive) to the internal PQ

! (EF is already mapped to the internal PQ by default)

...

ASR(config)# interface Serial0/1/0

ASR(config-if)# plim qos input class-map 1

! Attaches the SIP-based PLIM ingress scheduling template

! to the Serial interface

...

ASR(config)# interface POS0/2/0

ASR(config-if)# plim qos input class-map 1

! Attaches the SIP-based PLIM ingress scheduling template

! to the POS interface

30.1.2 策略1b:基于SPA的PLIM QoS

GE接口和ATM接口需要启用基于SPA的PLIM，详见例30-2。

例30-2 Tifosi的WAN汇聚设计:Cisco ASR 1000上基于SPA的内部调度机制分类案例

ASR(config)# interface GigabitEthernet0/0/0

ASR(config-if)# plim qos input map ip dscp-based

ASR(config-if)# plim qos input map ip dscp cs4 queue strict-priority

! Maps CS4 (Realtime Interactive) to the internal PQ for the GE int

! (EF is already mapped to the internal PQ by default)

...

ASR(config)# interface ATM4/1/0

ASR(config-if)# plim qos input map ip dscp-based

ASR(config-if)# plim qos input map ip dscp cs4 queue strict-priority

! Maps CS4 (Realtime Interactive) & to the internal PQ for the ATM int

! (EF is already mapped to the internal PQ by default)

30.2 策略2:LAN边界QoS策略

WAN 和分支LAN 边界QoS 策略要在入方向上信任DSCP（这是Cisco IOS 默认设置），并通过NBAR2执行精细的深度数据包检测。检测流量中包含识别名为SALES_APP的自定义（业务性数据）协议。

例30-3展示了Tifosi在WAN汇聚和分支路由器LAN边界上应用的（入向）QoS策略。

例30-3 Tifosi案例研究:LAN边界（入向）QoS策略

! This section configures the custom NBAR2 protocol SALES_APP

ASR/ISR(config)# ip nbar custom SALES_APP 5 ascii SALES source tcp 4567

! This section configures the NBAR2 class-maps

ASR/ISR(config-cmap)# class-map match-all NBAR2-VOICE

ASR/ISR(config-cmap)# match protocol cisco-phone

! Voice is matched by the cisco-phone NBAR2 protocol

ASR/ISR(config-cmap)# class-map match-all NBAR2-REALTIME-INTERACTIVE

ASR/ISR(config-cmap)# match protocol telepresence-media

! TelePresence is matched by the telepresence-media NBAR2 protocol

ASR/ISR(config-cmap)# class-map match-all NBAR2-SIGNALING

ASR/ISR(config-cmap)# match protocol attribute category voice-and-video

ASR/ISR(config-cmap)# match protocol attribute sub-category control-and-signaling

! Signaling is matched the voice-and-video category AND

! the control-and-signaling sub-category NBAR2 attributes

ASR/ISR(config-cmap)# class-map match-all NBAR2-MULTIMEDIA-CONFERENCING

ASR/ISR(config-cmap)# match protocol attribute category voice-and-video

ASR/ISR(config-cmap)# match protocol attribute sub-category voice-video-chat-col-

laboration

! Multimedia-Conferencing is matched by the voice-and-video category

! AND the voice-video-chat-collaboration sub-category NBAR2 attributes

ASR/ISR(config-cmap)# class-map match-any NBAR2-TRANSACTIONAL-DATA

ASR/ISR(config-cmap)# match protocol SALES_APP

ASR/ISR(config-cmap)# match protocol attribute category business-and-productivity-

tools

ASR/ISR(config-cmap)# match protocol attribute category instant-messaging

! Transactional-Data is matched by the custom SALES_APP OR

! the business-and-productivity-tools category OR

! the instant-messaging category NBAR2 attributes

ASR/ISR(config-cmap)# class-map match-all NBAR2-CLIENT-SERVER-FILE-SHARING

ASR/ISR(config-cmap)# match protocol attribute category file-sharing

ASR/ISR(config-cmap)# match protocol attribute sub-category client-server

! This special class-map matches the file-sharing category AND

! the client-server sub-category NBAR2 attributes

ASR/ISR(config-cmap)# class-map match-any NBAR2-BULK-DATA

ASR/ISR(config-cmap)# match protocol attribute category email

ASR/ISR(config-cmap)# match protocol attribute sub-category backup-systems

ASR/ISR(config-cmap)# match class CLIENT-SERVER-FILE-SHARING

! Bulk Data is matched by the email category OR

! the backup-systems sub-category NBAR2 attributes OR

! the (nested) class-map that matches the

! (file-sharing AND client-server NBAR2 attributes)

ASR/ISR(config-cmap)# class-map match-any NBAR2-SCAVENGER

ASR/ISR(config-cmap)# match protocol youtube

ASR/ISR(config-cmap)# match protocol netflix

ASR/ISR(config-cmap)# match protocol hulu

ASR/ISR(config-cmap)# match protocol attribute category social-networking

ASR/ISR(config-cmap)# match protocol attribute category gaming

ASR/ISR(config-cmap)# match protocol attribute sub-category p2p-file-transfer

ASR/ISR(config-cmap)# match protocol attribute sub-category p2p-networking

! The Scavenger class is matched by youtube OR netflix OR hulu

! NBAR2 protocols OR the social-networking category (which includes

! facebook) OR the gaming category OR the p2p-file-transfer

! sub-category OR the p2p-networking sub-category NBAR2 attributes

! This section configures the ingress NBAR2 marking policy map

ASR/ISR(config-cmap)# policy-map LAN-EDGE

ASR/ISR(config-pmap)# class NBAR2-VOICE

ASR/ISR(config-pmap-c)# set dscp ef

ASR/ISR(config-pmap-c)# class NBAR2-REALTIME-INTERACTIVE

ASR/ISR(config-pmap-c)# set dscp cs4

ASR/ISR(config-pmap-c)# class NBAR2-SIGNALING

ASR/ISR(config-pmap-c)# set dscp cs3

ASR/ISR(config-pmap-c)# class NBAR2-MULTIMEDIA-CONFERENCING

ASR/ISR(config-pmap-c)# set dscp af41

ASR/ISR(config-pmap-c)# class NBAR2-TRANSACTIONAL-DATA

ASR/ISR(config-pmap-c)# set dscp af21

ASR/ISR(config-pmap-c)# class NBAR2-BULK-DATA

ASR/ISR(config-pmap-c)# set dscp af11

ASR/ISR(config-pmap-c)# class NBAR2-SCAVENGER

ASR/ISR(config-pmap-c)# set dscp cs1

ASR/ISR(config-pmap-c)# class class-default

ASR/ISR(config-pmap-c)# set dscp default

! This section applies the LAN edge policy to an ASR GE int

ASR(config)# interface GigabitEthernet0/0/0

ASR(config-if)# service-policy input LAN-EDGE

注释:在ISR G2分支路由器的GE LAN接口上也应该应用相应的LAN边界策略。

注释:对于通过NBAR2来匹配应用类的class map（与之不同的是WAN边界class map——前文章节和本章后续内容中都会再次使用——它们使用DSCP标记来匹配应用类），有必要为其配置唯一的名称；否则有时可能会覆盖一个或一组class map。为此，这部分的案例将使用NBAR2-前缀。

30.3 策略3:WAN边界QoS策略

图30-2展示了Tifosi的8类WAN边界队列模型（详见第12章）。

图30-2 Tifosi Software案例研究:8类队列模型

例30-4给出了WAN队列策略的相应配置。

例30-4 Tifosi案例研究:WAN边界QoS策略

! This section configures the DSCP-matching class maps

! for the Tifosi eight-class egress queuing policy

ASR/ISR(config-cmap)# class-map match-all VOICE

ASR/ISR(config-cmap)# match dscp ef

ASR/ISR(config-cmap)# class-map match-all REALTIME-INTERACTIVE

ASR/ISR(config-cmap)# match dscp cs4

ASR/ISR(config-cmap)# class-map match-all SIGNALING

ASR/ISR(config-cmap)# match dscp cs3

ASR/ISR(config-cmap)# class-map match-all MULTIMEDIA-CONFERENCING

ASR/ISR(config-cmap)# match dscp af41

ASR/ISR(config-cmap)# class-map match-all TRANSACTIONAL-DATA

ASR/ISR(config-cmap)# match dscp af21

ASR/ISR(config-cmap)# class-map match-all BULK-DATA

ASR/ISR(config-cmap)# match dscp af11

ASR/ISR(config-cmap)# class-map match-all SCAVENGER

ASR/ISR(config-cmap)# match dscp cs1

! This section defines the eight-class WAN-edge egress queuing policy

ASR/ISR(config-cmap)# policy-map WAN-EDGE

ASR/ISR(config-pmap)# class VOICE

ASR/ISR(config-pmap-c)# priority percent 10

ASR/ISR(config-pmap-c)# class REALTIME-INTERACTIVE

ASR/ISR(config-pmap-c)# priority percent 23

ASR/ISR(config-pmap-c)# class SIGNALING

ASR/ISR(config-pmap-c)# bandwidth percent 2

ASR/ISR(config-pmap-c)# class MULTIMEDIA-CONFERENCING

ASR/ISR(config-pmap-c)# bandwidth percent 10

ASR/ISR(config-pmap-c)# fair-queue

ASR/ISR(config-pmap-c)# random-detect dscp-based

ASR/ISR(config-pmap-c)# class TRANSACTIONAL-DATA

ASR/ISR(config-pmap-c)# bandwidth percent 25

ASR/ISR(config-pmap-c)# fair-queue

ASR/ISR(config-pmap-c)# random-detect dscp-based

ASR/ISR(config-pmap-c)# class BULK-DATA

ASR/ISR(config-pmap-c)# bandwidth percent 4

ASR/ISR(config-pmap-c)# fair-queue

ASR/ISR(config-pmap-c)# random-detect dscp-based

ASR/ISR(config-pmap-c)# class SCAVENGER

ASR/ISR(config-pmap-c)# bandwidth percent 1

ASR/ISR(config-pmap-c)# class class-default

ASR/ISR(config-pmap-c)# bandwidth percent 25

ASR/ISR(config-pmap-c)# fair-queue

ASR/ISR(config-pmap-c)# random-detect

! This section tunes the Serial interface Tx-Ring and

! attaches the 8-class WAN-edge queuing policy

ASR(config)# interface Serial0/1/0

ASR(config-if)# tx-ring-limit 10

! Optimizes the T3 Tx-Ring for rich media applications

ASR(config-if)# service-policy output WAN-EDGE

! Attaches the WAN-edge queuing policy to the Serial interface

! This section attaches the 8-Class WAN-edge queuing policy

! to a POS interface

ASR(config)# interface POS0/2/0

ASR(config-if)# service-policy output WAN-EDGE

! Attaches the WAN-edge queuing policy to the POS interface

! This section attaches the 8-Class WAN-edge queuing policy

! to an ATM OC3 PVC

ASR(config)# interface ATM4/1/0.1 point-to-point

ASR(config-if-atm)# pvc 0/112

ASR(config-if-atm-pvc)# vbr-rt 149760 149760

! Defines the ATM traffic contract:

! Variable Bit Rate – Realtime (OC-3)

ASR(config-if-atm-pvc)# service-policy output WAN-EDGE

! Attaches the WAN-edge queuing policy to the (OC3) ATM PVC

注释:在ISR G2分支路由器的WAN接口上也应该应用相应的LAN边界策略。

Tifosi的网络管理员在WAN汇聚路由器上将所有WAN链路的带宽汇聚在一起，发现它超出了LAN 边界链路速率1 Gbit/s。因此（在这种超额预订的情况下）为了保护WAN 到LAN方向的流量，他们决定在GE LAN 边界链路上应用相同的8 类WAN 边界策略，详见例30-5。

例30-5 Tifosi案例研究:向LAN边界链路（仅在WAN汇聚路由器上）应用WAN边界QoS策略

! This section applies the 8-class WAN-edge queuing policy

! to the LAN-Edge GE interface (WAN Aggregator only)

ASR(config)#interface Gigabit 0/0/0

ASR(config-if)# service-policy output WAN-EDGE

! Attaches the WAN-edge queuing policy to the LAN-edge

! GE interface (on the WAN aggregator)

注释:由于在去往分支的WAN到LAN方向上都不存在超额预订，因此没有必要在分支路由器的LAN边界链路上应用8类WAN边界策略。

30.4 小结

本章继续学习Tifosi Software 的案例，着重为保护他们的私有WAN 网络，在WAN 汇聚和边界路由器上应用战略8类端到端QoS模型。

LAN边界和WAN边界策略都经过了简化和模块化，因此可以在WAN汇聚服务Cisco ASR 1000 路由器和Cisco ISR G2 分支路由器上，为其全部链路速率应用相同的策略。

LAN边界策略中使用了NBAR2应用识别，为流量类别提供深度数据包检测（这种功能超出了园区网接入交换机的能力范围）。除此之外，使用NBAR2类别和子类别属性简化了这些分类策略，这样无需配置冗长且复杂的策略配置，也可以轻松匹配庞大数量的应用协议。

WAN边界策略使用Cisco IOS LLQ/CBWFQ和WRED优化了WAN上的8类战略QoS模型。WAN汇聚路由器的LAN边界上也应用了相同的8类WAN边界模型，为了管理WAN到LAN方向上的超额预订现象。

30.5 扩展阅读

媒体网WAN汇聚QoS设计4.0:http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSWAN_40.html

ASR 1000 QoS体系结构:http://www.cisco.com/en/US/prod/collateral/routers/ps9343/solution_overview_c22-449961_ps9343_Product_Solution_Overview.html

Cisco IOS QoS配置指南图书馆:Cisco IOS 15M&T 版本:http://www.cisco.com/en/US/docs/ios-xml/ios/qos/config_library/15-mt/qos-15-mt-library.html

Cisco IOS 15M&T—NBAR配置指南:http://www.cisco.com/en/US/docs/ios-xml/ios/qos_nbar/configuration/15-mt/qos-nbar-15-mt-book.html

Cisco NBAR2协议图书馆:http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6558/ps6616/product_bulletin_c25-627831.html

第7部分 MPLS VPN QoS设计

第31章 MPLS VPN QoS设计的注意事项与建议

QoS（服务质量）除了在私有WAN和分支网络中提供的两种功能外（即通过队列策略管理数据包丢失和抖动，以及利用DPI[深度包检测]引擎加强分类粒度），在MPLS（多协议标签交换）VPN（虚拟专用网络）中，QoS的作用还会扩展到以下方面:

■ 按照合约定义的服务速率对流量进行整形；

■ 在整形速率内，执行分层的队列和丢弃行为；

■ 将企业服务标记映射为运营商服务标记；

■ 根据合约定义的速率对流量类别进行限速；

■ 恢复数据包标记。

因此，在MPLS VPN QoS 设计中应用的战略性QoS 设计原则包括以下内容（战略性QoS设计原则详见第11章）。

■ 在技术条件和管理条件均可行的条件下，在尽可能靠近源的位置对应用进行分类和标记:有些分类策略可能需要感知第7层的内容，而中心和分支的Catalyst交换机可能没有能力执行这种分类。因此在有技术能力实施这种详尽分类的设备中，CE（客户边界）路由器可能是最靠近源的设备了。

■ 在尽量靠近源的地方对不需要的流量进行限速:运营商将根据合约定义的速率来测量流量，并在PE（运营商边界）的入向边界设备上实施这些策略。当流量超出速率限制时，运营商可能会对流量进行重新标记或丢弃，或者对用户收取额外的费用。

■ 为了防止发生拥塞，在每个节点都启用队列策略，无论该节点发生拥塞的可能性有多小:在所有CE和PE边界设备上启用队列策略，同时也在运营商核心网络中启用队列策略（以防存在超额预定的情况）。

■ 启用控制层面限速来保护控制层面:加固网络基础设施，缓解并抑制网络攻击。

然而，在将这些战略性QoS设计原则转换为特定平台的配置命令前，你需要考虑与MPLS VPN相关的额外因素，包括以下内容:

■ MPLS VPN 基础设施；

■ 承载以太网服务；

■ 亚线路速率（Sub-Line Rate）以太网设计指导；

■ QoS思考模式的转变；

■ 运营商的服务类别模型；

■ MPLS DiffServ 隧道的模式；

■ 企业到运营商的映射；

■ MPLS VPN 接口QoS 角色。

接下来将依次讨论这些与MPLS VPN 相关的注意事项。

31.1 MPLS VPN基础设施

MPLS VPN 基础设施由以下设备构成:

■ CE路由器；

■ PE路由器；

■ P（核心）路由器。

图31-1 展示了在MPLS VPN 基础设施中，这些路由器各自的角色。

根据RFC2547（BGP MPLS VPN）中的定义，MPLS VPN 为所有互联的CE 路由器提供全网状的第3层虚拟WAN服务。正是这种全网状增加了QoS的复杂性，前文已经简要提到过。现在我们先来看看MPLS VPN 的接入链路。

图31-1 MPLS VPN基础设施和路由器角色

31.2 MAN和WAN以太网服务的演变

建议:

■ 以太网正迅速占据MAN/WAN中的主导地位——这在LAN环境中已成为了事实。

由于大众的认知——以及事实上的主导地位——以太网作为最主要的LAN协议，客户开始要求他们的运营商（SP）拓展以太网功能，使他们的多站点LAN能够无缝地连接在一起。首先会通过城域网（MAN）连接多站点LAN，之后还会通过广域网（WAN）进行连接。

为此，城域以太网论坛（MEF）于2001年成立，为那些通过城市网络连接LAN的企业用户开发无所不在的商业服务。最主要的概念是将以太网的简单性和成本模型引入到WAN中。

为了创造出广域以太网服务的市场，首先需要将SP能够提供的服务进行说明和标准化。基于这一考量，MEF定义了下列主要的以太网连通性服务。

■ E-Line:通过WAN连接两个客户以太网端口的服务。E-Line是基于点到点EVC（以太网虚拟连接）的，并定义了以下两个E-Line服务。

■ 以太网私有线路（EPL）:这是简单而基本的点到点服务，其特征是提供较低的数据帧延迟、数据帧延迟变化率和数据帧丢失率。不允许进行业务复用，而且——除了CIR（承诺信息速率）以外——不允许根据CoS（服务类别）设置带宽参数。

■ 以太网虚拟私有线路（EVPL）:这是允许业务复用（多于一个EVC）的点到点服务。可以为单独的EVC定义丰富的带宽配置参数，并能够为第2层控制协议提供多种处理方法。

■ E-LAN:连接多个客户端点设备的多点服务，使客户能够以桥接以太网络的方式连接站点。E-LAN是基于多点到多点EVC的。允许业务复用（多于一个EVC），提供丰富的性能保证，比如将CIR与CBS（承诺突发大小）和EIR（超额信息速率）关联在一起。

■ E-Tree:点到多点的E-LAN服务，在这种环境中，分支（叶）能够与中心（根）站点进行通信，但分支之间不能相互通信。E-Tree的典型应用是连锁企业的运作模式。

随着MPLS VPN 的发展，其日益增强的能力扩展了以太网的覆盖范围。举例来说，RFC 3985中定义了伪线（PW，Pseudo Wire）标准，即在MPLS隧道中使用MPLS LSP（标签交换路径），来透明地连接以太网LAN。PW既支持点到点VPWS（虚拟私有线路服务），也支持多点VPLS（虚拟私有LAN 服务）。在此之后，RFC 4448 定义了EoMPSL（基于MPLS 的以太网），即通过进一步模拟以太网LAN的功能，扩展了PW的功能。

Cisco IP NGN（下一代网络）承载以太网的体系结构更进了一步:由于几乎所有的流量都始发于以太网，因此其设计目标是将以太网贯穿于整个SP网络中，无论是保持以太网本身的形式，还是将其作为虚拟/仿真服务。IP NGN的重要技术基础包括MPLS VPN、EoMPLS、H-VPLS （分层VPLS）、IPoDWDM（基于DWDM[ 密集波分复用] 的IP）、IEEE 802.1ad，以及融合以太网、IP 和MPLS 技术。图13-2 展示了Cisco IP NGN 体系结构。

需要记住的是，以太网已经作为主流协议融入了MAN和WAN中，从QoS设计的角度看来，这个事实具有独特的借鉴意义，详见后续内容。

图31-2 Cisco IP NGN承载以太网体系结构

31.3 亚线路速率以太网设计的启示

建议:

■ 了解QoS对于亚线路速率以太网接入带来的影响（尤其是根据CE路由器接入链路上的嵌套队列策略，来实施分层整形的需求）；

■ 配置CE整形器的Bc（承诺突发）值，使其不超过SP限速器Bc值的一半。

对于企业客户和SP来说，以太网的普遍性和灵活性使其成为多种VPN接入媒介中最具吸引力的选择。企业用户不再需要购买特殊的线卡和模块来支持WAN协议，比如ATM和POS。同样地，SP也能够简化其对于硬件要求。此外，通过亚线路速率以太网服务，SP能够为用户提供灵活且可扩展的服务。

亚线路速率以太网服务（如名称所示）表示合约中定义的流量速率小于GE链路的容量，可能低至1 Mbit/s或高达999 Mbit/s。此外，这种合约是灵活的；无需升级硬件就可以增加带宽，这对于固定速率的WAN链路来说，增加带宽通常意味着升级硬件。举例来说，假设一条点到点WAN 链路的速率是T3/DS3（45 Mbit/s），如果要在链路上增加更多带宽，将需要对模块的硬件进行升级，并且这种链路所支持的更高速率为OC3（155 Mbit/s），这是跨度非常大的速率升级（超过300%）。相反，如果一个用户使用45Mbit/s的亚线路速率以太网服务，那么他可以在SP所能承受的范围内（以任意增量）提高带宽，而无需升级任何硬件。假设SP支持5 Mbit/s 增量，那么用户可以逐步且经济地升级，以满足不断变化的业务需求，比如先升级为50Mbit/s，再升级为55 Mbit/s 等。

然而从QoS的角度来看，需要额外关注亚线路速率。正如前面所讨论的，队列策略只有当物理接口拥塞时才会发挥作用（在Cisco IOS 软件中，即Tx-Ring 排满）。这意味着，在使用亚线路速率进行接入的媒介上，队列策略永远不会发挥作用，无论该介质是帧中继、ATM或以太网。在这种情况下，为了在亚线路速率环境中使用队列机制，只能引入一个由两部分组成的策略，也称为分层QoS（HQoS）策略或嵌套QoS策略，详见以下描述。

1.以亚线路速率对流量进行整形。

2.在亚线路速率的限制内，根据LLQ/CBWFQ策略对流量进行排队。

在使用HQoS策略时，通知IOS软件开始应用LLQ/CBWFQ策略的就不再是Tx-Ring了，而是在流量达到整形速率的限制时，由基于类的整形器来通知IOS软件。图31-3展示了HQoS策略。

图31-3 Cisco IOS HQoS（根据嵌套队列进行整形）策略的工作原理

此外，企业整形器的具体配置方法与SP的入向限速器之间有着特殊的关联。整形器和限速器都使用令牌桶算法（详见第4章）。最重要的一点是，整形器的Bc（承诺突发值）要小于入向限速器的Bc值；否则，通过了整形器的流量很可能会被运营商的入向限速器丢弃。

整形器的工作是通过引入延迟实现的。从理论上说，即在每个数据包之间加入空闲时间。只有基于硬件的整形器——比如Cisco Catalyst 3750 交换机所使用的技术——可以实现这种理论。Cisco IOS 整形器使用软件算法，来强制数据包产生延迟。Cisco 基于IOS 的整形器使用以下公式进行计算:

承诺突发（Bc）值=承诺信息速率（CIR）*时间间隔（Tc）

将目标带宽（CIR）进行划分，在固定的Tc（时间间隔）中进行发送，并限制在每个Tc之内，只能发送Bc字节的数据；超出Bc字节的流量必须等待下一个可用的Tc。一般来说，Tc越小，流量的整形效果越平滑。这种算法一般还是有效的，但要牢记以下细节。首先，IOS整形器能够划分的最小Tc是4毫秒。这意味着所有数据包之间的空闲时间并不是相等的；并且在一个Tc内，接口仍以线路速率发送数据包。如果排列数据包的队列深度大于Bc字节，那么在每个Tc刚一开始的时候，Bc字节内的所有数据包都会按顺序被发送出去，发送完成后会有一段强制空闲期。实际上，如果在持续的一段时间内，实际发送速率都高于CIR速率，整形器就会允许一定量的突发，并将突发流量的大小也限制为Bc字节。再者，每个Tc都与独立于前一个Tc。突发数据包可能会在一个Tc快要结束时到达整形器，并正好占用了全部突发的Bc字节；然后紧接着一个新的Tc开始了，整形器又允许发送下一个Bc字节的流量。也就是说，尽管接口总是以线路速率发送Bc字节的流量，但也有可能会以线路速率发送两倍于Bc字节的流量。每当整形器开始一个新的Tc时，就会忽略前一个Tc中流量的发送情况。

在理解整形器的工作原理时，还要考虑另一个特性，即部分数据包。当数据包到达时，它的长度超出了当前Tc内还允许发送的比特数（即剩余Bc所对应的比特数），这时出现的情况就称为部分数据包。有两种方法可以处理这一问题。第一种方法是延迟发送数据包，一直等到Bc桶中有足够发送该数据包的比特数之后，才发送数据包。这种方法有两个缺点。首先，接口无法达到CIR速率，因为在Tc超时的时侯，Bc桶中仍有剩余的可发送比特数。其次，虽然剩余的Bc比特数不足以发送大数据包，但可能足够发送尺寸小很多的数据包（大数据包后面可能排有这种小数据包）。上述两个问题促使我们研究如何能够最大化地利用剩余的Bc比特数。从而产生了第二种方法，即路由器会从下一个Tc内借用一些比特，以便及时传输到达的大数据包。图31-4展示了使用整形器带来的影响。

在MPLS VPN 设计的环境中，客户的设备上会配置整形器，来确保设备发送的流量不会超出合约中的带宽限制。反过来，SP的设备上会配置限速器，也是为了强制流量不会超出合约中的带宽限制。设计的实际结果是，使用整形器来防止上游的限速器丢弃数据包。通常情况下，SP在设置限速器时并不会考虑客户是否设置了整形器。如果客户知道SP的限速器参数，就可以根据这个参数来正确配置自己的整形器了。

理解限速器和整形器之间的理论差异，有助于理解它们在部署上的差别。首先，限速器不会对数据包进行排队，任何超出了速率限制的数据包都会被丢弃。整形器恰恰相反，只有所有队列空间都被占用后，才会有数据包被丢弃。使用限速器时，路由器不需要主动发出任何动作，只需做出响应即可。整形器的行为是主动的:必须对队列加以管理；要基于固定的Tc计时器来触发事件。整形算法使用令牌桶；在每个Tc开始时，向令牌桶中添加Bc个令牌；当数据包到达时，整形算法会查看令牌桶中是否有足够多的可用令牌。如果有足够多的令牌，算法就会允许数据包进入Tx-Ring，并从令牌桶中减去数据包大小的令牌。

图31-4 Cisco IOS整形器的工作原理和影响

如果令牌桶中没有足够多的令牌，那么数据包必须在队列中等待。在每个Tc间隔内，会有Bc个令牌被放入令牌桶中。如果有数据包在队列中等待，那么这些数据包将会被发送，发送过程直到队列为空或令牌桶再次耗尽令牌为止。

相比之下，限速是被动的行为；没有时间常量，也无需管理队列；只需做出简单的判断，即放行或丢弃数据包。在限速过程中，令牌桶一开始装满了Bc令牌。当数据包到达时，时间间隔要从上一个数据包开始计算。这段时间内所经过的时间乘以CIR，其结果决定了要向令牌桶中添加多少个令牌。在加入相应数量的令牌后，将数据包的大小与令牌桶中的令牌数量进行对比。如果令牌足够多，就把数据包放到Tx-Ring中，同时从令牌桶中减去该数据包大小的令牌。如果令牌桶中没有足够多的可用令牌，数据包将被丢弃。当限速速率接近接口的线路速率时，令牌桶的大小就变得不那么重要了。因为当CIR等于线路速率时，令牌桶的令牌消耗速度会和重新填入令牌的速度相同。

在使用整形器时，添加令牌是个周期性的事件；但在使用限速器时，添加令牌的行为与数据包的到达时间有关，因此在讨论限速器时，并没有时间常量（Tc）的概念。与这个概念最近接的情形是:在一直没有新数据包到达的情况下，令牌桶从空到完全填满所需的时间。在理想情况下，整形器以线路速率发送Bc字节，这些字节正好消耗了限速器Bc桶中的全部令牌；然后利用发送Bc字节后的强制空闲时间，限速器能够重新填满Bc桶。整形器的强制空闲时间是这样计算出来的:Tc * (1–CIR/ 线路速率)。在实际情况中，整形器的最佳设置原则是:保持限速器的Bc桶不消耗超过一半的令牌量。当整形CIR等于限速CIR时，将整形器的Bc值设置为限速器Bc值的一半，就可以确保实现上述原则了。

31.4 QoS思考模式的转变

建议:

■ 要认识到企业和运营商必须合作，共同管理MPLS VPN 中的QoS。

在了解了MPLS VPN 接入的第2 层QoS 注意事项后，网络管理员现在要继续考虑第3 层QoS的相关因素了。

如前所述，MPLS VPN 在中心网和分支网络之间提供了全网状的连通性。正因为MPLS VPN 具有全网状的特性，对比传统的第2 层私有WAN QoS 设计，为我们呈现了一个重要的QoS设计理念:私有WAN（通常部署在点到点拓扑或星形拓扑中）。

由于成本、可扩展性和可管理性的局限性，传统的私有WAN设计几乎不使用全网状模型。相反，大多数第2层WAN设计中会反复出现星型模型，无论是拥有一个中央中心站点的星型模型，还是拥有多个局部中心站点的星型模型（效率更高）。在这种星型设计中，企业需要在中心路由器（也称为WAN汇聚路由器）上集中实施QoS。一旦SP提供的服务满足了合约中定义的服务级别，那么在远端分支接收到的数据包将能够反映出中心路由器上实施的调度策略。WAN汇聚路由器不仅仅控制中心到分支的流量，它还控制着分支到分支的流量（通过中心路由器进行转发）。在传统的星型模型中，QoS是由企业客户进行管理的，详见图31-5。

图31-5 传统星型第2层私有WAN设计中的QoS管理

然而，由于MPLS VPN 服务提供了全网状连接，QoS 的管理模式将进行转变。在全网状设计中，中心路由器仍负责管理所有中心到分支流量的QoS，但它不再完全控制分支到分支流量的QoS。尽管看起来在这种新环境中，唯一必需的改变是确保在所有分支路由器上都部署QoS，但仅仅这样做还不够，因为这种做法只解决了部分问题。

以部署任意到任意的多媒体会议为例。由于使用了传统第2层WAN设计，因此需要在WAN汇聚路由器上配置调度策略，以此来优化多媒体会议的质量。而且企业还必须在分支路由器上，也为多媒体会议配置相似的优先级调度策略。这样一来，从中心去往分支（以及从分支去往分支）的多媒体会议呼叫都会受到保护，免受在这些站点之间传输的非重要流量的影响。但考虑到争夺带宽的流量可能不总是来自这些站点，也可能来自任何站点，这样一来，全网状模型的复杂性就暴露出来了。而且，企业不再完全控制分支到分支流量的QoS，因为这些流量不再通过中心路由器进行转发。继续上面的案例，如果在两个分支之间建立了一个多媒体会议呼叫，其中一个分支的用户还同时开始从中心站点下载大FTP文件，这时从全网状的MPLS VPN云到其中一个分支的（PE到CE）链路很可能出现超额预定的情况，从而导致多媒体会议呼叫被断开。

在这种情况中，唯一能够确保服务水平的方法是，让SP部署的QoS调度机制，与企业在所有连接远端分支的PE链路上实施的限速策略相匹配。这就是全网状拓扑结构中的QoS管理需要进行思考模式转变的原因——企业和SP 必须合作，共同管理MPLS VPN 中的QoS，如图31-6所示。

图31-6 全网状MPLS VPN设计中的QoS管理

由于MPLS VPN 实施了全网状的互联，因此必须在CE 和PE 路由器的出向边界上实施队列策略。而且，PE路由器上还将实施入向的限速策略，来强制执行SLA（服务水平协议）。

P路由器上的QoS策略是可选的。这是因为有些运营商MPLS核心网络的部署是冗余的，因此骨干网内不需要实施任何额外的QoS策略；其他运营商可能会在骨干中部署简单的DiffServ 策略，或者部署MPLS TE（流量工程），来应对骨干网内的拥塞问题。

31.5 运营商的服务类别模型

建议:

■ 完全理解你的运营商的CoS模型；

■ 如果可以的话，尽可能选择最符合你的战略性端到端模型的CoS模型。

提供给用户的CoS（服务类别）模型是由SP自行定义的。没有适用于所有情况的模型，因为这些CoS模型通常是SP差异性战略的重要组成部分。然而在本书写作时，大多数运营商提供4类或6类CoS模型，少部分提供8类（或更多）CoS模型。

需要根据数据包标记（通常使用DSCP）来判断SP给定的CoS。但每个SP为每个类别指定的标记会有所不同，而且重标记/丢弃策略以及每个类别的带宽分配也会不同。

当有多个SP模型可以选择时，建议用户选择最符合自己的战略性端到端QoS模型的（而不是反过来比较）。换句话说，管理员不应该根据SP所能提供的CoS模型来选择自己的QoS模型。

31.6 MPLS DiffServ隧道的模式

建议:

■ 了解MPLS DiffServ 隧道的模式，以及它能够对用户的DSCP 标记带来何种影响；

■ 短管道模式为企业客户提供透传服务，并在流量穿越MPLS VPN 云时，客户能够控制他们的流量类别。

因为MPLS标签中包含EXP位（实验位），这3个二进制数字常用于QoS标记，因此可以借助它们来实施“隧道DiffServ”——也就是在流量通过SP 的MPLS VPN 云的过程中，保留客户的第3层DiffServ标记，但同时SP又能够在云中执行重标记行为（通过MPLS EXP位），以便指明流量是否遵从合约的定义。

RFC 3270 中定义了三种不同的MPLS DiffServ 隧道模式:

■ 统一模式（Uniform Mode）；

■ 短管道模式（Short Pipe Mode）；

■ 管道模式（Pipe Mode）。

接下来将依次讨论每个MPLS DiffServ 隧道模式。

31.6.1 统一模式

建议:

■ 要注意，如果你的运营商使用统一模式的MPLS VPN DiffServ 隧道，你的数据包可能会被重新标记DSCP值。

通常当客户和SP共享相同的DiffServ域时，会使用统一模式，比如企业部署了自己的MPLS VPN 核心网。

统一模式是默认模式。在使用统一模式时，入向PE设备会在将标签添加到数据包上时，将IP ToS 字段的前3 位（IP 优先级位）自动映射到MPLS EXP 位。

如果MPLS 核心网中的限速器或其他机制重新标记了MPLS EXP 值，这些标记的变化会被复制到低级别的标签中，并最终复制到IP ToS 字段中（出向PE 设备会将MPLS EXP 位映射到IP优先级值中）。

图31-7 展示了统一模式的MPLS DiffServ 隧道的工作原理。

图31-7 统一模式MPLS DiffServ隧道的工作原理

如图31-7 所示，企业客户的DSCP 标记在传输过程中，被使用统一模式MPLS DiffServ隧道的SP重新标记了。

31.6.2 短管道模式

建议:

■ 对于那些想实现透传，且想要最大化控制自己流量的企业客户来说，短管道模式MPLS DiffServ 隧道是合理的选择。

当客户和运营商属于不同DiffServ域时，可以使用短管道模式（SP的DiffServ域范围是:从入向PE设备的入向接口开始，到出向PE设备的入向接口为止）。

这种模式适用于以下情形:SP想要强制执行自己的DiffServ策略，而客户要求在流量穿越MPLS VPN 云的过程中，保留自己的DiffServ 信息。短管道模式在流量穿越SP 网络的过程中，为客户提供了DiffServ透传服务（这一点与管道模式相同）。

在短管道模式中，最外层的标签是最有意义的信息来源，因为这个标签与SP的QoS PHB（逐跳行为）息息相关。在入向PE设备为数据包添加MPLS标签时，IP分类信息是不会被复制到最外层标签的EXP 中的。添加的MPLS EXP 值是依据SP 的管理策略，明确配置在入向PE 设备的入向接口上的。

当在SP 的MPLS VPN 云中出现重新标记的行为时，只有MPLS EXP 会被重新标记，新的标签并不会被复制到下层IP数据包的ToS字节中。图31-8展示了短管道模式的MPLS DiffServ隧道的工作原理。

图31-8 短管道模式MPLS DiffServ隧道的工作原理

如图31-8所示，运营商可以任意标记MPLS EXP值，来传递本地的PHB信息（与客户在数据包中标记的值没有任何关系）。从而在流量的传输过程中，客户的标记得以保留，并当数据包离开MPLS VPN时，用户能够继续使用原始的标记值。而且最后的PE出向队列策略是根据客户的标记来执行的，这在流量穿越MPLSVPN的过程中，为客户提供了最大化的数据包QoS控制能力。

31.6.3 管道模式

建议:

■ 管道模式会保留用户数据包的标记，但这些标记不会影响PE设备的出向队列策略。

短管道模式和管道模式的MPLS DiffServ 隧道之间的主要区别在于，后者PE 设备（面向客户CE）的出向策略是根据SP 的明确标记和重标记来实施的，而不是根据客户的IP DiffServ标记来实施（尽管客户的标记也保留了下来）。在使用短管道模式时，在SP云中发生的所有标签标记行为，当数据包离开MPLS 网络时，都不会被复制到IP ToS 字节中。图31-9 展示了管道模式的MPLS DiffServ 隧道的工作原理。

图31-9 管道模式MPLS DiffServ隧道的工作原理

如图31-9所示，管道模式的工作模式与短管道模式是相同的，唯一的不同是最后PE设备的出向队列策略是根据运营商的标记（而不是客户的标记）实施的。

31.7 企业到运营商的映射

建议:

■ 根据需求，有效地将企业的应用类别映射到运营商的CoS类别中。

有时候，SP（运营商）的CoS类别数量等于（或多于）企业在其战略端到端QoS策略中定义的应用类别数量；但实际情况并不总是这样。

如果企业的应用类别数量多于SP的CoS数量，企业管理员需要将企业的应用类别映射到SP的CoS模型中，管理员可以通过汇总和结合应用类别，有效地实施映射，并在此过程中执行必须的重新标记行为。

在执行企业到运营商的映射时，需要考虑以下内容:

■ 映射实时语音和视频流量；

■ 映射信令和控制流量；

■（可能的话）将基于UDP的应用与基于TCP的应用分隔开；

■（按需）重新标记和恢复数据包标记。

接下来将详细介绍企业到运营商映射的注意事项。

31.7.1 映射实时语音和视频

建议:

■ 在实时语音和视频应用所需的服务级别，和需要为实时流量带宽向SP支付的费用之间进行权衡；

■ 无论在哪种情况下，在CE设备的出向边界上实施双LLQ策略。

SP通常只用一个CoS来表示实时流量。如果你——作为企业的网络管理员——同时部署了实时语音和视频应用（也就是实时交互式应用类别），你就需要决定是否要把视频放到SP的实时类别中。

选择将实时语音和视频都映射到SP的实时CoS中，其结果是为这些实时应用提供最高级别的服务。这种做法的缺点是，一般运营商会以非常昂贵的价格出售实时带宽。因此，将视频分配到这个类可能花费很高（甚至过高）。但如果企业还是这样做了——与私有WAN设计相同——建议在CE设备的出向边界上使用双LLQ（或多LLQ）策略，来保护语音流量免受视频流量的干扰。

选择将实时视频降级映射到非实时的SP CoS，通常更符合成本效益，而且这样做对视频质量造成的影响也不大。如果企业选择了这种做法，仍应该在CE设备的出向边界（这个节点仍然由企业进行管理）上使用双LLQ（或多LLQ）策略。这样一来，视频只有在PE设备的出向边界上无法获得实时服务，这种做法在节约成本的前提下最大程度地减少了服务级别的损失。

31.7.2 映射控制和信令流量

建议:

■ 避免将控制层面流量和数据层面流量混合到一个SP CoS 中。

只要有可能，就应该将控制和信令流量分配到一个专用的SP CoS 中。否则的话，如果将这类流量与数据层面的流量放在一起，当这个类别出现超额预订的情况时，控制层面的流量可能会被丢弃，从而降低网络或语音/视频服务的稳定性。有时SP会自动将网络控制流量（标记为DSCPCS6）映射到专用的CoS中。

如果受到CoS类别数量的限制，无法为控制或信令流量提供专用的类别，可以考虑将这些控制层面的流量映射到SP的实时CoS中（因为这些流量通常很小，但非常重要）。

31.7.3 将TCP和UDP分隔开

建议:

■ 在将流量类别映射到SP的CoS类别中的时候，将TCP流量和UDP流量分隔开。

不在一个SP CoS 中混合TCP 流量和UDP 流量（尤其当UDP 流量是流媒体视频流量时，比如广播视频或多媒体流应用类别）的做法，是通用的最佳做法建议。其原因在于拥塞期间这类协议的行为。具体来说，TCP在检测到丢包后，会降低传输速率。尽管有些UDP应用也具有应用级别的滑动窗口、流量控制和重传功能，但大多数UDP应用会完全忽略丢包，因此也不会因为丢包而降低传输速率。

在将TCP 流量与UDP 流量映射到一个SP CoS 的情况中，当这个类别遭遇拥塞时，TCP流量会不断地降低传输速率，将带宽“让给”忽略丢包的UDP流量。这种效应被称为TCP饥饿或UDP主导。

即使在SP类别中启用了WRED（加权随机早期检测），仍会发生相同的情况，因为WRED（主要）负责管理TCP流量的拥塞。

当然，也总有无法分离TCP流量和UDP流量的情况，在决定将这两种应用放入同一个SP类别中时，知道这种做法会带来什么后果也总是好的。

31.7.4 重新标记和恢复标记

建议:

■（按需）在CE设备的出向边界上重新标记应用类别；

■（按需）通过DPI（深度数据包检测）策略，在CE设备的入向边界上恢复标记。

大多数SP 会使用数据包携带的DSCP 标记，来决定该数据包属于哪个SP CoS 类别。因此企业必须遵照SP的管理类别来标记（或重新标记）他们的流量，以便获得相应的服务级别。

通用的DiffServ原则是在技术条件和管理条件均可行的条件下，在尽可能靠近源的位置标记或信任流量。但有时需要在将特定类型的流量交给SP之前，对其进行重新标记，以便正确对应SP定义的类别。如果需要实施这种重新标记行为，建议在CE设备的出向边界上执行重新标记行为，而不要在企业网络中执行。这是因为随着时间的推移，SP提供的服务可能进一步发展或扩展，当企业需要跟随这种变化修改流量的标记时，只需在CE设备的出向边界管理标记就显得简单多了。

在有些案例中，企业可能需要将多个流量类型重新标记为相同的DSCP值，以便映射到相应的SP CoS 中。或者（如前所述）使用统一模式MPLS DiffServ 隧道的SP，在SP 云中可能会对违反合约的流量进行重新标记（第3层标记），这会影响到企业的端到端第3层标记。

无论是哪种情况，在流量离开MPLS VPN时，都已经不能仅凭DSCP标记来区分流量了。好在可以通过同样的LAN边界DPI（深度数据包检测，详见第29章）策略轻松地恢复DSCP标记，这时DPI 是应用在（VPN 边界）CE 路由器的入方向上的（也就是将从MPLS VPN 收到的流量进行重新分类，因为这些流量可能在传输过程中丢失了DSCP标记）。

31.8 MPLS VPN的QoS角色

建议:

■ 为所有路由器接口定义一致的入向和出向QoS策略。

根据MPLS VPN 中不同的路由器节点，前文讨论的QoS 策略元素可以分为以下角色，如图31-10所示。

图31-10 MPLS VPN的QoS角色

适用于这些角色的QoS策略如下所示。

1.面向中心网的CE设备入向/内部QoS（ASR1000）:可能应用入向/内部QoS策略（按需）。

2.面向LAN 边界的CE 设备:

■ 应该启用入向DSCP信任特性（默认启用）；

■ 可能应用入向NBAR2分类和标记策略；

■ 可能应用入向媒体网元数据分类和标记策略；

■ 可能应用出向LLQ/CBWFQ/WRED策略（按需）。

3.面向VPN 边界的CE 设备:

■ 应该启用入向DSCP信任特性（默认启用）；

■ 可能应用入向NBAR2分类和标记策略（以便恢复在传输过程中丢失的DSCP标记）；

■ 可能应用入向媒体网元数据分类和标记策略；

■ 可能应用RSVP策略；

■ 应该应用出向LLQ/CBWFQ/WRED策略（按需）；

■ 可能应用根据嵌套LLQ/CBWFQ/WRED策略进行整形的出向策略；

■ 可能应用出向DSCP 重标记策略（以便将企业应用类别映射到SP CoS 中）。

4.PE 设备入向/ 内部QoS（ASR 9000）:可能应用入向/ 内部QoS 策略（按需）。

5.面向用户边界的PE设备:

■ 应该启用入向DSCP信任特性（默认启用）；

■ 应该应用入向限速策略来测量客户流量；

■ 可能应用入向MPLS隧道模式策略；

■ 可能应用出向MPLS隧道模式策略；

■ 应该应用出向LLQ/CBWFQ/WRED策略。

6.面向核心边界的PE设备:

■ 应该启用入向DSCP信任特性（默认启用）；

■ 应该应用入向限速策略来测量客户流量；

■ 应该应用基于MPLS EXP 的出向LLQ/CBWFQ 策略；

■ 可能应用基于MPLS EXP 的出向WRED 策略。

7.P设备（核心路由器）入向/内部QoS（CRS-3）:可能应用入向/内部QoS策略（按需）。

8.边界P设备:

■ 应该启用入向DSCP信任特性（默认启用）；

■ 可能应用基于MPLS EXP 的出向LLQ/CBWFQ 策略（除非核心有冗余或启用了MPLS TE）；

■ 可能应用基于MPLS EXP 的出向WRED 策略。

31.9 小结

本章讨论了企业网MPLS VPN QoS 设计的注意事项与建议。MPLS VPN 中的QoS 具有以下功能:

■ 管理数据包丢失和抖动；

■ 按照合约定义的服务速率对流量进行整形；

■ 在整形速率内，执行分层的队列和丢弃行为；

■ 将企业服务标记映射为运营商服务标记；

■ 根据合约定义的速率对流量类别进行限速；

■ 恢复数据包标记。

适用于MPLS VPN 网络中的QoS 设计原则包括以下内容:

■ 在技术条件和管理条件均可行的条件下，在尽可能靠近源的位置对应用进行分类和标记；

■ 在尽量靠近源的地方对不需要的流量进行限速；

■ 为了防止发生拥塞，在每个节点都启用队列策略，无论该节点发生拥塞的可能性有多小。

本章概述了MPLS VPN基础设施，突出了通过MAN和WAN连接以太网日益重要的作用。接着讨论了使用亚线路速率的以太网链路的QoS设计，以及它们对于分层（根据嵌套队列进行整形）策略的需求，并建议将整形器的承诺突发值设置为SP的入向限速器的承诺突发值的一半。

QoS的思考模式需要转变，企业和SP必须合作，依照SP的CoS模型，共同管理MPLS VPN上的QoS。

接着介绍了MPLS DiffServ隧道的模式，展示了统一模式如何能够覆盖客户的DSCP标记，管道模式和短管道模式如何能够为客户提供DSCP透传。除此之外，还强调了短管道模式优于管道模式的特点。

继而讨论了各种企业到SP映射的注意事项，其中包括如何映射实时语音和视频流量、如何映射控制和信令流量，以及为什么要将TCP和UDP流量分隔开。这部分还包括实施重标记的建议，以及如何恢复在传输过程中丢失的DSCP标记。

最后对所有建议进行了总结，并汇总成不同的MPLS VPN接口QoS角色，包括以下内容:

■ 面向中心网的CE设备入向/内部QoS（仅适用于ASR）；

■ 面向LAN边界的CE设备；

■ 面向VPN边界的CE设备；

■ 面向客户边界的PE设备；

■ 面向核心边界的PE 设备；

■ 边界P设备。

31.10 扩展阅读

RFC 2547，BGP MPLS VPN:http://www.ietf.org/rfc/rfc2547

RFC 3270，MPLS对DiffServ的支持:http://www.ietf.org/rfc/rfc3270

RFC 3985，PWE3（伪线模拟边界到边界）体系结构:http://www.ietf.org/rfc/rfc3985

RFC 4448，在MPLS网络中传输以太网的封装方式:http://www.ietf.org/rfc/rfc4448

IP NGN 承载以太网设计:提升泽字节（Zettabyte）时代的互联生活:http://www.cisco.com/en/US/solutions/collateral/ns341/ns524/ns562/ns577/net_implementation_white_paper0900aecd806a7df1_ns537_Networking_Solutions_White_Paper.html

第32章 企业客户边界（Cisco ASR 1000和ISR G2）的QoS设计

企业客户边界路由器需要执行许多QoS策略，其中包括:

■ 将网络流量整形为合同规定的亚线路服务速率（sub-line service rate）。

■ 执行分层的队列技术，在这些经过整形的速率范围内丢弃数据包，以管理丢包和抖动的现象。

■ 在企业-服务供应商的服务类型标记之间建立映射。

■ 将那些从MPLS VPN 云接收的流量中，由于应用深层数据包分类检测而被丢弃的数据包标记恢复回来。

图32-1说明了企业客户边界路由器中的一些接口所扮演的QoS角色。

ASR1000 和ISR G2 路由器都可以作为企业边缘路由器来提供服务——使用哪款路由器取决于连接到MPLS VPN 的分支网络规模和链路速率。

由于我们已经（在第28章和第29章中）介绍过这些平台的架构，因此在这一章中，我们会介绍在直接将这些平台作为企业客户边界路由器进行部署时，QoS的设计步骤。

图32-1 企业客户边界路由器接口的QoS角色

32.1 QoS设计步骤

在一台担任企业客户边界路由器的Cisco ISR G2 路由器上配置QoS 可以分为两个步骤。

1.配置入站方向的QoS模型，包括以下内容:

■ DSCP信任状态（在IOS中默认即启用）；

■ 媒体网络元数据的分类和标记；

■ NBAR2的分类和标记。

2.配置出站方向的QoS策略，包括以下内容:

■ 队列和丢弃策略；

■ 分层整形（嵌套的队列和丢弃）策略（按需）。

下面我们会这些设计步骤分别进行介绍。

32.2 入站方向的QoS模型

在Cisco IOS 系统中，信任状态默认就已经开启，所以对于入站数据包的DSCP 信任状态，并不需要进行什么配置。

对于分类和标记，所有深度数据包监控策略（媒体网元数据应用识别或NBAR2）的详细配置方法均与第29章中介绍的方式相同。

这里顺便说一句，有些入站LAN边界的策略也可以应用在入站VPN边界的位置上，以通过DPI 技术来识别应用身份，以及恢复在MPLS VPN 云中（或者在企业- 服务提供商的标记转换过程中）丢失的标记。从配置的角度上看，管理员需要为此增加的配置非常简单——在VPN 边界接口的接口配置模式下输入service-policy input 就搞定了。

32.3 出站的QoS模型

企业客户边界路由器的出口队列模型与WAN边界队列模型几乎相同，不过在分配某些带宽时，可能需要适应于服务提供商的服务等级（CoS）模型。

除了队列和丢弃策略之外，对于企业客户边界路由器，可能还需要增加另外两项策略:

■ 通过嵌套的队列和丢弃策略来实现分层的整形策略；

■ 企业-服务提供商的标记映射（重标记）策略。

这两点会在下文中依次进行详细的介绍。

32.3.1 亚线路速率以太网:分层整形与队列模型

以太网迅速地成为了一种主流的WAN/LAN传输介质，而且通常使用的是亚线路速率（sub-line rate）。但由于在Cisco IOS 系统中，队列和丢弃策略不会参与亚线路速率流量的限制，因此需要通过另外的整形器在队列机制中，提前（换句话说，在物理接口出现堵塞之前）对流量施加压力。另外，本书在前面的章节中也曾提到过，我们推荐将整形器的承诺突发量设置为服务提供商入站限速器承诺突发量的一半以下。但管理员未必都能知道服务提供商入站限速器的突发量是多少，因此本书将在下文中介绍两个例子:在其中一个例子中，服务提供商的Bc是已知的；另一个例子则是未知的。

1.已知服务提供商限制的承诺突发量

在第一个例子中，服务提供商提供了一个4类的CoS模型，其中每一类的流量都限制在10Mbit/s流量以内，同时将承诺Bc（突发量）设置为200KB。因此，推荐将整形器的Bc设置在800Kb以下（用200KB乘以每字节8位，再除以2）。顺便说一句，由此得到的整形时间间隔即为20ms（Tc=Bc/CIR）。例32-1显示了如何通过套嵌的队列策略，来配置这种分层的亚线路速率整形策略。

例32-1 Cisco ISR G2(CE Router)分层整形和队列模型

! This section configures the hierarchical shaper

! with nested queuing policy

ISR-G2(config-pmap)# policy-map CE-EDGE-SHAPING

ISR-G2(config-pmap)# class class-default

ISR-G2(config-pmap-c)# shape average 40M 800K

! Shapes to 40 Mbps with 800 Kbit Bc

ISR-G2(config-pmap-c)# service-policy CE-EDGE-QUEUING

! Provides backpressure on the IOS queuing subsystem for the

! CE-EDGE-QUEUING queuing policy to engage

! when the shaping limit is reached

! This section applies the sub-line-rate shaper to the VPN edge int

ISR-G2(config)#interface GigabitEthernet0/2

ISR-G2(config-if)# service-policy output CE-EDGE-SHAPING

! Attaches the HQoS shaper to the CE Edge interface

注释:的确，在例32-1中的汇聚整形器模型有可能会导致这4类流量之一，超过SP对于它们限制的速率（极端的例子是，某一类流量占用了40Mbit/s流量，而其他类型的流量则全部遭到了忽略）。不过，这个破绽同样适用于线速交换的环境，因为在出现拥塞之前，设备是不会执行队列策略的。

但要注意，只有各类流量都按照分配给它们的速率比例进入设备，这个例子中调试的整形器才会达到最高的效率。

还有一种做法是使用分层整形器而不是汇聚整形器来执行QoS操作，也就是每个类别一个专用的整形器。不过，这种策略过于复杂，而且也会占用过多的CPU资源。此外，这样的策略可能会浪费带宽（因为服务提供商整形器重标记的流量比丢弃流量的还多）

管理员可以通过下列命令来验证例32-1中的配置。

■ show class-map

■ show policy-map

■ show policy-map interface

2.不知道服务提供商限制的承诺突发速率

如果不知道服务提供商的入站承诺突发速率，可以按照时间间隔为10ms，来设置分层整形器的保障突发速率值（Bc），这是Cisco十多年来一直推荐用户采用的通用富媒体整形推荐方案。

注释:在一些不常见的环境中，10ms的时间间隔还是有可能会造成SP PE边界入站整形器丢弃数据包，在这种环境中，可以将整形数值设置得更低一些。Cisco IOS最小的整形承诺突发量，是以4ms的最小整形时间间隔来进行计算的结果。不过有一点一定要搞清楚，那就是整形间隔的值越小，整形器对QoS子系统执行的中断次数也就越多，而边界CPU对QoS策略造成的影响也就越大。

这种配置方法的一个弊端是有可能会引入一些额外的整形延迟，因为数据包在转发前可能需要等待多个整形时间间隔（10ms）。然而，一旦整形器将数据包发送出去，这些数据包就几乎不可能被入站服务提供商的限制器所丢弃（前提是这些数据包的速率没有超过这个类别的限制速率）。

继续前面的例子，我们将承诺突发量设置为400Kb（40Mbit/s CIR*10ms Tc）。例32-2 显示了如何配置包含套嵌队列策略的第二个分层的子线路速率整形策略。

例32-2 Cisco ISR G2(CE Router)分级整形和队列模型

! This section configures the hierarchical shaper

! with nested queuing policy

ISR-G2(config-pmap)# policy-map CE-EDGE-SHAPING

ISR-G2(config-pmap)# class class-default

ISR-G2(config-pmap-c)# shape average 40M 400K

ISR-G2(config-pmap-c)# service-policy CE-EDGE-QUEUING

! Provides backpressure on the IOS queuing subsystem for the

! CE-EDGE-QUEUING queuing policy to engage

! when the shaping limit is reached

! This section applies the sub-line-rate shaper to the VPN edge int

ISR-G2(config)#interface GigabitEthernet0/2

ISR-G2(config-if)# service-policy output CE-EDGE-SHAPING

! Attaches the HQoS shaper to the CE Edge interface

管理员可以通过下列命令来验证例32-2中的配置。

■ show class-map

■ show policy-map

■ show policy-map interface

32.3.2 企业-服务供应商的映射模型

正如本书在前面的章节所介绍的那样，世上没有放之四海而皆准的CoS模型——因为不同服务提供商之间的CoS模型区别很大，而服务提供商也需要借此来体现相互之间的竞争优势。

因此，在实际应用中，可以使用三种独立的服务提供商模型作为企业映射模型:

■ 4-CoS服务提供商模型；

■ 6-CoS服务提供商模型；

■ 8-CoS服务提供商模型。

就像本书在前面的设计章节所介绍的那样，在基于应用的企业战略QoS模型中，包含一个4类的模型、一个8类的模型和一个12类的模型。它们中的每一个模型都可以与一个相应的服务提供商模型相对应，下面我们分别来介绍这些对应关系。

1.将4类企业模型映射为一个4-CoS的服务提供商模型

这个四四对应的企业-服务提供商模型是最容易进行配置的，由于企业应用类的数量和相应的服务提供商提供的服务类型之间存在一一对应关系，因此这种映射不需要进行重标记，也不需要拆解某个类型。唯一一个可能需要作一点调整的是为每种类别分配的带宽，具体分配的带宽应该由服务提供商的策略来决定。

图32-2显示了如何将一个4类企业模型映射为一个4类的服务提供商模型。

图32-2 将4类企业模型映射为一个4类的服务提供商模型

例32-3所示为图32-2所对应的CE路由器配置。为了进一步完善这个案例，我们将这个队列策略映射到了例32-1中的分层（亚线路速率）整形策略中。

例32-3 将Cisco ISR G2（CE路由器）4类企业模型映射为1个4类服务提供商模型的配置案例

! The class maps for this policy are identical to the

! Four-class egress queuing model in Example 28-5

! and therefore will not be repeated here for the sake of brevity

! This section defines a four-class enterprise to

! Four-class service provider queuing policy map

ISR-G2(config)# policy-map FOUR-CLASS-ENT-TO-FOUR-CLASS-SP

ISR-G2(config-pmap)# class REALTIME

ISR-G2(config-pmap-c)# priority percent 30

! Provisions the REALTIME class with 30% LLQ

ISR-G2(config-pmap)# class CONTROL

ISR-G2(config-pmap-c)# bandwidth percent 10

! Provisions the CONTROL class with 10% CBWFQ

ISR-G2(config-pmap)# class TRANSACTIONAL-DATA

ISR-G2(config-pmap-c)# bandwidth percent 35

! Provisions the TRANSACTIONAL-DATA class with 35% CBWFQ

ISR-G2(config-pmap-c)# fair-queue

! Enables a fair-queuing pre-sorter

ISR-G2(config-pmap-c)# random-detect dscp-based

! Enables DSCP-based WRED

ISR-G2(config-pmap)# class class-default

ISR-G2(config-pmap-c)# bandwidth percent 25

! Provisions the default/Best Effort class with 25% CBWFQ

ISR-G2(config-pmap-c)# fair-queue

! Enables a fair-queuing pre-sorter

ISR-G2(config-pmap-c)# random-detect

! Enables WRED

! This section configures the hierarchical shaper

! with nested queuing policy

ISR-G2(config-pmap)# policy-map CE-EDGE-SHAPING

ISR-G2(config-pmap)# class class-default

ISR-G2(config-pmap-c)# shape average 40M 800K

! Shapes to 40 Mbps with 800 Kbit Bc

ISR-G2(config-pmap-c)# service-policy FOUR-CLASS-ENT-TO-FOUR-CLASS-SP

! Provides backpressure on the IOS queuing subsystem for the

! four-class queuing policy to engage when the shaping limit is reached

! This section applies the sub-line-rate shaper to the VPN edge int

ISR-G2(config-pmap-c)#interface GigabitEthernet0/2

ISR-G2(config-if)# service-policy output CE-EDGE-SHAPING

! Attaches the HQoS shaper to the CE-edge interface

管理员可以通过下列命令来验证例32-3中的配置。

■ show class-map

■ show policy-map

■ show policy-map interface

2.将8类企业模型映射为一个6-CoS的服务提供商模型

在这个八对六的映射模型中，有两个企业应用类需要与另外两个类进行合并。

在这个案例中，网络控制类（Network Control）和信令类（Signaling）会被合并到一个服务提供商服务类型中；因为这两种应用类型都是为控制层协议服务的，而且这两类流量也可以相互适应。在这个服务提供商模型中（如图32-3所示），网络控制类流量和信令类流量分别需要被重标记为AF11和CS1。注意，仅仅将一个应用重标记为一个较低的代码点，这样做本身并不会降低这类流量的服务质量；这只是将流量放入相应的服务提供商CoS中的需求。

图32-3 将8类企业模型映射为一个6类的服务提供商模型

另一个需要进行合并的服务类别是清道夫类与尽力而为类，这两种类都需要合并到服务提供商的默认类中。因为清道夫类的全部意义就在于当流量出现拥塞时，对这一类流量进行节流，而通过一个阻塞点（CE边界）往往就足以达到这种效果。为了实现这种映射，需要将清道夫类的流量重标记为DF。

另外，将实时视频流量划分到一个非优先（nonpriority）的服务提供商CoS中，有可能是一种相当高效的做法，这一点本书已经在前面的章节提到过了。不过，即使实时视频流量会在PE出站接口通过非实时服务（如CBWFQ）的方式来进行处理，也没理由不在CE出站接口用严格优先级来为这类流量提供服务。具体做法如本例所示。

图32-3显示了如何将一个8类企业模型映射为一个6类的服务提供商模型。

例32-4所示为图32-3所对应的CE路由器配置。为了进一步完善这个案例，我们将这个队列策略映射到了例32-2中的分层（亚线路速率）整形策略中。

例32-4 将Cisco ISR G2（CE路由器）8类企业模型映射为1个6类服务提供商模型的配置案例

! The class maps for this policy are identical to the

! eight-class egress queuing model in Example 28-8

! and therefore will not be repeated here for the sake of brevity

! This section defines an eight-class enterprise to

! Six-class service provider queuing policy map

ISR-G2(config-cmap)# policy-map EIGHT-CLASS-ENT-TO-SIX-CLASS-SP

ISR-G2(config-pmap)# class VOICE

ISR-G2(config-pmap-c)# priority percent 10

! Provisions the VOICE class with 10% LLQ

ISR-G2(config-pmap-c)# class MULTIMEDIA-CONFERENCING

ISR-G2(config-pmap-c)# priority percent 20

! Provisions the MULTIMEDIA-CONFERENCING class with 20% LLQ

ISR-G2(config-pmap-c)# class MULTIMEDIA-STREAMING

ISR-G2(config-pmap-c)# bandwidth percent 10

! Provisions the MULTIMEDIA-STREAMING class with 10% CBWFQ

ISR-G2(config-pmap-c)# fair-queue

! Enables a fair-queuing pre-sorter

ISR-G2(config-pmap-c)# random-detect dscp-based

! Enables DSCP-based WRED

ISR-G2(config-pmap-c)# class TRANSACTIONAL-DATA

ISR-G2(config-pmap-c)# bandwidth percent 25

! Provisions the TRANSACTIONAL-DATA class with 25% CBWFQ

ISR-G2(config-pmap-c)# fair-queue

! Enables a fair-queuing pre-sorter

ISR-G2(config-pmap-c)# random-detect dscp-based

! Enables DSCP-based WRED

ISR-G2(config-pmap-c)# class NETWORK-CONTROL

ISR-G2(config-pmap-c)# bandwidth percent 5

! Provisions the NETWORK-CONTROL class with 5% CBWFQ

ISR-G2(config-pmap-c)# set dscp af11

! Remarks NETWORK-CONTROL to AF11 to map into SP Model

ISR-G2(config-pmap-c)# class SIGNALING

ISR-G2(config-pmap-c)# bandwidth percent 5

! Provisions the SIGNALING class with 5% CBWFQ

ISR-G2(config-pmap-c)# set dscp cs1

! Remarks SIGNALING to CS1 to map into SP Model

ISR-G2(config-pmap-c)# class SCAVENGER

ISR-G2(config-pmap-c)# bandwidth percent 1

! Constrains the SCAVENGER class to 1% CBWFQ

ISR-G2(config-pmap-c)# set dscp default

! Remarks SCAVENGER to DF to map into SP Model

ISR-G2(config-pmap-c)# class class-default

ISR-G2(config-pmap-c)# bandwidth percent 24

! Provisions the default/Best-Effort class with 24% CBWFQ

ISR-G2(config-pmap-c)# fair-queue

! Enables a fair-queuing pre-sorter

ISR-G2(config-pmap-c)# random-detect

! Enables WRED

! This section configures the hierarchical shaper

! with nested queuing policy

ISR-G2(config-pmap)# policy-map CE-EDGE-SHAPING

ISR-G2(config-pmap)# class class-default

ISR-G2(config-pmap-c)# shape average 40M 400K

ISR-G2(config-pmap-c)# service-policy EIGHT-CLASS-ENT-TO-SIX-CLASS-SP

! Provides backpressure on the IOS queuing subsystem for the

! EIGHT-CLASS-ENT-TO-SIX-CLASS-SP queuing policy to engage

! when the shaping limit is reached

! This section applies the sub-line-rate shaper to the VPN edge int

ISR-G2(config)#interface GigabitEthernet0/2

ISR-G2(config-if)# service-policy output CE-EDGE-SHAPING

! Attaches the HQoS shaper to the CE edge interface

注释:如前文所述，有些应用类型有可能会丢失它们原始的DSCP值（在本例中，网络控制类、信令类和清道夫类就会出现这种情况）。但（在有需要的时候）这些丢失的数值不难恢复，可以让接收CE路由器在VPN边界链路的入站方向上执行深度数据包监控。

管理员可以通过下列命令来验证例32-4中的配置。

■ show class-map

■ show policy-map

■ show policy-map interface

3.将12类企业模型映射为一个8-CoS的服务提供商模型

在这个十二对八的映射模型中，有2组（每组3个）企业应用类型会被合并到服务提供商模型的两个服务类别中。

首先，广播视频类、实时交互类、多媒体会议类应用类会被合并到一个单独的（非实时）服务提供商的CoS中。所有这3个应用都是基于RTP/UDP的应用，因此将它们结合起来可以提高效率。将这些类结合在一起的主要原因，是因为这样可以减少昂贵的实时服务提供商带宽，而这又是必要的投资。同时将广播视频类、实时交互视频流量与语音流量都放入SP实时类别中。语音流量、广播视频流量和实时交互流量都可以在CE边界的LLQ中进行服务。在本例中，为了实现这种映射关系，需要将广播视频类流量重标记为CS4。

第二，网络控制类、信令类和OAM应用类需要被合并到一个服务提供商的CoS中。因为这些应用主要都是控制层协议，因此它们可以比较好地和平共处。在本例中，为了实现这种映射关系，信令类和OAM类都需要被重标记为CS6。

图32-4显示了如何将一个12类企业模型映射为一个8类的服务提供商模型。

图32-4 将12类企业模型映射为一个8类的服务提供商模型

例32-5所示为图32-4所对应的CE路由器配置。为了进一步完善这个案例，需要将这个队列策略直接应用到一个与MPLS VPN SP 相连的全线速（1 Gbit/s）GE 接口上。

注释:本例中使用的平台是ASR1000，因此它可以以线速GE速率执行流量处理。

例32-5 将Cisco ISR G2（CE路由器）12类企业模型映射为1个8-CoS服务提供商模型的配置案例

! The class maps for this policy are identical to the

! 12-class egress queuing model in example 28-9

! and therefore will not be repeated here for the sake of brevity

! This section defines a 12-class enterprise to

! 8-class service provider queuing policy map

ASR-1000(config-cmap)# policy-map TWELVE-CLASS-ENT-TO-EIGHT-CLASS-SP

ASR-1000(config-pmap)# class VOICE

ASR-1000(config-pmap-c)# priority percent 10

! Provisions the VOICE class with 10% LLQ

ASR-1000(config-pmap-c)# class BROADCAST-VIDEO

ASR-1000(config-pmap-c)# priority percent 10

! Provisions the BROADCAST-VIDEO class with 10% LLQ

ASR-1000(config-pmap-c)# set dscp cs4

! Remarks BROADCAST-VIDEO to CS4 to map into SP Model

ASR-1000(config-pmap-c)# class REALTIME-INTERACTIVE

ASR-1000(config-pmap-c)# priority percent 10

! Provisions the REALTIME-INTERACTIVE class with 10% LLQ

ASR-1000(config-pmap-c)# class NETWORK-CONTROL

ASR-1000(config-pmap-c)# bandwidth percent 3

! Provisions the NETWORK-CONTROL class with 3% CBWFQ

ASR-1000(config-pmap-c)# class SIGNALING

ASR-1000(config-pmap-c)# bandwidth percent 3

! Provisions the SIGNALING class with 3% CBWFQ

ASR-1000(config-pmap-c)# set dscp cs6

! Remarks SIGNALING to CS6 to map into SP Model

ASR-1000(config-pmap-c)# class NETWORK-MANAGEMENT

ASR-1000(config-pmap-c)# bandwidth percent 4

! Provisions the NETWORK-MANAGEMENT class with 4% CBWFQ

ASR-1000(config-pmap-c)# set dscp cs6

! Remarks NETWORK-MANAGEMENT to CS6 to map into SP Model

ASR-1000(config-pmap-c)# class MULTIMEDIA-CONFERENCING

ASR-1000(config-pmap-c)# bandwidth percent 10

! Provisions the MULTIMEDIA-CONFERENCING class with 10% CBWFQ

ASR-1000(config-pmap-c)# fair-queue

! Enables a fair-queuing pre-sorter

ASR-1000(config-pmap-c)# queue-limit 400

! Sets the maximum queue depth to 400 packets

ASR-1000(config-pmap-c)# random-detect dscp-based

! Enables DSCP-based WRED

ASR-1000(config-pmap-c)# random-detect dscp af41 320 400

! Tunes minimum DSCP-WRED threshold for AF41 to 80% queue-depth

ASR-1000(config-pmap-c)# random-detect dscp af42 280 400

! Tunes minimum DSCP-WRED threshold for AF42 to 70% queue-depth

ASR-1000(config-pmap-c)# random-detect dscp af43 240 400

! Tunes minimum DSCP-WRED threshold for AF43 to 60% queue-depth

ASR-1000(config-pmap-c)# class MULTIMEDIA-STREAMING

ASR-1000(config-pmap-c)# bandwidth percent 10

! Provisions the MULTIMEDIA-STREAMING class with 10% CBWFQ

ASR-1000(config-pmap-c)# fair-queue

! Enables a fair-queuing pre-sorter

ASR-1000(config-pmap-c)# queue-limit 400

! Sets the maximum queue depth to 400 packets

ASR-1000(config-pmap-c)# random-detect dscp-based

! Enables DSCP-based WRED

ASR-1000(config-pmap-c)# random-detect dscp af31 320 400

! Tunes minimum DSCP-WRED threshold for AF31 to 80% queue-depth

ASR-1000(config-pmap-c)# random-detect dscp af32 280 400

! Tunes minimum DSCP-WRED threshold for AF32 to 70% queue-depth

ASR-1000(config-pmap-c)# random-detect dscp af33 240 400

! Tunes minimum DSCP-WRED threshold for AF33 to 60% queue-depth

ASR-1000(config-pmap-c)# class TRANSACTIONAL-DATA

ASR-1000(config-pmap-c)# bandwidth percent 10

! Provisions the TRANSACTIONAL-DATA class with 10% CBWFQ

ASR-1000(config-pmap-c)# fair-queue

! Enables a fair-queuing pre-sorter

ASR-1000(config-pmap-c)# queue-limit 400

! Sets the maximum queue depth to 400 packets

ASR-1000(config-pmap-c)# random-detect dscp-based

! Enables DSCP-based WRED

ASR-1000(config-pmap-c)# random-detect dscp af21 320 400

! Tunes minimum DSCP-WRED threshold for AF21 to 80% queue-depth

ASR-1000(config-pmap-c)# random-detect dscp af22 280 400

! Tunes minimum DSCP-WRED threshold for AF22 to 70% queue-depth

ASR-1000(config-pmap-c)# random-detect dscp af23 240 400

! Tunes minimum DSCP-WRED threshold for AF23 to 60% queue-depth

ASR-1000(config-pmap-c)# class BULK-DATA

ASR-1000(config-pmap-c)# bandwidth percent 5

! Provisions the BULK-DATA class with 5% CBWFQ

ASR-1000(config-pmap-c)# fair-queue

! Enables a fair-queuing pre-sorter

ASR-1000(config-pmap-c)# queue-limit 200

! Sets the maximum queue depth to 200 packets

ASR-1000(config-pmap-c)# random-detect dscp-based

! Enables DSCP-based WRED

ASR-1000(config-pmap-c)# random-detect dscp af11 160 200

! Tunes minimum DSCP-WRED threshold for AF11 to 80% queue-depth

ASR-1000(config-pmap-c)# random-detect dscp af12 140 200

! Tunes minimum DSCP-WRED threshold for AF12 to 70% queue-depth

ASR-1000(config-pmap-c)# random-detect dscp af13 120 200

! Tunes minimum DSCP-WRED threshold for AF13 to 60% queue-depth

ASR-1000(config-pmap-c)# class SCAVENGER

ASR-1000(config-pmap-c)# bandwidth percent 1

! Constrains the SCAVENGER class to 1% CBWFQ

ASR-1000(config-pmap-c)# class class-default

ASR-1000(config-pmap-c)# bandwidth percent 24

! Provisions the default/Best-Effort class with 24% CBWFQ

ASR-1000(config-pmap-c)# fair-queue

! Enables a fair-queuing pre-sorter

ASR-1000(config-pmap-c)# queue-limit 1000

! Sets the maximum queue depth to 1000 packets

ASR-1000(config-pmap-c)# random-detect dscp-based

! Enables DSCP-based WRED

(config-pmap-c)# random-detect dscp default 800 1000

! Tunes minimum DSCP-WRED threshold for DF to 80% queue-depth

! This section binds the queuing policy directly to the

! GE interface (connecting to the SP at full 1000-Mbps line rate)

ASR-1000(config)# interface GigabitEthernet 0/0/2

ASR-1000(config-if)# service-policy output TWELVE-CLASS-ENT-TO-EIGHT-CLASS-SP

注释:例32-5中的队列限制和WRED门限值，都按照ASR1000吉比特以太网接口的需求进行了调整。

管理员可以通过下列命令来验证例32-5中的配置。

■ show class-map

■ show policy-map

■ show policy-map interface

32.4 小结

本章概述了企业CE 路由器在QoS 策略中扮演的角色，而Cisco ASR 1000 和ISR G2 系列路由器都适合充当这样的角色。

入站方向的QoS设计方案已经无需赘述，因为它的设计方案与LAN边界深度数据包监控策略是相同的，而这种设计方案已经在分支路由器设计的篇章中已经进行了介绍。不过有一点必须说明，那就是这些策略同样可以有效地部署在VPN入站边界的位置，以恢复可能已在传输过程中丢失，或在企业-服务提供商映射过程中丢失的DSCP标记。

接下来对出站方向的QoS设计方案进行了探讨。首先，本章介绍了用于亚线路速以太网接入方案的分层整形策略（其中包含套嵌的队列）。本章在这里分两种情况进行了讨论，一种是服务提供商入站限速器的承诺突发量是被已知的（在这种情况下，CE整形器的承诺突发值应该设置为服务提供商入站限速器承诺突发量的一半以下），第二种情形是服务供应商的BC是未知的，在这种情况下，可以将CE 整形器设置为整形间隔10 ms 所对应的数值，这是官方推荐的最佳做法。

此后，本章对各种企业与服务提供商映射关系进行了详细的介绍，其中包括以下三种:

■ 将4类企业模型映射为一个4-CoS的服务供应商模型；

■ 将8类企业模型映射为一个6-CoS的服务供应商模型；

■ 将12类企业模型映射为一个8-CoS的服务供应商模型。

32.5 扩展阅读

Cisco IOS Release 15M&T—QoS Configuration Guide:（Cisco IOS 15M&T——QoS配置指南） http://www.cisco.com/en/US/docs/ios-xml/ios/qos/config_library/15-mt/qos-15-mt-library.html

第33章 服务供应商边界（Cisco ASR 9000）的QoS设计

服务提供商（SP）在PE（提供商边界）路由器上需要执行许多QoS（服务质量）的角色，其中包括:

■ 根据SP的CoS模型，在入站方向上通过CoS（服务类型）来限制流量；

■ 实现MPLS（多协议标签交换）差分服务（DiffServ）隧道模式的QoS策略；

■ 根据SP的CoS(服务类型)模型，通过MPLS EXP对去往MPLS VPN（虚拟专用网络）核心的流量执行队列算法；

■ 根据SP的CoS模型和MPLS差分服务隧道模型，对发往客户边界路由器的流量执行队列算法；

■ 按照协定的亚线路服务速率，对发往CE（客户边界）路由器的流量进行整形（并在整形速率的范畴之内，采取分层的队列与丢弃机制）。

图33-1 展示了SP PE 路由器中的一些接口，所扮演的QoS 角色。

Cisco ASR 9000 系列路由器非常适合充当SP PE 路由器，因此，这个系列的设备将在本章中着重进行介绍。首先，我们需要对这个平台的QoS架构进行概述。

图33-1 服务提供商PE路由器接口的QoS角色

33.1 QoS的体系结构

Cisco聚合服务路由器（ASR）9000系列路由器是一种分布式的、冗余的、模块化的平台，这种平台上采用了新一代的硬件和IOS XR 软件。

在硬件方面，ASR9000系统主要由以下几部分组成。

■ 路由交换处理器（RSP）:通常有冗余，负责执行控制平面和管理的功能。

■ 网络处理器（NPS）:是数据平面主要的转发集成电路（ASIC），负责提供第2层和第3层的转发（包括QoS）功能。网络处理器往往存在于多个线路卡中。

■ 矩阵接口ASIC（FIA）:负责在线路卡到交换机矩阵（switch fabric）之间提供无阻的数据连接，并管理内部系统的VoQ（虚拟输出队列）。

■ 可插拔物理接口（PHY）:包括吉比特以太网（GE）、10GE、40GE和100GE（以及WAN接口）。

图33-2 以一个24×10GE 线路卡为例，展示了ASR 9000 架构下这些主要硬组件之间的相互关系。

图33-2 Cisco ASR 9000的硬件价格（以A9K-24×10GE线路卡为例）

有一点毋须注意，那就是ASR9000硬件架构是完全无阻的，也就是在系统内不存在瓶颈。

以图33-2为例（配有一块24×10GE线卡）。这个线路卡中的所有10GE接口都被划分为了三个一组（每组最大的吞吐量为30 Gbit/s），其中每组都分配有一个专用的网络处理器，而每个NP 可以提供双向60 Gbit/s 的吞吐量。接下来，每两个NP 被都有一个专用的FIA，每个FIA 可以支持60 Gbit/s 的双向吞吐量。最后，每个FIA 都分配有一对矩阵通道链路（每条链路支持55 Gbit/s 的双向吞吐量），将FIA 连接到交换矩阵和RSP。因此，输入流量共计可以达到240 Gbit/s（24×10GE），而ASR 9000 架构可以提供275 Gbit/s（8×55 Gbit/s）的交换矩阵访问量，这个系统在任何时候都不会出现瓶颈。因此，没有必要通过入向队列技术来防止流量在到达交换矩阵之前即遭被丢弃。

也就是说，不管内部架构如何设计，网络中的路由器都可以按照这种方式进行配置，以汇聚流量（毕竟ASR 9000的作用就是充当ASR），并有可能超额占用连接SP核心的上行链路。在这种情况下，ASR 9000 系列设备就能够将输入输出队列同VOQ 结合起来使用，既有效又准确地解决网络拥塞的问题，如图33-3所示。

图33-3 ASR 9000的队列子系统

图33-3中所示的4个队列子系统如下。

■ 入站接口队列:这类队列策略需要通过MQC（模块化QoS命令行界面）来进行配置，然后再使用命令service-policy input 命令将其应用到一个接口/ 子接口上。这类队列机制除了三个隐式的优先级水平之外，还支持另外四个层次，这一点将在下一点（VOQ）中进行讨论。

■ 虚拟输出队列（VOQ）:这种队列策略被隐式配置在了MQC入站或出站队列策略中，它的特点是有三个优先级别，即优先级1、优先级2和正常（尽力而为）级。每个虚拟端口都支持4个VOQ队列，每个FIA支持高达4000个VOQ队列。由于这些节点不会出现实际的拥堵，所以才被称为虚拟输出队列，但是出站FIA向交换矩阵处理器（在RSP中）发送信号时会出现拥塞，而这则会迫使入站FIA开始在VOQ队列中缓冲数据包。

■ 出站FIA队列:这些队列的操作方式与VOQ的操作方式相同，因为这两种队列都支持同样三个隐式的层级。然而，这类队列却并不叫做虚拟队列，反而常常被人称为真实队列，因为这些队列常常会反映出NP的实际拥塞情况（而虚拟的拥塞事件则是由RSP交换机处理器发送给入站FIA的）。每个虚拟端口都支持4个出站FIA队列。

■ 出站接口队列:这类队列策略需要通过MQC来进行配置，然后再使用命令service-policy output 命令将其应用到一个接口/ 子接口上。这类队列机制除了三个隐式的优先级水平之外，还支持另外四个层次。

要想了解这些队列子系统之间的关系，最好利用一下逆向思维的方式。如果出站接口遭遇拥塞，出站方向的NP就会开始在出站接口中队列缓冲数据包。然后，它会告诉FIA出现了拥塞的情况，于是，出站FIA队列也会开始缓冲数据包。而后，出站FIA会向（活动的）RSP发出拥塞的信号。而RSP包含了限制流量访问交换矩阵的仲裁器。因此，仲裁器就会拒绝入站FIA访问交换矩阵，这样一来，系统就创建出了一次拥堵事件。于是，入站FIA就会开始在VOQ队列中缓冲数据包。而入站FIA无法访问交换矩阵最终会使得入站NP执行入站接口的队列策略。

对于这个三级的内部系统队列，优先级为1的数据包一定比优先级为2的数据包先接受服务。当优先级为1的数据包到达设备时，优先级为2的数据包有可能会遭遇服务中断的情况。只有当这两个优先级队列中的数据包都完全获得服务后，设备才会为常规流量提供服务，而且每当有优先级为1或2的数据包到达设备时，常规流量的服务就有可能终端。

在ASR 9000 上，这三个系统优先级可以在入向/ 出向MQC 策略中通过命令priority level（或缺省）进行配置。默认情况下，如果管理员没有明确指定级别，系统会默认优先级为1。例33-1展示了三级队列策略的配置方法，该策略可以应用到入接口或出接口上，也可以隐含地控制VOQ队列和出站FIA队列。

例33-1 Cisco ASR 9000上的三级接口与VOQ/出站 FIA队列策略

RP/0/RSP0/CPU0:ASR9K(config-cmap)# policy-map THREE-LEVEL-QUEUING

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class PRIORITY-LEVEL-1

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# priority level 1

! Configures class to be serviced with priority level 1

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class PRIORITY-LEVEL-2

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# priority level 2

! Configures class to be serviced with priority level 2

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class class-default

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 65

! All CBWFQ classes will be serviced with priority-level normal

下列命令可以验证例33-1中的配置。

■ show policy-map interface

■ show controllers fabric crossbar statistics

■ show controllers fabric fia stats

■ show controllers fabric fia drops [ ingress | egress ]

在ASR 9000 硬件平台上，还有最后一点与QoS 有关的内容需要特别说明:三类不同的QoS支持多种线卡，这与所支持的内存和QoS队列和限速的扩展功能有关。可供选择的内存包括以下几种类型。

■ Extended（E）:拥有最高的QoS扩展能力。

■ Base（B）:支持中等的QoS拓展能力。

■ Low（L）:支持最低的QoS拓展能力。

所有线卡的硬件QoS特性和配置语法都是一样的；但这些线卡支持的队列数量和策略数量却因所选线路卡的E/B/L类型而有所不同。鉴于具体细节会因线卡而不同，因此在有需要时，最好阅读各个线卡的数据表。

33.2 QoS的设计步骤

要配置一台充当SP PE 路由器的Cisco ASR 9000，通常包括以下4 步。

1.在PE到CE的接口上配置入站策略。

2.在PE 到CE 的接口上配置出站队列（如有需要，也可配置分层整形）。

3.在入站方向上，配置MPLS EXP 到QoS 组的映射（统一模式[Uniform Mode] 或管道模式[Pipe Mode]）。

4.在PE 到P 接口的出站方向上配置基于MPLS EXP 的队列。

注释:在配置内部QoS和VoQ时，没有任何必要的配置策略，因为这些策略在接口QoS策略中会通过priority和bandwidth remaining语句自动设置。

这些步骤和相应的策略通常会因正在使用的MPLS DiffServ（MPLS 差分服务）隧道模式的不同而变化，因此，需要进行相应的分组。此外，为了更好地说明设计方案，本章会使用（前面章节中介绍的）4类、6类和8类的SP模型。因此，本章着重介绍的策略组合包括以下几种:

■ 统一模式（Uniform Mode）的4 类SP 模型；

■ 管道模式（Pipe Mode）的6 类SP 模型；

■ 短管道模式（Short Pipe Mode）的8 类SP 模型。

33.3 MPLS 差分服务的隧道模型

在第31章中，我们曾经介绍过，有三种不同的MPLS 差分服务隧道模式。

■ 统一模式:数据包可以在第2层或第3层进行重标记，因为这种模式假定服务提供商和客户端共享了同一个差分服务域。

■ 管道模式:数据包只能在第2层进行重标记，而最后的出站队列策略将根据提供商的2层标记来执行。

■ 短管道模式:数据包只能在第2层进行重标记，而最后的出站队列策略将根据客户的3层标记来执行。

在下文的配置案例中，这几种MPLS差分服务隧道模式都会进行介绍。

33.3.1 统一模式的MPLS 差分服务隧道

统一模式的MPLS 差分服务隧道需要进行如下配置:

■ 在PE-CE边界配置入向限速；

■ 在PE-P 边界配置基于MPLS EXP 的出站队列；

■ 在PE-P 边界配置入向的MPLS EXP 到QoS 组的映射；

■ 在PE-CE边界配置基于QoS组的出站队列。

注释:按照上述顺序介绍这些策略是有原因的，因为这就是数据包通过MPLS VPN时的逻辑操作顺序。

在这个统一模式的例子中，我们使用了前面章节中介绍过的（见图32-2）4类SP模型。图33-4显示了这个4类SP模型的其他一些具体信息。

注释:如图33-4所示，DSCP值被映射到了MPLS EXP位，而MPLS EXP（有时）又要被映射为QoS组（QG）值。QG是需要通过QoS进行处理的数据包，所关联的一个内部标记值。QG可以充当内部标记占位符，让MPLS EXP能够在MPLS标签弹出或丢弃前进行复制，以此将这些EXP值保留下来。有关QG的详细信息将在本章的后续内容进行讨论。为了简单起见，同时也为了保持策略的一致性，我们在这些例子中将QG值统统设置为与MPLS EXP相匹配的数值（如，将MPLS EXP5映射为QG5，将MPLS EXP3映射为QG3，依此类推）。

图33-4 统一模式4类SP模型

1.统一模式的入站限速器

在这个模型中的第一个策略是将客户流量限制在协定速率之内。符合这个限制的流量会被打上MPLS标签（其中EXP位与流量类别的DSCP值头3位数值相匹配），然后传输出去。过量的SP-REALTIME 流量则会被丢弃，但过量的非实时流量则会被重标记为MPLS EXP 0。在默认类别（尽力而为传输类）中，符合限制的流量和过量的流量都会被打上一个EXP值为0的标签；从QoS策略的角度来看，这样做似乎意义不大，但部署这个限速器的真正目的通过测量过量流量，对超出限制的流量进行审计和计费。

例33-2显示了这个4类统一模式策略第一部分的配置。

例33-2 Cisco ASR 9000统一模式MPLS差分隧道:第一部分:入站限速器

! This section configures the class maps for the ingress policer

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-any SP-REALTIME

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp cs5

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp ef

! SP-REALTIME class is matched on DSCP CS5 or EF

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-any SP-AF3-CLASS

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp cs3

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp af31

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp af32

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp af33

! SP-AF3-CLASS is matched on DSCP CS3 or AF3

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-any SP-AF2-CLASS

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp cs2

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp af21

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp af22

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp af23

! SP-AF2-CLASS is matched on DSCP CS2 or AF2

! This section configures the Uniform-Mode four-class ingress policer

RP/0/RSP0/CPU0:ASR9K(config-cmap)# policy-map SP-FOUR-CLASS-INGRESS-MODEL-UNIFORM

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-REALTIME

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# police rate percent 30

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# conform-action set mpls experimental imposition 5

! Conforming SP-REALTIME traffic (EF/CS5) is sent with MPLS EXP 5

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# exceed-action drop

! Excess SP-REALTIME traffic is dropped

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class SP-AF3-CLASS

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# police rate percent 10

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# conform-action set mpls experimental imposition 3

! Conforming SP-AF3-CLASS (CS3/AF3) is sent with MPLS EXP 3

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# exceed-action set mpls experimental imposition 0

! Exceeding SP-AF3-CLASS is sent with MPLS EXP 0

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class SP-AF2-CLASS

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# police rate percent 35

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# conform-action set mpls experimental imposition 2

! Conforming SP-AF2-CLASS (CS2/AF2) is sent with MPLS EXP 2

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# exceed-action set mpls experimental imposition 0

! Exceeding SP-AF2-CLASS is sent with MPLS EXP 0

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class class-default

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# police rate percent 25

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# conform-action set mpls experimental imposition 0

! Conforming SP-BE-CLASS (DF) is sent with MPLS EXP 0

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# exceed-action set mpls experimental imposition 0

! Exceeding SP-BE-CLASS (DF) is sent with MPLS EXP 0

! This section attaches the ingress policer to the PE-to-CE interface

RP/0/RSP0/CPU0:ASR9K(config)# interface GigabitEthernet 0/2/0/0

RP/0/RSP0/CPU0:ASR9K(config-if)# service-policy input SP-FOUR-CLASS-INGRESS-MODEL-UNIFORM

注释:IOS XR需要管理员激活class map和service policy的配置（推出配置模式可以激活，在配置完每个class map和policy map之后输入end也可以激活）。为了简化配置案例，这部分配置不会在下文中显示出来。

可以用下列命令验证例33-2中的配置。

■ show class-map reference list （见例33-3）

■ show policy-map pmap name （见例33-4）

■ show policy-map interface （见例33-5）

■ show qos interface interface w/x/y/z input （见例33-6）

例33-3 显示了管理员配置的class map，以及调用这些class map 的policy map。

例33-3 查看class map:show class-map reference list

RP/0/RSP0/CPU0:ASR9K# show class-map reference list

Thu Feb 14 11:33:45.978 PST

1) ClassMap:SP-AF3-CLASS　Type:qos

Referenced by 1 Policymaps

PolicyMapName:SP-FOUR-CLASS-INGRESS-MODEL-UNIFORM Type:qos

2) ClassMap:SP-REALTIME　Type:qos

Referenced by 1 Policymaps

PolicyMapName:SP-FOUR-CLASS-INGRESS-MODEL-UNIFORM　Type:qos

3) ClassMap:SP-AF2-CLASS　Type:qos

Referenced by 1 Policymaps

PolicyMapName:SP-FOUR-CLASS-INGRESS-MODEL-UNIFORM　Type:qos

RP/0/RSP0/CPU0:ASR9K#

例33-4 显示了policy map 的名称及配置的内容。

例33-4 查看policy map:show policy-map pmap name

RP/0/RSP0/CPU0:ASR9K# show policy-map pmap-name SP-FOUR-CLASS-INGRESS-MODEL-UNIFORM

Thu Feb 14 11:31:25.433 PST

policy-map SP-FOUR-CLASS-INGRESS-MODEL-UNIFORM

class SP-REALTIME

police rate percent 30

conform-action set mpls experimental imposition 5

exceed-action drop

!

!

class SP-AF3-CLASS

police rate percent 10

conform-action set mpls experimental imposition 3

exceed-action set mpls experimental imposition 0

!

!

class SP-AF2-CLASS

police rate percent 35

conform-action set mpls experimental imposition 2

exceed-action set mpls experimental imposition 0

!

!

class class-default

police rate percent 25

conform-action set mpls experimental imposition 0

exceed-action set mpls experimental imposition 0

!

!

end-policy-map

!

RP/0/RSP0/CPU0:ASR9K#

例33-5 显示了应用到GE 接口上的service policy，以及各个类别的计数器信息。根据显示的信息可以看出，数据包的速率被限制在了协定速率的范围之内，设备对默认类别中过量的6148的数据包进行了报告。

例33-5 查看Service Policy:show policy-map interface

RP/0/RSP0/CPU0:ASR9K# show policy-map interface GigE 0/2/0/0

Thu Feb 14 11:27:11.255 PST

GigE0/2/0/0 input:SP-FOUR-CLASS-INGRESS-MODEL-UNIFORM

Class SP-REALTIME

Classification statistics　　　(packets/bytes)　(rate - kbps)

Matched　　　:　　　1355287/174832056　　　82305

Transmitted　　:N/A

Total Dropped　　:　　　　　0/0　　　　　0

Policing statistics　　　　(packets/bytes)　(rate - kbps)

Policed(conform)　:　　　1355287/174832056　　　83205

Policed(exceed)　:　　　　　0/0　　　　　0

Policed(violate)　:　　　　　0/0　　　　　0

Policed and dropped:　　　　　0/0

Class SP-AF3-CLASS

Classification statistics　　　(packets/bytes)　(rate - kbps)

Matched　　　:　　　91711668/2356990176　　　6532

Transmitted　　:N/A

Total Dropped　　:　　　　　0/0　　　　　0

Policing statistics　　　　(packets/bytes)　(rate - kbps)

Policed(conform)　:　　　91711668/2356990176　　　6532

Policed(exceed)　:　　　　　0/0　　　　　0

Policed(violate)　:　　　　　0/0　　　　　0

Policed and dropped:　　　　　0/0

Class SP-AF2-CLASS

Classification statistics　　　(packets/bytes)　(rate - kbps)

Matched　　　:　　　782028416/1091711668736　146177

Transmitted　　:N/A

Total Dropped　　:　　　　　0/0　　　　　0

Policing statistics　　　　(packets/bytes)　(rate - kbps)

Policed(conform)　:　　　782028416/1091711668736　146177

Policed(exceed)　:　　　　　0/0　　　　　0

Policed(violate)　:　　　　　0/0　　　　　0

Policed and dropped:　　　　　0/0

Class class-default

Classification statistics　　　(packets/bytes)　(rate - kbps)

Matched　　　:　　　1594194/102028416　　　0

Transmitted　　:N/A

Total Dropped　　:　　　　　0/0　　　　　0

Policing statistics　　　　(packets/bytes)　(rate - kbps)

Policed(conform)　:　　　2541454509/3802015946　　253413

Policed(exceed)　:　　　　6148/7912476　　　　0

Policed(violate)　:　　　　　0/0　　　　　0

Policed and dropped:　　　　　0/0

GigE0/2/0/0 direction output:Service Policy not installed

RP/0/RSP0/CPU0:ASR9K#

例33-6显示了接口deQoS配置，其中包括限速器的详细信息。

例33-6 查看接口的QoS信息:show qos interface

RP/0/RSP0/CPU0:ASR9K# show qos interface GigE 0/2/0/0 input

Thu Feb 14 13:03:46.088 PST

Interface:GigE0_2_0_0 input

Bandwidth configured:1000000 kbps Bandwidth programmed:1000000 kbps

ANCP user configured:0 kbps ANCP programed in HW:0 kbps

Port Shaper programed in HW:0 kbps

Policy:SP-FOUR-CLASS-INGRESS-MODEL-UNIFORM Total number of classes:4

----------------------------------------------------------------------

Level:0 Policy:SP-FOUR-CLASS-INGRESS-MODEL-UNIFORM Class:SP-REALTIME

QueueID:131074 (Port Default)

Policer Profile:48 (Single)

Conform:3000000 kbps (30 percent) Burst:37500000 bytes (0 Default)

Child Policer Conform:set exp-imp 5

Child Policer Exceed:DROP

Child Policer Violate:DROP

----------------------------------------------------------------------

Level:0 Policy:SP-FOUR-CLASS-INGRESS-MODEL-UNIFORM Class:SP-AF3-CLASS

QueueID:131074 (Port Default)

Policer Profile:49 (Single)

Conform:1000000 kbps (10 percent) Burst:12500000 bytes (0 Default)

Child Policer Conform:set exp-imp 3

Child Policer Exceed:set exp-imp 0

----------------------------------------------------------------------

Level:0 Policy:SP-FOUR-CLASS-INGRESS-MODEL-UNIFORM Class:SP-AF2-CLASS

QueueID:131074 (Port Default)

Policer Profile:50 (Single)

Conform:3500000 kbps (35 percent) Burst:43750000 bytes (0 Default)

Child Policer Conform:set exp-imp 2

Child Policer Exceed:set exp-imp 0

----------------------------------------------------------------------

Level:0 Policy:SP-FOUR-CLASS-INGRESS-MODEL-UNIFORM Class:class-default

QueueID:131074 (Port Default)

Policer Profile:51 (Single)

Conform:2500000 kbps (25 percent) Burst:31250000 bytes (0 Default)

Child Policer Conform:set exp-imp 0

Child Policer Exceed:set exp-imp 0

----------------------------------------------------------------------

RP/0/RSP0/CPU0:ASR9K#

2.（基于MPLS EXP的）统一模式出站队列策略

接下来，数据包会在PE 到P 接口上，命中基于MPLS EXP 的出站队列策略，如例33-7所示。

例33-7 Cisco ASR 9000统一模式MPLS差分隧道:第二部分:（基于MPLS EXP的）4类出站队列策略

! This section configures the class maps for the four-class

! MPLS EXP-based egress queuing policy

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-all SP-REALTIME-EXP

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match mpls experimental topmost 5

! The SP-REALTIME-EXP class is matched by MPLS EXP 5

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-all SP-AF3-CLASS-EXP

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match mpls experimental topmost 3

! The SP-AF3-CLASS-EXP class is matched by MPLS EXP 3

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-all SP-AF2-CLASS-EXP

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match mpls experimental topmost 2

! The SP-AF2-CLASS-EXP class is matched by MPLS EXP 2

! This section configures the four-class EXP-based queuing policy map

RP/0/RSP0/CPU0:ASR9K(config-pmap)# policy-map SP-FOUR-CLASS-EXP-QUEUING

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-REALTIME-EXP

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# priority

! SP-REALTIME-EXP will operate at priority level 1 (default)

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class SP-AF3-CLASS-EXP

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 15

! SP-AF3-CLASS-EXP will receive CBWFQ with 15% bandwidth remaining

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class SP-AF2-CLASS-EXP

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 50

! SP-AF2-CLASS-EXP will receive CBWFQ with 50% bandwidth remaining

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class class-default

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 35

! The default class will receive CBWFQ with 35% bandwidth remaining

! This section applies the service policy to the PE-to-P interface

RP/0/RSP0/CPU0:ASR9K(config)# interface tenGigE 0/1/0/2

RP/0/RSP0/CPU0:ASR9K(config-if)# service-policy output SP-FOUR-CLASS-EXP-QUEUING

注释:为了简化起见，在前面的章节中，我们在bandwidth和bandwidth remaining语句中使用的都是相同的百分比。而在这些SP模型中，bandwidth remaining百分比都经过了计算，在SP网络的设计方案中，带宽的精度需求要高得多，因为SP在与客户的合同中对带宽有明确规定。因此，在这些模型中，我们假定SP-REALTIME类被分配了30%的带宽，而其他类型的流量则会竞争剩余70%的总带宽。例如， SP-AF3-CLASS被分配了（总带宽）10%的带宽，但在配置bandwidth remaining percent这条命令时，应该填的百分比是15。

注释:通过MPLS EXP标记来匹配SP CoS的Class map都加上了一个-EXP后缀，这是为了便于将它们与匹配DSCP值的class map区分开。

注释:基于MPLS EXP 的随机检测可以有选择地对某些类型的流量启用；不过，为了让这些（相对复杂的）策略尽可能简单，以便读者能够把注意力放在主要的策略上，这些示例中都没有使用基于MPLS EXP 的加权随机早期检测（WRED）。（与前文中反复提到过的，基于DSCP 的WRED 相比）基于MPLS EXP 的WRED 唯一的语法在于，需要在输入命令random-detect 时，需要加上关键字exp（如 random-detect exp value min-threshold [ units ] maxthreshold [ units ]）。

可以用下面的命令验证例33-7中的配置。

■ show class-map reference list

■ show policy-map pmap name

■ show policy-map interface

■ show qos interface interface w/x/y/z output

3.统一模式（MPLS EXP到QG）的入站映射策略

现在，当数据包进入MPLS VPN 的出站PE 时，它的最后一个标签马上也要弹出。因此，在数据包到达最终出站接口之前，它的MPLS EXP 值就会丢失。所以，在丢失之前，当数据包从核心进入PE 路由器时，它们的MPLS EXP 值必须复制到一个称为QoS 组（QG）的内部标签中。通过这种方式，最终出站（PE到CE）的队列策略，就可以按照这个QG值（也就等于间接按照最后的MPLS EXP 值）来执行了。

注释:匹配MPLS EXP的class map与PE到P的出站队列策略是相同的（该策略已经在上例中进行了介绍），而这些策略也可以用来执行入站方向的MPLS EXP映射策略，因此本例中不再赘述。

例33-8 显示了MPLS EXP 到QG 的入站映射策略。

例33-8 CiscoASR 9000统一模式MPLS差分隧道:第三部分:MPLS EXP到QG的入站映射

! This section configures the ingress MPLS EXP-to-QG mapping

RP/0/RSP0/CPU0:ASR9K(config)# policy-map SP-FOUR-CLASS-EXP-TO-QOS-GROUP

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-REALTIME-EXP

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# set qos-group 5

! MPLS EXP 5 is mapped to QoS group 5

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class SP-AF3-CLASS-EXP

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# set qos-group 3

! MPLS EXP 3 is mapped to QoS group 3

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class SP-AF2-CLASS-EXP

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# set qos-group 2

! MPLS EXP 2 is mapped to QoS group 2

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class class-default

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# set qos-group 0

! Everything else is mapped to QoS group 0

! This section applies the MPLS EXP-to-QG mapping

! to the PE-to-P interface in the ingress direction

RP/0/RSP0/CPU0:ASR9K(config)# interface tenGigE 0/1/0/2

RP/0/RSP0/CPU0:ASR9K(config-if)# service-policy input SP-FOUR-CLASS-EXP-TO-QOS-GROUP

可以用下面的命令验证例33-8中的配置。

■ show class-map reference list

■ show policy-map pmap name

■ show policy-map interface

■ show qos interface interface w/x/y/z output

4.统一模式（基于QG的）出站队列策略

在数据包离开MPLS VPN网络时，它将命中的最后一个策略是PE到CE的出站队列策略。此时，MPLS标签已被弹出，但是它们的值已经被复制到了QG中，因此队列策略可以按照这些QG值来执行。

要注意，在这个阶段，统一模式MPLS差分隧道会用2层EXP值（之前已经复制为了QG值）替代MPLS差分服务值，而这有可能会覆盖客户的DSCP标记。

配置统一模式MPLS 差分服务隧道策略的最后一个步骤，方法如例33-9 所示。

例33-9 Cisco ASR 9000统一模式MPLS差分隧道:第四部分:基于QG的出站队列策略

! This section configures the QG-based class maps

RP/0/RSP0/CPU0:ASR9K(config)# class-map match-all SP-REALTIME-QG

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match qos-group 5

! SP-REALTIME-QG traffic is matched against QoS group 5

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-all SP-AF3-CLASS-QG

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match qos-group 3

! SP-AF3-CLASS-QG traffic is matched against QoS group 3

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-all SP-AF2-CLASS-QG

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match qos-group 2

! SP-AF2-CLASS-QG traffic is matched against QoS group 2

! This section configures the Uniform Mode four-class QG-based

! egress queuing policy map

RP/0/RSP0/CPU0:ASR9K(config)# policy-map SP-FOUR-CLASS-QG-QUEUING-UNIFORM

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-REALTIME-QG

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# priority

! SP-REALTIME-QG receives priority level 1 service (by default)

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# set dscp cs5

! SP-REALTIME-QG class is re-marked to DSCP CS5 (from MPLS EXP 5)

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class SP-AF3-CLASS-QG

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 15

! SP-AF3-CLASS-QG receives 15% bandwidth remaining

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# set dscp cs3

! SP-AF3-CLASS-QG class is re-marked to DSCP CS3 (from MPLS EXP 3)

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class SP-AF2-CLASS-QG

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 50

! SP-AF2-CLASS-QG receives 50% bandwidth remaining

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# set dscp cs2

! SP-AF2-CLASS-QG class is re-marked to DSCP CS2 (from MPLS EXP 2)

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class class-default

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 35

! The default class receives 35% bandwidth remaining

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# set dscp default

! Default class traffic is re-marked to DSCP DF

! This section attaches the policy to the PE-to-CE interface

RP/0/RSP0/CPU0:ASR9K(config)# interface GigE 0/2/0/0

RP/0/RSP0/CPU0:ASR9K(config-if)# service-policy output SP-FOUR-CLASS-QG-QUEUING-UNIFORM

注释:通过QG值来匹配SP CoS的Class map都加上了一个-QG后缀，这是为了便于将它们与匹配DSCP值或MPLS EXP值的class map区分开。

可以用下面的命令验证例33-9中的配置。

■ show class-map reference list

■ show policy-map pmap name

■ show policy-map interface

■ show qos interface interface w/x/y/z output

33.3.2 管道模式的MPLS 差分服务隧道

管道模式的MPLS 差分服务隧道需要进行如下配置:

■ 在PE-CE边界配置入向限速；

■ 在PE-P 边界配置基于MPLS EXP 的出站队列；

■ 在PE-P 边界配置入向的MPLS EXP 到QoS 组的映射；

■ 在PE-CE边界配置基于QG的出站队列。

注释:按照上述顺序介绍这些策略是有原因的，因为这就是数据包通过MPLS VPN时的逻辑操作顺序。

统一模式与管道模式的一个重要区别在于，管道模式的第2层标记不必对应DSCP的前3位（因为这些值只在服务提供商网络中具有本地意义），当数据包离开VPN时，第2层标记也不会映射到DSCP之中。因此，从客户的角度来看，该服务是透明的（也就是说，无论数据包在进入MPLS VPN 时携带的DSCP 标记是什么，在它们离开MPLS VPN 时，这些标记都是相同的）。

在这个管道模式的例子中，我们使用了前面章节中介绍过的（见图32-3）6类SP模型。图33-5显示了这个6类SP模型的其他一些具体信息。

1.管道模式的入站限速器

在这个模型中的第一个策略是将客户流量限制在协定速率之内。符合这个限制的流量会被打上MPLS标签（其中EXP位未必与客户DSCP标记值的头3位相匹配），然后传输出去。这个模型中的MPLS EXP 标记只具有本地意义，因此完全可以依SP 的管理习惯而定。

在这个限速模型中，过量的SP-REALTIME流量会被丢弃。但过量的非实时流量则会被重标记为MPLS EXP 7（在这个示例中，这是提供商本地意义的数值，标识的就是过量的数据流）。在这个时间点之前，所有标记为MPLS EXP 7 的流量都会在默认类中接受服务。

图33-5 管道模式6类SP模型

例33-10显示了这个6类管道模式入站限速器的配置。

例33-10 Cisco ASR 9000管道模式MPLS差分隧道:第一部分:入站限速器

! This section configures the class maps for the ingress policer

RP/0/RSP0/CPU0:ASR9K(config)# class-map match-any SP-REALTIME

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp cs5

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp ef

! SP-REALTIME is matched on DSCP CS5 or EF

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-any SP-AF4-CLASS

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp cs4

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp af41

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp af42

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp af43

! SP-AF4-CLASS is matched on DSCP CS4 or AF4

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-any SP-AF3-CLASS

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp cs3

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp af31

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp af32

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp af33

! SP-AF3-CLASS is matched on DSCP CS3 or AF3

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-any SP-AF2-CLASS

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp cs2

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp af21

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp af22

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp af23

! SP-AF2-CLASS is matched on DSCP CS2 or AF2

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-any SP-AF1-CLASS

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp cs1

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp af11

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp af12

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp af13

! SP-AF1-CLASS is matched on DSCP CS1 or AF1

! This section configures the Pipe Mode six-class ingress policer

RP/0/RSP0/CPU0:ASR9K(config-cmap)# policy-map SP-SIX-CLASS-INGRESS-MODEL-PIPE

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-REALTIME

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# police rate percent 10

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# conform-action set mpls experimental imposition 5

! Conforming SP-REALTIME traffic (EF/CS5) is sent with MPLS EXP 5

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# exceed-action drop

! Exceeding SP-REALTIME traffic is dropped

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-AF4-CLASS

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# police rate percent 20

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# conform-action set mpls experimental imposition 4

! Conforming SP-AF4-CLASS traffic (CS4/AF4) is sent with MPLS EXP 4

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# exceed-action set mpls experimental imposition 7

! Exceeding SP-AF4-CLASS traffic is sent with MPLS EXP 7

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-AF3-CLASS

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# police rate percent 10

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# conform-action set mpls experimental imposition 3

! Conforming SP-AF3-CLASS traffic (CS3/AF3) is sent with MPLS EXP 3

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# exceed-action set mpls experimental imposition 7

! Exceeding SP-AF3-CLASS traffic is sent with MPLS EXP 7

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-AF2-CLASS

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# police rate percent 25

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# conform-action set mpls experimental imposition 2

! Conforming SP-AF2-CLASS traffic (CS2/AF2) is sent with MPLS EXP 2

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# exceed-action set mpls experimental imposition 7

! Exceeding SP-AF2-CLASS traffic is sent with MPLS EXP 7

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-AF1-CLASS

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# police rate percent 10

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# conform-action set mpls experimental imposition 1

! Conforming SP-AF1-CLASS traffic (CS1/AF1) is sent with MPLS EXP 1

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# exceed-action set mpls experimental imposition 7

! Exceeding SP-AF1-CLASS traffic is sent with MPLS EXP 7

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class class-default

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# police rate percent 25

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# conform-action set mpls experimental imposition 0

! Conforming default-class traffic is sent with MPLS EXP 0

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# exceed-action set mpls experimental imposition 7

! Exceeding default-class traffic is sent with MPLS EXP 7

! This section attaches the ingress policer to the PE-to-CE interface

RP/0/RSP0/CPU0:ASR9K(config)# interface GigabitEthernet 0/2/0/0

RP/0/RSP0/CPU0:ASR9K(config-if)# service-policy input SP-SIX-CLASS-INGRESS-MODEL-PIPE

可以用下面的命令验证例33-10中的配置。

■ show class-map reference list

■ show policy-map pmap name

■ show policy-map interface

■ show qos interface interface w/x/y/z output

2.（基于MPLS EXP的）管道模式出站队列策略

接下来，数据包会在PE到P接口上，命中基于MPLS EXP的出站队列策略，如例33-11所示。

例33-11 Cisco ASR 9000管道模式MPLS差分隧道:第二部分:（基于MPLS EXP的）6类出站队列策略

! This section configures the class maps for the six-class

! MPLS EXP-based egress queuing policy

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-all SP-REALTIME-EXP

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match mpls experimental topmost 5

! SP-REALTIME-EXP is matched by MPLS EXP 5

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-all SP-AF4-CLASS-EXP

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match mpls experimental topmost 4

! SP-AF4-CLASS-EXP is matched by MPLS EXP 4

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-all SP-AF3-CLASS-EXP

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match mpls experimental topmost 3

! SP-AF3-CLASS-EXP is matched by MPLS EXP 3

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-all SP-AF2-CLASS-EXP

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match mpls experimental topmost 2

! SP-AF2-CLASS-EXP is matched by MPLS EXP 2

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-all SP-AF1-CLASS-EXP

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match mpls experimental topmost 1

! SP-AF1-CLASS-EXP class is matched by MPLS EXP 1

! This section configures the six-class EXP-based queuing policy map

RP/0/RSP0/CPU0:ASR9K(config)# policy-map SP-SIX-CLASS-EXP-QUEUING

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-REALTIME-EXP

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# priority

! SP-REALTIME-EXP will operate at priority level 1 (default)

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class SP-AF4-CLASS-EXP

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 22

! SP-AF4-CLASS-EXP will receive CBWFQ with 22% bandwidth remaining

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class SP-AF3-CLASS-EXP

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 11

! SP-AF3-CLASS-EXP will receive CBWFQ with 11% bandwidth remaining

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class SP-AF2-CLASS-EXP

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 28

! SP-AF2-CLASS-EXP will receive CBWFQ with 11% bandwidth remaining

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class SP-AF1-CLASS-EXP

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 11

! SP-AF1-CLASS-EXP will receive CBWFQ with 28% bandwidth remaining

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class class-default

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 28

! The default class will receive CBWFQ with 28% bandwidth remaining

! This section applies the service policy to the PE-to-P interface

RP/0/RSP0/CPU0:ASR9K(config)# interface tenGigE 0/1/0/2

RP/0/RSP0/CPU0:ASR9K(config-if)# service-policy output SP-SIX-CLASS-EXP-QUEUING

注释:在这个模型中，假定SP-REALTIME分到了10%的带宽，因此其他类型的流量就会竞争剩余90%的总带宽。例如，SP-AF4-CLASS被分配了（总带宽）20%的带宽，但在配置bandwidth remaining percent这条命令时，应该填的百分比是22。

注释:通过MPLS EXP标记来匹配SP CoS的class map都加上了一个-EXP后缀，这是为了便于将它们与匹配DSCP值的class map区分开。

可以用下面的命令验证例33-7中的配置。

■ show class-map reference list

■ show policy-map pmap name

■ show policy-map interface

■ show qos interface interface w/x/y/z output

3.管道模式（MPLS EXP到QG）的入站映射策略

管道模式与统一模式MPLS 差分服务隧道中的情况相同，当数据包进入MPLS VPN 的出站PE时，它的最后一个标签也将马上弹出。因此，在数据包到达最终出站接口之前，它的MPLS EXP 值就会丢失。所以，在丢失之前，当数据包从核心进入PE 路由器时，它们的MPLS EXP值必须复制到一个称为QoS组（QG）的内部标签中。通过这种方式，最终出站（PE到CE）的队列策略，就可以按照这个QG 值（也就等于间接按照最后的MPLS EXP 值，也就是SP本地有效的标记）来执行了。

注释:匹配MPLS EXP的class map与PE到P的出站队列策略是相同的（该策略已经在上例中进行了介绍），而这些策略也可以用来执行入站方向的MPLS EXP映射策略，因此本例中不再赘述。

例33-12 显示了MPLS EXP 到QG 的入站映射策略。

例33-12 Cisco ASR 9000管道模式MPLS差分隧道:第三部分:MPLS EXP到QG的入站映射

! This section configures the ingress MPLS EXP-to-QG mapping

RP/0/RSP0/CPU0:ASR9K(config)# policy-map SP-SIX-CLASS-EXP-TO-QOS-GROUP

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-REALTIME-EXP

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# set qos-group 5

! MPLS EXP 5 is mapped to QoS group 5

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-AF4-CLASS-EXP

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# set qos-group 4

! MPLS EXP 4 is mapped to QoS group 4

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-AF3-CLASS-EXP

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# set qos-group 3

! MPLS EXP 3 is mapped to QoS group 3

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-AF2-CLASS-EXP

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# set qos-group 2

! MPLS EXP 2 is mapped to QoS group 2

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-AF1-CLASS-EXP

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# set qos-group 1

! MPLS EXP 1 is mapped to QoS group 1

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class class-default

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# set qos-group 0

! Everything else is mapped to QoS group 0

! This section applies the MPLS EXP-to-QG mapping

! to the PE-to-P interface in the ingress direction

RP/0/RSP0/CPU0:ASR9K(config)# interface tenGigE 0/1/0/2

RP/0/RSP0/CPU0:ASR9K(config-if)# service-policy input SP-SIX-CLASS-EXP-TO-QOS-GROUP

可以用下面的命令验证例33-12中的配置。

■ show class-map reference list

■ show policy-map pmap name

■ show policy-map interface

■ show qos interface interface w/x/y/z output

4.管道模式（基于QG的）出站队列策略

在数据包离开MPLS VPN网络时，它将命中的最后一个策略是PE到CE的出站队列策略，这项策略会基于AP（MPLS EXP）标记来执行。虽然此时，MPLS 标签已被弹出，但是它们的值已经被复制到了QG中，因此队列策略可以按照这些QG值来执行。

要注意，在管道模式中，数据包在离开MPLS VPN 网络时，设备不会用MPLS EXP 值替换客户的DSCP标记（这才能确保保证DSCP的透明性）。

配置管道模式MPLS 差分服务隧道策略的最后一个步骤，方法如例33-13 所示。

例33-13 Cisco ASR 9000管道模式MPLS差分隧道:第四部分:基于QG的出站队列策略

! This section configures the QG-based class maps

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-all SP-REALTIME-QG

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match qos-group 5

! SP-REALTIME-QG traffic is matched against QoS group 5

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-all SP-AF4-CLASS-QG

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match qos-group 4

! SP-AF4-CLASS-QG traffic is matched against QoS group 4

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-all SP-AF3-CLASS-QG

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match qos-group 3

! SP-AF3-CLASS-QG traffic is matched against QoS group 3

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-all SP-AF2-CLASS-QG

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match qos-group 2

! SP-AF2-CLASS-QG traffic is matched against QoS group 2

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-all SP-AF1-CLASS-QG

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match qos-group 1

! SP-AF1-CLASS-QG traffic is matched against QoS group 1

! This section configures the Pipe Mode six-class QG-based

! egress queuing policy map

RP/0/RSP0/CPU0:ASR9K(config)# policy-map SP-SIX-CLASS-QG-QUEUING-PIPE

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-REALTIME-QG

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# priority

! SP-REALTIME-QG receives priority level 1 service (by default)

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class SP-AF4-CLASS-QG

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 22

! SP-AF4-CLASS-QG receives 22% bandwidth remaining

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class SP-AF3-CLASS-QG

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 11

! SP-AF3-CLASS-QG receives 11% bandwidth remaining

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class SP-AF2-CLASS-QG

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 28

! SP-AF2-CLASS-QG receives 11% bandwidth remaining

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class SP-AF1-CLASS-QG

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 11

! SP-AF1-CLASS-QG receives 28% bandwidth remaining

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class class-default

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 28

! The default class receives 28% bandwidth remaining

! This section attaches the policy to the PE-to-CE interface

RP/0/RSP0/CPU0:ASR9K(config)# interface GigE 0/2/0/0

RP/0/RSP0/CPU0:ASR9K(config-if)# service-policy output SP-SIX-CLASS-QG-QUEUING-PIPE

注释:通过QG值来匹配SP CoS的class map都加上了一个-QG后缀，这是为了便于将它们与匹配DSCP值或MPLS EXP值的class map区分开。

可以用下面的命令验证例33-13中的配置。

■ show class-map reference list

■ show policy-map pmap name

■ show policy-map interface

■ show qos interface interface w/x/y/z output

33.3.3 短管道模式的MPLS 差分服务隧道

短管道模式的MPLS 差分服务隧道需要进行如下配置:

■ 在PE-CE边界配置入向限速；

■ 在PE-P 边界配置基于MPLS EXP 的出站队列；

■ 在PE-CE边界配置基于DSCP的出站队列。

注释:按照上述顺序介绍这些策略是有原因的，因为这就是数据包通过MPLS VPN时的逻辑操作顺序。

短管道模式与管道模式一个重要区别是，最后的MPLS VPN PE 出站（面向顾客CE）队列策略是根据客户的DSCP 标记来执行的（该标记在穿越MPLS VPN 的过程中保持不变）。因此，在最后一台PE 上，也就不必执行MPLS EXP 到QG 的映射。

在这个短管道模式的例子中，我们使用了前面章节中介绍过的（见图32-4）8类SP模型。图33-6显示了这个8类SP模型的其他一些具体信息。

图33-6 短管道模式6类SP模型:第一部分:入站限速与PE-P出站队列策略

1.短管道模式的入站限速器

在这个模型中，第一个策略是将客户流量限制在协定速率之内。与管道模式相同的是，符合这个限制的流量会被打上MPLS标签（其中EXP位与流量类别的DSCP值头3位数值相匹配），然后传输出去。这个模型中的MPLS EXP 标记只具有本地意义，因此完全可以依SP 的管理习惯而定。

在这个限速模型中，过量的SP-REALTIME流量会被丢弃。但过量的非实时流量则会被重标记为MPLS EXP 7（在这个示例中，这是提供商本地意义的数值，标识的就是过量的数据流）。此外，在这个模型中，MPLS EXP 7 的作用也是标识清道夫类的流量。

例33-14显示了短管道模式入站限速器的配置。

例33-14 Cisco ASR 9000短管道模式MPLS差分隧道:第一部分:入站限速器

! This section configures the class maps for the ingress policer

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-any SP-REALTIME

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp cs5

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp ef

! SP-REALTIME is matched on DSCP CS5 or EF

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-all SP-CONTROL

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp cs6

! SP-CONTROL class is matched on DSCP CS6

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-any SP-AF4-CLASS

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp cs4

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp af41

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp af42

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp af43

! SP-AF4-CLASS is matched on DSCP CS4 or AF4

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-any SP-AF3-CLASS

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp cs3

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp af31

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp af32

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp af33

! SP-AF3-CLASS is matched on DSCP CS3 or AF3

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-any SP-AF2-CLASS

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp cs2

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp af21

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp af22

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp af23

! SP-AF2-CLASS is matched on DSCP CS2 or AF2

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-any SP-AF1-CLASS

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp af11

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp af12

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp af13

! SP-AF1-CLASS is matched on DSCP AF1

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-all SP-SCAVENGER

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match dscp cs1

! SP-SCAVENGER is matched on DSCP CS1

! This section configures the Short Pipe Mode

! Eight-Class ingress policer

RP/0/RSP0/CPU0:ASR9K(config)# policy-map SP-EIGHT-CLASS-INGRESS-MODEL-SHORT-PIPE

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-REALTIME

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# police rate percent 10

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# conform-action set mpls experimental imposition 5

! Conforming SP-REALTIME traffic (EF/CS5) is sent with MPLS EXP 5

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# exceed-action drop

! Exceeding SP-REALTIME traffic is dropped

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-CONTROL

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# police rate percent 10

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# conform-action set mpls experimental imposition 6

! Conforming SP-CONTROL traffic (CS6) is sent with MPLS EXP 6

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# exceed-action set mpls experimental imposition 7

! Exceeding SP-CONTROL traffic is sent with MPLS EXP 7

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-AF4-CLASS

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# police rate percent 30

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# conform-action set mpls experimental imposition 4

! Conforming SP-AF4-CLASS traffic (CS4/AF4) is sent with MPLS EXP 4

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# exceed-action set mpls experimental imposition 7

! Exceeding SP-AF4-CLASS traffic is sent with MPLS EXP 7

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-AF3-CLASS

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# police rate percent 10

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# conform-action set mpls experimental imposition 3

! Conforming SP-AF3-CLASS traffic (CS3/AF3) is sent with MPLS EXP 3

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# exceed-action set mpls experimental imposition 7

! Exceeding SP-AF3-CLASS traffic is sent with MPLS EXP 7

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-AF2-CLASS

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# police rate percent 10

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# conform-action set mpls experimental imposition 2

! Conforming SP-AF2-CLASS traffic (CS2/AF2) is sent with MPLS EXP 2

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# exceed-action set mpls experimental imposition 7

! Exceeding SP-AF2-CLASS traffic is sent with MPLS EXP 7

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-AF1-CLASS

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# police rate percent 5

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# conform-action set mpls experimental imposition 1

! Conforming SP-AF1-CLASS traffic (AF1) is sent with MPLS EXP 1

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# exceed-action set mpls experimental imposition 7

! Exceeding SP-AF1-CLASS traffic is sent with MPLS EXP 7

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-SCAVENGER

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# police rate percent 1

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# conform-action set mpls experimental imposition 7

! Conforming SP-SCAVENGER traffic (CS1) is sent with MPLS EXP 7

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# exceed-action set mpls experimental imposition 7

! Exceeding SP-SCAVENGER traffic is sent with MPLS EXP 7

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class class-default

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# police rate percent 24

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# conform-action set mpls experimental imposition 0

! Conforming default-class traffic is sent with MPLS EXP 0

RP/0/RSP0/CPU0:ASR9K(config-pmap-c-police)# exceed-action set mpls experimental imposition 7

! Exceeding default-class traffic is sent with MPLS EXP 7

! This section attaches the ingress policer to the PE-to-CE interface

RP/0/RSP0/CPU0:ASR9K(config)# interface GigabitEthernet 0/2/0/0

RP/0/RSP0/CPU0:ASR9K(config-if)# service-policy input SP-EIGHT-CLASS-INGRESS-MODEL-SHORT-PIPE

可以用下面的命令验证例33-14中的配置。

■ show class-map reference list

■ show policy-map pmap name

■ show policy-map interface

show qos interface interface w/x/y/z output

2.（基于MPLS EXP的）短管道模式出站队列策略

接下来，数据包会在PE到P接口上，命中基于MPLS EXP的出站队列策略，如例33-15所示。

例33-15 Cisco ASR 9000短管道模式MPLS差分隧道:第二部分:（基于MPLS EXP的）8类出站队列策略

! This section configures the class maps for the eight-class

! MPLS EXP-based egress queuing policy

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-all SP-REALTIME-EXP

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match mpls experimental topmost 5

! SP-REALTIME-EXP is matched by MPLS EXP 5

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-all SP-CONTROL-EXP

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match mpls experimental topmost 6

! SP-CONTROL-EXP is matched by MPLS EXP 6

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-all SP-AF4-CLASS-EXP

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match mpls experimental topmost 4

! SP-AF4-CLASS-EXP is matched by MPLS EXP 4

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-all SP-AF3-CLASS-EXP

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match mpls experimental topmost 3

! SP-AF3-CLASS-EXP is matched by MPLS EXP 3

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-all SP-AF2-CLASS-EXP

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match mpls experimental topmost 2

! SP-AF2-CLASS-EXP is matched by MPLS EXP 2

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-all SP-AF1-CLASS-EXP

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match mpls experimental topmost 1

! SP-AF1-CLASS-EXP is matched by MPLS EXP 1

RP/0/RSP0/CPU0:ASR9K(config-cmap)# class-map match-all SP-SCAVENGER-EXP

RP/0/RSP0/CPU0:ASR9K(config-cmap)# match mpls experimental topmost 7

! SP-SCAVENGER-EXP is matched by MPLS EXP 7

! This section configures the eight-class EXP-based queuing policy map

RP/0/RSP0/CPU0:ASR9K(config)# policy-map SP-EIGHT-CLASS-EXP-QUEUING

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-REALTIME-EXP

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# priority

! SP-REALTIME-EXP will operate at priority level 1 (default)

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-CONTROL-EXP

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 11

! SP-CONTROL-EXP will receive CBWFQ with 11% bandwidth remaining

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-AF4-CLASS-EXP

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 33

! SP-AF4-CLASS-EXP will receive CBWFQ with 33% bandwidth remaining

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-AF3-CLASS-EXP

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 11

! SP-AF3-CLASS-EXP will receive CBWFQ with 11% bandwidth remaining

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-AF2-CLASS-EXP

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 11

! SP-AF2-CLASS-EXP will receive CBWFQ with 11% bandwidth remaining

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-AF1-CLASS-EXP

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 6

! SP-AF1-CLASS-EXP will receive CBWFQ with 6% bandwidth remaining

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-SCAVENGER-EXP

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 1

! SP-SCAVENGER-EXP will receive CBWFQ with 1% bandwidth remaining

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class class-default

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 27

! The default class will receive CBWFQ with 27% bandwidth remaining

! This section applies the service policy to the PE-to-P interface

RP/0/RSP0/CPU0:ASR9K(config)# interface tenGigE 0/1/0/2

RP/0/RSP0/CPU0:ASR9K(config-if)# service-policy output SP-EIGHT-CLASS-EXP-QUEUING

注释:通过MPLS EXP标记来匹配SP CoS的class map都加上了一个-EXP后缀，这是为了便于将它们与匹配DSCP值的class map区分开。

可以用下面的命令验证例33-7中的配置。

■ show class-map reference list

■ show policy-map pmap name

■ show policy-map interface

■ show qos interface interface w/x/y/z output

3.短管道模式（基于DSCP的）出站队列策略

短管道模式和管道模式之间最主要区别在于最终出站队列策略（面向顾客CE）是根据客户的DSCP 标记来执行的，数据包在MPLS VPN 中传输的过程中，这个标记不会改变。

图33-7所示为最后这些的PE-CE出站队列策略。

图33-7 短管道模式6类SP模型:第二部分:最后的PE-CE出站队列策略

例33-16所示为图33-7对应的配置命令。

注释:由于这些class map是基于DSCP值来进行匹配的（与入站队列策略的class map相同），因此这些class map与例33-14中所示的class map相同，本例中不再赘述。

例33-16 Cisco ASR 9000管道模式MPLS差分隧道:第三部分:基于DSCP的出站队列策略

! This section configures the Short Pipe Mode

! eight-class DSCP-based egress queuing policy map

RP/0/RSP0/CPU0:ASR9K(config)# policy-map SP-EIGHT-CLASS-QUEUING-SHORT-PIPE

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-REALTIME

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# priority

! SP-REALTIME will operate at priority level 1 (default)

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-CONTROL

! SP-CONTROL will receive CBWFQ with 11% bandwidth remaining

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 11

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-AF4-CLASS

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 33

! SP-AF4-CLASS will receive CBWFQ with 33% bandwidth remaining

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# random-detect dscp-based

! Enables DSCP-based WRED on SP-AF4-CLASS

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-AF3-CLASS

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 11

! SP-AF3-CLASS will receive CBWFQ with 11% bandwidth remaining

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# random-detect dscp-based

! Enables DSCP-based WRED on SP-AF3-CLASS

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-AF2-CLASS

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 11

! SP-AF2-CLASS will receive CBWFQ with 11% bandwidth remaining

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# random-detect dscp-based

! Enables DSCP-based WRED on SP-AF2-CLASS

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-AF1-CLASS

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 6

! SP-AF1-CLASS will receive CBWFQ with 6% bandwidth remaining

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# random-detect dscp-based

! Enables DSCP-based WRED on SP-AF1-CLASS

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-SCAVENGER

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 1

! SP-SCAVENGER will receive CBWFQ with 1% bandwidth remaining

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class class-default

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 27

! The default class will receive CBWFQ with 27% bandwidth remaining

! This section applies the service policy to the PE-to-CE interface

RP/0/RSP0/CPU0:ASR9K(config)# interface GigabitEthernet 0/2/0/0

RP/0/RSP0/CPU0:ASR9K(config-if)# service-policy output SP-EIGHT-CLASS-QUEUING-SHORT-PIPE

注释:由于最后的队列策略是根据客户的DSCP标记来执行的，因此这个节点上很适合启用基于DSCP的WRED；而基于MPLS-EXP的WRED则可以（根据具体需要）应用于那些基于服务提供商的MPLS EXP标记，来执行拥塞避免策略的节点上。

可以用下面的命令验证例33-16中的配置。

■ show class-map reference list

■ show policy-map pmap name

■ show policy-map interface

■ show qos interface interface w/x/y/z output

33.4 总结

本章概述了服务提供商PE路由器在QoS中扮演的角色，并解释了Cisco的ASR9000系列ASR非常适合这个角色的理由。

本章还对ASR 9000 的QoS 架构进行了概述，证明了这是一个无阻的内部架构。此外，由于ASR 9000 可以通过配置起到聚合流量的作用，因此它支持大量的内部队列子系统，除了入站队列、出站队列之外，还支持VOQ和出站FIA队列的三级内部队列（优先级1队列、优先级2队列、普通队列）。

接下来，本章提供了三套完整的设计模型，介绍了如何配置统一模式、管道模式、短管道模式的MPLS 差分服务隧道，其中包括:

■ 入口限速模型；

■ 基于MPLS EXP（PE 到P）的队列模型；

■ MPLS EXP 到QoS 组的映射模型（如有需要）；

■ QoS组或基于DSCP（PE到P）的队列模型。

此外，本章还以大量示例介绍了以下三种服务提供商模型。

■ 4类SP模型；

■ 6类SP模型；

■ 8类SP模型。

33.5 扩展阅读

Cisco ASR 9000 Series Aggregation Services Router Modular Quality of Service Configuration Guide, Release 4.3.x （Cisco ASR 9000系列汇聚服务路由器模块化QoS配置指南，4.3.x版）:http://www.cisco.com/en/US/docs/routers/asr9000/software/asr9k_r4.3/qos/configuration/guide/b_qos_cg43xasr.html

Cisco ASR 9000 Series Aggregation Services Router MPLS Layer 3 VPN Configuration Guide, Release 4.3.x （Cisco ASR 9000系列汇聚服务路由器MPLS 3层VPN配置指南， 4.3.x 版）:http://www.cisco.com/en/US/docs/routers/asr9000/software/asr9k_r4.3/lxvpn/configuration/guide/vcasr9kv343.html

第34章 服务提供商核心（Cisco CRS）的QoS设计

服务提供商核心路由器的QoS设计，主要是为了解决网络拥塞时出现的丢包问题——无论拥塞发生在设备内部还是发生在接口上。

有时，服务提供商会在核心路由器上采取多种不同的方法来解决丢包的问题。其中的一种方法是密切监测链路的使用率，当使用率达到40%或50%时，增加额外的链路，以此来消除客户对于QoS 的需求。另一个方式是实施MPLS 流量工程（MPLS Traffic Engineering）。

对于服务提供商使用差分服务（DiffServ）QoS策略的情形，图34-1显示了SP核心路由器上的一些特殊QoS需求。

图34-1 服务提供商核心路由器的QoS角色

Cisco CRS-3 系列路由器经常用来充当SP 边界路由器的角色。不过，读者在进入设计的环节之前，不妨先对这个平台的硬件架构进行一下大致的了解。

34.1 QoS的体系结构

Cisco CRS 是专门为SP 网络设计的一款完全模块化的、分布式的路由器。CRS-3 是当前路由器系统中最具代表性的，它的容量是原先CRS-1系统的3.5倍，最高容量可达322TB。

CRS系统包含了多种内部QoS机制。为了解释清楚CRS的用途与原理，下面不妨对CRS的硬进行一个简短的概括。CRS-3系统主要由以下几部分组成。

■ 路由处理器（RP）:负责执行控制和管理功能。

■ 模块化服务卡（MSC）:是一个模块化的线路卡，可以提供基于硬件的数据包转发、策略特性，以及QoS数据包处理功能。CRS-MSC-140G系列模块就是为了让CRS-3能以140Gbit/s的速度连接到交换矩阵而专门设计的。

■ 物理层接口模块（PLIM）:一种物理上与设备相分离模块，可以提供光纤接口以及硬件的数据帧封装功能。一个PLIM上可以有一块或者多块特定PLIM应用接口卡（ASIC）（PLA），它们的作用是与相连的MSC交换三层数据包。

■ 中间层（Midplane）:直接连接相邻的PLIM和MSC，也负责将各个MSC与交换矩阵直接连接起来。

■ 交换矩阵（Switch fabric）:实现MSC之间的互联。CRS的交换矩阵是一个3段式的，基于信元的交换矩阵，它可以感知QoS技术。

图34-2显示了CRS-3架构中各个主要组成成份之间的相互关系。

在CRS-3架构中，有很多地方都有可能出现拥塞。要找出这些有可能出现拥塞的地方，应该深入研究CRS-3的硬件架构，以便了解MSC(CRS-MSC-140G)组成成份的具体信息，如图34-3所示。图34-3的上半部分表示数据包进入交换矩阵的路径，下半部分表示的是则是数据包出站的路径（有可能通过同一个MSC，也可能通过不同的MSC）

图34-2 CRS-3系统硬件架构

图34-3 CRS-3 MSC系统架构

MSC会在以下位置执行QoS操作。

1.PLIM:每个PLIM 都是通过一条140Gbit/s 的通道连接到MSC 的；其中有些PLIM可以缓冲数据（例如20 端口的10GE LAN/WAN-PHY 接口模块，总入站流量达到200Gbit/s）。为了管理这种情况，PLIM ASIC 实施了一个两级队列的策略（这两级为高优先级/低优先级）。

2.入站PSE（数据包交换引擎）:是负责处理3 层特性的主要ASIC，负责应用安全策略和QoS特性（如限速和WRED［加权随机早期检测］，入站和出站的队列ASIC负责执行队列和整形）。一个PSE负责接收数据（称为入站PSE），另一个PSE负责发送数据（称为出站PSE）。

3.入站队列:接收队列ASIC。入站和出站队列除了支持低延迟（low-latency）/ 严格优先级（strict-priority）队列与整形之外，都会使用一个叫做“逐个数据包修改的亏空轮巡（P2MDRR）”队列算法。以160Gbit/s 的速率进入入站队列Q ASIC 的数据包，会以141Gbit/s的速率离开队列，离开时原本的数据包被拆分成136字节一个的信元。在这个节点使用队列机制的原因，就是为了让数据的出站速率低于其入站速率。

4.交换矩阵:对于单播和组播流量，第2 段和第3 段交换矩阵（即矩阵S2 和矩阵S3）支持两级的队列策略（高优先级/低优先级）。

5.矩阵队列:在传输路径（从矩阵到PLIM）中，有两个矩阵队列ASIC。矩阵队列ASIC的主要功能就是将各个这些新元重组为一个完整的数据包。不过，由于这些信元进入矩阵队列的速率为113Gbit/s，而离开的速率却是100Gbit/s，因此在这些节点上同样必须使用队列技术。通过配置，矩阵队列可以以三种服务等级为数据包提供服务，这三个等级为:高优先级（HI）、确认转发（AF）和尽力而为的传输（BE）。

6.出站PSE:在传输端对入站PSE 的补充，支持在出站方向上进行限速和WRED。

7.出站队列:在传输端对入站队列ASIC 的补充，支持P2MDRR、低延迟队列和整形。

请注意，在每一个有可能出现内部拥塞的阶段，CRS-3都可以使用高优先级转发机制，也就是说，在所有有可能出现拥塞的节点上，高优先级的流量都能获得严格优先级服务。在矩阵队列中，管理员还可以对队列进行进一步的细分（可分为三个服务等级:高优先级、确认转发和尽力而为传输）。最后，入站和出站队列ASIC都支持最精确的队列分类，它们在所有接口上支持64000个队列。

管理员需要按照下面的方式配置接口QoS策略和内部QoS策略。

■ 应用在接口的入站方向上的（基于MQC 的）service policy 会在入站PSE 和入站队列ASIC 中进行实施。此外，policy map 中所有配置了priority 这种动作的流量类型，都不仅会在入站队列中接收到严格优先级服务，也会在PLIM ASIC 中接收严格优先级服务。

■ 应用在接口的出站方向上的（基于MQC 的）service policy 会在出站PSE 和出站队列ASIC中进行实施。

■ 应用在接口的交换矩阵上的（基于MQC 的）service policy 会在矩阵队列ASIC 中进行实施（交换矩阵在IOS XR 配置中是一个虚拟接口）。此外，policy map 中所有配置了priority这种动作的流量类型，都不仅会在矩阵队列ASIC接收到严格优先级服务，也会在交换机矩阵（S2和S3）队列和入站队列ASIC矩阵队列中接收严格优先级服务（ASIC矩阵队列是这个ASIC将信元传输给交换机矩阵的最后一个队列）。这类策略被统称为矩阵QoS，因为这类策略可以控制数据包/信元进入、穿越和离开交换矩阵的方式。

关于矩阵QoS策略和入站接口QoS策略这两者之间的关系，有一点必须强调:矩阵QoS策略可以（在入站队列矩阵队列ASIC的位置）控制（或覆盖）入站的QoS策略。如果入站接口的QoS策略是对流量进行分类，侬将其中某一类标记为优先类，而矩阵QoS策略却是将另一种流量标记为优先类，或者根本不将任何类型流量的设置为优先级流量。那么，入站接口上的priority这个语句就会在入站队列矩阵队列的地方被设备所忽略（因为入站接口的策略被矩阵QoS 策略覆盖了）。而矩阵QoS 策略会在S2 ASIC、S3 ASIC 和矩阵队列的位置控制队列技术。

注释:所有配置在入站接口策略中的priority（优先）策略，仍会用于入站队列ASIC上所配置的整形队列。但矩阵QoS应该控制哪些数据包会在入站队列矩阵队列中获得优先级服务。

例如，如果管理员通过在入站接口上配置关键字priority，而对流量打上MPLS EXP5 的标记，但却没有配置矩阵QoS 策略，那么EXP 5 数据包就不会在入站队列矩阵队列中获得高优先级服务（因为默认情况下，在矩阵QoS中，只有控制流量会被放入高优先级队列中）。

如果管理员配置了矩阵QoS 策略，只对MPLS EXP 6 数据包分配priority 服务，那么在入站队列矩阵队列中、S2、S3和矩阵队列中，同样也只有这类数据包可以获得严格优先级服务。

因此，管理员应该确保入站QoS策略和矩阵QoS策略之间不存在冲突。

34.2 QoS设计步骤

在充当运营商核心路由器的Cisco CRS-3 路由器上配置QoS，可以分为两大主要步骤。

1.配置一个矩阵QoS策略。

2.配置接口QoS策略（可以应用在入站方向或出站方向，也可能两个方向都要应用）。

34.3 运营商核心的CoS QoS模型

运营商核心QoS策略一共有三套（每套中都包括矩阵QoS策略和接口QoS策略），这三套SP CoS 模型分别为:

■ 4类的SP模型；

■ 6类的SP模型；

■ 8类的SP模型。

在下文中，本书会对这些SP核心CoS模型一一进行介绍（这三大模型可以与前面章节中的SP模型相对应）。

34.3.1 4-CoS的SP模型

4类的SP模型可以分别参考图32-2及图33-4。下面，将着重介绍矩阵QoS策略和接口QoS策略所对应的4类SP模型。

1.4-CoS的矩阵QoS策略

例34-1显示了矩阵QoS策略的4类SP模型。对于矩阵QoS策略来说，只能使用三个队列。

■ MPLS EXP 5 数据包对应高优先级矩阵Q。

■ MPLS EXP 2 和3 对应确认转发矩阵Q（为了满足这两类流量的转发需求，为它们分配的带宽值为这两类流量所需带宽的总和）。

■ 所有其他EXP值则（默认）对应尽力而为矩阵Q。

例34-1 服务提供商核心路由器的QoS角色

! This section configures the class maps for four-class fabric QoS

RP/0/RP0/CPU0:CRS-3(config-cmap)# class-map match-any SP-FABQOS-HI

RP/0/RP0/CPU0:CRS-3(config-cmap)# match mpls experimental topmost 5

! Matches MPLS EXP 5 (corresponds to the SP-REALTIME class)

RP/0/RP0/CPU0:CRS-3(config-cmap)# class-map match-any SP-FABQOS-AF

RP/0/RP0/CPU0:CRS-3(config-cmap)# match mpls experimental topmost 2 3

! Matches MPLS EXP 2 and 3 (corresponds to guaranteed BW SP classes)

! This section configures the four-class fabric QoS policy map

RP/0/RP0/CPU0:CRS-3(config-pmap)# policy-map SP-FOUR-CLASS-FABQOS

RP/0/RP0/CPU0:CRS-3(config-pmap)# class SP-FABQOS-HI

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# priority

! The SP-FABQOS-HP gets high priority (strict priority)

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# class SP-FABQOS-AF

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# bandwidth remaining percent 65

! The SP-FABQOS-AF gets assured forwarding with 65% BWR

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# class class-default

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# bandwidth remaining percent 35

! The default-class gets best effort with 35% BWR

! This section applies the fabric QoS policy to the switch fabric

RP/0/RP0/CPU0:CRS-3(config)# switch-fabric

RP/0/RP0/CPU0:CRS-3(config-switch-fabric)# service-policy SP-FOUR-CLASS-FABQOS

! Applies the fabric QoS policy to the switch fabric

注释:在这些案例中，所有class map执行的操作都是match-any，因为CRS-3的IOS XR（4.3.x版）系统不支持match-all操作。

注释:配置了priority语句的矩阵QoS policy map会将匹配的流量分配到一个高优先级（HI）的矩阵Q 队列中，而配置了bandwidth remaining 语句的policy map 会将匹配的流量类型分配到一个确认转发（AF）的矩阵Q队列中，而默认类型的流量则会被分配到尽力而为（BE）矩阵Q中（是否为默认类别分配带宽可由管理员根据需要自行决定）。

注释:在将service-policy语句应用到交换矩阵时，不需要为其指定方向（如入站方向或出站方向）。这是因为矩阵QoS策略实际上既适用于入站方向的队列策略（如入站Q矩阵队列），也适用于出站方向的队列策略（如交换矩阵的S2、S3段及矩阵队列）。

可以用下面命令来验证例34-1中的配置。

■ show class-map reference list

■ show policy-map pmap name

■ show controllers fabricq queues（见例34-2）

■ show controllers fabricq statistics（见例34-3）

例34-2突出显示了每个接口都有3个矩阵Q队列，它们是HI（高优先级队列）、AF（确认转发队列）和BE（尽力而为队列），以及管理员针对这些队列所作的配置。此外，这个案例也显示了组播流量也有同样这三个级别的队列，但还多了一个专门用来转发CPU控制流量的高优先级队列。

例34-2 验证矩阵QoS的命令:show controllers fabric queues

RP/0/RP0/CPU0:CRS-3# show controllers fabricq queues loc 0/5/CPU0

Fabric Queue Manager Queue Information:

=======================================

Location:0/5/CPU0

Asic Instance:0

Fabric Destination Address:0

CpuCtrl Cast range:0 - 7

Multicast Range:8 - 71

Unicast Quanta in KBytes:58, Multicast Quanta:14

+-----------------------------------------------------------------------------------

--+

|Type/Ifname　　　|Port| Queue| Q |P-quanta|Q-quanta|HighW |LowW　| Q Len |

BW |

|　　　　　　| num|　num |pri| KBytes | KBytes |KBytes|KBytes| KBytes|

(kbps)|

+-----------------------------------------------------------------------------------

--+

|Cpuctrl Cast　　　|　0| 0 – 7| HI|　13|　　13| 1021|　919|　0|

N/A|

|Multicast　　　|　0|　9| BE|　13|　　13| 5118|　4606|　0|

N/A|

|Multicast　　　|　0|　10| AF|　13|　　13| 5118|　4606|　0|

N/A|

|Multicast　　　|　0|　11| HI|　13|　1905| 5118|　4606|　0|

N/A|

|GigabitEthernet0/5/0/0|　1|　1025| BE|　13|　187| 3661|　3295|　0|

1000000|

|GigabitEthernet0/5/0/0|　2|　2049| AF|　13|　187| 3661|　3295|　0|

1000000|

|GigabitEthernet0/5/0/0|　3|　3073| HI|　1905|　187| 3661|　3295|　0|

1000000|

<snip>

例34-3通过阴影部分突出强调了以下现象:虽然在这个矩阵队列中，从信元重组出来的数据包有8,715,884,484个之多，但没有一个数据包遭到丢弃。

例34-3 验证矩阵QoS的命令:show controllers fabric statistics

RP/0/RP0/CPU0:CRS-3# show controllers fabricq statistics loc 0/1/CPU0

Fabric Queue Manager Packet Statistics

======================================

Location:0/1/CPU0

Asic Instance:0

Fabric Destination Address:　　　4

BP Asserted Count:　　　　　1 (+　　　　0 )

MC BP Asserted Count:　　　　0 (+　　　　0 )

Input Cell counters:

+----------------------------------------------------------+

Data cells:　　　　5202891134 (+　　　　4 )

Control cells:　　　2133618291 (+　　　34000 )

Idle cells:　　　31374246993871 (+　　499897823 )

Reassembled packet counters

+----------------------------------------------------------+

Ucast pkts:　　　　8715884484 (+　　　　0 )

Mcast pkts:　　　　　　0 (+　　　　0 )

Cpuctrlcast pkts:　　　1422623 (+　　　　2 )

Dropped packets

+----------------------------------------------------------+

Ucast pkts:　　　　　　0 (+　　　　0 )

Mcast pkts:　　　　　　0 (+　　　　0 )

Cpuctrlcast pkts:　　　　　0 (+　　　　0 )

Vital denied pkts:　　　　　0 (+　　　　0 )

NonVital denied pkts:　　　　0 (+　　　　0 )

Unicast lost pkts:　　　　　0 (+　　　　0 )

Ucast partial pkts:　　　　0 (+　　　　0 )

PSM OOR Drops:　　　　　　0 (+　　　　0 )

2.4-CoS的接口QoS策略

例34-4显示了接口QoS策略的4类SP模型。值得注意的是，（在CRS-MSC-140G上）管理员必须为配置了priority的流量类型手动添加一个限速器，这一点有别于其他平台。

例34-4 Cisco CRS-3的4类SP模型接口QoS策略

! The class maps for this policy are essentially the same

! as in Example 33-7

! (with the exception of substituting "match-all" with "match-any")

! and so, these will not be repeated here for the sake of brevity

! This section configures the four-class interface QoS policy map

RP/0/RP0/CPU0:CRS-3(config-pmap)# policy-map SP-FOUR-CLASS-EXP-QUEUING

RP/0/RP0/CPU0:CRS-3(config-pmap)# class SP-REALTIME-EXP

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# police rate percent 30

! An explicit policer is required on the priority class (CRS-MSC-140G)

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# priority level 1

! The SP-REALTIME-EXP class will receive strict-priority servicing

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# class SP-AF3-CLASS-EXP

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# bandwidth remaining percent 15

! The SP-AF3-CLASS-EXP class will receive 15% bandwidth remaining

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# class SP-AF2-CLASS-EXP

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# bandwidth remaining percent 50

! The SP-AF2-CLASS-EXP class will receive 50% bandwidth remaining

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# class class-default

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# bandwidth remaining percent 35

! Class-default will receive 35% bandwidth remaining

! This section applies the four-class interface QoS policy map to a

! core-to-edge (P-to-PE) interface in both directions

RP/0/RP0/CPU0:CRS-3(config)# interface TenGigE 0/1/0/2

RP/0/RP0/CPU0:CRS-3(config-if)# service-policy input SP-FOUR-CLASS-EXP-QUEUING

RP/0/RP0/CPU0:CRS-3(config-if)# service-policy output SP-FOUR-CLASS-EXP-QUEUING

! This section applies the four-class interface QoS policy map to a

! core-to-core (P-to-P) interface in both directions

RP/0/RP0/CPU0:CRS-3(config)# interface HundredGigE 0/1/1/0

RP/0/RP0/CPU0:CRS-3(config-if)# service-policy input SP-FOUR-CLASS-EXP-QUEUING

RP/0/RP0/CPU0:CRS-3(config-if)# service-policy output SP-FOUR-CLASS-EXP-QUEUING

可以使用如下命令来检验例34-4中的配置。

■ show class-map reference list

■ show policy-map pmap name

■ show policy-map interface

■ show QoS interface interface w/x/y/z output

34.3.2 6-CoS的SP模型

6类的SP模型可以分别参考图32-3及图33-5。下面，将着重介绍矩阵QoS策略和接口QoS策略所对应的4类SP模型。

1.6-CoS的矩阵QoS策略

例34-5显示了矩阵QoS策略的6类SP模型。对于矩阵QoS策略来说，只能使用三个队列。

■ MPLS EXP 5 数据包对应高优先级矩阵Q。

■ MPLS EXP 1 到4 对应确认转发矩阵Q（为了满足这两类流量的转发需求，为它们分配的带宽值为这几类流量所需带宽的总和）。

■ 所有其他EXP值则（默认）对应尽力而为矩阵Q。

例34-5 Cisco CRS-3的6类SP模型矩阵QoS策略

! This section configures the class maps for six-class fabric QoS

RP/0/RP0/CPU0:CRS-3(config-cmap)# class-map match-any SP-FABQOS-HI

RP/0/RP0/CPU0:CRS-3(config-cmap)# match mpls experimental topmost 5

! Matches MPLS EXP 5 (corresponds to the SP-REALTIME class)

RP/0/RP0/CPU0:CRS-3(config-cmap)# class-map match-any SP-FABQOS-AF

RP/0/RP0/CPU0:CRS-3(config-cmap)# match mpls experimental topmost 1 2 3 4

! Matches MPLS EXP 1-4 (corresponds to guaranteed BW SP classes)

! This section configures the six-class fabric QoS policy map

RP/0/RP0/CPU0:CRS-3(config-pmap)# policy-map SP-SIX-CLASS-FABQOS

RP/0/RP0/CPU0:CRS-3(config-pmap)# class SP-FABQOS-HI

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# priority

! The SP-FABQOS-HP gets High-Priority (strict-priority)

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# class SP-FABQOS-AF

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# bandwidth remaining percent 72

! The SP-FABQOS-AF gets Assured Forwarding with 72% BWR

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# class class-default

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# bandwidth remaining percent 28

! The default-class gets Best Effort with 28% BWR

! This section applies the fabric QoS policy to the switch fabric

RP/0/RP0/CPU0:CRS-3(config)# switch-fabric

RP/0/RP0/CPU0:CRS-3(config-switch-fabric)# service-policy SP-SIX-CLASS-FABQOS

! Applies the Fabric QoS policy to the switch fabric

可以使用如下命令来检验例34-5中的配置。

■ show class-map reference list

■ show policy-map pmap name

■ show controllers fabricq queues

■ show controllers fabricq statistics

2.6-CoS的接口QoS策略

例34-6显示了6类SP模型的接口Qos策略。

例34-6 Cisco CRS-3的6类SP模型接口QoS策略

! The class maps for this policy are essentially the same as

! in Example 33-11

! (with the exception of substituting "match-all" with "match-any")

! and so, these will not be repeated here for the sake of brevity

! This section configures the six-class interface QoS policy map

RP/0/RP0/CPU0:CRS-3(config-pmap)# policy-map SP-SIX-CLASS-EXP-QUEUING

RP/0/RP0/CPU0:CRS-3(config-pmap)# class SP-REALTIME-EXP

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# police rate percent 10

! An explicit policer is required on the priority-class (CRS-MSC-140G)

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# priority level 1

! The SP-REALTIME-EXP class will receive strict-priority servicing

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# class SP-AF4-CLASS-EXP

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# bandwidth remaining percent 22

! The SP-AF4-CLASS-EXP class will receive 22% bandwidth remaining

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# class SP-AF3-CLASS-EXP

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# bandwidth remaining percent 11

! The SP-AF3-CLASS-EXP class will receive 11% bandwidth remaining

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# class SP-AF2-CLASS-EXP

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# bandwidth remaining percent 11

! The SP-AF2-CLASS-EXP class will receive 11% bandwidth remaining

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# class SP-AF1-CLASS-EXP

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# bandwidth remaining percent 28

! The SP-AF1-CLASS-EXP class will receive 28% bandwidth remaining

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# class class-default

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# bandwidth remaining percent 28

! Class-default will receive 28% bandwidth remaining

! This section applies the six-class interface QoS policy map to a

! core-to-edge (P-to-PE) interface in both directions

RP/0/RP0/CPU0:CRS-3(config)# interface TenGigE 0/1/0/2

RP/0/RP0/CPU0:CRS-3(config-if)# service-policy input SP-SIX-CLASS-EXP-QUEUING

RP/0/RP0/CPU0:CRS-3(config-if)# service-policy output SP-SIX-CLASS-EXP-QUEUING

! This section applies the six-class interface QoS policy map to a

! core-to-core (P-to-P) interface in both directions

RP/0/RP0/CPU0:CRS-3(config)# interface HundredGigE 0/1/1/0

RP/0/RP0/CPU0:CRS-3(config-if)# service-policy input SP-SIX-CLASS-EXP-QUEUING

RP/0/RP0/CPU0:CRS-3(config-if)# service-policy output SP-SIX-CLASS-EXP-QUEUING

可以使用如下命令来检验例34-6中的配置。

■ show class-map reference list

■ show policy-map pmap name

■ show policy-map interface

■ show qos interface interface w/x/y/z output

34.3.3 8-CoS的SP模型

8类的SP模型可以分别参考图32-4及图33-6。下面，将着重介绍矩阵QoS策略和接口QoS策略所对应的8类SP模型。

1.8-CoS的矩阵QoS策略

例34-7显示了矩阵QoS策略的8类SP模型。对于矩阵QoS策略来说，只能使用三个队列。

■ MPLS EXP 5 数据包对应高优先级矩阵Q。

■ MPLS EXP 1、2、3、4、6、7 对应确认转发矩阵Q（为了满足这两类流量的转发需求，为它们分配的带宽值为这几类流量所需带宽的总和）。

■ 所有其他MPLS EXP 值（在本例中仅为MPLS EXP 0）则对应尽力而为矩阵Q。

例34-7 Cisco CRS-3的8类SP模型矩阵QoS策略

! This section configures the class maps for eight-class fabric QoS

RP/0/RP0/CPU0:CRS-3(config-cmap)# class-map match-any SP-FABQOS-HI

RP/0/RP0/CPU0:CRS-3(config-cmap)# match mpls experimental topmost 5

! Matches MPLS EXP 5 (corresponds to the SP-REALTIME class)

RP/0/RP0/CPU0:CRS-3(config-cmap)# class-map match-any SP-FABQOS-AF

RP/0/RP0/CPU0:CRS-3(config-cmap)# match mpls experimental topmost 1 2 3 4 6 7

! Matches MPLS EXP 1-4 and 6 & 7 (guaranteed BW SP classes)

! This section configures the eight-class fabric QoS policy map

RP/0/RP0/CPU0:CRS-3(config-pmap)# policy-map SP-EIGHT-CLASS-FABQOS

RP/0/RP0/CPU0:CRS-3(config-pmap)# class SP-FABQOS-HI

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# priority

! The SP-FABQOS-HP gets high-priority (strict-priority)

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# class SP-FABQOS-AF

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# bandwidth remaining percent 73

! The SP-FABQOS-AF gets assured forwarding with 73% BWR

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# class class-default

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# bandwidth remaining percent 27

! The default-class gets best effort with 27% BWR

! This section applies the fabric QoS policy to the switch fabric

RP/0/RP0/CPU0:CRS-3(config)# switch-fabric

RP/0/RP0/CPU0:CRS-3(config-switch-fabric)# service-policy SP-EIGHT-CLASS-FABQOS

! Applies the fabric QoS policy to the switch fabric

可以使用如下命令来检验例34-7中的配置。

■ show class-map reference list

■ show policy-map pmap name

■ show controllers fabricq queues

■ show controllers fabricq statistics

2.8-CoS的接口QoS策略

例34-8显示了8类SP模型的接口QoS策略。

例34-8 Cisco CRS-3的8类SP模型接口QoS策略

! The class-maps for this policy are essentially the same as

! in Example 33-15

! (with the exception of substituting "match-all" with "match-any")

! as such, these will not be repeated here for the sake of brevity

! This section configures the eight-class interface QoS policy-map

RP/0/RP0/CPU0:CRS-3(config-pmap)# policy-map SP-EIGHT-CLASS-EXP-QUEUING

RP/0/RP0/CPU0:CRS-3(config-pmap)# class SP-REALTIME-EXP

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# police rate percent 10

! An explicit policer is required on the priority-class (CRS-MSC-140G)

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# priority level 1

! SP-REALTIME-EXP class will receive strict-priority servicing

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# class SP-CONTROL-EXP

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# bandwidth remaining percent 11

! The SP-CONTROL-EXP class will receive 11% bandwidth remaining

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# class SP-AF4-CLASS-EXP

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# bandwidth remaining percent 33

! The SP-AF4-CLASS-EXP class will receive 33% bandwidth remaining

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# class SP-AF3-CLASS-EXP

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# bandwidth remaining percent 11

! The SP-AF3-CLASS-EXP class will receive 11% bandwidth remaining

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# class SP-AF2-CLASS-EXP

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# bandwidth remaining percent 11

! The SP-AF2-CLASS-EXP class will receive 11% bandwidth remaining

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# class SP-AF1-CLASS-EXP

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# bandwidth remaining percent 6

! The SP-AF1-CLASS-EXP class will receive 6% bandwidth remaining

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# class SP-SCAVENGER-CLASS-EXP

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# bandwidth remaining percent 1

! The SP-SCAVENGER-EXP class will receive 1% bandwidth remaining

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# class class-default

RP/0/RP0/CPU0:CRS-3(config-pmap-c)# bandwidth remaining percent 27

! This section applies the eight-class interface QoS policy map to a

! core-to-edge (P-to-PE) interface in both directions

RP/0/RP0/CPU0:CRS-3(config)# interface TenGigE 0/1/0/2

RP/0/RP0/CPU0:CRS-3(config-if)# service-policy input SP-EIGHT-CLASS-EXP-QUEUING

RP/0/RP0/CPU0:CRS-3(config-if)# service-policy output SP-EIGHT-CLASS-EXP-QUEUING

! This section applies the eight-class interface QoS policy map to a

! core-to-core (P-to-P) interface in both directions

RP/0/RP0/CPU0:CRS-3(config)# interface HundredGigE 0/1/1/0

RP/0/RP0/CPU0:CRS-3(config-if)# service-policy input SP-EIGHT-CLASS-EXP-QUEUING

RP/0/RP0/CPU0:CRS-3(config-if)# service-policy output SP-EIGHT-CLASS-EXP-QUEUING

可以使用如下命令来检验例34-8中的配置。

■ show class-map reference list

■ show policy-map pmap name

■ show policy-map interface

■ show qos interface interface w/x/y/z output

34.4 总结

本章一开始就明确了一个概念，即服务提供商核心路由器上的QoS设计方案，主旨是为了解决在内部或接口发生拥塞时如何防止数据包丢失的问题。而Cisco CRS-3 路由器正是专门为解决这一问题而研发出来的平台。

本章对CRS-3路由系统的内部硬件架构进行了一个简要的介绍，说明了哪些内部成份可以应用QoS策略，以及它们应用QoS的机制。此后，本章讨论了管理（入站和出站）接口QoS策略和内部矩阵QoS策略的方法，其中特别强调了矩阵QoS策略能够控制（或覆盖）入站接口QoS策略（前提是在两者相互冲突的情况下）。

接下来，在现有知识的基础上，本章介绍在以下各类SP模型中，配置矩阵QoS和接口QoS策略的方法:

■ 4-CoS的SP模型；

■ 6-CoS的SP模型；

■ 8-CoS的SP模型。

34.5 扩展阅读

Cisco IOS XR Modular Quality of Service Configuration Guide for the Cisco CRS Router, Release 4.3.x （Cisco CRS 路由器的IOS 模块化QoS 配置指南，4.3.x 版）:http://www.cisco.com/en/US/docs/routers/crs/software/crs_r4.3/QoS/configuration/guide/b_QoS_cg43xcrs.html

第35章 MPLS VPN QoS设计的案例研究

Tifosi 公司现已决定进行网络迁移，使用3 层的MPLS VPN 连接它们的总部网络和分支机构，这样做一方面是为了节约成本，同时也是为了全部（包括LAN和WAN环境）使用吉比特以太网接口来实现网络互联。

Tifosi 公司将延用Cisco ASR 1000 系列路由器（每台设备均配有ESP-20 和SIP-10）来连接公司主干园区网和MPLS VPN服务供应商。同样，他们也将继续以Cisco 3925E ISR G2路由器或Cisco 3945E ISR G2路由器充当用户边界路由器，用来将分支网络连接到MPLS VPN。

这家公司现已决定使用Maranello Networks 公司（他们本地的服务供应商）的一个六层CoS模型，通过这个模型，客户可以以5%作为递增值，为每个类分配不同比例的带宽。然而， Maranello Networks 会对高优先级的服务类别收取额外的带宽费用。

鉴于高优先级服务类别需要额外付费，Tifosi决定在一个非高优先级服务类别中，通过MPLS VPN 来传输Cisco TelePresence（网真）的流量（网真流量在这家公司的私有网络中属于实时互动应用类），因为这样做更加经济实惠，而且数据流的质量也有保障。

Tifosi 公司应用的QoS 策略与Maranello Network 的MPLS VPN 中应用的QoS 策略如图35-1所示。

Tifosi 的MPLS VPN 客户边界路由器QoS 策略包括以下几点。

■ 策略1:CE路由器的入向QoS（CiscoASR1000）:在GE接口启用基于SPA的PLIM。

■ 策略2:CE路由器的局域网边界QoS策略:在入站方向上执行NBAR2协议分类技术。

■ 策略3:CE路由器的VPN边界QoS策略:

■ 在入站方向上执行NBAR2协议分类技术（将任何重标记过DSCP值恢复为原始的标记值）；

■ 在出站方向上使用一个8类的队列模型（包括将企业私有的服务类别映射为服务供应商的服务类别）。

■ 策略4:PE 路由器的内部QoS（Cisco ASR 9000）:提供矩阵接口ASIC 以及虚拟出站队列策略。

图35-1 Tifosi Software公司案例研究:MPLS VPN网络的QoS设计

■ 策略5:PE路由器的客户边界QoS:

■ 在入站方向上提供包含短管道模式（Short Pipe Mode）限速策略的6-CoS SP模型；

■ 在出站方向上提供整形技术套嵌短管道模式队列策略的6-CoS SP 模型。

■ 策略6:PE 路由器的核心边界QoS:在出站方向上执行（基于MPLS EXP 的）6-CoS队列机制。

■ 策略7:P 路由器的内部QoS（Cisco CRS-3）:矩阵QoS 策略。

■ 策略8:P路由器的接口QoS:在出站方向上执行（基于MPLS EXP的）6-CoS队列机制。

下面我们对这些策略依次进行说明。

35.1 策略1:CE路由器的入向QoS（Cisco ASR 1000）

在Cisco ASR 1000 路由器的GE 接口（连接园区网与MPLS VPN 的接口）上，启用基于SPA 的内部PLIS QoS 策略；这里不需要再使用基于SIP 的PLIM 策略，因为所有以太网接口都使用了基于SPA的PLIM策略。

Tifosi基于SPA的PLIM策略与例30-2所示的策略相同。

注释:为免骗取稿酬之嫌，在前文中设计方案或案例研究中已经出现过的配置方案，若在后文中重复出现，后文均直接提供前文的案例编号，具体配置信息不再赘述。

35.2 策略2:CE路由器的局域网边界QoS策略

CE的局域网边界QoS策略会在入站方向信任DSCP值（这是Cisco IOS默认的），并通过NBAR2对信息执行深度数据包监控。Tifosi公司局域网边界的入站QoS策略与例30-3中相同。

35.3 策略3:CE路由器的VPN边界QoS策略

Tifosi此前曾根据自己的私有WAN/分支网络边界模型，购买了相应的带宽。现在，他们必须将自己的8类企业模型映射为服务提供商的6类模型。要做到这一点，他们决定将自己的实时互动类与信令类这两个服务类型进行组合（因此，他们需要将信令流量重新标记为CS4）。此外，他们的大数据类与清道夫类也需要进行组合（不过组合这两个服务类别倒是不需要重新标记某类流量）。此外，为了让多媒体会议类流量能够拥有自己的（不同于实时交互类流量的）CoS值，还需要对多媒体会议类流量进行重标记（从AF41到AF31）。

对于穿越了MPLS VPN 的流量，为了恢复它们的标记，Tifosi 选择在VPN 边界的入站方向上，应用同样的NBAR2局域网边界策略。

当流量通过MPLS VPN 时，实时互动服务类的流量会以非优先服务的方式接收处理。但是在客户边界路由器上，Tifosi公司为这一类别的流量保留了优先服务的处理方式。

次后，在执行了50Mbit/s的整形策略后，Tifosi还为流量嵌套了队列策略。由于Tifosi并不知道服务供应商在PE入站方向设置的限速，突发值到底是多少（Maranello拒绝透露这些信息，他们称这是企业内部信息），因此Tifosi以10毫秒作为时间间隔，对VPN访问GE链路进行整形。

图35-2 所示为在CE VPN 边界，Tifosi 的企业到服务供应商的映射关系。

图35-2 Tifosi Software公司案例研究:CE VPN边界的企业到SP映射

例35-1所示为相应的配置。

例35-1 Tifosi Software公司案例研究:CE VPN边界的QoS策略

! This section configures the DSCP-matching class maps

! for the Tifosi eight-class VPN-edge egress policy

ASR1K/ISR-G2(config-cmap)# class-map match-all VOICE

ASR1K/ISR-G2(config-cmap)# match dscp ef

ASR1K/ISR-G2(config-cmap)# class-map match-all REALTIME-INTERACTIVE

ASR1K/ISR-G2(config-cmap)# match dscp cs4

ASR1K/ISR-G2(config-cmap)# class-map match-all SIGNALING

ASR1K/ISR-G2(config-cmap)# match dscp cs3

ASR1K/ISR-G2(config-cmap)# class-map match-all MULTIMEDIA-CONFERENCING

ASR1K/ISR-G2(config-cmap)# match dscp af41

ASR1K/ISR-G2(config-cmap)# class-map match-all TRANSACTIONAL-DATA

ASR1K/ISR-G2(config-cmap)# match dscp af21

ASR1K/ISR-G2(config-cmap)# class-map match-all BULK-DATA

ASR1K/ISR-G2(config-cmap)# match dscp af11

ASR1K/ISR-G2(config-cmap)# class-map match-all SCAVENGER

ASR1K/ISR-G2(config-cmap)# match dscp cs1

! This section defines the eight-class VPN-edge egress policy

ASR1K/ISR-G2(config-cmap)# policy-map VPN-EDGE

ASR1K/ISR-G2(config-pmap)# class VOICE

ASR1K/ISR-G2(config-pmap-c)# priority percent 10

ASR1K/ISR-G2(config-pmap-c)# class REALTIME-INTERACTIVE

ASR1K/ISR-G2(config-pmap-c)# priority percent 23

ASR1K/ISR-G2(config-pmap-c)# class SIGNALING

ASR1K/ISR-G2(config-pmap-c)# bandwidth percent 2

ASR1K/ISR-G2(config-pmap-c)# set dscp cs4

ASR1K/ISR-G2(config-pmap-c)# class MULTIMEDIA-CONFERENCING

ASR1K/ISR-G2(config-pmap-c)# bandwidth percent 10

ASR1K/ISR-G2(config-pmap-c)# set dscp af31

ASR1K/ISR-G2(config-pmap-c)# fair-queue

ASR1K/ISR-G2(config-pmap-c)# random-detect dscp-based

ASR1K/ISR-G2(config-pmap-c)# class TRANSACTIONAL-DATA

ASR1K/ISR-G2(config-pmap-c)# bandwidth percent 25

ASR1K/ISR-G2(config-pmap-c)# fair-queue

ASR1K/ISR-G2(config-pmap-c)# random-detect dscp-based

ASR1K/ISR-G2(config-pmap-c)# class BULK-DATA

ASR1K/ISR-G2(config-pmap-c)# bandwidth percent 4

ASR1K/ISR-G2(config-pmap-c)# fair-queue

ASR1K/ISR-G2(config-pmap-c)# random-detect dscp-based

ASR1K/ISR-G2(config-pmap-c)# class SCAVENGER

ASR1K/ISR-G2(config-pmap-c)# bandwidth percent 1

ASR1K/ISR-G2(config-pmap-c)# class class-default

ASR1K/ISR-G2(config-pmap-c)# bandwidth percent 25

ASR1K/ISR-G2(config-pmap-c)# fair-queue

ASR1K/ISR-G2(config-pmap-c)# random-detect

! This section configures the hierarchical shaper

! with nested queuing policy

ASR1K/ISR-G2(config-pmap)# policy-map CE-EDGE-SHAPING

ASR1K/ISR-G2(config-pmap)# class class-default

ASR1K/ISR-G2(config-pmap-c)# shape average 50M 500K

ASR1K/ISR-G2(config-pmap-c)# service-policy VPN-EDGE

! This section applies the sub-line-rate shaper to an ASR CE VPN edge

ASR1K(config)#interface GigabitEthernet0/0/2

ASR1K(config-if)# service-policy input LAN-EDGE

! The (NBAR2) LAN-EDGE policy is shown in Example 30-3

ASR1K(config-if)# service-policy output CE-EDGE-SHAPING

! This section applies the sub-line-rate shaper to an ISR CE VPN edge

ISR-G2(config)#interface GigabitEthernet0/2

ISR-G2(config-if)# service-policy input LAN-EDGE

! The (NBAR2) LAN-EDGE policy is shown in Example 30-3

ISR-G2(config-if)# service-policy output CE-EDGE-SHAPING

35.4 策略4:PE路由器的内部QoS（Cisco ASR 9000）

在Cisco ASR 9000 PE 路由器上，不需要管理员手动配置任何内部QoS 策略。不过ASR 9000 的IOS XR 系统将自动为矩阵接口ASIC 和虚拟出站队列设置（与接口的QoS 策略相对应的）内部队列策略。

在这个案例里，例34-2中的SP-REALTIME类会在内部节点获得严格优先级服务；而所有其他类型的流量则会获得默认的服务。

35.5 策略5:PE路由器的客户边界QoS

PE边界将会配置一个6类短管道模式的入站限速器（与例33-10中配置的6类管道模式入站限速器相同）。

PE 出站方向的策略是:Maranello Networks 在50Mbit/s 的协定速率整形器（contracted-rate shaper）内嵌套了一个6类的短管道队列模型。

例35-2所示为入站和出站策略的详细配置方法。

例35-2 Tifosi Software公司案例研究:Maranello Network的PE边界（面向客户一端）QoS策略

! This section configures the Short Pipe Mode six-class

! egress queuing policy map

RP/0/RSP0/CPU0:ASR9K(config)# policy-map SP-SIX-CLASS-SHORT-PIPE

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-REALTIME

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# priority

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class SP-AF4-CLASS

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 28

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# random-detect dscp-based

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class SP-AF3-CLASS

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 11

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# random-detect dscp-based

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class SP-AF2-CLASS

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 28

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# random-detect dscp-based

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class SP-AF1-CLASS

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 5

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# random-detect dscp-based

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class class-default

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 28

! This section configures the shaper policy map

RP/0/RSP0/CPU0:ASR9K(config)# policy-map SP-SHAPER-50M

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class class-default

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# shape average 50M 500K

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# service-policy SP-SIX-CLASS-SHORT-PIPE

! This section attaches the policy to the PE-to-CE interface

RP/0/RSP0/CPU0:ASR9K(config)# interface GigE 0/2/0/0

RP/0/RSP0/CPU0:ASR9K(config-if)# service-policy input SP-SIX-CLASS-INGRESS-MODEL-SHORT-PIPE

! This policing policy is identical to Example 33-10

RP/0/RSP0/CPU0:ASR9K(config-if)# service-policy output SP-SHAPER-50M

35.6 策略6:PE路由器的核心边界QoS

在PE 边界的入站方向对流量实施了限速后，流量会被转发到核心并根据Maranello 本地的MPLS EXP 标记进行列队，如例35-3 所示。

例35-3 Tifosi Software公司案例研究:Maranello Network的PE边界（面向核心一端）QoS策略

! These class maps for this six-class MPLS EXP-based queuing policy

! are identical to those detailed in Example 33-11

! This section configures Maranello Networks's

! six-class EXP-based queuing policy map

RP/0/RSP0/CPU0:ASR9K(config)# policy-map SP-SIX-CLASS-EXP-QUEUING

RP/0/RSP0/CPU0:ASR9K(config-pmap)# class SP-REALTIME-EXP

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# priority

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class SP-AF4-CLASS-EXP

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 28

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class SP-AF3-CLASS-EXP

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 11

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class SP-AF2-CLASS-EXP

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 28

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class SP-AF1-CLASS-EXP

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 5

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# class class-default

RP/0/RSP0/CPU0:ASR9K(config-pmap-c)# bandwidth remaining percent 28

! This section applies the service policy to the PE-to-P interface

RP/0/RSP0/CPU0:ASR9K(config)# interface tenGigE 0/1/0/2

RP/0/RSP0/CPU0:ASR9K(config-if)# service-policy output SP-SIX-CLASS-EXP-QUEUING

35.7 策略7:P路由器的内部QoS（Cisco CRS-3）

Cisco CRS-3上需要配置一个与接口QoS策略相对应的矩阵QoS策略。Maranello Networks的6类服务供应商模型如例34-5所示。

35.8 策略8:P路由器的接口QoS

核心接口QoS 策略可参考例34-6 中的信息，唯一的不同是各个class map 中的所有match-all操作在CRS-3上都要替换为match-any操作。

35.9 总结

本章需要对Tifosi Software 的案例进行了研究，这家公司成功将自己的8 类端到端QoS 模型从私有的WAN 网络迁移到了一个MPLS VPN 网络中。同时，Tifosi 选择了本地服务提供商Maranello Networks 的6 类CoS 模型。

为了进行迁移，Tifosi需要在Cisco ASR 1000路由器和ISR-G2路由器上执行一些琐碎（但又十分关键）的配置变更——因为在这个案例中，上述设备充当了客户边界路由器的角色。这些变更主要是为了推翻先前的流量分类，建立从企业到运营商之间的分类映射关系，并在协定速率整形器中嵌套自己的队列策略。

为了便于读者更好地研究这个案例，本章还专门提供了Maranello Networks 对于MPLS VPN QoS 策略的相关配置。

35.10 扩展阅读

Classifying and Scheduling Packets for ASR 1000 Series:（ASR 1000系列设备对数据包的分类与调度） http://www.cisco.com/en/US/partner/docs/interfaces_modules/shared_port_adapters/configuration/ASR1000/ASRimpqos.html

Cisco IOS Release 15M&T:QoS Configuration Guide（Cisco IOS 15 M&T:QoS 配置指南）:http://www.cisco.com/en/US/docs/ios-xml/ios/qos/config_library/15-mt/qos-15-mt-library.html

Cisco ASR 9000 Series Aggregation Services Router Modular Quality of Service Configuration Guide, Release 4.3.x（Cisco ASR 9000系列集成服务路由器模块化的QoS配置指南，4.3.x）:http://www.cisco.com/en/US/docs/routers/asr9000/software/asr9k_r4.3/qos/configuration/guide/b_qos_cg43xasr.html

Cisco IOS XR Modular Quality of Service Configuration Guide for the Cisco CRS Router, Release 4.3.x（Cisco CSR 路由器Cisco IOS XR 系统的模块化QoS 配置指南）:http://www.cisco.com/en/US/docs/routers/crs/software/crs_r4.3/qos/configuration/guide/b_qos_cg43xcrs.html

第8部分 IPSec QoS设计

第36章 IPSec VPN QoS的注意事项与建议

近年来，与IPSec相关的技术已经成为了绝大多数IP网络的基本标准和组成要素，并在整个行业中得到了广泛应用。在很多地方，都不难发现IPSec虚拟专用网络（VPN）的踪迹，例如站点到站点间数据中心的互连，星形拓扑中大量远程节点与总部进行远程连接，家庭用户进行远程访问等环境。事实上，能够使用IPSec VPN 的环境多如牛毛。

当然，除了IPSec之外，还有很多创建VPN的方法，例如2层城域网的QinQ隧道、2层和3 层的MPLS VPN，以及使用传统协议的专线。VPN 技术是十分广泛的。但IPSec 提供了一个集安全、简便、灵活为一体的部署模式。同时，无论网络规模有多大，低廉的成本也是吸引网络工程师部署IPSec的一大成因。

在使用一个需要通过QoS（服务质量）来提供支持的实时应用程序时，部署IPSec VPN 还要考虑如下问题:

■ IPSec VPN 的拓扑；

■ IPSec 数据包的QoS 分类；

■ IOS预分类特性；

■ MTU的注意事项；

■ 对VPN传输的数据进行分类；

■ 防重放的注意事项。

36.1 IPSec VPN 拓扑

建议:

■ 理解不同的VPN拓扑结构，尤其是QoS对于数据包封装的影响。

IPSec技术最具吸引力的特性在于，它对于不同的网络拓扑都具有很强的适应性。如今最常使用的IPSec VPN 架构包括:

■ 标准的IPSec VPN；

■ GRE结合IPSec；

■ 远程接入VPN；

■ 对VPN架构进行隧道封装（例如DMVPN和FlexVPN）；

■ 无隧道的VPN（例如GETVPN）。

下面我们将对上述列表的前三种VPN架构进行讨论，DMVPN和GETVPN则会在后面的章节中进行讨论。

36.1.1 标准的IPSec VPN

标准的IPSec是所有VPN拓扑中最传统的，无论Cisco还是其他厂商的产品都广泛支持这类技术。标准的IPSec可以使用在点到点和点到多点的拓扑中，具体还要根据所使用的前端设备进行决定。标准的IPSec VPN 分为两个不同的模式:隧道模式和传输模式。

1.隧道模式

Cisco IOS 路由器默认的IPSec 模式是隧道模式。在隧道模式下，IPSec 会对整个IP 数据包提供保护，这就是说，VPN的发送方路由器会对整个原IP数据包进行加密，并在数据包中添加一个新的IP头部。隧道模式是部署IPSec时非常受欢迎的一种部署方式，因为这种模式支持各类路由协议（如开放式最短路径优先[OSPF]协议和中间系统到中间系统[IS-IS]协议）。在VPN隧道之上运行内部网关协议（IGP）的关键需求是支持组播，这是IPSec隧道模式的关键特征。图36-1所示为一个IPSec隧道模式的数据包结构。

图36-1 使用ESP的IPSec隧道模式IP数据包

2.传输模式

传输模式是部署IPSec时，非常常用的一种模式，这一模式通常用来加密P2P的连接。与隧道模式不同的是，传输模式不会将原始的数据包嵌套在一个新的数据包中。在IPSec传输模式下，设备只会对IP数据包的有效载荷进行加密，同时保留整个原始的IP数据包头，并将其复制到新的IPSec数据包外部。因为传输模式保留原始数据包头不动，所以传输模式无法同某些IP服务结合起来使用，（如组播或者其他依赖于组播的路由协议[如OSPF和EIGRP]）。举个例子来说，传输模式通常会与通用路由封装协议（GRE）一起使用，其中IPSec会对整个GRE隧道进行加密（后文会对此进行详细的介绍），图36-2所示为IPSec传输模式的数据包结构。

图36-2 使用ESP的IPSec传输模式IP数据包

36.1.2 GRE IPSec

如今，很多的网络都在使用通用路由封装协议（IP协议号47），以便连接不同网络的VPN服务。例如，GRE就是VRF-Lite的核心组成成份之一，这项技术可以让运行在不同路由器上的相关VRF（虚拟路由与转发）实例通过IP网络建立连接，同时让这些VRF与全局路由表和其他VRF之间相互分离。在上述环境中，GRE会将每个IP数据包都封装进一个新的IP数据包中，并产生一个新的IP数据包头部。相比于通过部署新的MPLS网络来连接VRF的方法，这种方式省时省力，因此被称为VRF-Lite（VRF精简版）。

由于GRE可以承载非IP协议的流量，因此GRE还有另外一类使用环境（如IPX或DECnet）。虽然这类场合越来越少见，但是如今还是有很多网络仍在使用非IP协议（因此这些网络也需要利用GRE）。除了这些基本的功能外，在其他一些场合中，GRE也可以用来将一些分散的网络通过IP云连接起来。

当人们以GRE作为一项VPN技术或隧道技术时，他们常常希望能够对GRE隧道中的流量进行加密，以确保连接的私密性与真实性。将GRE与IPSec隧道模式或者传输模式进行整合一直是讨论的焦点。其中有一点因素不容小觑，那就是隧道模式会使数据包的尺寸增加20个字节。从本质上讲，对于GRE over IPSec的环境中，既可以使用传输模式也可以使用隧道模式。但传输模式存在的几点限制也必须考虑在内。例如，如果加密隧道需要经过NAT（网络地址转换）或PAT（端口地址转换），那就只能使用隧道模式。

正因为IPSec 和GRE VPN 拓扑都使用了新的数据包头部，所以QoS 的分类方式有别于常规QoS 数据包的分类方式。图36-3 所示为GRE over IPSec 环境中的数据包结构。

图36-3 用IPSec加密的GRE数据包

36.1.3 远程接入VPN

Cisco 主要的VPN 远程接入VPN 客户端是AnyConnect Secure Mobility Client，该客户端支持IPSec和SSL（安全套接字）加密。很多前端设备都支持AnyConnect客户端，如ASA防火墙（自适应安全设备）和ISR（集成服务路由器）。从客户端的角度来看，AnyConnect支持Windows、Mac OS X、Linux、iOS、Android、谷歌Chrome 以及其他许多平台。

虽然AnyConnect不支持任何QoS分类、列队以及限速工具，但它拥有一项重要的功能，可以在用户使用实时应用时显著提升他们的体验质量。这项功能称为数据传输层安全（DTLS）。在讨论DTLS的工作原理之前，读者应该首先了解一下DTLS主要能够解决哪些应用性能方面的问题。

通过AnyConnect建立安全的SSL连接时，客户端会向远程站点的前端设备（如ASA防火墙）建立一条基于TCP的SSL连接。这也就意味着所有来自客户端的流量（包括语音、视频、数据流量）都会通过SSL TCP 连接进行传输。但是，如果有基于UDP 的实时应用也通过这条TCP隧道进行传输的话，实时应用的性能就会大打折扣。

TCP的工作方式是使用滑动窗口机制来确保远端站点可以正确地接收到数据。现在，如果（由于数据包丢失）接收方的主机并没有正确接收到滑动窗口内的某个数据包，那么连接就会被暂停，而接收方则会要求发送方重新发送丢失数据包所在窗口内的整端数据。一旦接收方成功接收了数据包，下一个数据包就会进行发送。

随着数据应用的发展，所有由于“网络事件”所丢失的数据都能以非常快捷的方式进行恢复。只可惜这种方法这并不适用于实时应用。若将一个基于UDP的实时应用封装进TCP隧道，那么哪怕只有一个数据包丢失，整个会话都会被暂停，这会导致实时应用出现严重的延迟。如果如果这是一个视频通话，那么只要数据包有半点丢失，整个视频会话就会不断的暂停与启动，视频质量让人不忍卒视。

AnyConnect中的DTLS提供了一种方法，可以优化对延迟敏感的流量（如VoIP和视频流量），因此DTLS可以克服这一问题、改善实时应用的性能。与普通的SSL连接不同的是， DTLS是一项数据报技术，也就是说这项技术使用的是UDP数据包而不是TCP数据包。

AnyConnect客户端的DTLS工作方式如下:当AnyConnect第一次连接前端设备时，它们之间会建立起一条基于TCP的SSL隧道。一旦SSL会话完全建立起来，客户就会协商出一条新的、基于UDP的DTLS隧道，这条隧道的作用纯粹是为了传输实时应用。DTLS的UDP特性保障了RDP语音和视频数据包可以畅通无阻地进行传输。即使出现了突发的数据包丢失情况或意外的网络事件，会话也不会暂停，丢失的数据包也不会重新发送。相反，下一个数据包会继续正常传输，给用户提供更加流畅的语音和视频体验。

如何发送数据包是动态决定的，这也就意味着使用哪条隧道发送数据包也是不确定的。在处理完每一个数据包后，AnyConnect 应用就会决定是使用常规的TCP SSL 隧道还是使用DTLS隧道。因此，AnyConnect可以根据每一刻所发送的流量类型来动态选择所使用的隧道类型。如果将AnyConnect与语音、视频或其他实时应用结合起来使用，就可以大大提升用户的整体体验。

36.2 IPSec数据包的QoS分类

建议:

■ Cisco VPN 路由器默认会自动将ToS 字节从内部数据包复制到VPN 数据包头部，读者应该理解路由器的这项默认的功能。

正如本书此前反复讨论过的那样，QoS分类是匹配数据包TCP/ IP头部中某个或某些字段，并据此将数据包分为不同的流量组或流量类的过程。借助数据包分类技术，管理员可以将网络流量划分为不同的优先级或着服务类别。正如前面的章节中所介绍的那样，QoS分类主要是通过匹配服务类型（ToS），尤其是差分服务代码点（DSCP）的标记来实现的。不过，如果通过IPSec对流量进行了加密，问题就出来了。如果一个IP数据包通过IPSec进行了加密，那么整个数据包（包括原数据包的头部）就都被加密了，因此任何QoS机制也就都无法针对原数据包来使用。事实上，由于IPSec的加密，路由器甚至完全搞不清原始数据包的头部是从哪里开始，在哪里结束的。

为了解决这个问题，Cisco路由器会在默认情况下，从原IP数据包中将对ToS字段进行复制，并将其写入到新的IPSec头部中，让设备仍然可以通过匹配DSCP值来对数据包进行分类。这项功能最大的好处在于它是自动进行的，不需要进行任何人工的配置。

GRE封装的情况与之类似。Cisco路由器会在默认情况下动态将原始IP数据包中的ToS字段复制到GRE数据包的IP头部中。如果GRE数据包通过IPSec进行了加密，那么ToS字段还会继续自动从GRE数据包复制到IPSec数据包的头部中，这也就意味着原ToS字节会被复制两次。图36-4所示为IPSec加密GRE数据包的过程。

图36-4 IP ToS字节的保留

注意，只有ToS字段会被复制到GRE或IPSec头部中，原IP头部的其他任何字段都享受不到这种待遇。可以想见，在某些情况下，人们可能希望根据一些IP数据吧头部中的其他一些信息来对数据包进行分类（如源IP、目的IP、端口号、标志位等）。但由于IOS默认只会将ToS字段复制到新的IPSec头部中，因此必须有另外的机制来满足通过其他字段来执行QoS分类的需求。

36.3 IOS预分类特性

建议:

■ 在使用除ToS字段之外的信息时，要注意QoS分类的限制；

■ 对于所有使用非ToS字段执行QoS分类的情形，应使用IOS预分类功能；

■ 最佳做法是对所有VPN连接启动该特性。

预分类特性已经作为一种“专为VPN研发的QoS”特性，写进了Cisco的IOS文档之中。于是有人误认为，在针对所有IPSec 或GRE VPN 连接使用任何QoS 机制之前，都要先启动该功能。正如前文所述，这种看法有失偏颇。在前文中，本书已经介绍过，IOS在默认情况下会将ToS字段复制到一个新的IP头部中，这是为了让设备能够正确地基于DSCP执行分类，而实现这个功能并不需要为IPSec和GRE进行什么特殊的配置。不过，要是想根据IP头部中的其他字段（如源或目的IP、TCP或者UDP端口号、标志位等等）对数据包进行分类，就要使用IOS预分类特性了。

在默认情况下，IOS会在执行QoS分类之前，先对数据包进行加密，如图36-5所示。

图36-5 正常操作顺序

而预分类功能则反其道而行之，让设备在对流量执行隧道封装和加密之前，先对数据包进行分类，如图36-6所示。

图36-6 预分类特性如何影响操作的顺序

从技术上来说，设备的操作顺序实际上并没有改变。不过从使用预分类特性的角度上看，不妨认为设备的操作顺序出现了变化。实际上，设备只是对原始数据包的头部进行了复制，并将它保存在了路由器的内存中，这也就是为什么QoS分类程序可以在对数据包执行隧道封装和加密后还能使用这些信息。图36-7显示了如何复制原始数据包头部，并在执行分类时使用这些信息。

图36-7 预分类特性的操作

这里有一点必须强调，预分类功能只能应用在加密路由器的出站接口（物理接口或隧道接口）上。因为只有对流量进行加密的路由器才会去复制原始数据包，也就是说该路径中的任何下游路由器都不能根据ToS字段以外的其他信息进行QoS分类。这是因为QoS是基于每一跳（PHB）进行部署的，若两个加密点之间的路由器需要根据ToS字段之外的信息来执行QoS分类，就有可能会出现问题。

因此，最好在VPN路由器上统统启动预分类特性，哪怕管理员只要求这台设备基于ToS字段来执行QoS分类，也应启用这一特性——这条建议具有普世价值。因为通过这种方式，即使QoS策略在日后发生了变化（需要这台设备根据IP头部中的其他字段执行分类），这个网络也不会因为管理员忘记输入这条命令而产生问题。此外，测试结果表明，预分类特性对路由器整体的性能影响极其小，因此上述建议并没有性能上的后顾之忧。

对于IPSec 隧道来说，pre-classify 这条命令应该应用在crypto mao 中以便该配置针对每一条隧道都发挥作用。通过这种方式，在配置了crypto map的物理接口上所使用的QoS 特性（如整形、限速、队列与WRED），就都可以根据所需的字段，对数据包进行分类了。

对于GRE隧道来说，pre-classify命令的工作原理同IPSec隧道一样，路由器复制原始的IP数据包头部，将其应用到新的GRE数据包之中。在GRE隧道环境中，命令pre-classify需要在隧道接口中应用。

例36-1展示了预分类特性在IPSec隧道中的应用。

例36-1 在IPsec隧道上使用预分类特性

crypto map MYMAP 10 ipsec-isakmp

set peer 10.1.1.1

set transform-set MYSET

match address ACL

qos pre-classify

!

interface FastEthernet 0/0

ip address 10.1.1.100

crypto map MYMAP

例36-2展示了如何在GRE隧道中启动QoS预分类功能。

例36-2 在GRE隧道上使用预分类特性

interface Tunnel500

ip address 192.168.1.0 255.255.255.252

qos pre-classify

tunnel source 192.168.1.1

tunnel destination 192.168.2

!

interface FastEthernet 0/0

ip address 10.1.1.100

当然，在很多情况下，我们都需要对GRE隧道本身进行加密，并需要根据DSCP以及IP头部中的其他字段对流量进行分类。这是一个相当普遍的需求，因为这样做既可以发挥GRE的优势（即通过一个网络云来扩展虚拟网络），又可以对数据提供必要的加密。图36-8即为这一部署模型的示意图。

在这个例子中，读者很容易产生一个疑问:如果要使用pre-classify命令，应该在哪里配置这条命令呢？是在VPN的隧道接口还是执行加密的物理接口？在这类情况下，管理员应该既在物理接口配置这条命令，也要在隧道接口上进行配置这条命令，如例36-3所示。

图36-8 对GRE隧道进行IPSec加密

例36-3 在GRE over IPSec隧道上执行预分类

crypto map MYMAP 10 ipsec-isakmp

set peer 10.1.1.1

set transform-set MYSET

match address ACL

qos pre-classify

!

interface Tunnel500

ip address 192.168.1.0 255.255.255.252

qos pre-classify

tunnel source 192.168.1.1

tunnel destination 192.168.2

!

interface FastEthernet 0/0

ip address 10.1.1.100

crypto map MYMAP

36.4 MTU的注意事项

建议:

■ MTU问题会对用户体验VPN网络的连通性和质量造成严重影响，一定要认识到这一点；

■ 应使用本章所介绍的最佳做法来解决MTU的问题。

每当在一个网络中使用隧道技术时，总是存在某处路径可能会超过最大传输单元（MTU）的风险。事实上，除非端到端之间存在巨型帧，否则在任何一种VPN拓扑中，都要解决MTU的问题。

比如说，管理员经常会通过某个云网络（如Internet）来建立自己的IPSec/ GRE隧道。起初，他们发现一切正常。他们能够ping通对端，也能够通过VPN链路拨打IP语音电话（VoIP）。之后，他们突然发现，某些应用根本没有工作。Email、文件服务器连接和许多其他应用都没有工作，为什么ICMP（因特网控制消息协议）和VoIP都能很好的工作，这些应用却无法正常工作呢？这个问题可难倒了大多数网络管理员。经过进一步调查，他们发现原来是MTU的限制造成了这些问题。

36.4.1 GRE如何解决MTU的问题

当一个接近甚至到达最大MTU的数据包到达VPN路由器时，路由器会为原始的数据包封装一个新的头部，而这会增加数据包的体积。下面，我们通过案例说明，在使用基本GRE隧道时，MTU是如何导致连接问题的。

1.在本例所使用的网络中，MTU为1500字节。

2.用户通过网络发送了一个1500 字节的数据包（1460 字节的数据+20 字节的TCP 头部+20字节的IP头部）。

3.该数据包进入GRE 隧道。GRE 需要一个24 字节的头部，这也就意味着在进入GRE隧道前，原始数据包的MTU不能超过1476字节（1476+24=1500，1476字节就是物理接口的MTU）。

4.原始数据包已经超过了MTU的大小，所以路由器将尝试把数据包分为两部分。

5.路由器注意到原始数据包头部的DF 位是1（即该数据包不允许分片），这也就意味着该数据包不能分片（DF位由发送程序设置，并且大多数情况下DF位的值都是1）。

6.路由器没有办法，只好丢弃原始数据包。

恰如上例所示，在GRE环境中，1500字节MTU的限制会导致网络连接出现严重的问题。表面上看，解决之道似乎是提高所有网络接口的MTU值，使网络能够支持更大尺寸的数据包。遗憾的是，在MAC层，设备通常会将IP数据包处理为以太网数据帧，其最大尺寸为1518字节，所以这个解决办法是不可行的——当然，要是你的网络能够支持端到端的巨型帧，那就另当别论了。

36.4.2 IPSec如何解决MTU的问题

在大MTU的问题上，IPSec的做法与GRE不尽相同。IPSec会最多为原始数据包增加58字节，这明显超过了GRE的24个字节。当原始1500字节的数据包到达IPSec加密引擎时，它最多将增加到1558字节，因此必须在出站接口进行分片。下面我们通过案例解释IPSec是如何解决MTU问题的。

1.一台主机通过网络发送一个1500字节的数据包。

2.VPN 路由器接收数据包并对其进行加密，同时在原始IP 数据包的基础上添加了52 字节的头部（提示:增加58字节是最大值，增加52字节更为常见）。

3.数据包现在为1552字节，必须要分割为两部分。

4.另一端的IPSec 路由器接收到这两个数据段后，去除外部的IP 头部并将两个数据段进行重组。

5.IPSec在接收路由器上解密已经重组完成的数据包并将其发送给目的主机。

如上例所示，IPSec与GRE不同，IPSec有一个内置的机制来处理数据包超过MTU的情况。在IOS系统中，IPSec总是会为传输的数据及自己的控制报文执行路径MTU检测（PMTUD）。于是IPSec VPN 路由器就会知道，即使出站MTU 是可以接受的，沿途的路由器也有可能会出现问题，那么路由器就可以提前将数据包进行分片。即便原始数据包的DF位设置为1，IPSec机制仍可以忽略这一点，依然对数据包执行分片，因为IPSec机制很清楚另一端的设备会重组数据包。

那么，IPSec与GRE的不同之处到底在哪里呢？它们主要的不同在于，IPSec的接收路由器拥有重组原始IP数据包的能力，因此，IPSec可以将一个完整而没有分片的数据包发送给目的主机。而在纯GRE的环境中，哪怕VPN路由可以手动重写DF位的数值（如通过route-map），这两个GRE片段也永远无法在接收端的VPN路由器上进行重组，因此接收方主机也就很可能会丢弃这两个分片。

但总的来说，在使用IPSec时，也应该尽量避免分片的情况。虽然现在几乎所有的Cisco路由器都是采用基于硬件的加密特性，但数据包分片和重组毕竟也是数据交换这一处理过程中的一个步骤，换句话说，在发生分片和重组时，CPU将首当其冲面临严峻的考验。这样做相当于让路由器加密引擎的处理水准由硬件级别降低到了软件级别，因此必然会严重影响使用这台路由器的应用。

本书的主旨是QoS技术，因此不求尽数各类处理MTU问题的不同方式。严格来说，在统意义上，QoS与MTU之间也没有太大关系，但根据前面不难发现，MTU问题会对应用性能以及用户体验构成相当严重的影响。所以，网络工程师和网络管理员还是应该掌握对MTU所能造成的问题。在下一节中，本书将介绍如何处理因VPN头部而带来的大MTU问题。

36.4.3 运用TCP MSS调整特性

处理MTU 问题最常见的方式是使用IOS TCP MSS 调整特性。TCP 最大段大小（MSS）定义了主机在一个TCP/IP数据报中，所能接受的最大有效载荷数据。在两台主机之间建立TCP连接（TCP SYN）时，每一端都要将MSS 报告给对方。最终，发送主机端负责限制每个TCP段的数据报大小，使其小于等于接收端主机所报告的MSS。

MSS同MTU类似，但MSS指的是IP数据包中，实际的有效载荷数据部分，而MTU指的是整个IP数据包，其中包括了TCP头部和IP头部的尺寸。

例如，如果一个IP数据包的MTU是1500字节，那么这1500字节中一定包括20个字节的IP头部和20字节的TCP头部。因此，对于一个1500字节的数据包，它的MSS实际上只有1460字节，如图36-9所示。

图36-9 在TCP三次握手的过程中调整TCP会话的MSS值

在图36-9中，一台发送主机开始向一台MSS值为1460字节的主机建立TCP会话。此时，这台名为Madrid 的Cisco VPN 路由器并没有让接收主机方主动对消息作出响应（发送方和接收方都不知道流量会穿过一条IPSec/GRE隧道，因此这次通信有可能会遭遇MTU分片的问题），这台路由器拦截了TCP 会话，并在会话建立的通信（即TCP SYN）中插入了一个自己推荐的新MSS值——1378字节。由于这个MSS保证小于1500字节，因此流量通过VPN隧道时就不会被设备分片。此外，由于这个MSS比接收方本来应该予以响应的那个MSS值要小，因此双方协定以以这个值作为MSS 值，于是这个会话的TCP MSS 也就顺理成章地变成了1378字节。

在这种情况下，IOS 中的TCP MSS 调整特性可以让路由器在TCP 会话建立过程中充当中间人的角色，让它有机会修改两台设备之间的协定MSS值。于是，这台路由器也就能够改变协定的MSS值，成为了设置连接MSS值的实权人物，这也就避免了流量在穿越VPN隧道的过程中，TCP会话超过MTU值的问题。例36-4所示为在一台Cisco路由器上手动为所有穿越GRE隧道的TCP会话，设置MSS的方法。

例36-4 TCP调整MSS特性的配置

interface Tunnel500

ip address 192.168.1.0 255.255.255.252

ip tcp adjust-mss 1378

tunnel source 192.168.1.1

tunnel destination 192.168.2

!

为了解释清楚本例中，MSS值这个1378字节是怎么计算出来的，请看下面的计算过程。

■ 原始IP数据包=1500字节

■ IP头部占20字节=1480字节

■ TCP头部占20字节=1460字节

■ GRE头部占24字节=1436字节

■ IPSec最大为58字节=1378字节

在本例中，1378是最理想的MSS值，它可以避免数据包在添加GRE和IPSec头部的过程中，不知不觉超出字节限制的问题。有些工程师会常常会将MSS设置得更低，以便给数据包留出一些“富余量”，这可以由工程师自行决定。

关于TCP MSS 调整特性，还有一点十分重要，毋须谨记，那就是这个特性相当消耗路由器资源，因此可能会会对设备的整体性能构成显著影响，进而严重影响应用的性能。鉴于这项特性会对性能产生影响，建议在出现问题时再启动该功能。

由于调整MSS可以在TCP连接建立路径中的任意一点执行，而且也只需要在路径中的一处执行即可，因此没有必要在前端和远程站点中同时配置。实际上，最常见的建议是，只在远程站点的隧道接口配置这项特性，而不在前端设备上使用它。这么做的理由是，如果前端站点上汇聚了大量的隧道，存在大量的TCP 连接，那么让一台前端站点的设备通过TCP MSS 特性独立调整MSS值会对前端路由器的性能造成极大影响，因为每个新建的TCP会话都要通过前端设备的控制层进行处理。反之，如果将这个特性配置分配给各个在远程站点来完成，那也就等于将消耗CPU资源的任务分配给了所有这些远端路由器共同完成，因此可以降低了前端站点的负担。

读者还应注意，TCP MSS 调整功能只对TCP 流量起作用而对于UDP 流量不起作用。虽然在大型的MTU中很少看到UDP流量的身影，但这种风险依然客观存在。举例来说，Cisco视频编码有能力定制MTU，因此MTU有可能被设置得大到足以影响视频的性能。正如之前提到的，尽管在VPN链路中存在各种解决MTU问题的办法，但它们大多需要对数据包进行分片，而对于实时流量（如视频会议流量）分片的做法并不可取。为了保证视频的质量，最好在让视频会议设备穿越VPN隧道进行通信之前，先检查一下它们的MTU设置。

36.5 对VPN上的数据执行压缩

建议:

■ 如有可能，尽量在VPN连接中使用压缩策略来提升吞吐量和用户体验，并降低延迟；

■ 对那些会将用来执行QoS分类的字段进行封装和隐藏的WAN压缩技术，要留个心眼。

在设计两个站点间的IPSec VPN 时，有很多种方法可以降低整体的带宽。数据压缩可以提升网络的实际吞吐量，使其远高于VPN链路的理论带宽，而且这种做法也可以改善远距离VPN链路的延迟问题。

36.5.1 使用WAAS对TCP进行优化

Cisco广域应用服务（WAAS）极大提高了广域网VPN的用户体验。WAAS使用了大量的压缩技术，如LZ压缩、重复数据消除技术（DRE）以及特定应用优化器（AOS），这些技术都可以显著减少通过WAN或VPN发送的数据量。广域网加速技术（如WAAS和WAAS Express[一项IOS特性集，不需加装其他硬件或模块即可使用]）不仅可以提高链路的有效带宽，而且极大地提高了VPN的往返时间（RTT）的延迟。

下面以一个真实的Cisco WAAS 实施案例为例进行介绍。这是一家位于北美的计算机软件公司，每天需要向位于印度的远程分支机构备份75 GB 的数据。连接到印度的链路是T1， RTT为400毫秒。这家公司每日的备份工作往往都需要3天才能完成。在实施了WAAS后，第一次执行备份的时间从75小时下降到了15小时，随后每日备份只需要45分钟，这是由于WAAS有能力以字节或“块”为单位，高速缓存冗余数据。当然，对于像WAAS这种从加密连接中获取益处的技术，压缩必须在加密之前进行。

这类压缩技术可以大大提升用户体验。但WAAS这样的压缩技术也不是完美无瑕，它只能支持基于TCP的流量。在使用WAN压缩技术时，还有一点必须考虑在内，那就是WAN加速器本身不会对设备执行QoS 造成影响，这一点必须保证。例如，在使用Cisco WAAS 时，数据包中只有数据部分进行了压缩，因此原始ToS字节也就被保留了下来，当设备执行QoS分类时，可以查看并使用这个字段。必须指出，市面上的许多WAN加速解决方案都会对WAN加速器之间的所有流量统统执行隧道封装，其中包括原IP头部，而这会让QoS分类无章可循。

36.5.2 在VPN连接上使用语音编码器

WAN压缩技术（如WAAS）是解决TCP流量问题最好的工具，但它们并不能解决基于UDP的流量问题（如语音或视频流量）。

为了在带宽受限的VPN链接中提高整体的语音容量，管理员经常选择使用语音压缩编码器，如ILBC或G.729。

相比较而言，典型的G.711 编码器每路呼叫都会消耗80 kbit/s 的带宽，而一个G.729 编码器所需要的带宽则只有24 kbit/s。因此，与（没有使用任何压缩技术的）G.711编解码器相比，使用这种压缩策略的效果是，3倍数量的呼叫可以通过VPN链路进行传输。

虽然从表面上看，这非常吸引人，但在穿越原始网络（Internet）的VPN连接中上使用语音编解码器时必须格外注意。由于G.729是将大量语音数据压缩成较少的数据包，因此，在不可靠的网络上，使用这类编解码器会造成明显的丢包，例如Internet就会经常发生这种情况。为了克服这一问题，Cisco在G.729有一个内置了一个保护机制，以帮助解决这个问题。

下面解释一下G.729是如何弥补VPN链接丢包问题的。假如有4个经过了压缩的语音数据包正在通过VPN连接进行发送。由于一次意外的网络事件，其中一个数据包丢失。此时，接收端G.729解码器会执行一个特殊的隐藏策略，以隐瞒丢失了一个数据包的情况。比如说，如果丢失的是数据包队列中的第三个数据包，监听端会等待接收这个数据包，直到抖动缓冲器失效。同时，该解码器会重放第二个数据包以掩盖第三个数据包已经丢失的情况。解码器真正的目的是通过缩小数据包之间的间隔时间来欺骗监听端设备，虽然重放的数据并不是真正的第3个数据包。正是因为具有这项隐藏策略，G.729才能在整次会话中容忍平均多达5%的数据丢失。

近些年，涌现出了一个新的开源语音编码器，可以解决这些问题。这就是互联网低比特率编码器（iLBC），一项由Global IP Solutions（已被谷歌并购）开发并定义在RFC 3951 中的编解码器。iLBC提供了15.2kbit/s以及13.33kbit/s两种比特率，非常适合应用在有损的VPN链路上。在没有数据包丢失的情况下，iLBC编码器的比特率为15.2kbit/s，它提供的MOS（平均意见值）性能与G.729极为类似。而在出现数据包丢失（1%～10%）的情况下，iLBC的表现更加出色，图36-10展示了各种语音编码丢包的情况比较。

iLBC在CiscoIP电话以及网关之中得到了广泛的应用。

图36-10 各类编码的MOS打分与丢包率的对比

36.5.3 CRTP和IPSec的不兼容性

在处理加密方面，最大的问题（很可能也是唯一的问题）在于，执行QoS所需调用的原IP数据包头部也被加密成了乱码。如果没有（本章前文中介绍的）那些特殊IOS特性，VPN链路上根本就不可能执行QoS策略。压缩实时协议（cRTP）就要是一项必须能够看到原数据包的特性，因此cRTP与IPSec并不兼容。

了解IOS栈的操作顺序有助于解释这个问题。因为原RTP数据包是在加密之前先进行压缩的，因此不可能再压缩已经加密的数据包。所以，鉴于cRTP无法将已加密的RTP数据包与一个已知的媒体流之间建立关联，压缩根本不会发生，设备也没法执行cRTP。经过了加密的IP/UDP/RTP数据包会绕过加密进程，以未压缩的状态进入传输队列。

同样值得注意的是，cRTP功能是以跳为单位执行的，而IPSec经常横亘两个IPSec端点之间的多台中间设备。这种差异让这两种技术之间变得愈发不可调和。因此，不能将cRTP用于IPSec VPN 环境中，来节省网络带宽。

36.6 防重放的启示

建议:

■ 在启用了QoS 策略的IPSec VPN 网络中，防重放造成的丢弃可能会导致潜在的风险。

IPSec提供一个内在的消息完整性机制，以便识别数据包是否被拦截者或黑客进行了重复播放。这个概念称为无连接的完整性。IPSec也提供了部分序列完整性检测机制以避免接收重复的数据包。这些概念都在RFC2401，Security Architecture for the Internet Protocol中进行了概述。

当管理员在一个IPSec转换集中配置了ESP认证（esp-sha-hmac）后，接收方的IPSec对等体会检测各个SA（安全关联）中传输的数据包是否只接收到了一次。由于两个IPSec对等体之间可以发送成千上万的数据包，因此这里实施了一个64个数据包的滑动窗口，以限制对等体用于接收数据包时所使用的内存。数据包可以不依次到达，但是它们必须在可接受的窗口范围之内接收到。如果到达得太晚，就会被设备丢弃。

防重放窗口协议操作步骤如下。

1.发送方为加密的数据包分配一个（在其安全关联中）唯一的序列号。

2.接收方保持一个64 数据包的滑动窗口，该窗口的右边缘包含了已接收（数据包）的最高序列号。此外，接收方会通过一个布尔型变量表示当前窗口中每一个数据包是否均已收到。

3.接收方计算已收到数据包的序列号。

a.如果所接收数据包的序列号落在窗口内，并且之前没有接收过该数据包，设备就会接受这个数据包并将其标记为已接收状态。

b.如果所接收数据包的序列号落在窗口内，并且之前已经接收过该数据包，设备就会丢弃这个数据包并将重放错误计数器加1。

c.如果所接收的数据包序列号大于窗口的最高序列号，设备就会接受这个数据包并将其标记为已接收状态，同时该滑动窗口“向右”移动。

d.如果所接收的数据包序列号小于窗口的最低序列号，设备就会丢弃这个数据包并将重放错误计数器加1。

如果在收敛的IPSec VPN 环境中启动QoS，低优先级的数据包就会被推迟服务，以便给高优先级的数据包让位。从IPSec防重放序列号的角度来看，这样做的副作用在于需要对失序的数据包重新排序。因此，QoS有可能会因正常的QoS优先级操作，而将正常发送和接收的数据包当做重放数据包执行丢弃，这个担忧是合理的。

图36-11所示即为上述过程。在该例子中，设备接收到了序列号为4到67的语音数据包，但数据包3的发送却被推迟，并将其和语音包68一起发送。当反重放进程检查到数据包3时，这个数据包就会被丢弃，因为已将超出了滑动窗口的最左侧。数据包的接收可以是乱序的，但必须落在窗口的范围之内。

在纯IPSec 隧道的设计方案中（没有加密IP GRE 隧道）可以通过为语音、视频、数据分别创建相互分离的安全关联来消除防重放的影响。也就是说，语音、视频、数据必须与crypto map中所调用的不同行访问列表进行匹配。如果IP电话的网络编址与工作站是相互分离的（例如前者使用私有的RFC 1918 地址），这就很容易实现。

图36-11 反重放操作

想像一下丢包对于TCP应用的影响:TCP是面向连接的协议，协议中内置了流量控制机制。TCP应用并不明白数据包为何会丢失。从发送方主机的角度上想，在一个出现了拥塞的出站接口上应用的QoS策略丢弃了一个数据包，这和防重放造成的数据包丢失毫无分别。但从网络角度上看，在将数据包发送到WAN链路上之前（WAN的带宽是十分昂贵的，一定要在接收端的IPSec VPN 路由器上通过防重放机制丢弃数据包）就把它丢弃掉是一种更加高效的策略，但丢包的位置和原因对于TCP驱动来说无关紧要。

在经历持续的拥塞和队列满载的IPSec VPN 链路上，反重放的丢包率通常在1% ～1.5%之间（前提是没有其他策略参与）。

而在WAN接口出站方向上被丢弃的数据包则少到可以忽略不计，其数量显然比反重放丢弃的数据包要少得多。这是因为反重放所触发的丢包比出站方向的服务策略更多（后者视乎出站队列的尺寸，以及定义类别的数量而定）。

默认情况下，每个CBWFQ类接收一个长度为64数据包的队列。管理员可以通过show policy interface 命令来验证这一信息。同时，在接收端的IPSec 对等体上，（每个IPSec SA）有一个64数据包的反重放窗口来处理所有的延迟列队(LLQ)以及基于类的加权公平列队(CBWFQ)中的数据包。

这就解释了为什么接收端VPN路由器的防重放机制，在丢弃那些（因QoS机制优先处理VoIP数据而）被推迟发送的数据包时，比发送端的服务策略要积极得多。因为发送端出站接口的列队深度（每个接口上有多个64数据包的列队）与接收方防重放窗口的宽度（每SA 64 数据包的滑动窗口）不匹配。随着policy map 中定义的带宽类别越来越多，不匹配的程度也会逐步增加。正如之前所提到的那样，这样做浪费了昂贵的WAN/VPN带宽，因为通过WAN链路传输这些数据包所能得到的唯一结果，就是让它们在解密前即被丢弃。

每个CBWFQ队列64数据包的默认值被设计旨在吸收突发流量，以推迟发送而不是丢弃的方式处理这些突发的数据包。在没有使用IPSec的网络中，这是一种优化网络的手段。

注释:本书第37章会对在DMVPN环境中，为每个SA设计不同QoS策略的内容进行探讨。

通过在发送端出站服务策略中降低队列的数据包数量（max threshold），可以让设备更多地丢弃数据包，而不是将数据包缓存起来或者推迟发送，在网络中配置了IPSec认证（esp-sha-hmac）的环境中，这样做可以明显改善网络环境。大量测试结果显示，调整队列限制的做法可以将反重放丢包率由1%降至低于0.1%。这是因为减少服务策略队列限制的数量，可以让发送端的服务策略更加积极地丢弃数据包，而不是将数据包转发大幅度推迟（队列深度太深的效果就是数据包的转发大幅度延迟）。而这就可以降低因反重放而导致的丢包数量。可以将应用按照优先级降序排列，并依次降低其队列中的数据包数量，这是经验之谈。

注释:在很多网络中，默认的列队限制值与默认的IPSec防重放性能都是可以接受的。修改列队限制值可能会对QoS服务策略及相关的CPU性能造成负面影响。在启用列队限制时，一定要留意CPU的使用率。

注释:IOS还为QoS/IPSec的防重放问题提供了另一种补救措施，即拓展或者禁用IPSec防重放窗口。但要切记，在IETF IPSec标准定义的防重放窗口大小为64数据包，因此，上述解决方案并不符合工业标准。而上文中介绍的调整QoS队列限制的做法，是一项完全符合标准的解决方案。

36.7 总结

本章重点介绍了在VPN环境中部署QoS面临着哪些挑战，其中着重介绍了在IPSec和GRE网络中部署QoS策略所面临的挑战。本章一开始介绍了各个VPN的部署模型，同时解释了使用这些模型为何会影响设备在分类流量时查看数据包中的某些字段。当使用基于DSCP的分类时，IOS 默认会将ToS 字段复制到新的IPSec 头部中。不过，如果需要根据TCP/ IP 头部中其他字段执行数据包分类，就要使用QoS预分类特性来复制数据包的原始头部，这样才能通过原始头部中的其他字段对数据包进行分类。

当解决VPN的问题时，增加数据包头部可能会导致严重的MTU分片以及重组问题。此外，在设计VPN方案时，可以通过使用压缩技术（如使用WAAS，或合理选用语音和视频编码器）来提升用户体验。一定要注意cRTP和IPSec这两项工具互不兼容。IPSec防重放技术也带来了一些问题，QoS队列机制可能会将数据包重新排序，而貌似失序的流量有可能会被丢弃。

在接下来的三章中，本书的重点在于如何在某些特定的VPN拓扑中部署QoS，即DMVPN、GETVPN以及家用办公网络。

36.8 扩展阅读

《VoIP技术构架（第2版修订版）》Manoj Bhatia, Jonathan Davidson, Satish Kalidindi, Sudipto Mukherjee, James Peters著，高艳译，人民邮电出版社出版

iLBC freeware:http://ilbcfreeware.org/

第37章 DMVPN的QoS设计

动态多点VPN（DMVPN）是IPSec站点到站点VPN的一种重要实现方式。曾几何时，网络工程师和管理者所要面临的一项重大的挑战就是，如何便捷地拓展自己的VPN网络。因为，如果在大量分支路由器之间两两应用静态的点到点IPSec隧道，不仅前端路由器上的配置量会变得十分庞大，大到几乎无法管理，而且日常的网络维护工作也会因此而变得异常艰难。

试想，若一个拥有成千上万门店的大型零售企业想要通过公共的云网络连接到他们的总部或者数据中心，那么它们必须对穿越公共网络的数据进行加密。这种情况不仅需要管理大量的IPSec配置，更需要使用相当复杂的QoS机制。举例来说，零售商可能会从分支网络向总部网络发送各种各样不同类型的流量，其中包括语音流量、网页流量以及信用卡交易流量。在这种情况下，信用卡交易流量在传输过程中的安全性显然必须得到保障，同时这类流量在传输的过程中也需要借助一个复杂的QoS机制来为其提供服务，因为对于公司来说，及时处理这些信用卡交易的信息是很重要的。

如果管理员需要手动配置成百上千条点到点的隧道，还要在前端设备上为每一个隧道配置各自的QoS策略，哪怕他/她能保证自己的配置不会出错，如此浩大的配置工作也足以让人望而生畏。例如，将VPN端点配置为远端站点，这就需要在每个VPN隧道接口上手动配置IPSec 加密策略、安全用户文件（security profile）及服务质量（QoS）策略配置。此外，对这样的环境进行排错很可能会成为管理员的一场噩梦。

DMVPN在这方面具有明显的优势，它能够让管理员轻松地在前端路由器上部署大规模的VPN网络，并且能让管理员以极少的配置对不同隧道分别部署不同的QoS策略。DMVPN另一个吸引人的方面在于，它能够动态地建立分支站点到分支站点间的通信，而无需手动建立隧道。分支站点只需与中心路由器之间建立通信，通过中心路由器学习远端分支站点上使用的IP地址（也就是它希望与之进行通信的那个IP地址），两个分支站点之间就可以动态建立起一条新的VPN隧道，于是流量也就不必由中心路由器进行中转了。

在想要部署VPN的环境中，无论远程站点的数量屈指可数，还是不计其数，DMVPN都是一项极具吸引力的VPN技术。

DMVPN的另一项巨大的优势在于，它只会在前端路由器的接口上使用单个mGRE（多点通用路由封装协议），而并不使用大量独立的GRE隧道去连接每一台分支路由器。在传统的IPSec VPN 环境中，部署QoS 只有两种方法，要么在连接WAN 网络的物理接口上使用QoS policy map，要么在每个GRE 隧道接口上分别关联一个独立的QoS policy map。若采用第一种方式，那么这个面向WAN 网络的policy map 就会作用于全部的出站数据流，而无法对每台分支路由器（每个隧道）分别施以流量管理。第二种方式比第一种方式要好，但它的配置量过大，难于部署。举例来说，如果为每一个远程分支的路由器分别创建一个独立的VPN隧道，那么要想实现QoS 机制，就必须要在每一个GRE 隧道接口上应用专门的出站QoS policy map。因此这类网络的扩展性极差，毕竟大多数路由器的系统都会对管理员创建class map 或policy map的数量进行限制。

总之，就部署QoS而言，DMVPN架构拥有如下几大优势。

■ 可以降低中心路由器上的QoS总配置量。

■ 可以扩展为成千上万个站点，其中心路由器的每一个隧道都配独立的QoS策略。

■ 当网络中出现了新的分支路由器时，不需要为其在中心站点上执行任何QoS配置。

■ 可以灵活部署在分支站点到分支站点的模型中，以及总部到分支站点的模型中。

■ 大多数的企业级Cisco 路由器都支持这项技术（如ISR G2 路由器以及ASR 1000 路由器）。

本章将会探讨如下内容:

■ DMVPN网络中，QoS的作用；

■ DMVPN 的 QoS 架构；

■ DMVPN 的QoS 设计案例；

■ DMVPN 同FlexVPN QoS 模型的比较。

37.1 DMVPN网络中QoS的作用

DMVPN是当今使用最为广泛的VPN架构之一。目前，DMVPN已经成为了穿越不可靠网络（如Internet），部署站点到站点IPSec VPN 的一种黄金标准。

正如第36章中所介绍的那样，部署VPN的一项常见需求在于，要求该VPN网络能够支持动态路由协议（如开放最短路径优先协议[OSPF]和增强型内部网关路由协议[EIGRP]）和组播。因此，站点到站点VPN环境中经常会使用加密的GRE隧道。不过，如果将GRE和IPSec结合起来使用，配置的复杂程度就会显著提高，因此传统的静态站点到站点VPN隧道在扩展性方面难以为继。

37.1.1 DMVPN的构成

DMVPN将mGRE和IPSec加密与NHRP（下一跳解析协议）结合了起来，让管理员可以毫不费力地配置隧道端点，弹指间将分支站点的数量扩展到成千上万个之多。DMVPN的主要组成部分如下所示。

■ mGRE:mGRE可以让管理员在中心路由器上创建一个GRE隧道接口，来为大量的远端分支站点服务，而无需为每个隧道端点配置一个独立的GRE隧道接口（中心路由器的扩展性取决于具体的路由器平台）。通过部署mGRE隧道接口，管理员只需部署一个单一的出站QoS策略即可完成任务，再也不必在每一个静态GRE隧道端点上都配置QoS策略了。

■ IPSec隧道端点的动态发现与加密用户文件（crypto profile）:DMVPN 能够动态创建crypto map（加密映射），因此，管理员也就不必为每个隧道端点分别手动配置静态的crypto map 了。如果需要在DMVPN 环境中运用QoS 技术，这无疑是一大优势，因为这极大降低了IPSec的配置需求。

■ NHRP:通过NHRP，分支路由器可以使用动态配置的IP地址。换言之，远端路由器可以从本地运营商那里获取DHCP（动态主机配置协议）地址，并使用该地址与中心路由器建立连接。此外，NHRP是一个无需手动干预的部署模型，这也让DMVPN的配置和管理工作变得更加轻松。如果在DMVPN拓扑中使用NHRP技术，不妨将中心路由器视为一台“下一跳服务器”，而不是一台传统的VPN路由器。在本章中介绍的QoS特性（即以隧道为单位进行部署的QoS特性）中，NHRP也是一项十分重要的组成部分。在这个环境中，分支路由器向中心路由器通告要使用哪种QoS策略，也是通过NHRP机制来实现的。

37.1.2 如何在DMVPN中实施QoS

在上述三大组成部分的协同作用下，DMVPN网络可以迅速扩展到成千上万个远端节点，同时为各个分支站点提供QoS服务。

因为DMVPN是IP传输网络的一部分，所以从中心VPN路由器和分支VPN路由器的LAN接口接收到的所有数据包的DSCP值，默认都会获得信任。除非管理员确有理由不信任这个标记值，否则就不必在该网络节中的这个节点上对流量进行重标记。因此，在DMVPN拓扑中，QoS的主要功能就是在出站方向上，对某些穿越VPN隧道的流量实施分层整形和队列技术。

图37-1展示了在一个简单的DMVPN网络中，应该在何处实施QoS技术。

图37-1 在一个与3个远程站点通过IPSec和mGRE建立DMVPN的环境中实施QoS

37.2 DMVPN QoS 配置

DMVPN要依赖mGRE隧道接口，但在接口下，传统的QoS策略无法正常工作。为了解决这个问题，DMVPN提供了一种针对各个隧道分别提供QoS机制的特性。正如DMVPN本身需要依赖NHRP来发现端点，并执行路由转发一样，DMVPN网络中针对各个隧道的QoS机制也需要利用 NHRP 协议。这部分内容会在下面几节中进行详细介绍。

37.2.1 下一跳路由协议

在DMVPN的三大组成成份中，在分支站点之间动态创建全互联隧道，并为各个隧道提供QoS服务的特性就是NHRP。如图37-2所示，在最开始创建DMVPN时，每台分支路由器与中心路由器之间都都有一个永久的IPSec隧道。但在必要时，分支路由器也可以向其他分支路由器动态创建一条IPSec隧道。这样做的好处在于，当分支站点需要与其他分支站点进行通信时，进入中心站点的流量不必无功而返，因此这既可以提高中心路由器的性能，又可以减少分支路由器之间的往返时间（RTT）。

所以当一个分支路由器想要同其他分支路由器进行通信时，这样做可以消除流量在中心路由器中周转的时间，从而提高了中心路由器的性能并减少了分支路由器间往返的时间（RTT）。

为了支持这项功能，NHRP会在中心路由器上维护一个数据库，其中包含了各个分支路由器的真实广域网IP地址。当一台新的分支路由器进入到网络中，并通过加密的mGRE隧道与中心路由器建立了连接时，它就会将自己的真实WAN IP 地址注册到中心路由器的NHRP 数据库中。

现在，假设某人身处于某个远程分支网络中，他/她想向另一个远程分支网络拨打VoIP语音电话。在理想情况下，这个人一定希望他/它的IP电话能够直接在分支间站点进行通信，而不是在中心路由器那里走一个V型，才最终到达另一台分支路由器。要想达到这一效果，发起呼叫的那台分支路由器必须首先在中心路由器的NHRP数据库中查询被叫端目的分支路由器的WAN地址。

当该信息返回给分支路由器时，这台设备就能向对端的分支路由器动态建立一个新的加密mGRE隧道了，而此时语音流量也就不会再经过中心路由器，而是可以直接在分支路由器间传输了。

图37-2所示即为这一过程。

图37-2 DMVPN中的NHRP

从QoS的角度来看，NHRP也同样扮演着重要的角色。在分支路由器执行NHRP注册时，它会向DMVPN中心路由器通告其所属的NHRP组，而中心路由器也就可以据此向各个分支路由器应用正确的出站QoS策略了。

37.2.2 在DMVPN环境中，需要通过不同的方式来实现QoS策略

将QoS应用到DMVPN环境中的一大挑战在于，所有中心-分支隧道的终点都集中在中心路由器的一个mGRE隧道接口上。随着管理员部署的传统IPSec和GRE命令越来越多，管理员可以直接在各个隧道接口上部署QoS策略，并在数据流通过这些隧道出站时，对其应用这些策略，如图37-3所示。其效果相当于为不同站点实施了不同的QoS策略。

那么，要是我们不在各个隧道接口应用不同的QoS策略，而只在VPN路由器面向WAN网络的接口上应用一个统一的出站QoS策略，会出现什么情况呢？尽管这种方法也许可以保证总的WAN链路可以满足QoS策略的要求，但绝对保证不了去往各个分支路由器的流量都能满足QoS的需求。这样做的副作用在于，去往某些分支路由器的流量有可能会远远大于去往其他分支路由器的流量，于是去往某些分支站点的关键任务流量也就无法分配到必要的带宽。

图37-3 传统星型结构VPN中的QoS技术

在传统的站点到站点VPN环境中，因为每个分支站点都使用了相互独立的GRE隧道接口，因此管理员可以对各隧道应用不同的QoS策略。但在DMVPN环境中，所有分支站点的隧道都连接到了同一个mGRE隧道接口上。也就是说，管理员很难在这个接口上针对不同的站点部署不同的QoS策略。所以，尽管DMVPN确实解决了一些问题，但它同时也带来了一些新的问题。为了解决这一新的挑战，让管理员能够在DMVPN环境中针对不同隧道实施QoS策略， Cisco专门开发了一项新的特性，称为DMVPN的每隧道QoS特性。

37.2.3 DMVPN的每隧道QoS特性（Per-TunnelQoSForDMVPN Feature）

顾名思义，DMVPN的每隧道QoS特性可以让管理员在DMVPN环境中，以隧道或者分支路由器为单位，分别启用QoS特性。通过这项特性，管理员可以在DMVPN中心路由器的mGRE隧道接口上应用一个出站方向的QoS服务策略，而路由器会将该策略应用到与该服务策略相关联的分支隧道中。

这种做法的一大好处在于，它可以保护了每一台分支路由器。例如，某台分支路由器可能想要霸占所有的带宽，所以它传输了很多的数据流量，使得那些没有那么繁忙的分支路由器无带宽可用。该特性的另外一个好处在于，它可以限制核心路由器向低带宽的分支路由器发送过多的数据流量，并最终导致该路由器无带宽可用。

该特性还有另一项重要的优势，即系统可以在一定程度上自动运行。例如，当分支路由器向中心站点进行注册时，DMVPN中心路由器会自动创建出一条隧道，因此管理员也就不需要手动为各个分支站点配置QoS了。

正如本书此前曾经多次讨论过的那样，只有当出站接口真正出现拥塞时，队列机制才会发挥作用。由于在DMVPN环境中，所有隧道都连接到了同一个虚拟mGRE接口，因此即使通过mGRE接口的流量并不多，也有必要通过某种方式告知路由器的QoS机制，某条VPN隧道中存在拥塞。在处理路由器物理接口速度与WAN链路的速率不匹配这一问题时，首先需要将数据流整形为VPN隧道的实际带宽，以人为地限制流量传输。如果使用了DMVPN的每隧道QoS特性，系统会自动为各个隧道应用整形器。这也就允许路由器对各隧道中不同类型的数据流量执行差分服务。这种方法称为分层队列框架（HQF）。

在使用HQF时，应用于DMVPN中心路由器mGRE接口上的QoS策略可以对去往各个分支路由器的隧道流量进行整形（父策略），并依据CBWFQ（基于类的加权公平队列）对穿越该隧道的数据流实施差分服务（子策略）。

NHRP则可以将多个分支路由器分为一组，并对同一个组中的所有分支路由器应用相同的QoS策略。虽然一个组中可能会有多台分支路由器，但NHRP却可以为各个隧道分别应用流量整形器，如果任何一个隧道中的流量超过了许用的带宽，设备就会对其施加限制，同时子策略也会发挥作用，如图37-4所示。

需要注意的是在启用了该功能后，QoS的其他功能（如队列和整形）也会在物理接口的出战方向上执行。该特性会将GRE和IPSec添加的数据包头部考虑在内，在出站接口对数据包施以整形和队列机制时，这些头部空间也会计算进最大传输单元（MTU）之中。

图37-4 为DMVPN的不同隧道应用QoS

37.3 DMVPN QoS 设计实例

正如本章先前所提到的那样，在GRE隧道接口上应用QoS服务策略的传统办法并不能同mGRE结合起来使用，因为多条隧道的终点都是同一个逻辑接口。DMVPN的每隧道QoS特性，其独特之处在于能够针对不同的NHRP组应用不同的策略，以便实施各类不同的QoS策略，如4类模型、8类类型、和12类模型。

通过NHRP组，可以将针对不同隧道的QoS服务策略应用到同一个mGRE隧道接口上。在DMVPN环境中引入NHRP组这项功能，是为了支持对不同的隧道实施不同的QoS策略。当DMVPN分支路由器连接到中心路由器时，它会将NHRP组的信息发送给中心路由器。ASR1000 系列的IOS 和IOS XE 均支持该功能。DMVPN 中心路由器需要借助NHRP 组中的信息，对不同的分支路由器上应用相应的QoS策略。

管理员只需在分支路由器上配置NHRP组成员关系（该信息会被通告给中心路由器，并存储在其NHRP数据中），就可以定义分支路由器的身份了，因此也就无需通过常常的访问控制列表（ACL）来确定各个分支路由器的分组了（在中心路由器上配置这些ACL相当麻烦，因为分支站点往往是动态获取地址信息的）。同时，该做法还有一个巨大的优势，当分支路由器向核心路由器进行注册时，它也会告知核心路由器自己属于哪个NHRP组。于是，核心路由器就会根据这些信息更新NHRP数据库，并在流量离开核心路由器时对其应用正确的QoS策略。所以，虽然向核心路由器通告自己属于哪一个NHRP组是分支路由器的责任，但NHRP组与QoS策略之间的对应关系，却是由中心路由器上负责建立的。

注释:分支路由器上的每个GRE接口通常只属于一个NHRP组，但如果这台分支路由器参与了两个或者多个DMVPN网络（如在高可用性设计方案中），那么它的GRE隧道接口就有可能拥有不同的NHRP组名。

注释:如果中心路由器没有从分支路由器那里接收到NHRP组的字符串，那么中心路由器就不会它应用QoS策略，已经应用到该分支路由器的QoS策略也会被移除。

注释:这里所介绍的方法会将QoS策略应用在从中心路由器去往分支路由器的出站流量上。如需对从分支路由器去往中心路由器的流量应用QoS策略，可以在各个分支路由器的出站方向上使用使用任意一个标准的QoS参考设计（4类、8类、和12类模型）。

假设在如表37-1所列出的大型DMVPN网络设计方案中，有三个NHRP组（也就是说有三类分支路由器）。第一个NHRP组的成员只有1.5Mbit/s的带宽，也仅使用了一些基本的应用（如VoIP应用和一些其他的数据应用）。在第二个NHRP组中，每个站点拥有10Mbit/s的带宽，因此也运行了一些多媒体会议与流媒体的应用。第三组分支站点的带宽则大得多，每个站点拥有50Mbit/s的带宽，它们在第二组的基础上使用了一些广播视频类的应用。表37-1对这个网络中，三类分支路由器的需求进行了总结。

表37-1 设计案例:3类分支站点

37.3.1 DMVPN QoS设计步骤

在DMVPN隧道两端配置QoS的步骤如下所示。

中心路由器

1.配置子策略。

2.配置父策略。

3.将父策略应用到隧道接口上。

4.在接口中添加NHRP组成员。

分支路由器

1.将分支路由器添加到NHRP组中。

2.在隧道接口中添加4类、8类或12类QoS策略。

下面几节对上述步骤进行详细的介绍。

37.3.2 在中心路由器配置每隧道QoS（Per-Tunnel QoS）

在中心路由器上，管理员的第一项任务是配置QoS策略，然后再将配置好的策略添加到mGER隧道接口上。由于设计案例中有三种类型的分支路由器（也就是3个NHRP组），因此需要首先添加这三种QoS模型（4类、8类或12类模型）都会使用的QoS分类。

在之前章节所介绍的大多数示例中，路由器或者交换机上只会使用了4类、8类或12类QoS模型其中的某一种。但在DMVPN环境中，情况则有所不同。因为有各种不同类型的分支路由器都需要连接到同一台中心路由器上，它们对于QoS的需求也各不相同，因此管理员就有必要在一台路由器上设置这三种模型所需要的QoS策略，这也就是本章将这三种模型放在一起介绍的原因。因此，在中心路由器上，管理员需要配置支持所有（或其中某些）模型的class map 和policy map。在这个实例行将介绍的DMVPN 网络中，分支路由器会用到全部上述3种标准的QoS模型。

在下一节中，我们会介绍如何为各类服务类型设置policy map。

1.在中心路由器上配置4类别的QoS模型

下面的示例旨在向读者将展示如何为DMVPN中心路由器配置4类别的QoS模型。同前面几章中的示例一样，管理员需要首先确保在中心路由器上已经配置了合适的class map（详情参见第28章）。

如例37-1所示，配置的第一步是构建一个子策略。如果管理员先配置了父系的policy map，路由器不会接受这一的配置请求，因为内部的子系policy map 此时尚未配置，这一点与配置普通的QoS策略并无区别。

例37-1 配置4类模型分支机构中的子系QoS策略

ASR1000(config)# policy-map 4-CLASS-CHILD

! This policy map is a "child" of the parent policy map that is

! responsible for shaping all four-class spokes.When the shaper

! creates artificial backpressure, this policy map is invoked by

! the router.

ASR1000(config-pmap)# class REALTIME

ASR1000(config-pmap-c)# priority percent 33

ASR1000(config-pmap)# class CONTROL

ASR1000(config-pmap-c)# bandwidth percent 7

ASR1000(config-pmap)# class TRANSACTIONAL-DATA

ASR1000(config-pmap-c)# bandwidth percent 35

ASR1000(config-pmap-c)# fair-queue

ASR1000(config-pmap)# class class-default

ASR1000(config-pmap-c)# bandwidth percent 25

ASR1000(config-pmap-c)# fair-queue

ASR1000(config-pmap-c)# random-detect

注释:本章所介绍的所有中心路由器配置都是在ASR 1000系列的IOS XE 3.6系统上进行创建和测试的。如果用ISR G2路由器来充当中心路由器，配置的方法基本与ASR相同。

可以通过如下命令来验证例37-1中的配置。

■ show class-map

■ show policy-map

在配置完子policy map 后，就可以创建外层嵌套的父policy map 了，这个策略的主要作用是对每条VPN隧道所通过的流量进行整形，如例37-2所示。整形器会对流量进行限制，并调用例37-1所示的队列。

例37-2 配置4类模型分支机构中的父系QoS策略

ASR1000(config)# policy-map 4-CLASS-PARENT

ASR1000(config-pmap)# class class-default

ASR1000(config-pmap)# shape average 1500000

! Shaper to create queuing backpressure at 1.5 Mbps

ASR1000(config-pmap)# service-policy 4-CLASS-CHILD

! Nested service policy to call the "child" policy

可以通过如下命令来验证例37-2中的配置。

■ show class-map

■ show policy-map

此后，管理员需要在中心路由器的mGRE接口上，应用父系的QoS策略，如例37-3所示。

例37-3 将父系QoS policy map应用到mGRE接口上

ASR1000(config)# interface Tunnel10

ASR1000(config-if)# ip address 10.1.1.254 255.255.255.0

! If using EIGRP, make sure to disable split horizon

ASR1000(config-if)# no ip split-horizon eigrp 100

ASR1000(config-if)# ip nhrp authentication hector

ASR1000(config-if)# ip nhrp map multicast dynamic

ASR1000(config-if)# ip nhrp map group SPOKE-1-GROUP service-policy output 4-CLASS-PARENT

! Attach the parent service policy to the mGRE interface

! and associates this policy with NHRP SPOKE-1-GROUP

ASR1000(config-if)# ip nhrp network-id 12300

ASR1000(config-if)# tunnel source GigabitEthernet0/0/0

ASR1000(config-if)# tunnel mode gre multipoint

ASR1000(config-if)# tunnel key 3210

ASR1000(config-if)# tunnel protection IPsec profile MY-BIG-VPN

可以通过如下命令来验证例37-3中的配置。

■ show run interface tunnel10

■ show ip nhrp group-map

■ show dmvpn detail

注释:读者或许已经注意到了，在这个配置案例中，管理员通过一行命令禁用了EIGRP的水平分割。虽然在隧道内使用哪种路由器协议完全可以由管理员自行决定，但由于EIGRP协议极具扩展性，因此在星形拓扑中使用EIGRP（增强型内部网关路由协议）是一种常见的做法。总的来说，在星形拓扑的设计方案中，EIGRP要比OSPF更加稳定。

OSPF协议每学到一条新的路由就会泛洪一次更新包（该数据包称为链路状态确认数据包[LSA]）。设想，在一个数百个分支节点通过Internet建立通信的大型VPN网络中，哪怕只有一台分支路由器丢失了原先的链路状态，OSPF进程就会产生一个全网的LSA更新信息，并向同一个区域中的所有路由器泛洪该消息。如果网络状况不佳，情况可能会变得更加难以控制，因为设备会一遍又一遍地将LSA发送给所有其他的分支路由器，而这些分支路由器则会设法分析这些新的LSA并计算出当前的SPF路径，而这会使这些路由器的CPU使用率飙升。

EIGRP就不存在这样的问题。因为EIGRP并不基于开放最短路径优先（OSPF）协议和中间系统到中间系统（IS-IS）协议所使用的链路状态算法。因此，EIGRP往往更适合DMVPN的环境，并且EIGRP也可以轻松地拓展出成千上万个分支网络，而OSPF在扩展性方面则与EIGRP相去甚远。

2.在中心路由器上配置8类别的QoS模型

例37-4到例37-6所示为如何在中心路由器上配置8类的QoS模型。在这之前，假定已经有人配置好了相应的class map。

例37-4 在8类模型中，配置子系的QoS policy map

ASR1000(config )# policy-map 8-CLASS-CHILD

! This policy map is a "child" of the parent policy map that is

! responsible for shaping all eight-class spokes.When the shaper

! creates artificial backpressure, this policy map is invoked by

! the router.

ASR1000(config-pmap)# class VOICE

ASR1000(config-pmap-c)# priority percent 10

ASR1000(config-pmap)# class MULTIMEDIA-CONFERENCING

ASR1000(config-pmap-c)# priority percent 23

ASR1000(config-pmap)# class NETWORK-CONTROL

ASR1000(config-pmap-c)# bandwidth percent 5

ASR1000(config-pmap)# class SIGNALING

ASR1000(config-pmap-c)# bandwidth percent 2

ASR1000(config-pmap)# class MULTIMEDIA-STREAMING

ASR1000(config-pmap-c)# bandwidth percent 10

ASR1000(config-pmap-c)# fair-queue

ASR1000(config-pmap-c)# random-detect dscp-based

ASR1000(config-pmap)# class TRANSACTIONAL-DATA

ASR1000(config-pmap-c)# bandwidth percent 24

ASR1000(config-pmap-c)# fair-queue

ASR1000(config-pmap-c)# random-detect dscp-based

ASR1000(config-pmap)# class SCAVENGER

ASR1000(config-pmap-c)# bandwidth percent 1

ASR1000(config-pmap)# class class-default

ASR1000(config-pmap-c)# bandwidth percent 25

ASR1000(config-pmap-c)# fair-queue

ASR1000(config-pmap-c)# random-detect

可以通过如下命令来验证例37-4中的配置。

■ show class-map

■ show policy-map

同样，管理员接下来可以配置父系的QoS policy map，如例37-5 所示。

例37-5 在8类模型中，配置父系QoS policy map

ASR1000(config)# policy-map 8-CLASS-PARENT

ASR1000(config-pmap)# class class-default

ASR1000(config-pmap-c)# shape average 10000000

! Shaper to create queuing backpressure at 10 Mbps

ASR1000(config-pmap-c)# service-policy 8-CLASS-CHILD

! Nested service policy to call the "child" policy

可以通过如下命令来验证例37-5中的配置。

■ show class-map

■ show policy-map

最后需要将主QoS策略映射应用到mGER接口上，如例37-6所示。为了简化起见，本例只提供了相关的QoS配置。

例37-6 将8类别的父系QoS policy map应用到mGRE接口上

ASR1000(config)# interface Tunnel10

! Only a partial configuration of the tunnel interface is shown

! here.The rest of the tunnel configuration is the same as the

! four-class model hub example shown earlier.

ASR1000(config-if)# ip address 10.1.1.254 255.255.255.0

ASR1000(config-if)# ip nhrp map group SPOKE-2-GROUP service-policy output 8-CLASS-PARENT

! Attach the parent service policy to the mGRE interface

! and associate this policy with NHRP SPOKE-2-GROUP

可以通过如下命令来验证例37-6中的配置。

■ show run interface tunnel10

■ show ip nhrp group-map

■ show dmvpn detail

3.在中心路由器上配置12类别的QoS模型

例37-7到例37-10所示为如何在中心路由器上配置12类的QoS模型。在这之前，假定已经有人配置好了相应的class map。

例37-7 在12类模型中，配置子系的QoS policy map

ASR1000(config)# policy-map 12-CLASS-CHILD

! This policy map is a "child" of the parent policy map that is

responsible for shaping all 12-class spokes.When the shaper

creates artificial backpressure, this policy map is invoked by

the router.

ASR1000(config-pmap)# class VOICE

ASR1000(config-pmap-c)# priority percent 10

ASR1000(config-pmap)# class REALTIME-INTERACTIVE

ASR1000(config-pmap-c)# priority percent 13

ASR1000(config-pmap)# class BROADCAST-VIDEO

ASR1000(config-pmap-c)# priority percent 10

ASR1000(config-pmap)# class NETWORK-CONTROL

ASR1000(config-pmap-c)# bandwidth percent 2

ASR1000(config-pmap)# class SIGNALING

ASR1000(config-pmap-c)# bandwidth percent 2

ASR1000(config-pmap)# class NETWORK-MANAGEMENT

ASR1000(config-pmap-c)# bandwidth percent 3

ASR1000(config-pmap)# class MULTIMEDIA-CONFERENCING

ASR1000(config-pmap-c)# bandwidth percent 10

ASR1000(config-pmap-c)# fair-queue

ASR1000(config-pmap-c)# random-detect dscp-based

ASR1000(config-pmap)# class MULTIMEDIA-STREAMING

ASR1000(config-pmap-c)# bandwidth percent 10

ASR1000(config-pmap-c)# random-detect dscp-based

ASR1000(config-pmap-c)# fair-queue

ASR1000(config-pmap)# class TRANSACTIONAL-DATA

ASR1000(config-pmap-c)# bandwidth percent 10

ASR1000(config-pmap-c)# fair-queue

ASR1000(config-pmap-c)# random-detect dscp-based

ASR1000(config-pmap)# class BULK-DATA

ASR1000(config-pmap-c)# bandwidth percent 4

ASR1000(config-pmap-c)# fair-queue

ASR1000(config-pmap-c)# random-detect dscp-based

ASR1000(config-pmap)# class SCAVENGER

ASR1000(config-pmap-c)# bandwidth percent 1

ASR1000(config-pmap)# class class-default

ASR1000(config-pmap-c)# bandwidth percent 25

ASR1000(config-pmap-c)# fair-queue

ASR1000(config-pmap-c)# random-detect

可以通过如下命令来验证例37-7中的配置。

■ show class-map

■ show policy-map

例37-8 所示为父系policy map 的配置。

例37-8 为12类模型的Group 3 Spokes配置父系的QoS policy map

ASR1000(config)# policy-map 12-CLASS-PARENT

ASR1000(config-pmap)# class class-default

! create backpressure at 50 Mbps

ASR1000(config-pmap-c)# shape average 50000000

! use a nested service policy to call the "child" policy

ASR1000(config-pmap-c)# service-policy 12-CLASS-CHILD

可以通过如下命令来验证例37-8中的配置。

■ show class-map

■ show policy-map

同样，最后一步是将上面配置的服务策略应用到mGRE隧道接口。例37-9的阴影部分所示为如何在DMVPN中心路由器上为组3（Group 3）中的分支路由器启动每隧道QoS的配置。

例37-9 将12类别的父系QoS Policy Map应用到mGRE接口上

ASR1000(config)# interface Tunnel10

! Only a partial configuration of the tunnel interface is shown

! here.The rest of the tunnel configuration is the same as the

! four-class model hub example shown earlier.

ASR1000(config-if)# ip address 10.1.1.254 255.255.255.0

ASR1000(config-if)# ip nhrp map group SPOKE-3-GROUP service-policy output 12-CLASS-PARENT

! Attach the parent service policy to the mGRE interface

! and associates this policy with NHRP SPOKE-3-GROUP

可以通过如下命令来验证例37-9中的配置。

■ show run interface tunnel10

■ show ip nhrp group-map

■ show dmvpn detail

DMVPN的一个独特功能在于，它能在单个接口上支持多种QoS服务策略。这个特性相当有趣，因为在其他任何环境中，管理员都不能在一个接口上添加多种服务策略。在当前介绍的这个设计案例中，分支站点到分支站点之间只有3种不同的类型:1.5Mbit/s带宽的链路、10Mbit/s带宽的链路和50Mbit/s带宽的链路。但这并不需要配置三种不同的mGRE接口，因为DMVPN可以在同一个接口上配置多个策略映射。例37-10所示为如何在中心路由器的一个mGRE 接口上配置三种不同的父系policy map。

同之前一样，下面的案例中只会显示相关的QoS配置。

例37-10 将所有这3个policy map都添加到一个mGRE接口上

ASR1000(config)# interface Tunnel10

ASR1000(config-if)# ip address 10.1.1.254 255.255.255.0

ASR1000(config-if)# ip nhrp map group SPOKE-1-GROUP service-policy output 4-CLASS-PARENT

! Adds the SPOKE-1-GROUP spokes (4-Class model spokes)

ASR1000(config-if)# ip nhrp map group SPOKE-2-GROUP service-policy output 8-CLASS-PARENT

! Adds the SPOKE-2-GROUP spokes (8-Class model spokes)

ASR1000(config-if)# ip nhrp map group SPOKE-3-GROUP service-policy output 12-CLASS-PARENT

! Adds the SPOKE-3-GROUP spokes (12-Class model spokes)

可以通过如下命令来验证例37-10中的配置。

■ show run interface tunnel 10

■ show ip nhrp group-map

■ show dmvpn detail

37.3.3 在分支路由器上配置每隧道QoS

第一步是在各个分支路由器上配置它们所属的NHRP组。一旦完成这些配置，分支路由器就会与中心路由器进行通信，并告知中心路由器自己属于哪个NHRP组。例37-11到例37-13所示为将分支路由器添加为NHRP组成员的方法。配置的关键在于，分支路由器的NHRP组名必须与中心路由器QoS服务策略中使用的名称相同。当NHRP开始进行注册时，中心路由器就会把这个NHRP组名存储进NHRP数据库中。此后，设备就会使用这个数据库来确定每台分支路由器上分别应该使用何种服务策略。

注释:在接下来的配置案例中，我们均假定已经有人配置了分别对应4类、8类、12类模型配置的class map。

例37-11 所示为如何让一台分支路由器将自己宣告为组1（Group 1）的成员路由器。命令ip nhrp 可以实现上述功能。

例37-11 （4类别模型中）Group1中的一台分支路由器

! Spoke 1 (part of SPOKE-1-GROUP):

ISR1941_SPOKE_1(config)# interface tunnel10

ISR1941_SPOKE_1(config-if)# ip address 10.1.1.30 255.255.255.0

ISR1941_SPOKE_1(config-if)# ip nhrp authentication hector

ISR1941_SPOKE_1(config-if)# ip nhrp group SPOKE-1-GROUP

! Associates this spoke with NHRP SPOKE-1-GROUP

ISR1941_SPOKE_1(config-if)# ip nhrp map 10.1.1.254 172.25.1.254

ISR1941_SPOKE_1(config-if)# ip nhrp map multicast 172.25.1.254

ISR1941_SPOKE_1(config-if)# ip nhrp network-id 12300

ISR1941_SPOKE_1(config-if)# ip nhrp nhs 10.1.1.254

ISR1941_SPOKE_1(config-if)# ip tcp adjust-mss 1360

! Enable this command on all the spoke routers, not the hub

ISR1941_SPOKE_1(config-if)# tunnel source GigabitEthernet0/0

ISR1941_SPOKE_1(config-if)# tunnel mode gre multipoint

ISR1941_SPOKE_1(config-if)# tunnel key 3210

ISR1941_SPOKE_1(config-if)# tunnel protection IPsec profile MY-BIG-VPN

可以通过如下命令来验证例37-11中的配置。

■ show run interface tunnel 10

■ show ip nhrp group-map

■ show dmvpn detail

例37-12 （8类别模型中）Group 2中的一台分支路由器

! Spoke 2 (part of SPOKE-2-GROUP):

ISR1941_SPOKE_2(config)# interface tunnel10

ISR1941_SPOKE_2(config-if)# ip address 10.1.1.40 255.255.255.0

ISR1941_SPOKE_2(config-if)# ip nhrp authentication hector !

ISR1941_SPOKE_2(config-if)# ip nhrp group SPOKE-2-GROUP

! Associates this spoke with NHRP SPOKE-2-GROUP

ISR1941_SPOKE_2(config-if)# ip nhrp map 10.1.1.254 172.25.1.254

ISR1941_SPOKE_2(config-if)# ip nhrp map multicast 172.25.1.254

ISR1941_SPOKE_2(config-if)# ip nhrp network-id 12300

ISR1941_SPOKE_2(config-if)# ip nhrp nhs 10.1.1.254

ISR1941_SPOKE_2(config-if)# ip tcp adjust-mss 1360

! Enable this command on all the spoke routers, not the hub

ISR1941_SPOKE_2(config-if)# tunnel source GigabitEthernet0/0

ISR1941_SPOKE_2(config-if)# tunnel mode gre multipoint

ISR1941_SPOKE_2(config-if)# tunnel key 3210

ISR1941_SPOKE_2(config-if)# tunnel protection IPsec profile MY-BIG-VPN

可以通过如下命令来验证例37-12中的配置。

■ show run interface tunnel 10

■ show ip nhrp group-map

■ show dmvpn detail

例37-13 （12类别模型中）Group 3中的一台分支路由器

! Spoke 3 (part of SPOKE-3-GROUP):

ISR1941_SPOKE_3(config)# interface tunnel10

ISR1941_SPOKE_3(config-if)# ip address 10.1.1.50 255.255.255.0

ISR1941_SPOKE_3(config-if)# ip nhrp authentication hector

ISR1941_SPOKE_3(config-if)# ip nhrp group SPOKE-3-GROUP

! Associates this spoke with NHRP SPOKE-1-GROUP

ISR1941_SPOKE_3(config-if)# ip nhrp map 10.1.1.254 172.25.1.254

ISR1941_SPOKE_3(config-if)# ip nhrp map multicast 172.25.1.254

ISR1941_SPOKE_3(config-if)# ip nhrp network-id 12300

ISR1941_SPOKE_3(config-if)# ip nhrp nhs 10.1.1.254

ISR1941_SPOKE_3(config-if)# ip tcp adjust-mss 1360

! Enable this command on all the spoke routers, not the hub

ISR1941_SPOKE_3(config-if)# tunnel source GigabitEthernet0/0

ISR1941_SPOKE_3(config-if)# tunnel mode gre multipoint

ISR1941_SPOKE_3(config-if)# tunnel key 3210

ISR1941_SPOKE_3(config-if)# tunnel protection IPsec profile MY-BIG-VPN

可以通过如下命令来验证例37-13中的配置。

■ show run interface tunnel10

■ show ip nhrp group-map

■ show dmvpn detail

■ show policy-map multipoint

注意，在前面的例子中，只需要在分支路由器中进行一些特殊的配置，就能在各个分支路由器上识别出NHRP组的成员关系。当管理员在分支路由器上配置好NHRP组成员的名称后，这台分支路由器就会向中心路由器通告自己属于哪个NHRP组，以便中心路由器对其应用正确的QoS配置文件。

在三个组中，每组的分支路由器上都配置了类似的QoS配置文件（例如WAN带宽、所使用的应用等），它们使用的NHRP 组成员名称也都相同。在这个案例中，Spoke 1 属于NHRP SPOKE-1-GROUP，Spoke 2 属于 NHRP SPOKE-2-GROUP 等。同时，SPOKE-1-GROUP、SPOKE-2-GROUP和SPOKE-3-GROUP都在中心路由器上定义了不同的QoS配置文件。

注释:虽然本章的重点是如何在中心路由器上执行QoS配置，以及如何将分支路由器添加到NHRP组中，但读者也应考虑在分支路由器的物理接口上配置一个出站的QoS策略，以便在高优先级流量进入广域网时，为其提供有保障的服务。详细的内容将在第39章中进行讨论。

37.3.4 验证DMVPN的QoS配置

现在，管理员已经在中心路由器上应用了服务策略，并将其应用到了mGRE接口上，此时应该验证NHRP是否接受了组成员发来的注册信息。验证NHRP分支路由器的成员身份是相当重要的，因为中心路由器需要借助分支路由器向自己宣告的组成员身份，为它们应用不同的（每隧道）QoS策略。

如例37-14所示，NHRP数据库将三台分支路由器与正确的NHRP组建立了关联，以便自己能够正确地为它们应用QoS策略。

例37-14 验证分支路由器是否已经以组成员的身份注册到了中心路由器上:show ip nhrp group-map

ASR1000# show ip nhrp group-map

!

Interface:Tunnel10

NHRP group:SPOKE-1-GROUP

QoS policy:4-CLASS-PARENT

Tunnels using the QoS policy:

Tunnel destination overlay/transport address

10.1.1.30/172.17.10.1　　　! Spoke 1

NHRP group:SPOKE-2-GROUP

QoS policy:8-CLASS-PARENT

Tunnels using the QoS policy:

Tunnel destination overlay/transport address

10.1.1.40/172.16.20.1　　　! Spoke 2

NHRP group:SPOKE-3-GROUP

QoS policy:12-CLASS-PARENT

Tunnels using the QoS policy:

Tunnel destination overlay/transport address

10.1.1.50/172.16.30.1　　　! Spoke 3

还有一条命令也很有用:show dmvpn detail。例37-15 显示了这条命令的部分输出信息，这部分信息与DMVPN网络中的QoS服务策略应用有关。输出信息显示，中心路由器上连接了三个NHRP组的路由器，还显示了一些具体的DMVPN信息。

例37-15 验证DMVPN分支路由器的关联:show dmvpn detail

ASR1000# show dmvpn detail

!

Legend:Attrb --> S - Static, D - Dynamic, I - Incomplete

N - NATed, L - Local, X - No Socket

# Ent --> Number of NHRP entries with same NBMA peer

NHS Status:E --> Expecting Replies, R --> Responding, W --

UpDn Time --> Up or Down Time for a Tunnel

=================================================================

Interface Tunnel10 is up/up, Addr.is 10.1.1.254, VRF ""

Tunnel Src./Dest.addr:172.25.1.254/MGRE, Tunnel VRF ""

Protocol/Transport:"multi-GRE/IP", Protect "MY-BIG-VPN"

Interface State Control:Disabled

nhrp event-publisher:Disabled

Type:Hub, Total NBMA Peers (v4/v6):2

# Ent　Peer NBMA Addr Peer Tunnel Add State　UpDn Tm Attrb　Target Network

----- --------------- --------------- ----- -------- ----- ------

1　　172.16.10.1　10.1.1.30　UP 19:45:38　D

NHRP group:SPOKE-1-GROUP

Output QoS service-policy applied:4-CLASS-PARENT

1　　172.16.20.1　10.1.1.40　UP 20:51:07　D

NHRP group:SPOKE-2-GROUP

Output QoS service-policy applied:8-CLASS-PARENT

1　　172.16.30.1　10.1.1.50　UP 19:47:21　D

NHRP group:SPOKE-3-GROUP

Output QoS service-policy applied:12-CLASS-PARENT

最后，强烈建议管理员对自己配置的服务策略进行确认，确保它们的配置和应用均无差错。在使用DMVPN 时，可以使用show policy-map multipoint 命令。这条命令是DMVPN 所独特有的。几乎在这本书中出现的所有示例中，验证QoS 策略使用的命令都是show policy-map interface。但在DMVPN中，关键词从interface变成了multipoint。

例37-16展示了使用8类模型QoS组的一部分输出命令。

例37-16 验证policy map的配置:show policy-map multipoint

ASR1000# show policy-map multipoint

Interface Tunnel10 <--> 30.0.0.1

Service-policy output:GROUP-2-PARENT

Class-map:class-default (match-any)

1182492 packets, 1485130581 bytes

5 minute offered rate 24418000 bps, drop rate 19520000 bps

Match:any

Queueing

queue limit 64 packets

(queue depth/total drops/no-buffer drops) 0/912489/0

(pkts output/bytes output) 307082/399820764

shape (average) cir 10000000, bc 40000, be 40000

target shape rate 10000000

Service-policy:GROUP-2-CHILD

queue stats for all priority classes:

Queueing

queue limit 512 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 90069/117269838

Class-map:VOICE (match-all)

28171 packets, 35382776 bytes

5 minute offered rate 593000 bps, drop rate 0000 bps

Match:dscp ef (46)

Priority:10% (1000 kbps), burst 25000, b/w ex drops:0

Class-map:MULTIMEDIA-CONFERENCING (match-any)

61898 packets, 77743888 bytes

5 minute offered rate 1288000 bps, drop rate 0000 bps

Match:dscp af41 (34)

Match:dscp af42 (36)

Match:dscp af43 (38)

Priority:23% (2300 kbps), burst 57500, b/w ex drops:0

Class-map:NETWORK-CONTROL (match-all)

3165 packets, 3896984 bytes

5 minute offered rate 73000 bps, drop rate 0000 bps

Match:dscp cs6 (48)

Queueing

queue limit 64 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 3098/4033596

bandwidth 5% (500 kbps)

Class-map:SIGNALING (match-all)

4695 packets, 5896920 bytes

5 minute offered rate 105000 bps, drop rate 0000 bps

Match:　dscp cs3 (24)

Queueing

queue limit 64 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 4695/6112890

bandwidth 2% (200 kbps)

Class-map:MULTIMEDIA-STREAMING (match-any)

309878 packets, 389206768 bytes

5 minute offe rate 6405000 bps, drop rate 5891000 bps

Match:　dscp af31 (26)

Match:　dscp af32 (28)

Match:　dscp af33 (30)

Queueing

queue limit 64 packets

(queue dep/total dp/no-buff drop/fldrop) 16/274845/0/0

(pkts output/bytes output) 35033/45612966

bandwidth 10% (1000 kbps)

Fair-queue:per-flow queue limit 16 packets

Exp-weight-constant:4 (1/16)

Mean queue depth:15 packets

dscp　Transmitted　Rand drop T/F drop Min Max Mark

pkts/bytes pkts/bytes　pkts/bytes th th prob

af31　35002/45572604 0/0　　0/0　28 32　1/10

af32　16/20832　0/0　　0/0　24 32　1/10

af33　15/19530　0/0　　0/0　20 32　1/10

Class-map:TRANSACTIONAL-DATA (match-any)

309879 packets, 389208024 bytes

5 minute offered rate 6405000 bps, drop rate 4999000

Match:　dscp af21 (18)

Match:　dscp af22 (20)

Match:　dscp af23 (22)

Queueing

queue limit 64 packets

(qu depth/total drops/no-buf drops/flowdrops) 16/233198/0/0

(pkts output/bytes output) 76681/99838662

bandwidth 24% (2400 kbps)

Fair-queue:per-flow queue limit 16 packets

Exp-weight-constant:4 (1/16)

Mean queue depth:14 packets

dscp Transmitted　Random drop　Tail/Flow drop Min Max Mark

pkts/bytes　pkts/bytes　pkts/bytes th th　prob

af21 76628/99769656　0/0　　　0/0　28　　32　1/10

af22　22/28644　0/0　　　0/0　24　　32　1/10

af23　31/40362　0/0　　　0/0　20　　32　1/10

Class-map:SCAVENGER (match-all)

154939 packets, 194603384 bytes

5 minute offered rate 3206000 bps, drop rate 3148000

Match:　dscp cs1 (8)

Queueing

queue limit 64 packets

(queue depth/total drops/no-buffer drops) 64/146681/0

(pkts output/bytes output) 8258/10751916

bandwidth 1% (100 kbps)

Class-map:class-default (match-any)

309879 packets, 389206909 bytes

5 minute offered rate 6405000 bps, drop rate 4937000

Match:any

Queueing

queue limit 64 packets

(queue depth/tot drop/no-buffer drops/fldrops) 16/230217/0/0

(pkts output/bytes output) 79661/103718622

bandwidth 25% (2500 kbps)

Fair-queue:per-flow queue limit 16 packets

Exp-weight-constant:4 (1/16)

Mean queue depth:14 packets

class Transmitted Random drop Tail/Flow drop Min Max Mark

pkts/bytes　pkts/bytes　pkts/bytes　th　th　prob

0　79661/103718622 0/0　　0/0　　16　32　1/10

1　　0/0　　0/0　　0/0　　18　32　1/10

2　　0/0　　0/0　　0/0　　20　32　1/10

3　　0/0　　0/0　　0/0　　22　32　1/10

4　　0/0　　0/0　　0/0　　24　32　1/10

5　　0/0　　0/0　　0/0　　26　32　1/10

6　　0/0　　0/0　　0/0　　28　32　1/10

7　　0/0　　0/0　　0/0　　30　32　1/10

37.4 分支路由器间的每隧道QoS

在为DMVPN网络设计QoS策略时，最常见的一个问题就是，如何在分支路由器间应用每隧道QoS？举例来说，当一台远程分支路由器动态建立了一个通向其他分支路由器的隧道，如何针对这条新的隧道应用出站方向的QoS策略呢？难道要参照中心路由器的做法吗？遗憾的是，DMVPN的每隧道QoS功能目前只能应用在中心路由器上，这就意味着在分支路由器之间的通信中，无法为不同的隧道应用不同的出站策略。

本章也确实在设计案例中，在分支路由器（与中心路由器相连的）出站方向上应用了QoS策略。但是，因为分支路由器无法访问中心路由器上的NHRP数据库，所以它也就不能为不同类型的分支路由器应用不同的QoS策略。换言之，如果需要在分支路由器之间部署每隧道QoS，只能通过配置静态ACL来实现。但这种做法往往得不偿失。

如果在站点间部署QoS策略也是强制性的需求，不妨考虑使用FlexVPN。FlexVPN和DMVPN有许多相似之处，但主要的区别在于FlexVPN不直接分支站点间直接进行通信。也就是说，分支间通信的流量必须要经过中心路由器才能从一个分支到达另一个分支。虽然这种做法明显会增加网络延迟，也会消耗中心路由器上的资源，但这种方式却可以解决分支站点间以隧道为单位部署QoS的问题，这是它的优势。FlexVPN也和DMVPN一样支持在中心站点与分支站点间的每隧道QoS。但因为所有分支路由器向外传输的流量都必须首先经过中心路由器，所以分支路由器上只需要部署一项QoS策略即可。

37.5 总结

本章讨论了设计DMVPN的各种因素，特别是如何在DMVPN环境中为不同隧道实施不同的QoS策略。此外，本章还讨论了DMVPN的优势以及这项技术大受欢迎的各类原因。

本章对DMVPN的架构和设计方案进行了简短的回顾，同时着重介绍了在DMVPN环境中配置QoS的几大组成成份。本章还详述了NHRP协议，以及分支路由器是如何使用NHRP来将其组成员身份通告给中心路由器的，这可以让中心路由器为分支路由器应用正确的出站QoS策略。

本章讨论了DMVPN环境中的QoS问题，以及如何在中心路由器上使用每隧道QoS机制。本章介绍了一项特性，名为DMVPN的每隧道QoS，并为其提供了一个详细的设计案例。通过这个设计实例，本章介绍了如何在一台DMVPN中心路由器上配置三类分支路由器。这可以让读者进一步了解，如何在一个DMVPN环境中，对不同的分支路由器分别应用4类、8类和12类的QoS模型。

此外，本章也探讨了分支路由器上的QoS设计方案，不过结论是DMVPN的每隧道QoS特性只能应用在中心路由器上。如果一定要在分支站点间实现每隧道的QoS策略，本章也提供了一种可供选择的QoS设计方案。

37.6 扩展阅读

DMVPN Overview（DMVPN概述）:www.cisco.com/go/dmvpn

DMVPN Configuration Guide（DMVPN 配置指南）:http://www.cisco.com/en/US/partner/docs/ios-xml/ios/sec_conn_dmvpn/configuration/xe-3s/sec-conn-dmvpn-per-tunnel-QoS.html

DMVPN Feature Guide（DMVPN特性指南）:http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ftgreips.html

第38章 GET VPN的QoS设计

通过前面一章的内容，读者应该已经熟悉了在搭建动态多点VPN（DMVPN）环境时，在QoS方面需要考虑哪些重要因素。DMVPN是目前最常用的VPN架构之一。另一项用户甚众的VPN 架构（GET VPN）虽与DMVPN 颇有不同，但功能却与前者一样强大。

在前一章中，本书曾经介绍过DMVPN在经典的IPSec VPN技术的基础上作出了许多改进，特别是在动态建立多点隧道，以及使用NHRP协议将QoS策略应用到每个隧道上这两方面，可谓颇有建树。GET VPN 提供的VPN 功能则与DMVPN 差距较大，它不使用隧道加密IPSec端到端的数据。虽然从技术的角度上看，在组成员之间传输数据包，使用的还是IPSec隧道模式，但组成员间的关系，并不是由传统的IPSec安全关联（SA）所定义的。

DMVPN 与传统的IPSec VPN 相比，最大的优势是它能够扩展出大量的分支网络，同时减少配置和管理上的负担。GET VPN 将VPN 扩展性方面的优势提升到了一个全新的水平，同时它还可以不通过隧道技术，支持端到端的QoS需求。

在建立IPSec隧道时，端点会创建一条全新的点到点连接，以此建立起一个覆盖网络。传统VPN和DMVPN所使用的VPN覆盖模型是相当强大的，但是这类模型会显著增加配置和管理的难度，甚至需要通过那些极为有针对性QoS特性（譬如NHRP这种针对不同隧道应用QoS 特性的方式）来保护高优先级的流量。如果不使用点到点的模型，那么许多IPSec VPN 所固有的具有局限性和复杂性的问题，也可以就迎刃而解了。

为什么呢？试想，智能网络一般都是依靠各个路由设备的功能，来处理穿越网络的数据包的。恰如前两章所述，在通过VPN传输数据时，当原始数据包被封装成了IPSec数据包，或者是封装成通用路由协议(GRE)数据包（意味着它进入了隧道模式）时，原数据包在网络中也就不可见了。而这会增加很多事情的难度，让人们必须借助一些特殊的工具（如QoS预分类特性）来解决问题。如果能够完全控制原始IP 数据包头部，即使使用IPSec VPN（如GET VPN）对数据包进行加密的情形也不例外，那么语音和视频等依赖核心网络特性（如路由、组播和QoS）的应用，它们的端到端操作才能有所保障。

本章的主要内容包括:

■ GET VPN QoS 概述；

■ GET VPN QoS 配置概述；

■ GET VPN 环境下的QoS 设计；

■ 在部署GET VPN 时，需要与服务提供商合作。

38.1 GET VPN QoS概述

DMVPN 是一个公共的不可靠网络（如Internet）上的星型结构网络，而GET VPN 则更适用于私有网络。首先，GET VPN 适合部署任意到任意（站点到站点）的私有网络环境（如多协议标签交换[MPLS] 网络）中。假设，一家公司通过本地服务提供商的3 层MPLS VPN，连接了许多分支。虽然根据MPLS的特性，很多人都会认为，任意到任意的链路是私有的，也是安全的，但有些企业还是希望穿越运营商网络的连接能够进行加密，以提升数据的私密性。

虽然在MPLS网络之内，也可以部署DMVPN，但这种环境实施和管理起来，总是不太方便，而QoS设计方案也会变得相当累赘。通过对比，如果使用DMVPN技术，就会在MPLS VPN 的基础上添加一层新的VPN。但若使用GET VPN，鉴于GET VPN 不使用隧道技术，因此这种环境只会对出入客户边界路由器的数据包进行加密。因此，主要的不同在于，GETVPN并没有真正的星型网络这种概念，它不需要通过一个hub端来汇聚所有远端站点的流量，也不会造成大面积流量超载的情况，因此可以简化QoS的架构。

在判断GET VPN是否是最适合的VPN技术时，要确定当前环境中是否已有一个私有网络，或MPLS VPN 环境，以及设计需求是否只是希望加密远端CE 路由器之间（穿越网络）相互发送的流量。表38-1 概括了DMVPN 和GET VPN 之间的一些主要区别。

表38-1 DMVPN和GET VPN的技术比较

在下面的章节中，本书会对一些与GET VPN 有关的重要QoS 概念进行介绍。

38.1.1 组域的概念

随着组加密传输（或GET VPN）技术的问世，人们不使用任何隧道技术就可以部署任意到任意的IPSec VPN 了。在经典的IPSec VPN 和DMVPN 技术中，IPSec 会在VPN 端点之间建立一种称为SA（安全关联）的对等体关系。当两个端点开始协商SA，并确定了加密方式和哈希算法后，这两个端点就相当于建立了基本的点到点隧道。这个SA只对这两台路由器之间才有意义。比如，在DMVPN环境中，当一台spoke路由器需要向另一台spoke路由器发送加密流量时，它会首先使用NHRP去发现对端设备，然后它就会自动与那台spoke设备之间建立安全关联（DMVPN不会自动实现这一功能）。DMVPN需要依靠与远端站点之间建立一条独立的SA（或隧道）；因此，在DMVPN环境中，QoS也必须以SA为单位，分别为每个站点一一地应用。

而在GET VPN 的情形中，路由器之间并没有SA 的概念，这也就是说路由器之间不用建立IPSec 隧道。GET VPN 使用的是一种“组SA”的概念，网络中所有加密的节点共享组SA。由于GET VPN 网络中，所有路由器都属于同一个大的组SA，因此管理员也就没必要再分别为每个基本站点应用QoS；他/ 她只需在每个GET VPN 路由器的出站接口上配置QoS。所以说，DMVPN 中需要分别为每个隧道部署QoS 的概念，在GET VPN 网络中并不适用。

这项技术称为组解释域（GDOI），定义在RFC 3547 中。在深入讨论GDOI 的工作方式，以及GDOI 如何在GET VPN 环境中支持QoS 技术之前，需要首先介绍一下用来建立GET VPN网络的两类设备。

38.1.2 GET VPN的搭建

在部署GET VPN时，会使用到两类路由器:组成员（GM）路由器和密钥（KS）路由器。GM路由器是在数据包出入各站点时，真正用来加密和解密这些数据包的设备，而KS的作用则是负责管理GM使用的加密密钥。在MPLS环境中，GM服务往往运行在CE路由器上，而KS路由器则通常运行在专用的路由器上，这类设备往往位于数据中心或非军事区（DMZ）内。

在网络的每个远端站点中，至少都有一台GM 路由器，但在整个GET VPN 网络中，只会部署一台（或者再加一个备份的）KS路由器。KS路由器负责为网络中的GM路由器管理和分发组加密密钥。KS路由器会向所有经过认证，也注册过的GM路由器发送加密密钥和IPSec加密策略，并会在必要时周期性地更新密钥信息。

KS路由器只会向自己信任的GM路由器分发密钥，这意味着GM路由器需要先向KS路由器注册并且通过认证，然后才能获得KS路由器分发的密钥，这样才能实现IPSec的加密服务。

从QoS 角度，GET VPN 使用的两种控制协议为GDOI 协议（使用UDP 848 端口）和ISAKMP 协议（使用UDP 500 端口）。路由器默认会将这两个控制协议标记为CS6，这和IOS处理其他控制和管理协议（如路由协议更新）的方法类似。通过这种方法，私有网络云中的GDOI 和ISAKMP 数据包，都能通过PHB QoS 工具正确地得到处理。只要网络的信任边界设置无误，管理员就不需要专门对这些控制数据包进行重标记。

GM路由器的规模依IPSec的预计吞吐量，以及路由器上运行的其他服务而定，但KS路由器纯粹属于控制设备，它只负责管理GDOI成员和密钥。由于KS路由器不需要转发任何数据，因此KS 路由器一般使用低端的集成服务路由器ISR（如ISR G2 2900 系列）即可。KS 路由器通常部署在企业的数据中心网络，或者网络中其他的安全区域中。表38-2概括了GM路由器和KS路由器的一些重要特性，以及QoS需求。

为了说清GET VPN 的工作方式，可以举一个例子。假设某个私有网络中有20 个站点，它它们使用3 层MPLS 网络来传输数据。如果要在这个网络上部署GET VPN，那么这20 个站点就都属于同一个加密组，因此也就可以向其他站点发送加密的数据包。由此可以看出，这种任意到任意的加密模型与MPLS的固有路由模型相得益彰。

表38-2 GET VPN的网络组成

图38-1 所示为GET VPN 环境下的通用QoS 架构。

图38-1 在GET VPN架构中部署QoS的位置

38.1.3 IP头部保留

GET VPN 与IPSec 隧道模式在设计上存在许多细微的差别，其中之一是后者会使用一个新的IP头部将原始的IP数据包封装进一个新的IP数据包中，这个新IP头部的源、目的IP地址与原始IP头的地址不同，却与IPSec隧道的两端相符。由于缺乏IP头部保留机制，因此这种技术在应用QoS技术时会比较麻烦，因为只有ToS（服务类型）字节默认会被复制到IPSec头部中。

当然，如果要对穿越公共网络（如Internet）的数据进行加密，那么通过VPN连接来隐藏源、目的IP地址还是很有意义的。但在私有网络环境中，这样做则裨益不大，而且增加一层不明确的头部还会增加网络的复杂程度。比如，在MPLS网络中，运营商边缘（PE）路由器通常会在各个VRF（虚拟路由转发）中处理IP路由转发的功能。不过，如果你已经对从一个分支的CE路由器流量进行了加密，那么PE路由器就无法看到原始的IP头部。于是，PE路由器也就只能根据外部的IP地址信息来执行路由决策了。从QoS的角度看，由于原IP头部隐藏在了IPSec隧道模式的头部之中，因此对流量进行分类也变得更加困难了。

有鉴于此，GET VPN 的设计者提出了一种新的网络构建思路，这种思路可以将整个IP 头部保留下来，而只对数据部分进行加密。图38-2 所示为经典IPSec 隧道模式与GET VPN 数据包头部的差别。

图38-2 GET VPN IP数据包头部保留

通过图38-2，不难发现GET VPN 和IPSec 的隧道模式的工作方式有很大不同。因为GET VPN可以保留原始的IP头部，而这简化了PE路由器上的数据包处理过程。比如说，保留原来的IP地址可以简化内部网关协议（IGP）的路由决策过程，也可以使组播流量的处理不受妨碍（前提是MPLS运营商也支持某种组播复制服务），也能够简化QoS的处理过程。

IP头部保留的方式在QoS工具集中发挥了关键性的作用，通过这种方法，不仅ToS字段依然可以保留下来（保留ToS字段是所有IPSec技术的默认行为），而且源、目的IP地址也会被保留下来，于是可供选择的数据包分类方式也就更加宽泛了。也就是说，GET VPN 数据包仍然会被视为ESP IPSec 数据包，而不是TCP 或UDP 数据包。因此，如果管理员还是希望根据TCP或者UDP端口号来执行QoS分类，那么，由于整个TCP/IP头都可以完整地复制并保留进路由器内存中，以便路由器执行分类，因此QoS的预分类特性也依然是有效的。

38.2 GET VPN配置概述

GET VPN 是一项相当复杂的技术，其中包含许多技术和特性，这项技术完全可以用一整本书进行介绍。在本章的这一部分中，我们仅提供GET VPN 的一些基本特性和配置，以便在后文中可以进一步介绍GET VPN 环境下的QoS 设计方案。

38.2.1 密钥服务器的配置

例38-1 演示了在本章中所讨论的GET VPN QoS 设计方案中，如何执行KS 的配置。在这个案例中，充当KS 的设备是一台ISR 2951。

例38-1 GET VPN KS的配置

ISR2951-KS# show running-config

!

crypto isakmp policy 10

encr aes 256

authentication pre-share

!

!

crypto ipsec transform-set MYSET esp-aes esp-sha-hmac

!

crypto ipsec profile GDOI

set security-association lifetime seconds 7200

set transform-set MYSET

!

crypto gdoi group MY-GET-VPN

!

! The identity number must match on all GMs and the KS

identity number 101

server local

rekey lifetime seconds 7200

rekey retransmit 10 number 2

rekey authentication MYPUBKEY rsa GET-VPN-KEY

rekey transport unicast

sa ipsec 1

profile GDOI

match address ipv4 CONTROL-PLANE

从QoS设计的角度看，KS路由器上真心没什么特殊的配置，因为它充当的的确就是一台服务器而已。GET VPN GDOI 控制层（使用UDP 848 端口）和ISAKMP（使用UDP 500 端口）已经默认将所有流量标记为CS6。这两个协议是KS和GM路由器之间执行通信的唯一两种协议。除此之外，只有一点值得注意:与KS路由器连接的2层设备必须和KS路由器之间建立DSCP信任关系，然后才能相互传递数据包（且不修改DSCP的数值）。

一定要确保KS路由器有足够的带宽，向GM路由器更新密钥。带宽需求随网络的规模和策略的数目而变化。不过，KS向GM更新密钥的流量最好在网络中被视为高优先级流量。

如例38-2 中所示，一旦GET VPN 系统建立起来并开始工作，管理员就可以看到有许多组成员注册到了KS路由器上。

例38-2 在KS上查看GDOI的状态

ISR2951# show crypto gdoi ks

Total group members registered to this box:20

Key Server Information For Group MY-GET-VPN:

Group Name　　　　:MY-GET-VPN

Group Identity　　　:101

Group Members　　　:20

IPsec SA Direction　　:Both

ACL Configured　　　:access-list CONTROL-PLANE

现在，KS已经启动并且开始工作，下一步是配置GM路由器。

38.2.2 GM的配置

与KS路由器配置相比，GM上需要执行的IPSec配置不值一提。IPSec转换集（transform set）、IPSec用户文件（profile）、加密访问控制列表（ACL），这些都是从KS路由器推送过来的。例38-3阐述了如何配置GETVPN的GM路由器。注意，执行这些配置的是一台ISR 3925。

例38-3 配置组成员路由器

ISR3925-GM# show running-configuration

!

crypto isakmp policy 10

encr aes 256

authentication pre-share

crypto isakmp key cisco123 address 0.0.0.0

!

crypto gdoi group MY-GET-VPN

identity number 101

server address ipv4 172.16.1.254

!

crypto map MYMAP gdoi fail-close

match address PROTECT-KS

activate

crypto map MYMAP 10 gdoi

set group MY-GET-VPN

!

interface GigabitEthernet0/0

ip address 192.168.50.2 255.255.255.0

crypto map MYMAP

从GS上面可以看出，这台设备已经成功第注册在了KS路由器上，如例38-4所示。

例38-4 确认GM的注册情况

ISR3925-GM# show crypto gdoi

GROUP INFORMATION

Group Name　　　　:MY-GET-VPN

Group Identity　　　:101

Crypto Path　　　　:ipv4

Key Management Path　　:ipv4

Rekeys received　　　:0

IPsec SA Direction　　:Both

Group Server list　　:172.16.1.254

Group member　　　:192.168.50.2

Version　　　　:1.0.1

Registration status　:Registered

Registered with　　:172.16.1.254

Re-registers in　　:72 sec

Succeeded registration:28

Attempted registration:28

Last rekey from　　:0.0.0.0

Last rekey seq num:0

Multicast rekey rcvd　:0

allowable rekey cipher:any

allowable rekey hash　:any

allowable transformtag:any ESP

Rekeys cumulative

Total received　　:0

After latest register:0

Rekey Received　　:never

ACL Downloaded From KS 172.16.1.254:

access-list　deny pim any any

access-list　deny udp any any port = 500

access-list　deny udp any any port = 848

access-list　permit ip any any

此时，GET VPN 系统已经开始运转。虽然IPSec 加密密钥、加密ACL 等都是由KS 负责推送的，但QoS的配置却并不是由KS路由器集中管理的。下面我们会介绍如何在这个GET VPN中设计QoS方案。

38.3 GET VPN的QoS配置

由于GET VPN 不借助隧道技术，因此它的QoS 配置步骤较其他类型的VPN 系统要简单得多。例如，在DMVPN 环境中，每个与hub 路由器相连的DMVPN spoke 上都需要应用QoS特性。而这必须要使用分级的QoS策略（在父策略中使用隧道整形器，而在子策略中应用各类QoS 工具）才能实现。但若使用GET VPN，这些都是浮云。

GET VPN 的概念都是围绕着“共享的IPSec 组域”建立起来的，这意味着GET VPN 环境中没有所谓隧道的概念。由于在GET VPN 中不存在隧道，因此管理员只需要在面向GET VPN的物理接口上，应用合理的QoS服务策略即可。就像前文中介绍的配置那样，QoS配置会被添加到MPLS CE 或私有WAN 边界路由器上。

在GET VPN 网络中配置QoS 的步骤可以总结如下所示。

GM路由器:

1.配置class map。

2.配置policy map。

3.将策略映射关联到物理的WAN接口。

KS上不需要执行什么特殊的QoS配置，不过管理员还是应该:

1.确认设备具备传输KS控制流量所需的DSCP信任关系；

2.确认设备具备足够的带宽来传输KS控制流量（特别是GDOI更新密钥的流量）。

这些步骤会在下一节中进行详细的介绍。在下一节中，我们会介绍如何在GET VPN 系统中的GM路由器上使用三种不同的QoS模型（4类模型、8类模型和12类模型）。

38.3.1 使用4类的模型配置GM路由器

继续前文中配置GM路由器的案例（见例38-3），现在开始在GM的配置添加QoS部分的内容。和本书前面的示例一样，hub 路由器上已经配置了合理的class map（和本书第28章中定义的相同）。

这个配置的下一步是建立policy map，如例38-5 所示。

注释:如果CE/GM路由器接口和PE路由器接口带宽是匹配的，那么这样的GET VPN环境完全可以不必配置分层的整形器。不过，如果存在带宽不匹配的情况，就需要通过分层的整形器向CE/GM路由器接口施压。在下面的示例中，我们没有使用分层整形器，但如有需要，管理员完全可以在这个配置中添加整形器，并将下面的policy map作为整形器的子策略。

例38-5 配置4类的GET VPN QoS Policy Map

ISR3925-GM(config)# policy-map 4-CLASS-QOS-GETVPN

! Creates the four-class policy map

ISR3925-GM(config-pmap)# class REALTIME

ISR3925-GM(config-pmap-c)# priority percent 33

ISR3925-GM(config-pmap)# class CONTROL

ISR3925-GM(config-pmap-c)# bandwidth percent 7

ISR3925-GM(config-pmap)# class TRANSACTIONAL-DATA

ISR3925-GM(config-pmap-c)# bandwidth percent 35

ISR3925-GM(config-pmap-c)# fair-queue

ISR3925-GM(config-pmap)# class class-default

ISR3925-GM(config-pmap-c)# bandwidth percent 25

ISR3925-GM(config-pmap-c)# fair-queue

ISR3925-GM(config-pmap-c)# random-detect

可以使用下列命令来验证例38-5中的配置。

■ show class-map

■ show policy-map

最后，将policy map 应用到广域网接口，如例38-6 所示。

例38-6 将policy map应用到WAN接口上

ISR3925-GM(config)# interface GigabitEthernet0/0

ISR3925-GM(config-if)# ip address 192.168.50.2 255.255.255.0

ISR3925-GM(config-if)# crypto map MYMAP

ISR3925-GM(config-if)# service-policy output 4-CLASS-QOS-GETVPN

! Attaches the four-class QoS policy in the outbound direction to

! the WAN interface

可以使用命令show policy-map interface GigabitEthernet0/0 来检验例38-6 中的配置。

38.3.2 使用8类的模型配置GM路由器

8类模型的配置方法与前面的4类模型非常类似。我们在这里同样假设设备上已经配置了合理的class map（见例38-7）。

例38-7 创建8类的policy map

ISR3925-GM(config )# policy-map 8-CLASS-QOS-GETVPN

! Creates the eight-class policy map

ISR3925-GM(config-pmap)# class VOICE

ISR3925-GM(config-pmap-c)# priority percent 10

ISR3925-GM(config-pmap)# class MULTIMEDIA-CONFERENCING

ISR3925-GM(config-pmap-c)# priority 23

ISR3925-GM(config-pmap)# class NETWORK-CONTROL

ISR3925-GM(config-pmap-c)# bandwidth percent 5

ISR3925-GM(config-pmap)# class SIGNALING

ISR3925-GM(config-pmap-c)# bandwidth percent 2

ISR3925-GM(config-pmap)# class MULTIMEDIA-STREAMING

ISR3925-GM(config-pmap-c)# bandwidth percent 10

ISR3925-GM(config-pmap-c)# fair-queue

ISR3925-GM(config-pmap-c)# random-detect dscp-based

ISR3925-GM(config-pmap)# class TRANSACTIONAL-DATA

ISR3925-GM(config-pmap-c)# bandwidth percent 24

ISR3925-GM(config-pmap-c)# fair-queue

ISR3925-GM(config-pmap-c)# random-detect dscp-based

ISR3925-GM(config-pmap)# class SCAVENGER

ISR3925-GM(config-pmap-c)# bandwidth percent 1

ISR3925-GM(config-pmap)# class class-default

ISR3925-GM(config-pmap-c)# bandwidth percent 25

ISR3925-GM(config-pmap-c)# fair-queue

ISR3925-GM(config-pmap-c)# random-detect

可以使用如下命令检验例38-7的配置。

■ show class-map

■ show policy-map

接下来的工作和前文相同，管理员现在可以将新的policy map 应用到GET VPN 的WAN接口上，如例38-8所示。

例38-8 配置8类模型的QoS的policy map

ISR3925-GM(config)# interface GigabitEthernet0/0

ISR3925-GM(config-if)# ip address 192.168.50.2 255.255.255.0

ISR3925-GM(config-if)# crypto map MYMAP

ISR3925-GM(config-if)# service-policy output 8-CLASS-QOS-GETVPN

! Attaches the 8-Class QoS policy in the outbound direction to

! the WAN interface

可以使用命令show policy-map interface GigabitEthernet0/0 来检验例38-8 中的配置。

38.3.3 使用12类的模型配置GM路由器

同样，12类模型和前面介绍的4类和8类模型也非常类似。我们在这里同样假设设备上已经配置了合理的class map。下面的工作直接从创建policy map 开始，如例38-9 所示。

例38-9 配置12类模型的GET VPN QoS的policy map

ISR3925-GM(config)# policy-map 12-CLASS-QOS-GETVPN

! Creates the 12-class policy map

ISR3925-GM(config-pmap)# class VOICE

ISR3925-GM(config-pmap-c)# priority percent 10

ISR3925-GM(config-pmap)# class REALTIME-INTERACTIVE

ISR3925-GM(config-pmap-c)# priority percent 13

ISR3925-GM(config-pmap)# class BROADCAST-VIDEO

ISR3925-GM(config-pmap-c)# priority 10

ISR3925-GM(config-pmap)# class NETWORK-CONTROL

ISR3925-GM(config-pmap-c)# bandwidth percent 2

ISR3925-GM(config-pmap)# class SIGNALING

ISR3925-GM(config-pmap-c)# bandwidth percent 2

ISR3925-GM(config-pmap)# class NETWORK-MANAGEMENT

ISR3925-GM(config-pmap-c)# bandwidth percent 3

ISR3925-GM(config-pmap)# class MULTIMEDIA-CONFERENCING

ISR3925-GM(config-pmap-c)# bandwidth percent 10

ISR3925-GM(config-pmap-c)# fair-queue

ISR3925-GM(config-pmap-c)# random-detect dscp-based

ISR3925-GM(config-pmap)# class MULTIMEDIA-STREAMING

ISR3925-GM(config-pmap-c)# bandwidth percent 10

ISR3925-GM(config-pmap-c)# random-detect dscp-based

ISR3925-GM(config-pmap-c)# fair-queue

ISR3925-GM(config-pmap)# class TRANSACTIONAL-DATA

ISR3925-GM(config-pmap-c)# bandwidth percent 10

ISR3925-GM(config-pmap-c)# fair-queue

ISR3925-GM(config-pmap-c)# random-detect dscp-based

ISR3925-GM(config-pmap)# class BULK-DATA

ISR3925-GM(config-pmap-c)# bandwidth percent 4

ISR3925-GM(config-pmap-c)# fair-queue

ISR3925-GM(config-pmap-c)# random-detect dscp-based

ISR3925-GM(config-pmap)# class SCAVENGER

ISR3925-GM(config-pmap-c)# bandwidth percent 1

ISR3925-GM(config-pmap)# class class-default

ISR3925-GM(config-pmap-c)# bandwidth percent 25

ISR3925-GM(config-pmap-c)# fair-queue

ISR3925-GM(config-pmap-c)# random-detect

可以使用下列命令验证例38-9的配置。

■ show class-map

■ show policy-map

最后，需要把policy map 应用到WAN 接口上，如例38-10 所示。

例38-10 将Policy Map应用到GET VPN的WAN接口上

ISR3925-GM(config)# interface GigabitEthernet0/0

ISR3925-GM(config-if)# ip address 192.168.50.2 255.255.255.0

ISR3925-GM(config-if)# crypto map MYMAP

ISR3925-GM(config-if)# service-policy output 12-CLASS-QOS-GETVPN

! Attaches the 12-Class QoS policy in the outbound direction to

! the WAN interface

38.3.4 确认QoS策略

在创建完QoS配置并将其应用到路由器后，最后一步是确认上述配置已经生效。最有效的命令是show policy-map interface x/y。例38-11 所示为在前面配置的8 类模型中，该命令的输出信息。

例38-11 show policy-map interface x/y 的输出信息

ISR3925-GM# show policy-map interface GigabitEthernet0/0/0

GigabitEthernet0/0/0

Service-policy output:8-CLASS-QOS-GETVPN

queue stats for all priority classes:

Queueing

queue limit 512 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 575850/749756700

Class-map:VOICE (match-all)

194950 packets, 253824900 bytes

30 second offered rate 4486000 bps, drop rate 0000 bps

Match:dscp ef (46)

Priority:10% (10000 kbps), burst bytes 250000,b/w exced drops:0

Class-map:MULTIMEDIA-CONFERENCING (match-any)

380900 packets, 495931800 bytes

30 second offered rate 8966000 bps, drop rate 0000 bps

Match:dscp af41 (34)

Match:dscp af42 (36)

Match:dscp af43 (38)

Priority:23% (23000 kbps),burst bytes 575000,b/w exceed drops:0

Class-map:NETWORK-CONTROL (match-all)

5314 packets, 5186815 bytes

30 second offered rate 101000 bps, drop rate 0000 bps

Match:dscp cs6 (48)

Queueing

queue limit 64 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 5263/5181877

bandwidth 5% (5000 kbps)

Class-map:SIGNALING (match-all)

5905 packets, 7688310 bytes

30 second offered rate 136000 bps, drop rate 0000 bps

Match:　dscp cs3 (24)

Queueing

queue limit 64 packets

(queue depth/total drops/no-buffer drops) 0/0/0

(pkts output/bytes output) 5905/7688310

bandwidth 2% (2000 kbps)

Class-map:MULTIMEDIA-STREAMING (match-any)

389905 packets, 507656310 bytes

30 second offered rate 8973000 bps, drop rate 0000 bps

Match:　dscp af31 (26)

Match:　dscp af32 (28)

Match:　dscp af33 (30)

Queueing

queue limit 64 packets

(queue depth/total drops/no-buffer drops/flowdrops) 8/31/0/0

(pkts output/bytes output) 389874/507615948

bandwidth 10% (10000 kbps)

Fair-queue:per-flow queue limit 16 packets

Exp-weight-constant:4 (1/16)

Mean queue depth:8 packets

dscp　Transmitted Random drop　Tail/Flow　drop Min　Max Mark

pkts/bytes　pkts/bytes　pkts/bytes　th　th　prob

af31 387699/504784098 0/0　　　0/0　　28　32　1/10

af32　1249/1626198　0/0　　　0/0　　24　32　1/10

af33　926/1205652　0/0　　　0/0　　20　32　1/10

Class-map:TRANSACTIONAL-DATA (match-any)

389888 packets, 507634176 bytes

30 second offered rate 8967000 bps, drop rate 0000 bps

Match:　dscp af21 (18)

Match:　dscp af22 (20)

Match:　dscp af23 (22)

Queueing

queue limit 99 packets

(queue depth/total drops/no-buffer drops/flowdrops) 0/0/0/0

(pkts output/bytes output) 389888/507634176

bandwidth 24% (24000 kbps)

Fair-queue:per-flow queue limit 24 packets

Exp-weight-constant:4 (1/16)

Mean queue depth:6 packets

dscp　Transmitted Random drop　Tail/Flow　drop Min　Max Mark

pkts/bytes　pkts/bytes　pkts/bytes　th　th　prob

af21 388105/505312710 0/0　　　0/0　　42　49　1/10

af22　1047/1363194　0/0　　　0/0　　36　49　1/10

af23　736/958272　0/0　　　0/0　　30　49　1/10

Class-map:SCAVENGER (match-all)

194950 packets, 253824900 bytes

30 second offered rate 4486000 bps, drop rate 0000 bps

Match:　dscp cs1 (8)

Queueing

queue limit 64 packets

(queue depth/total drops/no-buffer drops) 3/0/0

(pkts output/bytes output) 194950/253824900

bandwidth 1% (1000 kbps)

Class-map:class-default (match-any)

389905 packets, 507653837 bytes

30 second offered rate 8973000 bps, drop rate 0000 bps

Match:any

Queueing

queue limit 104 packets

(queue depth/total drops/no-buffer drops/flowdrops) 0/0/0/0

(pkts output/bytes output) 389905/507653837

bandwidth 25% (25000 kbps)

Fair-queue:per-flow queue limit 26 packets

Exp-weight-constant:4 (1/16)

Mean queue depth:6 packets

class　Transmitted Random drop Tail/Flow　drop Min Max Mark

pkts/bytes　pkts/bytes　pkts/bytes　　th　th　prob

0　389905/507653837　0/0　　0/0　　　26　52　1/10

1　　0/0　　　0/0　　0/0　　　29　52　1/10

2　　0/0　　　0/0　　0/0　　　32　52　1/10

3　　0/0　　　0/0　　0/0　　　35　52　1/10

4　　0/0　　　0/0　　0/0　　　39　52　1/10

5　　0/0　　　0/0　　0/0　　　42　52　1/10

6　　0/0　　　0/0　　0/0　　　45　52　1/10

7　　0/0　　　0/0　　0/0　　　48　52　1/10

本节阐述了如何创建并应用本书通篇介绍的4类、8类和12类QoS模型。还有一点不得不提，那就是在GET VPN 环境中，何时需要使用命令qos pre-classify。这一点将在下一节中进行介绍。

38.3.5 何时、如何使用QoS预分类特性

设计原则:

■ 若需求为基于源、目的IP地址来分类数据包，那么可以不使用QoS预分类，但仍然建议采用这种方式；

■ 若需求为基于TCP或者UDP端口号来分类数据包，则必须使用QoS预分类；

■ 在GET VPN 环境的一般原则是，始终启用QoS 预分类特性。

在所有IOS上实施IPSec时，路由器总是会将原IP头部中的DSCP标记复制到外部的IPSec 头部中。这条原则同样适用GET VPN。但在GET VPN 中，整个原IP 头部都会被保留下来，而这意味着如果QoS分类是依靠源或目的IP地址来执行的，那么无需使用QoS预分类特性也可以实现QoS 分类。GET VPN 固然为分类提供了更多选择，但若管理员希望根据数据包的UDP、TCP 端口号来执行分类，GET VPN 恐怕帮助不大。

即使GET VPN 保留了原始IP 头部，IP 头部的协议类型依然是50（ESP）。而TCP 的协议类型标识是6，UDP的协议类型标识是17，这意味着若不借助QoS预分类技术，设备就无法基于UDP或者TCP端口号来执行分类。如前文中的第36章所述，QoS预分类特性会让路由器复制数据包的原TCP/IP 头部，以备其此后执行QoS 分类之用。如果在crypto map 中使用这项特性，设备就可以基于TCP、UDP端口号来执行QoS分类。

例38-12显示了如何在GM路由器上启用这项特性。

例38-12 在GM路由器上配置QoS预分类特性

ISR3925-GM(config)# crypto map MYMAP 10 gdoi

ISR3925-GM(config-crypto-map)# qos pre-classify

最理想的方法是，无论何时都启用QoS预分类特性，哪怕这个网络根本不需要基于TCP或UDP端口号来对数据包进行分类。因为这个特性对于路由器的性能影响极小，所以在GS路由器上没有理由不启用这个特性。有一点必须说明，即使管理员有可能在加密路由器上使用qos pre-classify，鉴于执行QoS是一种逐跳的行为，管理员还是无法在所有的中间路由器上（如在MPLS云中）都基于TCP和UDP端口号对数据包进行分类。

38.4 将GET VPN与DMVPN结合起来的案例

这种组合确实有点怪异，但是在设计VPN 网络时同时使用GET VPN 和DMVPN 确实相当常见。从网络响应时间的角度，DMVPN在spoke端到spoke端通信时存在一个重要缺陷。从设计的角度，动态隧道的建立和生效需要1到2秒的时间。虽然DMVPN的spoke端与hub端之间始终存在一条永久的IPSec连接，但spoke端到spoke端的隧道是根据需要动态建立。因此，spoke端到spoke端的隧道延迟既不是NHRP导致的，也不是GRE隧道封装数据所导致的，而是两个spoke 端交换ISAKMP 信息并建立IPSec SA 的过程所导致的。

这一段小小的延迟很容易被用户所察觉。例如，当用户使用VoIP电话从一个spoke端拨打另一个spoke端，在建立动态加密VPN隧道导致的这段微小的延迟，有可能会导致源端到目的端的信号中断。因为远端电话不会像用户预期的那样立刻响起，所以用户会感受到网络的延迟。

这就是人们为什么会将这两种VPN技术结合起来使用。如果单独使用DMVPN来建立GRE隧道，而暂不考虑IPSec，那么在spoke两端建立VPN隧道的时间就会明显加快。实际上，在只使用GRE的环境中，spoke到spoke之间的通信几乎根本没有延迟。这种方法唯一的问题是不提供任何数据加密。要想解决这个问题，管理员就可以在GRE隧道内部运行GET VPN。这样一来，spoke端和hub端之间的数据就会由组SA加密，而不需要等待隧道建立。加密的数据包只会通过DMVPN GRE 隧道进行传输。于是，DMVPN 的spoke 端路由器也就成了GET VPN 的GM 路由器，负责加密数据并将其封装到正确的GRE 隧道中。

显然，这种方法不同于一般的DMVPN设计方案。传统的DMVPN环境会用IPSec加密整个GRE 数据包，而很少关注GRE 隧道中的数据流。不过，在使用GET VPN 时，并不是GRE隧道本身会被加密，GET VPN 加密的是在GRE 隧道中的数据。事实上，在这个解决方案中， DMVPN可以让远端spoke之间仿佛是通过一个私有网络建立了连接。准确地说，在这种环境下，是DMVPN方案中的GRE隧道让中间的网络云貌似一个私有网络而不是公共网络。

这种设计方案的效果是，spoke与spoke之间可以高速建立隧道，同时数据的安全性也可以通过IPSec加密得到保护。因此，这种方案可以大大提升用户体验。

38.5 在部署GET VPN时，需要与服务提供商合作

设计原则:

■ 确保在整个MPLS WAN 网络中，端到端的DSCP 处理方式是连续（相同）的。

QoS的工作是以跳为单位的，也就是说网络中的每一跳都必须应用QoS策略。这一章提供QoS工具，主要是为了解决数据包离开广域网接口时，GM路由器出现阻塞的问题。要想实现真正意义上的端到端QoS策略，MPLS运营商也要在他们的网络上实施一致的QoS策略，以匹配企业网络中部署的策略。

很多时候，想要让企业的QoS策略与服务提供商提供的策略相匹配是很困难的，因此有时，双方必须都作出让步，达成一种双方都能接受的混合模型。

通常的建议是，管理员要为各类应用映射合理的DSCP值，这样队列策略才能自始至终保持不变。例如，在MPLS环境中，CE到PE到P到PE到CE的DSCP处理就应该是连续的。

38.6 小结

本章重点是如何在GET VPN（也称作无隧道VPN）网络中设计QoS 方案。GET VPN 技术与DMVPN不同，它更适合私有网络拓扑（如MPLS网络）。GET VPN使用了组加密的概念，因此它并不需要建立点对点的安全关联，它会使用组SA实现任意站点到任意站点的加密。

GET VPN还有一个优势，那就是它在加密过程中会保留IP头部。因此，在执行QoS分类时，设备就可以不仅依赖DSCP或ToS值，也可以使用源和目的IP地址进行分类。如果需要根据其他参数执行分类（如TCP、UDP 端口号），那么管理员就需要在crypto map 中使用QoS 的预分类技术。

本章以三个QoS模型（也就是QoS的4类模型、8类模型和12类模型）为例，描述了如何在GET VPN GM 路由器上实施QoS 技术。因为GET VPN 不依赖于隧道技术，所以在任意一种QoS服务模型中，管理员配置的策略都只需应用在WAN接口上，而不需要将它们嵌套在一个父系整形策略之内。

本章还通过一个现实的例子，解释了如何将DMVPN 与GET VPN 技术结合起来，在spoke端到spoke端穿越公共网络进行通信的过程中，全面提升用户体验。在这个例子中， DMVPN 的作用是提供spoke 端之间的GRE 隧道连接，而GET VPN 则用来这些加密隧道中的流量。

最后，建议企业网络技术人员与服务提供商进行合作，以便了解服务提供商采用的QoS模型以及它们采取的流量标记方式，这些信息会对穿越服务提供商的网络构成潜在的影响。

38.7 扩展阅读

Cisco GET VPN主页:http://www.cisco.com/go/getvpn

GET VPN Design and Implementation Guide（GET VPN设计与实施指南）:http://www.cisco.com/en/US/prod/collateral/vpndevc/ps6525/ps9370/ps7180/GETVPN_DIG_version_1_0_External.pdf

RFC 3547, GDOI:http://www.ietf.org/rfc/rfc3547.txt

第39章 家庭办公环境VPN网络中的QoS案例分析

鉴于Tifosi Software 的云计算产品屡获佳绩，该公司现决定开放一个新的客户服务中心系统来提高客户的整体满意度，并降低成本。此前，Tifosi将客户服务中心外包给了亚洲一家颇具口碑的企业。但随着新技术的产生，首席信息官罗德·布拉顿认为，让客户服务中心的员工在家办公是未来的发展方向。总体而言，这家企业希望聘请200名电话客服人员，其中100名客服人员在北美，50名在亚洲，50名在欧洲（“日不落”的不间断服务模式）。其目的是让所有的客服中心的人都能在家办公，以便进一步降低成本。

39.1 构建技术解决方案

虽然罗德对这种家庭客服中心的操作模式充满信心，但是他并不清楚如何在技术上实现这种效果。其中一个最为关键的问题是，如果让在家办公的员工通过公共Internet连接进来，用户体验是否会受到影响。具体点说，罗德担心通过这种方式打进电话的用户会因为语音或视频的质量不佳而大发雷霆，导致这些用户对这个企业的技术支持能力产生质疑。

罗德与Tifosi的高级网络架构师汤姆·斯帕格蒂就这个问题进行了探讨，并要求他拿出一个能够支持这个提案的解决方案。由于Tifosi的服务中心要使用本地的互联网进行连接，所以汤姆建议使用Cisco的DMVPN解决方案，因为DMVPN不仅易于管理，而且还能直接部署在家用路由器环境中，同时这个解决方案支持针对每条隧道采用不同的QoS技术。

汤姆的团队建议Tifosi严格遵循Cisco提出的虚拟办公室（CVO）部署模型。在这个模型中，将一台小型IOS路由器部署在远程工作人员的家中，并级联当地ISP提供的路由器，如图39-1 所示。该团队还建议在企业总部使用一对冗余的ASR 1002 路由器，并为每个家庭的客户中心的客户代表配备一台ISR 881 路由器。

图39-1 Tifosi要求建立的虚拟办公室

39.2 QoS的应用需求

为了给Tifosi的客户提供无差异的体验，家庭办公的解决方案需要支持下列应用:

■ 思科代理桌面（CAD）；

■ 使用iLBC 编解码器的Cisco IP 电话；

■ 带视频功能的WebEx ；

■ Cisco TelePresence 视频会议；

■ Cisco内部交流的Jabber及IP软电话。

为了满足这些不同的语音、视频和数据通信的需求，每个家庭客服中心的上下行链路带宽都不应小于10 Mbit/s。虽然大多数ISP 都不能在Internet 上支持任何类型的QoS 技术，以解决Tifosi路由器可能出现的拥塞问题，但在（面向DMVPN网络的）前端路由器上以及881分支路由器上（面向ISP提供的家用路由器）实施QoS策略还是非常有必要的。由于家庭客服人员会使用到各类的多媒体应用，因此无论在家庭路由器上还是在DMVPN核心路由器上，都推荐使用8类的QoS模型。这样做有两大好处:

■ 可以让Tifosi各地网络中的QoS策略保持一致；

■ 可以满足远程客服中心人员的核心需求。

总之，无论在前端路由器还是ISR 881家用代理路由器上，8类模型的设置方式如下所示。

■ 语音类:标记为EF，PHB为EF，提供10%的严格优先级队列。

■ 实时互动类（以支持按需的TelePresense视频）:标记为CS4，PHB为EF，提供23%的严格优先级队列。

■ 信令类（以便在DMVPN隧道中使用EIGRP路由）:标记为CS3，提供2%的有保障带宽。

■ 多媒体会议类（以满足Cisco Jabber、WebEx 及其他视频会议的需求）:标记为AF41，处理方式为AF PHB，提供10%的有保障带宽，并启用基于DSCP 的WRED。

■ 业务性数据类（主要用来为Cisco Agent Desktop 提供服务）:标记为AF21，处理方式为AF PHB，提供25%的有保障带宽，并启用基于DSCP 的WRED。

■ 大数据类:标记为AF11，处理方式为AF PHB，提供4%的有保障带宽，并启用基于DSCP的WRED。

■ 清道夫类:标记为CS1并将带宽限制在1%以内。

■ 尽力而为传输类:所有其他应用继续接收一项默认服务，该服务所占用的带宽小于链路总带宽的1/4。

39.3 QoS配置

虽然在前文中，我们假设ISP不能为穿越Internet的流量提供任何级别的QoS机制，但网络中的每一台路由器都需要支持拥塞管理。配置DMVPN网络的工作，既需要在前端ASR 1002 路由器上进行，也需要在客服人员家中的ISR 881 路由器上执行。

39.3.1 前端路由器的配置

前端路由器的配置严格遵循了第37章中介绍的解决方案。该解决方案以隧道（SA）为单位，可以针对每个站点执行不同的QoS机制。为了达到这种效果，需要在mGRE隧道接口嵌套一个整形器（作为父系策略），当出现拥塞时，设备会使用8类的QoS策略。在这种情况下，只有一类用户，所以设备也只会实施8类的QoS模型。于是，WAN前端的汇聚带宽被定义为了1Gbit/s，数据中心也会共享这段带宽。预计这段带宽完全可以满足家庭客户中心的需求。

配置工作的第一步是按照前面介绍的8 类模型来创建class map，如例39-1 所示。

例39-1 定义class map（default类已预定义）

ASR1000(config)# class-map match-all VOICE

ASR1000(config-cmap)# match dscp ef

ASR1000(config-cmap)# class-map match-all REALTIME-INTERACTIVE

ASR1000(config-cmap)# match dscp cs4

ASR1000(config-cmap)# class-map match-any SIGNALING

ASR1000(config-cmap)# match dscp cs3

ASR1000(config-cmap)# class-map match-all MULTIMEDIA-CONFERENCING

ASR1000(config-cmap)# match dscp af41

ASR1000(config-cmap)# class-map match-any TRANSACTIONAL-DATA

ASR1000(config-cmap)# match dscp af21

ASR1000(config-cmap)# class-map match-any BULK-DATA

ASR1000(config-cmap)# match dscp af11

ASR1000(config-cmap)# class-map match-any SCAVANGER

ASR1000(config-cmap)# match dscp cs1

! Defines the 8 classes on the headend

在创建好class map 之后，需要创建使用这些类的子策略，如例39-2 所示。注意，应该先配置子策略，再配置父策略，否则路由器会拒绝未配置的子策略。

例39-2 创建子policy map

ASR1000(config)# policy-map 8-CLASS-CHILD

ASR1000(config-pmap)# class VOICE

ASR1000(config-pmap-c)# priority percent 10

! Assign voice 10 % in strict-priority queue

ASR1000(config-pmap-c)# class REALTIME-INTERACTIVE

ASR1000(config-pmap-c)# priority 23

! Assign voice 23 % in strict-priority queue

ASR1000(config-pmap-c)# class SIGNALING

ASR1000(config-pmap-c)# bandwidth percent 2

! Signaling is given 2%

ASR1000(config-pmap-c)# class MULTIMEDIA-CONFERENCING

ASR1000(config-pmap-c)# bandwidth percent 10

ASR1000(config-pmap-c)# fair-queue

ASR1000(config-pmap-c)# random-detect dscp-based

! Multimedia conf is given 10% WFQ with WRED based on DSCP

ASR1000(config-pmap-c)# class TRANSACTIONAL-DATA

ASR1000(config-pmap-c)# bandwidth percent 25

ASR1000(config-pmap-c)# fair-queue

ASR1000(config-pmap-c)# random-detect dscp-based

! Transactional data is given 25% WFQ with WRED based on DSCP

ASR1000(config-pmap-c)# class BULK-DATA

ASR1000(config-pmap-c)# bandwidth percent 4

ASR1000(config-pmap-c)# fair-queue

ASR1000(config-pmap-c)# random-detect dscp-based

! Bulk data is only given 4% WFQ with WRED

ASR1000(config-pmap-c)# class SCAVENGER

ASR1000(config-pmap-c)# bandwidth percent 1

! Scavenger is given only 1% of available BW

ASR1000(config-pmap-c)# class class-default

ASR1000(config-pmap-c)# bandwidth percent 25

ASR1000(config-pmap-c)# fair-queue

ASR1000(config-pmap-c)# random-detect

! Best effort in the default class is given 25% WFQ with WRED

第三步是创建父policy map，这个策略是对DMVPN 网络中各个spoke 执行人工限制的核心步骤，方法如例39-3所示。

例39-3 创建父policy map

ASR1000(config)# policy-map 8-CLASS-PARENT

ASR1000(config-pmap)# class class-default

ASR1000(config-pmap-c)# shape average 10000000

! Create backpressure at 10 Mbps downstream to each agent

ASR1000(config-pmap-c)# service-policy 8-CLASS-CHILD

! Use a nested service policy to call the "child" policy

在创建完policy map 和class map 之后，一定要验证一下配置是否正确。管理员可以通过下面两条命令验证之前的配置。

■ show class-map

■ show policy-map

最后一步就是将父policy map 应用到mGRE 接口上，如例39-4 所示。

例39-4 将policy map应用到mGRE接口上

ASR1000(config)# interface Tunnel10

ASR1000(config-if)# ip address 10.1.1.254 255.255.255.0

!

<snip>

!

ASR1000(config-if)# ip nhrp map group GROUP1 service-policy output 8-CLASS-PARENT

! Associate the policy map to the NHRP Group

ASR1000(config-if)# ip nhrp network-id 12300

ASR1000(config-if)# tunnel source GigabitEthernet0/0/0

ASR1000(config-if)# tunnel mode gre multipoint

ASR1000(config-if)# tunnel key 3210

ASR1000(config-if)# tunnel protection ipsec profile TIFOSI

可以使用命令show policy-map interface命令来检验例39-4中的配置。请注意，在本例中，我们没有在连接WAN的物理接口上部署任何出站方向的QoS策略。本例中使用的ASR1002物理连接速度为1Gbit/s，Tifosi的ISP提供的速率也是1Gbit/s，这意味着该方向上并不存在带宽不匹配的情况。此外，如果网络在未来出现了带宽不匹配的情形，管理员也可以在物理接口上应用QoS策略，但最初实施QoS时，设计方案中并不包含这部分内容。

39.3.2 家庭办公环境的路由器（Spoke）配置

读者或许已经注意到了一个现象，那就是在配置前端DMVPN路由器这一方面，上文中介绍的流程与第37中介绍的方法相当合拍。而在下文中，我们将介绍如何在分支路由器上配置QoS。

分支机构的主要挑战在于，家庭办公室的路由器与访问Internet的可用带宽之间，速率几乎肯定是不匹配的。例如，ISR 881路由器用100Mbit/s的物理接口连接到ISP运营商的路由器，而Tifosi 只向ISP 购买了10Mbit/s 的连接。显然，ISR 881 原本可以以超过10Mbit/s 的速率向Internet发送流量，但它并不清楚上游路由器出现了拥塞的情况，而这会严重影响应用质量和用户体验。因此，虽然对穿越Internet的流量制定一些特殊的QoS处理方式基本不太可能，但Tifosi公司至少可以确保在家庭办公的员工不会受到速率不匹配的影响。

切记，对于使用IOS系统的路由器而言，它们只有在检测到接口出现拥塞时，才会开始使用QoS拥塞管理工具。例如，如果接口的速率为100Mbit/s，但是路由器发送数据的速率低于100Mbit/s（如15Mbit/s），那么路由器就不会运行QoS，因为它认为此时没有必要使用QoS；由于没有数据包遭到丢弃，所以网络中也就没有出现拥塞。在本例中，只有当ISP提供的路由器与Internet 之间链路出现拥塞时，数据包才会被丢弃。读者也许会认为，在Cisco 881 路由器的接口上使用命令bandwidth xxx 来降低接口带宽，才是最简单的解决问题之道。但问题在于，这条命令并不能真正改变接口的带宽，因此完全不能解决这个问题（接口配置模式下的bandwidth语句，其主要作用是影响路由协议计算路径的方式）。此时，应该采用的解决方案是使用与前端路由器中相似的分层整形器，如图39-2所示。

图39-2 在家庭网络中解决带宽的问题

首先，配置与前端路由器相同的class map 和policy map。每台分支路由器上都应启用例39-5中的配置。再次重申，分支机构路由器需要使用的是8类QoS模型。

例39-5 创建与此前定义的8类模型相对应的class map

ISR881(config)# class-map match-all VOICE

ISR881(config-cmap)# match dscp ef

ISR881(config-cmap)# class-map match-all REALTIME-INTERACTIVE

ISR881(config-cmap)# match dscp cs4

ISR881(config-cmap)# class-map match-any SIGNALING

ISR881(config-cmap)# match dscp cs3

ISR881(config-cmap)# class-map match-all MULTIMEDIA-CONFERENCING

ISR881(config-cmap)# match dscp af41

ISR881(config-cmap)# class-map match-any TRANSACTIONAL-DATA

ISR881(config-cmap)# match dscp af21

ISR881(config-cmap)# class-map match-any BULK-DATA

ISR881(config-cmap)# match dscp af11

ISR881(config-cmap)# class-map match-any SCAVANGER

ISR881(config-cmap)# match dscp cs1

! Defines the eight classes on each spoke router

如前文所述，下一步的配置工作是创建CBWFQ这一子策略，一旦父整形器检测到网络中出现了拥塞，设备就会对不同应用采取CBWFQ技术。例39-6所示即为具体的配置方式。

例39-6 创建与此前定义的8类模型相对应的policy map子策略

ISR881(config)# policy-map 8-CLASS-CHILD

ISR881(config-pmap)# class VOICE

ISR881(config-pmap-c)# priority percent 10

! Assign voice 10 % in strict-priority queue

ISR881(config-pmap-c)# class REALTIME-INTERACTIVE

ISR881(config-pmap-c)# priority 23

! Assign voice 23 % in strict-priority queue

ISR881(config-pmap-c)# class SIGNALING

ISR881(config-pmap-c)# bandwidth percent 2

! Signaling is given 2%

ISR881(config-pmap-c)# class MULTIMEDIA-CONFERENCING

ISR881(config-pmap-c)# bandwidth percent 10

ISR881(config-pmap-c)# fair-queue

ISR881(config-pmap-c)# random-detect dscp-based

! Multimedia conf is given 10% WFQ with WRED based on DSCP

ISR881(config-pmap-c)# class TRANSACTIONAL-DATA

ISR881(config-pmap-c)# bandwidth percent 25

ISR881(config-pmap-c)# fair-queue

ISR881(config-pmap-c)# random-detect dscp-based

! Transactional data is given 25% WFQ with WRED based on DSCP

ISR881(config-pmap-c)# class BULK-DATA

ISR881(config-pmap-c)# bandwidth percent 4

ISR881(config-pmap-c)# fair-queue

ISR881(config-pmap-c)# random-detect dscp-based

! Bulk data is only given 4% WFQ with WRED

ISR881(config-pmap-c)# class SCAVENGER

ISR881(config-pmap-c)# bandwidth percent 1

! Scavenger is given only 1% of available BW

ISR881(config-pmap-c)# class class-default

ISR881(config-pmap-c)# bandwidth percent 25

ISR881(config-pmap-c)# fair-queue

ISR881(config-pmap-c)# random-detect

! Best effort in the default class is given 25% WFQ with WRED

在创建了class map 和子policy map 之后，需要创建一个嵌套在外面的（父）整形器来将带宽人为修正为10Mbit/s，以保障通向ISP的链路上不会出现拥塞的情况，如例39-7所示。

例39-7 创建父policy map

ISR881(config)# policy-map 8-CLASS-PARENT

ISR881(config-pmap)# class class-default

! create backpressure at 10 Mbps downstream to each agent

ISR881(config-pmap-c)# shape average 10000000

! use a nested service policy to call the "child" policy

ISR881(config-pmap-c)# service-policy 8-CLASS-CHILD

在创建完全部的policy map 和class map 之后，可以使用如下命令来检验此前的配置。

■ show class-map

■ show policy-map

在检验完父策略之后，需要将它应用到家用路由器的WAN接口上，如例39-8所示。注意，在这里，不需要将该策略应用到DMVPN隧道接口上，而要将其应用到物理接口上。在本例中，最重要的不是隧道内的超额流量，而是离开物理接口的总流量。由于IOS会自动将DSCP值复制到外部IP 头部，因此物理接口上的policy map 能够正确地对流量进行分类，并将其放入到相应的队列当中。

最后一步是将每个分支路由器的NHRP组名添加到mGRE隧道中，这是为了让总部路由器了解，应该对从总部流向分支网络的下游流量应用什么样的QoS策略。在本例中，（如例39-8 所示）我们使用的分支名称为GROUP 1。这与在中心路由器QoS service policy 命令中配置的NHRP名称相符。

例39-8 将policy map应用到物理接口上

ISR881(config)# interface FastEthernet 0/0

ISR881(config-if)# ip address 192.168.1.44 255.255.255.0

ISR881(config-if)# service-policy output 8-CLASS-PARENT

! This section attaches the outbound service policy to the physical interface

!

ISR881(config)# interface tunnel 1

ISR881(config-if)# ip address 10.1.1.22 255.255.255.0

ISR881(config-if)# ip nhrp group GROUP1

! This section is used to tell the hub router the NHRP group membership of this

! spoke.

在对家庭办公网络中的路由器应用了service policy 命令后，可以使用show policy-map interface x/y 命令来检验上述配置。

39.4 小结

通过研究上述案例，本章讨论了应用在家用VPN路由器上的QoS技术，应该按照什么标准进行设计，本章介绍的配置方案特别适合在家办公的客服中心人员与公司总部建立连接的环境。本章在第37章DMVPN案例的基础上进行了拓展，介绍了如何在中心与分支路由器上正确地使用8类的QoS模型。

在远程办公人员的案例中，需要面临主要的挑战在于，如何解决分支路由器与本地ISP所提供带宽速度不匹配的问题。本章介绍了在物理接口上通过分层整形技术人为限制流量速率的方法，这种方法可以顺利解决ISP路由器上出现的拥塞问题。这种方法可以防止在ISP提供的路由器到Internet之间的上行链路上出现拥塞，不过它并不能解决流量在Internet上传输时有可能遭遇的丢包问题。

39.5 扩展阅读

CVO main page（CVO主页）:http://www.cisco.com/go/cvo

CVO Solutions Guide（CVO解决方案指南）:http://www.cisco.com/en/US/solutions/collateral/ns340/ns517/ns430/guide_c07-683001.html

CVO Deployment Guide（CVO部署指南）:http://www.cisco.com/en/US/solutions/collateral/ns340/ns517/ns430/ns855/deployment_guide_c22-493157.html