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....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@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 itself1 - Tenant OpenStack project2 - Tenant self-service network3 - Tenant self-service subnet - e.g. 10.0.0.0/244 - Security groups5 - Maybe FIPs6 - Tenant Logical Router7 - 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/24Now 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 optionOption 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 keystarting with `neutron`."So, from my perspective:Neutron changes for the [RFE] unmanaged dynamic router resources - OVNb. Ignore specific resources as defined by individual rules:starting with `neutron`.
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 keyWe 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 perspectiveRegards,RobertoEm ter., 18 de jul. de 2023 às 09:40, Felix Huettner <felix.huettner@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’.