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

William Tu u9012063 at gmail.com
Mon Mar 1 19:18:21 UTC 2021


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