[cisco-voip] Strict Priority Queuing over T1 for Voice

Fri Oct 27 23:33:06 EDT 2006

Another thing you could do as a workaround is to use 'match protocol rtp audio' on your class-map (match any) with dscp ef or some other combination you like.  I've had to use this in places to fix voice quality issues where QoS wasn't being set correctly throughout the network and no one had access to rest of network, etc or knew what was being done where.  

----- Original Message ----
From: Keith Klevenski <keith.klevenski at rig.net>
To: Jason Aarons (US) <jason.aarons at us.didata.com>; cisco-voip at puck.nether.net
Sent: Thursday, October 26, 2006 11:32:22 AM
Subject: Re: [cisco-voip] Strict Priority Queuing over T1 for Voice

<!--
 _filtered {font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
text-decoration:underline;}
span.EmailStyle17
	{
font-family:Arial;
color:windowtext;}
span.EmailStyle18
	{
font-family:Arial;
color:navy;}
span.EmailStyle19
	{
font-family:Arial;
color:navy;}
span.EmailStyle20
	{
font-family:Arial;
color:navy;}
span.EmailStyle21
	{
font-family:Arial;
color:navy;}
span.EmailStyle22
	{
font-family:Arial;
color:navy;}
 _filtered {
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{}
-->

It turns out the problem is indeed the
6608.  It intermittently marks RTP packets with DSCP 0.  This explains why I didn’t
see any drops on any interfaces because I falsely assumed the packets were
being marked with EF so if they were dropped I should see them dropped in the high
priority queue.  There were plenty of low priority queue drops, but I never
though the RTP stream would be part of those drops!  We did look at sniffer
traces before, but didn’t look at every single packet to see how it was
marked.  That is where we didn’t absolutely confirm that ALL packets were
being marked properly.

Oddly manually marking the packets on the
vlan interface where all the 6608 ports are doesn’t work either.  You can
see the matches in the show policy-map int command and it looks like they are
getting marked with DSCP 46, but upon looking at the sniffer traces after the problem
continued the DSCP was still marked 0 for some packets just as it was before.  

Going to open a TAC case to see what the
deal is with this bug.  It is first found in CatOS, but fixed in a CallManager
release.  That seems pretty strange to me and even stranger why a service
policy on the MSFC didn’t have any effect.  I’m certain it was
configured properly.  It is also odd that Cisco says there is no known
workaround for the problem.  Why can’t you just manually mark the
packets?  Well, apparently you can’t at least from the MSFC so I guess it’s
all related somehow.

Anyway, just an FYI for you all.  We ended
bandaiding the problem by putting all UDP traffic sourced from the 6608 ports
in the high priority queue on the outbound interface of the T1 (the 7200) at
the datacenter to the office until we get it resolved.  I will keep you
posted.  ;)

Keith

From:
cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Keith Klevenski

Sent: Wednesday, October 25, 2006
12:06 PM

To: Jason Aarons (US);
cisco-voip at puck.nether.net

Subject: Re: [cisco-voip] Strict
Priority Queuing over T1 for Voice

Thanks Jason.

After doing some more research I think I
may be hitting CSCsb49202:

6608 : Incorrect marking DSCP value to 0

It is first fixed in version 4.1(3)ES53
which is newer than SR3c which is what we’re running and is the latest
SR.

If this is the problem this actually makes
sense.  I’m not seeing any drops in the HIGH priority queue, but
plenty in the low queue when there is congestion on the T1.  All of the
RTP packets I saw were marked EF, but I didn’t see if every single packet
in sequence was marked with EF.  If some are being marked with DSCP 0 then
they would be dropped in the low priority queue which I see plenty of drops
there when there is congestion on the T1.  And the fact that if I am on an
internal call (over the T1) or out a different gateway I do not see any
problems.

PQ has been working fine for us and works
fine with links over satellite for oil rigs.  We only care about voice so
that’s why we use legacy PQ.  Easy and straightforward.

Instead of upgrading to the latest ES
we’re going to mark all RTP packets with DSCP EF manually to make sure
they are marked properly.  I will update the group with the results.

Thanks for all of the input!

Keith

From:
cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Jason Aarons (US)

Sent: Wednesday, October 25, 2006
11:54 AM

To: cisco-voip at puck.nether.net

Subject: Re: [cisco-voip] Strict
Priority Queuing over T1 for Voice

I would change the QoS match the Cisco SRND
recommendations. Plus Cisco can’t say your are not using their best
practices.

It seems to me you get more deatail in
show policy-map interface versus show queueing interface.

Aside from that look for show queueing
interface, show interface and drops. You indicate none are found, maybe verify
that with Ethereal/WireShark. The Smart Decode in Ethereal is pretty good.

From: Keith Klevenski
[mailto:keith.klevenski at rig.net] 

Sent: Wednesday, October 25, 2006
10:36 AM

To: Jason Aarons (US);
cisco-voip at puck.nether.net

Subject: RE: [cisco-voip] Strict
Priority Queuing over T1 for Voice

