Bug 251527 - Fake ARP dropped after migration leading to loss of network connectivity
Fake ARP dropped after migration leading to loss of network connectivity
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel-xen (Show other bugs)
All Linux
low Severity low
: rc
: ---
Assigned To: Don Dutile
Martin Jenner
Depends On:
Blocks: 441716
  Show dependency treegraph
Reported: 2007-08-09 11:30 EDT by Ian Campbell
Modified: 2008-05-21 10:49 EDT (History)
4 users (show)

See Also:
Fixed In Version: RHBA-2008-0314
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-21 10:49:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
xen-unstable 13763:8132bf3ddbef ported to 2.6.18-53.el5 (1.26 KB, patch)
2007-12-14 04:31 EST, Ian Campbell
no flags Details | Diff
xen-unstable 14280:42b29f084c31 ported to 2.6.18-53.el5 (10.83 KB, patch)
2007-12-14 04:32 EST, Ian Campbell
no flags Details | Diff
[NET] link_watch: Always schedule urgent events (4.45 KB, patch)
2008-01-15 18:47 EST, Herbert Xu
no flags Details | Diff

  None (edit)
Description Ian Campbell 2007-08-09 11:30:35 EDT
After migration the Xen netfront sends a gratuitous ARP to cause arp caches to
get refreshed and minimise network downtime.

Unfortunately carrier detect is delayed in the kernel (up to a minute?) so the
ARP is either dropped meaning there is a network blackout until the ARP caches
expire or the guest generates an ARP for some other reason.

This was fixed in the upstream Xen kernel by

Or in the upstream mainline kernel by
Comment 1 Ian Campbell 2007-12-14 04:31:30 EST
Created attachment 288931 [details]
xen-unstable 13763:8132bf3ddbef ported to 2.6.18-53.el5
Comment 2 Ian Campbell 2007-12-14 04:32:02 EST
Created attachment 288941 [details]
xen-unstable 14280:42b29f084c31 ported to 2.6.18-53.el5
Comment 3 Herbert Xu 2008-01-15 18:47:29 EST
Created attachment 291769 [details]
[NET] link_watch: Always schedule urgent events

I have rolled up the commits d9568ba91b1fdd1ea4fdbf9fcc76b867cca6c1d5 and
db0ccffed91e234cad99a35f07d5a322f410baa2 into one and backported it to RHEL5.
Comment 4 Bill Burns 2008-01-23 14:41:12 EST
Assigning and setting flags.
Comment 6 Rob Kenna 2008-01-23 15:06:50 EST
Causing problems with at least one customer configuration where they are
performing failback in clustered configuration.  Would like this in 5.2.

"This is really killing us because it makes zero-downtime failback
impossible - we are seeing 30-60s loss of connectivity until the ARP
cache expires."
Comment 7 Nick Strugnell 2008-01-24 05:34:51 EST
This needs a matching bug for 4.6 as we are seeing it in 4.6 DomUs

Comment 8 Don Dutile 2008-01-24 10:07:03 EST

BZ 429930 is the rhel4 clone of this bug, and I've attached the rhel4
equiv. patch for it.

We're in the process of doing live migration testing of rhel5.2-ish & 
rhel4.7-ish kernel with the respective patches.  once verified, i'll
post the rhel4 patch (for 4.7). 
if needed for 4.6.z, pls raise flags for that additional effort.

- Don
Comment 9 Don Zickus 2008-01-24 11:08:51 EST
in 2.6.18-74.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5
Comment 11 Jakub Suchy 2008-02-06 11:35:05 EST
We (our customer) have just tested updated kernels and can't confirm that this
issue is fixed. Network blackout is shorter, about 15 sec (comparing to 1-3
minutes before updating the kernel), but we expect it to be much more shorter (1
Comment 21 errata-xmlrpc 2008-05-21 10:49:11 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.