[ovs-discuss] Error while using ct commands in conntrack+ovs

[Akshaya Mahadik]

I tried using kernal 4.3.0 but it still gives the same error!
Can u tell me proper kernal that have an OVS module with conntrack support
On Jun 9, 2016 9:57 PM, "Ben Pfaff" <blp at ovn.org> wrote:

> On Thu, Jun 09, 2016 at 06:07:43PM +0530, Akshaya Mahadik wrote:
> > Hi
> > I am new to ovs and recently was working with conntrack and i got this
> error
> >
> >  ovs-ofctl add-flow mybridge \ "table=71,
> >
> priority=65,ct_state=-trk,ip,reg5=0x1,in_port=1,dl_src=fa:16:3e:a4:22:10,nw_src=192.168.0.1
> > actions=ct(table=72,zone=NXM_NX_REG6[0..15])"
> > OFPT_ERROR (xid=0x6): OFPBMC_BAD_MASK
> > NXT_FLOW_MOD (xid=0x6):
> > (***truncated to 64 bytes from 128***)
> > 00000000  01 04 00 80 00 00 00 06-00 00 23 20 00 00 00 0d |..........#
> ....|
> > 00000010  00 00 00 00 00 00 00 00-47 00 00 00 00 00 00 41
> |........G......A|
> > 00000020  ff ff ff ff ff ff 00 00-00 32 00 00 00 00 00 00
> |.........2......|
> > 00000030  00 00 00 02 00 01 00 00-04 06 fa 16 3e a4 22 10
> |............>.".|
> >
> > Can u plz help with this
> > ovs=2.5.0
> > conntract=1.4.3
> > kernal=3.18
>
> It seems likely that the kernel you're using doesn't have an OVS module
> with conntrack support.
>
> ### Q: Are all features available with all datapaths?
>
> A: Open vSwitch supports different datapaths on different platforms.  Each
>    datapath has a different feature set: the following tables try to
> summarize
>    the status.
>
>    Supported datapaths:
>
>    * *Linux upstream*: The datapath implemented by the kernel module
> shipped
>                        with Linux upstream.  Since features have been
> gradually
>                        introduced into the kernel, the table mentions the
> first
>                        Linux release whose OVS module supports the feature.
>
>    * *Linux OVS tree*: The datapath implemented by the Linux kernel module
>                        distributed with the OVS source tree.
>
>    * *Userspace*: Also known as DPDK, dpif-netdev or dummy datapath. It is
> the
>                   only datapath that works on NetBSD, FreeBSD and Mac OSX.
>
>    * *Hyper-V*: Also known as the Windows datapath.
>
>    The following table lists the datapath supported features from
>    an Open vSwitch user's perspective.
>
> Feature               | Linux upstream | Linux OVS tree | Userspace |
> Hyper-V |
>
> ----------------------|:--------------:|:--------------:|:---------:|:-------:|
> NAT                   |      4.6       |       NO       |    NO     |
>  NO    |
> Connection tracking   |      4.3       |       YES      |    NO     |
> PARTIAL |
> Tunnel - LISP         |      NO        |       YES      |    NO     |
>  NO    |
> Tunnel - STT          |      NO        |       YES      |    NO     |
>  YES   |
> Tunnel - GRE          |      3.11      |       YES      |    YES    |
>  YES   |
> Tunnel - VXLAN        |      3.12      |       YES      |    YES    |
>  YES   |
> Tunnel - Geneve       |      3.18      |       YES      |    YES    |
>  NO    |
> QoS - Policing        |      YES       |       YES      |    NO     |
>  NO    |
> QoS - Shaping         |      YES       |       YES      |    NO     |
>  NO    |
> sFlow                 |      YES       |       YES      |    YES    |
>  NO    |
> IPFIX                 |      3.10      |       YES      |    YES    |
>  NO    |
> Set action            |      YES       |       YES      |    YES    |
> PARTIAL |
> NIC Bonding           |      YES       |       YES      |    YES    |
>  NO    |
> Multiple VTEPs        |      YES       |       YES      |    YES    |
>  NO    |
>
>    **Notes:**
>    * Only a limited set of flow fields is modifiable via the set action by
> the
>      Hyper-V datapath.
>    * The Hyper-V datapath only supports one physical NIC per datapath.
> This is
>      why bonding is not supported.
>    * The Hyper-V datapath can have at most one IP address configured as a
>      tunnel endpoint.
>
>    The following table lists features that do not *directly* impact an
>    Open vSwitch user, e.g. because their absence can be hidden by the
> ofproto
>    layer (usually this comes with a performance penalty).
>
> Feature               | Linux upstream | Linux OVS tree | Userspace |
> Hyper-V |
>
> ----------------------|:--------------:|:--------------:|:---------:|:-------:|
> SCTP flows            |      3.12      |       YES      |    YES    |
>  YES   |
> MPLS                  |      3.19      |       YES      |    YES    |
>  YES   |
> UFID                  |      4.0       |       YES      |    YES    |
>  NO    |
> Megaflows             |      3.12      |       YES      |    YES    |
>  NO    |
> Masked set action     |      4.0       |       YES      |    YES    |
>  NO    |
> Recirculation         |      3.19      |       YES      |    YES    |
>  YES   |
> TCP flags matching    |      3.13      |       YES      |    YES    |
>  NO    |
> Validate flow actions |      YES       |       YES      |    N/A    |
>  NO    |
> Multiple datapaths    |      YES       |       YES      |    YES    |
>  NO    |
> Tunnel TSO - STT      |      N/A       |       YES      |    NO     |
>  YES   |
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20160610/7403c397/attachment-0002.html>