tom at snnap
Mar 18, 2008, 12:22 AM
Post #2 of 2
(2473 views)
Permalink
|
|
Re: Shaping/Policing PPPoE sessions on Cisco 10008
[In reply to]
|
|
You could use RADIUS attributes to apply a service policy to the
virtual-interface, or you could use RADIUS attributes to apply a
rate-limit command to the virtual-interface.
Using the service policy has the added benefit of being able to apply QoS
configurations on a user-by-user basis (e.g. business customers have a
different service level than residential customers), whereas a rate-limit
just simply caps the data transfer rate.
The ISP I work for applies rate-limits via RADIUS attributes (IIRC). We're
also using 10008s aswell as 7200VXRs with thousands (circa 8-10 per box)
of sessions terminated from our own DSLAM deployments, and also a 3rd
party wholesale DSL provider. This setup is working quite well.
Last time I looked the CPUs of the 10008s were coping quite well with
plenty of room to grow.
> A little history......currently, we are using UBR's to shape our current
> PPPoATM DSL subscribers. Depending on their VPI, the customers get
> applied to a VC-Class where the UBR speed is set. (256kb, 1.5mb, 5mb,
> etc.) We only shape/police the downstream while the DSLAM
> shapes/polices the upstream.
>
> Now for the future........we are in the process of implementing Calix
> DSLAMs that will be connected via Ethernet rings to Cisco 7609's. There
> we will hand off the traffic via Layer-2 vlans to our Cisco 10008 DSL
> Aggregator for PPPoE termination. We were trying to figure out the best
> way to shape/police the customers for their purchased bandwidth. Our
> Cisco Sales Engineer said that we can create service-policies on the
> 10008 and use a radius attribute to point those customers to those
> service policies. I'd like to know if this is the best option and how
> well it scales for 1000's of customers. We don't want to shoot
> ourselves in the foot by using a method that will start to tax the CPU
> on our router and cause degradation of service to others.
>
> It would be great to hear what other Service Providers are doing to
> shape/police their customers download and upload speeds.
>
> Regards,
> -Dave R.
>
> **DISCLAIMER
> This e-mail message and any files transmitted with it are intended for the
> use of the individual or entity to which they are addressed and may
> contain information that is privileged, proprietary and confidential. If
> you are not the intended recipient, you may not use, copy or disclose to
> anyone the message or any information contained in the message. If you
> have received this communication in error, please notify the sender and
> delete this e-mail message. The contents do not represent the opinion of
> D&E except to the extent that it relates to their official business.
> _______________________________________________
> cisco-nas mailing list
> cisco-nas [at] puck
> https://puck.nether.net/mailman/listinfo/cisco-nas
_______________________________________________
cisco-nas mailing list
cisco-nas [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nas
|
