Open Stack

Would it be possible to implement multiple external network ports on the
same router?

It is not the same case of multi-homing [1], in the case of OVN-IC there
are no symmetric internet routes....
[1] https://review.opendev.org/c/openstack/neutron/+/874199

Basically an external port for ovn-ic doesn't have SNAT!

Could this be done Rodolfo? What would be the effort/implications?

If possible, we can integrate everything we are discussing in terms of
solutions into a single reference design.


Em ter., 18 de jul. de 2023 às 10:20, Roberto Bartzen Acosta <
roberto.acosta at luizalabs.com> escreveu:

> Hi Rodolfo,
>
> I agree with you, my initial idea with this thread was exactly what we are
> doing, debating problems and possible solutions for interconnecting
> workloads using unmanaged dynamic router resources. Thank you for being
> engaged with this!
> I'm sorry if the strategy wasn't presented clearly, let me talk about it
> then.
>
> Imagine we have a tenant on OpenStack, and this client has all the
> resources created by OpenStack itself
> 1 - Tenant OpenStack project
> 2 - Tenant self-service network
> 3 - Tenant self-service subnet - e.g. 10.0.0.0/24
> 4 - Security groups
> 5 - Maybe FIPs
> 6 - Tenant Logical Router
> 7 - Tenant Logical Router Ports:  1.  external network (provider/default
> gw) ;   2. internal network (self-service subnet)
> 8 - Tenant VMs - some VMs on the self-service subnet 10.0.0.0/24
>
> Now that same tenant expects to connect these VMs with another deployment
> in the same region - High Availability.
>
> Option 1 - Floating IPs -> it's not a good option
> Option 2 - OVN-IC - L3 routing between self-service networks   :)
>
> What's the strategy? connect the Tenant Logical Router with the TS of the
> OVN-IC.
>
> Creation steps:
> 1. Create a transit switch in the OVN-IC-NB
> 2. In each OpenStack / Neutron:
>    a. Create a new Logical_Router_Port (externally managed) on the Tenant
> Logical Router and link this port with the TS.
>
> What is the point here, as Felix comments: even with the creation of the
> special network type, it will still be necessary to filter learned
> resources.
> "   a. Ignore all resources where `external_ids` does not contain any key
>       starting with `neutron`."
>
> So, from my perspective:
> Neutron changes for the [RFE] unmanaged dynamic router resources - OVN
>    b. Ignore specific resources as defined by individual rules:
>       I. ignore all Logical_Router_Ports  where `external_ids` does not
> contain any key
>       starting with `neutron`.
>       II. ignore all Logical_Router_Static_Route where `external_ids` does
> not contain any key
>       starting with `neutron`.
>
>
> We have already tested this and it is enough for interconnect to work in
> multi-tenant scenarios, and with the router connected to a generic external
> network provider (where all other tenants are connected).
>
> That is, the Logical Router was created by Neutron, so it can decide to
> learn dynamic routes and ignore external interconnect Logical_Router_Ports.
>
> BTW: Felix, the transit switch will learn remote Logical_Switch_Ports
> ports automatically via OVN-NB, in this case these ports were not created
> by Neutron and would need more special treatment to skip these resources.
>
> Note: about creating a new external provider network type, I already
> expressed my arguments about the multi tenant case and the need to create
> more resources to have this together with the default gw. If it were
> possible to have this in the same Logical_router tenant, I mean, use two
> external networks on the same Router: here we would have a lot of gain in
> my perspective
>
> Regards,
> Roberto
>
>
>
> Em ter., 18 de jul. de 2023 às 09:40, Felix Huettner
> <felix.huettner at mail.schwarz> escreveu:
>
>> Hi everyone,
>>
>> we will validate in the next weeks the idea i'll describe below. If it
>> sounds feasible to us i would write up a spec for this for later
>> implementation.
>>
>> Setup:
>> 1. Two neutron setups with OVN
>> 2. A OVN-IC setup not managed by any tooling (used manually)
>>
>> Target setup for a individual project
>>
>> +-------------------------------------+
>> |          Transit Switch (ts1)       |
>> |          172.24.0.0/24              |
>> +-------------------------------------+
>>         |                    |
>> +----------------+   +----------------+
>> | 172.24.0.10    |   | 172.24.0.11    |
>> |    Router      |   |    Router      |
>> | 192.168.0.1    |   | 192.168.1.1    |
>> +----------------+   +----------------+
>>         |                    |
>> +----------------+   +----------------+
>> |    Network     |   |    Network     |
>> | 192.168.0.0/24 |   | 192.168.1.0/24 |
>> +----------------+   +----------------+
>>         |                    |
>> +----------------+   +----------------+
>> |      VM        |   |      VM        |
>> |  192.168.0.10  |   |  192.168.1.10  |
>> +----------------+   +----------------+
>>
>> Main creation workflow of a interconnected network:
>> 1. Create a transit switch in the OVN-IC-NB
>> 2. In each neutron:
>>    a. Create a new provider network that maps to the transit switch.
>>       E.g. using `--provider-network-type ovn-ic
>> --provider-phyiscal-network ts1`
>>    b. Create the internal network and router as always and attach the
>>       router to the internal network and the provider network
>>
>> Changes needed in Neutron (from my perspective):
>> 1. Neutron must not touch the resources created by OVN-IC. This might be
>>    done using two options:
>>    a. Ignore all resources where `external_ids` does not contain any key
>>       starting with `neutron`.
>>    b. Ignore specific resources as defined by individual rules:
>>       I. ignore all Logical_Router that contain
>>          `other_config:interconn-ts`
>>       II. ignore all Logical_Router_Static_Route that contain
>>          `external_ids:ic-learned-route`
>> 2. Neutron must allow OVN-IC transit switches to be treated as external
>>    networks. AFAIK this should work in the same way as creating any kind
>>    of OVN network (so Logical_Switch), but just importing an existing
>>    Logical_Switch.
>>
>> From my perspective with these two changes we should be good to
>> interconnect two neutron setups with probably minimal changes needed.
>> This is because OVN-IC would only touch the transit switch (which looks
>> in the Northbound like a regular Logical_Switch). All other resources
>> would still be managed by neutron and work as they do now.
>>
>> I will get back to this discussion and (if appropriate) provide a spec
>> or this idea, once we had time to validate this on our side (which will
>> take some weeks).
>>
>> Thanks
>> Felix
>>
>> On Tue, Jul 18, 2023 at 01:23:27PM +0200, Rodolfo Alonso Hernandez wrote:
>> > Ok, this is being tortuous. First of all: define a strategy. If you are
>> > going to create the resources in Neutron, define how. I've provided a
>> way
>> > to do this, find a formal strategy to ground it.
>> >
>> > Second: (again) try to find a connection between resources, if you are
>> > going to use the strategy of creating the resources in Neutron. The
>> > "Logical_Router_Static_Route" belongs to a router univocally. If that
>> > router has been created by OpenStack, then you can modify the DB sync
>> > method to consider learned routes too.
>> >
>> > In order to do this, you'll need a set of resources that are going to be
>> > needed in Neutron, the OVN counterparts and other resources (like
>> > "Logical_Router_Static_Route") that will be added and will be present in
>> > OVN and not in Neutron DB. Also you'll need to know how to relate all of
>> > them.
>> Diese E Mail enthält möglicherweise vertrauliche Inhalte und ist nur für
>> die Verwertung durch den vorgesehenen Empfänger bestimmt.
>> Sollten Sie nicht der vorgesehene Empfänger sein, setzen Sie den Absender
>> bitte unverzüglich in Kenntnis und löschen diese E Mail.
>>
>> Hinweise zum Datenschutz finden Sie hier<https://www.datenschutz.schwarz
>> >.
>>
>>
>> This e-mail may contain confidential content and is intended only for the
>> specified recipient/s.
>> If you are not the intended recipient, please inform the sender
>> immediately and delete this e-mail.
>>
>> Information on data protection can be found here<
>> https://www.datenschutz.schwarz>.
>>
>

-- 




_‘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/20230718/f193d86e/attachment-0001.htm>