Mailing List Archive

Shaping/Policing PPPoE sessions on Cisco 10008
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.
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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nas


_______________________________________________
cisco-nas mailing list
cisco-nas@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nas