WFQ/CBWFQ/LLQ介绍
WFQ/CBWFQ/LLQ
加权公平排队(Weighted Fair Queuing)缩写 WFQ。
它是一种拥塞管理算法，该算法识别对话(以数据流的形式)、分开属于各个对话的分组，并确保传输容量被这些独立的对话公平地分享。WFQ是在发生拥塞时稳定网络运行的一种自动的方法，它能提高处理性能并减少分组的重发。
WFQ(weighted fair queuing加权公平排队)
目标：
1为每个活动流提供公平的带宽分配机制
2为少量交互流提供更快的调度机制
3为高优先级流提供更多的带宽
WFQ：是一种基于流的排队算法，到达的数据包被分成多个流，每隔流都被分配给一个FIFO队列。
可以基于IP和TCP或UDP头中以下字段标识流：源IP地址 目的IP地址 协议号 TOS 源TCP/UDP端口号 目的TCP/UDP端口号
WFQ插入和丢弃策略
WFQ有一个保持队列（hold queue）,保持队列=WFQ系统中数据包占用的所有内存之和，数据包到达时，保持队列已满，那就丢弃数据包（WFQ主动丢弃WFQ aggressive dropping）
例外：数据包分配到一个空队列，不会丢弃
WFQ的优缺点：
主要优点 ：
WFQ配置简单，无需显示分类
不会让任何流得不到处理机会，能够保证所有流的吞吐量
从最主动的流中丢弃数据包，可以为非主动流提供更快的服务
是一种标准.简单的排队机制，大多数CISCO平台和IOS版本都支持
缺点
WFQ的分类和调度机制是不可配置和无法修改的
WFQ仅支持低速链路（2.048Mbit/s及以下的）
WFQ不能为流量流提供带宽和时延保证
WFQ系统中多个流量流可能会被分配到同一个对列中去
WFQ的配置和监控
默认情况下，所有低速（2.048Mbit/s及以下）串行接口都启用WFQ
接口模式下： fair-queue [cdt] [dynamic-queues] \\ cdt 为拥塞丢弃门限,dynamic 动态队列 默认为256
hold-queue max-limit out \\定义保持队列
CBWFQ基于类别的加权公平排队
比WFQ更好，因为可以创建用户自定义的类别，并为所有类别分配专属队列，每个队列都有用户自定义的（最小）带宽，而且在有可用带宽队列可以使用更多带宽。
最多可以创建64个用户自定义类别，每个队列都是有保证带宽和最大包门限的FIFO队列，一旦达到最大，就会产生尾部丢弃。
分类，调度和带宽保证
带宽
带宽百分比
带宽剩余百分比
CBWFQ的优点
可以创建用户自定义的类别，利用MQC的分类映射可以很容易地定义这些流量类别
可以基于用户策略和用户意愿为每种流量类别分配/预留带宽
可以基于现有网络应用和用户策略定义最多64个固定类别，从而提供微调手段，而且扩展性更好
缺点：没有为实时性应用提供合适地队列（VOIP 和 视频）无法保证低时延
配置和监控CBWFQ
LLQ
包含了一个优先级队列，使其非常适合时延和抖动敏感型应用
优点：
LLQ具有CBWFQ的所有优点，包括自定义流量类别，为每种类别的流量提供带宽保证，并确保可以在所有类别的队列上应用WRED。（严格优先级队列除外）
对于LLQ和CBWFQ来说，任何没有被显示分类的流量都被认为class-default流量，可以将class-default流量类别队列由FIFO改为WFQ,需要时也可以用WRED.
LLQ最大优势 可以为时延和抖动敏感型应用的流量提供一个或多个有带宽保证的严格优先级队列
LLQ并不局限于特定平台或传输介质
配置和监控LLQ
Weight Fair Queuing
配置WFQ:
1)特点:
*基于流的队列算法 //把同一个流的数据放到同一个队列中(即WFQ的分类是基于"流"，用户无法控制)
*将交互式流量(eg.telnet对响应时间要求高) 放在队列的前面，以减少响应时间;
将剩余带宽在不同流之间公平地分配;
防止大数据量的流(eg.FTP) 独占出接口
|-----FTP-----|
---------------------------R
|-telnet-|
交互式流量
FIFO：
FTP先到，先发送
WFQ:
在 "最后" 判断报文到达时间,何时收到完整的数据包，才认为到达
使得小报文(telnet)优先进行发送，该情况，认为telnet报文先到达设备
WFQ的思想:
i, 为每个流创建一个专用的队列，避免队列的 饥饿，延迟，抖动 等
ii, 在所有流间公平，正确地分配带宽
iii, WFQ使用 [IP优先级] 作为分配带宽的权重
注:WFQ中的flow亦称为conversation(会话)
注:在带宽小于等于E1(2.048Mbps)的串行接口上 缺省 使用WFQ
注:WFQ不能在配置 Tunneling 和 加密 的接口上使用
---Forwarded Packets|
|
|
Flow 1--------Weight值-------------
| \
| \
Flow 2--------Weight值------------- WFQ Scheduler-----> Hardware Queuing
| /
| /
Flow 4096--------Weight值----------
|
权重高的，一次多放报文;权重低的，一次少放报文即体现公平原则，同时体现权重原则
WFQ uses per-flow FIFO queues
参数:
-------IP-------- --TCP-- Payload Source IP Address
/ \ / \ Destination IP Address
Src. Dst Proto ToS | Src. Dst Source TCP or UDP Port
Addr. Addr Port Port Destination TCP or UDP Port
↓ ↓ ↓ ↓ ↓ ↓ Transport Protocol
ToS Field
Hash Algorithm
|
|-------→Queue Number
队列256，但网络中流1000个----→不同流配到同一个队列中
希望: 一个流对应一个队列
调度时就无法体现每个流公平调度机制
HASH结果:
flow 1
----→1个队列 。同一个队中不同的流是不作区分的
flow 2
解法:将队列个数调大
在WFQ中，要保证 队列个数 要大于 网络中流的个数，这样调度方式较为合理
流的多少设备无法控制
用户不干预 对流的分类，是自动分类的，WFQ的分类是由内部算法自动计算
带来的缺点:不能人工定义类别
用户可以定义信息:
WFQ队列:
8个队: 保留下来给系统使用Systems packets
0~1000个队: 保留给RSVP flows (0~1000)
剩下队列: 动态队列
一般接口配成256个队
队列可以调整，保证队列个数超过实际网络流的个数
the number of queues configured has to be significantly larger
than the expected number of flows
2)WFQ的分类方式
* 源IP地址 / 目标IP地址 / 协议号 / ToS字段 / 源TCP或UDP端口号 / 目标TCP或UDP端口号
注:WFQ中利用这些参数作为 hash算法 的输入参数，可以计算出对应队列的 索引号
因此，通常情况下，同一个流的数据将被分类到同一个队列中
注:WFQ中存在8个队列用于系统的报文发送,最多可配置1000个队列用于RSVP流，另外用户可以配置动态队列的个数
WFQ缺省使用的动态队列数取决于接口带宽，通常为256个动态队列,该参数取值范围是16~4096(必须是2的整数次幂)
注：若网络中存在较大的并发流，则可能2个不同流间分类到同一个队列中
因此在配置动态队列数量时，应该超过网络中实际并发流的数量
3)WFQ的插入，丢弃策略
WFQ Insertion and Drop Policy
---Forwarded Packets|
|
|
Flow 1--------Weight值-------------
| \
| \
Flow 2--------Weight值------------- WFQ Scheduler-----> Hardware Queuing
| /
| /
Flow 4096--------Weight值----------
|
|
队列多，但是报文是否能加入其中，要看实际情况：
1)-每个队列有长度(上限满了)，报文无法加入，丢弃! ---单独队列满
2)-队列中报文存在缓存，所有队列所有报文的数量有上限---所有报文数达到上限
以上二因素，可导致报文无法排到队列中!报文丢包!
WFQ always drops packets of the most aggressive flow
比较活跃的流，报文量最多的流进行丢弃，惩罚
丢包时特殊情况:
Drop mechanism exceptions:
1)要排到的队列是空的，不会被丢弃
a packet classified into an empty queue is never dropped
2)IP优先级不影响丢包机制，丢包时不考虑IP优先级
the packet IP precedence has no effect on the dropping scheme
配置WFQ优点和缺点:
Benefits:
1)simple configuration 配置简单
int s0
fair-queue //表示该接口使用了WFQ
不需要分类，用户无法配置
no need for classification to be configured
2)保证所有流都可以得到带宽,不会出现如PQ把低优先级别的数据饿死
Guarantees throughput to all flows
3)丢包时会优先丢弃比较活跃的报文
Drops packets of most aggressive flows
4)在思科大部分平台上都可以支持WFQ
supported on most platforms / in most Cisco IOS versions
Drawbacks:
1)多个流经过HASH算法后有可能落到同一个队列中
Possibility of multiple flows ending up in one queue
原因
1)--队列配得太少
(2)--网络中流太多，超过队列个数
2)不能对流进行分类，不能控制
lack of control over classification
3)只能在带宽小于等于2M的接口上支持
supported only on links less than or equal to 2 Mb
4)对不同流不能保障多少带宽，完全由WFQ的算法决定
每个不同的流是无法提供固定的带宽保证,可控性差
cannot provide fixed bandwidth guarantees
配置命令:
route(config-if):fair-queue cdt dynamic-queues reservable-queues
动态队列个数 保留队列个数
reservable-queues
保留队列个数：针对RSVP流,可以保留一定的队列，缺省是0，范围0~1000
dynamic-queues
动态队列个数: 缺省是256,流确实很多，可以调大，最大4096
cdt:
每个队自己的长度
一个数据排到第一个队中，cdt=64，如果该队的报文己达到64,新的报文丢包!
每个队中排的报文数量是有限的
所有队列加起来，上限:
hold-queue max-limit out
缺省1000
一个报文是否在WFQ中排到队列中的二个因素:
1)--本队列是否己满
2)--所有队列是否超出队列上限 ----超出报文丢弃
验证:
show interface s1/0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
size: 0 当前队列的报文数
max total: 1000(总数) 所有队列中报文累加最多能放报文的数量
threshold: 64 每个队最多可以放的报文数量
drop: 0 丢包情况
Conversations 0/1/256 (active/max active/max total)
WFQ中conversation(会话)=流
max active: 历史统计中最多的流数=1
active: 目前流数=0
max total: 256个动态队列 [若每个队都放64,超过]
若max active > max total，就要将队列调得更大
int s1/0
fair-queue 128 4096 1000
cdt 动态队列个数 所有队列最多能存多少数据(最多1000)
Output queue: 0/1000/128/0 (size/max total/threshold/drops)
size: 0 当前队列的报文数
max total: 1000(总数不变) 所有队列中报文累加最多能放报文的数量
threshold: 128 每个队最多可以放的报文数量
drop: 0 丢包情况
Conversations 0/1/4096 (active/max active/max total)
max total: 4096个动态队列,防止不同流配到同一个队列中
若这样就无法基于流来调度，没法区分
缺省：
1)--若带宽小于等于2.048M ------>WFQ
2)--其他情况------>FIFO
/ CBWFQ
WFQ----改进--->---/
\
\ LLQ
WFQ的hold-queue limit表示所有队列累计能够存放的最大报文数量
CDT(拥塞丢弃门限值)表示单个队列中能存放的最大报文数量
i,WFQ在以下情况时丢弃报文：
*当一个队列中的报文数量超过CDT,此时就算hold-queue未满，该报文还是丢弃
注：该丢弃方式可以用于限制最活跃的数据流
* 若所有队列中的报文总数已经超过hold-queue
ii、例外情况
* 若一个报文被排入空的队列中，它在任何情况下都不会被丢弃
* IP报文中的IP优先级字段不会影响WFQ的丢弃机制。
4）配置WFQ
Router(config)#int s0
Router(config-if)#fair-queue 128 1024 100
Router(config-if)#hold-queue 1200 out
注：设置s0接口使用WFQ，并设置动态队列数量为1024个队列，为RSVP流保留100个队列；
每个队列能够存放128个报文（CDT），所有队列最大的报文数量为1200（Hold-queue）
查看WFQ的命令
show interface 接口名称
show queue 接口名称
注：在WFQ中，weight的计算方式为4096/(IP优先级+1)或者32384r/(IP优先级+1)
因此在show queue中看到的weight值越大，表示权重越低。
------------------------------------
5、配置CBWFQ和LLQ
WFQ: 用户无法控制分类，由HASH算法自己决定
CBWFQ:让用户对流量自己来分类
WFQ 对正常流量处理没问题，但是对语音流量显得"太公平"(语音要求低延迟)
CBWFQ:考虑到公平特性，并没有考虑到语音的应用
为了保证语音可以优先传输，引入LLQ
Queuing Methods Combined融合网络应用:
包括:视频，语音，普通数据
LLQ = CBWFQ + Priority Queue
CBWFQ特点:
1)能够给不同的类保障一定的带宽
CBWFQ is a mechanism that is used to guarantee bandwidth to classes
2)对传统的WFQ作了扩展支持用户自己定义流量的分类:
3)队列的个数和类别是一一对应,给每个class 保留带宽
a queue is reserved for each class
CBWFQ Architecture(构造)
classification由用户定义
并流量分配到不同class中,针对不同class定义不同带宽值
|---报文4--> Class 1 \
| Bandwidth = 64 \
| \
|---报文3--> Class 2 \
-4-3-2-1->| Bandwidth = 128----- WFQ----2-1--4--3---->
| / 报文
| /
|---报文2-1-->Class 3 /
| Bandwidth = 32
权重和带宽 成 正比关系
带宽值越大，权重值越大,通过带宽的参数配置，控制权重比例
配置工作
分类:
策略:指定类有多少带宽Bandwidth avaliability can be defined by specifying:
带宽指定方式:
(1) ---Bandwidth ( in kbps ) //<8-2000000>
(2) ---Percentage of bandwidth //percent
百分比
(3) ---Percentage of remaining available bandwidth //remaining
剩余可用带宽的百分比
计算公式:
Bandwidth(avail) = Bandwidth * MaxReservable - SUM(all fixed guarantees)
剩余的可用带宽 = 接口带宽值*最大的保留百分比 - 己经分配出去的带宽
1.544M * 75%(缺省值)
并不是把所有带宽都转发我们的数据，
一些系统的报文也需要发送，通常会保留25%作为系统的目的使用
缺省情况下接口保留带宽值75%(即用户可以使用75%带宽)
-----10G带宽，若使用到7.5G时，就要扩容!
CBWFQ:
Benefits:
1)自己可以分类
Custom-defined classifications
2)对不同类进行带宽的分配
Minimum bandwidth allocation
3)具有更好的调节能力和扩展性
Finer granularity and scalability
Drawback:
语音无法得到很好的服务质量，对语音来说不合适，语音要求有比较小的延迟
Voice traffic can still suffer unacceptable delay
CBWFQ的缺点-----太公平，轮询方式调度，没法保证语音业务得到保障
CBWFQ配置:
定义一个类
定义 策略
在策略policy-map里配置带宽:
router(config-pmap-c)#
bandwidth bandwidth
bandwidth percent percent
bandwidth remaining percent percent
队列满了如何丢包?
router(config-pmap-c)#
queue-limit queue-limit
--定义每个队能存放的报文数量(队列长度)
eg.
queue-limit 128 //报文超过128就丢包，丢包方式:Tail-Drop
队列满之后，后继报文才会丢弃
--丢包方式--
方式一:尾丢弃
policy-map mypolicy
class class01
bandwidth 128
queue-limit 128 //尾丢弃
方式二:random-detect随机早期检测
policy-map mypolicy
class class01
bandwidth 128
random-detect //随机早期检测“丢弃”
二者冲突!
fair-queue [number-of-dynamic-queues]
配置实例：
HTTP流量保障256Kbps带宽
FTP流量保证512Kbps带宽
class-map class_HTTP //定义类
match protocol http
class-map class_FTP
match protocol ftp
class-map class_BT
match protocol bittorrent
policy-map Policy_HTTP_FTP //定义"策略"
class class_HTTP
bandwidth 256
class class_FTP
bandwidth 512
class class_BT
drop
class class-default //网络中剩下流量(除了http,ftp)使用WFQ自动放到fair-queue
fair-queue
int fa0/0 //最后应用到相应物理接口
service-policy output Policy_HTTP_FTP
//问题:语音无法保障
相对CQ-字节数无法保障带宽比例,WFQ可以保证
查看命令: show policy-map interface
另
配置实例:
class-map match-all class_office
match access-group name acl_office
class-map mathc-all class_student
match access-group name acl_student
policy-map polic_ald
class class_office
priority 1920 //优先级队列，保留带宽1.92M
class class_student
shape average 128000 //×××,最多带宽128k
class class-default
fair-queue //其它所有流量，加权公平队列
inter f0/0
service-policy output policy_ald //接口应用
限速，报文过滤 使用QoS MQC方式!
ACL只能过滤第三层，第四层信息，不能过滤应用层
1）CBWFQ
i、特点
* 确保每种类别流量的带宽
* 扩展WFQ的功能，提供用户自定义流量类别的功能
* 每一种类对应一个队列
注：CBWFQ支持多个类，在每个类对应的FIFO队列中缺省采用Tail Drop方式进行丢包，也可以支持WRED方式。
ii、分类
使用class－map方式对流量进行分类
iii、调度
根据不同类的权重来保证带宽。（注：思科设备会根据给不同类配置的带宽值或百分比，计算每个类的权重）
带宽的配置方式：
a）bandwidth（kbps）
命令：bandwidth 带宽值
注：配置的带宽值必须在该接口的保留带宽内。（缺省情况下一个接口的保留带宽为75％，其余保留给系统用途）
b）带宽百分比（接口可用带宽的百分比）
命令：bandwidth percent 百分比
c）剩余可用带宽的百分比
命令：bandwidth remaining percent 百分比
注：如何配置接口的保留带宽？
int s1/0
max-reserved-bandwidth 百分比（缺省为75％）
配置实例：
HTTP流量保障256Kbps带宽
FTP流量保证512Kbps带宽
class-map class_HTTP
match protocol http
class-map class_FTP
match protocol ftp
class-map class_BT
match protocol bittorrent
policy-map Policy_HTTP_FTP
class class_HTTP
bandwidth 256
class class_FTP
bandwidth 512
class class_BT
drop
class class-default
fair-queue
int fa0/0
service-policy output Policy_HTTP_FTP
------------------------------
A priority queue is added to CBWFQ for real-time traffic
新增PQ，目的是为了实时流量提供服务
CBWFQ:为每个流量进行分类，对类定义带宽
LLQ目的:在CBWFQ之上，对实时的流量提供更高优先级的支持
高优先级的流量保证:
High-priority classes are guaranteed:
低延迟保证
-Low-latency propagation of packets
保障一定带宽
-Bandwidth
在任何情况下，语音数据都优先得到发送
网络中语音流量过多，是否会占用更多的带宽?--NO
高优先级的数据在保证"低延迟传播"和"带宽"时，可以管制"policy"
当网络发生拥塞时，高优先级的分类所占用的带宽 不能超过 保障的带宽值
High-priority classes are also policed when congestion occurs-they
then cannot exceed their guaranteed bandwidth
保留128K带宽，上限值!发生拥塞时不允许超过128k值
超过该值的数据丢弃!
低优先级的分类 还是 CBWFQ!
Lower-priority classes use CBWFQ
LLQ Architecture架构:
【Forwarded Packets】
↓ 【Priority Queue】上半部分优先级队列,分类将重要数据排到PQ中
↓
Class ---→Bandwidth ---→
Priority Policing |→Priority Queue----→ |
↓ |→ (FIFO) |
Class ---→Bandwidth ---→ V V V V |
Priority Policing |
↓ |
↓ |----→【Hardware
↓ | Queuing System】
↓ 【 CBWFQ 】剩下流量按CBWFQ分类 | Hardware Queue ----→Interface
Class 1?---->Tail-Drop--->Queue 1 ---→| | V V V
↓ | |
↓ | CBWFQ---→| V=Voice 语音优先转发，然后才是其它类别数据
Class 2?---->Tail-Drop--->Queue 2 ---→|Scheduler
↓ |
↓ |
Class 3?---->Tail-Drop--->Queue 3 ---→|
LLQ基本可以满足企业中融合的网络应用
支持语音对网络的低延迟，抖动小，保障带宽
对其它流量提供公平处理
LLQ Benefits:优点
1)高优先级队列服务质量很到保证，特别是针对语音业务
High-priority classes are guaranteed:
--Low-latency propagation of packets
--Bandwidth
2)LLQ包含了CBWFQ,所以网络流量的分类，用户可以自己定义!
Entrance criteria to a class can be defined by an ACL
CBWFQ配置参数: bandwidth
LLQ的配置:
router(config-pmap-c)#
priority bandwidth [burst] // 表示这个类所处的队列是优先级队列
给优先级队列保证的带宽
*Traffic exceeding the specified bandwidth is dropped if congestion exists;
otherwise,policing is not used
若优先级较高的数据流量在网络拥塞时流量超出定义的带宽值
超出部分将被丢弃!
若网络没有拥塞，这个类的流量是可以超过带宽值
作的策略，网络没有拥塞时，不会生效!
网络拥塞之后，PQ队列中的数据最大的带宽不能超过bandwith值
router(config-pmap-c)#
priority percent percentage [burst]
接口带宽的百分比
配置实例:
class-map voip
match ip precedence 5 (通常IP优先级=5为语音流量)
class-map mission-critical (关键业务流量)
match ip precedence 3 4
class-map transactional (事务型流量)
match ip precedence 1 2
policy-map Policy1
class voip
priority percent 10 //针对VOIP类使用PQ,这路流量在任何情况下都是优先发送
同时最大可以带宽为接口带宽的10%
class mission-critical \
bandwidth percent 30 \
\
class transactional / ----CBWFQ方式进行调度，分别保障30%和20%接口带宽
bandwidth percent 20 /
class class-default -----剩下其它队列采用缺省的WFQ调度
fair-queue
2）LLQ（低延迟队列）
i、特点
在CBWFQ中添加一个优先级队列用于实时的流量。
* 高优先级队列得到如下保障：
a）低延迟的报文转发
b）带宽
注：在拥塞发生时，高优先级的流量同时受到管制---即它们占用的带宽不能超过它们所保障的带宽。
* 低优先级队列使用CBWFQ。
ii、配置LLQ
priority 带宽值----为一个类分配固定的带宽值确保快速转发；若拥塞时，超过该带宽的流量将被丢弃。（若没有拥塞，将不会使用管制）
配置实例：
class-map voip
match ip precedence 5
class-map mission-critical
match ip precedence 3 4
class-map transactional
match ip precedence 1 2
policy-map policy1
class voip
priority percent 10
class mission-critical
bandwidth percent 30
class transactional
bandwidth percent 20
class class-default
fair-queue
int s1/0
service-policy output policy1
使用该QoS的结果：
i.若网络没有拥塞，所有数据都可以得到调度!
ii,若网络发生拥塞，voip类的数据优先发送，并且它占用的带宽不能超过接口的10%。始终优先发送，流量太大会管制!
mission-critical类的数据可以保证它至少有30%*接口带宽(CBWFQ保证发生拥塞时的下限，至少有30%的带宽)
为什么voIP中需要使用CAC（呼叫接入控制）来限制并发的voip呼叫数量?
CAC: QoS无法对不同的voip呼叫进行区分，若未使用CAC，则一旦呼叫数量超出一定的数量，
在网络发生拥塞时，可能导致所有呼叫的报文被丢弃(具体丢哪个呼叫不一定)，使得所有呼叫的质量下降。
使用CAC来限制网络中并发呼叫数据的原因!
网络没有拥塞，说明硬件队列没有满，一个数据要转发，直接排到硬件队列!(硬件队列不能调度)能调度的只是软件队列部分
一般情况下，硬件队列长度不是很长，若做很长，语音就没法得到合理保证
查看不同平台硬件队列长度：
show control int s0/0 -2个硬件队列
show control int fa0/0 -4个硬件队列
查看命令:
来观察接口中使用的队列情况
show policy-map interface f0/0
Summary:
FIFO
PQ ---机制简单配置麻烦
CQ ---机制简单配置麻烦
WFQ
CBWFQ ----适用
LLQ
转载于:https://blog.51cto.com/nalushenxian/634236