[Pkg-xen-devel] Bug#679533: Bug#679533: Traffic forwarding issue between Xen domU/dom0 and ovs

[Hans van Kranenburg]

On 07/25/2012 01:13 PM, Ian Campbell wrote:
> On Tue, 2012-07-17 at 19:05 +0200, Hans van Kranenburg wrote:
>> On 07/10/2012 08:16 PM, Ian Campbell wrote:
>>> On Fri, 2012-06-29 at 16:06 +0200, Hans van Kranenburg wrote:
>>>> We're seeing weird behaviour regarding network traffic between a Xen
>>>> dom0 and domU. I reported this issue yesterday to the
>>>> openvswitch-discuss mailing list, but it seems this could also be a
>>>> (regression?) bug in the xen hypervisor or the linux kernel...
>>>
>>> Did you get any response from the vswitch folks?
>>
>> The response from Ben Pfaff (nicira/openvswitch) was like: "I wish I had
>> something to suggest, but this seems like a truly bizarre problem."
>
> That's basically what I was thinking too.

I really hate the fact I haven't been able to reproduce the situation 
again...

> I've had a trawl through the upstream netback fixes and although there
> are one or two which sound like they might be relevant none of them are
> actually relevant to the version of netback in Squeeze. Likewise for the
> netfront driver.
>
> Is the traffic all on-box or is it off box (and does it make a
> difference?). There might be some similarities with
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631102

No difference.

The line "It's possible to "revive" the DomU for a short while by 
getting a console with xm on Dom0 and then sending pings to the Dom0 and 
other hosts." from 631102 very much looks like my report, and that's why 
I first thought it could be an arp/mac-address issue, but while seeing 
the arp requests not being answered but being present on the dom0-part 
of the virtual interface I got confused. Anyway, repeating myself now.

Aditionally, it might be worth noting that the issue didn't affect all 
virtual network interfaces in the domU. I could login over a different 
interface just fine and from there generate traffic to the outside of 
the domU.

> [...]
>> ...the first thing to do would be to reproduce this using the exact
>> software/hardware situation it originated in, and that seems to be quite
>> a challenge already...
>
> Right, I'm not sure what else can be done I'm afraid, I'm rather
> perplexed :-/

I'll try again, using a test-system that can be left in a broken state 
for research if I manage to break it.

-- 
Hans van Kranenburg - System / Network Engineer
+31 (0)10 2760434 | hans.van.kranenburg at mendix.com | www.mendix.com