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

[Simon]

Klaus Steden <klausfiend at 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