加载中…
个人资料
  • 博客等级:
  • 博客积分:
  • 博客访问:
  • 关注人气:
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
正文 字体大小:

Yeslab安德CCIE技术文档QoS之WRED

(2013-01-18 11:34:06)
标签:

ccie

ccnp

redhat

rhca

yeslab

杂谈

一、理论支持

Random Early Detection(RED)早期检测随即丢弃
        拥塞避免机制,首先我们要说的是尾丢弃的问题,简单的尾丢弃有故在的弱点的,比如会引起TCP的同步,一些TCP session被饿死,导致高时延以及没有区别的丢弃。所以在拥塞管理(软件队列机制)之前引入了拥塞避免
        引入拥塞避免我们又要从TCP说起,网络中应用最多的就是TCP连接了(当然现在UDP也很多)对UDP来说当包被丢弃时,不会有任何相应,因为UDP没有任何机制去检测包被丢弃了而TCP在意识到包被丢弃后会降速。这里用到了sequence和ACK这两位。TCP接收者端没有收到包或者没有收到任何ACK,发送者认为报文是丢失了,更重要的是,发送者也会降低发送数据的速度TCP发送者在包被丢弃之后会减低发送速率。通过丢弃一定数量的包,拥塞避免工具会让TCP连接降速,从而避免拥塞,所以拥塞避免机制是一种主动的拥塞管理,而队列机制是一种被动的拥塞管理,TCP用两个不同的窗口机制来决定可以发送的数据大小:通告窗口大小(接收者)和拥塞窗口CWND(抓包可见)。
        拥塞窗口机制带来的问题是TCP的慢启动,不同的TCP session在不同时间开始,TCP的窗口大小持续增长,导致慢启动(TCP数据按照指数级增长所有的session到达同一高度-速率),这个是无法改变的,如下图所示
         如果到达一定速率,导致拥塞,不能接受的是这种丢弃发生在同一时间,TCP session在同一时间重启动,这称之为TCP的同步。可以把TCP的同步理解为所有人同一时间在上午九点钟上班,下午五点钟下班会导致交通在这两个时段拥塞所以我们的结论是利用TCP在丢包之后会降速的机制避免TCP的同步(可以理解为错时上下班)早期随机检测是一种在队列满之前的一种丢弃机制;RED随着增长而丢弃报文;RED导致以下结果:TCP降到和出接口带宽等同的速率,平均队列size更小(远远小于软件队列的最大队列深度,不致于发生尾丢弃);IP优先级低的更容易被丢弃  

二、拓扑描述

如图所示,已经配置了串行链路的直连地址以及IGP协议

三、实验步骤

1、基于接口的WRED(加权早期随即丢弃)

R2(config)#int s1/0
R2(config-if)#random-detect---默认情况下这里的权重为基于IP优先级 
验证
R2#sh queueing random-detect---需要注意的是,这里的验证命令是查看队列(虽然我们不是在查看队列)
Current random-detect configuration:
Serial1/0---s1/0接口已经启用了WRED
        Queueing strategy: random early detection (WRED)---这里也比较容易让人迷惑,这里显示为一个RED队列,其实这不是一个队列,但是默认情况下,接口开启了RED之后不能再修改为其他队列,下面我们会拿WFQ做一个反例
    Random-detect not active on the dialer
    Exp-weight-constant: 9 (1/512)
    Mean queue depth: 0 
  class      Random drop      Tail drop    Minimum Maximum  Mark
            pkts/bytes       pkts/bytes    thresh  thresh   prob
          0/0              0/0           20      40  1/10
          0/0              0/0           22      40  1/10
          0/0              0/0           24      40  1/10
          0/0              0/0           26      40  1/10
          0/0              0/0           28      40  1/10
          0/0              0/0           31      40  1/10
          0/0              0/0           33      40  1/10
          0/0              0/0           35      40  1/10
    rsvp      0/0              0/0           37      40  1/10
让我们来解读上面的验证情况:
         默认为基于IP优先级的WRED,不同的优先级有不同的最小丢弃阀值,比如优先级为0(第一行)的流量最小丢弃阀值为20,在队列还没有满的时候,如果到达20个包,那么就开始随即的丢弃报文(小于20的时候是没有丢弃的),丢弃可能性为10%;最大丢弃阀值为40,如果到达40个报文,那么为百分百的尾丢弃;优先级越高,丢弃可能性越小,拿优先级7来对比,它的最小丢弃阀值为35,也就是说先进先出队列中有35个包的时候开始了随即丢弃,而优先级6的是到达33就开始随机丢弃了
