[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] xen 2.0, networking, bridging, and nfsroot

Isn't the misfeature you describe a function of the brctl utilities? Couldn't they be modified to add an option to 'brctl addif', eg 'inherit' so to make br0 inherit eth0's address you might use this syntax:
brctl addif br0 eth0 inherit
brctl could then internally do it this way:
1. create bridge br0
2. give br0 eth0's ip address
3. up br0
4. add eth0 to br0
5. remove address from eth0
but maybe the problem is that 3+4+5 need to be done in an atomic operation and there's no way to do that from userspace.
another solution which would maybe solve the nfsroot problem is to have the kernel configure a bridge at boot time via kernel parameters, eg bridge=br0,eth0 and then do everything on br0 from the start rather than starting with eth0 and moving to br0 at some later stage.
failing all of that, initrd might solve all the problems.
I think it would be incorrect to just always automatically add the ip address of an interface being added though.

From: Ian Pratt
Sent: Wed 11/08/2004 10:43 AM
To: brianw@xxxxxxxxxxxx; Adam Heath; xen-devel@xxxxxxxxxxxxxxxxxxxxx
Cc: Ian.Pratt@xxxxxxxxxxxx
Subject: Re: [Xen-devel] xen 2.0, networking, bridging, and nfsroot

> So, along comes 2.0.  It now uses a normal bridge to connect dom0 and domN.
> However, the bridge has a hole, where the network does not exist, while it
> copies the addresses from eth0 to br0, and changes all the routes.
> In nfsroot mode, this fails, as suddenly the network is inaccessible, so
> brctl(and friends) can no longer be found.

It's an unfortunate mis-feature of the Linux bridge code that
when adding an interface to the bridge it doesn't inherit the IP
addresses associated with the interface: As I recall, one of
either tx or rx breaks, but the other direction is OK.

I presume 2.6 exhibits the same behaviour? 

We've tried to work around this in the /etc/xen/network script,
but it's certainly a problem for nfsroot dom0 systems. 

One option is to come up with a patch to the linux bridge code to
'fix' the current arguably broken behaviour. It would be
interesting to take this up with the bridge code maintainer. Any

The other alternative is to route rather than bridge VIF's onto
the real network. We've supplied example scripts for bridging,
but it would be good to include example scripts for a routed
setup too. 

Just edit the network-script and vif-script parameters in
/etc/xen/xend-config.sxp to point at a pair of new scripts.

I've had routed setups working just fine. The only slight
annoyance is that I had to configure a dummy IP address for the
backend (vifX.Y) interfaces to point routes through. I was hoping
to set them up as explicit point-to-point links and avoid this,
but ifconfig wouldn't let me. Perhaps there's some device flag
that our backend driver should be setting to allow this? If so, a
patch for this would be great.


SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.