Just using plain old legacy priority
queuing:

priority-list 1 protocol ip high list 110

priority-list 1 protocol ip medium list
111

priority-list 1 protocol ip normal list
112

priority-list 1 default low

access-list 110 permit ip any any dscp ef

access-list 111 permit ip any any dscp
af31

access-list 111 permit ip any any dscp
af21

access-list 111 permit ip any any dscp
af22

access-list 111 permit ip any any dscp
af23

access-list 111 permit ip any any dscp cs3

access-list 112 permit ip any any dscp
af11

access-list 112 permit ip any any dscp
af12

access-list 112 permit ip any any dscp
af13

From: cisco-voip-bounces at puck.nether.net
[mailto:cisco-voip-bounces at puck.nether.net] On
Behalf Of Jason Aarons (US)

Sent: Wednesday, October 25, 2006
8:08 AM

To: cisco-voip at puck.nether.net

Subject: Re: [cisco-voip] Strict
Priority Queuing over T1 for Voice

Auto qos voip does a great job of
generating the policy-maps. What does your policy look like?.

What does your show policy-map interface
x/y/z show when the problem occurs?  Are LLQ matched packets being
discarded? Maybe the service-policy is not protecting the voice like you think.

From:
cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Keith Klevenski

Sent: Tuesday, October 24, 2006
5:43 PM

To: cisco-voip at puck.nether.net

Subject: [cisco-voip] Strict
Priority Queuing over T1 for Voice

Hi all,

I’ve been battling a problem that seemed to have
surfaced recently as we have added more users to the office.  We have an
office of about 35 users now with a point to point T1 (HDLC) between this
office and the datacenter where the CallManager’s (running 4.1.3) and
PSTN gateway (6608 blade) are.  Basically this:

PSTN

  |

6608/6509 (datacenter) (12.1(11b)E14 on msfc and 6.4(10) on
sup)

   | trunk

7200 (datacenter) 12.3(6a)

  |

T1

  |

2811 (remote office)  12.3(11)T7

  | trunk

3750 (remote office)

  |

Phones

We have strict priority queuing configured on the T1
interfaces (and the FastEthernet interfaces although I don’t think this
is necessary) with DSCP EF traffic in the high queue and signaling (AF31/21/22/23
and CS3) the medium queue and other traffic in the normal and low queues. 

The problem is when the T1 is saturated we start seeing high
jitter (1-2 seconds) and rxlost packets on the phones and voice quality of
course suffers.  The thing is I see NO dropped packets on any interface
from the PSTN to the switch port the phone is connected to other than the call
statistics on the phone.  This confuses me greatly unless the phone itself
is dropping them… it would seem that if the phone determines there are
missing packets (rxlost) they would show up on some interface somewhere but
they do not.  Sniffer traces at the phone show the missing packets. 
Sniffer traces at the trunk at the remote office show missing packets, but
traces on the trunk in the datacenter (from the 7200 to 6509) show all packets
accounted for.  Seems like the T1 is the issue.  There are 24 line
code violations on the T1 in the last 24 hours, but no slips.  The problem
only seems to occur when there is high traffic on the T1.  We also noticed
no other traffic is marked EF and the RTP stream is EF at the datacenter and at
the office so that isn’t being remarked or anything.  But there are
no input queue drops on the 2811 (which I wouldn’t expect since the RTP stream
should be CEF switched anyway).  If the input interface cannot handle the
amount of traffic and the traffic is all CEF switched where would you see input
drops?  There are a handful of buffer failures, but nothing that would
account for the number of complaints I’ve been getting lately.

I’ve connected my phone directly to the 2811 and
bypassed the 3750 with the same results.

I also noticed that the rxsize fluctuates between 10ms and 20ms also. 
Shouldn’t that always be 20ms?  I thought that was odd.

I guess my main question is when using strict priority
queuing shouldn’t the voice packets ALWAYS get sent first no matter
what??  I want to believe they are since there are NO drops in the high
priority queue outbound from the datacenter.  What is the best way to do
QoS for voice over a T1 when you only care about the voice?  Seems like
strict priority queuing is the best way to assure voice traffic is sent
first.  We don’t really care about starving out any other
traffic.  If packets are being dropped shouldn’t I see them
somewhere other than on the phone?

Any input on this problem is welcome!

Keith

Disclaimer:

This e-mail communication and any attachments may contain confidential and privileged information and is for use by the designated addressee(s) named above only.  If you are not the intended addressee, you are hereby notified that you have received this communication in error and that any use or reproduction of this email or its contents is strictly prohibited and may be unlawful.  If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you.

Disclaimer:

This e-mail communication and any attachments may contain confidential and privileged information and is for use by the designated addressee(s) named above only.  If you are not the intended addressee, you are hereby notified that you have received this communication in error and that any use or reproduction of this email or its contents is strictly prohibited and may be unlawful.  If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you.

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://puck.nether.net/pipermail/cisco-voip/attachments/20061027/aec29f4e/attachment-0001.html 