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

[Justin Shore]

Yes.  This has been a major problem for us!  I've seen this happen in 3 
different scenarios, all of them involving a particular model of DSL 
modem and either Vista, OS X, or D-Link WBR-1310/EBR-2310 firewalls.

What I've found through a lot of sniffing is that all 3 platforms I 
listed above do a g-arp when they receive the DHCP OFFER.  The g-arp has 
a source protocol address (SPA) of 0.0.0.0.  The destination hardware 
address (DHA) is malformed in the case of the D-Link.  I haven't checked 
on the other 2 yet.  The DPA is the the IP from the DHCP OFFER.  The DSL 
modem/router that is causing our problems is a VisionNet 202ER.  The 202 
responds to the g-arp with its own MAC as the SHA.  This causes the 
Vista/OS X/D-Link to send a DHCP DECLINE.  I haven't looked into the 
guts of a DHCP DECLINE packet but I'm assuming that their is a field in 
there that carries a reason for the DECLINE.  In this case it's the 
g-arp response.  I did all of this research on the D-Link problem but 
the symptoms are exactly the same on the OS X and Vista boxes so I would 
have to say that I believe much of this to be true for those platforms 
as well.

The end result is that our Cisco IOS DHCP servers log the conflict and 
pull that IP out of the pool.  An OS X box depleted one of our pools in 
about 30 seconds.  Vista took about 15 minutes (BSD is apparently much 
faster...).  The D-link took a couple minutes.

I see a couple of causes here.  One, the VisionNet 202 must have a 
builtin proxy-ARP function.  That is the only way to explain it's 
response to the g-arp.  The VisionNet does not respond to the g-arp when 
you disable its internal DHCP client (so the modem doesn't pull down and 
IP from the DHCP as well which it does even in bridged mode for whatever 
reason).  The second cause is the way the client device formats the 
g-arp.  All of the documentation I've read on g-arp states that the SPA 
must be populated with the IP of the device.  To me this implies that if 
the device doesn't yet have an IP that it can't generate a g-arp. 
However these platforms, or at least the D-Link which I have actually 
sniffed, sets the SPA to 0.0.0.0.  This is what sets off the proxy-arp 
process in the VisionNet modem/router.  The VisionNet sees that the DPA 
is for an host to which it has a route to and that the SPA is not in 
that subnet and does not have a route to the DPA.  The VisionNet then 
replies to the arp with it's own MAC as the DHA and forwards the frames 
to the actual DHA (the very definition of proxy-arp).  This behavior is 
not observed when the client DHCP process is disabled on the VisionNet, 
preventing it from pulling its own IP down from the IOS DHCP server. 
Ie, the VisionNet no longer has a connected interface in the DPA subnet 
which implies that it doesn't have a specific route to that subnet and 
thus it does not reply to the arp.

We are now generating truck rolls to each DSL customer's house to 
disable the DHCP client feature.  Why the modem doesn't turn off the 
DHCP client when you set it to bridged mode is beyond me.  It's nuts. 
This burns up 2 IPs for every customer.  That's almost as bad as when we 
used /30s to address DSL customers!

Now if you don't use VisionNet modems then the problem may be on your 
IOS device.  Have you disabled proxy-arp on the interfaces facing you 
DHCP clients?  It's on by default.

Justin


Kurt Bales wrote:
> Hey Guys,
> 
> Has anyone else noticed an increase in "Gratuitous ARP" entries under "sh ip
> dhcp conflict" lately?
> 
> We serve Customer addresses (for better or worse!) via DHCP in some network
> designs. The DHCP server is running on the local Cisco Device in the area
> (usually an 1811). Lately we have noticed a large number of "conflicts"
> listed with "Gratuitous ARP" as the reason. 9 times out of 10 has shown the
> offending machine to be a Windows Vista install.
> 
> Does anyone know why this is happening, or a way we can combat against it?
> We are moving our network away from DHCP addressing for customers, but this
> is a slow process. Is there a method to alert when the number of conflicts
> reaches a threshold?