26.1先进先出队列
先进先出队列(First In First Out Queueing, FIFO)
如图所示FIFO 队列，不对报文进行分类，当报文进入接口的速度大于接口能发送的速度 时，FIFO
按报文到达接口的先后顺序让报文进入队列，同时 FIFO 在队列的出口让报文按进队 的顺序出队先进的
报文将先出队后进的报文将后出队。注意：当没有使用其他的队列机制时， 除了传输速率小于2.048Mbps
的串行接口以外的所有接口，默认都使用这种队列机制， 比如以太网口等。
26.2 WFQ加权公平队列
26.2.1 WFQ简介
加权公平队列(Weighted Fair Queueing, WFQ),它是一种基于流的队列
如图所示，WFQ对报文按流进行分类(对于IP网络相同源IP地址、目的IP地址、源端口号、目的
端口号、协议号、IP 优先级的报文属于同一个流)每一个流被分配到一个队列，该过程称为散列，采用
HASH算法来自动完成。尽量将不同的流分入不同的队列，WFQ的队列数目N可以配置，在出队的时候
WFQ 按流的 IP 优先级来分配每个流应占有出口的带宽优先级的数值越小所得的带宽越少，优先级的数
值越大所得的带宽越多，这样就保证了相同优先级业务 之间的公平，体现了不同优先级业务之间的权
值。例如接口中当前有 8 个流它们的优先级分别为 0、1、2、3、4、5、6、7、则带宽的总配额将是所
有流的优先级 + 1 之和即1 + 2 + 3+ 4 + 5 + 6 + 7 + 8 = 36。
每个流所占带宽比例(为自己的优先级数 + 1)/(所有 (流的优先级 + 1)之和)即每个流可得的带宽比
例分别为1/36、2/36、3/36、4/36、5/36、6/36、7 /36、8/36。
又比如当前共4个流，3个流的优先级为4，1个流的优先级为5，则带宽的总配额将是(4 + 1) * 3 +
(5 + 1) = 21 那么3个优先级为4的流获得的带宽比例均为5/21，优先级为5的流获得的带宽比例为6/21。
由此可见WFQ 在保证公平的基础上对不同优先级的业务体现权值，而权值依赖于IP报文头中所携带的
IP优先级。
注意：
WFQ是传输速率低于2.048Mbps 的串行接口默认的队列机制。
WFQ存在一些限制：
第一个是WFQ 不支持隧道或采用了加密技术的接口，因为这些技术要修改数据包中 WFQ 用
于分类的信息。
第二个WFQ提供的带宽控制的精确度不如CBWFQ和CQ等队列机制。
24.1.2 WFQ配置
接口下启用WFQ: nimokaka(config-if)#fair-queue
显示公平队列的配置状态: nimokaka#show queueing fair
Router#show queueing fair
Current fair queue configuration:
Interface Discard Dynamic Reserved
threshold queue count queue count
Serial0 64 256 0
显示接口的队列信息: nimokaka#show queue [interface]
Router#show queue serial0
Input queue: 0/75/0 (size/max/drops); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 9/1000/120/0 (size/max total/threshold/drops
Conversations 1/4/256 (active/max active/threshold)
Reserved Conversations 0/1 (allocated/max allocated)
(depth/weight/discards/tail drops/interleaves) 2/4096/0/0/0
Conversation 1044, linktype: ip, length: 1504
source: 172.26.237.58, destination: 172.26.237.2, id: 0xC4FE, ttl:126,
TOS: 0 prot: 6, source port 1563, destination port 4665
26.3 PQ优先级队列
26.3.1 Priority Queue简介
优先级队列（Priority Queueing, PQ）
如图所示， PQ 对报文进行分类，对于 IP 网络可以根据 IP 报文的优先级/DSCP 等条件进行分类，
将所有报文分成最多至4类，分别属于PQ 的4个队列中的一个，然后按报文的类别将报文送入相应的
队列。PQ 的 4 个队列分别为高优先队列、中优先队列、正常优先队列和低优先队列、它们的优先级依
次降低。在报文出队的时候，PQ 首先让高优先队列中的报文出队并发送，直到高优先队列中的报文发
送完，然后发送中优先队列中的报文，同样直到发送完，然后是正常优先队列和低优先队列，这样分类
使属于较高优先级队列的报文将会得到优先发送，而较低优先级的报文将会在发生拥塞时被较高优先级
的报文抢先，使得高优先级业务如 VoIP 的报文能够得到优先处理较低优先级业务，,如 E-Mail 的报文
在网络处理完关键业务后的空闲中得到处理既保证了高优先级业务的优先又充分利用了网络资源。
PQ使用的限制和缺点：
第一， 由于PQ是静态配置的,因此它不能适应网络结构的改变。
第二， 由于数据包要经过处理器卡的分类，因此PQ对数据包转发的速度要比FIFO慢。
第三， PQ 不支持隧道接口
另外 PQ 一个非常显著的缺点就是如果高优先级的队列没有发送完成， 低优先级的数据将永远不
会发送，造成两级分化，使较低优先级的数据转发困难。
3.2 Priority Queue配置
1、定义优先级列表,可以基于协议或基于进站接口：
基于协议：
nimokaka(config)#priority-list list-number protocol protocol-name
{high|medium|normal|low} queue-keyword keyword-value
priority-list号码为1-16，关注一下红色标记部分，其实我们可以添加一些扩充选项来准确定位
流量比如
fragment (IP packets with non-zero fragment offset) gt/lt
<size> based on packet size (including L2 frame) list
<acl> ACL classification
tcp/udp <port> TCP or UDP port number
基于进站接口：
nimokaka(config)# priority-list list-number interface interface-type interface-number
{high | medium | normal | low}
2、定义默认的优先级队列,未分类的流量默认被分配进该队列,优先级默认为normal:
nimokaka(config)#priority-list {list} default {high|medium|normal|low}
3、定义每个队列中数据包的最大个数,由高到低,默认为20,40,60 和80.可以更改:
nimokaka(config)# priority-list {list} queue-limit {high-limit medium-limit
normal-limit low-limit}
4、把优先级列表应用在接口上:
nimokaka(config-if)#priority-group {list}
26.3.3 检查Priority Queue配置
1、显示接口队列信息：
Router#show interface serial0
<top portion deleted>
Queueing strategy: priority-list 1
Output queue (queue priority: size/max/drops):
high: 2/20/0, medium: 0/40/0, normal: 0/60/0, low: 4/80/0
<bottom portion deleted>
2、显示PQ 列表信息:
Router#show queueing priority
Current priority queue configuration:
List Queue Args
1 low default
1 high protocol ip list 103
1 medium protocol ip list 102
1 normal protocol ip list 101
1 low protocol ip list 100
26.3.4 PQ配置实例
要求sna流量高优先级，www 的ip流量低优先级别，其他流量中等优先级别，给sna流量设置队列深度为
50消息
interface serial 0 //在接口下应用队列
priority-group 1
priority-list 1 protocol sna high //sna 是高优先级
priority-list 1 protocol ip low tcp 80 //www 是低优先级
priority-list 1 protocol ip medium //其他 ip 流量是中等优先级
priority-list 1 queue-limit 50 40 60 80 //高优先级队列，队列深度 50
基于分组大小的优先级队列，对于很多语音信息，其分组大小不会超过 100字节，所以可以对这样大小
的报文进行优化：
interface serial 0
priority-group 1
priority-list 1 protocol ip high lt 100
priority-list 1 default low
基于分组大小的优先级队列，适用于证券交易数据通讯或者 VOIP数据通讯
interface serial 0
priority-group 1
priority-list 1 protocol ip high lt 100
priority-list 1 default low
根据源地址限定优先级队列
interface serial 0
priority-group 1
priority-list 1 protocol ip high list 1
priority-list 1 default low
access-list 1 permit 213.13.13.0 0.0.0.15
26.4 CQ自定义队列
26.4.1 Custom Queue简介
如图所示CQ对报文进行分类，报文分成最多16类，分别属于CQ的16 个队列中的一个，然后按
报文的类别将报文送入相应的队列，实际上队列的号码是 0-16一共17个，但是 0号队列是超级优先队
列，路由器总是先把 0 号队列中的报文发送完然后才处理 1 到 16 号队列中的数据包，所以 0 号队列一
般作为系统队列，通常把实时性要求高的交互式协议和链路层协议报文放到 0 号队列中。1 到 16 号队
列可以按用户的定义分配它们能占用接口带宽的比例，在报文出队的时候，CQ 按定义的带宽比例分别
从 1 到 16 号队列中取一定量的报文在接口上发送出去。可以将 CQ 和 PQ 做个比较，PQ 赋予较高优先
级的报文绝对的优先权，这样虽然可以保证关键业务的优先，但在较高优先级的报文的速度总是大于接
口的速度时，将会使较低优先级的报文始终得不到发送的机会。采用 CQ 则可以避免这种情况的发生，
CQ 可以把报文分类然后按类别将报文分配到 CQ 的一个队列中去，而对每个队列又可以规定队列中的
报文所占接口带宽的比例，这样就可以让不同业务的报文获得合理的带宽，从而既保证关键业务能获得
较多的带宽，又不至于使非关键业务得不到带宽。但是由于 CQ轮循调度，各个队列它对高优先级尤其
是实时业务的时延保证不如PQ。
假设局域网 1 的服务器向局域网 2 的服务器发送关键业务的数据，局域网 1 的 PC 向局域网 2 的
PC发送非关键业务的数据，如果对路由器1 的串口1配置CQ进行拥塞管理，同时配置服务器间的数据
流的进入队列 1，队列 1 中的报文占有 60%的带宽，例如每次出队 6000 个字节的报文，PC 间的数据流
进入队列2，队列2中的报文占有20%的带宽，例如每次出队2000个字节的报文，则CQ对这两种不同
业务的报文将做区别，对待报文的发送采用轮询调度的方式，首先让队列 1中的报文出队，并发送直到
此队列中的报文被发送的字节数不少于 6000 字节，然后才开始发送队列 2 中的报文，直到此队列中的
报文被发送的字节数不少于2000字节，然后是其他队列，如果路由器 1 的串口1的物理带宽是2M，则
局域网 1 的服务器向局域网 2 的服务器发送关键业务的数据所能占的带宽将至少为 1.2M（2*0.6），局
域网1 的PC向局域网2的 PC 发送非关键业务的数据所能占的带宽将至少为0.4M（2*0.2），当路由器
1的串口 1中除了上述两个数据流外没有其他数据要发送时，这两种数据流将按比例分享接口的剩余空
闲带宽即局域网 1 的服务器向局域网 2 的服务器发送关键业务的数据所能占的带宽将为
1.5M[2*0.6/(0.2+0.6)]。局域网 1 的 PC 向局域网 2 的 PC 发送非关键业务的数据所能占的带宽为
0.5M[2*0.2/(0.2+0.6)]，当局域网1的服务器向局域网2的服务器不发送关键业务的数据时并且除了局域
网 1 的 PC 向局域网 2，的 PC 发送非关键业务的数据外没有其他的数据流，则局域网 1 的 PC 向局域网
2的 PC发送非关键业务的数据所能占的带宽将可以为2M。
为了能够为每个队列分配一定的带宽，必须为每个队列定义一定字节数的数据包。自定义队列中
的数据包也按照队列号顺序被转发，当队列为空或超出本次队列允许发送的数据包时,接下来会轮到下
一个队列。但是假如定义的字节数为100 字节，而某个数据包的大小为1024字节，那么该队列每次将
转发的数据包的大小即为1024字节，而不是100字节。假如有3个队列，每个队列中的数据包大小分
别为500字节，300字节和200字节如果想让这3个队列平均的占用带宽，为这3个队列定义的字节数
分别为200字节，200字节和200字节，但是实际上生效的带宽占用比为5/3/2，因此如果把队列中数
据包的字节数定义的过小的话，将导致带宽分配的不尽如人意。但是如果把队列中数据包的字节数定义
的过大，那么将导致下一个队列中的数据包被转发的等待时间过长。
CQ使用中存在一些限制：
1， 由于CQ是静态配置的，因此它不能适应网络结构的改变。
2， 由于数据包要经过处理器卡的分类，因此CQ对数据包转发的速度要比FIFO慢。
26.4.2 Custom Queue配置
1、定义CQ列表：
nimokaka(config-if)#custom-queue-list {list} （后面是列表的号码）
2、定义队列中数据包的字节数或最大个数：
定义最大个数
nimokaka(config)# queue-list list-number queue queue-number limit limit-number
（queue的号码是队列的号码，limit的后面接的是队列里面的数量，默认为20个，范
围是0到32767）
定义队列大小（就是定义队列的带宽）
nimokaka(config)#queue-list {list} queue {queue-number} byte-count bytes
默认为1500字节
3、把数据包分配进特定的CQ 中,可以基于协议或基于进站接口：
基于协议
nimokaka(config)#queue-list {list} protocol protocol {queue-number}
queue-keyword keyword-value
同样的道理，也可以加入相应的参数，参看PQ配置的参数
基于接口
nimokaka(config)#queue-list {list} interface interface {queue-number}
4、定义默认的CQ 队列,未分类的流量默认被分配进该队列:
nimokaka(config)#queue-list {list} default {queue-number}
26.4.3 Custom Queue配置检查
1、显示接口队列信息: nimokaka#show queue [interface]
Router#show interface serial0/0/3
<top portion deleted>
Queueing strategy: custom-list 1
Output queues: (queue #: size/max/drops)
0: 0/20/0 1: 0/20/0 2: 0/20/0 3: 0/20/0 4: 0/20/0
5: 0/20/0 6: 0/20/0 7: 0/20/0 8: 0/20/0 9: 0/20/0
10: 0/20/0 11: 0/20/0 12: 0/20/0 13: 0/20/0 14: 0/20/0
15: 0/20/0 16: 0/20/0
<bottom portion deleted>
2、显示CQ列表信息： nimokaka#show queueing custom
Router#show queueing custom
Current custom queue configuration:
List Queue Args
1 1 protocol ip tcp port <protocolA>
1 2 protocol ip tcp port <protocolB>
1 3 protocol ip tcp port <protocolC>
1 1 byte-count 2172
1 2 byte-count 6693
1 3 byte-count 2493
26.4.4 CQ配置实例
interface serial 0
custom-queue-list 1 //在接口应用队列
queue-list 1 protocol sna 1 //在 queue-list 1 中定义 sna,ip,ipx 队列。
queue-list 1 protocol ip 2
queue-list 1 protocol ipx 3
queue-list 1 queue 1 byte-count 15000 //queue 1,sna 被设为 3*(1500+3500)=15000
queue-list 1 queue 2 byte-conut 3500 //queue 2,ipx,被设为 3500 字节
queue-list 1 queue 3 byte-conut 1500 //默认 1500
26.5 CBWFQ基于类的公平队列
26.5.1 CBWFQ简介
CBWFQ (Class-based weighted fair queueing) 是思科公司在 IOS 中的一种新的队列技术，它是 WFQ 队
列技术的拓展。使用 CBWFQ 技术，可以将数据流根据各种条件分类，同类的数据占用一个队列。当数据
被分类完毕后，可以为该类数据定制传输特性，如带宽、传输的权级 (weight) 、传输限制等。为一个队列
指定的带宽通常是指在带宽拥塞时为该队列所保证的带宽。
在分类数据时，需要指明每个队列的长度，即该队列所能存放的数据包的量。如果数据包超出队列的
容量，会发生丢包的现象，通常是队列尾部的数据包被丢弃。
图中所示LLQ（Low Latency Queueing，低延迟队列）是一个具有较高优先级的队列，它的优先级仅次
于二层协议队列（如同CQ中的0号队列），与RTP优先队列（RTP优先队列的参见后文介绍）一个或多个类的
报文可以被设定进入LLQ，队列不同类别的报文可设定占用不同的带宽，在调度出队的时候，若LLQ中有报
文则总是优先，发送LLQ中的报文直到LLQ中没有报文时或者超过为LLQ配置的最大预留带宽时，才调度发送
其他队列中的报文。
图中1到64的队列为各类报文的队列每类报文占一个队列，我们称它们为BQ(Bandwidth Queueing)
在系统调度报文出队的时候，按用户为各类报文设定的带宽将报文出队发送这种队列技术，应用了先
进的队列调度算法可以实现各个类的队列的公平调度属于1到N1号BQ队列的报文可以被确保得到用户设定
的带宽，当接口中某些类别的报文没有时,BQ 队列的报文还可以公平地得到空闲的带宽,大大提高了线路的
利用率,同时在接口拥塞的时候仍然能保证各类报文得到用户设定的最小带宽。
当报文不匹配用户设定的所有类别时，报文被送入系统定义的缺省类，虽然允许为缺省类配置带宽使
其作为BQ类进行基于类的队列调度，但是更多的情况是为缺省类配置WFQ，使所有进入缺省类的报文进行
基于流的队列调度。
CBWFQ最多允许配置64个BQ类，缺省类的WFQ的队列个数N可以由用户设定。 对于缺省类的WFQ和BQ，
当队列的长度达到队列的最大长度时,缺省采用尾丢弃的策略。但用户还可以选择用加权随机预检测
(Weighted Random Early Detection, WRED)的丢弃策略（加权随机预检测的丢弃策略请参见后面加权随机预检
测WRED的描述）。
综上所述CBWFQ有一个低时延队列 - LLQ 用来支撑EF（加速转发）类业务，被绝对优先发送，另外有
64个BQ用来支撑AF（确保转发）类业务，可以保证每一个队列的带宽及可控的时延，还有一个WFQ对应BE
（尽力而为传输）业务使用接口剩余带宽进行发送。CBWFQ可根 据报文的输入接口ACL、IP优先级/DSCP等
规则对报文进行分类，进入相应队列规则可以是通手工配置，对于进入LLQ和BQ的报文要进行测量，考虑到
链路层控制报文的发送链路层封装开销及物理层开销
建议RTP优先队列LLQ与BQ占用接口的总带宽不要超过接口带宽的75%%（默认就是只占用75％带宽）
LLQ只采用尾丢弃，BQ可采用尾丢弃或者WRED（基于IP优先级DSCP） WFQ可采用尾丢弃和WRED。CBWFQ
可为不同的业务定义不同的调度策略，如带宽时延等。由于涉及到复杂的流分类，对于高速接口GE以上启
用CBWFQ特性系统资源存在一定的开销。
RSVP也可以和CBWFQ 协同工作.当一个接口同时配置了CBWFQ 和RSVP,它们之间的工作 是独立的.并
且当CBWFQ 不存在的时候RSVP 还是会继续工作.
CBWFQ使用存在的一些限制：
一、目前流量和整形不支持CBWFQ。
二、CBWFQ 不支持以太网子接口
26.5.2 CBWFQ配置
在配置队列时，可以配置一个默认队列，所有没有具体分类的数据都会被放到默认队列中。默认队列
的数据处理可以通过用户配置去定义。如果没有定义默认队列，那么那些没有匹配到任意类的数据会根据
数据流 (flow) 区分并用 best-effort 方式处理。
CBWFQ 对 WFQ 作了一些改进，在 WFQ 中， weight 是用来指明队列的权级的，而在 CBWFQ 中，
weight 是用来指明每个数据包的权级的。数据包到达出口时，根据事先定义好的标准被分成不同的类别，
每个包都会有自己的 weight 。数据包的 weight 被指定了以后，数据包会排在相应的类的队列中， CBWFQ
通过使用 weight 来保证数据包的公正处理。
CBWFQ 可以为某类流量指定相应的带宽。根据接口的带宽，可以配置多达 64 类数据，并指定相应
的处理方式。这是传统的基于数据流的 WFQ 所做不到的。也是 CBWFQ 与 WFQ 的区别之所在。
CBWFQ 在分类定义数据流时，不仅仅可以通过 IP 地址和端口号；还可以通过扩展访问控制列表
(EACL) 或数据输入接口 (input interface) 。这也是 WFQ 所做不到的。
在采用 CBWFQ 时，我们通常需要三个步骤：
1 定义数据的分类策略，在这里是通过 class map 来做分类数据的定义
a、定义class map
nimokaka(config)#class-map [match-all|match-any] {map-name}
b、定义匹配语句
nimokaka(config-cmap)#
一些匹配条件选项:
match access-group {ACL} 匹配IP ACL
match protocol {protocol} 匹配协议
match input-interface {interface} 匹配进站接口
match qos-group {Group ID} 匹配组ID
match destination-address {mac mac-address} 匹配目标MAC 地址
match source-address {mac mac-address} 匹配源MAC 地址
match ip {dscp dscp} 匹配IP DSCP 值
match ip {precedence precedence} 匹配IP 优先级
match class-map {map-name} 匹配
class map match vlan {vlan-id} 匹配VLAN
2 为每类数据定义其处理的策略，通过 policy map 来定义
a. 设置policy map:
nimokaka(config)#policy-map {policy-name}
b. 调用class map 或默认的class map(所有未分类的流量默认都属于该分类,否则未分类
的流量将以尽力而为的方式被处理):
nimokaka(config-pmap)#class {class-map|class-default}
c. 设置策略:
nimokaka(config-pmap-c)#bandwidth {kbps|percent percent}
d. 定义尾丢弃机制允许的队列中数据包个数的上限,默认值为64:
nimokaka(config-pmap-c)#queue-limit {packets}
其他配置参数
nimokaka(config-pmap-c)#random-detect 用于WRED
nimokaka(config-pmap-c)#shape 令牌桶参数
nimokaka(config-pmap-c)#police (car限速)
nimokaka(config-pmap-c)#priority 优先级，低延迟队列(LLQ).
3 将所定义的策略应用到接口上。
在出站接口上应用policy map:
nimokaka(config-if)#service-policy output {policy-name}
更改用于RSVP 和CBWFQ 等队列机制保留的最大带宽值,默认为75%:
nimokaka(config-if)#max-reserved-bandwidth {percent}
26.5.3 检查CBWFQ配置
1、查看policy map 信息：
nimokaka#show policy-map [policy-name]
2、查看接口的policy map 信息：
nimokaka#show policy-map interface [interface]
3. 显示接口的队列信息:
nimokaka#show queue [interface]
26.5.4 CBWFQ配置实例
限制源自192.168.10.0/24 的流量的带宽为1000kbps:
!
class-map match-all nimokaka
!
policy-map kaka
bandwidth 1000 限制带宽1000k
queue-limit 30 限制队列数据包上限30个包
class class-default 其他的放置到默认队列
!
interface Serial1
ip address 172.16.10.1 255.255.255.252
service-policy output kaka
!
access-list 1 permit 192.168.10.0 0.0.0.255
多class-map联合使用
class-map match-any nimokaka1
match protocol sqlnet
match protocol ipsec
match access-group 100
match ip precedence 4 5
!
class-map match-all nimokaka2
match access-group 101
match access-group 102
!
class-map nimokaka3
match access-group 103
policy-map kaka
class nimokaka1 bandwidth 6000 class nimokaka2 bandwidth 3000 class
nimokaka3 bandwidth 700 class class-default bandwidth 200
!
interface ethernet 1/1
service-policy output kiss
基于IP优先级的控制
class-map match-any class0
match ip precedence 4
match ip precedence 0
class-map match-any class1
match ip precedence 1
match ip precedence 5
class-map match-any class2
match ip precedence 2
match ip precedence 6
class-map match-any class3
match ip precedence 3
match ip precedence 7
policy-map tos-based
class class0
bandwidth 6750
class class1
bandwidth 13500
class class2
bandwidth 18000
class class3
bandwidth 6750
interface hssi0/0/0
service-policy output tos-based
26.6 LLQ低延迟队列
26.6.1 LLQ简介
LLQ（Low Latency Queueing，低延迟队列）是一个具有较高优先级的队列，它的优先级仅次于二层
协议队列（如同CQ中的0号队列），与RTP优先队列（RTP优先队列的参见后文介绍）一个或多个类的报
文可以被设定进入LLQ，队列不同类别的报文可设定占用不同的带宽，在调度出队的时候，若LLQ中有报
文则总是优先，发送LLQ中的报文直到LLQ中没有报文时或者超过为LLQ配置的最大预留带宽时，才调度
发送其他队列中的报文。 进入LLQ的报文在接口没有发生拥塞的时候，此时所有队列中都没有报文，所
有属于LLQ的报文都可以被发送在接口，发生拥塞的时候队列中有报文时，进入LLQ的报文被限速超出规
定流量的报文将被丢弃，这样在接口不发生拥塞的情况下可以使属于LLQ的报文能获得空闲的带宽在，
接口拥塞的情况下又可以保证属于LLQ的报文不会占用超出规定的带宽，保护了其他报文的应得带宽，
另外由于只要LLQ中有报文系统就会发送LLQ中的报文，所以LLQ中的报文被发送的延迟最多是接口发送
一个最大长度报文的时间，无论是延时还是延时抖动 LLQ都可以将之降低为最低限度，这为对延时敏感
的应用如VoIP业务提供了良好的服务质量保证
26.6.2 LLQ配置
在CBWFQ中使用bandwidth命令是用于定义普通队列的，
但是如果改用priority, j配置的就是低延时队列，凌驾于CBWFQ的上面
nimokaka(config-pmap-c)#priority {bandwidth}
为LLQ和IP RTP设置占用带宽的百分比
nimokaka（config-if）#max-reserved-bandwidth percent
26.6.3 检验LLQ配置
1、显示接口队列信息： nimokaka#show queue [interface]
2、调试优先级队列： nimokaka#debug priority
26.6.4 LLQ配置实例
使用LLQ给视频流量提供保留带宽
在配置之前肯定事先已经将视频流量的数据包优先级更改成5，给ACL100和101定义的数据包加
入class map， 然后使用policy map中的priority命令来保证1518k的带宽，并且把优先级set到5，交给
下一跳路由器
class-map match-all nimokaka1
match access-group 100
class-map match-all nimokaka2
match access-group 101
!
policy-map video1 //定义LLQ策略
class nimokaka1
priority 1518 //使用priority定义为Video预留的带宽
set ip precedence 5 //更改优先级
class class-default fair-queue
policy-map video class nimokaka2 priority 1518
set ip precedence 5 class class-default fair-queue
!
interface FastEthernet1/0/0.1 description HQ1 LAN encapsulation dot1Q 1
ip address 129.2.80.21 255.255.0.0
service-policy output video1 //在接口下应用策略
!
interface Serial1/0/0
description Router 1 to ROUTER 2
ip address 206.141.24.1 255.255.255.0
ip route-cache policy
no ip route-cache distributed service-policy output video
!
access-list 100 permit ip host 141.2.20.20 host 129.2.20.34 precedence critical
//通过ACL匹配
access-list 101 permit ip host 129.2.20.34 host 141.2.20.20 precedence critical
26.7 RTP优先级队列
26.6.1 RTP-PQ简介 
如图所示：RTP优先队列是一种解决实时业务包括语音与视频业务服务质量的简单队列技术。其原
理就是将承载语音或视频的RTP报文送入高优先级队列使其得到优先发送，保证延时和抖动降低为最低
限度，从而保证了语音或视频这种对时延敏感业务的服务质量，RTP 优先队列将RTP报文送入一个具有
较高优先级的队列，RTP报文是端口号在一定范围内为偶数的UDP报文，端口号的范围可以配置一般为
16384~32767，RTP优先队列可以同前面所述的任何一种队列包括FIFO、PQ、CQ、WFQ与CBWFQ 结合使
用。它的优先级是最高的。
一般语音数据包的体积较小，如果有体积较大的数据包要从该接口被转发出去，该接口应配置链路
分片和交叉（LFI）特性.体积较大的数据包被分片为体积较小的数据包。该特性 防止语音数据包要等待
到体积较大的数据包被转发完毕之后才能被转发。这样语音数据包可 以和被分片的数据包交叉被转发
出去。从而减少了语音数据包转发消耗的时间。
由于对进入RTP优先队列的报文进行了限速，超出规定流量的报文将被丢弃这样，在接口拥塞的情
况下可以保证属于RTP优先队列的报文不会占用超出规定的带宽，保护了其他报文的应得带宽解决了PQ
的高优先级队列的流量可能丢弃低优先级流量的问题。
26.6.2 RTP-PQ配置
添加起始port和port范围， 后面的bandwidth填写的是预留的带宽
nimokaka(config-if)#ip rtp priority {starting-rtp-port-number
port-number-range}{bandwidth}
为LLQ和IP RTP设置占用带宽的百分比
nimokaka（config-if）#max-reserved-bandwidth percent
26.6.3 检验RTP-PQ配置
1、显示接口队列信息: nimokaka#show queue [interface]
2、调试优先级队列: nimokaka#debug priority
26.6.4 RTP和CBWFQ结合使用
定义class map
nimokaka(config)# class-map nimokaka
nimokaka(config-cmap)# match access-group 101
nimokaka(config-cmap)# exit
定义和使用policy map
nimokaka(config)# policy-map kiss
nimokaka(config-pmap)# class nimokaka
nimokaka(config-pmap-c)# bandwidth 3000
nimokaka(config-pmap-c)# queue-limit 30
nimokaka(config-pmap-c)# random-detect
nimokaka(config-pmap-c)# random-detect precedence 0 32 256 100
nimokaka(config-pmap-c)# exit nimokaka(config)# interface Serial1
nimokaka(config-if)# service-policy output nimokaka
设置RTP
nimokaka(config-if)# ip rtp priority 16384 16383 40
RTP是直接应用到接口上的，所以优先级超级超级高，另外看看端口范围，起始端口是16384，
范围是从16384加上后面的range=16383， 应该是从16384--32767这个范围，存在一个加法公式。
26.6.5 CRTP压缩实时传输协议
实时传输协议(RTP)是一种用于传输实时数据流量的协议。RTP包含数据部分和包头部分。数据部分
用于支持实时传输应用程序的各种属性。包头部分的体积比较大，最少包括了12 字节的RTP包头,20字节
的IP 包头(IPH)和8字节的UDP包头,因此IP/UDP/RTP包头总长度 至少为40字节。根据IP/UDP/RTP包头长度
的不同,RTP数据包的长度为20字节到160字节不等。如果不对IP/UDP/RTP包头进行压缩的话,对于RTP数据
包的传输是很没效率的。因此后来出现了压缩IP/UDP/RTP包头的压缩式实时传输协议(CRTP)。
CRTP是一种逐跳的压缩机制。CRTP可以把IP/UDP/RTP包头从40字节压缩为2到5字节。当广域网接
口带宽不高，并且RTP数据流量过大的话，应该考虑使用CRTP；但是对于高于T1线 路速率的接口，无需
使用CRTP。CRTP支持ISDN，支持使用PPP，HDLC或FR封装的接口.但是FR 的封装格式只能使用Cisco特有
的格式。
26.6.6 CRTP配置
1． 启用CRTP：如果不指定关键字passive，将对所有IP/UDP/RTP包头进行压缩；如果指定
passive关键字，当进站RTP数据包的IP/UDP/RTP包头被压缩，才相应的压缩出站的RTP数据
包的IP/UDP/RTP包头：
nimokaka(config-if)#ip rtp header-compression [passive]
2、 更改IP/UDP/RTP包头压缩的连接数,默认为16条.可选:
nimokaka(config-if)#ip rtp compression-connections {number}
RTP头压缩，默认16条，最大500条
nimokaka(config-if)#ip tcp compression-connections {number}
TCP头压缩，默认16条，最大128条
基于帧中继环境的CRTP
1、在物理接口上启用CRTP，那么该物理接口相关的子接口将继承CRTP的配置信息。如果不
指定关键字passive，将对所有IP/UDP/RTP包头进行压缩；如果指定passive关键字，当
站RTP数据包的IP/UDP/RTP包头被压缩，才相应的压缩出站的RTP数据包的IP/UDP/RTP包
nimokaka(config-if)#frame-relay ip rtp header-compression [passive]
2、更改IP/UDP/RTP包头压缩的连接数，默认为16条，可调整:
nimokaka(config-if)#frame-relay ip rtp compression-connections {number}
3、只针对特定的PVC启用CRTP。如果指定关键字active，将对所有IP/UDP/RTP包头进行
缩；如果指定passive关键字，当进站RTP数据包的IP/UDP/RTP包头被压缩，才相应的压
出站的RTP数据包的IP/UDP/RTP包头。还可以指定最大的IP/UDP/RTP包头压缩的连接数,
认为16条，可调整:
nimokaka(config-if)#frame-relay map ip {ip-address} {dlci} [broadcast] rtp
header-compression [active|passive] [connections number]
4、在特定PVC上同时启用CRTP 和TCP 头部压缩。
nimokaka(config-if)#frame-relay map ip {ip-address} {dlci} [broadcast]
compress
26.6.7 检验CRTP
1、显示IP/UDP/RTP包头的压缩统计信息：
nimokaka#show ip rtp header-compression [interface] [detail]
2、显示FR 的IP/UDP/RTP包头的压缩统计信息：
nimokaka#show frame-relay ip rtp header-compression [interface]
26.8 WRR加权轮询队列
26.6.1 WRR简介
WRR(Weighted Round-Robin)调度算法
交换机的端口支持4 个输出队列，WRR 队列调度算法在队列之间进行轮流调度，保证每个队
列都得到一定的服务时间。WRR 可为每个队列配置一个加权值（依次为w3、w2、w1、w0），加
权值表示获取资源的比重。如一个100M的端口，配置它的WRR 队列调度算法的加权值为50、30、
10、10（依次对应w3、w2、w1、w0），这样可以保证最低优先级队列至少获得10Mbit/s 带宽，
避免了低优先级队列中的报文可能长时间得不到服务的缺点。WRR 队列还有一个优点是，虽然多
个队列的调度是轮循进行的，但对每个队列不是固定地分配服务时间片——如果某个队列为空，那
么马上换到下一个队列调度，这样带宽资源可以得到充分的利用。
HQ-WRR 调度算法
HQ-WRR 调度模式在WRR 的基础上，在4 个输出队列中选择队列3 为高优先级队列。如果4
个队列的占用的带宽超过了端口的能力，交换机首先保证队列3 的报文优先发送出去，然后对其余
3 个队列实行WRR 调度。
26.6.2 C3550的Qos时序及队列
3550 交换机有两种不同类型的端口：千兆端口和非千兆端口（10/100M 端口）每个 3550 的端口上
都有4个不同的输出队列。这些队列中的一个可以被配置为优先级队列。余下的几个端口被配置为非绝对的
优先级队列，并使用Weighted Round Robin (WRR)。 所有的端口上，数据包根据各自的服务类别（CoS）被
分配为四中可能的类别之一。
其中千兆端口还能支持每个队列的管理机制。每个队列可以使用 Weighted Random Early Discard
(WRED)或者双线程的 tail drop 。队列大小可调（每个队列均分配相应的 缓冲区）。非千兆端口不支持任
何队列管理机制，例如 WRED 或者双线程 tail drop
10/100M 端口支持 FIFO 队列。 每个端口队列的大小都不可改变。但是可以为每个队列分配最小的
保留带宽。
26.6.3 WRR队列配置
CoS 到队列映射
本节讨论 3550 如何决定将每个数据包放置到队列中去。数据包队列取决于服务类别（CoS）。
通过使用 CoS 到队列的接口映射命令，每个八种可能的 Cos 数值将被映射到相应 的四个队列。
下面是该命令的示例：
nimokaka(config-if)# wrr-queue cos-map queue-id cos1... cos8
nimokaka(config-if)# wrr-queue cos-map 1 0 1
nimokaka(config-if)# wrr-queue cos-map 2 2 3
nimokaka(config-if)# wrr-queue cos-map 3 4 5
nimokaka(config-if)# wrr-queue cos-map 4 6 7
该示例将 CoS 0和 1 映射到 Q1, CoS 2 和 3 映射到 Q2, CoS 4 和 5映射到 Q3, CoS 6和 7
映射到 Q4。
每个端口的 CoS 到队列的映射情况可以通过使用下面的命令来进行验证：
nimokaka# sh mls qos int gig 0/1 queueing
GigabitEthernet0/1
...Cos-queue map:
cos-qid
0 - 1
1 - 1
2 - 2
3 - 2
4 - 3
5 - 3
6 - 4
7 - 4.
当然，DSCP 也可以有默认的映射，如下图
绝对的优先级队列
绝对的优先级队列在初始状态下通常是空的。这就意味着一旦有数据包进入队列，该包将马上被
转发。当 WRR 队列中所有的数据包都被转发后，优先级队列根据需要关闭并清空。 绝对的优先级队
列被特别设计来处理对延迟/抖动比较敏感的数据流，例如语音。绝对的优先级队列将导致其他队列严
重滞后。在其他三个 WRR 中的数据包在绝对的优先级队列中数据传输完成之前，将不会被转发。注
意：要避免其他队列的严重滞后，要特别注意放到优先级 队列中的流量。
该队列通常用于语音数据流，而此类型应用并不占用很高的带宽。但是若有人将一些占 用带宽较
多的应用（例如数据转移或备份）放到绝对的优先级队列。这将引起其他流量的严重滞后。要避免该
问题，特殊的数据流应被放置在分类/准入，并在网络中标记该数据流。 例如，你可能需要采取一下
预防措施：
1、在非可信的源端口使用非可信的端口 QoS 状态；
2、在使用 Cisco IP 电话端口可靠的边界特性时，确信 IP 电话配置于其它应用是可信的
3、修正进入绝对优先级队列的数据流。在千兆端口上修正数据流的流量限制为 100M。
在 3550 上，可以配置一个队列为优先队列，（总是 Q4），在端口模式下使用如下命令：
nimokaka(config-if)# priority-queue out
（加载这个命令之后，Q4 就会成为优先队列）
如果某个端口没有配置优先队列，则 Q4 被当做标准的 WRR 队列（下节将详细描述） 你可以通过
输入和下面一样的 IOS 命令来验证某端口是否被配置为绝对优先级队列，
nimokaka#sh mls qos interface gig 0/1 queueing
GigabitEthernet0/1
Egress expedite queue: ena
26.6.4 3550的WRR配置
在 3550 上，WRR 是一个对输出时间序列进行管理的机制。WRR 在三个或四个队列（如果没有绝对
优先级队列）之间工作。使用 WRR 模式的队列在循环方式下是置空的，可以为每个 队列配置相应的权值。
例如，配置了不同的权值，不同的队列将提供不同的服务，如下所示：
Serving WRR Q1 : 10% of time
Serving WRR Q2 : 20% of time
Serving WRR Q3 : 60% of time
Serving WRR Q4 : 10% of time
对每个队列，你可以在端口模式使用以下命令来配置四个权值（各自相对于一个队列）：
nimokaka(config-f)#wrr-queue bandwidth weight1 weight2 weight3 weight4
nimokaka(config)# interface gigabitethernet0/1
nimokaka(config-if)# wrr-queue bandwidth 1 2 3 4
注意：权值是相对的，下面是计算方式
Q1 = weight 1 /(weight1 + weight2 + weight3 + weight4) = 1/(1+2+3+4) = 1/10
Q2 = 2/10
Q3 = 3/10
Q4 = 4/10
WRR 可通过以下两种方式执行：
a) WRR per bandwidth: 每个权值描述了可以用于发送的特别带宽。权 Q1 允许使用大约
10％的带宽，Q2 将获得大约 20％的带宽，以此类推。
b) WRR per packet: 该算法在3550 交换机上实现。 这表示每个权值表示了某个数量的数据
包将被发送，而不管包的大小如何。
3550 上实现 WRR per packet 表现为如下形式：
Q1 传输 1/10 的数据包
Q2 传输 2/10 的数据包
Q3 传输 3/10 的数据包
Q4 传输 4/10 的数据包
如果被传送的包是同样大小则是最理想的情况.在4 个队列中你依然能够获得理想的共享带宽。然而，
如果队列间的平均包大小有差异，则会在拥塞事件发生时对传输产生巨大的影响。
假设当前交换机只有两个数据流， 同时假设处于以下的情形：
一个千兆口的队列 2（Q2）以 Cos 3 类别方式每秒传输少量的交互应用数据流（80 字节/帧）
一个千兆口的队列 1（Q1）以 Cos 0 类别方式每秒传输大型文件数据流（1518 字节/帧）
两个队列都将以传输 1 Gbps 的速率传输数据。两个数据流需要共享同一个输出的千兆口。假设我们
已经为 Q1 和 Q2 设置了同样的权值，WRR 应用到每个数据包，并且每个队列 内传输的数据量不同于两
个队列之间的数据量。每个队列都转发了同样数量的数据包，然而 交换机实际上发送了下面数量的数据：
77700 包/秒由 Q2 输出 = (77700 x 8 x 64) bits/sec (大约 52 Mbps)
77700 包/秒由 Q1 输出= (77700 x 8 x 1500) bits/sec (大约 948 Mbps)
注意：
如果你想要每个队列都公平的接入网络，需要考虑每个数据包的平均值。每个数据包都
被假设放置在同一个队列，因而权值得到改善。
例如：如果你想要为四个队列赋予相同的接入（每个队列各自分配到 1/4 的带宽），流量表现为如下
形式：
Q1: 最佳的互联网数据流量。假定数据流的平均包大小为 256 字节。
Q2 : 文件备份形成的文件传输，主要由 1500 字节构成的数据包。
Q3 : 视频流，每个包被分成 192 字节。
Q4 : 交互应用，主要由 64 字节构成的数据包。 这就产生了以下的情形：
Q1 消耗 4 倍于 Q4 的带宽 Q2 消耗 24 倍于 Q4 的带宽 Q3 消耗 3 倍于 Q4 的带宽
若要以同样的带宽接入网络，采用如下的配置：
Q1 权值设为 6
Q2 权值设为 1
Q3 权值设为 8
Q4 权值设为 24
如果分配了以上的权值，则在拥塞事件发生时，四个队列将分享到同样的带宽。
如果设置了绝对优先级队列， WR 权值将在其余三个队列中重新分配。下面是一个设置了绝对优先级，
而 Q4 没有进行配置的情况下，队列 1、2、3。
Q1 = 1 / (1+2+3) = 1/6 数据包输出
Q2 = 2/6 数据包输出
Q3 = 3/6 数据包输出
队列的权值可以通过 IOS show 命令进行验证：
nimokaka#sh mls qos interface gig 0/1 queueing GigabitEthernet0/1
QoS is disabled. Only one queue is used
When QoS is enabled, following settings will be applied
Egress expedite queue: dis wrr bandwidth weights:
qid-weights
1 - 25
2 - 25
3 - 25
4 - 25
如果启用了快速优先级队列，Q4 的权值仅在快速队列失效时使用。 看下面的示例：
nimokaka#sh mls qos interface gig 0/1 queueing
GigabitEthernet0/1
Egress expedite queue: ena wrr bandwidth weights:
qid-weights
1 - 25
2 - 25
3 - 25
4 - 25