| Message ID | 20210110021636.5892-1-iaccepted@163.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | [ovs-dev] tunnel:fix vlan bug for tunnel forwarding | expand |
On 1/10/21 3:16 AM, Hongzhi Guo wrote: > From: hongzhi guo <iaccepted@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@intel.com> > Fixes: 7c12dfc527a5 ("tunneling: Avoid datapath-recirc by combining recirc actions at xlate.") > > Signed-off-by: hongzhi guo <iaccepted@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)); > } > > /* >
On Mon, Mar 1, 2021 at 3:47 AM Ilya Maximets <i.maximets@ovn.org> wrote: > > On 1/10/21 3:16 AM, Hongzhi Guo wrote: > > From: hongzhi guo <iaccepted@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. > > >
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@gmail.com] Sent: 2/3/21 3:18 To: Ilya Maximets <i.maximets@ovn.org> Cc: Hongzhi Guo <iaccepted@163.com>; ovs-dev <ovs-dev@openvswitch.org>; Guohongzhi (Russell Lab) <guohongzhi1@huawei.com>; ALeX Wang <ee07b291@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@ovn.org> wrote: > > On 1/10/21 3:16 AM, Hongzhi Guo wrote: > > From: hongzhi guo <iaccepted@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. > > >
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)); } /*