On Sun, 6 Jan 2002, Lennert Buytenhek wrote: > > > Having TCP/IP or not is probably not the problem. If W2K answers ARP > > > requests on this interface you're still fscked. > > > > True. But I'd have thought disabling TCP/IP should disable ARP too. If the > > interface was configured, it'd also have a different IP > > Some OSes (including linux by default, I think) answer ARP requests for > local IP addresses even on interfaces that don't carry them.
Ah, ok. > > If the answer is no, then it could be caused by the > > VMWare "bridging" (I'll call it slaving from now on to avoid confusion). > > Recall that the external ethernet interface on rocky is actually slaved to > > sandy's external ethernet interface. Suppose the slaving decides which > > frames to send to rocky by looking at the source MAC address; if it's the > > MAC address of the slave device then it doesn't send them, and if it isn't > > it does. > > I don't really see how this would work? Can you elaborate on this a bit? The slaving needs to present the illusion to the VM (rocky in this case) of a real ethernet device. Therefore, it needs to send it everything on the ethernet including frames originating with sandy, but not including those originating with rocky. One way it might do this is to consider every frame any device, internal (rocky/sandy) or external, sends. Then, all it would do is to filter out any frame that has rocky's source MAC address from those it sends to rocky, and similarly for sandy. The consequence of this would be that any bridged frames rocky sent out would get echoed back to it, causing it to think that those MACs were on the external ethernet and leading to the problems I've seen. Cheers, Ganesh _______________________________________________ Bridge mailing list [EMAIL PROTECTED] http://www.math.leidenuniv.nl/mailman/listinfo/bridge
