sending options from wrong subnet in shared-network

[Brian J. Murrell]

On Thu, 2013-12-05 at 16:09 +0100, Sten Carlsen wrote: 
> Just for the record:
> 
> ALL host statements are outside ANY subnet declaration?

Yes.  The subnet declarations are as I pasted in my first message, with
no host declarations in them.

> If they are not,
> inheritance will come from that subnet as well, overriding the options
> in the subnet where the address eventually comes from.

Well, if that's a way to force the options from the proper subnet, then
maybe that's my solution, despite this seeming wrong.

But I was always under the impression that declaring hosts inside subnet
statements was considered wrong, or at least, bad form.

However, just to try to use classes/subclasses to rectify this I
modified my configuration as follows:

class "mgmt" {
    match pick-first-value (option dhcp-client-identifier, hardware);
}

shared-network foo {
    subnet 192.168.0.0 netmask 255.255.255.0 {
         #allow members of "mgmt";
         option routers             192.168.0.1;
         option domain-name         "subnet.example.com";
         option domain-name-servers 192.168.0.4;
         option subnet-mask         255.255.255.0;
         default-lease-time         21600;
         max-lease-time             43200;
    }
    subnet 10.14.80.0 netmask 255.255.248.0 {
         option routers             10.14.80.1;
         option domain-name         "subnet.example.com";
         option domain-name-servers 10.14.80.8, 10.14.80.9, 10.14.80.6;
         option subnet-mask         255.255.248.0;
         pool {
             range dynamic-bootp        10.14.80.100 10.14.83.254;
             deny members of "mgmt";
         }
         default-lease-time         21600;
         max-lease-time             43200;
         next-server                10.14.80.6;
    }
}

subclass "mgmt" 1:00:1e:67:6d:37:1d;
host lotus-1-mgmt.subnet.example.com {
    hardware ethernet 00:1e:67:6d:37:1d;
    fixed-address 192.168.0.1;
}

Yet the lease offered to the client still has a mixture of IP address
from the second subnet and options from the first (I've included the
request also, just for good measure):

10:03:45.291836 52:54:00:19:d9:08 > Broadcast, ethertype IPv4 (0x0800), length 441: (tos 0x0, ttl 64, id 4, offset 0, flags [none], proto UDP (17), length 427)
    0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 52:54:00:19:d9:08, length 399, xid 0x19d908, Flags [none]
          Client-Ethernet-Address 52:54:00:19:d9:08
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            Requested-IP Option 50, length 4: 10.14.81.56
            Server-ID Option 54, length 4: 10.14.80.6
            GUID Option 97, length 17: 0.131.219.112.238.241.63.20.77.122.75.89.47.80.50.93.8
            Client-ID Option 61, length 7: ether 52:54:00:19:d9:08
            T175 Option 175, length 45: 177.5.1.16.236.129.57.19.1.1.23.1.1.21.1.1.24.1.1.35.1.1.34.1.1.25.1.1.33.1.1.16.1.2.18.1.1.17.1.1.235.3.0.9.7
            DHCP-Message Option 53, length 1: Request
            MSZ Option 57, length 2: 1472
            ARCH Option 93, length 2: 0
            NDI Option 94, length 3: 1.2.1
            Vendor-Class Option 60, length 32: "PXEClient:Arch:00000:UNDI:002001"
            CLASS Option 77, length 4: "gPXE"
            Parameter-Request Option 55, length 13: 
              Subnet-Mask, Default-Gateway, Domain-Name-Server, LOG
              Hostname, Domain-Name, RP, Vendor-Option
              Vendor-Class, TFTP, BF, Option 175
              Option 203

10:03:45.383078 52:54:00:0f:ce:31 > 52:54:00:19:d9:08, ethertype IPv4 (0x0800), length 344: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 330)
    10.14.80.6.bootps > 10.14.81.56.bootpc: BOOTP/DHCP, Reply, length 302, xid 0x19d908, Flags [none]
          Your-IP 10.14.81.56
          Server-IP 10.14.80.6
          Client-Ethernet-Address 52:54:00:19:d9:08
          file "/pxelinux.0"
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: ACK
            Server-ID Option 54, length 4: 10.14.80.6
            Lease-Time Option 51, length 4: 10
            Subnet-Mask Option 1, length 4: 255.255.255.0
            Default-Gateway Option 3, length 4: 192.168.0.1
            Domain-Name-Server Option 6, length 4: 192.168.0.4
            Hostname Option 12, length 11: "lotus-19vm8"
            Domain-Name Option 15, length 13: "subnet.example.com"

Now given that the problem is that the client is receiving options from
the first subnet, ideally I could put some kind of allow/deny in there
ensuring that hosts that are not in the class "mgmt" can't get anything
from that subnet but there is no pool in the first subnet since they are
all fixed-addresses and allow/denying based on classes seems to be
limited to pools.

But TBH, I don't think this really has anything to do with classes since
the root problem is the mixing of assigned address and options from the
two different subnets.  I can't imagine any configuration where that
should be possible/valid.

Cheers,
b.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20131205/415533d8/attachment.bin>