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

Justin Shore justin at justinshore.com
Thu May 31 17:00:57 EDT 2007


Phil Mayers wrote:
>> 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 
> 
> That's odd.
> 
>> uses 0.0.0.0 for the SPA (source protocol address).  Herein lies the 
> 
> That's normal.

So a host can send ARPs without a valid SPA?

>> 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 
> 
> You're saying that gateways with proxy arp enabled will respond to ARP 
> requests when the target IP is INSIDE the subnet?
> 
> It should be apparent that's not the case, or nothing would work on that 
> subnet ever.

Proxy-ARP is supposed to kick in when a router receives an ARP request 
for a TPA that's part of a subnet on another interface.  In the case of 
our VisionNet 202s the modem is pulling an IP even in bridged mode 
unless you explicitly disable the built DHCP client which is on by 
default.  That means that the modem has a connected route to the TPA's 
subnet thus meeting the requirements for proxy-arp and allowing it to 
reply to the g-arp with its own MAC in the reply.  This was easily 
proven once we realized this by disabling the DHCP client on the modem. 
  It no longer had a connected route to the TPA's subnet and would no 
longer respond to the g-arps.

It was a very annoying and costly problem for us.  I had to watch the 
DHCP conflicts for signs of the problem, debug the DHCP server to find 
out which PVC the DECLINE was coming in on, cross-referenced the VPI/VCI 
to a specific customer and generate a truck roll to go out and either 
replace the modem or switch it to bridged modem and disable the DHCP 
client.  Needless to say that was a lot of truck rolls.

This may not be what Kurt is seeing but this may help him find a more 
workable solution.

Justin



More information about the cisco-nsp mailing list