Hmm. You might be able to get more information about how the
datapath(incl. conntrack) is identifying the flow by turning up debug
logging in vswitchd (look for upcall and flow_put):

ovs-appctl vlog/set dpif:dbg

The conntrack tools can also be useful, although you'll need to filter
the output to only the relevant traffic:

conntrack -L

I see you're also using zones; removing those would reduce the problem space.

If it's still not clear, there's always the option to log some
messages in ovs_ct_execute() and trace the execution.

On 24 March 2015 at 09:03, John Hurley <[email protected]> wrote:
> Hi Joe,
>
>
> Following on from my earlier message, I have tested a few more scenarios.
> It seems that Conntrack works fine for UDP and ICMP packet flows.
> Earlier I had been testing with TCP traffic.
> This is still not working.
> Any ideas on why TCP would be failing on the conntrack commit?
>
> I have also noticed that if I replay UDP packets shorter than 64 bytes into
> OVS they are rejected by conntract and can cause the kernel panic issue.
> The NULL check on the nf_ct_is_confirmed() you mentioned earlier is required
> to prevent this from happening.
>
> John
>
>
> On Tue, Mar 24, 2015 at 9:56 AM, John Hurley <[email protected]>
> wrote:
>>
>> Hi Joe,
>>
>> Thanks for the response.
>> I have ensured the nf_conntrack_ipv4 module is loaded but still cannot get
>> the commit to work.
>>
>> I am running Ubuntu 14.04
>> Kernel version: 3.16.0-30-generic
>>
>> John
>>
>> On Mon, Mar 23, 2015 at 6:27 PM, Joe Stringer <[email protected]>
>> wrote:
>>>
>>> Hi John,
>>>
>>> I strongly suspect in this case, conntrack has been unable to identify
>>> the connection. There's two parts to this: Perhaps you need to load
>>> nf_conntrack_ipv4? if that module is not loaded, then conntrack cannot
>>> identify any IP traffic. Separately, to address the crash, the line
>>> with the nf_ct_is_confirmed() call likely needs to check if ct is
>>> non-NULL first.
>>>
>>> One useful datapoint is what kernel version/distro are you running?
>>> I've been testing on the latest net-next, although I should expect it
>>> work on anything back to linux-3.10. Perhaps earlier depending on the
>>> particular features required, YMMV.
>>>
>>> Apologies, there's a few bugs like this which I have found in local
>>> testing but I have not pushed the changes yet. This is in part because
>>> the ongoing development is against the linux tree, so I haven't
>>> backported the current development code to build inside the OVS tree.
>>>
>>> Without the commit, the nf_conntrack tables will not be populated.
>>>
>>> On 23 March 2015 at 09:49, John Hurley <[email protected]> wrote:
>>> > Hi,
>>> > I am interested in using Conntrack within OVS and have installed the
>>> > latest
>>> > version from the banch
>>> > (https://github.com/justinpettit/ovs/tree/conntrack).
>>> >
>>> > When I run an example mentioned in the tests:
>>> >
>>> > ovs-ofctl del-flows br0
>>> > ovs-ofctl add-flow br0 \
>>> >     "in_port=1,conn_state=-trk,tcp,action=ct(commit,zone=9),2"
>>> > ovs-ofctl add-flow br0 \
>>> >     "in_port=2,conn_state=-trk,tcp,action=ct(recirc,zone=9)"
>>> > ovs-ofctl add-flow br0 "in_port=2,conn_state=+trk+est-new,tcp,action=1"
>>> > ovs-ofctl add-flow br0
>>> > "in_port=2,conn_state=+trk-est+new,tcp,action=drop"
>>> > ovs-ofctl add-flow br0 priority=10,action=normal
>>> >
>>> > I am seeing a kernel panic for the 'commit' action.
>>> > I have traced this to the nf_ct_is_confirmed(ct) call on the
>>> > nf_conntrack
>>> > module.
>>> > If I edit the code to avoid this check I avoid the panic but am getting
>>> > an
>>> > error response from calls such as 'nf_ct_get(skb, &ctinfo)'.
>>> >
>>> > It appears that ovs-conntrack is not populating the nf_conntrack tables
>>> > for
>>> > me.
>>> > Is there any information on installing/running the ovs-conntrack branch
>>> > specifically or is there anything else that should be done on top of
>>> > the
>>> > standard OVS installation.
>>> > Doing an lsmod I can see both openvswitch and nf_conntrack modules
>>> > running.
>>> >
>>> > Thanks,
>>> >
>>> > John
>>> >
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > discuss mailing list
>>> > [email protected]
>>> > http://openvswitch.org/mailman/listinfo/discuss
>>> >
>>
>>
>
_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss

Reply via email to