08-27-2009 07:36 AM - edited 03-04-2019 05:52 AM
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,
08-27-2009 07:53 AM
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
Giuseppe
08-27-2009 08:47 AM
Hi,
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.
HTH
Mohamed
08-27-2009 10:30 AM
Mohamed,
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,
08-27-2009 11:30 AM
Hello Sessie,
here it is the link I meant
http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080094660.shtml
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
Giuseppe
08-27-2009 12:50 PM
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
08-27-2009 11:34 AM
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.
HTH
Mohamed
08-27-2009 01:06 PM
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
fair-queue
interface Multilink1
service-policy output sample
Might be used (or an enhanced version of this sample config).
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: