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

[Xen-users] Re: XCP: Weird interface bonding problem



After fighting with this for a day, I found that a beta of XCP 1.0 was released. After installing it, the networking worked perfectly. I noticed that the beta does not use openvswitch per default, which was great for my purpose, as it allowed me to choose a better (layer3+4) load balancing algorithm.


~Adam


On Sat, Nov 27, 2010 at 8:44 PM, Adam Walters <abwalters@xxxxxxxxxxxx> wrote:
All,

I've been wrestling with an odd problem with interface bonding in XCP, and was hoping that someone on the mailing list had seen it and/or knew how to fix it. I have four interfaces in a bond, which is then VLANed out. My VMs are able to ping one another (if on the same host), the host they live on, but not anything outside of the host (including the switch the host is plugged in to). I can fix the connectivity problem if I use ovs-appctl to disable all but one of the slaves, but that sort of defeats the purpose of having the bond interface in the first place. Any MACs that hash out to a value for the active slave work just fine.

I've triple checked that the switch interfaces are configured identically. I have also tried putting the switchports into a LAG (I use a Dell 5324 switch), but the LAG actually took down all connectivity. The LAG was configured for Layer2 hashing only. All ports on the switch are forwarding in spanning-tree. Eventually, I want to split the interfaces across two switches, but I want to get it working on the switch I'm more familiar with first.

I can upload a bug report or any other information needed that will help. i'm running the current release of XCP, 0.5.

Thanks in advance for any help you can provide.

~Adam

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users

 


Rackspace

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