Open Stack

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-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 at 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 Ontariomolenkam at uwo.ca                 http://sts.sci.uwo.ca
> (519) 661-2111 x86882		(519) 661-3566
>
>

-- 




_‘Esta mensagem é direcionada apenas para os endereços constantes no 
cabeçalho inicial. Se você não está listado nos endereços constantes no 
cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa 
mensagem e cuja cópia, encaminhamento e/ou execução das ações citadas estão 
imediatamente anuladas e proibidas’._


* **‘Apesar do Magazine Luiza tomar 
todas as precauções razoáveis para assegurar que nenhum vírus esteja 
presente nesse e-mail, a empresa não poderá aceitar a responsabilidade por 
quaisquer perdas ou danos causados por esse e-mail ou por seus anexos’.*



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230627/bdba0f88/attachment-0001.htm>