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

Ilya Maximets i.maximets at ovn.org
Mon Mar 1 11:47:00 UTC 2021


On 1/10/21 3:16 AM, Hongzhi Guo wrote:
> 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

Hi.  I didn't look closely to the code yet, but since you have a test
scenario, could you, please, create a unit test in tests/tunnel.at for it?

Best regards, Ilya Maximets.

> 
> 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));
>  }
>  
>  /*
> 



More information about the dev mailing list