WS-C6509-E, SUP2T, Microflow Policing drops not visible

[DominikKristof]

Hello all,

We had problems with voice quality recently. The issue was with local calls between analog and IP phone or between analog phones (each connected to different voice GW) while crackling was heard only on IP phone. It all pointed to QoS since it occurred only during peak hours but when I was checking "show interface ... " show policy-map FLOW-POLICING " or "show queueing interface ... " there were no drops or errors. This is the configuration we had:

interface Port-channel31
 switchport
 ...
 service-policy input FLOW-POLICING
!
interface TenGigabitEthernet2/2/13
 switchport
 ......
 platform qos queue-mode mode-dscp
 wrr-queue bandwidth 5 25 20 20 20 5 5
 wrr-queue queue-limit 5 25 10 10 10 5 5
 wrr-queue random-detect min-threshold 1 70 100 100 100
 wrr-queue random-detect min-threshold 2 70 100 100 100
 wrr-queue random-detect min-threshold 3 70 100 100 100
 wrr-queue random-detect min-threshold 4 70 100 100 100
 wrr-queue random-detect min-threshold 5 70 100 100 100
 wrr-queue random-detect min-threshold 6 70 100 100 100
 wrr-queue random-detect min-threshold 7 70 100 100 100
 wrr-queue random-detect max-threshold 1 100 100 100 100
 wrr-queue random-detect max-threshold 2 100 100 100 100
 wrr-queue random-detect 4
 wrr-queue random-detect 5
 wrr-queue random-detect 6
 wrr-queue random-detect 7
 wrr-queue dscp-map 1 1 8 9 10 11 12 13 14 15
 wrr-queue dscp-map 1 1 41 42 43 44 45 47
 wrr-queue dscp-map 2 1 0 1 2 3 4 5 6 7
 wrr-queue dscp-map 3 1 32 33 34 35 36 37 38 39
 wrr-queue dscp-map 4 1 16 17 18 19 20 21 22 23
 wrr-queue dscp-map 5 1 24 25 26 27 28 29 30 31
 wrr-queue dscp-map 6 1 48 49 50 51 52 53 54 55
 wrr-queue dscp-map 7 1 56 57 58 59 60 61 62 63
 channel-group 31 mode desirable
!
policy-map FLOW-POLICING
  class VOICE
     police flow mask src-only 200000 8000 conform-action transmit exceed-action drop
...
#show class VOICE
 Class Map match-all VOICE (id 47)
   Match ip  dscp ef (46)

After we changed exceed-action to "transmit" voice issue disappeared. Later on I realized that all calls coming from analog phones via same voice GW are detected as a single flow since flow mask src-only is used. As I understand this, micro-flow policy was dropping packets after more than 3 calls were coming from a single voice GW (each call takes 64kbps). My question is, why I couldn't see drops under "show interface" or "show queueing interface "? Voice packets are labeled with DSCP 46 and marking was confirmed via packet captures. We blamed voice vendor all the time because I did not see any drops related to voice on interfaces or policy-maps and now I look stupid.

Thanks for advice.

[acampbell]

Hi,

A g711 codec voice call through IP take more like 80+K not the 64k (This is its TDM value)
It all depends on whether you are using frame,ATM,ethernet etc

So your policy map seems a bit short on bandwidth to me

!
policy-map FLOW-POLICING
  class VOICE
     police flow mask src-only 200000 8000 conform-action transmit exceed-action drop

To allow 3 x G711 calls you need to up the CIR to

!
policy-map FLOW-POLICING
  class VOICE
     police flow mask src-only 250000 8000 conform-action transmit exceed-action drop

Regards
Alex

[DominikKristof]

Thanks Acampell,

Sorry I was wrong about 64kbps per call and you're right it's something above 80. Codec for internal calls is G711.

I was thinking about changing flow mask to full-flow and thus have each call from voice GW identified as separate flow. It will bit more aggressive on netflow memory but that switch should handle it.

My main point is how to check those drops. We have more boxes and similar setup elsewhere and wonder how are other sites affected. TAC engineer only stated that we can’t see drops under “show policy-map” since we’re not using ACL but class map only. We still wonder why we couldn’t see it under “show interface “. Video traffic is being dropped by the same policy and we can see input drops under interface level for that.