Em ter., 27 de jun. de 2023 às 15:22, Gary Molenkamp <molenkam@uwo.ca> escreveu:

Thanks for the pointers, itlooks like I'm starting to narrow it down. Something still confusing me, though.

I've built a Zed cloud, since upgraded to Antelope, using the Neutron
Manual install method here:
https://docs.openstack.org/neutron/latest/install/ovn/manual_install.html
I'm using a multi-tenent configuration using geneve and the flat
provider network is present on each hypervisor. Each hypervisor is
connected to the physical provider network, along with the tenent
network and is tagged as an external chassis under OVN.
         br-int exists, as does br-provider
         ovs-vsctl set open .
external-ids:ovn-cms-options=enable-chassis-as-gw

Any specific reason to enable gateway on compute nodes? Generally it's recommended to use controller/network nodes as gateway. What's your env(number of controllers, network, compute nodes)?

Wouldn't it be interesting to enable-chassis-as-gw on the compute nodes, just in case you want to use DVR: If that's the case, you need to map the external bridge (ovs-vsctl set open . external-ids:ovn-bridge-mappings=...) via ansible this is created automatically, but in the manual installation I didn't see any mention of it.

The problem is basically that the port of the OVN LRP may not be in the same chassis as the VM that failed (since the CR-LRP will be where the first VM of that network will be created). The suggestion is to remove the enable-chassis-as-gw from the compute nodes to allow the VM to forward traffic via tunneling/Geneve to the chassis where the LRP resides.

ovs-vsctl remove open . external-ids ovn-cms-options="enable-chassis-as-gw" ovs-vsctl remove open . external-ids ovn-bridge-mappings ip link set br-provider-name down ovs-vsctl del-br br-provider-name systemctl restart ovn-controller systemctl restart openvswitch-switch

How does one support both use-case types?

If I want to use DVR via each compute node, then I must create the br-provider bridge, set the chassis as a gateway and map the bridge. This seems to be breaking forwarding to the OVN LRP.    The hypervisor/VM with the working LRP works but any other hypervisor is not tunneling via Geneve.

https://docs.openstack.org/neutron/zed/ovn/faq/index.html

The E/W traffic is "completely distributed in all cases." for OVN driver... It is natively supported and should work via openflow / tunneling / Geneve without any issues.

The problem is that when you set the enable-chassis-as-gw flag you enable gateway router port scheduling for a chassis that may not have an external bridge mapped (and this breaks external traffic).

You can trace the traffic where the VM is and check where it is breaking via datapath command:

ovs-dpctl dump-flows

But if you are facing problems on east/west traffic, please check your OVN settings (example):

ovs-vsctl list open_vswitch

- external_ids : {ovn-encap-ip="192.168.200.10", ovn-encap-type="geneve", ovn-remote="tcp:192.168.200.200:6642"})

...and make sure geneve tunnels are established between all hypervisors (example):

root@comp1:~# ovs-vsctl show
Bridge br-int

....
Port ovn-2e4ed2-0
Interface ovn-2e4ed2-0
type: geneve
options: {csum="true", key=flow, remote_ip="192.168.200.11"}
Port ovn-fc7744-0
Interface ovn-fc7744-0
type: geneve
options: {csum="true", key=flow, remote_ip="192.168.200.30"}

Thanks as always, this is very informative.

Gary

-- 
Gary Molenkamp			Science Technology Services
Systems Administrator		University of Western Ontario
molenkam@uwo.ca                 http://sts.sci.uwo.ca
(519) 661-2111 x86882		(519) 661-3566