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

[Xen-users] VM bridge doesn't pass traffic



Hey guys,

I've got a really strange issue with the networking on Debian 8.2 with
Xen 4.4, probably particularly regarding the network bridge between the
host machine and the vm.
I recently set up a server cluster consisting of two Debian Jessie
servers in a pretty basic configuration with Xen 4.4 from the official
repositories. I then configured corosync, pacemaker and DRBD to sync a
root partition between the two nodes and installed a Debian Jessie VM on
the master node.
Everything worked fine so far, but when I wanted to start configuring
the vm two days ago, I found that though the eth0 interface was up and
running a correctly configured IP the vm didn't have any access to the
network.
I then proceeded to check every possible thing I could think of and am
now at my wit's end.
The bridge is brought up by the default vif-bridge script and running,
as brctl shows:

bridge name     bridge id               STP enabled     interfaces
xenbr0          8000.0cc47a781e22       no              eth0
                                                        vif1.0

The required iptables rules are correctly generated:

Chain INPUT (policy ACCEPT 22281 packets, 3522K bytes)
 pkts bytes target     prot opt in     out     source
destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source
destination
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0
0.0.0.0/0            PHYSDEV match --physdev-out vif1.0 --physdev-is-bridged
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0
0.0.0.0/0            PHYSDEV match --physdev-in vif1.0 --physdev-is-bridged

Chain OUTPUT (policy ACCEPT 18929 packets, 3285K bytes)
 pkts bytes target     prot opt in     out     source
destination

Strangely, the vif interface is shown as DOWN in ip a on the dom0:

5: vif1.0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master
xenbr0 state DOWN group default qlen 32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff

And dmesg in the vm shows this error:

xenbus_probe_frontend: Device with no driver: device/vif/0

What's confusing me is that the interface is online and UP in the vm:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
group default qlen 1000
    link/ether 00:16:3e:c2:91:71 brd ff:ff:ff:ff:ff:ff
    inet 10.xx.xx.xxx/24 brd 10.41.16.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:fec2:9171/64 scope link
       valid_lft forever preferred_lft forever

But the IP is not reachable from the network and the vm won't get any
connection.
A tcpdump on from the dom0 on vif1.0 shows the following when trying to
ping the gateway from the vm:

20:26:11.653018 ARP, Request who-has 10.xx.xx.1 tell 10.xx.xx.xxx, length 28
20:26:12.651128 ARP, Request who-has 10.xx.xx.1 tell 10.xx.xx.xxx, length 28
20:26:13.651094 ARP, Request who-has 10.xx.xx.1 tell 10.xx.xx.xxx, length 28

While a tcpdump on xenbr0 shows nothing when pinging from the vm. When
pinging from an other machine though, similar entries show up in a
tcpdump on xenbr0 while nothing is shown on the vif interface:

20:27:53.216669 ARP, Request who-has 10.xx.xx.xxx tell 10.xx.xx.1, length 46
20:27:54.216676 ARP, Request who-has 10.xx.xx.xxx tell 10.xx.xx.1, length 46
20:27:55.216564 ARP, Request who-has 10.xx.xx.xxx tell 10.xx.xx.1, length 46

It seems to me that the bridge doesn't pass the traffic through to the vm.
Does anybody have an idea or experienced something similar?

Thanks in advance and kind regards,
  David Winterstein

Compositiv GmbH
Hammer Deich 30
20537 Hamburg
Tel: 040 / 609 4349 0
Fax: 040 / 609 4349 40

GeschÃftsfÃhrer Matthias Krawen
Amtsgericht Hamburg - HRB 122540

USt.-IdNr: DE282432834
Es gelten ausschlieÃlich unsere AGB.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users

 


Rackspace

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