QoS on C887VA: SIP, DSCP and LLQ

francois_vaning · ‎11-20-2014

Hello Cisco Support Community ;)

I have a question about LLQ QoS configuration specifically about DSCP usage.

I'm trying to enable QoS egress on an VDSL line.

My config looks like this:

class-map match-all Voice
match ip dscp ef
class-map match-any CallSignaling
match ip dscp cs3
match ip dscp af31

!

policy-map WAN-EDGE
class Voice
priority percent 33
class CallSignaling
bandwidth percent 5
class class-default
fair-queue

!

interface Dialer1
mtu 1492
bandwidth 22500
ip address negotiated
no ip redirects
no ip unreachables
ip nat outside
ip virtual-reassembly in
encapsulation ppp
load-interval 30
dialer pool 1
dialer-group 1
ppp authentication chap callin
ppp chap hostname woot
ppp chap password 0 woot
ppp direction callout
ppp pap sent-username woot password 0 woot
ppp ipcp header-compression ack
ppp ipcp dns request accept
ppp ipcp address accept
service-policy output WAN-EDGE

This config is nearly entirely based on a QoS design document edited by Cisco (http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/QoS-SRND-Book.html)

When analysing packets using packet capture on the router I can see packets with DSCP code af31 (HexTOS 0x68).

However, when issuing sh policy-map interface dialer 1 here is what I get:

R887-H#sh policy-map interface dialer 1
Dialer1

Service-policy output: WAN-EDGE

queue stats for all priority classes:
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0

Class-map: Voice (match-all)
715 packets, 68700 bytes
30 second offered rate 0000 bps, drop rate 0000 bps
Match: ip dscp ef (46)
Priority: 33% (7425 kbps), burst bytes 185600, b/w exceed drops: 0

Class-map: CallSignaling (match-any)
0 packets, 0 bytes
30 second offered rate 0000 bps, drop rate 0000 bps
Match: ip dscp cs3 (24)
0 packets, 0 bytes
30 second rate 0 bps
Match: ip dscp af31 (26)
0 packets, 0 bytes
30 second rate 0 bps
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
bandwidth 5% (1125 kbps)

Class-map: class-default (match-any)
137497 packets, 17237719 bytes
30 second offered rate 0000 bps, drop rate 0000 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops/flowdrops) 0/0/0/0
(pkts output/bytes output) 0/0
Fair-queue: per-flow queue limit 16 packets

For some reason it looks like the dscp code is not matched...

I don't understand why. Furthermore, i've also tried multiple configurations to match those packets:

- match protocol sip

- ACL created to matche this traffic.

- putting both af31 and cs3 as af31 seems to be the legacy.

- putting priority 100 for both classes (as a percent of 22000 kbps is still a huge number)

I don't know if it's related but voip works perfectly downstream (hearing the other people) but slightly bad on upstream (other people hearing what you're saying).

Any help would be welcome ;)

BTW, i'm using Version 15.2(4)M5 on C887VA

Thanks a lot!

Regards,

François Van Ingelgom

Joseph W. Doherty · ‎11-20-2014

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

At a glance, what you have looks correct, so I wonder whether you might be hitting a bug.

However, I also wonder whether NAT is causing the match statement to fail.

Since your traffic is actually using AF31, you might try matching only for that.

Or, you might try matching both CS3 and AF31 with the same match statement.

