Hi Felix, Thanks for your feedback.
Em seg., 9 de set. de 2024 às 04:22, Felix Huettner <felix.huettner@stackit.cloud> escreveu: > On Thu, Sep 05, 2024 at 03:32:14PM -0300, Roberto Bartzen Acosta via dev > wrote: > > Hey everyone, > > > > I was validating the idea of integrating BGP with the exchange module as > a > > whole and found some issues addressed in the proposed patch [1]. > > > > However, the route learning and integration with the control plane (NB > > database) part is still open. Do you have any idea how this will be > > implemented? I can't see any other way to do this than to integrate with > > Logical_Router_Static_Route at the NB database level, and that's exactly > > what OVN-IC does to inject remotely learned routes. > > > > I have some ideas that may not make sense but I would like to know how > you > > see this part so we can think of an implementation proposal. > > Hi Roberto, > > i am currently trying to add this to the active-active router patches to > see how the whole system could look like. > It is based mostly on the patches of Forde with some of what you describe > here > combined. > code is currently available here, but can be expected to be broken :) > https://github.com/felixhuettner/ovn/commits/test_active_active_routing_v4/ Sorry, I haven't seen your latest version yet ;) > > > > > > Highlights: > > > > - Create a new Southbound Database table for advertised and learned > > routes (NB/SB sync): Routing_Information_Base > > - e.g. Routing_Information_Base columns: > > - route_table > > - ip_prefix > > - nexthop > > - logical_port (basically the matching criteria for SB > > Port_Binding table) > > - options > > - external_ids > > - Route Advertisement process: > > - Initially created based on the Logical_Router_Static_Route rows > (we > > can add connected networks too) - NB sync. > > I solved this for connected networks by handling them also as `struct > parsed_route` > https://github.com/felixhuettner/ovn/commit/ed77c78f91490a12607993798d97cdf9328b3a26 > > > - Create entries only if we have some option enabled in LRP, > > something like: LRP options:redistribute-rib=true. > > - Use the policy filter criteria (same as OVN-IC) to filter > > advertised routes. In other words, do not create entries in this > > RIB table > > if there is some policy blocking it. > > - The monitoring process for changes in the > > Logical_Router_Static_Route rows will not create new entries in > > the SB RIB > > table for learned routes identified by key (e.g. with the > external_ids > > exchange-learned-route key). > > - Route Learning process: > > - Add new rows in the Routing_Information_Base table based on the > > learned prefix from the exchange module. We need to set some > > config option > > flag for this, like: options:learn-exchange-routes=true or we can > add a > > protocol specific if it works better for general use cases like: > > options:learn-exchange-routes-protocol=BGP. > > - Add an engine node for Routing_Information_Base in > inc-proc-northd > > and a sync function like this (en_sync_to_sb_pb_run) to > > synchronize routing > > between new routes created in the SB Routing_Information_Base > > table and/or > > updates in the NB database (e.g. changes to the > > Logical_Router_Static_Route > > table). > > - The result of this synchronization is basically: > > - SB->NB: creating/deleting/updating Logical_Router_Static_Route > > entries for learned routes in the Routing_Information_Base > > table (using the > > key). > > Why would you see the need to push the learned routes to the northbound > database? I would see this as just creating chaos in the CMS. > I would rather keep them only in the SB and let northd do the merging. > This is not necessary at all! It would not be necessary to sync a new table with NB since the learned routes can be redistributed as static routes via OVN-IC, for example. The solution as a whole needs to be generic enough that we can redistribute/learn static routes in addition to directly connected routes. So, as long as northd merges these routes, it should work perfectly fine! Of course we need to be careful with the route policies that can block some prefix. I see your suggestion to use a new RTPROT_OVN type to solve the problem I mentioned in the other thread, thanks. Another question: I think the patches are overwriting each other in several parts, wouldn't it be better to have a separate common development branch on OVN for this new functionality? to concentrate the commits of all parts and facilitate testing/reviews before putting it into the main source code? Just a suggestion if it works for you. Kind regards, Roberto > Thanks > Felix > > > - NB->SB: Creating/deleting/updating entries in the > > SB Routing_Information_Base table for LRP with the config > > option enabled - > > based on LRSR table. > > - We need to create an identifier for this in the LRSR table to > > avoid loops/reentrance, for example, ovn-ic creates a key > > ic-learned-route > > in the external_ids. So, we can use a similar approach for > > this, such as: > > external_ids:exchange-learned-route=RIB_UUID. > > > > > > What do you think? any ideas? > > > > [1] > > > https://mail.openvswitch.org/pipermail/ovs-dev/2024-September/417066.html > > > -- _‘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’.* _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
