[cisco-bba] 7204VXR vs ASR1001-x (as LNS / provider is LAC)

[Bruce Technical]

Diagram below:

Wholesaler Fiber >.    our Radius   Server
                                              |                       |
                                       ASR-1001-x(A)    ASR-1001-x(B)

Best Regards,

On Mar 31, 2017 8:08 AM, "Bruce Nikzad" <bruce at rayantelecom.ca> wrote:

> Hi James,
>
> Thanks for the details. I appreciate any and all diagrams and guides as
> it's my first time ha fling this.
>
> Here is a big difference about what I am hearing here and maybe I have
> heard it wrong. Apparently our wholesaler provider wants their fiber to
> connect directly to our ASR-1000-x (we are not decided on equipment yet but
> they recommend to sell us ASR-1000-x) and then Radius gets quiried and
> gives ASR the OK to send back to wholesaler.
>
> ^^^ If above is true (which never made sense to me) then we can't have
> multiple Cisco routers that support LAC.
>
> The only other thing they said is that they can round robin this to our
> multiple ASRs. I guess directly to them than a Radius.
>
> Is it possible they are doing it differently than your structure?
>
> Best Regards,
>
>
> On Mar 31, 2017 4:44 AM, "James Bensley" <jwbensley at gmail.com> wrote:
>
> On 28 March 2017 at 19:55, Bruce Technical <brucetechnical at gmail.com>
> wrote:
> > P.S. why would you not recommend ASR vs ASR-X? (There is a huge price
> > difference on eBay).
> >
> > On Mar 28, 2017 12:07 PM, "Bruce Technical" <brucetechnical at gmail.com>
> > wrote:
> >>
> >> ***sending again with reply all and a minor change***
> >> Hi James,
> >>
> >> Not late at all. We are deciding this week to go with one ASR-x or
> >> multiple 7206vxr.
> >>
> >> 1- How would couple 7206vxr work together when our ISP is wanting to
> >> connect to LNS first and not Radius?
> >>
> >> 2- I am asked to pick single or multimode fiber. For 7206vxr which one
> >> should I pick and which is supported?
> >>
> >> 1000 customers is not bad for the price of a VXR.
> >>
> >> Best Regards,
>
>
>
> Hi Bruce,
>
> >> 1- How would couple 7206vxr work together when our ISP is wanting to
> >> connect to LNS first and not Radius?
>
> That's a bit odd. I would expect the normal procedure to be as follows
> (visual representation here:
> https://null.53bits.co.uk/index.php?page=adsl2-2-ppp-over-l2tp-life-cycle
> ),
> sorry if you know all this it’s not meant to be patronising:
>
> - CPE comes online and wholesaler LAC queries the CPE for authentication
> details
> - Wholesaler LAC sends access-request using the CPE provided
> authentication details to wholesaler RADIUS to check if these details
> are correct
> - Wholesaler RADIUS see's these detail belong to another ISP (you!) an
> will proxy the authentication request to your RADIUS (forwards your
> RADIUS the access-request
> - Your RADIUS authenticates the user and in the access-accept response
> to the wholesalers RADIUS send your tunnel-endpoint IP and password
> (your LNS IP and password)
> - When wholesaler RADIUS response sends this access-accept back to the
> LAC in response to the LACs access-request
> - The LAC builds the L2TP tunnel to your LNS
> ....
>
> From then on it’s all within your domain of responsibility.
>
> We have one wholesaler who's LACs speak to our RADIUS servers, so they
> are dual purpose devices, LAC and RADIUS Proxies. If the wholesaler
> wants their LAC/BRAS to talk to your LNS directly without any RADIUS
> involvement, how will you be able to dynamically return your LNS IP,
> unless they have fixed details: *@realm1.net > 1.2.3.4 (your LNS IP),
> *@realm2.net > 5.6.7.8 (another of your LNS IPs) etc.
>
> With multiple LNS as we heave, either the wholesaler RADIUS asks our
> RADIUS for the tunnel-endpoint IP and we return multiple IPs with the
> same preference and they round-robin across them (we can offset the
> preference in the RADIUS reply if we want to traffic steer certain
> sessions to certain LNS devices), or in the case of that “other”
> wholesaler, their LACs talk to our RADIUS then build the L2TP to our
> LNSs and again round-robin of the multiple IPs returned.
>
>
> >> 2- I am asked to pick single or multimode fiber. For 7206vxr which one
> >> should I pick and which is supported?
>
> Both are supported (you would purchase an MM or SM SFP/GBIC to go into
> the chassis line card, the transceiver “handles” the MM/SM port and
> the chassis is agnostic of it more or less). Multimode is usually
> cheaper although single mode will carry for a greater distance. You
> just need to weigh up what’s right for you there, nothing to
> complicated.
>
>
> >> 1000 customers is not bad for the price of a VXR.
>
> I’m in the UK, with the rise of FTTC that number will probably come
> down. CPU == throughput (more or less) on the 7200 series, slowly we
> are moving from 1000x 8Mbps ADLS to some hundreds of 40-80Mbps FTTC.
> 7200s are so cheap you can scale our horizontally easily, just deploy
> more LNS’s and return the additional IPs in your RADIUS response.
> However 10x 7200s is a lot more hassle than say 2x ASR1006-X. 7200s
> are so cheap though, have one if not two in the lab, probably some
> others lying around in storage we’ve forgotten about etc. It’s
> expensive to have an ASR 1000 series sitting in the lab for very
> occasional usage.
>
>
> > P.S. why would you not recommend ASR vs ASR-X? (There is a huge price
> > difference on eBay).
>
> The non-X versions either are EoS already or will be soon. The X
> versions are pretty much the defacto for the 1000 series devices. The
> H-X versions are out and they will eventually replace the X versions
> but that is still some years away. So for now if someone was going to
> put in a new deployment I’d recommend the X versions as the death
> knell has been rung for the non-X versions (bug fixes, TAC support,
> code upgrades etc). The X versions are more expensive as they are the
> next generation from the original non-X versions and much faster and
> more scalable.
>
>
> Cheers,
> James,
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-bba/attachments/20170331/18df91ef/attachment.html>