[c-nsp] How to QoS Voice on a Cisco LNS (How to attach
aservice-policy to a Virtual-Interface?)
BALLA Attila
atis at eik.bme.hu
Wed Mar 2 05:07:00 EST 2005
Hi,
I tried it again in our testbed: NPE-G1 as LNS, c1751 as LAC, and two
831s as DSL CPE.
The CPEs are connected to a LAN switch, and the LAC is connected to this
LAN switch also.
The CPEs are coming with PPPoE and the LAC forwards the PPP frames
toward the LNS via L2TP. We put hierachical QoS on the Virtual-Template
(shaping and llq, voice in the priority queue), we set mtu 576 and mss 536
and bw 512 on virtual-template. These paremeters are cloned to the
Virtual-Access.
And this configuration was working _properly_:
c72.adsl#sh policy-map interface vi 289
Virtual-Access289
Service-policy output: link_shaping_512
Class-map: class-default (match-any)
292730 packets, 34361385 bytes
30 second offered rate 396000 bps, drop rate 0 bps
Match: any
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
400000/400000 2500 10000 10000 25 1250
Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 22 292708 34349657 44708 20992358 yes
Service-policy : rt_q
Class-map: rt (match-any)
19007 packets, 1290166 bytes
30 second offered rate 25000 bps, drop rate 0 bps
Match: ip precedence 5
19007 packets, 1290166 bytes
30 second rate 25000 bps
Match: mpls experimental topmost 5
0 packets, 0 bytes
30 second rate 0 bps
Queueing
Strict Priority
Output Queue: Conversation 40
Bandwidth 34 (kbps) Burst 1500 (Bytes)
(pkts matched/bytes matched) 9234/592704
(total drops/bytes drops) 0/0
Class-map: class-default (match-any)
273723 packets, 33071219 bytes
30 second offered rate 370000 bps, drop rate 0 bps
Match: any
Shaping and queueing was working and voice was good also.
Maybe it is unsupported feature because it is working up to some sessions,
but if we have a lot of sessions it doesn't work....
Anybody has any experiences?
BR,
Attila
On Mon, 28 Feb 2005, BALLA Attila wrote:
> Hi,
>
> I did the same hierarchical qos (llq within shaping) and it didn't work...
> ;-(
> For example I set 400kbps shaping, but the virtual-access had more than 500
> kpbs traffic, and the shaper wasn't active.
> I opened a TAC case, and I was told that qos on l2tp virtual-access isn't
> supported:
>
> CSCdz24549
> Externally found enhancement defect: New (N)
> QoS for L2TP required
> The QoS on L2TP virtual-access interfaces is not available today
>
> CSCdy41179
> Externally found enhancement defect: New (N)
> Feature request: per-user shaping and queueing
>
> It is really unbelievable... We use a 7200/NPE-G1 as LNS with 12.3(5a)B3.
>
> BR,
> Attila
>
> On Thu, 17 Feb 2005 Cameron.Dry at didata.com.au wrote:
>
>> 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.
>> ******************************************************************************
>>
>>
>> _______________________________________________
>> 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/
>
More information about the cisco-nsp
mailing list