Mailing List Archive

DHCP server recommendation for subscribers management
Hi Juniper-NSP community,

What DHCP server do you use/would recommend to deploy for subscriber
management? Preferably packaged for CentOS. Required features are IPv4,
IPv6 IANA, IPv6 IA_PD. Active leasequery support is desirable but
optional.

--
Kind regards,
Andrey
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: DHCP server recommendation for subscribers management [ In reply to ]
Jerry Jones ????? 2021-08-06 09:37:
> Strongly suggest having active lease query or bulk active lease query
>
> I believe kea has this support
>
> Jerry Jones?

Thanks for reply, Jerry.
In my understanding active leasequery can be run between routers, so
might be not needed on DHCP server, am I correct?
Interesting question what happens if we have two routers with
synchronized DHCP bindings, will be DHCP demux interfaces created on the
secondary router based on that? My guess is no, but need to test it. If
then traffic switches from primary to secondary router, will the
secondary be able to pass IP traffic right away or it will have to wait
for next DHCP packet from a client to create demux interface?

Kind regards,
Andrey
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: DHCP server recommendation for subscribers management [ In reply to ]
Andrey Kostin via juniper-nsp <juniper-nsp@puck.nether.net> writes:

> What DHCP server do you use/would recommend to deploy for subscriber
> management?

The one in JUNOS. Using RADIUS as backend.


Bjørn
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: DHCP server recommendation for subscribers management [ In reply to ]
Bjørn Mork via juniper-nsp ????? 2021-08-06 12:38:
> Andrey Kostin via juniper-nsp <juniper-nsp@puck.nether.net> writes:
>
>> What DHCP server do you use/would recommend to deploy for subscriber
>> management?
>
> The one in JUNOS. Using RADIUS as backend.
>

Thanks, currently using it but looking for a central server for more
effective IP usage.

Kind regards,
Andrey
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: DHCP server recommendation for subscribers management [ In reply to ]
Andrey Kostin <ankost@podolsk.ru> writes:
> Bjørn Mork via juniper-nsp ????? 2021-08-06 12:38:
>> Andrey Kostin via juniper-nsp <juniper-nsp@puck.nether.net> writes:
>>
>>> What DHCP server do you use/would recommend to deploy for subscriber
>>> management?
>> The one in JUNOS. Using RADIUS as backend.
>>
>
> Thanks, currently using it but looking for a central server for more
> effective IP usage.

Probably stupid question, but here goes... How does a central server
make the IP usage more effective? Are you sharing pools between
routers?

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.

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.


Bjørn
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: DHCP server recommendation for subscribers management [ In reply to ]
Bjørn Mork via juniper-nsp ????? 2021-08-06 15:27:

Thanks for your reply.
>
> 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.

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

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

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.

Kind regards,

Andrey
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: DHCP server recommendation for subscribers management [ In reply to ]
Andrey Kostin via juniper-nsp <juniper-nsp@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
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: DHCP server recommendation for subscribers management [ In reply to ]
> On 10/08/2021, at 10:40 PM, Bjørn Mork via juniper-nsp <juniper-nsp@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

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: DHCP server recommendation for subscribers management [ In reply to ]
Nathan Ward via juniper-nsp ????? 2021-08-10 08:00:
>> On 10/08/2021, at 10:40 PM, Bjørn Mork via juniper-nsp
>> <juniper-nsp@puck.nether.net> wrote:

Thank you Nathan and Bjorn for your explanations, they are very helpful!
I'll definitely look at ip pool management in RADIUS. I'm struggling to
find a good freeradius documentation source, could you give some links?

So far, I started to play with KEA dhcp server and stumbled on "shared
subnet" with multiple pools topic. I have two clients connected. The
first pool has only one IP available to force the client who comes last
to use the second pool. The first client successfully gets .226 IP from
the first pool, but the second client fails.

My config has this:

"subnet4": [
{
"subnet": "X.X.X.224/28",
"pools": [ { "pool": "X.X.X.226 - X.X.X.226" } ],
"relay": {
"ip-addresses": [ "X.X.X.225" ]
},
"option-data": [.
{
// For each IPv4 subnet you most likely need to
specify at
// least one router.
"name": "routers",
"data": "X.X.X.225"
}
]
},
{
"subnet": "X.X.X.240/28",
"pools": [ { "pool": "X.X.X.242 - X.X.X.245" } ],
"relay": {
"ip-addresses": [ "X.X.X.225" ]
},
"option-data": [.
{
// For each IPv4 subnet you most likely need to
specify at
// least one router.
"name": "routers",
"data": "X.X.X.241"
}
],

In the log I get this:
Aug 10 15:51:17 testradius kea-dhcp4[44325]: WARN
ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET [hwtype=1 d0:76:8f:a7:43:ca], cid=[no
info], tid=0x485c2228: failed to allocate an IPv4 address in the subnet
X.X.X.224/28, subnet-id 1, shared network
Aug 10 15:51:17 testradius kea-dhcp4[44325]: WARN
ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 d0:76:8f:a7:43:ca], cid=[no info],
tid=0x485c2228: failed to allocate an IPv4 address after 1 attempt(s)
Aug 10 15:51:17 testradius kea-dhcp4[44325]: WARN
ALLOC_ENGINE_V4_ALLOC_FAIL_CLASSES [hwtype=1 d0:76:8f:a7:43:ca], cid=[no
info], tid=0x485c2228: Failed to allocate an IPv4 address for client
with classes: ALL, VENDOR_CLASS_xxxxxxxx.dslforum.org, UNKNOWN

Looks like KEA doesn't consider the second subnet as belonging to the
same shared network despite the matching giaddr. I followed example in
Kea documentation and expect that relay address matching giaddr should
do the trick, but I feel maybe subnets have to be in the same bracket,
however don't know how to put it there. At one moment I saw addresses
leased from both pools but later it returned back to this. Maybe it was
a transient state when previous lease didn't expire yet, I'm not sure.


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

Good point, thanks. I find Juniper documentation on primary and
preferred IP very confusing, for me it's always try and fail method to
find a working combination. Even more confusing, few years ago I had a
TAC case opened regarding the meaning of preferred address for IPv6
assignment to pppoe subscriber and I was told by TAC that it's not
supported for IPv6 at all. I think it changed in recent releases.
For example, there is unique IP on lo0 that is used as router-id etc.,
and also there should be one or more IPs that match subnets in address
pools. In dynamic profile address is specified this way:
unnumbered-address "$junos-loopback-interface" preferred-source-address
"$junos-preferred-source-address"
Currently I don't have neither primary or preferred specified on lo0 and
.225 is somehow selected.
In my understanding preferred-source-address has to match subnet in
address pool, otherwise it will fail to assign an address. And it also
will be used as giaddr in this case. Which address should be primary and
which preferred in this case?

Kind regards,
Andrey
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: DHCP server recommendation for subscribers management [ In reply to ]
Andrey Kostin via juniper-nsp ????? 2021-08-10 16:44:

> So far, I started to play with KEA dhcp server and stumbled on "shared
> subnet" with multiple pools topic. I have two clients connected. The
> first pool has only one IP available to force the client who comes
> last to use the second pool. The first client successfully gets .226
> IP from the first pool, but the second client fails.

Found the problem with KEA config, I didn't read docs thoroughly and
missed "shared-networks" statement. It works this way:

"shared-networks": [
{
"name": "ftth",
"relay": {
"ip-addresses": [ "Y.Y.Y.Y" ]
},


"subnet4": [
{
"subnet": "X.X.X.224/28",
"pools": [ { "pool": "X.X.X.226 - X.X.X.226" } ],

"option-data": [.
{
// For each IPv4 subnet you most likely need to
specify at
// least one router.
"name": "routers",
"data": "X.X.X.225"
}
]
},
{
"subnet": "X.X.X.240/28",
"pools": [ { "pool": "X.X.X.242 - X.X.X.245" } ],

"option-data": [.
{
// For each IPv4 subnet you most likely need to
specify at
// least one router.
"name": "routers",
"data": "X.X.X.241"
}
]
}
],

However it puzzled me why KEA didn't send anything in response to BNG,
but it's a different topic.
Meanwhile I set unique IP on lo0 as primary and now it appears in
giaddr. On demux interfaces Junos uses an IP that matches the subnet of
leased IP. So it looks like in this case preferred IP setting doesn't
affect address selection process in any way.

Kind regards,
Andrey
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: DHCP server recommendation for subscribers management [ In reply to ]
> On 11/08/2021, at 8:44 AM, Andrey Kostin <ankost@podolsk.ru> wrote:
>
> Nathan Ward via juniper-nsp ????? 2021-08-10 08:00:
>>> On 10/08/2021, at 10:40 PM, Bjørn Mork via juniper-nsp <juniper-nsp@puck.nether.net> wrote:
>
> Thank you Nathan and Bjorn for your explanations, they are very helpful!
> I'll definitely look at ip pool management in RADIUS. I'm struggling to find a good freeradius documentation source, could you give some links?

Yeah the FreeRADIUS docs are hard to navigate - but getting better.

You want to look in the example configs. Start from an understanding of what you want the RADIUS messages to have in them. You can do this with just a static Users file in your test environment with just one subscriber, and then look at moving that in to sqlippool or similar, with whatever logic you need to get those attributes in to the right place. Framed-IP-Address obviously, but maybe also Framed-IP-Netmask etc. - better to experiment with the attributes and get them right without the sqlippool complexity.

https://wiki.freeradius.org/modules/Rlm_sqlippool This is alright (it appears outdated on the surface, but is up to date I think)
https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/raddb/mods-available/sqlippool This is the example config and has some more detail than the above.
https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/raddb/mods-config/sql/ippool/postgresql/queries.conf This is useful to understand some of the internals

>> 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.
>
> Good point, thanks. I find Juniper documentation on primary and preferred IP very confusing, for me it's always try and fail method to find a working combination. Even more confusing, few years ago I had a TAC case opened regarding the meaning of preferred address for IPv6 assignment to pppoe subscriber and I was told by TAC that it's not supported for IPv6 at all. I think it changed in recent releases.
> For example, there is unique IP on lo0 that is used as router-id etc., and also there should be one or more IPs that match subnets in address pools. In dynamic profile address is specified this way:
> unnumbered-address "$junos-loopback-interface" preferred-source-address "$junos-preferred-source-address"
> Currently I don't have neither primary or preferred specified on lo0 and .225 is somehow selected.
> In my understanding preferred-source-address has to match subnet in address pool, otherwise it will fail to assign an address. And it also will be used as giaddr in this case. Which address should be primary and which preferred in this case?

I can see that being the case for IPv6 - IPv6 has a source address selection mechanism which will, in theory, choose the best address for the destination IP.

I’m not entirely sure re. your other question - but the giaddr must be unique within your network - or the DHCP server cannot route packets back to it.

A good setup for IPv4 DHCP relay is:

lo0 addresses on BNG-1
192.168.0.1/32 - use as giaddr
10.0.0.1/32
10.0.1.1/32
10.0.2.1/32
10.0.3.1/32

lo0 addresses on BNG-2
192.168.0.2/32 - use as giaddr
10.0.0.1/32
10.0.1.1/32
10.0.2.1/32
10.0.3.1/32

DHCP server:
Single shared network over all these subnets:
Subnet 192.168.0.0/24 - i.e. covering giaddrs
No pool
Subnet 10.0.0.0/24
pool 10.0.0.2-254
Subnet 10.0.1.0/24
pool 10.0.1.2-254
Subnet 10.0.2.0/24
pool 10.0.2.2-254
Subnet 10.0.3.0/24
pool 10.0.3.2-254

This causes your giaddrs to be in the shared network with the subnets you want to assign addresses from (i.e. the ones with pools), so the DHCP server can match them up, but, with no pool in the 192.168.0.0/24 subnet you don’t assign addresses out of that network.

Otherwise you have to have a unique /32 for each BNG in each subnet and you burn lots of addresses that way.

I am sorry I can’t recall the configuration to make the above behave like that - but can probably dig something up if you are stuck.

--
Nathan Ward

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: DHCP server recommendation for subscribers management [ In reply to ]
Nathan Ward ????? 2021-08-10 20:53:

> Yeah the FreeRADIUS docs are hard to navigate - but getting better.
>
> You want to look in the example configs. Start from an understanding
> of what you want the RADIUS messages to have in them. You can do this
> with just a static Users file in your test environment with just one
> subscriber, and then look at moving that in to sqlippool or similar,
> with whatever logic you need to get those attributes in to the right
> place. Framed-IP-Address obviously, but maybe also Framed-IP-Netmask
> etc. - better to experiment with the attributes and get them right
> without the sqlippool complexity.
>
> https://wiki.freeradius.org/modules/Rlm_sqlippool This is alright (it
> appears outdated on the surface, but is up to date I think)
> https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/raddb/mods-available/sqlippool
> This is the example config and has some more detail than the above.
> https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/raddb/mods-config/sql/ippool/postgresql/queries.conf
> This is useful to understand some of the internals
>

Thanks for links. I'm pretty well familiar with radius users file syntax
but freeradius modules calls puzzles me a little.

>
> A good setup for IPv4 DHCP relay is:
>
> lo0 addresses on BNG-1
> 192.168.0.1/32 - use as giaddr
> 10.0.0.1/32
> 10.0.1.1/32
> 10.0.2.1/32
> 10.0.3.1/32
>
> lo0 addresses on BNG-2
> 192.168.0.2/32 - use as giaddr
> 10.0.0.1/32
> 10.0.1.1/32
> 10.0.2.1/32
> 10.0.3.1/32
>
> DHCP server:
> Single shared network over all these subnets:
> Subnet 192.168.0.0/24 - i.e. covering giaddrs
> No pool
> Subnet 10.0.0.0/24
> pool 10.0.0.2-254
> Subnet 10.0.1.0/24
> pool 10.0.1.2-254
> Subnet 10.0.2.0/24
> pool 10.0.2.2-254
> Subnet 10.0.3.0/24
> pool 10.0.3.2-254
>
> This causes your giaddrs to be in the shared network with the subnets
> you want to assign addresses from (i.e. the ones with pools), so the
> DHCP server can match them up, but, with no pool in the 192.168.0.0/24
> subnet you don’t assign addresses out of that network.
>
> Otherwise you have to have a unique /32 for each BNG in each subnet
> and you burn lots of addresses that way.

How is potential IP conflict handled in this case if BNGs are connected
to the switched LAN segment? In my case with vlan per customer it can
happen when a client requests the lease and can get replies from same IP
but different MACs. BNGs can also see each other and report IP conflict.

Kind regards,

Andrey
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: DHCP server recommendation for subscribers management [ In reply to ]
Hi Nathan,

>
> You want to look in the example configs. Start from an understanding
> of what you want the RADIUS messages to have in them. You can do this
> with just a static Users file in your test environment with just one
> subscriber, and then look at moving that in to sqlippool or similar,
> with whatever logic you need to get those attributes in to the right
> place. Framed-IP-Address obviously, but maybe also Framed-IP-Netmask
> etc. - better to experiment with the attributes and get them right
> without the sqlippool complexity.
>
> https://wiki.freeradius.org/modules/Rlm_sqlippool This is alright (it
> appears outdated on the surface, but is up to date I think)
> https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/raddb/mods-available/sqlippool
> This is the example config and has some more detail than the above.
> https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/raddb/mods-config/sql/ippool/postgresql/queries.conf
> This is useful to understand some of the internals
>

I started to play with sqlippool and have a couple of questions.
Does sqlippool or any other module supports IPv6? I haven't found
anything about it in the documentation.
Is ippool module used only as example for database schema? It looks like
it doesn't need to be enabled for sqlippool operation.

Kind regards,
Andrey
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp