Prioritizing Voice over Data in MLPPP

Unanswered Question
Aug 27th, 2009
User Badges:

have now connected two of our branchs using a bundle of two T1s configured in MLPPP mode. I have data and voice going across and in normal circumstances everything works just fine but when there is a heavy traffic ( like when the backup is running and pulling data across) the voice part start struggling and employees complain about a goggling in the voice. I have come to the conclusion that there must be something wrong with my configuration for prioritizing the voice packets over data. I really appreciate if anyone could give a look at the attached configuration and comment on current configuration or suggest a different solution.

Thank you,

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.5 (2 ratings)
Giuseppe Larosa Thu, 08/27/2009 - 07:53
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Sessie,

here you can find a document about QoS for VoIP over PPP links

as a comment: you are using old priority queue.

However if there is any application using marked packets (not cs0 but any type of csx or AFxy) it will go to high priority queue and will compete with the small ip packets.

In addition to considering modern QoS LLQ and CBFWQ you should put on the high queue (or LLQ in the newer modular QoS) only the ip packets of RTP streams that are udp packets using ports 16384 - 32xxx

only these should be in high queue

Hope to help


Mohamed Sobair Thu, 08/27/2009 - 08:47
User Badges:
  • Gold, 750 points or more


You have priority Queuing but this has impact that packets matches the default Class wont be serviced and result in queue starvation.

2nd point, why dont you consider LLQ , with LLQ you gurantee bandwidth and delay for the priority queue without starving other Classes in CBWFQ.

So the question here is:

1- Does your Voice traffic marked in the first place as you are matching it in the priority-list?

2- I would implement LLQ with MQC standard and config your RTP packet UDP ports 16384 32767 and TCP port 1720 on the priority Queue while leaving your DATA traffic to be served from CBWFQ.



eweber1234 Thu, 08/27/2009 - 10:30
User Badges:


Thanks for your comments, I guess I have a lot to learn now since I don't know much about LLQ and MQC standards. Any ways, thankd for sending me to the right direction. Regarding your question, that if our Voice data is marked, how would I find that out? Should I use a sniffer?

We use Toshiba CTX sytems here.

Thanks and Happy Ramadan,

Giuseppe Larosa Thu, 08/27/2009 - 11:30
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Sessie,

here it is the link I meant

As I wrote in my first post there is a risk that other traffic types are placed in the high queue with your current configuration.

if this happens quality of voice is reduced by the high jitter (delay variation) that is experienced by the fact that big data packets and voice packets are intermixed on the high queue.

Hope to help


eweber1234 Thu, 08/27/2009 - 12:50
User Badges:

Thank you very much for being so diligent and following up, I will go through the document and hopely figure it out. It is a new area for me and I have a lot to catch up.

Best to you and have a nice day/night

Mohamed Sobair Thu, 08/27/2009 - 11:34
User Badges:
  • Gold, 750 points or more

Hi Sessie,

To be honest, I havent done it my self, I think you could by Sniffer, but you shouldnt rely on sniffer for your end to end QoS.

The packet has to be marked in the Ip header at the ingress and you apply the QoS policy at the egress.

Your previous example shows you have priority queuing with prority-list matching DSCP and CSx. The question still remains , where are the classified and marked packet in your config?

I am not too sure that Only sniffer could show you what type of packet are classified and the marking used, but it should be in your config OR else, The Priority-list it self could have classification and marking within the Access-list used by the Priority.

I mean the Access-list it self used by the priority-list could include both Classification (Traffic classification) and Marking.



Joseph W. Doherty Thu, 08/27/2009 - 13:06
User Badges:
  • Super Bronze, 10000 points or more

There are several issues with your configs.

First, we don't know what your traffic is using for markings. Offen modern VoIP will use a DSCP EF marking, but you're not matching for that.

Second, you're matching against DSCP code selector markings, but there are many more DSCP markings. (NB: However, if you used IP Prec matching, you would match DSCP groups.)

Third, you have CS6 and CS7 higher than CS5, but with VoIP, you often give it the highest priority.

Fourth, PQ provides absolute priorities, so any higher queue can starve lower queues from obtaining any bandwidth (also mentioned in other posts).

Fifth, it's possible you might need to tune tx-ring-limit.

As the other posters have also mentioned, CBWFQ is a newer approach. So, something like:

(NB: syntax might be incorrect)

class-map match-all realtime

match ip precedence 5

policy-map sample

class realtime

priority percent 30

class class-default


interface Multilink1

service-policy output sample

Might be used (or an enhanced version of this sample config).


This Discussion