[Kea-users] Unable To Support Multiple Subnets via DHCP Relay

Igor Smitran sigor at blic.net
Mon Dec 26 08:41:52 UTC 2016


I know it's too late for this kind of ideas, but i will say it anyway:

1. We should look on a subnet4 option only as a container for devices 
that have some options in common:
     a) they send DHCP packets over the same relay
     b) they belong to same class
     c) something else

2. If 1 is true then we should have a slightly different setup of 
subnet/pools:
     a) subnets should contain common options (name server, domain name...)
     b) subnet should contain a classifier setup (i.e. relay info) based 
on which devices belong to that subnet
     c) pools should have a possibility of adding additional options to 
them (netmask and routers for start)

That way we would be able to have only one subnet definition per 
classifier (if i am not mistaking) and it would look like this (rough 
example, sorry):

subnet4: [
     {
     id: 1,
     // common options for this subnet start
          "option-data" : [
          {
            "name" : "ntp-servers",
            "code" : 42,
            "space" : "dhcp4",
            "csv-format" : true,
            "data" : "ntp.server.ip.address"
          },
          {
            "name" : "domain-name",
            "code" : 15,
            "space" : "dhcp4",
            "csv-format" : true,
            "data" : "domain.name.tld"
          },
          {
            "name" : "domain-name-servers",
            "code" : 6,
            "space" : "dhcp4",
            "csv-format" : true,
            "data" : "first.dns.ip.address, second.dns.ip.address"
          },
         ],
     // common options for this subnet end

     // pools start
     "pools": [
         {
             "pool": "first.pool.start.ip - first.pool.end.ip",
             // pool specific options start
              "option-data" : [
                 { "name" : "routers" ... },
                 { "name" : "netmask" ...}
             ]
             // pool specific options end
         },
         {
             "pool": "second.pool.start.ip - second.pool.end.ip",
             // pool specific options start
              "option-data" : [
                 { "name" : "routers" ... },
                 { "name" : "netmask" ...}
             ]
             // pool specific options end
         },
     ],
     // pools end

     // classifier start
          "relay": {
            "ip-address": "relay.ip.address"
          }
     // classifier end
     }
]

this situation doesn't cover specific cases, for example cable network 
where one relay covers two device classes and i haven't really thought 
about it for now, so i will not make any proposals about that case.



More information about the Kea-users mailing list