队列深度小导致突发时丢包的问题

发布时间:  2014-07-10 浏览次数:  154 下载次数:  1
问题描述
【Problem Summary】display port-queue statistics interface Gigabitethernet1/0/0 af2
【Problem Details】

客户发现AF2业务流有丢包,通过port-queue统计,看到af2有少量丢包,但是流量速率并没有达到af2限制的带宽,信息如下:

<AR-PE1>

display port-queue statistics interface Gigabitethernet11/1/1 af2 out

 [af2]

 Current usage percentage of queue: 0

  Total pass:

                         133,146,652 packets,            119,468,624,234 bytes

  Total discard:

                                  11 packets,                     17,485 bytes

    Drop tail discard:

                                  11 packets,                     17,485 bytes

    Wred discard:

                                   0 packets,                          0 bytes

  Last 30 seconds pass rate:

                               1,644 pps,                     13,962,024 bps

  Last 30 seconds discard rate:

                                   0 pps,                              0 bps

    Drop tail discard rate:

                                   0 pps,                              0 bps

    Wred discard rate:

                                   0 pps,                              0 bps

  Peak rate:

                          2014-06-27 01:52:50                108,037,656 bps

从统计信息上看,业务的高峰时,只有100M多,而该接口是10GE口,af2应该有2G的带宽,但是有少量丢包,需要分析丢包原因及解决丢包问题。
处理过程

队列丢包类的问题,一般情况是队列出现了突发,导致某一时间队列满,从而出现了丢包。

该问题进行分析,首先获取单板的信息,确认单板接口大小和af2的理论带宽:

1、 单板信息

LPU 11 : uptime is 620 days, 12 hours, 13 minutes

         StartupTime   2012/10/18   01:45:46

  Host    processor :

  SDRAM Memory Size: 1024M  bytes

  Flash Memory Size:   32M  bytes

  LPU version information

  PCB         Version : CR52LPUN REV B

 

  PIC0:CR5M00L2XX20 version information

  PCB         Version : CR52L2XXN REV A

  FPGA        Version : 203

  PIC1:CR5M00L2XX20 version information

  PCB         Version : CR52L2XXN REV A

  FPGA        Version : 203

 

Pic-status information in Chassis 1:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

SLOT PIC Status     Type                   Port_count Init_result   Logic down 

11   0   Registered LAN_WAN_2X10G_N_CARD   2          SUCCESS       SUCCESS    

11   1   Registered LAN_WAN_2X10G_N_CARD   2          SUCCESS       SUCCESS    

接口是10GE接口的。

 

2、 接口的配置

#

interface GigabitEthernet11/1/1

 description "Connect to C300_ARML5_CS_001"

 undo shutdown

 eth-trunk 55

 port-queue be wfq weight 20 outbound

 port-queue af1 wfq weight 5 outbound

 port-queue af2 wfq weight 20 shaping shaping-percentage 20 port-wred car outbound

 port-queue af3 wfq weight 20 outbound

 port-queue ef pq shaping shaping-percentage 10 port-wred car outbound

 port-queue cs6 pq shaping shaping-percentage 2 port-wred car outbound

 port-queue cs7 pq shaping shaping-percentage 2 port-wred car outbound

#

从接口配置分析,af2配置了shaping接口带宽的20%,也就是2G,另外配置了port-wred。再查看port-wred的信息:

#

port-wred car

 queue-depth 8

#

 

分析上述的配置,af2配置了shaping2G,但是port-wred配置的队列深度比较小,queue-depth的单位是kbyte

队列深度是8kbyte时,理论推算可承受的突发:8kbyte/2Gbits=0.000035s,从这个时间看,实际适应缓存能力是非常弱的。而网络中的突发是时时都可能存在时,这么小的缓存可能导致丢包。因此怀疑该问题是存在突发,且队列深度配置太小导致了丢包。

现网通过调整丢列深度,目前丢包不再发生。

 

有关突发举个例子:比如50个业务链接,每个业务在5ms内,发了501000byte长度的报文,计算这些业务的速率:50*50*1000byte/5ms = 4Gbits,也就是计算下来这个突发可能达到4Gbit每秒。

根因

队列深度配置太小,突发适应能力比较弱,有流量突发时可能出现丢包。

解决方案
【Resolution Summary】
【Resolution Details】

调整队列的深度。

#

port-wred car

 queue-depth xxx    ---调整该值;

#

建议按照容许的缓存时间推算出一个值。比如200Mbit速率,按20ms缓存时间:200Mbit*20ms=512kbyte

建议与总结

网络中的突发是时时存在的,一般的突发都可通过适当的调整队列的缓存来缓解或解决,对于突发比较严重的,可能只调整缓存的方式不能得到根本的解决,这时就需要能分析出突发源,尽量从源头做优化了。

END