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 >> >> >> >> > >Received on Fri May 1 17:27:45 2009