[Kea-users] CIDR or range notation in relay lists when using shared-networks?

[Simon]

Klaus Steden <klausfiend at gmail.com> wrote:

> FWIW, my team had no input into the network design process, we just got saddled with a bespoke implementation and have been adapting as we go.

Ah, the joys of inheriting someone else’s “bright idea”.

> This is the basic model: 
> 
> - an instance of Kea behind a single unicast IP handles all DHCP for the entire physical site
> - each switch is configured to use this same unicast IP as its DHCP helper address
> - the site has multiple distinct networks distributed across multiple switches via VXLAN

So far, so good.

> - each VXLAN uses a distinct relay address to forward DHCP requests to the helper IP
> - each relay address is in a subnet reserved specifically just for relay addresses

At this point I would argue that the network design is broken.
The expectation is that each relay agent should use a unicast address from a subnet in which the served clients reside. If this is done, then allocation happens “automagically” as the server will automatically associate the relay address with the subnet(s) served (or more accurately, the broadcast domain containing those subnets).
The way they’ve done it, you need to “do something” manually with the config in order to associate relay address with client network.

Questions:
Are distinct IP addresses associated with each client network ? I.e., each relay address is used for only one client network, and there is no duplication ?
Is there a pattern to this, e.g. a /27 range used for each client network, or are random single addresses used ?

What I’m thinking is that you could define a shared-network containing the client subnet(s) and the allowed relay addresses for each of the VLANs. That will automatically associate clients to the correct network for picking up network specific options (e.g. router address(es)). That’s going to be simpler if you can use (e.g.) 192.168.120.16/28 than if you need to use multiple /32 subnets in the shared network.

> The driver here is that it's been difficult to maintain the list of individual IPs because we're not kept in the loop when a new relay IP gets allocated, and the only solid info I can squeeze out of our network team is the subnets they've set aside specifically for relay IP addresses.

So not only have you inherited a “poor” network design, but you have a network team that doesn’t like to co-operate for the benefit of the business. That’s going to be a never ending source of “interesting times”.


Simon