sending options from wrong subnet in shared-network
Sten Carlsen
stenc at s-carlsen.dk
Thu Dec 5 16:39:36 UTC 2013
On 05/12/13 16:31, Brian J. Murrell wrote:
>
> 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;
> }
You should use only class OR host, using both may still be confusing.
Remember there is a hierarchy of where options are taken from - it was
listed in another post not long ago about a similar subject.
As I now recall, fixed-address can only be used in host statements.
Do you need a host statement for those hosts that do not need a fixed
address? A host with a host statement is a known host, that can be used
in allow/deny.
Personally I use a subclass if the host needs to be accepted and a host
statement if it needs a fixed address. This means hosts can have 3 types:
- known host with fixed-address - host statement
- known host with access to the network and one of several gateways -
subclass
- unknown host, gets an address but can not see the internet and can not
see any other hosts or services
>
> 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.
>
>
>
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
--
Best regards
Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"
More information about the dhcp-users
mailing list