[j-nsp] DHCP server recommendation for subscribers management

[Bjørn Mork]

Andrey Kostin via juniper-nsp <juniper-nsp at puck.nether.net> writes:
> Bjørn Mork via juniper-nsp писал 2021-08-06 15:27:
>> Probably stupid question, but here goes... How does a central server
>> make the IP usage more effective?  Are you sharing pools between
>> routers?
>
> Yes, going to have at least two routers as BNG and trying to find a
> way to not lock IP addresses if they aren't needed.

Yes, can make sense in some scenarios.  Main problem is the number of
host routes you must carry in your network, unless you have a level
where you can aggregate routes from those BNGs.

>> 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

>> 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.

> 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.

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

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.



Bjørn