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

[Andre Beck]

Re Keith,

On Wed, Oct 25, 2006 at 12:06:21PM -0500, Keith Klevenski wrote:
> 
> After doing some more research I think I may be hitting CSCsb49202:
> 
> 6608 : Incorrect marking DSCP value to 0

Wuargh.
 
> If this is the problem this actually makes sense.

Perfect 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.

You could probably verify that it is this problem using interface
precedence accounting, but it might get a little hard to differentiate
the packets hitting prec 0 intentionally from those hitting it
unintentionally. But at least it allows you to get a summary on this
without actually beeing on location with a sniffer. Or use an ACL that
doesn't actually drops anything, but allows you to count RTP packets
with a non-EF DSCP.

> 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.

You can even cup it at the top using rate-limit (CAR). Already done this
to prevent starvation. If present, I'd also reserve the high queue for
network management traffic (IGP), but cup it at 5% or so of the line rate.

> 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.

You might also just add an RTP match on the ACL that classifies your
high queue traffic (the one currently only matching DSCP EF), but
remarking once is probably easier than touching a lot of routers, if
there are many. If you happen to have a 3550/60/3750 switch somewhere
in the path, maybe you can convince it to do this for you at practically
no cost (100/1000Base wirespeed).

If you'd be on ATM PVCs I'd had shouted "Fix your tx-ring!" (some ATM
PAs essentially have a hidden hardware queue that can zero out all
positive effects of a previous software CBWFQ/LLQ by beeing too large
and involving serialization delays way beyond 200ms), but given *that*
bug, you very likely found your issue.

-- 
                  The _S_anta _C_laus _O_peration
  or "how to turn a complete illusion into a neverending money source"

-> Andre Beck    +++ ABP-RIPE +++    IBH Prof. Dr. Horn GmbH, Dresden <-