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

[Guru Shetty]

ct_lb is tricky. I guess, the default should be to just pick the first
option.

On 30 November 2016 at 08:24, Ben Pfaff <blp at ovn.org> wrote:

> One initial, trivial, step might be to just have every ct_next respond
> that the flow is established.  Then at least it would be possible to see
> how packets flow through the system in the normal case.
>
> I noticed that you were getting DHCP-related errors from ovn-trace.  I
> have a patch out that fixes that:
>         https://patchwork.ozlabs.org/patch/685627/
> It hasn't attracted any reviews yet; I hope it does soon.
>
> On Wed, Nov 30, 2016 at 06:48:17AM +0000, Michael Kashin wrote:
> > 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?
> > >
> _______________________________________________
> discuss mailing list
> discuss at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20161130/fa0aa409/attachment.html>