[cisco-bba] ASR1K LNS

[James Bensley]

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.