On 13/10/2022 02:35, Numan Siddique wrote:
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.
I can confirm that this works, but I assume that they will eventually
be expired after 10Min?
Is there a down side to doing this? why wouldn't it be the default behavior?
On Fri Dan Williams wrote:
Can you dump flows on br-int, then
stop ovn-controller, then dump flows again and compare?
When Not using --restart the flows on the gateway Hypervisor do
differ as follows:
< priority=100,in_port=13
actions=move:NXM_NX_TUN_ID[0..23]->OXM_OF_METADATA[0..23],move:NXM_NX_TUN_METADATA0[16..30]->NXM_NX_REG14[0..14],move:NXM_NX_TUN_METADATA0[0..15]->NXM_NX_REG15[0..15],resubmit(,38)
907d905
< cookie=0x2c437b7a, table=24, priority=50,arp,metadata=0x7,arp_tpa=10.10.1.3,arp_op=1
actions=move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],mod_dl_src:00:13:97:41:e4:e6,load:0x2->NXM_OF_ARP_OP[],move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],load:0x139741e4e6->NXM_NX_ARP_SHA[],move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],load:0xa0a0103->NXM_OF_ARP_SPA[],move:NXM_NX_REG14[]->NXM_NX_REG15[],load:0x1->NXM_NX_REG10[0],resubmit(,37)
1050,1053c1048,1049
< cookie=0x2a5722d6, table=37, priority=100,reg15=0x8000,metadata=0x7
actions=load:0x1->NXM_NX_REG15[],resubmit(,39),load:0x8000->NXM_NX_REG15[],load:0x7->NXM_NX_TUN_ID[0..23],set_field:0x8000->tun_metadata0,move:NXM_NX_REG14[0..14]->NXM_NX_TUN_METADATA0[16..30],output:13
< cookie=0xd5d9bb2a, table=37, priority=100,reg15=0x2,metadata=0x7
actions=load:0x7->NXM_NX_TUN_ID[0..23],set_field:0x2->tun_metadata0,move:NXM_NX_REG14[0..14]->NXM_NX_TUN_METADATA0[16..30],output:13
< cookie=0xf91f8de7, table=37, priority=100,reg15=0x8005,metadata=0x7
actions=load:0x7->NXM_NX_TUN_ID[0..23],set_field:0x8005->tun_metadata0,move:NXM_NX_REG14[0..14]->NXM_NX_TUN_METADATA0[16..30],output:13
< cookie=0xb8821ca4, table=37, priority=100,reg15=0x3,metadata=0x2
actions=load:0x2->NXM_NX_TUN_ID[0..23],set_field:0x3->tun_metadata0,move:NXM_NX_REG14[0..14]->NXM_NX_TUN_METADATA0[16..30],bundle(eth_src,0,active_backup,ofport,members:13,5)
---
cookie=0x2a5722d6, table=37, priority=100,reg15=0x8000,metadata=0x7
actions=load:0x1->NXM_NX_REG15[],resubmit(,39),load:0x8000->NXM_NX_REG15[]
cookie=0xb8821ca4, table=37, priority=100,reg15=0x3,metadata=0x2
actions=load:0x2->NXM_NX_TUN_ID[0..23],set_field:0x3->tun_metadata0,move:NXM_NX_REG14[0..14]->NXM_NX_TUN_METADATA0[16..30],bundle(eth_src,0,active_backup,ofport,members:5)
So I think it is clear that, the tunnel from it to the Hypervisor hosting
the VM is removed.
Thanks
Brendan
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:
https://urldefense.com/v3/__http://patchwork.ozlabs.org/project/ovn/list/?series=314426&archive=both&state=*__;Kg!!ACWV5N9M2RV99hQ!OO0VML3AwB4c_qqVYhpRDjgkwGQdUKbIogaUTAeXALWnGNVOt3O2HZsxzMP__-pymKVSDEztYKvjUbrE$
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://urldefense.com/v3/__https://mail.openvswitch.org/mailman/listinfo/ovs-discuss__;!!ACWV5N9M2RV99hQ!OO0VML3AwB4c_qqVYhpRDjgkwGQdUKbIogaUTAeXALWnGNVOt3O2HZsxzMP__-pymKVSDEztYGdQeh9A$
_______________________________________________
discuss mailing list
[email protected]
https://urldefense.com/v3/__https://mail.openvswitch.org/mailman/listinfo/ovs-discuss__;!!ACWV5N9M2RV99hQ!OO0VML3AwB4c_qqVYhpRDjgkwGQdUKbIogaUTAeXALWnGNVOt3O2HZsxzMP__-pymKVSDEztYGdQeh9A$
_______________________________________________
discuss mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
