DHCP subnet issue

[Peter Rathlev]

On Tue, 2012-09-18 at 09:48 +0200, Michele Pinassi wrote:
> class "subnet_1" {
>     match pick-first-value (option dhcp-client-identifier, hardware);
> }
> 
> subclass "subnet_1" 1:00:04:f2:aa:MAC1;
> subclass "subnet_1" 1:cc:ef:48:5d:MAC2;
> subclass "subnet_1" 1:cc:ef:48:5d:MAC3;
> subclass "subnet_1" 1:cc:ef:48:5d:MAC4;

The "hardware" variable will AFAIK never match those subclasses since
it's always six bytes. Only CI can match a seven byte string.

Shortened version of the subnet declaration:

> shared-network voip {
>     subnet 172.20.0.0 netmask 255.255.0.0 {
>         pool {
>             allow members of "subnet_1";
>         }
>         pool {
>             allow members of "subnet_2";
>         }
>     }
> }
...
> dhcpd: DHCPREQUEST for 172.20.1.16 (172.20.1.2) from cc:ef:48:5d:MAC4
> via eth1
> dhcpd: DHCPACK on 172.20.1.16 to cc:ef:48:5d:MAC4 via eth1
> dhcpd: DHCPDISCOVER from cc:ef:48:5d:MAC4 via eth1: network
> 172.20.0.0/16: no free leases
> dhcpd: DHCPDISCOVER from cc:ef:48:5d:MAC4 via eth1: network
> 172.20.0.0/16: no free leases

This might be caused by MAC4 not sending a CI in the discover. I don't
know for sure, but maybe you can simply extend the subclasses to match
both CIs and MAC addresses:

  subclass "subnet_1" 1:cc:ef:48:5d:MAC4;
  subclass "subnet_1" cc:ef:48:5d:MAC4;

Otherwise you could create two classes, one for CI and one for MAC
addresses, allowing both in the pools.

Or you could select only the last six bytes from CI as identifier,
assuming it's always a MAC address (01) though that would probably
violate the DHCP specs in a way that's not recommended. It would
probably be something like suffix(option dhcp-client-identifier, 6).

-- 
Peter