I think it's very important not to make ovn-trace misleading. If my flow
fails due to ACL drop or misconfigured NAT and ovn-trace shows that
everything is fine, it'd make it pretty useless.

Ben,
Thanks for the patch. I'll give it a go.

On 1 December 2016 at 07:15, Ben Pfaff <b...@ovn.org> wrote:

> That seems like a reasonable way to start out.
>
> On Wed, Nov 30, 2016 at 08:40:27AM -0800, Guru Shetty wrote:
> > 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 <b...@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" <b...@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 <b...@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
> > > 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

Reply via email to