[c-nsp] Windows Vista, Gratuitous ARP and DHCP conflicts

Justin Shore justin at justinshore.com
Thu May 31 09:56:49 EDT 2007


Phil Mayers wrote:
> Kurt Bales wrote:
>> Hello All,
>>
>> Just a follow up to this post. I got into work this morning and found this
>> problem occuring in overdrive!
> 
> As I believe I mentioned in a previous post, It's normal for the client 
> to do an ARP *request* for the IP it's offered; that is how conflicts 
> are detected before picking the lease. So, a normal process looks like this:

It may be normal but best I can tell Vista's g-arp frames are not 
formatted correctly.  In fact this problem affects not only Vista but 
the D-Link's WBR and EBR product lines and OS X (I don't know what 
version). I fought this battle months ago and lost.  We discovered this 
issue when we put Vista, OS X or the new D-Links behind the VisionNet 
202 ADSL modem.  Previously we used the 200ES and 201 models.  The 202 
was significantly different.  Unfortunately it also came with a builtin 
proxy-arp function that can't be disabled.

> router: OFFER src=gwip dst=255.255.255.255 dmac=? [1]
> client: ARP request ip=leaseip

It's all good up until this point.  The g-arp that Vista sends uses a BS 
MAC (a multi-cast MAC no less) for the THA (target hardware address). 
It uses 0.0.0.0 for the SPA (source protocol address).  Herein lies the 
problem.  Any device that performs proxy-arp functions will respond to 
this ARP because 1) it has a connected network to the target device in 
question and 2) it knows based on the SPA that the sending host is not 
already in that subnet (otherwise the local host would respond to the 
ARP itself).  When the proxy-arp device responds, in our case the 
VisionNet modem, the sending device sends a DHCP DECLINE to the DHCP 
server and requests another IP.  The only fixes we found for this 
problem was to not put Vista, OS X or the new D-Link firewalls behind a 
VisionNet 202 modem or to put a LinkSys firewall in front of them.

 From what I read a device is not supposed to send an ARP request until 
it has a valid IP to use as the SPA.  Of course what I read also 
indicates that the THA is supposed to be ff:ff:ff:ff:ff:ff and not the 
made up MAC that Vista uses.

Kurt, disabling proxy ARP on the interfaces facing your DHCP clients 
should resolve the technical issue at least.

Justin


More information about the cisco-nsp mailing list