lease limit 1 and Apple Mac Computers creates duplicate IP address

[Matt Jenkins]

Hi Simon, thanks for the details response. My responses are inline.

Thanks,

Matthew Jenkins
SmarterBroadband
matt at sbbinc.net
530.272.4000

On 09/13/2013 04:44 AM, Simon Hobson wrote:
> Matt Jenkins wrote:
>> CPE connected to a switch.
>> 1. Apple computer gets IP address then disconnects cable.
>> 2. Lease expires.
>> 3. Other non-Apple computer connects and gets same IP address.
>> 4. Apple computer connects and is unable to get a lease. It then assigns
>> itself the original IP address it had. Now there is an IP conflict.
>>
>> CPE connected to a switch.
>> 1. Apple computer gets IP address then disconnects cable.
>> 2. Lease expires.
>> 3. Other non-Apple computer connects and gets a new IP address.
>> 4. All other unused IP addresses are given out.
>> 5. New CPE connects and customers computer gets IP address Apple
>> computer had. (This will be a different household)
>> 6. Original Apple computer connects and is unable to get a lease. It
>> then assigns itself the original IP address it had. Now there is an IP
>> conflict.
> Do you have any form of filtering/privacy control in place ?
> My observations are that the client will do two things in parallel or in close temporal proximity :
>
> 1) Check if the router is the same device as it was on a network for which it still has a valid lease (does ARP requests for the IP of the router)
1. Yes the router will be the same.
> 2) Broadcast DHCP packets
2. This is all being done via DHCP relay.
>
> If it gets no response from a DHCP server AND the router is the same device AND there is an unexpired lease AND ARP requests for the address get no answer - only then does it reuse an address. Also, they are (IIRC) pretty good about checking before using a manually configured address and will pop up a warning if it would create a duplicate. If it can't get a valid address, it will assign itse;f a link-local address (169.254....)

With lease limit 1, my understanding is, the DHCP server does not 
respond to the client if there are still IPs in the pool available, but 
due to the restriction of agent.remote-id it does not have an IP to 
provide. At least in my wireshark scans and logs I can see no sign of a 
response from the DHCP server to the client. In the first situation ARP 
requests would succeed between the two computers. In the second example 
there is client isolation between the two devices.
>
> So firstly, the device shouldn't be attampting to use an expired lease (a common part of both scenarios). Have you tried with longer leases just in case there's some timing problem ? 10 minute leases are a bit short anyway for the general case.
I discovered this by accident while doing some testing, I am using short 
lease times so its reasonable to test this while I watch it. I could try 
longer lease times but our production network uses 30 minute leases. The 
amount of traffic this generates doesn't affect performance.
>
> Secondly, assuming there's something wrong with the client's lease timing, is there anything in teh network that will block it being able to detect the other computer ? Specifically, it must be able to do an ARP request and gete an answer from any other device that might be using it. I'm wondering if perhaps there is some filtering in place - otherwise all customers' computers would be open and visible to each other. However, this privacy filtering would break suplicate IP address detection.
In the first scenario, the one I am testing most, ARP requests between 
devices would succeed. (Its a dumb switch).

Any other ideas of things I can check? Anything I can do to get the DHCP 
server to say there are no IPs available in this case?

Thanks!
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
>