[ovs-dev] [PATCH] tunnel:fix vlan bug for tunnel forwarding

Guohongzhi (Russell Lab) guohongzhi1 at huawei.com
Mon Mar 1 01:38:31 UTC 2021


Hi, William and Ilya, please review this patch, thanks.

Best Regard.

-----Original Message-----
From: Hongzhi Guo [mailto:iaccepted at 163.com] 
Sent: 1/3/21 10:49 AM
To: ovs-dev at openvswitch.org
Cc: sugesh.chandran at intel.com; Guohongzhi (Russell Lab) <guohongzhi1 at huawei.com>; ee07b291 at gmail.com; aserdean at cloudbasesolutions.com; azhou at ovn.org; aatteka at nicira.com; iaccepted at 163.com
Subject: [PATCH] tunnel:fix vlan bug for tunnel forwarding

From: hongzhi guo <iaccepted at 163.com>

I found the basic vxlan topology cannot work when upgrade ovs 2.12 version.
Through debugging, I found that when the native tunnel forward, the inner vlan was used for forwarding mistakely.
Which resulted in packet loss on the tunnel_bearing port.

Then I abstracted the scene where the problem occurred.

Test:
|-----------|
|	br1     o br1(tag=2)
|--------p--|
         |br1-2(tag=2)
         |
         |                        ip = 10.10.10.22
         |br2-1(tag=2)           p3(tag=3)in namespace
|--------p--|                |--------o--|
|   br2     o                |   br3     |
|--------v--|                |-t---------|
        vxlan               tunnel_bearing(tag=3)
 (remote_ip=10.10.10.22)     (10.10.10.21)

Bridge br3
    datapath_type: netdev
    Port p3
        tag: 3
        Interface p3
            type: internal
    Port tunnel_bearing
        tag: 3
        Interface tunnel_bearing
            type: internal
    Port br3
        Interface br3
            type: internal
Bridge br2
    datapath_type: netdev
    Port br2
        Interface br2
            type: internal
    Port br2-1
        tag: 2
        Interface br2-1
            type: patch
            options: {peer=br1-2}
        Port vxlan
            Interface vxlan
                type: vxlan
                options: {remote_ip="10.10.10.22"} Bridge br1
    datapath_type: netdev
    Port br1
        tag: 2
        Interface br1
            type: internal
    Port br1-2
        tag: 2
        Interface br1-2
            type: patch
            options: {peer=br2-1}

Trace:
ovs-appctl ofproto/trace br1 in_port=br1,\
	dl_src=fa:16:3e:8c:eb:5b,dl_dst=fa:16:3e:a5:15:f3,\
	ip,nw_src=20.20.20.104,nw_dst=20.20.20.101,\
	nw_proto=6 -generate

Trace-result:
bridge("br1")
-------------
 0. priority 0
    NORMAL
     -> no learned MAC for destination, flooding

bridge("br2")
-------------
 0. priority 0
    NORMAL
     -> no learned MAC for destination, flooding
     -> output to native tunnel
     -> tunneling to 10.10.10.22 via tunnel_bearing
     -> tunneling from 96:2d:94:57:6a:55 10.10.10.21\
     	to c6:bc:3e:69:83:cc 10.10.10.22

bridge("br3")
-------------
 0. priority 0
    NORMAL
     >>>> dropping VLAN 2 tagged packet received on\
     port tunnel_bearing configured as VLAN 3 access port <<<<
     >> disallowed VLAN VID for this input port, dropping

CC: Sugesh Chandran <sugesh.chandran at intel.com>
Fixes: 7c12dfc527a5 ("tunneling: Avoid datapath-recirc by combining recirc actions at xlate.")

Signed-off-by: hongzhi guo <iaccepted at 163.com>
---
 ofproto/ofproto-dpif-xlate.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c index 7108c8a30..d03ccf91e 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -3546,6 +3546,7 @@ propagate_tunnel_data_to_flow__(struct flow *dst_flow,
         }
     }
     dst_flow->nw_proto = nw_proto;
+    memset(dst_flow->vlans, 0, sizeof(dst_flow->vlans));
 }
 
 /*
--
2.18.0.windows.1




More information about the dev mailing list