Or, you might try matching just for IPPrec 3 (if you don't have AF32 or AF33 traffic).

francois_vaning · ‎11-20-2014

Thanks for your answer!

I will investigate the potential NAT issue. From what i can see in my captures, packet might be natted but it still have the correct dscp flags on it.

I've tested with:

- match ip dscp af31

- match ip dscp af31 cs3

- match ip precedence 3

Still the same results... I also wonder if i might be hitting a bug on IOS. Unfortunately, I don't have a subscription on this device so .... I guess i'm stuck :(

Still it works for rtp which is probably the most important but i'm concerned about having unresponsive calls in case of congestion due to the inability to signal the end of the call...

Anyway, thanks a lot for your help!

Regards,

François

Joseph W. Doherty · ‎11-21-2014

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

If the FQ in class-default works as it should, your signalling traffic shouldn't be much at risk. In fact, IMO, just FQ alone deals effectively with about 90% of all QoS requirements. Adding a real-time class, deals with about 99% of all QoS requirements, and the following policy, deals with almost 100%.

policy-map sample

class real-time

priority percent 33

class hi-priority

bandwidth remaining percent 89

fair-queue

class lo-priority

bandwidth remaining percent 1

fair-queue

class class-default

bandwidth remaining percent 9

fair-queue

Usage of the above's non-LLQ classes should ideally be the inverse of the class percentages. The class percentages are set, in the above, not for bandwidth reservations, but for relative dequeuing priorities.

Also in the above, almost all non-LLQ traffic should be in the default class. Lo-priority is useful for known bandwidth hogs that are bandwidth adaptable (e.g. most TCP) and aren't timing sensitive. An example might be bulk file copies. Hi-priority is for flows that really, really need priority over others, but don't have a real-time requirement. A good example of such traffic might be "screen scraping", like Citrix or RDP. Or, possibly something like telnet.

The above, also can work really well if you can dynamically move flows between classes based on flow's bandwidth usage.

francois_vaning · ‎11-22-2014

Hello,

Thank you for providing me this sample, i've used it ;)

Now everything seems to be working aok, calls are not disturbed anymore.

For the record, I think i've found why I had uplink performance issue:

I use nbar for firewalling and I didn't tell it to inspect sip just tcp and udp.

I think that now that I have instructed it to inspect sip, the laggy output issues are gone. (hopefuly).

Anyway, thanks a lot for your help!

I'll try to update the IOS software if we have a subscription some days...

Regards,

François

Reuben Farrelly · ‎11-23-2014

I'll throw in the suggestion that what you are trying to do is technically not supported on the version of IOS you have installed.

You'll want to go to 15.3(3)M(latest) which is now MD, or 15.4(3)M(latest) for this to be officially supported:

Refer:

Shaping on Dialer Interfaces 15.3(1)T The Shaping on Dialer Interfaces feature provides support for PPPoE/A configurations on dialer interfaces.

From: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_conavd/configuration/15-mt/qos-conavd-15-mt-book/qos-conavd-dial.html#GUID-F0B9C4C2-6852-4CC3-B671-C61B77BC6A24

francois_vaning · ‎11-26-2014

Hello all!

As sugested, i've upgraded to 15.3(3)M4.

I now have QoS working for both rtp packet and sip packet.

However I had to configure very differently because this configuration didn't work in 15.3(3)M4.

It gave me the following error:

Flow Fair Queueing feature is not supported in default class of parent level policy of

As suggested in this thread: https://supportforums.cisco.com/discussion/12351281/applying-service-policy-output-dialer-interface-887va

I converted my configuration this way:

policy-map childpol
class Voice
priority 200
class CallSignaling
bandwidth 200
class class-default
fair-queue
policy-map parpol
class class-default
shape average 16800000
service-policy childpol

It seems to be working now, however I'm concerned the traffic might get first shaped then prioritized adding latency to the process because of the shaping first occuring.

I am wrong? If not, what could be a better configuration?

Thanks a lot for your help!

Regards,

François Van Ingelgom

Joseph W. Doherty · ‎11-26-2014

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

In theory, the shaper should use the child policy queues, but Cisco doesn't document exactly how things work, and from past experience, I suspected some Cisco version had both shaper and child policy queues.

I doubt the shaper would be an issue for any traffic except perhaps for the child's LLQ, so what you might do is:

policy-map childpol
class CallSignaling
bandwidth 200
class class-default
fair-queue
policy-map parpol

class Voice
priority 200
police average 200000
class class-default
shape average 16600000
service-policy childpol

francois_vaning · ‎11-26-2014

I'll try this config today!

I also suspect Cisco use two queues in this config because when I issue this command:

R887-H#sh policy-map int dial 1
Dialer1

Service-policy output: parpol

queue stats for all priority classes:
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 3/306

Class-map: class-default (match-any)
3251500 packets, 321841076 bytes
30 second offered rate 4000 bps, drop rate 0000 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/3/0
(pkts output/bytes output) 3251398/322104458
shape (average) cir 16800000, bc 67200, be 67200
target shape rate 16800000

Service-policy : childpol

queue stats for all priority classes:
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 14818/1423344

Class-map: Voice (match-all)
14818 packets, 1423344 bytes
30 second offered rate 0000 bps, drop rate 0000 bps
Match: ip dscp ef (46)
Priority: 200 kbps, burst bytes 5000, b/w exceed drops: 0

Class-map: VoiceSig (match-all)
10173 packets, 5305591 bytes
30 second offered rate 1000 bps, drop rate 0000 bps
Match: ip dscp af31 (26)
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 10172/5389661
bandwidth 100 kbps

Class-map: class-default (match-any)
3223078 packets, 313331851 bytes
30 second offered rate 3000 bps, drop rate 0000 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops/flowdrops) 0/3/0/3
(pkts output/bytes output) 3219876/312796275
Fair-queue: per-flow queue limit 16 packets

It looks like the traffic is first queued and shaped then prioritized.

Thanks a lot for your example!

I'll keep you posted of the result.