R2(config)#int s1/0
R2(config-if)#fair-queue
Must remove RED configuration first.---默认情况仅仅支持FIFO的队列(FIFO队列深度为40个报文)
可以人为的修改每一个IP优先级的最小和最大丢弃阀值,以及丢弃可能性(分母):
        R2(config-if)#random-detect precedence 6 10 39 8---把IP优先级6的流量的最小丢弃阀值改为10,最大丢弃阀值为39,丢弃可能性为八分之一(即最后一个数字8
R2#sh queueing interface s1/0
Interface Serial1/0 queueing strategy: random early detection (WRED)
    Random-detect not active on the dialer
    Exp-weight-constant: 9 (1/512)
    Mean queue depth: 0 
  class          Random drop      Tail drop    Minimum Maximum  Mark
                  pkts/bytes       pkts/bytes    thresh  thresh  prob
          0/0              0/0           20      40  1/10
          0/0              0/0           22      40  1/10
          0/0              0/0           24      40  1/10
          0/0              0/0           26      40  1/10
          0/0              0/0           28      40  1/10
          0/0              0/0           31      40  1/10
          0/0              0/0           10      39  1/8
          0/0              0/0           35      40  1/10
   rsvp      0/0              0/0           37      40  1/10
 
在IOS中可以有不同的丢弃Profile,默认基于IP优先级,也可以基于DSCP
R2(config-if)#random-detect dscp-based
 
R2#sh queueing interface s1/0
Interface Serial1/0 queueing strategy: random early detection (WRED)
    Random-detect not active on the dialer
    Exp-weight-constant: 9 (1/512)
    Mean queue depth: 0
    dscp          Random drop      Tail drop    Minimum Maximum  Mark
                  pkts/bytes       pkts/bytes    thresh  thresh  prob
   af11      0/0              0/0           33      40  1/10
   af12      0/0              0/0           28      40  1/10
   af13      0/0              0/0           24      40  1/10
   af21      0/0              0/0           33      40  1/10
   af22      0/0              0/0           28      40  1/10
   af23      0/0              0/0           24      40  1/10
   af31      0/0              0/0           33      40  1/10
   af32      0/0              0/0           28      40  1/10
   af33      0/0              0/0           24      40  1/10
   af41      0/0              0/0           33      40  1/10
   af42      0/0              0/0           28      40  1/10
   af43      0/0              0/0           24      40  1/10
    cs1      0/0              0/0           22      40  1/10
    cs2      0/0              0/0           24      40  1/10
    cs3      0/0              0/0           26      40  1/10
    cs4      0/0              0/0           28      40  1/10
    cs5      0/0              0/0           31      40  1/10
    cs6      0/0              0/0           33      40  1/10
    cs7      0/0              0/0           35      40  1/10
     ef      0/0              0/0           37      40  1/10
   rsvp      0/0              0/0           37      40  1/10
default       0/0              0/0           20      40  1/10
 
        让我们回忆一下我们讲到DSCP的AF(确保转发)类的时候,我们提到过AF的结构为AAADD0,其中DD这里表示丢弃可能性,那么AF13和AF33的丢弃可能性是相同的,如上所示也验证了这一点,基于DSCP的时候EF和RSVP的最低丢弃阀值都为37。
下面我们修改某一个DSCP的丢弃可能性和阀值 
R2(config-if)#random-detect dscp af43 37 40 11---对DSCP43的流量,最小丢弃阀值为37,最大丢弃阀值为40,丢弃可能性为十一分之一
R2#sh queueing interface s1/0
Interface Serial1/0 queueing strategy: random early detection (WRED)
    Random-detect not active on the dialer
    Exp-weight-constant: 9 (1/512)
    Mean queue depth: 0
 
   dscp          Random drop      Tail drop    Minimum Maximum  Mark
                  pkts/bytes       pkts/bytes    thresh  thresh  prob
   af42      0/0              0/0           28      40  1/10
   af43      0/0              0/0           37      40  1/11
   cs1      0/0              0/0           22      40  1/10
 
        我们再来讨论N值,你可以从上个验证命令看到默认为9.RED会参考前一个平均队列深度来判断是否发生了拥塞,而不是根据真实队列深度来判断是否发生了拥塞,这是因为真实队列深度变化的速度远远高于平均队列深度,而RED为了避免同步,会采用一个比较均衡的方式,计算公式如下:
