[j-nsp] DHCP server recommendation for subscribers management

[Nathan Ward]

> On 10/08/2021, at 10:40 PM, Bjørn Mork via juniper-nsp <juniper-nsp at puck.nether.net> wrote:
> 
>>> In any case, you can do that with a sufficiently smart RADIUS server
>>> too.  You don't have to let JUNOS manage the address pools even if
>>> it is
>>> providing the DHCP frontend.
>> 
>> I understand that it could be an option, but for vlan-per-customer
>> model radius authentication isn't really needed for DHCP clients. Auth
>> is done for a parent VLAN-demux interface, so for DHCP sessions BNG
>> will send only accounting. In this case it will require to develop
>> "smart-enough" radius backend. If there is any solution already
>> available I'd definitely look at it, but I'd try to avoid building a
>> homebrew solution.
> 
> I don't know where to draw the line between config and programming, but
> RADIUS pool management exists as a feature:
> https://networkradius.com/doc/3.0.10/raddb/mods-available/ippool.html

Yep - for most use cases this works pretty well “out of the box”. You should also consider sqlippool, which has had a lot more work recently, particularly with postgres as a DB. I have contributed some of those changes, and as a “reference” case, for one customer I run reasonable size (low 6 figures) pools in sqlippool with 15 min accounting updates and no scaling problems in sight.
The ippool module is quite old, and slow, and doesn’t support any failover if you have multiple RADIUS servers. I don’t think it’s seen love in a number of years.
PS - Make sure you run a recent FreeRADIUS - 3.0.10 is pretty old these days.

It only gets complicated and in to “home-brew” territory if you’re wanting to do complex policy. If you’re fine with a single “pool” (which might be a single pool with addresses from many subnets) then you’ll be fine.

If you want different users on different pools, a very easy solution is to pull a pool name for that user from wherever your RADIUS users are stored (i.e. DB or whatever), which is then used the sqlippool to look up an address to assign. You have to do a little extra config in FreeRADIUS to handle that, but I think that stuff might even be in the documentation as examples - it should be very easy.

You can get really fancy with FreeRADIUS config - but for basic use cases you don’t need to.


In my view, learning and operating a whole new system (DHCP server) is harder than adding a bit of extra functionality to something you already have - RADIUS.

>>> IMHO, having the DHCP frontend on the edge makes life so much easier.
>>> Building a sufficiently redundant and robust centralized DHCP
>>> service is
>>> hard.  And the edge router still has to do most of the same work
>>> anyway,
>>> relaying broadcasts and injecting access routes.  The centralized DHCP
>>> server just adds an unneccessary single point of failure.
>> 
>> I agree that it's a complication, but imo it's a reasonable tradeoff
>> for effective IP space usage. For relatively big IP pools it would be 
>> sufficient saving. From KEA DHCP server documentation I see that
>> different scenarios for HA are supported, so some redundancy can be 
>> achieved.
> 
> IMHO, DHCP server failover has traditionally created more problems than
> it solved.  But I have no experience with KEA, so let's hope it's just
> working now.

Centralised DHCP has three problems, in my view (and experience):
1) More resources. It has to process DHCP messages roughly every lease half-life, x 2 or 3 if you are doing IPv6 IA_NA and IA_PD. RADIUS only processes auth, then one update per session. In a broadband environment you might want to have low DHCP timers so your customers re-connect if your BNG loses state for some reason (interface down, reboot, etc.), which translates in to a lot of messages. RADIUS-backed dhcp-local-server doesn’t mean more processing, at least not noticeably so - the BNG is processing the DHCP regardless of whether it’s relayed, or processed with RADIUS.
2) Fragile. Even with HA, your DHCP server *must* be available to keep customers online. After a DHCP server outage of sufficient length, if your network is of sufficient scale, you may find that the customers send retransmissions of messages as your BNG and DHCP server try to get everyone online - and that only pushes the DHCP server harder, causing more retransmissions. You’ll hit control plane policers on your BNG, and it will be a prolonged outage that comes in waves. With RADIUS based IP assignment, the BNG handles RADIUS retransmissions (and failover to other RADIUS servers), and blocks any CPEs sending lots of requests - either after an outage, or because there’s some bug where it spams you with DHCP requests for some reason.
3) Static IPs. Static IPs in DHCP means your option82 (or similar) must be correct - as that’s all the DHCP server sees. If you are using RADIUS, you can use any parameter available to RADIUS in order to identify the customer and hand out a static address. To the BNG, a static address for a RADIUS backed DHCP subscriber looks just like a dynamic one, no special BNG config required (same as DHCP relay).

It is good that you are considering KEA, which *somewhat* reduces these concerns. ISC dhcpd restarting with a large number of addresses in a pool, leases, etc. can sometimes take a long time - at which point you start dropping customers offline as their leases expire, and the DHCP request storm starts.

Obviously though, my strong recommendation is to use RADIUS for this, despite KEA being a little better than ISC dhcpd (where is where my war stories are from).

>> Another question that puzzles me is how to use multiple discontinuous
>> pools with DHCP server. With Junos internal DHCP I can link DHCP pools 
>> in the same way as for PPPoE and just assign additional GW IP to
>> lo0. With that Junos takes care of finding available IP in pools and
>> use proper GW address. In case of external DHCP server, router has to
>> insert relay option but how can it choose what subnet to use in this
>> case if there are more than one available? This problem should be also
>> actual for big cable segments, although for cable interface IP
>> addresses are directly configured on the interface, but for Junos BNG
>> a customer-facing interface is unnumbered.
> 
> The subnet choice is always up to the DHCP server.  You create a shared
> network with all the subnets and ranges that are supposed to share
> pools.  This is similar to the linked pool in JUNOS. The server will
> select a free address in this shared network if the giaddr matches one
> of the configured subnets.  Note that there doesn't have to be mathing
> range if you don't want to share giaddr and client subnets.

Just to pull this out and make it obvious, the key words here are “shared network”, which is a term used in the ISC dhcpd config to signal that subnets configured in that shared network are to be treated as one big pool.

> All routers sharing a pool must have all the same GW addresses
> configured on lo0.

I don’t know if this is completely true, I *think* you can tell the DHCP relay to replace the gateway address, but it certainly makes things easier so good to just do that.

Note that you also must have a unique address as the primary address on the interface as the giaddr - which the the centralised dhcp server talks to. If that giaddr is shared across BNGs, your replies will go to the wrong place a large % of the time, and not get to the subscriber.
The giaddr does not need to be an address in any of the subnets you want to hand out addresses in - in isc dhcpd, you can configure the giaddr in a subnet as part of the “shared network” you want to hand out addresses from, which if you have a lot of BNGs saves you a handful of addresses you can give to customers.

Note that (from memory) the address used as the giaddr is also used as the “DHCP server address”. It’s what your CPE will send renew messages to. That does not confuse CPE, in my experience.

> I don't think this is any different whether you use the local DHCP
> server with RADIUS shared pool or a centralized DHCP server shared pool.


With RADIUS you can certainly hand out different router addresses for whatever reason - though not sure why you’d want to.

--
Nathan Ward