Hi Mike,
In a nutshell:
* create qos policies on your aggregation router (7200/ASR). These should
be a standard parent/child policy with the parent to shape the traffic and
then whatever queueing you want in the child.
* add entries in radius to apply qos policy to subscriber
virtual-interface when they connect
An example of the radius attribute returned:
Cisco-AVPair = "ip:sub-qos-policy-out=qos-dsl-8m"
which would reference the QoS policy defined on the router of "policy-map
qos-dsl-8m".
The big problem you will have is knowing what speed to shape each
individual DSL session to (ie. the downstream sync speed). There are some
ways that this can be presented to you from the DSL carrier, but it's
probably best to assume that you won't get this information (although
lucky for you if it is presented to you). For QoS to be of ANY benefit you
need to shape the traffic to LESS than the sync speed. This leaves you
with a couple of options to achieve this outcome:
1. shape all to a uniform speed that you know will be achieved by all
connections
2. shape to some speed you determine to be reasonable (but likely less)
that the sync based on distance calculations
3. wait until service is up and check sync speed and apply the nearest
speed shaper
We only do QoS for DSL services in limited numbers and so we use the third
option. It would be manually intensive for any large number of services
but is manageable for us. We also provide managed CPE (Cisco 800's) and so
are able to determine the sync speed easily (and monitor it via SNMP
should we choose to).
The problem is always shaping to something that is BELOW the sync speed so
that your QoS functions, but not TOO much below so that you are robbing
the users of performance. An extreme example would be that you could shape
all sessions to 1mbps, but then if someone achieved a sync speed of
20mbps, you'd be wasting the extra 19mbps that might be available to that
user.
Without looking I think we have QoS policies for DSL of something like
512k, 1500k, 2m, 4m, 6m, 8m, 10m, 16m, 20m. There might be a couple more
between 10 & 20m, but you get the idea. Make sure you allow for your
overhead as well, sync speed != QoS shaper (PPPoE/PPPoA, etc).
There is also the issue that sync speeds do change over time (usually
downwards, rarely increasing), so we often choose to be conservative in
case the speed of the service drops.
Good luck :)
regards,
Tony.
On Wed, 14 May 2014 07:30:14 +1000, Mike
<[email protected]> wrote:
Hi,
Does anyone have code snippets or pointers to implemeting QoS solutions
for broadband (eg: dsl) subscribers? The cisco docs are difficult to
read and real-world examples would be more helpful here.
Thanks.
Mike-
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
