On 26.02.2026 20:05, Lucas Vargas Dias wrote: > Hi, > > > Em qui., 26 de fev. de 2026 às 12:28, Rukomoinikova Aleksandra > <[email protected]> escreveu: > > Hi Lucas! > I tried to fix the same situation, but when learning happens through > multiple transit switches. I thought it would be right hashing ICDB > route UUID - In essence, its matching routes from ICDB to routes > in NBDB > directly. This approach also fix situation you described, but with > your > patch, ICDB will have two routes, but only one will be learned by the > router. With mine, router will have two identical routes, which is > generally questionable. In either case, network won't work because > packets will flapping between availability zones when processed on > the > transit switch, so I don't have any strong arguments for whether > this is > a good or bad thing. In SBDB on the router, even with two routes, > we'll > only see one logical flow because routes are literally identical. One > small argument: it seems it will be easier for the user to see > that the > situation as such is not valid if he sees two routes instead of one. > Here's the patch I made - > > https://github.com/Sashhkaa/ovn/commit/74c6a322a7505c0a13efdb20f58b1f6018f3d016 > > > > What do you think? If you don't mind, I can send you this patch. And > again, sorry if I interrupted your work on this. > > > > In your test, are lr11 and lr12 connected in TS11, and are lr13 and > lr12 connected in TS12? > Do you have two LSPs ports pointing to the same LRP from lr12? > If your test is different from the scenario above, could you provide a > test in the patch that you sent?
Hi! Sure, here: https://github.com/Sashhkaa/ovn/commit/83f7cf11a09d723ce167dd54c6699cf37241e8e5 If you're okay with it and you don't mind, I could take your test and add it here too for patch. > > I think your points make sense, the user will see the problem easier > if the logical router has two routes > in a scenario with one transit switch and it'll have one logical flow > (nexthop and prefix are equals). > > Your patch looks good to me. > I cloned your repo to run the test I added and don't generate a loop. > > Regards, > Lucas > > > > > On 24.02.2026 15:16, Rukomoinikova Aleksandra wrote: > > Hi Lucas! > > > >> Avoid learned route loop if two differents AZs > >> configure the same address and adv ther same prefix. > >> Do not remove the route from routes learned structure, > >> mark the route as not stale. > > nit: Maybe, it's worth clarifying that the patch solves the > problem when such learning happen through a single transit switch? > > > > In case where there are multiple transit switches, routes won't be > > endlessly learned, but there will be a different problem with the > > endless updating of external_ids, which will be updated with > different > > transit switch's TS. This problem is not related to the problem of > > endless route learning in general, but it seems worth mentioning for > > easier tracking later. > > > >> Signed-off-by: Lucas Vargas Dias <lucas.vdias at luizalabs.com > <http://luizalabs.com> > <https://mail.openvswitch.org/mailman/listinfo/ovs-dev>> > >> --- > >> ic/ovn-ic.c | 17 ++++++++------ > >> tests/ovn-ic.at <http://ovn-ic.at> | 60 > +++++++++++++++++++++++++++++++++++++++++++++++++ > >> 2 files changed, 70 insertions(+), 7 deletions(-) > >> > >> diff --git a/ic/ovn-ic.c b/ic/ovn-ic.c > >> index 95d73cb4b..3f3c0d99d 100644 > >> --- a/ic/ovn-ic.c > >> +++ b/ic/ovn-ic.c > >> @@ -1300,6 +1300,7 @@ struct ic_route_info { > >> const struct nbrec_logical_router_static_route *nb_route; > >> const struct nbrec_logical_router_port *nb_lrp; > >> const struct nbrec_load_balancer *nb_lb; > >> + bool stale; /* True if the route is stale and should be > removed. */ > >> }; > >> > >> static uint32_t > >> @@ -1393,6 +1394,7 @@ add_to_routes_learned(struct hmap > *routes_learned, > >> ic_route->origin = origin; > >> ic_route->route_table = nb_route->route_table; > >> ic_route->nb_lr = nb_lr; > >> + ic_route->stale = true; > >> hmap_insert(routes_learned, &ic_route->node, > >> ic_route_hash(&prefix, plen, &nexthop, origin, > >> nb_route->route_table)); > >> @@ -2168,8 +2170,7 @@ sync_learned_routes(struct ic_context *ctx, > >> route_learned->nb_route, "ic-learned-route", uuid_s); > >> free(uuid_s); > >> } > >> - hmap_remove(&ic_lr->routes_learned, &route_learned->node); > >> - free(route_learned); > >> + route_learned->stale = false; > >> } else { > >> /* Create the missing route in NB. */ > >> const struct > nbrec_logical_router_static_route *nb_route = > >> @@ -2197,11 +2198,13 @@ sync_learned_routes(struct ic_context *ctx, > >> /* Delete extra learned routes. */ > >> struct ic_route_info *route_learned; > >> HMAP_FOR_EACH_SAFE (route_learned, node, > &ic_lr->routes_learned) { > >> - VLOG_DBG("Delete route %s -> %s that is not in IC-SB > from NB.", > >> - route_learned->nb_route->ip_prefix, > >> - route_learned->nb_route->nexthop); > >> - nbrec_logical_router_update_static_routes_delvalue( > >> - ic_lr->lr, route_learned->nb_route); > >> + if (route_learned->stale) { > >> + VLOG_DBG("Delete route %s -> %s that is not in > IC-SB from NB.", > >> + route_learned->nb_route->ip_prefix, > >> + route_learned->nb_route->nexthop); > >> + nbrec_logical_router_update_static_routes_delvalue( > >> + ic_lr->lr, route_learned->nb_route); > >> + } > >> hmap_remove(&ic_lr->routes_learned, &route_learned->node); > >> free(route_learned); > >> } > >> diff --git a/tests/ovn-ic.at <http://ovn-ic.at> > b/tests/ovn-ic.at <http://ovn-ic.at> > >> index 1a826aa1c..ead16aa91 100644 > >> --- a/tests/ovn-ic.at <http://ovn-ic.at> > >> +++ b/tests/ovn-ic.at <http://ovn-ic.at> > >> @@ -3394,6 +3394,66 @@ OVN_CLEANUP_IC([az1], [az2]) > >> AT_CLEANUP > >> ]) > >> > >> +OVN_FOR_EACH_NORTHD([ > >> +AT_SETUP([ovn-ic -- check loop with LSP of duplicated address]) > >> + > >> +ovn_init_ic_db > >> + > >> +for i in 1 2 3; do > >> + ovn_start az$i > >> + ovn_as az$i > >> + > >> + # Enable route learning at AZ level > >> + check ovn-nbctl set nb_global . options:ic-route-learn=true > >> + # Enable route advertising at AZ level > >> + check ovn-nbctl set nb_global . options:ic-route-adv=true > >> +done > >> + > >> +# Create new transit switches and LRs. Test topology is next: > >> +# logical router (lr12) > >> +# | > >> +# logical router (lr11) - / transit switch (ts11) \ - logical > router (lr13) > >> +# > >> + > >> +# Create lr11, lr13, ts11 and connect them > >> +for i in 1 3; do > >> + ovn_as az$i > >> + > >> + lr=lr1$i > >> + check ovn-nbctl lr-add $lr > >> + > >> + check ovn-ic-nbctl --wait=sb --may-exist ts-add ts11 > >> + > >> + lrp=lrp-$lr-ts11 > >> + lsp=lsp-ts11-$lr > >> + # Create LRP and connect to TS > >> + check ovn-nbctl lrp-add $lr $lrp aa:aa:aa:aa:a1:0$i > 169.254.101.1/24 <http://169.254.101.1/24> > >> + check ovn-nbctl lsp-add-router-port ts11 $lsp $lrp > >> +done > >> + > >> +# Create lr12 and connect it to ts11 > >> +ovn_as az2 > >> +check ovn-nbctl lr-add lr12 > >> + > >> +# Create LRP and connect to TS > >> +check ovn-nbctl lrp-add lr12 lrp-lr12-ts11 aa:aa:aa:aa:a1:03 > 169.254.101.2/24 <http://169.254.101.2/24> > >> +check ovn-nbctl lsp-add-router-port ts11 lsp-lr12-ts11 > lrp-lr12-ts11 > >> + > >> + > >> +# Create directly-connected route in lr11 > >> +check ovn_as az1 ovn-nbctl lrp-add lr11 lrp-lr11 > aa:aa:aa:aa:bb:01 "192.168.0.1/24 <http://192.168.0.1/24>" > >> +check ovn_as az3 ovn-nbctl lrp-add lr13 lrp-lr13 > aa:aa:aa:aa:bb:03 "192.168.0.1/24 <http://192.168.0.1/24>" > >> +sleep 2 > > nit: It seems like a sleep is not needed here, bc line below > calls WAIT macro > > > >> +OVS_WAIT_FOR_OUTPUT([ovn_as az2 ovn-nbctl lr-route-list lr12 | > grep 192.168 | > >> + grep learned | awk '{print $1, $2}' | sort ], > [0], [dnl > >> +192.168.0.0/24 <http://192.168.0.0/24> 169.254.101.1 > >> +]) > >> + > >> +OVN_CLEANUP_IC([az1], [az2], [az3]) > >> + > >> +AT_CLEANUP > >> +]) > >> + > >> OVN_FOR_EACH_NORTHD([ > >> AT_SETUP([ovn-ic -- prefix filter -- filtering routes]) > >> ovn_init_ic_db > >> -- > >> 2.43.0 > > |Reviewed-by:| Alexandra Rukomoinikova <[email protected]> > > > > -- > regards, > Alexandra. > > > > /‘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’./ > -- regards, Alexandra. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
