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

[Bruce Technical]

Hi Harald,

Thanks again for the input.

*"You basically have to ask your provider whether they can send traffic for
@relamA and @relamB to different LNS IP-addresses.*
*If they can, you could use @realmA customers to be terminated at some
cheapo-LNS-device - they only get internet-access - end of story." *<<< I
am grasping the idea of SP sending requests to us to multiple 7204vxr but
what do you mean by @realmA to be terminated to some cheapo LNS device and
only internet access? I thought if we have two realms like
*john at mytelecom-a.com
<http://mytelecom-a.com>* would need the same support as a user we sign up
like    *sally**@mytelecom-b.com <http://mytelecom-b.com>*

"And then you could use @realmB customers to be directed to some
cisco/juniper/.. box where you can then add VRF and other options." <<< I
thought VRF is needed regardless (on both realmA or realmB) to keep
customer public IPs on separate virtual routes so they can't sniff each
other packets etc...which means we have to do this regardless. Isn't that
so? is there another solution as well?

"if your vrf customers get IPs from local cisco ip-pools you might even be
able to get vrf2vrf-connectivity by using static routes" <<< We are getting
multiple /24 blocks from our IP Transit provider (which might also be our
same DSLAM service provider) and I thought we talked that those will be in
Radius server and passed on to SP to assign to customer. I am not clear on
this part at all yet.

" I'd suggest in anyway to get two boxes, just in case one breaks or better
have them both terminate your sessions and be redundant always" <<< We
definitely have the budget for two or three boxes of these. Is there any
way to create a HA redundancy using multiple boxes?

Cheers,




On Sat, Feb 11, 2017 at 8:20 PM, Harald Kapper <hk at kapper.net> wrote:

> Hi
> Actually a „7204vxr“ is just a chassis, the NPE-G2 is what makes things
> work this is basically the cpu + 3xGig-Ethernet + 100Meg-management-port.
> The G2 is the limiting factor, also there is no better NPE available for
> 72xx routers anyways.
>
> You can of course use a switch with a SFP module to terminate your fiber
> access and you very much so should.
>
> The support for multiple router would be needed from your
> broadband-service because:
> They decide which connection they send to your LNS or your multitple LNS
> boxes, at least they should support terminating at two different IPs on
> your end, but maybe they even support more than two l2tp-endpoints, but if
> they support only one IP then you have no way to move sessions from one
> 72xx to another. The more l2tp-endpoint-IPs they support the more LNS
> devices you can run on your end and scale by adding hardware.
>
> Ad) mikrotik - this is simply a box to terminate sessions and hand out
> IPs, vrf is not supported (you could do some hacks, but don't).
> Ubiquiti doesn't do plain l2tp-lns as you mentioned yourself, don't do it
> :).
>
> >> 4- I am not exactly sure what you mean here:
> "If you can get multiple endpoints for different realms from your
> broadband-service you might even consider to have one realm to terminate
> internet-traffic only using a cheap mikrotik and use another realm to
> terminate at one or more 72xx for vrf-use." Can you please explain? Our
> provider does allow us to have multiple realms but I am not sure if they
> send this to multiple devices or not. They will give us a 6 strand fiber
> but maybe they will use one strand to terminate AHHSPI.
>
> You basically have to ask your provider whether they can send traffic for
> @relamA and @relamB to different LNS IP-addresses.
> If they can, you could use @realmA customers to be terminated at some
> cheapo-LNS-device - they only get internet-access - end of story.
> And then you could use @realmB customers to be directed to some
> cisco/juniper/.. box where you can then add VRF and other options.
> If your broadband-provider sends @realmB sessions to more than one LNS
> IP-address, you might consider some sane cisco-to-cisco setup to keep the
> vrf users in sync, this can either be achieved by using ospf in each vrf
> between the ciscos or by using bgp-vpnv4 (if you're not fluent in mpls this
> might give you more headache than it's worth for starters), if your vrf
> customers get IPs from local cisco ip-pools you might even be able to get
> vrf2vrf-connectivity by using static routes, but I guess you get the point.
>
> Anyway, for a 100meg starter plan I'd suggest get some NPE-G1 or NPE-G2
> boxes (better G2) and if you're not cisco aware, do lots of reading, you
> can easily feature-overload one box, but if you do well you can scale up to
> several hundreds of users and deliver roughly 500 mbit/s per box without
> lots of worries. I'd suggest in anyway to get two boxes, just in case one
> breaks or better have them both terminate your sessions and be redundant
> always, this way if you have to reboot one box, only roughly 50% of your
> users get disconnected.
>
> If you have no budget, you could even get started using some C2851 boxes,
> but they will be easily maxed out at some 100+ Mbit/s traffic, but you can
> buy them for virtually no money.
>
> Regards
> hk
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-bba/attachments/20170212/b8e58fb3/attachment-0001.html>