[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