[afnog] Subscriber Management with BNG

Wed Jan 20 08:27:35 UTC 2016

Thank you Andrew :) 

From: "Andrew Alston" <Andrew.Alston at liquidtelecom.com> 
To: "Vincent Mwamba" <vincent at africonnect.co.zm>, afnog at afnog.org 
Sent: Wednesday, 20 January, 2016 10:01:12 
Subject: RE: Subscriber Management with BNG 

Hi Vincent, 

Depends on the segment of the network. 

We use a system called 6connect Provision as an IPAM system, and this supports a full API and smart assignments and various other really nifty features (including really detailed v6 support and support for handling both forward and reverse DNS). 

Our provisioning systems in many cases talk via API calls to this system to allocate space and do reverse DNS and this is done for both where we are doing v4 and v6. 

As a note, while running the risk of getting shot for product endorsement, I can honestly say that having tested almost every IPAM system on the market, * NOTHING * has been able to touch 6connect Provision, and once AfriNIC has their REST API’s in place, it will even allow you to SWIP space directly to the RIR whois database to keep records up to date. Yes, its pricey, but worth every cent! 

Anyone who wants more details can contact me (please note: I do not have any direct affiliation with 6connect so I say these things purely because it really is an excellent product) 

Thanks 

Andrew 

From: Vincent Mwamba [mailto:vincent at africonnect.co.zm] 
Sent: 20 January 2016 10:39 
To: Andrew Alston <Andrew.Alston at liquidtelecom.com>; afnog at afnog.org 
Cc: Vincent Mwamba <vincent at africonnect.co.zm> 
Subject: Re: Subscriber Management with BNG 

Hi Andrew, 

Thank you for the pointers, 

On the /29 allocations do you do it manually or automated, if automated what are you using? 

Thanks 

Vincent 

From: "Andrew Alston" < Andrew.Alston at liquidtelecom.com > 
To: "Vincent Mwamba" < vincent at africonnect.co.zm >, afnog at afnog.org 
Sent: Wednesday, 20 January, 2016 00:45:34 
Subject: RE: Subscriber Management with BNG 

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 

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 

W: www.liquidtelecom.com 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.afnog.org/pipermail/afnog/attachments/20160120/97db7011/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/20160120/97db7011/attachment-0001.png>