[ovs-discuss] [ovn] ovn-trace ct_actions not implemented

[Michael Kashin]

Sorry, replying to all now.

I'm doing POC testing on a miniature OpenStack environment with a single
controller and two compute nodes. I want to be able to examine lflows from
any node (usually its the controller) to see the end-to-end datapath,
including potential drops by ct ACLs, NAT and LB actions. Currently, as
I've said, I can only examine L2 flows.
I can definitely see a benefit in doing the live flow debugging from the
operational standpoint. However, in my case, simply providing ct metadata
as command line options would be more than enough.
Cheers,
Michael

On 30 Nov 2016 6:03 a.m., "Ben Pfaff" <blp at ovn.org> wrote:

> On Tue, Nov 29, 2016 at 08:20:50PM -0800, Justin Pettit wrote:
> >
> > > On Nov 29, 2016, at 5:28 PM, Ben Pfaff <blp at ovn.org> wrote:
> > >
> > > It's "not yet".  I'd like to implement them, but I'm not sure how to do
> > > it because connection-tracking state, for any given connection, is
> > > embedded in the kernel of some hypervisor, which may not be one that
> > > ovn-trace is running on (if ovn-trace is even running on a hypervisor).
> > >
> > > One option would be to supply connection-tracking metadata on the
> > > ovn-trace command line, e.g. something like --ct=est,rel or --ct=new.
> > > Then ct_next could simply set ct_state to the specified values.  This
> > > would allow testing given scenarios.
> >
> > What about using the existing conntrack entries by running "ovs-appctl
> > dpctl/dump-conntrack" by default?  That might be helpful for live
> > debugging and seems like a reasonable default.  It does seem like it
> > would be helpful to be able to specify values for testing what-if
> > scenarios, too.  I would imagine we'd need the ability to specify
> > multiple zones on the command-line in case a single flow crosses
> > multiple zones.
>
> I think our proposals cover two important special cases.
>
> Michael, what problem are you trying to solve?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20161130/2ab30796/attachment-0001.html>