本节书摘来自异步社区《端到端QoS网络设计（第2版）》一书中的第2章，第2.3节，作者【美】Tim Szigeti , 【加】Robert Barton , 【美】Christina Hattingh , 【美】Kenneth Briley，更多章节内容可以访问云栖社区“异步社区”公众号查看
2.3 模块化QoS命令行模型
端到端QoS网络设计（第2版）
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语法结构
例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语法结构示例
注释：
本书中对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示例
管理员可以通过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排序示例
在例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这个类别，因为语音和传真中继流量都匹配DSCP EF的条件，因此语音流量也会被归入FAX-RELAY这个类别中。图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 入站策略与出站策略
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带宽的保障。
在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的汇总信息
