[ovs-dev] native tunneling bug?

Jesse Gross jesse at nicira.com
Wed Sep 2 15:55:18 UTC 2015


On Wed, Sep 2, 2015 at 6:44 AM, Jesse Gross <jesse at nicira.com> wrote:
> On Tue, Sep 1, 2015 at 7:14 PM, Pravin Shelar <pshelar at nicira.com> wrote:
>> On Tue, Sep 1, 2015 at 4:56 PM, Ben Pfaff <blp at nicira.com> wrote:
>>> I think I've come across a bug in OVS native tunneling, or at any rate
>>> an important difference between Linux kernel and OVS native tunneling.
>>> In Linux kernel tunneling, a tunnel packet received by the kernel first
>>> passes through the kernel IP stack.  Among other things, the IP stack
>>> drops packets that are not destined to the current host.  It appears to
>>> me that the native tunneling code doesn't have any similar check,
>>> because I'm seeing it accept and packets flooded by the upstream switch
>>> that are not destined to an IP address of the host.  This means in
>>> effect that the user of native tunneling must set "options:local_ip",
>>> whereas a user of Linux kernel tunneling doesn't (and probably
>>> shouldn't).
>>>
>> Right. Its bug.
>>
>>> I suspect that this behavior is unintentional; it isn't mentioned in
>>> README-native-tunneling.md or (as far as I can tell) anywhere else.
>>>
>>> I noticed this while testing OVN.  If you configure a few hypervisors
>>> and send packets from only one of them, then the switch that connects
>>> them will flood all the packets to all of the rest (since it hasn't yet
>>> learned where they are).  The result is that for N hypervisors, remote
>>> VIFs get N-1 copies of the packets instead of just one.  I'm appending a
>>> patch that works around it, though I'd prefer to fix the tunneling code
>>> rather than apply this patch.
>>>
>> We can fix it adding the local ip-address to tnl-port-map.
>> I will send a patch.
>
> Presumably we also should use DMAC as well?

And I realized no VLAN tag as well (since if it is an access port, the
tag should be stripped off as already).

This is a larger point but there's a bunch of things that are missing
from a typical IP stack implementation. Some that I immediately see
are verifying the IP header checksum and checking the header length. I
guess there are probably others as well.



More information about the dev mailing list