From mboxrd@z Thu Jan 1 00:00:00 1970 From: Derrik Pates Subject: Re: ARP problems in -testing? Date: Sun, 16 Jan 2005 19:27:36 -0500 Message-ID: <41EB0678.4070707@devrandom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: xen-devel-admin@lists.sourceforge.net Errors-To: xen-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Keir Fraser Cc: =?ISO-8859-1?Q?Jan_Kundr=E1t?= , Ron Watkins , xen-devel@lists.sourceforge.net List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > The MAC addresses from the tcpdump log look sane. The problem must lie > elsewhere. I just tried this on a dedicated server located at thePlanet in Texas; I think this is an issue that combines the following: - No MAC address specified causes a random MAC address to be selected at domain create time - The upstream router has a local ARP cache - The host system's ARP cache for addresses on the virtual NIC for the instance is blown out when the virtual interface disappears when the domain is destroyed This seems to explain why tcpdump shows packets going to the VM's IP, but TCP sessions and ICMP packets don't get a response - the switch still knows the "old" MAC address, but the first outbound packet to the outside world implicitly eradicates the old ARP-cache entry. I don't think this is Xen's fault at all, just a property of the implementation of ARP resolution. I just happened to notice that the MAC shown in incoming packets didn't match the current MAC address (based on ifconfig's output), so this is my current theory on what's happening. -- Derrik Pates demon@devrandom.net ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt