On Tue, Jun 11, 2013 at 10:13:21AM +0900, Simon Horman wrote:
> Hi Ethan, Hi All,
>
> I have observed what appears to be a regression caused by
> 796223f5bc3a4896e6398733c798390158479400 ('netdev: Add new "struct
> netdev_rx" for capturing packets from a netdev.').
>
> In my test environment I am using Open vSwitch with the user-space
> datapath inside a KVM virtual machine. The virtual machine has a single
> bridge with two interfaces attached, eth0 and dummy0.
>
> dummy0 is (as its name suggests) a dummy interface.
>
> eth0 is a virtual ethernet interface the other end of which
> is a tap device in the host, tap0.
>
> In the host tap0 is attached to a (normal linux, not Open vSwtich)
> bridge and that bridge has a local IP address. I suspect that this
> is not relevant other than that the host can send packets to the virtual
> machine.
>
> The problem that I see is that when Open vSwtich receives a multicast
> packet, either IPv4 or IPv6, the packet seems to loop forever.
>
> I suspect that what is happening is that Open vSwtich receives the
> multicast packet, then floods it to all interfaces, however for some
> reason it then receives the packet again and thus a loop is established.
>
> It is not at all apparent to me why this problem is caused by
> the patch referred to above. However, I have tested it a number of
> times and feel confident that it is the case.
A little more information:
This problem seems to affect packets that are flooded.
For example ARP when using a rule that outputs to normal.
I am able to break the loops by inserting a rule with actions=drop,
matching on packets that are looping.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
