[c-nsp] How to QoS Voice on a Cisco LNS (How to attach aservice-policy to a Virtual-Interface?)

Wed Feb 16 20:41:33 EST 2005

Logical interfaces do not inherently support a state of congestion.
You need to apply a parent shaping policy that limits the output rate
and leads to a congested state on the virtual interface. LLQ/CBWFQ is
then applied as a child policy. So, you would have something like this:

 policy-map 256K-PARENT-OUT
  class class-default
   shape average 256000
  service-policy output_policer

Note that you will need a seperate parent shaper for each bandwidth
supported, and this can be applied on a per-user basiss via radius.

When selecting your shaping values, be sure to take into 
account the layer 2 overhead of the DSL provider, as you _must_
guarantee that the choke point is the virtual-interface. This may
mean reducing the shaper to around 85-90% of the actual DSL bandwidth, 
although this will depend on the architecture of the carrier network.

Finally, you should also consider applying a service policy to the
physical interface as well to ensure voice packets are prioritised
should the physical interface itself experience congestion.

regs

Cameron

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Alexander Lucke
Sent: Thursday, 17 February 2005 7:47 AM
To: cisco-nsp at puck.nether.net
Subject: AW: [c-nsp] How to QoS Voice on a Cisco LNS (How to attach
aservice-policy to a Virtual-Interface?)

Hi Arie,

CAR is an idea. The problem I have with queueing it that I tried to
configure my service-policy on a virtual-template, e.g.

class-map match-all DSCP_EF
  match  dscp ef
policy-map output_policer
  class DSCP_EF
   priority 100
  class class-default
   fair-queue
!
interface Virtual-Template2
 description #### incoming DSL sessions ####
 mtu 1456
 ip unnumbered Loopback7
 ip access-group CUSTOMER-IN in
 ip route-cache flow
 ip tcp adjust-mss 1416
 no logging event link-status
 load-interval 60
 no snmp trap link-status
 no peer default ip address
 ppp mtu adaptive
 ppp authentication chap pap callin
 service-policy input SET_DSCP
 service-policy output output_policer
!

When I set the "service-policy output output_policer", I get an error
message

"Class Based Weighted Fair Queueing will be applied only to the
Virtual-Access interfaces associated with an MLP bundle."

For every session that's up (i.e. every virtual-access interface). After
reading some documentation I think that prioritizing (by queueing) is
not possible with PPPoE but I still hope I'm wrong ;-)

So - if you don't do the above - what do you do with CAR? Do you simply
limit the class-default traffic to something like "total bandwidth less
voice bandwidth"? 

This should work with some customers here but with others I will have -
under heavy call load - more voice traffic than data and limiting the
class-default to less than 50% of the total bandwidth (even when no
calls are active) would not make them happy.

Regards,
Alexander Lucke

-- 
alexander lucke · managing director
DNS:NET internet service gmbh · ostseestrasse 111 · 10409 berlin
http://www.dns-net.de · phone +49-30-420278-22 · fax +49-30-420278-78

-----Ursprüngliche Nachricht-----
Von: Arie Vayner [mailto:ariev at netvision.net.il] 
Gesendet: Mittwoch, 16. Februar 2005 21:17
An: Alexander Lucke; cisco-nsp at puck.nether.net
Betreff: RE: [c-nsp] How to QoS Voice on a Cisco LNS (How to attach
aservice-policy to a Virtual-Interface?)

We are using 7300's for something similar.
We load a per user CAR policy for both upstream and downstream policing
from RADIUS and it works perfectly. We have been experimenting with a
policy-map per virtual access and it seems to work as well, as long as
you pre-define all the policies in the global config. I have never
tested a priority queue with such a config, but it's a cpu based
platform so it should support it...

Arie Vayner
CCIE#12198

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Alexander Lucke
Sent: Wednesday, February 16, 2005 5:06 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] How to QoS Voice on a Cisco LNS (How to attach
aservice-policy to a Virtual-Interface?)

Hi,

I have a problem with QoS and hope that someone else already solved such
a problem and can help me here.

What I need to do is prioritizing Voice traffic on SDSL lines. 

For the upstream part, this is no problem as the CPE (a small cisco
router) can do QoS on the ethernet interface. My problem is the
downstream part. My LNS (Cisco 7206VXR/300) gets the PPPoE-DSL sessions
via L2TP over a FastEthernet interface. I configured some vpdn-groups
and some virtual-templates and everything works fine with normal data
traffic. 

My problem is that - when reading some documentation (e.g.
http://www.cisco.com/warp/public/105/pppoe_qos_dsl.html) - it seems
impossible to do a "session based queueing/shaping/whatever". It seems
only to support marking.

Did anybody solve this issue? How is it possible to let an LNS
prioritize Voice traffic in the downstream direction?

And No, we do not have access to the DSLAMs or the DSL aggregation
network but let's assume that we don't have congestion (no overbooking
;-) here.

Viele Grüße
Alexander Lucke

--
alexander lucke · managing director
DNS:NET internet service gmbh · ostseestrasse 111 · 10409 berlin
http://www.dns-net.de · phone +49-30-420278-22 · fax +49-30-420278-78

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

******************************************************************************
 - NOTICE FROM DIMENSION DATA AUSTRALIA
This message is confidential, and may contain proprietary or legally privileged information.  If you have received this email in error, please notify the sender and delete it immediately.

Internet communications are not secure. You should scan this message and any attachments for viruses.  Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments.
******************************************************************************