QOS常见问题分析和定位

QOS常见问题分析和定位

2. EF类丢包

(1)      问题描述

在有些情况下，用户反映语音质量不好。如果丢包，语音质量肯定会不好。可以通过命令查看EF是否丢包。

[h3c]display qos policy interface

Classifier: RTP

     Matched : 0/0 (Packets/Bytes)

     5 Min Rate: 0 bps                              //这里是流量统计

     Operator: AND

     Rule(s) : if-match rtp start-port 16384 end-port 32768

     Behavior: RTP

      Marking:

        Remark DSCP ef

        Remarked: 0 (Packets)

      Expedited Forwarding:

        Bandwidth 32 (Kbps), CBS 4500 (Bytes)

        Matched  : 0/0 (Packets/Bytes)

        Enqueued : 0/0 (Packets/Bytes)

           Discarded: 0/0 (Packets/Bytes)             //这里表示EF是否丢包

(2)      问题定位及解决过程

可能的原因有很多，最常见的原因如下：

l   如果丢包首先要查看一下流量统计5 Min Rate:0 bps，如果流量超过Bandwidth，说明可能给EF分配的带宽不够。

l   注意是否有其他不需要保护的报文匹配了EF。

对于是否有其他不需要保护的报文匹配了EF，可以通过以下方式查看发现：

l   不要发送受保护的流，例如被保护的流是电话语音，那么就不要打电话。

l   通过reset counter interface命令把统计清掉。

l   过一段时间用display qos policy interface查看是否有报文匹配EF，如果有，说明类匹配规则可能不太好，有其他报文匹配了EF。

(3)      CBS值太小，而EF流量有突发，这时可尝试把CBS值调大一些。

3. EF类或RTPQ延迟大

(1)      问题描述

延迟是指报文发送开始到结束，整个过程所需要的时间。通常在高速设备上都很低，小于10ms。这类问题通常需要使用测试仪器或测试软件才能发现，或者打电话感觉延迟比较大。

(2)      问题定位及解决过程

如果发生了这个问题，可能的原因如下：

l   CPU利用率过高，处理不及时；

l   qmtoken 1没有配置；

l   紧急报文太多，如果是这样应该属于异常，通过命令可以查看紧急报文数量。

例如：

<Mosaic-E>display interface GigabitEthernet

GigabitEthernet0/0/0 current state :UP

Line protocol current state :UP

Description : GigabitEthernet0/0/0 Interface

The Maximum Transmit Unit is 1500, Hold timer is 10(sec)

Internet protocol processing : disabled

IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 00e0-fc53-6d02

Media type is twisted pair, loopback not set, promiscuous mode not set

100Mb/s, Full-duplex,  link type is autonegotiation

Output flow-control is disabled, input flow-control is disabled

Output queue : (Urgent queuing : Size/Length/Discards)  0/50/0

Output queue : (Protocol queuing : Size/Length/Discards) 0/500/0

Output queue : (FIFO queuing : Size/Length/Discards)  0/75/0

Last clearing of counters: Never

    Last 300 seconds input rate 83.58 bytes/sec, 668 bits/sec, 0.67 packets/sec

    Last 300 seconds output rate 13.27 bytes/sec, 106 bits/sec, 0.03 packets/sec

    Input: 48729 packets, 5437823 bytes, 48729 buffers

           11354 broadcasts, 37374 multicasts, 0 pauses

           0 errors, 0 runts, 0 giants

           0 crc, 0 align errors, 0 overruns

           0 dribbles, 0 drops, 0 no buffers

    Output:2700 packets, 977400 bytes, 2700 buffers

           2700 broadcasts, 0 multicasts, 0 pauses

           0 errors, 0 underruns, 0 collisions

           0 deferred, 0 lost carriers                       

如果查看紧急队列时Size较大（通常不会大于2），或有Discards，表明发生了这种情况。

EF调度顺序在协议队列之后，如果协议报文较多也会导致EF延迟大或抖动大。

l   在有些应用中在CBQ队列下层还存在队列，如FR的PVC下还有物理接口的队列，这时延迟可能是由物理层队列造成的。

l   有时候延迟大不一定发生在我们的设备上，可能是网络上其它设备造成的，如果是这样的话我们是没有办法的。

4. EF类延抖动大

(1)      问题描述

抖动是指时延的平均值和最大值的差值。如果这个值比较大语音效果可能会不好。有些测试工具会发现这个问题，如使用smartflow测试延迟、抖动。

(2)      问题定位及解决过程

如果是流量固有的抖动是没有办法的。

如果我们的设备造成抖动大可能是CBS引起的，可以调整再测。通常是减小CBS值，但太小会造成丢令牌，导致带宽减小，所以应该通过实测适当选择。

在traffic behavior 视图下：

queue ef bandwidth xxxxxxx cbs xxxxxx    

或

queue ef bandwidth pct xxx cbs_ratio xx     

5. AF类带宽得不到保证

(1)      问题描述

测试时可能会发现AF类发生了丢包，或带宽小于配置的带宽。

(2)      问题定位及解决过程

一个可能的原因是没有配置qmtoken，通常这时AF保护的是TCP流。如果链路拥塞，当没有配置qmtoken时，由于底层队列过长的原因，那么报文发送延迟可能会比较大。由于TCP发送数据有自己的流控机制，当他发现延迟大时会认为自己发送流量太大，就会主动降低发送速度。而其实这时流量可能还没有达到给AF类指定的带宽。这时的现象就是AF流的流量小于AF指定的带宽，AF流的带宽被别人抢占了。其实这都是延时造成TCP流控不准了。

测试方法是FTP或NeTIQ等软件用TCP流测试。

常用的显示命令介绍

1. 清除端口的统计信息

reset counters interface [ interface_type | interface_type interface_num | interface_name ]

2. 查看接口应用qos的信息

display qos policy interface [ interface-type interface-number [ dlci dlci-number [ outbound ] | inbound | outbound ] ]