known client ending up in unknown pool

James Clark Calloway callowayj at ornl.gov
Thu Nov 9 19:06:34 UTC 2006


Greetings .. We have dhcp set up so that if a client is not known they get
directed to a special subnet with limited access.

An example definition of one of our limited subnets is:

      subnet 10.1.x.x netmask 255.255.255.0 {
          option domain-name "domain";
          option routers x.x.x.x;
          option subnet-mask x.x.x.x;
          option broadcast-address x.x.x.x;
          pool {
              allow unknown clients;
              deny dynamic bootp clients;
              deny members of "ras-clients";
              range x.x.x.x 	x.x.x.x2;
              default-lease-time x;
              max-lease-time     x;
              option domain-name-servers  x.x.x.x, x.x.x.x;
              option netbios-name-servers x.x.x.x, x.x.x.x;
          }
      }


So, by the above, if a client is known they would
not get one of the addresses in the pool listed above.

For the past little bit we have had probably one incident per
day where a known client is ending up in this address pool.

A sample from the logs of our dhcp server:


v  9 08:46:35 server dhcpd: [ID 702911 local7.info] DHCPDISCOVER from
mac via x.x.x.x
Nov  9 08:46:36 server dhcpd: [ID 702911 local7.info] DHCPOFFER on
(addr on restricted subnet)  to  mac (host) via x.x.x.x
Nov  9 08:46:37 server dhcpd: [ID 702911 local7.info] DHCPREQUEST for
(addr on restricted subnet) (nameserver_ip) from mac (host) via
(ip)
Nov  9 08:46:37 server dhcpd: [ID 702911 local7.info] DHCPACK on (addr on 
restricted subnet)
to mac (host) via (router ip)
Nov  9 08:54:06 server dhcpd: [ID 702911 local7.info] DHCPREQUEST for
(addr on restricted subnet) from  (host) via bge0


.. many ACKS follow of the 10.1 address, and then this particular client
seemed to fix itself. Some fix themselves manually. Some fix themselves
after the user does a release/renew. Sometimes that doesnt fix it
and we set it static and then later dhcp seems to behave as normal.

Here is where the above seemed to fix itself:


Nov  9 10:18:46 server dhcpd: [ID 702911 local7.info] DHCPDISCOVER from
mac via router
Nov  9 10:18:46 server dhcpd: [ID 702911 local7.info] DHCPOFFER on
(ip listed in dhcpd.conf host area) to mac via router
Nov  9 10:18:47 server dhcpd: [ID 702911 local7.info] DHCPREQUEST for
(good IP)  (nameserver ip) from mac via (router)
Nov  9 10:18:47 server dhcpd: [ID 702911 local7.info] DHCPACK on
(good ip) to mac via (router)
Nov  9 11:03:35 server dhcpd: [ID 702911 local7.info] DHCPREQUEST for
(good ip) from mac via router
Nov  9 11:03:35 server dhcpd: [ID 702911 local7.info] DHCPACK on
(good ip) to mac via router


At the time of this the client had a listing in the conf file

host ahostdef {
      hardware ethernet mac;
      fixed-address (good ip);
      option host-name   "host";
      option domain-name "domain";
}


Do we have something wrong in our logic on the pool defs ? a) Why would
this guy not get his regular address thats listed in the conf file , and
b) why would he be getting ACKs on an address in a subnet that he 
shouldn't --if our logic is set up right-- be allowed into ?

We've done it this way for years  and it always seemed to work ...
but we recently lowered our lease time from a rather large one to a much 
smaller time ... so now folks are ACKing etc a lot more often and 
interactive with the dhcp server. This is for 3.0.4.



More information about the dhcp-users mailing list