6.4 基于类的整形配置
Cisco QoS认证考试指南（第2版）
Cisco IOS软件包含4种不同的整形工具。其中CB整形特性和FRTS（帧中继流量整形）是最常用的两个工具。有趣的是，这4个整型工具内部的工作原理从根本上说是一样的。事实上，这4个整型工具共享IOS中的多数整形代码。尽管有些特性有所区别，配置方法也有所不同，但很多核心功能是一样的。因此，浸有必要掌握所有4个流量整形工具，当前QoS考试只关注CB整形特性，它使用MQC进行配置。
注释：若你想要了解更多有关FRTS的信息，可以参考本书附赠CD-ROM中的附录B，那里提供了本书第一版中包含的FRTS内容。
CB整形特性中提供了多种特性。首先，基本工作流程与本章前文介绍的整形流程相同，其中包括使用单一令牌桶的概念。CB整形特性可以在多种不同的接口上启用。它也可以根据BECN信令进行速率适应，并在收到FECN后，在VC链路上返回BECN。此外，CB整形特性还可以为接口下的一部分流量实施整形。最后，CB整形特性的配置很简单，与其他以“基于类的”标识开头的QoS特性一样，CB整形特性使用MQC进行配置。
除了核心特性之外，CB整形特性还可以利用IOS提供的的队列工具。整形器将流量进行排队，以降低整体流量速率。CB整形特性在延迟发送数据包时，默认使用单一FIFO队列，但它还可以为整形队列应用其他的队列工具，其中包括WFQ、CBWFQ和LLQ。通过使用这些工具，CB整形特性可以更好地提供多服务业务。比如将LLQ应用到整形队列中，来为语音和视频流提供低延迟服务。
如前所述，与所有以“基于类的”标识开头的QoS工具一样，CB整形特性也使用MQC进行配置。表6-7和表6-8中列出了与CB整形特性相关的配置和show命令（这里省略了MQC中的match命令，你可以在第3章的表3-2中查看这些命令）。
例6-1 R3上的CB整形配置，整形速率为64 kbit/s
CB整形特性使用默认类（class-default）和一个策略映射（shape-all），这个策略映射通过service-policy output shape-all命令启用在S0/0.1上。命令class-map class-default匹配了所有数据包。policy-map shape-all命令中只调用了class-default类——这里本质上也配置了分类特性，但它匹配所有流量。在class class-default命令下，使用shape average 64000命令将流量整形为64 kbit/s。
与基于MQC的其他工具一样，show policy-map和show policy-map interfaceserial0/0.1命令提供了与本例相关的所有信息。注意，show policy-map命令只列出了与配置相同的信息，但show policy-map interface却列出了状态统计信息，告诉你当前整形特性是否活跃，并列出了计算值，比如Bc和Be。
若shape命令中没有指定特定的值，CB整形器会计算出Bc和Be的值。通过这两个值，CB整形器能计算出Tc的值。使用较低的整形速率（低于320 kbit/s）时，CB整形器会认为Bc为8000比特，并根据以下公式计算出Tc：Tc=Bc/CIR，计算结果需四舍五入。整形速率为320 kbit/s时，Tc的计算结果是25毫秒或0.025秒。注意在第一个案例中，Tc=125毫秒，因为8000/64 000=1/8秒。
使用高于320 kbit/s的整形速率时，CB整形器会使用默认Tc（即0.025秒），并根据相同的公式计算出Bc，即公式可以转换为Bc=Tc×CIR。比如使用640 kbit/s的整形速率时，Bc=0.025×640 kbit/s=
16000比特。
注释：QoS课程现在建议让IOS选择Bc和Be值。若你需要发送低延迟多服务流量，你需要通过设置Bc，将Tc的计算结果控制在10毫秒以内。这个建议是由Cisco提出的。
例6-1中提供了show policy-map interface s0/0.1命令的输出显示，从中可以更清晰地理解整形器如何使用令牌桶进行工作。首先，Be默认与Bc相等。Bc默认为8000比特，因为本例中的整形速率（64 kbit/s）低于320 kbit/s。这两个值在命令的输出中以Sustain bits/sec和Excess bits/sec表示。在这两个值前面的Byte Limit表示令牌桶的大小。在本例中，Bc+Be等于16 000比特或2000字节。在命令输出最后显示的Increment (bytes)表示在每个Tc内，有多少字节等量的令牌填入桶中。每个时间间隔填入令牌桶中的比特数，本例中为8000比特，也就是1000字节。本质上，命令输出中列出的详细内容表明了整形器令牌桶的工作逻辑。
在本例中，数据包在子接口上排起队列，以便接受整形，少数数据包在物理接口的软件队列中排队。在128 kbit/s时钟速率下，将接口上的所有流量整形为64 kbit/s，物理接口上应该不会发生拥塞。
默认情况下，CB整形器对整形队列使用单一FIFO队列。对于CB整形器来说，有一个常见的错误概念：因为使用了MQC命令，因此自动使用CBWFQ——这是错误的！在本例中，整形队列使用的是FIFO队列。
6.4.1 通过设置Bc来调整Tc
除了配置整形速率之外，你还可以明确设置Bc和Be值。从而，你可以在Tc=Bc/CIR这个公式中提供两个变量，CB整形器可以根据你的配置，轻松计算出Tc的值。下面案例展示了如何通过设置Bc来调整Tc。
在第二个配置中，假设帧中继提供商将R3到R1之间的VC限速为96 kbit/s。这个网络上需要支持单路G.729 VoIP呼叫，需要占用大概28 kbit/s。针对语音流量，你需要谨慎处理丢包、延迟和抖动，因此你决定对除了语音之外的所有流量进行整形。为了避免在帧中继云中出现丢包，你需要把其他流量的速率整形为64 kbit/s（这样一来，单路VoIP呼叫和整形为64 kbit/s的流量不会超出帧中继网络中设定的限速速率）。下一个案例展示出配置信息，其中配置规则如下所示：
将非VoIP流量整形为64 kbit/s；
选择Bc值使Tc为50毫秒；
在子接口启用配置。
在本例中，有一通VoIP呼叫，一条Web页面连接，页面中包含两个框架，以及一个FTP下载应用。例6-2给出了配置命令和一些show命令。
例6-2 R3上的CB整形配置，非语音流量的整形速率为64 kbit/s，Tc=50毫秒
本例中的配置相对简单，但很详细。一上来通过熟悉的MQC命令配置了LLQ。使用class-map match-all voip-rtp命令创建了一个新的类映射，其中匹配所有语音负载流量。在policy-map shape-non-voip命令中调用class voip-rtp，不做任何配置。这个类中没有任何参数配置，也就不会为这个类中的数据包采取任何行为，其中包括整形行为。class class-default中调用的类匹配所有流量，其中使用shape average 64000 3200命令将流量整形为64 kbit/s，Bc设置为3200比特（CB整形特性会计算出Tc等于3200/64000，即50毫秒）。由于class voip-rtp出现在策略映射的第一条，因此所有VoIP流量都会与这个类相匹配，即不接受整形。
show policy-map命令再次显示了配置信息。注意在命令class voip-rtp下面没有命令——没有在class voip-rtp命令下面添加任何命令——这样做有效地创建了一个“不作为”类。class class-default命令匹配所有其他流量，并将其整形为64 kbit/s。在show policy-map interface s0/0.1命令的输出中你可以看到，只为class class-default启用了整形功能，并没有为class voip-rtp启用整形功能。
注意本例中没有配置Be，它与前一个案例一样，都使用默认值，即与Bc相等。
本例说明了如何通过CB整形特性，为一部分流量实施整形——避免对语音流量进行整形。还说明了如何通过设置Bc的值，来影响Tc值的计算结果。如果你需要在包含VoIP流量的网络中启用整形特性，接下来的案例为你提供了更好的解决方案。
6.4.2 使用LLQ和小Tc，为语音微调整形特性
在前一个案例中，配置整形的初衷是因为帧中继提供商在VC上实施了96 kbit/s的限速。即使当前没有建立VoIP呼叫，数据流量也只能获得64 kbit/s带宽。即使这种做法对于单条语音呼叫来说很好，但对数据并不是太好的选择。现在实际的需求是为语音提供高质量服务，其次为数据提供良好的服务，已知运营商实施了96 kbit/s的限速。
更好的解决方案是在CB整形特性中，为整形队列使用包括CBWFQ或LLQ在内的队列工具。在前两个案例中，整形队列使用的都是单一FIFO队列，因为没有配置队列特性。在下面的案例中，CB整形特性会将所有流量整形为96 kbit/s，其中包括语音流量，同时在整形队列上使用LLQ来确保语音的高质量。由于本例需要对语音流量进行整形，需要通过配置将Tc降为10毫秒，这是在对延迟敏感的语音和视频流量进行整形时，推荐使用的Tc值。本例的配置要求如下所示：
为一路G.729 VoIP呼叫提供高质量服务，其中包括低丢包、低延迟和低抖动；
确保流量不超出运营商的限速速率，来实现VoIP的丢包保障；
通过使用LLQ来实现VoIP的延迟和抖动保障；
选择Bc值使Tc为10毫秒；
对所有流量进行整形，其中包括语音流量，因为LLQ会确保语音流的高优先级。
例6-3给出了配置命令。
从左到右查看本图，数据包第一次从子接口路由出去。IOS查看整形特性是否活跃。一旦一个数据包超出了流量契约，整形特性就会变得活跃；当所有整形队列中的数据包发完且后续数据包未超出流量契约时，整形特性变为不活跃。因此，整形器必须在这一步就介入进来，决定是否要把数据包放入整形队列。
若数据包超出契约，整形器需要对数据包进行排队。本例不使用单一的FIFO队列，而是为整形队列使用定义在policy-map queue-voip中的队列系统。这个策略映射中定义了两个队列，其中一个为32 kbit/s低延迟队列，所有语音负载都会被放入这个队列。这条队列是由class voip-rtp命令中的policy-map queue-voip命令创建的。由于queue-voip定义了队列方法，但其中没有配置任何其他细节，所有其他数据包都会进入第二个队列，即与class-default类相关联的队列（class-default队列默认应用WFQ，可以禁用这一配置）。
流程中的下一个步骤展示出在这个配置中，如何将队列和整形功能集成到一起。数据包被放入其中一个整形队列后，CB整形器必须决定何时将数据包从队列中拿出。但是整形器并不决定拿出哪个数据包——定义在policy-map queue-voip中的队列逻辑负责决定接下来处理哪个数据包。因此，shape average 96000 960命令告诉CB整形器速率和Bc值，整形器会在决定何时将下一个数据包从整形队列中拿出时，使用这些值。当CB整形器将下一个数据包从整形队列中拿出时，数据包将被放入接口软件队列中，并最终离开串行接口。
CB整形特性与能够应用于整形队列的队列工具（本例中的LLQ）之间的相互关系可能有些复杂。尤其是整形器必须决定是否将数据包放入整形队列，然后整形器还得决定何时将下一个数据包从整形队列中拿出。在这两步之间，队列的调度程序负责决定接下来服务哪个整形队列中的数据包。
现在仔细看看配置。policy-map shape-all命令创建了整形配置，shape average 96000 960命令启用整形特性并定义了Bc，从而Tc=960/96 000，即10毫秒。即使960比特的Bc值看上去要小于普通数据包，在网络中有VoIP流量时，你仍需要在这个接口上使用分片工具。分片特性可以使最大的数据帧变为小于960比特的数据帧。除此之外，service-policy queue-voip命令用于启用LLQ，也就是在策略映射shape-all中的类class-default中启用LLQ，即为整形队列启用LLQ。
现在看看policy-map queue-voip中的两个类。class voip-rtp命令匹配所有VoIP负载，通过priority 32命令为其分配32 kbit/s流量，将其配置为低延迟队列。记住，LLQ实际上会以这个速率来对低延迟队列中的流量进行限速，因此低延迟队列只能够以32 kbit/s发送流量。由于所有流量整形为96 kbit/s，因此还剩余64 kbit/s，这是为队列机制确保的带宽量；class class-default命令匹配了所有其他流量，为这类流量确保64 kbit/s。
最后在S0/0.1使用service-policy output shape-all接口子命令，在子接口启用CB整形特性。到此为止，为离开子接口S0/0.1的所有数据包应用了CB整形逻辑和LLQ逻辑。
show policy-map命令显示了配置的详细信息。其中policy-mapshape-all对流量实施整形，policy-map queue-voip实施LLQ。show policy-map interface s0/0.1命令列出了整形参数和状态统计参数，与前文案例相同。但命令的后一半出现了新的显示信息，即policy-map shape-all通过policy-map queue-voip使用LLQ的详细信息。在使用CBWFQ和LLQ时，还可以通过show policy-map interface命令查看到相同的信息，其中包括数据包速率和字节速率，详见第5章。
这个配置也适用于G.729呼叫，因为当voip-rtp类中有数据包在等待时，LLQ总是会优先服务这个类中的数据包。若网络中没有建立VoIP呼叫，其他流量可以以96 kbit/s的速率进行发送，即全部整形速率。换句话说，其他流量最少可以使用64 kbit/s，最多可以使用全部整形速率。使用了LLQ，在VoIP呼叫建立后，VoIP数据包总是会获得最好的服务，除非VoIP流量超出了LLQ的限速速率32 kbit/s。
在这个案例配置中，你需要注意两个术语。在一个策略映射中调用了另一个策略映射时，这种配置有时称为“层级式（Hierarchical）”策略映射，有时也被称为“嵌套式（Nested）”策略映射。或者你也可以将其理解为：为整形队列配置CBWFQ和LLQ的方法。
6.4.3 整形到峰值速率
在到目前为止所有的CB整形案例中，启用整形特性的命令总是以shape average开头。但这里还有另一个可选选项来代替关键字“average”，这条命令的完整语法如下所示：
与shap average一样，CB整形特性设置Bc为8000，Be使用相同的值，计算出的Tc为0.125秒。还与shap average一样，令牌桶的大小是Bc+Be，即16 000比特。但是，与每个Tc内向令牌桶中填入Bc比特不同，shape peak告诉CB整形特性在每个Tc内向令牌桶中填入Bc+Be令牌。换句话说，这意味着整形器在每个时间间隔内，可以发送承诺突发和超额突发。
有趣的是，shape peak 64000命令实际上以高于64 kbit/s的速率对数据包进行整形。你可以使用以下公式来计算真正的整形速率：
整形速率=配置的速率(1+Be/Bc)
比如在本例中，实际的整形速率应为128 kbit/s：
64(1+8000/8000)=128
例6-4给出了使用关键字peak的配置案例，并使用一些命令来验证使用peak后的计算结果。
从本例中可以看出，在同一个策略映射类（class-default）中，同时配置了shape average命令和shape adaptive命令。shape average命令启用了整形特性；若只使用这一条命令，CB整形特性总是会将流量整形为96 kbit/s。在同一个类中配置了shapeadaptive 32000命令之后，CB整形特性会在收到BECN后降低整形速率，使双向速率都降低为32 kbit/s。在每收到一个BECN后，速率都会降低当前实际整形速率的25%。但整形速率不会降到比32 kbit/s还低——因此你可以把32 kbit/s当作最低速率，把96 kbit/s当作最高速率。
回顾一下，若在连续的16个时间间隔内没再收到BECN，路由器会开始增加整形速率，在每个时间间隔内，增加原始96 kbit/s整形速率的1/16，即CB整形特性会在每个Tc内向令牌桶中多填入一些令牌，具体数值为(Bc+Be)/16。最终速率的提升要比BECN导致的速率降低慢一些。
6.4.5 混合CB整形配置：百分比整形
如果你愿意的话，shape命令还允许你根据链路带宽的百分比来配置整形速率。这种配置方法在使用shape average和shape peak命令时都适用。举例来说，你使用一个帧中继接口，它的访问速率（物理时钟速率）是128 kbit/s，你希望将其整形为64 kbit/s，你可以使用shape average percent 50命令。
需要注意的是，当你在物理接口使用这条命令时，实际的整形速率是根据接口配置的带宽进行计算的。以同一条命令为例，若接口默认的bandwidth命令设置是1544，即T速率。实际整形速率将为接口速率的50%，也就是722 kbit/s。
注意在使用percent选项时，Bc和Be是以毫秒为单位配置的。有趣的是以percent选项配置Bc会导致CB整形特性重新设置Tc（基于公式：Bc=Tc×CIR）。例6-6所示的案例配置中也显示了计算出的Bc和Be值。
在配置中，shape average percent 50 125 ms命令启用了整形特性，整形速率是接口带宽的50%。在本例中，S0/1的带宽被设置为128 kbit/s，因此当使用了service-policy output percent-test命令时，CB整形特性会以128 kbit/s的50%进行计算。要注意，在这条命令中，需要在配置的Bc值（见案例）和Be值（未显示在案例中）后面添加关键字ms。
show policy-map interface命令的输出信息中列出了一些有趣的信息。比如这里显示了计算出的速率64 000 bit/s。也显示了配置的Bc时间间隔为125毫秒。CB整形会计算出Bc=64 000×0.125，即8000比特。
6.4.6 对比CB整形和FRTS
QoS考试中并不涉及其他3种IOS整形工具，只需要简单了解GTS、DTS和FRTS即可。有趣的是，QoS考试内容中包含帧中继分片特性，该特性需要FRTS配置，因此如果你愿意的话，可以查看CD-ROM附录B中的FRTS内容。
现在先回顾一下到目前为止你所学到的CB整形概念和配置。同时，由于很多配置都需要使用FRTS，有必要在这里比较这两个QoS工具，尽管考试中并不涉及FRTS。
表6-9总结了CB整形特性和FRTS之间对比的重要内容，后续会对其进行详细解释。
*Cisco QoS课程声称物理接口可以支持WFQ。除此之外，从技术上说FRF并不是一个队列工具，它只是使用两个队列来完成相同的效果
下面简单解释一下表格中的内容。首先，FRTS只支持帧中继——否则这个名字起得也太差了——但CB整形特性可以支持任意类型的数据链路协议。若你配置帧中继来使用多点子接口，FRTS允许你针对每条VC进行整形，但CB整形特性无法实现。
其他内容曾经非常重要，但现在已经没有那么重要了，比如CB整形特性不支持帧中继分片特性。本书第8章中详细介绍了分片特性，在为延迟敏感的流量提供支持时，该特性非常重要。但还有另一个分片选项可以使用，称为帧中继分片上的多链路PPP（Multi-link PPP over Frame Relay Fragmentation），这样就可以在帧中继接口同时使用CB整形特性和分片特性了。