From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cristian Zamfir Subject: Re: arp during live migration Date: Mon, 05 Mar 2007 15:40:18 +0000 Message-ID: <45EC39E2.3020100@dcs.gla.ac.uk> References: 45E88EEA.4020707@dcs.gla.ac.uk <342BAC0A5467384983B586A6B0B3767104DC3DAF@EXNA.corp.stratus.com> <1172938895.14470.25.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1172938895.14470.25.camel@localhost.localdomain> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jacob Gorm Hansen Cc: "Graham, Simon" , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org > In my case, I NEVER see the gratuitous ARP being sent (confirmed using > tcpdump on peth0 in Dom0) and the return value from dev_queue_xmit is > sometimes 0 and sometimes 2 (that's PLUS 2 -- congestion notification > [NET_XMIT_CN]). I am seeing the same error, indeed it looks like it is NET_XMIT_CN. I also see 100% percent loss, the ARP never makes it to the wire in any of my tests. > If the ARP is only being used to advertise the move of the MAC to a new > port, it would be better to construct some kind of reliable protocol, > e.g. pinging a remote host (like the default GW) until an answer comes > back. This should be enough to make sure the switch got the message. If > the ARP is used for updating peer ARP caches, pinging everyone in the > guest's /proc/net/arp table until a majority have replied would be a > solution. Given that I am seeing 100% loos, I am considering implementing something like this. However, I assumed that sending the arp broadcast in netfront works for most people using 3.0.3. Can anyone confirm that they are actually seeing the arp being sent on the wire with xen >= 3.0.3? Cristian