Klaus Steden <klausfi...@gmail.com> wrote:
> … so it’s been an uphill battle just to push for basic changes like "let's
> use one DHCP server for multiple subnets instead of standing up a separate
> local DHCP server on each subnet because L3 is not actually that complicated".
I guess you can be grateful for the little wins !
> To answer your questions:
>
> 1. yes, each distinct subnet has a distinct relay IP that is not reused by
> the other subnets
> 2. yes, all of the relay IPs are part of a specific subnet (iirc it's a /21
> or /22), although I don't know if there's a pattern to how relay IPs are
> chosen (sequentially? randomly? stepwise? etc.) from this subnet
OK, so some good news then.
> And yes, there have been a lot of "interesting times" so far.
I bet :-(
> FWIW, this is the relevant section of my Kea4 config file:
>
> """
> "shared-networks": [
> {
> "name": "iad1",
> "relay": {
> "ip-addresses": <?include "/etc/kea/kea-relay4.json"?>
> },
> "subnet4": [
> <?include "/etc/kea/kea-pool4.json"?>
> ]
> }
> ],
> """
That’s not going to work. That says “all of the subnets, and all of the relay
addresses, are in one big shared network. As I understand KEA config, you need :
"shared-networks": [
{
"name": “VLAN57",
"subnet4": [
{
"subnet": “192.168.120.66/32",
},
{
"subnet": "192.0.57.0/24",
"pools": [ { "pool": "192.0.57.100 - 192.0.57.199" } ]
"option-data": [
{
"name": "routers",
"data": "192.0.57.1"
} ]
}
]
},
{
"name": “VLAN123",
"subnet4": [
{
"subnet": “192.168.120.250/32",
},
{
"subnet": "192.0.123.0/24",
"pools": [ { "pool": "192.0.123.100 - 192.0.123.199" } ]
{
"name": "routers",
"data": "192.0.123.1"
} ]
}
]
}
],
Yes, it’s going to be one right p.i.t.a. to manage.
What that says is that if you receive a relayed packet from the subnet
192.168.120.66/32 then treat it as including clients from subnet 192.0.57.0/24
as well. Since there is no pool for the 192.168.120.66/32 subnet, then only
addresses from the 192.0.57.0/24 subnet will get considered for offering to the
client. In the general case you can have multiple subnets for clients within
the shared network - and the server will consider them as all equal in terms of
what can be handed out to clients.
From memory, I think you mentioned that all devices have static address
reservations, in which case you’ll need to adapt the subnet declarations, so :
{
"subnet": "192.0.57.0/24",
"pools": [ { "pool": "192.0.57.100 - 192.0.57.199" } ]
"option-data": [
{
"name": "routers",
"data": "192.0.57.1"
} ]
}
becomes :
{
"subnet": "192.0.57.0/24",
"pools": [ { "pool": "192.0.57.100 - 192.0.57.199" } ]
"option-data": [
{
"name": "routers",
"data": "192.0.57.1"
} ]
"reservations": [
{
"hw-address": "1a:1b:1c:1d:1e:1f",
"ip-address": “192.0.57.17"
},
{
... more reservations
} ]
}
And if there’s no dynamic clients at all, then you could delete the pool
section altogether. It’s a matter for you and the rest of the business to
determine if there’s a case for keeping a very small pool (with suitably short
lease times) - allowing newly added devices to get an address (which I suspect
you could spot in the logs with suitable filtering) prior to you actually being
told about it and configuring the correct reservation.
By the time you get to this level of complexity, it may be time to consider a
database backend for config - or store your config elsewhere and use scripts to
build the KEA config. The latter is quite common with DHCPD for large configs.
Simon
--
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
