On 1/7/26 1:27 PM, Lucas Vargas Dias wrote:
> Hi Dumitru,
> 

Hi Lucas,

> Thanks for the example of configuration.
> 
> Em ter., 6 de jan. de 2026 às 13:39, Dumitru Ceara <[email protected]>
> escreveu:
> 
>> On 1/5/26 6:50 PM, Lucas Vargas Dias wrote:
>>> Hi Dumitru,
>>>
>>
>> Hi Lucas,
>>
>>>
>>> I'm testing a scenario with a logical router that has a
>> logical_router_port
>>> used to ovn-ic and another logical router port used to DR.
>>> I'm learning in all logical router ports, I would like to learn just in
>>> logical router port from DR.
>>> Follow an example of configuration:
>>>
>>
>> Thanks for the sample config!
>>
>>> ovn-nbctl -- lr-add dcx1
>>> # LRP used to Dynamic routing
>>> ovn-nbctl -- lrp-add dcx1 rp-public 00:00:02:01:02:04 169.254.254.2/30
>> --
>>> lrp-set-options rp-public
>>> ovn-nbctl set logical_router dcx1 options:dynamic-routing=true
>>> ovn-nbctl set logical_router dcx1 options:requested-tnl-key=1002
>>
>> Btw, there's a better way to configure the VRF ID:
>>
>> ovn-nbctl set logical_router dcx1 options:dynamic-routing-vrf-id=1002.
>> Relying on the requested-tnl-key is not that great, I'd recommend using
>> the new option from now on.
>>
>>> ovn-nbctl set logical_router dcx1
>>> options:dynamic-routing-redistribute="connected,static"
>>> ovn-nbctl --wait=sb set logical_router_port rp-public
>>> options:routing-protocols=BGP,BFD
>>> ovn-nbctl --wait=sb set logical_router_port rp-public
>>> options:routing-protocol-redirect=bgpvrf1002
>>> ovn-nbctl --wait=sb set logical_router_port rp-public
>>> options:dynamic-routing-redistribute="connected,static"
>>> ovn-nbctl --wait=sb set logical_router_port rp-public
>>> options:dynamic-routing-maintain-vrf=true
>>> ovn-nbctl lrp-set-gateway-chassis rp-public ovn-chassis-4
>>>
>>> # LRPs used to ovn-ic
>>> ovn-nbctl lrp-add dcx1 ts1001-dcx1 12:00:01:d9:b5:d4 169.254.11.5/24
>>> ovn-nbctl set logical_router_port ts1001-dcx1
>> ha_chassis_group="$HA_GROUP1"
>>>
>>>
>>> ovn-sbctl list learned_route
>>> _uuid               : e283e6a9-ef99-468a-bafe-0b8802208436
>>> datapath            : 2e170dbc-23cb-4de2-98b9-666de3700e71
>>> external_ids        : {}
>>> ip_prefix           : "10.0.0.0/24"
>>> logical_port        : ae4c72f8-c30d-478f-86f5-2ed8d125f32c
>>> nexthop             : "169.254.254.1"
>>>
>>> _uuid               : 5524ae47-a81b-4dd0-8e90-baf171c73dcf
>>> datapath            : 2e170dbc-23cb-4de2-98b9-666de3700e71
>>> external_ids        : {}
>>> ip_prefix           : "10.0.0.0/24"
>>> logical_port        : 8b108f3d-7402-48f5-bf15-7471db49c066
>>> nexthop             : "169.254.254.1"
>>>
>>>
>>> ovn-sbctl list port_binding 8b108f3d-7402-48f5-bf15-7471db49c066
>>> _uuid               : 8b108f3d-7402-48f5-bf15-7471db49c066
>>> additional_chassis  : []
>>> additional_encap    : []
>>> chassis             : []
>>> datapath            : 2e170dbc-23cb-4de2-98b9-666de3700e71
>>> encap               : []
>>> external_ids        : {}
>>> gateway_chassis     : []
>>> ha_chassis_group    : []
>>> logical_port        : ts1001-dcx1
>>> mac                 : ["00:01:11:00:11:15 169.254.11.5/24"]
>>> mirror_port         : []
>>> mirror_rules        : []
>>> nat_addresses       : []
>>> options             : {chassis-redirect-port=cr-ts1001-dcx1,
>>> peer=ts1001-dcx1-rp}
>>> parent_port         : []
>>> port_security       : []
>>> requested_additional_chassis: []
>>> requested_chassis   : []
>>> tag                 : []
>>> tunnel_key          : 3
>>> type                : patch
>>> up                  : false
>>> virtual_parent      : []
>>>
>>>
>>>
>>> ovn-sbctl list port_binding ae4c72f8-c30d-478f-86f5-2ed8d125f32c
>>> _uuid               : ae4c72f8-c30d-478f-86f5-2ed8d125f32c
>>> additional_chassis  : []
>>> additional_encap    : []
>>> chassis             : []
>>> datapath            : 2e170dbc-23cb-4de2-98b9-666de3700e71
>>> encap               : []
>>> external_ids        : {}
>>> gateway_chassis     : []
>>> ha_chassis_group    : []
>>> logical_port        : rp-public
>>> mac                 : ["00:00:02:01:02:04 169.254.254.2/30"]
>>> mirror_port         : []
>>> mirror_rules        : []
>>> nat_addresses       : []
>>> options             : {chassis-redirect-port=cr-rp-public,
>> peer=public-rp}
>>> parent_port         : []
>>> port_security       : []
>>> requested_additional_chassis: []
>>> requested_chassis   : []
>>> tag                 : []
>>> tunnel_key          : 1
>>> type                : patch
>>> up                  : false
>>> virtual_parent      : []
>>>
>>>
>>
>> I think this looks similar to the use case Felix had when he added the
>> LRP.options:dynamic-routing-port-name support:
>>
>>
>> https://github.com/ovn-org/ovn/blob/3708cf59ea3759152adaa875dbf244e2e4898650/ovn-nb.xml#L4512C35-L4541
>>
>> Without that config option ovn-controller learns routes on all DGPs, in
>> your case rp-public (because it has gateway_chassis=ovn-chassis-4) and
>> ts1001-dcx1 (because it has ha_chassis_group set and the active chassis
>> happens to be ovn-chassis-4).
>>
>> As you always bind rp-public to ovn-chassis-4 you could also set:
>>
>> ovn-nbctl set logical_router_port rp-public
>> options:dynamic-routing-port-name=<a-LSP-that-is-bound-on-ovn-chassis-4>
>>
>> e.g., the bgpvrf1002 port (assuming that's bound on ovn-chassis-4).
>>
>> Then ovn-controller will only learn routes with logical_port=rp-public
>>
>> Would that work for you?
>>
> 
> It works partially. If I configured it exactly in the following order, it
> works.
> ovn-nbctl -- lr-add dcx1
> # LRP used to Dynamic routing
> ovn-nbctl -- lrp-add dcx1 rp-public 00:00:02:01:02:04 169.254.254.2/30 --
> lrp-set-options rp-public
> ovn-nbctl set logical_router dcx1 options:dynamic-routing=true
> ovn-nbctl set logical_router dcx1 options:dynamic-routing-vrf-id=1002
> ovn-nbctl set logical_router dcx1
> options:dynamic-routing-redistribute="connected,static"
> ovn-nbctl --wait=sb set logical_router_port rp-public
> options:routing-protocols=BGP,BFD
> ovn-nbctl --wait=sb set logical_router_port rp-public
> options:routing-protocol-redirect=bgpvrf1002
> ovn-nbctl --wait=sb set logical_router_port rp-public
> options:dynamic-routing-redistribute="connected,static"
> ovn-nbctl --wait=sb set logical_router_port rp-public
> options:dynamic-routing-maintain-vrf=true
> *ovn-nbctl --wait=sb set logical_router_port rp-public
> options:dynamic-routing-port-name=bgpvrf1002*
> ovn-nbctl lrp-set-gateway-chassis rp-public ovn-chassis-4
> 
> # LRPs used to ovn-ic
> ovn-nbctl lrp-add dcx1 ts1001-dcx1 12:00:01:d9:b5:d4 169.254.11.5/24
> ovn-nbctl set logical_router_port ts1001-dcx1 ha_chassis_group="$HA_GROUP1"
> 
> 
> If I configure ovn-nbctl set logical_router_port rp-public
> options:dynamic-routing-port-name=<a-LSP-that-is-bound-on-ovn-chassis-4>
> after configured
> the ha_chassis_group, route is learned in all LRPs.
> 
> 
> ovn-nbctl -- lr-add dcx1
> # LRP used to Dynamic routing
> ovn-nbctl -- lrp-add dcx1 rp-public 00:00:02:01:02:04 169.254.254.2/30 --
> lrp-set-options rp-public
> ovn-nbctl set logical_router dcx1 options:dynamic-routing=true
> ovn-nbctl set logical_router dcx1 options:dynamic-routing-vrf-id=1002
> ovn-nbctl set logical_router dcx1
> options:dynamic-routing-redistribute="connected,static"
> ovn-nbctl --wait=sb set logical_router_port rp-public
> options:routing-protocols=BGP,BFD
> ovn-nbctl --wait=sb set logical_router_port rp-public
> options:routing-protocol-redirect=bgpvrf1002
> ovn-nbctl --wait=sb set logical_router_port rp-public
> options:dynamic-routing-redistribute="connected,static"
> ovn-nbctl --wait=sb set logical_router_port rp-public
> options:dynamic-routing-maintain-vrf=true
> ovn-nbctl lrp-set-gateway-chassis rp-public ovn-chassis-4
> 
> # LRPs used to ovn-ic
> ovn-nbctl lrp-add dcx1 ts1001-dcx1 12:00:01:d9:b5:d4 169.254.11.5/24
> ovn-nbctl set logical_router_port ts1001-dcx1 ha_chassis_group="$HA_GROUP1"
> 
> *ovn-nbctl --wait=sb set logical_router_port rp-public
> options:dynamic-routing-port-name=bgpvrf1002*
> 

This sounds like an incremental processing bug in northd (I guess).

Can you try an "ovn-appctl -t ovn-northd inc-engine/recompute" on the
node where ovn-northd runs after you ended up in the broken state
(second way of configuring things)?

Does that "fix" the route learning?

Thanks,
Dumitru


_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to