cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
746
Views
0
Helpful
7
Replies

Strange Voip QoS behaviour on 871 router

simon beliveau
Level 1
Level 1

Hi,

I just can't configure the strict priority queue on the cisto 871.

My phone ATA is connected to the router and interface 4 is connected though PPPoE to the internet via an ADSL modem.

The packets seem to match my class but there is no queuing.  Here's what it looks like:

Class-map: Voice-Calls (match-any)
      25387 packets, 3603194 bytes
      5 minute offered rate 7000 bps, drop rate 0 bps
      Match: ip dscp ef (46)
        25387 packets, 3603194 bytes
        5 minute rate 7000 bps
      Match: ip precedence 5
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing
        Strict Priority
        Output Queue: Conversation 264
        Bandwidth 200 (kbps) Burst 5000 (Bytes)
        (pkts matched/bytes matched) 0/0            '===========Why is this 0/0 and not 25387/3603194 ???
        (total drops/bytes drops) 0/0

My configuration is pretty simple and looks like this:

class-map match-any Voice-Calls
  description [---[ Actual Calls Simon ]---]
  match ip dscp ef
  no match ip precedence 5
class-map match-any Voice-Control
description [---[ Call control Simon]---]
match ip precedence 3
class-map match-any HTTP_Simon
description [---[Test HTTP]---]
match access-group 169
!
access-list 169 remark [---[web users priority over  rest]---]
access-list 169 permit tcp any any eq www
!
policy-map WAN-Link
  description [---[ Apply Treatment for Classes ]---]
  class Voice-Calls
   priority 200
  class Voice-Control
   bandwidth 30
  class HTTP_Simon
   bandwidth 300
  class class-default
   fair-queue
!
int fa 4
service-policy output WAN-Link
!

Any support would be greatly appreciated as I am really blocked on this one.

Thank you.

Simon

1 Accepted Solution

Accepted Solutions

paolo bevilacqua
Hall of Fame
Hall of Fame

There is no queuing because the FE interface is never congested.

You could configure nested classes, shaping to upload speed in the parent, however in practice that is rarely necessary.

Just refrain from doing much data transfer when using the phone.

View solution in original post

7 Replies 7

paolo bevilacqua
Hall of Fame
Hall of Fame

There is no queuing because the FE interface is never congested.

You could configure nested classes, shaping to upload speed in the parent, however in practice that is rarely necessary.

Just refrain from doing much data transfer when using the phone.

Thanks for the help.  I am a bit surprised of that since my examples were always showing the data being routed to the corresponding queue, but I`ll investigate that.  Nonetheless, when I make important uploads (torrents or speedtest.net), the egress phone signal is very very choppy.  There must be a simple way to fix this isn't it?

Only using nested classe ad indicated above.

Otherwise, get a 877 router and you can apply QoS directly as it directly controls the congestion point.

Please remember to rate useful posts clicking on the stars below.

markbatts
Level 1
Level 1

Remeber for QOS to work effectively you need to have it running on all devices between where you are and where you are calling.Your configuration looks correct and  the fact that the PQ isn't kicking in implies that your are not reaching congestion on the interface.Whats probably happening is that your router is quite happily sending data out of port 4 , the packets are then hitting the modem and the they are being lost there as it goes from 100MB down to whatever your speed connection is.To be honest i don't think you're going to be able to fix it.

cheers

mark

Mark,

As indicated above, it is "fixable". See:

http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfmcli2.html#wp1023458

Traffic Policy as a QoS Policy (Hierarchical Traffic Policies) Example

Hi,

I think you might be missing the point, i'm not saying you can't fix the queuing on the router thats easy.I'm saying that how do you manage the packets when they leave it.Even if the router correctly priortises the packets they're only going to get dropped at the next hop.

Its common misconception that configuring QOS on the ony one device is good enough, fixing the QOS on the router will only help to alleviate the issue not resolve it.

mark

Mark, please take more time to read other's.

that is exactly what I'm saying in my first post above, and the document referenced teaches you how to correct the problem, by configuring a hierarchical nested policy where traffic is shaped first to upload speed of the router downstream, then prioritized for for voice.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: