On 05/13/2014 05:54 PM, Tony wrote:
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 :)
Thank you for your response, this is very helpful.
In my environment I do have line sync information since it's my own
dslams. Its provided via PPPoE Intermediate Agent, or DHCP Option 82
depending on type of subscriber (currently Im 100% pppoe but thats going
to change).
Some ideas I had then would be to dynamically determine which class to
put any given customer into. We have freeradius and a script that can
execute for each authentication request and looks at the intermediate
agent info and could decide which QoS policy to apply based on the
customer actual data rates (which is an administratively configured
value, not to be confused with 'attainable rate', which is based on loop
length and quality). This would make things dynamic and likely
worthwhile. The only fly in the ointment would be the case where,
without retraining, the attainable rate drops by some significant margin
below the previously-established actual rate, which would make the QoS
ineffective. In that case however, it would be no worse than not having
qos and I would argue that there likely would need to be some sort of
service call anyways to restore service to normal anyways.
Mike-
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
