[afnog] Subscriber Management with BNG

[Andrew Alston]

Hi Vincent,

While I agree with some of the other things Mark has said about vendor engagement, I’ll also attempt to give you some basic things you can attempt that may put you on a helpful track, see inline responses.

We are in the process of installing Broadband network gateways(BNG) on ASR9k for subscriber management in the access network using PPPoE and IPoE.
We have a few concerns we would like some help with.


1.     How can we achieve Geo-redundancy without using proprietary cisco technology (nV cluster / Geo loacation) if possible.

You could attempt to terminate the dial-up point on a VRRP floating address, with the BNG’s linked via VPLS.  Dialing the floating IP should put them through to whichever BNG is primary and in theory would allow failover if that primary BNG died. (Note I haven’t actually tested this for IPoE dial-up, but it is something I’ve used extensively to give customers redundancy between two termination routers that function in affect like BNG’s, generally by allocating a /29 to the customer, BNG1 get’s IP1, BNG2 gets IP2, Float is IP3 and Customer is IP4 using the float as his GW.


2.     How can we have users dialing at any of the (2) locations and still get the same IP address.

If the two BNG’s have VPLS linkage between them, then yes, in theory its possible.


3.     We have the BNGs connected directly to the Core network, is it okay to have the /32s at the point of entry into the core(about 5k routes). with this it allows a customer to dial from any location and pick the same address.

I would strongly suggest if you’re doing 5000 routes into the core that you do it in BGP tagging the routes as no-export to ensure no route leakage.  You don’t really wanna carry that many routes in your IGP, its far better to keep the IGP small and put them in BGP.  If you do choose to put them in BGP, you won’t have any issues with 5k routes at all.


4.     If the third point is not best practice how can we summarize without introducing other devices.

Your other option is on your BNG’s to null route the aggregate and make sure its distributing in the IGP and then allow the local connected table on the BNG’s themselves to direct to the correct client – since the null route is simply an aggregate and more specific will win, this is another option.

A third option is a combination of my answer to question 3 and 4, where you announce an aggregate into BGP with no-export from the BNG and then let the local routing on the BNG’s take care of the rest.

5. Any other help is appreciated


Hope what I’ve said makes sense, let me know if you have any other questions and I’ll attempt to answer them (preferably on list so others can also potentially gain from the information).

Thanks

Andrew Alston
Group Head of IP Strategy
[cid:24DFDAAE-631D-4EDA-9C2E-8978E3AA9664]
Liquid Telecommunications Limited, 6 New Street Square, London EC4A 3BF
T: +27 76 219 7933 (ZA) T: +254 733 2222 04 (KE) E: andrew.alston at liquidtelecom.com<mailto:andrew.alston at liquidtelecom.com>
W: www.liquidtelecom.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.afnog.org/pipermail/afnog/attachments/20160119/4d4c84d1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 17933 bytes
Desc: image001.png
URL: <http://www.afnog.org/pipermail/afnog/attachments/20160119/4d4c84d1/attachment-0001.png>