Can't Get Dynamic Address from one pool when device is configured as Fixed Address on other, separate pool.

matt.fura at bt.com matt.fura at bt.com
Tue Nov 18 23:49:12 UTC 2014


Niall,

I think that part of the policies is clear.  The aspect I was not aware of was that if a client is defined as a Fixed Address in a completely separate pool, the server still considers it as a known host.  This is the part that threw me.

Thinking about it now, it definitely makes sense and I see why it's treated as such.

Thanks again for all the help!

Regards,

Matthew Fura | Sr. TAC Engineer | BT Diamond IP | Office +1.610.280.2339 | Fax +1.610.423.4774 | http://bt.diamondip.com


-----Original Message-----
From: dhcp-users-bounces at lists.isc.org [mailto:dhcp-users-bounces at lists.isc.org] On Behalf Of Niall O'Reilly
Sent: Tuesday, November 18, 2014 6:42 PM
To: Users of ISC DHCP
Subject: Re: Can't Get Dynamic Address from one pool when device is configured as Fixed Address on other, separate pool.

At Tue, 18 Nov 2014 17:42:58 +0000,
Graham Clinch wrote:
> 
> > The /20:
> > 
> > subnet 130.x.x.0 netmask 255.255.240.0 {
> > 	option subnet-mask 255.255.224.0 ; 
> > 	option routers 130.x.x.1 ; 
> > 	option domain-name-servers 10.x.x.x , 10.x.x.x ; 
> > 	option domain-name "example.com" ; 
> > 	option netbios-name-servers 10.x.x.x ; 
> > 	option netbios-node-type 8 ; 
> >  	default-lease-time 86400 ;
> > 	get-lease-hostnames False ;
> > 	max-lease-time 86400 ;
> > 	min-lease-time 500 ;
> > 	ping-check True ;
> > 	ping-timeout 2 ;
> > 	pool {
> > 		option subnet-mask 255.255.224.0 ; 
> > 		option routers 130x.x.1 ; 
> > 		option domain-name-servers 10.x.x.x , 10.x.x.x ; 
> > 		option domain-name "example.com" ; 
> > 		option netbios-name-servers 10.x.x.x ; 
> > 		option netbios-node-type 8 ; 
> > 		 authoritative ;
> > 		ddns-updates False ;
> > 		default-lease-time 1800 ;
> > 		do-forward-updates False ;
> > 		get-lease-hostnames False ;
> > 		max-lease-time 1800 ;
> > 		min-lease-time 1800 ;
> > 		one-lease-per-client True ;
> > 		ping-check True ;
> > 		ping-timeout 2 ;
> > 		update-optimization True ;
> > 		use-host-decl-names False ;
> > 		 allow unknown-clients ;
> > 
> > And the 'Dynamic' /24:
> > 
> > subnet 137.x.x.0 netmask 255.255.255.0 {
> >  	pool {
> > 		option subnet-mask 255.255.255.0 ; 
> > 		option routers 137.x.x.1 ; 
> > 		option domain-name-servers 137.x.x.x ; 
> > 		 authoritative ;
> > 		ddns-updates False ;
> > 		default-lease-time 1800 ;
> > 		do-forward-updates False ;
> > 		get-lease-hostnames False ;
> > 		max-lease-time 1800 ;
> > 		min-lease-time 1800 ;
> > 		one-lease-per-client True ;
> > 		ping-check True ;
> > 		ping-timeout 2 ;
> > 		update-optimization True ;
> > 		use-host-decl-names False ;
> > 		 allow unknown-clients ;
> > 		range 137.x.x.30 137.x.x.254;
> 
> Urgh.  That configuration is crying out for some housekeeping!
> 
> I'm heading down the same track as Phil - my *hunch* is that 'allow 
> unknown-clients' in the /24 is preventing known clients from being 
> allocated addresses (allow 'only' unknown-clients).
> 
> The documentation isn't very clear, but given that "Dynamic address 
> assignment to unknown clients is allowed by default" (in dhcpd.conf's 
> "The unknown-clients keyword"), I'd start by removing both occurances 
> of "allow unknown-clients", since specifying it is either doing 
> nothing, or (my hunch) implicitly causing 'deny known-clients'.

  Here's the relevant part of the man page for dhcpd.conf.  

	Each entry in a pool’s permit list is introduced with the
        allow or deny keyword.  If a pool has a permit list, then only
        those clients that match specific entries on the permit list
        will be eligible to be assigned addresses from the pool.  If a
        pool has a deny list, then only those clients that do not
        match any entries on the deny list will be eligible.  If both
        permit and deny lists exist for a pool, then only clients that
        match the permit list and do not match the deny list will be
        allowed access.

  It could be clearer and use its terminology more consistently, but
  I think there's only one way to read it, which confirms your hunch,
  Graham.

  With only "allow" entries, anything not matching at least one entry
  is forbidden.  Consequently, specifying only "allow unknown-clients;"
  blocks all "known" ones.

  IHTH
  Niall O'Reilly
  
_______________________________________________
dhcp-users mailing list
dhcp-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users


More information about the dhcp-users mailing list