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