Open Stack

On 2023-06-27 15:02, Roberto Bartzen Acosta wrote:
>
>
> Em ter., 27 de jun. de 2023 às 15:22, Gary Molenkamp <molenkam at 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-namesystemctl 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).

E/W traffic looks good and each compute shows forwarding connections to 
the other compute.

Each compute has the proper external bridge mapped.  ie:

external_ids        : {hostname=compute05.cloud.sci.uwo.ca, 
ovn-bridge-mappings="provider:br-provider", 
ovn-cms-options=enable-chassis-as-gw, ovn-encap-ip="192.168.0.105", 
ovn-encap-type=geneve, ovn-remote="tcp:172.31.102.100:6642", 
rundir="/var/run/openvswitch", 
system-id="8e0fa17c-e480-4b60-9015-bd8833412561"}

Likewise all geneve tunnels between the compute nodes are established.





-- 
Gary Molenkamp			Science Technology Services
Systems Administrator		University of Western Ontario
molenkam at uwo.ca                  http://sts.sci.uwo.ca
(519) 661-2111 x86882		(519) 661-3566
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230628/331a4525/attachment-0001.htm>