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 > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
