WFQ加权公平队列(每个队列的计算原则与权重比关系)
及加权效果取证
加权公平队列(Weighted FairQueuing),它不允许用户使用MQC语句来手工完成对流量的分类,因为WFQ的分类是自动完成的,它基于每一种不同的流(flow)来分类,然后将不同的flow送入不同的队列。在实施WFQ的队列调度时主要是为了两个目标:一、为不同的数据流提供公平的服务;二、它可以为具备高优先级(较高IP优先级或者DSCP值)的数据提供更多的带宽,使其得到更好的服务。现在首先来理解如下五个重要的知识点:
1、WFQ如何自动去完成对不同流(flow)的分类,这依赖于数据中的那些关键因素?
2、WFQ如何为不同的流提供公平的服务?
3、WFQ如何为高优先级的流提供更多的带宽?
4、WFQ的计度计划与SN的计算公式,先转发谁?再转发谁?
5、WFQ的丢弃策略、队列数量和队列长度
6、WFQ调度器的总体执行流程
1 WFQ如何自动去完成对不同流(flow)的分类,这依赖于数据中的那些关键因素?
WFQ是不能通过用户配置策略ACL或者数据的TOS字段去匹配数据来完成分类的,它将自动将相同的流分配到同一个类别中,那么什么是相同的流?很简单,一般而言,只要具备相同的源IP地址、目标IP地址、相同的传输层协议(TCP或者UDP)、源端口、目标端口这五个关键的因素,那么WFQ会认为这是同一个流,会将其规划到同一个类别中。WFQ这种分类的方式是不能被人工干预的,而且这种分类随时都可能变,因为流活跃和变化都非常的迅速,也就是说可能用户通过show queue查看当前WFQ分类的排队信息的时候,活跃的流已经发生变化了。
因为WFQ是基于不同的流来完成自动分类,然后将针对不同的类产生队列,事实上也就是每一个流一个队列,那么WFQ最多可以支持4096个队列,可看出WFQ所支持的队列数非常庞大。另外一个问题就是很多时候,用户会提出疑问:WFQ分类时为什么不去关注TOS字段,因为该字段中包含着IP优先级和DSCP值?事实这个问题并不重要,因为在一个良好的网络设计中属于同一个流的TOS字段中的IP优先级或者DSCP值是相同的。
2 WFQ如何为不同的流提供公平的服务?
这种情况是一种很理想的情况,WFQ将为网络中不同的流分配相同的带宽,打个比喻:假设整个链路具备256K的带宽,如果网络中存在10个不同的流(事实上也就是10个分类)那么,在理想状态下,这10个流将每个分别获得25.6K的带宽。为什么说它是理想的状态?依照上述的分配原则,那么这10个流的必须是具备相同的优先级、相同的数据包长度、相同的权重等因素,才能保证它们每个能公平的分得25.6K的带宽,因为WFQ为不同的流分配带宽时,会考虑权重(Weighted),实其从WFQ的名称就不难看出,它叫加权公平队列,而权重又直接和IP优先级和DSCP值有关,关于这一点在后面部分会详细描述。
在目前所描述的WFQ为不同流提供公平服务的环境中,可以得出这样一个结论:如果流量体积越小,那么它所获得的服务质量就越高,反之,流的体积越大它所能获得的服务质量就越低。为什么呢?仍然遵守上面的描述,假设现在每个流可以分得25.6K的带宽,如果此时流1需要10K的带宽来转发数据,那么流量1的数据将能得到迅速转发,因为WFQ可以为流1提供25.6K的带宽,而它的转发只需要10K,相反如果流2需要40K的带宽来转发数据,那么相对于流1而言流2就不能得到更好的服务质量保证,因为WFQ为每个流公平的分配了25.6K的带宽,而流2需要的带宽超过了其本身队列分配的25.6K,所以流2会被延迟。当然WFQ调度程序可以将流量1没有使用的多余带宽分配给其它的流。根据上面的描述,不难看出WFQ很像时分复用系统(TDM)。
3、WFQ如何为高优先级的流提供更多的带宽?
WFQ可以高优先级的流量提供更多的带宽,它根据优先级+1来计算带宽分配的比率,打个比方说:现在网络中一共有10个流,其中5个使用默认的优先级尽力而为(也就是0),另外5个使用IP优先级1,那么根据IP优先级加1的计算原则是(1+1):(0+1)=2:1,也就是说此时5个使用IP优先级1的流量将获得比5个使用IP优先级0的流要多一倍的带宽。关于这一点在计算机SN号的时候可以被体显出来,后面会有实例作详细分析。如果网络现在的总体带宽为256K,那么使用IP优先1的流将使用大约170K左右的带宽,而IP优先级为0的将使用大约85K左右的带宽。
根据上面的描述,不难得到一个关于WFQ的结论:如果不考虑IP优先级,那么体积较小的流将得到比体积效大的流更好的服务,如果考虑IP优先级,那么高IP优先级的流将比低IP优先级的流得到更好的服务,如果体积很小,同时IP优先级也很高的流,那么它将得到最好的服务,通常是指这类流的带宽/延迟/抖动/丢弃都会得到最大化的改善。
注意:关于WFQ能为高优先级的流量提供更多的带宽将在“取证演示:配置WFQ队列及影响数据传输的效果”部分作描述。
4、WFQ的调度计划与SN的计算公式,先转发谁?再转发谁?
WFQ会给自动划分的每个流一定带宽的带宽比例,但是这个比例随时都可能发生变化,而且变化得很快,所以不是很好统计和分析,为什么呢?因为一个流是即时的,发送完成就不存在了,而且这个时间相对于人类的感观而言,非常的短暂。说明这个观点的目的是为了指引出一个原则:不能简单的将WFQ理解为:假设链路256K的带宽,被分给10个流,每个流就是25.6K的带宽,这个描述仅于初次理解WFQ时对它的“公平性”进行一个形象的比喻,因为的确最佳的比喻方式就是实例化和数字化。但这并不是WFQ最真实的工作机制。或者读者现在可以进一步的理解WFQ是在网络发生拥塞时,它能让每个队列的数据都得到尽量可能公平的服务,也就是说WFQ的调度器能让每个队列的数据都得到调度,而不像PQ那样工作。至于这个调度机制是否满足用户网络的服务特点,那就必须针对特定的情况了,但是现在应该来理解WFQ如何去调度不同队列的数据。
WFQ调度原则:
当路由器硬件队列空闲或者还有空间时,WFQ将具备最小SN(sequence Number序例号)的数据包调度进入硬件队列发送,那么什么是SN,如何计算SN就是关键?
SN的计算公式与演示实例
当前数据包的SN=前一个数据包SN+(权重*当前数据包的长度)
权重=32384/(IP优先级+1)
假设被送入TX硬件队列的前一个数据包的SN为200,而当前数据的长度为1500,优先级为1,那么首先应该计算当前数据包的权重,即32384除以(1+1)等于16192,然后用当前数据包的权重16192乘以当前包的长度1500等于24288000,最后再加上前一个包的SN200就等于24288200。所以当前数据包的SN=24288200.
为了体现WFQ关于SN的计算及权重所引发的公平性问题,及参入优先级后WFQ会提供更多转发机率的问题,现在举一些更复杂些的实例。
实例1:优先级相等,较小的数据包能得到更好的服务质量保证
假设有如图所示的4个流,第个流中有4个数据包,第个流的数据包都有不同的数据长度,而且所有数据包的IP优先级都是0,因为在这里笔者将首先讨论全部数据包优先级都是0的情况下,WFQ的调度过程。为了在理论下分析方便,目前假设每一个流的第一数据包前面的SN号都是0。
那么使用上面所描述的关于SN的计算机公式,可以得到图中关于从D1…….A4,总共16个数据包的SN,然后再根据WFQ首先调度低SN号的原则,那么在图所示的环境中,WFQ执行这样这个调度顺序:D1、D2、D3、D4、C1、B1、C2、A1、C3、B2、C4、A2、B3、B4、A3、A4。根据这样的调度顺序,不难看出WFQ在数据的优先级都相等的情况下,体积越小的数据包越容易得到更好的服务,比如图中的流D中的数据包得到最先的转发,流C次之,流B和流A更次之。但是也可以看出至少不同4个流中的数据在不同程度都能得到服务,不至于“饿死”队列中的数据,这是WFQ所谓“公平”之处。记住优先级相同,那么数据包的尺寸最大,所产生的SN就越大,被立即调度的可能性就会靠后。
实例2:优先级较高的数据包能得到更好的服务质量保证
如果此时将流C数据的IP优先级设为3,而其它条件都不变的情况下,如图所示,明显可看出流C的每个数据的SN号被降低,也就是说流C被优先调度的可能性增大,然后按照WFQ优先调度低SN的原则,目前的调度顺序是:D1、C1、D2、C2、D3、C3、D4、C4、B1、A1、B2、A2、B3、A3、B4、A4。通过这个优先调度低SN的原则,可以对比先前没有更改优先级时的调度顺序,不难发现:流C的IP优先级被设置为3后,它获得了更多的调度,也就是它可以使用更多的带宽,因为优先级变高,权重就会变小,那么通过SN计算公式得出的SN号就会更小,所以它更容易被调度。
此时流C的IP优先级为3时比它的IP优先级为0时获得了多4倍的带宽,为什么这样讲?大家是否还记得在笔者在描述“3、WFQ如何为高优先级的流提供更多的带宽”提到过一个公式:(X+1):(0+1),X表示当前的IP优先级,使用这个公式可以计算机出流C的IP优先级为3时和它为0时对带宽使用比例的公式:(3+1):(0+1)=4:1,也就是说当流C的IP优先级变为3时是IP优先级为0时使用带宽的4倍,而且数学就是一个很有趣的工具,为什么呢? 如图所示:你会发现流C的IP优先级为3时计算出来的SN正好比IP优先0时计算出的SN小4倍,请记住哟:WFQ是先调度较小SN的原则,这意味着什么不言而喻!
通过上面的各种演算实例可以看出WFQ的几个特性:
1权重与优先级是成反比的,优先级越高,权重最小,那么生产的SN就越小,就越容易被WFQ优先调度,这个特性源于,WFQ总是为高优先级的数据分配更多的带宽。
2如果优先级相同,那么大体积的数据相较于小体积的数据不能得到更好的服务质量。
3如果数据包体积较小,并且IP优先级较高,那么这种数据将得到最佳的服务质量。
4 WFQ可以为每一个流都提供服务,不管服务的质量是好或者差,至少不至于“饿死”不同队列中的数据,这是它和PQ最大的不同。
5、WFQ的队列数量、队列长度、丢弃策略
WFQ支持4096个队列数量,关于WFQ队列的长度,它有两种可能,因为WFQ为每个流可以规划一个队列,所以WFQ为每个流,实际上就是针对不同流的每个队列规划了一个CDT(CongestiveDiscard Threshold拥塞丢弃门限值),用户可以把该值理解为针对每个流队列的长度,默认情况下每个队列的CDT值最大为4096;另一种是将全部队列设置了一个绝对长度,通常也称呼该长度为排队限制(Hold-QueueLimit);这个排队限制的最大长度值也是4096。关于配置整体队列长度、最大的针对每个流队列的数量、CDT如下所示:
配置整体队列长度和CDT:
R1(config)#intes1/0
R1(config-if)#hold-queue1500 out * 设置所有队列的整体长度为1500
R1(config-if)#fair-queue120 64
*每个针对流的具体队列的CDT为120,也就是当达到该值时,具体针对不同流的队列为了避免拥塞开始丢弃该队列中的数据包;可以最多有64个针对不同流所创建的动态队列,注意其实在64后面还有一个参数叫“Reservable Conversation Queues(可预留的会话队列)”这是一个让RSVP让WFQ为每个RSVP预留流,创建队列的选项,由于该配置关联到RSVP的知识点,它不在路由交换类CCNP的范围,所以这里不作更多描述。
可以通过show inte s1/0接口,如图所示,可以看到整体输出队列的大小为1500,每个队列的CDT丢弃门限为120,允许一个接口最多能创建64个动态队列。当然用户也可以通过执行Show queueing fair指令来查看加权公平队列,具体显示如图所示,也可以看到允许的最大队列数及队列的CDT丢弃门限值,但是这里需要注意的是在显示中出现了8个Link queues(链路队列),这8个队列是为路由器产生的开销流量提供服务的,也就是在许多文档中所描述的WFQ维护的8个隐式队列。
注意:在配置WFQ的队列时,用户只能在16-4096这个范围进行配置,而且必须是16的倍数,比如:16、32、64、128……等这些值将是有效的,为什么会有这样的一个限制呢?主要的原因是WFQ要使用hash算法来分类,由于某些数学原因,只有将队列的数量配置为16的倍数时,才可能运行hash算法。
在理解WFQ的队列长度及丢弃门限后,不得不讨论的一个问题就是WFQ的丢弃策略,WFQ它仍然是使用“尾弃”策略,但是这个“尾弃”策略是经过调整后的“尾弃”,为什么这样讲?如图所示,首先WFQ对全部队列作了一个排队限制(Hold-Queue Limit),当某一个数据包的到来,并且排队限制(即整体全部的队列)已经满载,那么这个数据包将被丢弃,但是这个丢弃决定并不是针对某一个单一的队列(因为不同流会有不同的队列)作出的。那么就还有一种情况,就是到来新的数据包时,排队限制(即整体全部的队列)还未满载,那么IOS系统将计算新数据包的SN,然后决定某个针对具体流的单独队列是否满载,实际上也就是看某个具体的队列是否达到了CDT门限,如果没有达到具体队列的CDT门限,就将该数据包送入具体的某个队列排队,如果此时该具体队列已经满载,注意此时WFQ将不仅是执行简单的“尾弃”,而是去查看其它的针对不同流的队列中是否排入了一个比当前数据包具备更大SN编号的数据,如果有WFQ则转而去丢弃那个比当前数据包更大SN的数据,这样做的一个目的是WFQ在已经达到CDT值时为较低SN数据包服务,避免较低SN的数据包不能得到排队处理而被“饿死”。
6、WFQ调度器的总体执行流程
现在对WFQ的零散知识点分别做了相关的描述,剩下来的事情就是将上面描述的各个零散知识点组织成一个完整的关于WFQ的整体调度流程。如图所示:可以看出在这个过程中,数据包在接入路由器后,被WFQ根据流(flow)的五个关键因素所分类,注意这个分类是WFQ自动完成分类,管员不能手工配置,然后判断是否达到整体队列长度(绝对长度)然后计算SN值,再交给丢弃策略做决定,这里的丢弃策略是指队列满载时(当然这里针对的是具体的流队列),值得一提的是计算SN是在丢弃策略判断之前进行计算的,因为丢弃策略会考虑SN的大小。如果队列没有满载,那么WFQ优先调度具备较小SN的数据包,然后将其输送到硬件队列。
取证演示:配置WFQ队列及影响数据传输的效果
演示目标:
1 仍然是首先模拟低速链路,该环境为56K。
2 将队列配置为FIFO,观察环境中的大体积流量“垄断”带宽现象,小体积流量延迟很大
3配置队列为WFQ,在持续大体积流量传输时,再次观察小体积流量的延迟变化
4完成采样在未使用优先级加权时,WFQ队列下小体积流量的平均延迟。
5配置小体积流量具备更高的优先级来加权WFQ队列,再次采样加权优先级后的平均延迟
6 观察WFQ队列的关键显示,自动分类情况、队列长度、CDT值、丢弃情况等。
演示环境:如图所示。
演示步骤:
第一步:
R1(config)#intes1/0
R1(config-if)#nofair-queue
R1(config-if)#exit
R1(config)#intes1/0
R1(config-if)#fair-queue
R1(config-if)#exit
通过把192.168.2.101和客户机之间的ICMP流量的IP优先级调高,此时主机到192.168.2.101的流量被WFQ最优先调度的可能性就越大,未加权时如下图所示。
R1(config)#access-list 101 permit icmp host192.168.2.101 host 192.168.4.2
R1(config)#class-map icmp
R1(config-cmap)#match access-group 101
R1(config-cmap)#exit
R1(config)#policy-mapqos
R1(config-pmap)#classicmp
R1(config-pmap-c)#set ip precedence 7
R1(config-pmap-c)#exit
R1(config)#intee2/0
R1(config-if)#service-policy input qos
R1(config-if)#exit
加权后的延迟:
完成实验取证后总结WFQ队列的优势与不足:
WFQ具备最少的配置,能为不同的流量自动分类,并最大公平的分配带宽,这样所有进入网络设备的流量都能得到服务,不至于“饿死”某个队列中的数据,所以它符合在低速链路上作为一种默认队列方式被启动,因为默认所有的流量被平等对待,这恰好引出了WFQ的不足,至少WFQ具有如下几个天生的缺点:
1、它不能被用户以“应需而动”的原则执行基于用户期望的流量分类
2、它不能为不同类别的流量去申明使用用户所期望的链路资源(带宽)
3、它过于公平,无法满足一些特定环境的流量订制计划。
由于上述的三个重要原因:所以必须要产生一种能突破上述三个原因的队列工具,而后
继紧接着将要描述的队列工具CBWFQ能破突这些限制。
本文出自 “无名的基督” 博客,谢绝转载!
WFQ加权公平队列(每个队列的计算原则与权重比关系)加权效果后转发取证
原文地址:http://7658423.blog.51cto.com/7648423/1587658