Bug 245866 - /etc/xen/scripts/network-bridge cannot handle aliased addresses
Summary: /etc/xen/scripts/network-bridge cannot handle aliased addresses
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xen   
(Show other bugs)
Version: 5.0
Hardware: All Linux
Target Milestone: ---
: ---
Assignee: Daniel Berrange
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-06-27 04:00 UTC by Anchor Systems Managed Hosting
Modified: 2008-05-21 15:19 UTC (History)
4 users (show)

Fixed In Version: RHBA-2008-0305
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-21 15:19:44 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
xen-netdev-alias.patch (1.51 KB, patch)
2008-01-09 18:13 UTC, Mark McLoughlin
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2008:0305 normal SHIPPED_LIVE xen bug fix and enhancement update 2008-05-20 18:04:30 UTC

Description Anchor Systems Managed Hosting 2007-06-27 04:00:31 UTC
Description of problem:

When using bridged networking with Xen, the /etc/xen/scripts/network-bridge
script that is run doesn't handle aliased addresses on ${netdev} properly, and
thus leaves networking in a broken state.

Version-Release number of selected component (if applicable):


How reproducible:

Every time

Steps to Reproduce:
1. Add an aliased address on the network device that is to be bridged. E.g. with
the following:

ip addr add dev eth0 label eth0:00

2. Configure xen to use bridged networking by setting '(network-script
network-bridge)' in /etc/xen/xend-config.sxp
3. Start the xend service
Actual results:
The script attempts to add the aliased address to the physical device eth0:00
which is actually just the label, hence the 'ip addr add' command fails. The
simplistic regexes used don't account for aliases.

Expected results:
Aliased addresses should be correctly added to the virtual network device.

Additional info:
The bug is in the transfer_addrs() function around line 109.

Comment 1 Anchor Systems Managed Hosting 2007-06-27 08:53:29 UTC
The following patch seems to work:

--- network-bridge.orig 2007-06-27 18:51:52.000000000 +1000
+++ network-bridge      2007-06-27 18:52:15.000000000 +1000
@@ -109,7 +109,8 @@
     ip addr show dev ${src} | egrep '^ *inet ' | sed -e "
 s/inet/ip addr add/
-s/${src}/dev ${dst}/
+s/${src}/dev ${dst} label ${dst}/
 " | sh -e
     # Remove automatic routes on destination device
     ip route list | sed -ne "

Comment 2 Anchor Systems Managed Hosting 2007-06-28 06:18:18 UTC
VLAN interfaces also do not appear to work. They are not handled by the script
at all and hence when $netdev is renamed to $pdev, the vlan interfaces become

E.g. eth0.444@eth0 becomes eth0.444@peth0

when it should be recreated as eth0.444@eth0 (when eth0 is the virtual interface).

Comment 3 RHEL Product and Program Management 2007-10-16 03:56:22 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update

Comment 5 Mark McLoughlin 2007-10-26 17:00:37 UTC
The patch looks right to me and I've given it a small bit of testing and it does
what it says on the tin.

I'd like to get it upstream before including in RHEL 5.2, though.

reporter: do you want to submit the patch upstream to
xen-devel@lists.xensource.com or shall I?

Oh, and btw - the vlan issue is logged separately in bug #337651 if you want to
add your input there.

Comment 6 Anchor Systems Managed Hosting 2007-10-29 03:32:28 UTC
Mark, maybe it'd be best if you submit the patch since you probably have some
history with them. It is more likely to be accepted.

Comment 8 Mark McLoughlin 2008-01-03 16:18:01 UTC
Okay, patch submitted upstream:


The hold-up was that, in my testing, the alias label seemed to get changed so
that e.g. the alias would be "eth0:2" rather than "eth0:00" after network-bridge
was run. This turned out to be a kernel bug:


I don't think the kernel bug is that important, though - the important thing is
that the alias's address gets transfered.

Comment 9 Mark McLoughlin 2008-01-09 10:37:10 UTC
Fix has been accepted upstream for 3.2.0.

Easier steps to reproduce:

  1) Boot with kernel-xen, but with xend disabled
  2) Run system-config-network, then New->Ethernet->eth0->
     set IP->OK->Edit->Activate when parent starts->OK->Activate, or
       $> cat > /etc/sysconfig/network-scripts/ifcfg-eth0:1 <<EOF
  3) modprobe netloop
  4) /etc/xen/script/network-bridge start

Without the patch, network-bridge should fail with:

  Error: either "local" is duplicate, or "secondary" is a garbage.

With the patch, network-bridge should succeed and you should see that 
the eth0:1 device is still configured after it has run.

Comment 10 Mark McLoughlin 2008-01-09 18:13:07 UTC
Created attachment 291176 [details]

Comment 11 Mark McLoughlin 2008-01-09 18:15:02 UTC
Re-assigning to Dan to pull into the 5.2 Xen RPM

Comment 12 Daniel Berrange 2008-01-11 14:53:43 UTC
Fix built:

$ brew latest-pkg dist-5E-qu-candidate xen
Build                                     Tag                   Built by
----------------------------------------  --------------------  ----------------
xen-3.0.3-44.el5                          dist-5E-qu-candidate  berrange

* Fri Jan 11 2008 Daniel P. Berrange <berrange@redhat.com> - 3.0.3-44.el5
- Deal with network device aliases (rhbz#245866)

Comment 15 errata-xmlrpc 2008-05-21 15:19:44 UTC
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.