Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 213991 - xen networking doen't bring bridge up with xen 3.0.3
xen networking doen't bring bridge up with xen 3.0.3
Product: Fedora
Classification: Fedora
Component: xen (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Xen Maintainance List
Martin Jenner
Depends On:
  Show dependency treegraph
Reported: 2006-11-04 07:37 EST by Henning Schmiedehausen
Modified: 2008-02-26 18:38 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-26 18:38:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
dmesg of the xen host (15.62 KB, text/plain)
2006-11-04 07:39 EST, Henning Schmiedehausen
no flags Details
dmesg of the xen client (6.57 KB, text/plain)
2006-11-04 07:39 EST, Henning Schmiedehausen
no flags Details

  None (edit)
Description Henning Schmiedehausen 2006-11-04 07:37:52 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20060930 Fedora/ Firefox/

Description of problem:
After upgrading FC5 to the current versions of kernel and xen, the virtual hosts finally start again. However, the networking does not work. 

brctl show
xenbr0          8000.feffffffffff       no              peth3

if you run "ifconfig vif2.0 up", network starts working.

In the dmesg file of the host I found:

device vif2.0 entered promiscuous mode
audit(1162642195.512:11): dev=vif2.0 prom=256 old_prom=0 auid=4294967295
ADDRCONF(NETDEV_UP): vif2.0: link is not ready
xenbr0: port 3(vif2.0) entering disabled state

That seems to be the problem. 

Version-Release number of selected component (if applicable):
xen-3.0.3-1.fc5 kernel-2.6.18-1.2200.fc5 (xen0 and xenU)

How reproducible:

Steps to Reproduce:
1. update FC5 with all patches
2. start a xen client with bridged networking
3. look at dmesg

Actual Results:
networking does not work

Expected Results:
the bridge should pick up the topology changes (client interface coming up) and networking should work. It worked up to 2187

Additional info:
Set prio to high because this breaks existing xen installations.
Comment 1 Henning Schmiedehausen 2006-11-04 07:39:05 EST
Created attachment 140350 [details]
dmesg of the xen host
Comment 2 Henning Schmiedehausen 2006-11-04 07:39:38 EST
Created attachment 140351 [details]
dmesg of the xen client
Comment 3 Rene Cunningham 2007-01-08 00:54:59 EST
Do you have a network interface that uses a Broadcom chipset?

I too had the same problem and i had to upgrade the firmware for my broadcom NIC. 

See the following thread that describes the problem.


The following page (mywiki.ncsa.uiuc.edu was down at the time of writing this
comment, hence google cache) described how to upgrade the firmware.

IBM had a patch released for the broadcom chipset which fixed this error for me.
Comment 4 Henning Schmiedehausen 2007-01-08 02:44:07 EST
No, I'm using Intel EEPro 100 cards. Actually the problem was that the
networking config no longer detects reliably to which a card a bridge is
connected. Adding the mac addresses explicitly now works. In my
/etc/xen/auto/<host> I have

vif = [ "mac=00:16:3e:3e:05:af,bridge=xenbr0",
"mac=00:16:3e:3e:05:ae,bridge=xenbr1" ]

and that works well. Without the mac=<xxx> parameters it does not. 

Seems to be more of a documentation issue than a real bug.
Comment 5 Red Hat Bugzilla 2007-07-24 20:02:32 EDT
change QA contact
Comment 6 Chris Lalancette 2008-02-26 18:38:46 EST
This report targets FC6, which is now end-of-life.

Please re-test against Fedora 7 or later, and if the issue persists, open a new bug.


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