On Tue, Oct 11, 2022 at 3:31 PM Dan Williams <[email protected]> wrote: > > On Fri, 2022-10-07 at 13:51 +0100, Brendan Doyle wrote: > > Hi Folks, > > > > Apologies if this is a dumb question I'm not too familiar with the > > what goes on between ovn-controller and the kernel OVS flows. > > > > So ovn-controller is control plane, the OVS flows it get pushed > > down to the kernel (the data plane). So I expected that if ovn- > > controller > > is stopped on a hypervisor that the dataplane flows would persist in > > the kernel. > > > > But what I see is if I have a VM on hypervisor A and a gateway on > > hypervisor B. If I stop ovn-controller on hypervisor A then I can > > no longer access the VM via the gateway. There is no Geneve > > traffic sent to hypervisor A. > > Stopping ovn-controller shouldn't flush OVS flows as reported by "ovs- > ofctl dump-flows br-int". And if the OVS flows don't get flushed I > wouldn't expect data plane flows to get flushed either.
Although the datapath flows would eventually expire if those flows are idle for 10 seconds (I think). Also when you stop ovn-controller either using systemd or using ovn-ctl stop_controller, before exiting it deletes all the tunnel interfaces from the "br-int". I'd presume this causes ovs-vswitchd revalidator thread to delete the datapath flows related to the tunnels. If you don't want ovn-controller do the cleanup, you can pass the option "--restart" while stopping ovn-controller - /usr/share/ovn/scripts/ovn-ctl stop_controller --restart This would also preserve the datapath flows until ovs-vswitchd revalidator thread expires them. Thanks Numan > There used to be an issue when the new ovn-controller started and > flushed some flows before it had completely downloaded the Southbound > DB but that's been fixed by: > > http://patchwork.ozlabs.org/project/ovn/list/?series=314426&archive=both&state=* > > What version of OVN are you running? Can you dump flows on br-int, then > stop ovn-controller, then dump flows again and compare? (use --no-stats > to make diffing easier). > > Dan > > > > > I guess as expected CENTRAL has taken hypervisor A out of the > > Southbound DB, regenerated flows and updated hypervisor B. > > I thought that the OVS flows might persist in the kernel in > > hypervisor A and CENTRAL would use the last known location of the > > VM and not regenerate flows and still tunnel from the gateway on B > > to A. But I guess not, but it does seem odd that the control plane > > going down breaks the data plane. > > > > Brendan. > > > > _______________________________________________ > > discuss mailing list > > [email protected] > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > > _______________________________________________ > discuss mailing list > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