New average = (Old_average * (1 – 2–n)) + (Current_Q_depth * 2–n)
拿9来举例:
New average = (Old_average * .998) + (Current_Q_depth * .002)
换句话说,只参考了现有队列深度的非常小的一部分,而参考现有的平均队列深度更多。该值9为默认也可以修改:
R2(config-if)#random-detect exponential-weighting-constant 5
R2#sh queueing interface s1/0
Interface Serial1/0 queueing strategy: random early detection (WRED)
    Random-detect not active on the dialer
    Exp-weight-constant: 5 (1/32)
    Mean queue depth: 0 
   dscp          Random drop      Tail drop    Minimum Maximum  Mark 

2、CB-WRED基于类的WRED

        接口下的WRED针对TCP的流量是生效的,但对于UDP等其他流量没有效果。为了将该技术用于其他的分类的时候就扩展到了CBWRED,即用MQC的方式来配置WRED
R2(config)#ip access-list extended UDP
R2(config-ext-nacl)#permit ip any any precedence 5
R2(config-ext-nacl)#permit udp any any eq ntp!
R2(config)#class-map match-any UDP
R2(config-cmap)#match access-group name UDP!
R2(config)#policy-map WRED
R2(config-pmap)#class UDP
R2(config-pmap-c)#bandwidth percent 10---不能和LLQ合用,可以和CBWFQ合用,而且RED不能单独使用
R2(config-pmap-c)#random-detect 
interface Serial1/0
service-policy output WRED---应用到出接口 
R2#sh policy-map  
  Policy Map WRED
    Class UDP
      Bandwidth 10 (%)
            exponential weight 9
            class    min-threshold    max-threshold    mark-probablity
            ----------------------------------------------------------
 
                                                  1/10
                                                   1/10
                                                  1/10
                                                  1/10
                                                  1/10
                                                  1/10
                                                  1/10
                                                  1/10
            rsvp                                     1/10
也可以根据某一个IP优先级设置丢弃阀值
R2(config-pmap-c)#random-detect precedence 5 1 2 1---这个设置的非常小 
在R3去做测试:
R3#ping   
Protocol [ip]:
Target IP address: 12.1.1.1
Repeat count [5]: 20
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]: 160---等于IP优先级5,请自行计算
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 13, 100-byte ICMP Echos to 12.1.1.1, timeout is 2 seconds:!!!!!!!!!!!!!
Success rate is 100 percent (13/13), round-trip min/avg/max = 8/22/60 ms 
R2#sh policy-map int
 Serial1/0 ---应用在了s1/0接口 
  Service-policy output: WRED 
    Class-map: UDP (match-any)
      20 packets, 2080 bytes
      5 minute offered rate 1000 bps, drop rate 0 bps
      Match: access-group name UDP---匹配的ACL为名为UDP的列表
        20 packets, 2080 bytes
        5 minute rate 1000 bps
      Queueing
        Output Queue: Conversation 265
        Bandwidth 10 (%)
        Bandwidth 154 (kbps)
        (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0---遗憾的是我们还是没能看到丢包
         exponential weight: 9
         mean queue depth: 0 
  class    Transmitted      Random drop      Tail drop    Minimum Maximum  Mark
           pkts/bytes       pkts/bytes       pkts/bytes    thresh  thresh  prob
           0/0               0/0              0/0           20      40  1/10
           0/0               0/0              0/0           22      40  1/10
           0/0               0/0              0/0           24      40  1/10
           0/0               0/0              0/0           26      40  1/10
           0/0               0/0              0/0           28      40  1/10
          20/2080            0/0              0/0                 1/1
           0/0               0/0              0/0           32      40  1/10
           0/0               0/0              0/0           34      40  1/10
   rsvp       0/0               0/0              0/0           36      40  1/10
如上验证已经有匹配 
        总结如下:WRED是一种拥塞避免机制;不可以和接口队列合用,只能支持FIFO;可以和CBWFQ结合使用(虽然书中给出了LLQ,但实验了多个IOS却不可以);可以给IP优先级或者DSCP设置不同的阀值和丢弃策略  
试验完成
欢迎大家继续关注Ender的文档以及更多视频

0

阅读 收藏 喜欢 打印举报/Report
  

新浪BLOG意见反馈留言板 欢迎批评指正

新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 产品答疑

新浪公司 版权所有