This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 245866 - /etc/xen/scripts/network-bridge cannot handle aliased addresses
/etc/xen/scripts/network-bridge cannot handle aliased addresses
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xen (Show other bugs)
5.0
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Berrange
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-27 00:00 EDT by Anchor Systems Managed Hosting
Modified: 2008-05-21 11:19 EDT (History)
4 users (show)

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


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

  None (edit)
Description Anchor Systems Managed Hosting 2007-06-27 00:00:31 EDT
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):

xen-3.0.3-25.0.3.el5

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 192.168.1.5/24 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 04:53:29 EDT
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@\([0-9]\+\.[0-9]\+\.[0-9]\+\.[0-9]\+/[0-9]\+\)@\1@
-s/${src}/dev ${dst}/
+s/${src}/dev ${dst} label ${dst}/
+s/secondary//
 " | sh -e
     # Remove automatic routes on destination device
     ip route list | sed -ne "
Comment 2 Anchor Systems Managed Hosting 2007-06-28 02:18:18 EDT
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
$netdev.vid@$pdev.

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-15 23:56:22 EDT
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
release.
Comment 5 Mark McLoughlin 2007-10-26 13:00:37 EDT
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-28 23:32:28 EDT
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 11:18:01 EST
Okay, patch submitted upstream:

  http://lists.xensource.com/archives/html/xen-devel/2008-01/msg00024.html

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:

  http://marc.info/?l=linux-netdev&m=119937651627280&w=2

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 05:37:10 EST
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
     just 
       $> cat > /etc/sysconfig/network-scripts/ifcfg-eth0:1 <<EOF
       IPADDR=foo
       ONPARENT=yes
       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 13:13:07 EST
Created attachment 291176 [details]
xen-netdev-alias.patch
Comment 11 Mark McLoughlin 2008-01-09 13:15:02 EST
Re-assigning to Dan to pull into the 5.2 Xen RPM
Comment 12 Daniel Berrange 2008-01-11 09:53:43 EST
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 11:19:44 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.

http://rhn.redhat.com/errata/RHBA-2008-0305.html

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