Re: [ovs-discuss] GRE over IPv6 configuration
On 6/14/2019 11:06 AM, William Tu wrote: On Thu, Jun 13, 2019 at 9:44 AM Gregory Rose wrote: On 6/12/2019 2:47 PM, Gregory Rose wrote: On 6/12/2019 2:20 AM, Eli Britstein wrote: I started to code a support for upstream kernel. With this, the OVS port is created, as well as the netdev Linux device. I still don't have traffic, but I'm not sure it is not something else. Could you please have a look (and even better try?) still need to tidy up https://github.com/elibr-mellanox/linux/tree/ovs-ipv6-gre I'm going to copy William Tu on this. He has worked on the upstream drivers to enable ERSPAN, which runs over gre. William, Eli is trying to implement an ip6gre vport module for upstream. You can see his patches at the link above. I've never Hi Eli, I think the vport type is for compatibility code. see Pravin's feedback here https://www.spinics.net/lists/netdev/msg458250.html https://www.spinics.net/lists/netdev/msg458374.html We should add new type type using dpif-netlink-rtnl. thought about it before but it appears there is a gap between our out of tree ip6gre support and the upstream. Do you expect ip6gre to work on the upsream OVS right now or is this truly a gap? I think for newer kernel, OVS can use the upstream's ip6gre module. But I never tested after 4.20 kernel. ip6gre is definitely not working in the upstream kernel. I'm looking into it. I think Eli has stumbled onto a gap between our out of tree drivers and the upstream drivers. Thanks, - Greg ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] GRE over IPv6 configuration
On 6/14/2019 10:55 AM, Ben Pfaff wrote: On Wed, Jun 05, 2019 at 09:30:18AM -0700, Gregory Rose wrote: On 6/4/2019 11:38 AM, Ben Pfaff wrote: On Tue, Jun 04, 2019 at 06:08:00PM +, Eli Britstein wrote: On 6/4/2019 8:24 PM, Ben Pfaff wrote: On Tue, Jun 04, 2019 at 03:13:02PM +, Eli Britstein wrote: Hello, I would like to configure a GRE tunnel over IPv6, on a Linux system. However, I encounter the following: My command: ovs-vsctl add-port br1 gre6 -- set interface gre6 type=ip6gre options:remote_ip= 2001:db8:0:f102::11 options:key=55 Output: ovs-vsctl: Error detected while setting up 'gre6': could not add network device gre6 to ofproto (Address family not supported by protocol). See ovs-vswitchd log for details. ovs-vsctl: The default log directory is "/var/log/openvswitch". In the log: bridge|WARN|could not add network device gre6 to ofproto (Address family not supported by protocol) I notice that if I want to define a ip6gretap with “ip link”, there is a need to use “-6” option, to set the correct family. Is there a way to note the correct family (though I think should be implicit by “ip6gre”)? Or maybe some other configuration? OVS doesn't have an "ip6gre" interface type. Just use "gre". I see it does in lib/netdev-vport.c, line 1222. Isn't that ip6gre? Um, that's weird. We don't document it. I thought for sure that we tried to make our "regular" tunnels just accept both IPv4 and IPv6 addresses. Hmm, no documentation. Uh, that's not good. I'll check that. Did you get a chance to take a look? It would be good to improve the documentation. My apologies but no, not yet. I have this task flagged and will get to it sooner rather than later. Meanwhile, there seems to be a gap between out of tree OVS capabilities with ip6gre and what is upstream. I can document what our out of tree kernel drivers can do but will need to investigate further for what is going on with the upstream ip6 gre. Thanks, - Greg ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] GRE over IPv6 configuration
On Thu, Jun 13, 2019 at 9:44 AM Gregory Rose wrote: > > > > On 6/12/2019 2:47 PM, Gregory Rose wrote: > > > > On 6/12/2019 2:20 AM, Eli Britstein wrote: > >> > >> > >> I started to code a support for upstream kernel. With this, the OVS > >> port is created, as well as the netdev Linux device. I still don't > >> have traffic, but I'm not sure it is not something else. > >> > >> Could you please have a look (and even better try?) still need to tidy up > >> > >> https://github.com/elibr-mellanox/linux/tree/ovs-ipv6-gre > >> > >> > > > > I'm going to copy William Tu on this. He has worked on the upstream > drivers to enable ERSPAN, which runs over gre. > > William, > > Eli is trying to implement an ip6gre vport module for upstream. You can > see his patches at the link above. I've never Hi Eli, I think the vport type is for compatibility code. see Pravin's feedback here https://www.spinics.net/lists/netdev/msg458250.html https://www.spinics.net/lists/netdev/msg458374.html We should add new type type using dpif-netlink-rtnl. > thought about it before but it appears there is a gap between our out of > tree ip6gre support and the upstream. Do > you expect ip6gre to work on the upsream OVS right now or is this truly > a gap? I think for newer kernel, OVS can use the upstream's ip6gre module. But I never tested after 4.20 kernel. Regards, William > > Thanks, > > - Greg ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] GRE over IPv6 configuration
On Wed, Jun 05, 2019 at 09:30:18AM -0700, Gregory Rose wrote: > > On 6/4/2019 11:38 AM, Ben Pfaff wrote: > > On Tue, Jun 04, 2019 at 06:08:00PM +, Eli Britstein wrote: > > > On 6/4/2019 8:24 PM, Ben Pfaff wrote: > > > > On Tue, Jun 04, 2019 at 03:13:02PM +, Eli Britstein wrote: > > > > > Hello, > > > > > > > > > > I would like to configure a GRE tunnel over IPv6, on a Linux system. > > > > > However, I encounter the following: > > > > > > > > > > My command: > > > > > ovs-vsctl add-port br1 gre6 -- set interface gre6 type=ip6gre > > > > > options:remote_ip= 2001:db8:0:f102::11 options:key=55 > > > > > > > > > > Output: > > > > > ovs-vsctl: Error detected while setting up 'gre6': could not add > > > > > network > > > > > device gre6 to ofproto (Address family not supported by protocol). > > > > > See > > > > > ovs-vswitchd log for details. > > > > > ovs-vsctl: The default log directory is "/var/log/openvswitch". > > > > > > > > > > In the log: > > > > > bridge|WARN|could not add network device gre6 to ofproto (Address > > > > > family > > > > > not supported by protocol) > > > > > > > > > > I notice that if I want to define a ip6gretap with “ip link”, there > > > > > is a > > > > > need to use “-6” option, to set the correct family. > > > > > > > > > > Is there a way to note the correct family (though I think should be > > > > > implicit by “ip6gre”)? Or maybe some other configuration? > > > > OVS doesn't have an "ip6gre" interface type. Just use "gre". > > > I see it does in lib/netdev-vport.c, line 1222. Isn't that ip6gre? > > Um, that's weird. We don't document it. I thought for sure that we > > tried to make our "regular" tunnels just accept both IPv4 and IPv6 > > addresses. > > Hmm, no documentation. Uh, that's not good. I'll check that. Did you get a chance to take a look? It would be good to improve the documentation. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] datapath type problem
On Fri, Jun 14, 2019 at 04:48:48PM +0800, dx wrote: > Hi, > > I am using ovn and want to use load balance in my project, but I got the > ovn-controller log: > > OFPT_FLOW_MOD (OF1.3) (xid=0x510): ADD table:47 > priority=100,ip,reg0=0x4/0x4,metadata=0x1 cookie:0xe4805c93 > actions=ct(table=48,zone=NXM_NX_REG13[0..15],nat) > 2019-06-14T08:45:47.130Z|00028|ofctrl|INFO|OpenFlow error: OFPT_ERROR (OF1.3) > (xid=0x539): NXBMC_CT_DATAPATH_SUPPORT > OFPT_FLOW_MOD (OF1.3) (xid=0x539): ADD table:44 > priority=65535,ct_state=-new-est+rel-inv+trk,ct_label=0/0x1,metadata=0x1 > cookie:0xe524faae actions=resubmit(,45) > 2019-06-14T08:45:47.130Z|00029|ofctrl|INFO|OpenFlow error: OFPT_ERROR (OF1.3) > (xid=0x54f): NXBAC_CT_DATAPATH_SUPPORT > OFPT_FLOW_MOD (OF1.3) (xid=0x54f): ADD table:42 > priority=100,ip,reg0=0x1/0x1,metadata=0x1 cookie:0x2d432bd5 > actions=ct(table=43,zone=NXM_NX_REG13[0..15]) > 2019-06-14T08:45:47.133Z|00030|ofctrl|INFO|OpenFlow error: OFPT_ERROR (OF1.3) > (xid=0x581): NXBAC_CT_DATAPATH_SUPPORT > OFPT_FLOW_MOD (OF1.3) (xid=0x581): ADD table:13 > priority=100,ip,reg0=0x1/0x1,metadata=0x1 cookie:0x97892e43 > actions=ct(table=14,zone=NXM_NX_REG13[0..15]) > 2019-06-14T08:45:47.133Z|00031|ofctrl|INFO|OpenFlow error: OFPT_ERROR (OF1.3) > (xid=0x588): NXBAC_CT_DATAPATH_SUPPORT > OFPT_FLOW_MOD (OF1.3) (xid=0x588): ADD table:47 > priority=100,ipv6,reg0=0x4/0x4,metadata=0x1 cookie:0xe4805c93 > actions=ct(table=48,zone=NXM_NX_REG13[0..15],nat) > 2019-06-14T08:45:47.135Z|00032|ofctrl|INFO|OpenFlow error: OFPT_ERROR (OF1.3) > (xid=0x5b2): NXBAC_CT_DATAPATH_SUPPORT > OFPT_FLOW_MOD (OF1.3) (xid=0x5b2): ADD table:18 > priority=100,ipv6,reg0=0x4/0x4,metadata=0x1 cookie:0x527b9d58 > actions=ct(table=19,zone=NXM_NX_REG13[0..15],nat) > 2019-06-14T08:45:47.136Z|00033|ofctrl|INFO|OpenFlow error: OFPT_ERROR (OF1.3) > (xid=0x5ee): NXBMC_CT_DATAPATH_SUPPORT > OFPT_FLOW_MOD (OF1.3) (xid=0x5ee): ADD table:14 > priority=65535,ct_state=-new-est+rel-inv+trk,ct_label=0/0x1,metadata=0x1 > cookie:0x7355227c actions=resubmit(,15) > 2019-06-14T08:45:47.137Z|00034|ofctrl|INFO|OpenFlow error: OFPT_ERROR (OF1.3) > (xid=0x608): NXBMC_CT_DATAPATH_SUPPORT > OFPT_FLOW_MOD (OF1.3) (xid=0x608): ADD table:44 > priority=1,ct_state=-est+trk,ip,metadata=0x1 cookie:0xdc9d19b7 > actions=load:0x1->NXM_NX_XXREG0[97],resubmit(,45) > 2019-06-14T08:45:47.141Z|00035|ofctrl|INFO|OpenFlow error: OFPT_ERROR (OF1.3) > (xid=0x6ee): NXBMC_CT_DATAPATH_SUPPORT > > I find that the ovs seems to be not support feature below: > > 2019-06-14T08:14:01.639Z|00019|ofproto_dpif|INFO|system@ovs-system: Datapath > does not support check_pkt_len action > 2019-06-14T08:14:01.639Z|00020|ofproto_dpif|INFO|system@ovs-system: Datapath > does not support ct_state > 2019-06-14T08:14:01.639Z|00021|ofproto_dpif|INFO|system@ovs-system: Datapath > does not support ct_zone > 2019-06-14T08:14:01.639Z|00022|ofproto_dpif|INFO|system@ovs-system: Datapath > does not support ct_mark > 2019-06-14T08:14:01.639Z|00023|ofproto_dpif|INFO|system@ovs-system: Datapath > does not support ct_label > 2019-06-14T08:14:01.639Z|00024|ofproto_dpif|INFO|system@ovs-system: Datapath > does not support ct_state_nat > 2019-06-14T08:14:01.639Z|00025|ofproto_dpif|INFO|system@ovs-system: Datapath > does not support ct_orig_tuple > 2019-06-14T08:14:01.639Z|00026|ofproto_dpif|INFO|system@ovs-system: Datapath > does not support ct_orig_tuple6 > > After searched the official docs, I find that 'Linux OVS tree' datapath > support many feature. > > How can I use 'Linux OVS tree’ datapath? Does it help my issue? Probably you need to either upgrade your kernel or build and install a kernel module from the OVS tree. Read the OVS documentation for details. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] VxLAN in Userspace
On Thu, Jun 13, 2019 at 10:58:21PM -0400, Vasu Dasari wrote: > Flavio, > > tnl_neigh_cache_flush(), flushes entire tunnel ARP table. When a bridge is > removed, ARP entries learnt on that bridge alone have to be removed. > Entries from other bridges have to be in tact. > > I am thinking of doing the following: > > 1. Write a new API in lib/tnl-neigh-cache.c: tnl_neigh_flush(const char* > br_name) which purges all neighbor entries on bridge br_name. That's better, indeed. > 2. From ofproto/ofproto-dpif-xlate.c: xlate_xbridge_remove() invoke the > function tnl_neigh_flush () to flush the entries. > > til_neigh_xxx() functions are getting called from ofproto-dpif-xlate.c, and > hence thinking that xlate_xbridge_remove() is a right place to do the job. > > What do you think? The device with the IP address can be any regular interface, so do you think it would work if you remove a device that is out of OVS? fbl > > -Vasu > > > On Thu, Jun 13, 2019 at 7:27 PM Vasu Dasari wrote: > > > Yes Flavio. Looking at code to fix this. Will send fix for review soon. > > > > Vasu > > > > > On Jun 13, 2019, at 7:15 PM, Flavio Leitner wrote: > > > > > >> On Wed, Jun 12, 2019 at 07:18:27PM -0400, Vasu Dasari wrote: > > >> Thanks Ben. Meanwhile I think I found an bug in OVS 2.9.0 with stale ARP > > >> entries after a bridge is deleted. > > >> > > >> I ran my tunneling experiment successfully. Used mininet to simulate the > > >> environment. After quitting the mininet, switch s1 is deleted. But, I > > still > > >> see the ARP entries in OVS. > > > > > > Looks like when route_table_valid is false we also need to > > > call tnl_neigh_cache_flush() otherwise you will need to wait > > > the ARP entry in the cache to expire (15min?) which is quite > > > a long time. > > > > > > Do you think you can work on a patch? > > > > > >> root@mn1:~# ovs-vsctl show > > >> f6af5f1c-a11c-435f-9b03-7317f364ae48 > > >>Manager "ptcp:6640" > > >>ovs_version: "2.9.0" > > >> > > >> Even thought there is no s1, I still see entries here. > > >> root@mn1:~# ovs-appctl tnl/arp/show > > >> IPMAC Bridge > > >> > > == > > >> 172.168.1.1 02:42:ac:14:00:02 s1 > > >> 172.168.1.2 02:42:ac:14:00:03 s1 > > >> 10.0.0.10 82:ec:29:c0:bc:ef s1 > > >> 10.0.0.1 d2:54:11:f0:95:df s1 > > >> > > >> > > >> Just for completeness, this is what I had to do to fix my configuration. > > >> > > >> Figured out what was wrong with my configuration. > > >> > > >> Modify my bridge s1 to be: > > >> > > >> ovs-vsctl --may-exist add-br s1 \ > > >>-- set Bridge s1 datapath_type=netdev \ > > >>-- set bridge s1 fail-mode=standalone \ > > >> other_config:hwaddr=$(cat /sys/class/net/eth1/address) > > >> > > >> Add the flows: > > >> ovs-ofctl add-flow s1 "priority=1,in_port=s1-eth1 actions=vxlan" > > >> ovs-ofctl add-flow s1 "priority=1,in_port=vxlan actions=s1-eth1" > > >> ovs-ofctl add-flow s1 "priority=0 actions=NORMAL" > > >> > > >> ip addr add 1.1.1.1/24 dev s1 > > >> ip link set s1 up > > >> ip addr flush dev eth1 2>/dev/null > > >> ip link set eth1 up > > >> > > >> ovs-appctl tnl/arp/set s1 1.1.1.2 00:00:01:00:00:02 > > > > > > Yeah, that will replace the old entry with the new one. > > > > > > fbl > > > > > > > > >> > > >> *Vasu Dasari* > > >> > > >> > > >>> On Tue, Jun 11, 2019 at 6:22 PM Ben Pfaff wrote: > > >>> > > On Tue, Jun 11, 2019 at 03:17:24PM -0400, Vasu Dasari wrote: > > I am running into an issue which sounds pretty basic, probably I > > might be > > missing something. > > >>> > > >>> I think you're trying to use kernel tools to configure userspace > > >>> tunnels. Did you read Documentation/howto/userspace-tunneling.rst? > > >>> > > > > > >> ___ > > >> discuss mailing list > > >> disc...@openvswitch.org > > >> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > > > > > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Docker container connected by OVS+DPDK, `Ping` work but `iperf` NOT
Hello Ben, Thank you for your replay, I have already try to "up" the ports created by ovs-docker. However, things do not work as well. The configuration of the ovs-docker port is : 9f59092068994_l Link encap:Ethernet HWaddr 96:ec:de:eb:e3:f9 inet6 addr: fe80::94ec:deff:feeb:e3f9/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:1 errors:0 dropped:0 overruns:0 frame:0 TX packets:31 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:42 (42.0 B) TX bytes:4532 (4.5 KB) They are up. I have try to assign an IP address to it. iperf server still does not work. The problem is strange, for I have observed (using tcpdump in docker container) iperf request packets (tcp packets) arrived at the ovs-docker port, but the iperf server (application level) does not receive the packet. iperf server can receive iperf packets using "system". But When I change to "netdev" (for DPDK), iperf server cannot receive iperf packets. Best wishes, xia On Fri, Jun 14, 2019 at 1:54 AM Ben Pfaff wrote: > On Thu, Jun 13, 2019 at 12:33:40PM +0800, xia rui wrote: > > Hello, everyone. > > I am using OVS+DPDK to test the throughput of two docker containers. I > set > > up my platform as described in the following question in StackOverflow > (url: > > > https://stackoverflow.com/questions/56539216/docker-container-connected-by-ovsdpdk-ping-work-but-iperf-not > > ). > > > > There are two containers (box1, box2) and one OVS bridge (ovs-br1), which > > connects box1-eth1 and box2-eth1. > > > > I can ping from box1-eth1 to box2-eth2 using bridge ovs-br1. However, > iperf > > does not work. > > > > I have checked the packets sent by box1-eth1 has reached box2-eth1, and > the > > iperf server in box2 has no reaction. > > > > The detailed description in another question in StackOverflow (url: > > > https://stackoverflow.com/questions/56555930/interface-received-packets-iperf-application-does-not-get-packets-and-does-no > > ) > > The log that you quoted has a number of "network is down" messages for > the network devices. Maybe you need to bring them up e.g. with > "ifconfig $dev up". > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] datapath type problem
ovs version: # ovs-vsctl --version ovs-vsctl (Open vSwitch) 2.11.90 DB Schema 8.0.0 linux os: # cat /etc/redhat-release CentOS Linux release 7.6.1810 (Core) # uname -r 3.10.0-327.el7.x86_64 > > Hi, > > I am using ovn and want to use load balance in my project, but I got the > ovn-controller log: > > OFPT_FLOW_MOD (OF1.3) (xid=0x510): ADD table:47 > priority=100,ip,reg0=0x4/0x4,metadata=0x1 cookie:0xe4805c93 > actions=ct(table=48,zone=NXM_NX_REG13[0..15],nat) > 2019-06-14T08:45:47.130Z|00028|ofctrl|INFO|OpenFlow error: OFPT_ERROR (OF1.3) > (xid=0x539): NXBMC_CT_DATAPATH_SUPPORT > OFPT_FLOW_MOD (OF1.3) (xid=0x539): ADD table:44 > priority=65535,ct_state=-new-est+rel-inv+trk,ct_label=0/0x1,metadata=0x1 > cookie:0xe524faae actions=resubmit(,45) > 2019-06-14T08:45:47.130Z|00029|ofctrl|INFO|OpenFlow error: OFPT_ERROR (OF1.3) > (xid=0x54f): NXBAC_CT_DATAPATH_SUPPORT > OFPT_FLOW_MOD (OF1.3) (xid=0x54f): ADD table:42 > priority=100,ip,reg0=0x1/0x1,metadata=0x1 cookie:0x2d432bd5 > actions=ct(table=43,zone=NXM_NX_REG13[0..15]) > 2019-06-14T08:45:47.133Z|00030|ofctrl|INFO|OpenFlow error: OFPT_ERROR (OF1.3) > (xid=0x581): NXBAC_CT_DATAPATH_SUPPORT > OFPT_FLOW_MOD (OF1.3) (xid=0x581): ADD table:13 > priority=100,ip,reg0=0x1/0x1,metadata=0x1 cookie:0x97892e43 > actions=ct(table=14,zone=NXM_NX_REG13[0..15]) > 2019-06-14T08:45:47.133Z|00031|ofctrl|INFO|OpenFlow error: OFPT_ERROR (OF1.3) > (xid=0x588): NXBAC_CT_DATAPATH_SUPPORT > OFPT_FLOW_MOD (OF1.3) (xid=0x588): ADD table:47 > priority=100,ipv6,reg0=0x4/0x4,metadata=0x1 cookie:0xe4805c93 > actions=ct(table=48,zone=NXM_NX_REG13[0..15],nat) > 2019-06-14T08:45:47.135Z|00032|ofctrl|INFO|OpenFlow error: OFPT_ERROR (OF1.3) > (xid=0x5b2): NXBAC_CT_DATAPATH_SUPPORT > OFPT_FLOW_MOD (OF1.3) (xid=0x5b2): ADD table:18 > priority=100,ipv6,reg0=0x4/0x4,metadata=0x1 cookie:0x527b9d58 > actions=ct(table=19,zone=NXM_NX_REG13[0..15],nat) > 2019-06-14T08:45:47.136Z|00033|ofctrl|INFO|OpenFlow error: OFPT_ERROR (OF1.3) > (xid=0x5ee): NXBMC_CT_DATAPATH_SUPPORT > OFPT_FLOW_MOD (OF1.3) (xid=0x5ee): ADD table:14 > priority=65535,ct_state=-new-est+rel-inv+trk,ct_label=0/0x1,metadata=0x1 > cookie:0x7355227c actions=resubmit(,15) > 2019-06-14T08:45:47.137Z|00034|ofctrl|INFO|OpenFlow error: OFPT_ERROR (OF1.3) > (xid=0x608): NXBMC_CT_DATAPATH_SUPPORT > OFPT_FLOW_MOD (OF1.3) (xid=0x608): ADD table:44 > priority=1,ct_state=-est+trk,ip,metadata=0x1 cookie:0xdc9d19b7 > actions=load:0x1->NXM_NX_XXREG0[97],resubmit(,45) > 2019-06-14T08:45:47.141Z|00035|ofctrl|INFO|OpenFlow error: OFPT_ERROR (OF1.3) > (xid=0x6ee): NXBMC_CT_DATAPATH_SUPPORT > > I find that the ovs seems to be not support feature below: > > 2019-06-14T08:14:01.639Z|00019|ofproto_dpif|INFO|system@ovs-system: Datapath > does not support check_pkt_len action > 2019-06-14T08:14:01.639Z|00020|ofproto_dpif|INFO|system@ovs-system: Datapath > does not support ct_state > 2019-06-14T08:14:01.639Z|00021|ofproto_dpif|INFO|system@ovs-system: Datapath > does not support ct_zone > 2019-06-14T08:14:01.639Z|00022|ofproto_dpif|INFO|system@ovs-system: Datapath > does not support ct_mark > 2019-06-14T08:14:01.639Z|00023|ofproto_dpif|INFO|system@ovs-system: Datapath > does not support ct_label > 2019-06-14T08:14:01.639Z|00024|ofproto_dpif|INFO|system@ovs-system: Datapath > does not support ct_state_nat > 2019-06-14T08:14:01.639Z|00025|ofproto_dpif|INFO|system@ovs-system: Datapath > does not support ct_orig_tuple > 2019-06-14T08:14:01.639Z|00026|ofproto_dpif|INFO|system@ovs-system: Datapath > does not support ct_orig_tuple6 > > After searched the official docs, I find that 'Linux OVS tree' datapath > support many feature. > > How can I use 'Linux OVS tree’ datapath? Does it help my issue? > > Thanks ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] datapath type problem
Hi, I am using ovn and want to use load balance in my project, but I got the ovn-controller log: OFPT_FLOW_MOD (OF1.3) (xid=0x510): ADD table:47 priority=100,ip,reg0=0x4/0x4,metadata=0x1 cookie:0xe4805c93 actions=ct(table=48,zone=NXM_NX_REG13[0..15],nat) 2019-06-14T08:45:47.130Z|00028|ofctrl|INFO|OpenFlow error: OFPT_ERROR (OF1.3) (xid=0x539): NXBMC_CT_DATAPATH_SUPPORT OFPT_FLOW_MOD (OF1.3) (xid=0x539): ADD table:44 priority=65535,ct_state=-new-est+rel-inv+trk,ct_label=0/0x1,metadata=0x1 cookie:0xe524faae actions=resubmit(,45) 2019-06-14T08:45:47.130Z|00029|ofctrl|INFO|OpenFlow error: OFPT_ERROR (OF1.3) (xid=0x54f): NXBAC_CT_DATAPATH_SUPPORT OFPT_FLOW_MOD (OF1.3) (xid=0x54f): ADD table:42 priority=100,ip,reg0=0x1/0x1,metadata=0x1 cookie:0x2d432bd5 actions=ct(table=43,zone=NXM_NX_REG13[0..15]) 2019-06-14T08:45:47.133Z|00030|ofctrl|INFO|OpenFlow error: OFPT_ERROR (OF1.3) (xid=0x581): NXBAC_CT_DATAPATH_SUPPORT OFPT_FLOW_MOD (OF1.3) (xid=0x581): ADD table:13 priority=100,ip,reg0=0x1/0x1,metadata=0x1 cookie:0x97892e43 actions=ct(table=14,zone=NXM_NX_REG13[0..15]) 2019-06-14T08:45:47.133Z|00031|ofctrl|INFO|OpenFlow error: OFPT_ERROR (OF1.3) (xid=0x588): NXBAC_CT_DATAPATH_SUPPORT OFPT_FLOW_MOD (OF1.3) (xid=0x588): ADD table:47 priority=100,ipv6,reg0=0x4/0x4,metadata=0x1 cookie:0xe4805c93 actions=ct(table=48,zone=NXM_NX_REG13[0..15],nat) 2019-06-14T08:45:47.135Z|00032|ofctrl|INFO|OpenFlow error: OFPT_ERROR (OF1.3) (xid=0x5b2): NXBAC_CT_DATAPATH_SUPPORT OFPT_FLOW_MOD (OF1.3) (xid=0x5b2): ADD table:18 priority=100,ipv6,reg0=0x4/0x4,metadata=0x1 cookie:0x527b9d58 actions=ct(table=19,zone=NXM_NX_REG13[0..15],nat) 2019-06-14T08:45:47.136Z|00033|ofctrl|INFO|OpenFlow error: OFPT_ERROR (OF1.3) (xid=0x5ee): NXBMC_CT_DATAPATH_SUPPORT OFPT_FLOW_MOD (OF1.3) (xid=0x5ee): ADD table:14 priority=65535,ct_state=-new-est+rel-inv+trk,ct_label=0/0x1,metadata=0x1 cookie:0x7355227c actions=resubmit(,15) 2019-06-14T08:45:47.137Z|00034|ofctrl|INFO|OpenFlow error: OFPT_ERROR (OF1.3) (xid=0x608): NXBMC_CT_DATAPATH_SUPPORT OFPT_FLOW_MOD (OF1.3) (xid=0x608): ADD table:44 priority=1,ct_state=-est+trk,ip,metadata=0x1 cookie:0xdc9d19b7 actions=load:0x1->NXM_NX_XXREG0[97],resubmit(,45) 2019-06-14T08:45:47.141Z|00035|ofctrl|INFO|OpenFlow error: OFPT_ERROR (OF1.3) (xid=0x6ee): NXBMC_CT_DATAPATH_SUPPORT I find that the ovs seems to be not support feature below: 2019-06-14T08:14:01.639Z|00019|ofproto_dpif|INFO|system@ovs-system: Datapath does not support check_pkt_len action 2019-06-14T08:14:01.639Z|00020|ofproto_dpif|INFO|system@ovs-system: Datapath does not support ct_state 2019-06-14T08:14:01.639Z|00021|ofproto_dpif|INFO|system@ovs-system: Datapath does not support ct_zone 2019-06-14T08:14:01.639Z|00022|ofproto_dpif|INFO|system@ovs-system: Datapath does not support ct_mark 2019-06-14T08:14:01.639Z|00023|ofproto_dpif|INFO|system@ovs-system: Datapath does not support ct_label 2019-06-14T08:14:01.639Z|00024|ofproto_dpif|INFO|system@ovs-system: Datapath does not support ct_state_nat 2019-06-14T08:14:01.639Z|00025|ofproto_dpif|INFO|system@ovs-system: Datapath does not support ct_orig_tuple 2019-06-14T08:14:01.639Z|00026|ofproto_dpif|INFO|system@ovs-system: Datapath does not support ct_orig_tuple6 After searched the official docs, I find that 'Linux OVS tree' datapath support many feature. How can I use 'Linux OVS tree’ datapath? Does it help my issue? Thanks___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
