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

Bug#592780: linux-image-2.6.32-5-amd64: pv-ops DomU kernel doesn't forward network traffic



On Thu, 2010-08-12 at 21:50 +0200, Bastian Blank wrote:
> tags 592780 moreinfo
> thanks
> 
> On Thu, Aug 12, 2010 at 03:30:32PM -0300, Sebastián Cruz wrote:
> > Everything went fine until we tried to configure an OpenVPN server on a DomU. We found out that forwarding traffic was not working. We tried hard to debug the problem (tcpdump, wireshark, etc) and packets reached the DomU but they never left.
> 
> Works here. This needs more information.

Just for the record, I made the bug report on a squeeze DomU (oxigeno)
running on a squeeze Dom0 (carbono), which is neither the DomU where the
OpenVPN stuff happened nor the testing DomU we used to investigate
later. Though it's the same kind of DomU and the testing machine doesn't
exist any more. I did it there just in case reportbug collected some
useful info from the running kernel.

Also notice that as we do not forward on oxigeno we haven't changed it
to -xen.

We've been dealing with this for the past 3 months approximately, so not
everything is fresh in my mind.

> - kernel on the dom0

Using xen-hypervisor-4.0-amd64 and linux-image-2.6.32-5-amd64 on it.

root carbono ~ # xm info 
host                   : carbono
release                : 2.6.32-5-xen-amd64
version                : #1 SMP Sat Jul 24 04:03:11 UTC 2010
machine                : x86_64
nr_cpus                : 2
nr_nodes               : 1
cores_per_socket       : 2
threads_per_core       : 1
cpu_mhz                : 2982
hw_caps                :
bfebfbff:20100800:00000000:00000940:0008e3fd:00000000:00000001:00000000
virt_caps              : hvm
total_memory           : 8181
free_memory            : 668
node_to_cpu            : node0:0-1
node_to_memory         : node0:668
node_to_dma32_mem      : node0:668
max_node_id            : 0
xen_major              : 4
xen_minor              : 0
xen_extra              : .1-rc3
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
hvm-3.0-x86_32p hvm-3.0-x86_64 
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : unavailable
xen_commandline        : dom0_mem=768M
cc_compiler            : gcc version 4.4.4 (Debian 4.4.4-5) 
cc_compile_by          : waldi
cc_compile_domain      : debian.org
cc_compile_date        : Wed Jun 30 14:32:51 UTC 2010
xend_config_format     : 4

> - checksum-offloading settings.

On the Dom0 eth0 is the interface shared with the DomUs. There two other
NICs connected to an iSCSI server. I'm pretty sure I tried to change the
checksumming on the Dom0 during the investigation, but can't be more
precise now.

Dom0:
root carbono ~ # ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off
ntuple-filters: off
receive-hashing: off

DomU:
root oxigeno ~ # ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: off
large-receive-offload: off
ntuple-filters: off
receive-hashing: off

> - debugging output of openvpn.

I think OpenVPN has nothing to do with it. I only mentioned it
anecdotally. We tested the scenario doing a simple NAT on a freshly
installed DomU and the problem was as described earlier.

> - capture (tshark, wireshark, tcpdump) of the "any" pseudo-device of the
>   domain running openvpn.

Let me recreate a testing machine and I'll gather these, give me some
time.

> > root=/dev/xvda2 ro root=/dev/xvda2 ro ip=:127.0.255.255::::eth0:dhcp 
> 
> None of the kernels have ip config included.

Your comment made me look closer at this and we do not have this
explicitly stated on any of our DomUs. Anyway I found out that on 3 of
our 4 Dom0 every DomU running there has the "ip=" parmeter on
its /proc/cmdline. We even have some like this:
"ip=:1.2.3.4::::eth0:dhcp".

I thought about pygrub, but some of them use it and some don't. So it
can't be that.

On the DomU:
root oxigeno ~ # cat /boot/grub/menu.lst |grep vmlinuz-2.6.32-5-amd64
kernel          /boot/vmlinuz-2.6.32-5-amd64 root=/dev/xvda2 ro 

On the Dom0:
root carbono ~ # cat /etc/xen/oxigeno.cfg 
#
# Configuration file for the Xen instance xen-oxigeno, created
# by xen-tools 3.9 on Wed Nov 25 12:45:03 2009.
#

#
#  Kernel + memory size
#
bootloader   = '/usr/lib/xen-default/bin/pygrub'
memory      = '1024'
vcpus       = '2'
#
#  Disk device(s).
#
root        = '/dev/xvda2 ro'
disk        = [
                  'phy:/dev/gw/xen-oxigeno-disk,xvda2,w',
                  'phy:/dev/gw/xen-oxigeno-swap,xvda1,w',
                  'phy:/dev/gw/archlinux-repo-lv,xvda3,w',
                  'phy:/dev/gw/apt-cache-lv,xvda4,w',
                  'phy:/dev/gw/cy-lv,xvda5,w',
                  'phy:/dev/gw/gis-lv,xvda6,w',
                  'phy:/dev/gw/samba-lv,xvda7,w',
                  'phy:/dev/gw/disk-images-lv,xvda8,w',
              ]


#
#  Hostname
#
name        = 'oxigeno'

#
#  Networking
#
dhcp        = 'dhcp'
vif         = [ 'mac=00:16:3E:B1:9B:6E' ]

#
#  Behaviour
#
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

> > auto eth0:1
> > iface eth0:1 inet static
> 
> Interface aliases are discuraged.

You can safely ignore this. oxigeno it's the only DomU we have with
aliasing. The test machine and the one where it started with the OpenVPN
thing only had one interface, assigned by DHCP and without any strange
stuff.

-- 
Sebastián Cruz
default50@gmail.com
GPG FP: 5D35 54C4 ABA7 DED9 133F 5272 04F7 13E3 B03D 64C4

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: