4

I am using Debian wheezy with XEN 4.1. I have two network bridges xenbr0 and xenbr1.

xenbr0 is linked to the real-eth0-nic so the domU's can talk to the outside world, which worked fine.

xenbr1 was intended as an internal network bridge for communication between domU's and dom0.

The Problem is the xenbr1 and I don't know why. The domU's are successfully connected to the xenbr1 because I can Ping between the domU's. So the bridge is working somehow, but no traffic to or from dom0's xenbr1 is possible.

My xenbr1 setup in /etc/network/interfaces:

auto xenbr1
iface xenbr1 inet static
        pre-up brctl addbr $IFACE
        up ip link set $IFACE up
        post-down brctl delbr $IFACE
        down ip link set $IFACE down
        address         10.0.0.1
        netmask         255.255.255.0
        hwaddress       ether MAC

brctl show:

bridge name     bridge id               STP enabled     interfaces
xenbr0          8000.mac                no              eth0
                                                        vif1.0
                                                        vif2.0
xenbr1          8000.mac                no              vif1.1
                                                        vif2.1

Network connections:

                  dom0
            xenbr1 - 10.0.0.1
            /               \
           /                 \
        domU-1              domU-2
  vif1.1 - 10.0.0.2      vif2.1 - 10.0.0.3

domU-1 can ping domU-2 and vice versa.
dom0 can not reach any domU and the domU's can not reach dom0. So something is blocked in dom0 I think.

My first thought was, that I maybe have a problem with iptables, but it seems that xen created the necessary rules:

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A FORWARD -m physdev --physdev-out vif2.1 --physdev-is-bridged -j ACCEPT
-A FORWARD -m physdev --physdev-in vif2.1 --physdev-is-bridged -j ACCEPT
-A FORWARD -m physdev --physdev-out vif2.0 --physdev-is-bridged -j ACCEPT
-A FORWARD -m physdev --physdev-in vif2.0 --physdev-is-bridged -j ACCEPT
-A FORWARD -m physdev --physdev-out vif1.1 --physdev-is-bridged -j ACCEPT
-A FORWARD -m physdev --physdev-in vif1.1 --physdev-is-bridged -j ACCEPT
-A FORWARD -m physdev --physdev-out vif1.0 --physdev-is-bridged -j ACCEPT
-A FORWARD -m physdev --physdev-in vif1.0 --physdev-is-bridged -j ACCEPT

I hope anyone can help me or has a start where to look.

Improve this question
1
  • Same problem. Did you solve it?
    – Wakan Tanka
    Apr 27, 2015 at 9:15

1 Answer 1

Reset to default
1

You need to connect dom0 to the xenbr1 bridge. Think of a bridge as an ethernet switch, you need to "plug" dom0 into it to work. You will notice that dom0 is connected to xenbr0 via eth0.

If you have an additional interface on the host(eth1), you can simply do:

brctl addif xenbr1 eth1

This should work provided the IP networking is properly configured.

Improve this answer
2
  • The bridge-device itselv resides in the Dom0 - so normally there should be no need to add more devices from the Dom0.
    – Nils
    Jun 9, 2013 at 21:05
  • Same problem as OP: On dom0 bridge is configured and domU interfaces are added to this bridge. On dom0 there is also dummy interface configured and added to this bridge. All IP are from same subnet. The domU machines are able to communicate between each other but unable to communicate with domU.
    – Wakan Tanka
    Apr 27, 2015 at 9:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .