[afnog] Subscriber Management with BNG

Wed Jan 20 10:07:48 UTC 2016

Hi Mark,

I will definitely be going with v6 as well.

Thanks

Vincent

----- Original Message -----
From: "Mark Elkins" <mje at posix.co.za>
To: "Vincent Mwamba" <vincent at africonnect.co.zm>
Cc: "Andrew Alston" <Andrew.Alston at liquidtelecom.com>, afnog at afnog.org
Sent: Wednesday, 20 January, 2016 11:44:56
Subject: Re: [afnog] Subscriber Management with BNG

Vincent,

with /29's - I'm assuming you'll be providing non-NAT-ed IPv4 addresses
- and allow the Customer to run NAT on their individual networks?

So, while you are planning and building this network, can I suggest that
you add IPv6 to it from day one.

A suitable allocation to an end user is anything between a /48 and
perhaps stretching to a /60 (nothing smaller).

If the customer is a Home a /56 could be considered suitable. If the
customer is anything bigger, that is, Business, School or place with 10
or more people, then use a /48. (This would be what I'd do - your
mileage may vary).

Even if you disable the IPv6 configuration to some home users (for what
ever reason), build a dual stacked network.

On Wed, 2016-01-20 at 09:38 +0200, Vincent Mwamba wrote:
> 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
> 
> 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
> 
> 
> W: www.liquidtelecom.com
> 
>  
> 
>  
> 
> 
> 
> 
> _______________________________________________
> afnog mailing list
> https://www.afnog.org/mailman/listinfo/afnog

-- 
Mark James ELKINS  -  Posix Systems - (South) Africa
mje at posix.co.za       Tel: +27.128070590  Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za