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

Wed Oct 25 13:06:21 EDT 2006

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. 

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