Mailing List Archive

You probably need to shape to a circuit speed rather than a percentage. I
know I ran into some weird quirks with QoS on the ASR1001-X, where it
wouldn't do QoS at all if the circuit traversed over an LACP link. I believe
that part was finally fixed. The ASR looks like it hard enforces the session
over whatever transport it maps to, and can change for example if you have a
path failure and the path changes.

You can push down the QoS profile from RADIUS (on a per user basis), and tag
different users with different profiles (depending on what connection speed
they are supposed to have). Obviously not as ideal as having it use the
LAC's speed, but it should work.

GTG

> -----Original Message-----
> From: cisco-bba [mailto:cisco-bba-bounces@puck.nether.net] On Behalf Of
> James Bensley
> Sent: November 20, 2015 11:38 AM
> To: cisco-bba@puck.nether.net
> Subject: [cisco-bba] ASR1K LNS
>
> Hi All,
>
> I guess a while back many people moved their PPP subscribers over to
> ASR1Ks and ASR9Ks etc, probably mostly from 7200/7300/7600 series devices
> and similar.
>
> I'm finally looking at moving over users with QoS and I'm having several
> issues as it goes, but the very first one I want to tackle is just
applying a basic
> shaper. This shaper is shaping to 95% of 1G not 95% of the uer session :(
Even
> though the LNS nows the subscriber speed (i.e. the LAC is sending it over
in
> the L2TP call setup):
>
>
> policy-map CPE-DSL-QOS-PARENT-OUT
> class class-default
> shape average percent 95
> service-policy CPE-DSL-QOS-PE-OUT
>
> lns1-lhclon.core#show policy-map interface vi2.1
>
> Virtual-Access2.1
>
> SSS session identifier 1 -
>
> Service-policy output: PE-DSL-QOS-PARENT-OUT
>
> Class-map: class-default (match-any)
> 7 packets, 588 bytes
> 30 second offered rate 0000 bps, drop rate 0000 bps
> Match: any
> Queueing
> queue limit 665 packets
> (queue depth/total drops/no-buffer drops) 0/0/0
> (pkts output/bytes output) 0/0
> shape (average) cir 950000000, bc 9500000, be 9500000
> target shape rate 950000000
>
>
> Any one seen this, fixed it?
>
> The core-facing interfaces on this ASR1002-X (IOS-XE 03.13.04.S,
> 15.4(3)S4) are a 2x1G etherchannel.
>
> Cheers,
> James.
> _______________________________________________
> cisco-bba mailing list
> cisco-bba@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-bba

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

Thanks for the on and off list responses all.

For list archives;

The ASR 1000 series seems to have minimal support for QoS over ADSL. I
made several tests using an ASR1002-X and wrote up all the issue I had
an experiences over these two links:

http://null.53bits.co.uk/index.php?page=adsl-and-lns-shaping-llq

http://null.53bits.co.uk/index.php?page=asr-ios-xr-lns-config

However it seems that the ASR 1002-X specifically in the whole range
or ASR1000s has less support than all the others for subscriber QoS :(

I have engaged TAC but didn't really get anywhere. Even using the
"model f" QoS policy on Cisco's website didn't help. Every subscriber
is shaped to % of the LNS physical links the L2TP tunnels come over.
We did have port-channels and as Gary mentioned, these are not really
support on the ASR1000 series for much of anything, I wouldn't
recommend deploying port-channels at all with these boxes.

The only way to achieve nice QoS ADSL also as Gary mentioned is to
shape the circuit to a specific speed. As per one off list person
said, the only good way to do this is in RADIUS. Get RADIUS to pull
the sync speed out of the AAA accounting info and send back a shaper
to say 10% less that that speed.

The post by "suivethefirst" on this Cisco support forum page pretty
much heads the nail on the head:
https://supportforums.cisco.com/discussion/11699691/use-bandwidth-vai-qos-parent-policy



Cheers,
James.
_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

Anonymous off-list response I'm forwarding for the sake of list archives:

On 2 February 2016 at 23:53, Anon wrote:
> Probably too late to matter, but that's pretty much exactly what we do on
> 7200's now anyway for DSL tails, so nothing has changed. All of things
> you've pointed out are the same.
>
> * Thought using port-channel would be good for redundancy, nope, QoS issues,
> gone back to single physical link. Redundancy is via having multiple
> LNS/BRAS not trying to add some redundancy to each box. The 7200's won't do
> more than 1Gbps of throughput, so aggregating using port-channel for
> bandwidth isn't a limitation.

For the ASR1000s, what I have done is expanded our existing design for
the 7200s. On the 7200s we used multiple sub-interfaces and advertised
those sub-int IPs in RADIUS either back to on-net LACs or wholesale
providers LACs/BRASs. So provider one received gi0/0.1 in a RADIUS
response and provider 2 received gi0/0.2 in their RADIUS responses. So
that way we can graph per LNS how much traffic is passing through for
each wholesale provider or LAC/BRAS etc.

For the ASRs we have gi0/0/0.123 which RADIUS returns as an LNS IP to
a LAC/BRAS. Once that physical link starts to get fill we can turn up
gi0/0/1 and create gi0/0/1.123 and add that IP into RADIUS. So RADIUS
now advertises the IP of gi0/0/0.123 and gi0/0/1.123 as if they were
two separate LNS routers. If you have 10G ports, then you're laughing.

> * The actual interfaces are "virtual-access" and so they inherit bandwidth
> parameter from the parent link, so yes, qos % doesn't work
> * All of our qos policies use hard numbers, not percent, but this means
> having a separate qos policy for each sync speed.
> * We've done the same thing in terms of shaping, we have a bunch of policies
> (ie 1 - 20M in 1M intervals) and we check the sync speed and us the correct
> policy in radius for that link. We only do business stuff though, at lower
> volume, so we can do this without the issues of massive overhead on touching
> each service. It can cause issues though, if the sync on the line drops to
> below what the qos policy is set to (ie. set a 6M qos policy and sync drops
> to 5.7M)
...
> I like the option of returning the QoS value automagically from radius and
> will have to look at this at some point in the future. Does it round down to
> the nearest whole mbps interval or something ?

In the case of RADIUS, the LNS receives the sync rate from the LAC
inside the L2TP tunnel the PPP session is carried in. When the LNS
speaks to RADIUS it sends that up/down speed sync value and from here
there are few ways to approach this.

Firstly, we can have RADIUS take that value (say its 10,000Kbps) and
just knock %10 off and then send that back wrapped up in some actual
Cisco AVPairs that provide a QoS policy configuration on the fly, see
this example link:
http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r4-3/bng/configuration/guide/b_bng_cg43xasr9k/b_bng_cg43asr9k_chapter_0101.html#task_A652C6A7F3CA4B96AEBCDE16D68ACB2D

That's on the ASR9K, haven't tried it on the 1K though.

Secondly, RADIUS can receive the sync speed, knock of 10% and then
send back in a policer AV pair;

Cisco-AVPair = "lcp:interface-config=rate-limit input 9000000
conform-action transmit exceed-action"

Thirdly, RADIUS can receive the sync speed and you could say, knock
10% off then match it against a list of predetermined policies you
have configured on all LNS routers and send back that name of the
nearest policy in an AV pair: Cisco-avpair =
"ip:sub-qos-policy-out=9Mps-policy" (the example you already gave).

In all cases, depending on how you have your RADIUS and LNS's
configured you can use the RADIUS COA feature to then update the LNS
from time-to-time, if the sync speed changes, with a new policy.
However this depends on if your LNS is signalled the sync speed change
by your supplier, if you LNS signals that in an accounting packet to
your RADIUS, and if you RADIUS can process and return based on that,
and if you LNS can update an already established session.

Cheers,
James.
_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba