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

Guohongzhi (Russell Lab) guohongzhi1 at huawei.com
Tue Mar 2 02:37:50 UTC 2021


The VLAN id of the inner packet is 2, and the VLAN id of the tunnel port is 3.
The result I expect should be that the packet can be forwarded from the VXLAN tunnel.
And the VXLAN packet received by the destination should be in the following format, the outer VLAN id is 3, and the inner VLAN id is 2.
Is there something wrong with my understanding?

Yesterday I tried kernel-mode of OVS2.12 and user-mode of OVS2.7,all of which did so.

Best regards,Hongzhi Guo.

-----Original Message-----
From: William Tu [mailto:u9012063 at gmail.com] 
Sent: 2/3/21 3:18
To: Ilya Maximets <i.maximets at ovn.org>
Cc: Hongzhi Guo <iaccepted at 163.com>; ovs-dev <ovs-dev at openvswitch.org>; Guohongzhi (Russell Lab) <guohongzhi1 at huawei.com>; ALeX Wang <ee07b291 at gmail.com>
Subject: Re: [PATCH] tunnel:fix vlan bug for tunnel forwarding

On Mon, Mar 1, 2021 at 3:47 AM Ilya Maximets <i.maximets at ovn.org> wrote:
>
> 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

Why is this an issue?
I looked at your setup, the inner packet has a VLAN id = 2, and you assign tunnel port to be VLAN id = 3, so it makes sens to drop the packet, right?

William
>
> 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.
>
> >


More information about the dev mailing list