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

[Phil Mayers]

Justin Shore wrote:
> 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?

Sending with an SPA of 0.0.0.0 is part of the duplicate address 
detection that certainly every version of windows from win98 onwards, 
most linux /sbin/dhclient-script setups and MacOSX have used. So yes.

My Google-fu is weak finding the relevant RFCs however.

The rationale is that of course during DAD you don't *have* 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 

Ah, I see.

> 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.

Yes - I can imagine that was very tedious!

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

> 
> Justin
>