[c-nsp] LNS Alternatives

[James Bensley]

On 23 May 2016 at 10:03, CiscoNSP List <CiscoNSP_list at hotmail.com> wrote:
> Cheers James - We need them all(5), as our POPs are geographically VERY far apart lol......majority of our customers are eth based, and use DSL as either redundant link, or where eth/fibre not available.......unfortunately, they make a HUGE noise re latency(They are VERY latency conscious!)  when we tried a single LNS setup...i.e. All DSL tails terminating on the one LNS.....as an example, 2 sites, 1 kilometre apart, latency was over 120m/sec..if we had an LNS at that POP, latency would have been 30ish....hard pill to swallow, but when the noisy customers are spending lots of $ with you, it's best to keep them happy.

Hmm in that case, I would either shout loudly at Cisco to get a better
price, the ASR1001-X for say <1000 subscribers (assuming an even
distribution between PoPs) is rather pricey. Have you considered
Juniper too? You can do all the same stuff on MX's as far as I know,
we have MX480's running as LNS too. Just a thought.

> Regarding features and the "X" range...Ive played a bit now with our Lab 1006, and yes, definitely some "challenging"(insane!) differences between them and the 7200....geez the stupid no compression thing,  some reply attributes cause the ASR to use full VAI, which causes it to fail also, qos pre-classify under virt template also causes ASR to use full VAI(Again, causes it to fail).....damn, Cisco loved making the transition from 7200->ASR an easy one lol......Are there even more things I need to be aware of with the old 1001 vs the 1001-X series?(From your e-mail, sounds like there is?)

Yes the change in RADIUS attributes and using sub-interfaces et al. is
very annoying. We have managed to work around pretty much everything
however it was additional head ache caused by Cisco, the reasons for
which are (mostly) unknown to us.

They do work AS LNS/BNG, the ASR1000 series devices, I just cast
stress how much testing you must do first. We were having issues were
the couldn't make QoS changes without rebooting the box, so we needed
to get our configs exactly right and fully testd before any traffic
goes live.

Cheers,
James.