On 10/26/2018 10:26 AM, Gregory Rose wrote:
On 10/17/2018 6:06 AM, Yousong Zhou wrote:
On Wed, 17 Oct 2018 at 21:01, Yousong Zhou <[email protected]>
wrote:
...
ovs-vsctl add-port br0 tun0 -- set interface tun0 type=gre
options:remote_ip=flow options:key=flow options:packet_type=legacy_l2
ofport_request=2
Pasted the wrong line. packet_type=legacy_l3 works.
packet_type=legacy_l3 did not.
ovs-vsctl add-port br0 tun0 -- set interface tun0 type=gre
options:remote_ip=flow options:key=flow options:packet_type=legacy_l3
ofport_request=2
I also tried substitute type=gre with vxlan, stt, geneve, with
packet_type=legacy_l3 unchanged, they all just silently dropped the
traffic.
What is generating the layer 3 traffic? I looked at scapy but it
seems to insist on adding L2 Ethernet
headers and I haven't found a way around that.
Nevermind - I figured that out. This is a bug but I think it's a bug
only in the Linux kernel datapath because
OVS never sends the netlink message to set the netlink parm for
IFLA_GRE_COLLECT_METADATA.
Instead, the metadata flag is just set on creation and then that's it.
Even though the code explicitly
indicates that for metadata mode tunnels the type should be ARPHRD_NONE.
I think the userspace datapath would work but I haven't had time to
check it.
Thanks for finding this bug!! We appreciate it when someone takes the
time to help us out and find
problems in OVS.
I'll begin investigating a fix.
I'm working on the master branch which is OVS 2.10. The solution for
2.10 might not be the same for
the 2.8.4 release you're working with so it will probably take
additional backporting to fix that release.
But at least we know what the problem is.
Thanks again!
- Greg
Thanks,
- Greg
yousong
_______________________________________________
discuss mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
_______________________________________________
discuss mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
