Michael S. Zick wrote: > On Fri May 1 2009, Martin wrote: >> On Fri, 2009-05-01 at 08:54 -0700, Roderick A. Anderson wrote: >>> I'm asking for a clue stick here. First time I've run into this issue >>> ... hard. Be a few times where it took a bit for outbound traffic to >>> get a route but can't remember running into this problem. >>> >>> The short question is: does the network/NIC _know_ which IP address it >>> is responding for when a ping request comes in or does it just respond >>> to the ping request at the MAC (hardware?) level? >>> > > The *NIC* responds to MAC address(es) - > The *network* - now that is a big question. ;) So if a ping request comes in the NIC it should respond regardless of what IP it was sent to. That makes sense. > > There is a ARP cache in the kernel, but it *should* be rather short-lived. > Try arpping to help find out what is happening. Oddest stuff happening. When I check the arp table on the old host the troublesome guest's name (not IP) doesn't show up. When I ping the guest from another system the entry shows up. I was thinking the main router, between the two hosts, is using a long lived arp cache. I prefer staying way from it, the router, but may have to get access and take a look around. Maybe flush the arp cache, if I can, right after shutting down the old guest and starting the new. Thanks for the ideas. \\||/ Rod -- > > Mike >> Ping uses ICMP, which is a service running over IP, thus it is processed >> with the rest of the IP layer (in the kernel, unless you ahve a very >> expensive TCP/IP offload engine). This is layer 3, MAC is a link level >> (level 2) concept and thus independant of the processing of ICMP, beyond >> providing a packet connection. >> >> Cheers, >> - Martin >> >> >> >> > >