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" <[email protected]> wrote:
>
> > On Tue, Nov 29, 2016 at 08:20:50PM -0800, Justin Pettit wrote:
> > >
> > > > On Nov 29, 2016, at 5:28 PM, Ben Pfaff <[email protected]> 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
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
