Hi Lucas,
On 1/6/26 5:39 PM, Dumitru Ceara wrote:
> 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?
>
I also wanted to point out that we're working on adding support for
disabling dynamic route learning (potentially per router port). CC-ing
Mairtin too as he's working on it:
https://issues.redhat.com/browse/FDP-2750
If the new configuration described in this issue above will be supported
both for routers and indvidually for router ports you could selectively
disable route learning on your other distributed gateway ports
(ts1001-dcx1).
At this moment, we're targeting adding support for this new feature in
the upcoming 26.03 release.
Regards,
Dumitru
> Regards,
> Dumitru
>
>>
>> Regards,
>> Lucas
>>
>>
>> Em seg., 5 de jan. de 2026 às 08:41, Dumitru Ceara <[email protected]>
>> escreveu:
>>
>>> On 1/2/26 6:29 PM, Lucas Vargas Dias wrote:
>>>> Em qui., 18 de dez. de 2025 às 11:56, Dumitru Ceara <[email protected]>
>>>> escreveu:
>>>>
>>>>> On 12/18/25 2:50 PM, Lucas Vargas Dias wrote:
>>>>>> Hi Dumitru,
>>>>>
>>>>> Hi Lucas,
>>>>>
>>>>>> thanks for the review.
>>>>>>
>>>>>> Em sex., 12 de dez. de 2025 às 12:29, Dumitru Ceara <[email protected]
>>>>
>>>>>> escreveu:
>>>>>>
>>>>>>> On 12/5/25 7:20 PM, Lucas Vargas Dias via dev wrote:
>>>>>>>> Learned routes must have the nexthop reachable. So, if logical router
>>>>>>>> has two ports in differents subnets, route must be learned in just
>>>>>>>> one which is the port in the same subnet from nexthop.
>>>>>>>>
>>>>>>>> Signed-off-by: Lucas Vargas Dias <[email protected]>
>>>>>>>> ---
>>>>>>>
>>>>>>> Hi Lucas,
>>>>>>>
>>>>>>> Thanks for the patch!
>>>>>>>
>>>>>>> I'm not sure I understand the problem though, please see below.
>>>>>>>
>>>>>>>> northd/en-learned-route-sync.c | 44 ++++++++++++++++++++
>>>>>>>> tests/ovn-northd.at | 14 ++++++-
>>>>>>>> tests/system-ovn.at | 74
>>>>> +++++++++++++++++-----------------
>>>>>>>> 3 files changed, 93 insertions(+), 39 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/northd/en-learned-route-sync.c
>>>>>>> b/northd/en-learned-route-sync.c
>>>>>>>> index f22aaa664..4c9de8651 100644
>>>>>>>> --- a/northd/en-learned-route-sync.c
>>>>>>>> +++ b/northd/en-learned-route-sync.c
>>>>>>>> @@ -227,6 +227,50 @@ routes_table_sync(
>>>>>>>> sbrec_learned_route_delete(sb_route);
>>>>>>>> continue;
>>>>>>>> }
>>>>>>>> + bool is_same_subnet = false;
>>>>>>>> + for (size_t i = 0; !is_same_subnet &&
>>>>>>>> + i < sb_route->logical_port->n_mac;
>>>>>>>> + i++) {
>>>>>>>> + struct lport_addresses logical_port_addrs;
>>>>>>>> + if
>>> (!extract_lsp_addresses(sb_route->logical_port->mac[i],
>>>>>>>> + &logical_port_addrs)) {
>>>>>>>> + destroy_lport_addresses(&logical_port_addrs);
>>>>>>>> + continue;
>>>>>>>> + }
>>>>>>>> + ovs_be32 neigh_prefix_v4;
>>>>>>>> + struct in6_addr neigh_prefix_v6;
>>>>>>>> +
>>>>>>>> + if (ip_parse(sb_route->nexthop, &neigh_prefix_v4)) {
>>>>>>>> + for (size_t j = 0; j <
>>>>> logical_port_addrs.n_ipv4_addrs;
>>>>>>>> + j++) {
>>>>>>>> + struct ipv4_netaddr address =
>>>>>>>> + logical_port_addrs.ipv4_addrs[j];
>>>>>>>> + if (address.network ==
>>>>>>>> + (neigh_prefix_v4 & address.mask)) {
>>>>>>>> + is_same_subnet = true;
>>>>>>>> + break;
>>>>>>>> + }
>>>>>>>> + }
>>>>>>>> + } else if (ipv6_parse(sb_route->nexthop,
>>>>> &neigh_prefix_v6))
>>>>>>> {
>>>>>>>> + for (size_t j = 0; j <
>>>>> logical_port_addrs.n_ipv6_addrs;
>>>>>>> j++) {
>>>>>>>> + struct ipv6_netaddr address =
>>>>>>>> + logical_port_addrs.ipv6_addrs[j];
>>>>>>>> + struct in6_addr neigh_prefix =
>>>>>>>> + ipv6_addr_bitand(&neigh_prefix_v6,
>>>>>>> &address.mask);
>>>>>>>> + if (ipv6_addr_equals(&address.network,
>>>>>>> &neigh_prefix)) {
>>>>>>>> + is_same_subnet = true;
>>>>>>>> + break;
>>>>>>>> + }
>>>>>>>> + }
>>>>>>>> + }
>>>>>>>> + destroy_lport_addresses(&logical_port_addrs);
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> +
>>>>>>>> + if (!is_same_subnet) {
>>>>>>>> + sbrec_learned_route_delete(sb_route);
>>>>>>>> + continue;
>>>>>>>> + }
>>>>>>>> parse_route_from_sbrec_route(parsed_routes_out, lr_ports,
>>>>>>>> &lr_datapaths->datapaths,
>>>>>>>> sb_route);
>>>>>>>> diff --git a/tests/ovn-northd.at b/tests/ovn-northd.at
>>>>>>>> index 864854c56..0d1d06196 100644
>>>>>>>> --- a/tests/ovn-northd.at
>>>>>>>> +++ b/tests/ovn-northd.at
>>>>>>>> @@ -15578,7 +15578,7 @@ AT_CHECK([grep -w "lr_in_ip_routing"
>>> lr0flows |
>>>>>>> ovn_strip_lflows], [0], [dnl
>>>>>>>> ])
>>>>>>>>
>>>>>>>> # Learn a route to 2001:db8:2::/64 via 2001:db8:ffff::20 learned on
>>>>>>> lr0-sw1.
>>>>>>>> -# This is not reachable so will not produce a lflow.
>>>>>>>> +# This is not reachable so will not produce a lflow. Also, it'll be
>>>>>>> removed by northd
>>>>>>>
>>>>>>> As the comment used to say, while the route is learned, ovn-northd
>>>>>>> doesn't actually produce logical flows for it because the next hop is
>>>>>>> not reachable on any network configured on lr0-sw1.
>>>>>>>
>>>>>>> So yes, the route is in SB.Learned_Route, but it doesn't affect
>>> routing
>>>>>>> in any way. It's exactly the same as configuring a NB Static_Route
>>> with
>>>>>>> a wrong next hop.
>>>>>>>
>>>>>>> Moreover, your code removes the Learned_Route in northd. But
>>>>>>> Learned_Routes are fully managed (created & deleted) by
>>> ovn-controller.
>>>>>>>
>>>>>>> So next time ovn-controller runs it will just relearn the route
>>>>>>> (re-create the SB.Learned_Route record). So this only creates
>>>>>>> unnecessary churn as far as I understand.
>>>>>>>
>>>>>>> Or is there a use case I missed?
>>>>>>>
>>>>>>>
>>>>>> You're right, it's more appropriate to add the code in ovn controller
>>>>>> and northd will not generate flows. However, I would like to avoid the
>>>>>> garbage on the southbound.
>>>>>>
>>>>>
>>>>> I'm still not sure what "garbage" we're avoiding. The router learns a
>>>>> "dynamic" route from a routing protocol (like any traditional router).
>>>>> Then there's some logic (in northd in our case) that decides whether
>>>>> that route should be used for actual traffic forwarding (i.e., is
>>>>> installed in the forwarding table in traditional routers).
>>>>>
>>>>> If the port it's learnt on doesn't have an IP in a subnet that includes
>>>>> the next hop, northd doesn't "install" the route (as logical flows).
>>>>>
>>>>> Also, I don't think you can move the check to ovn-controller. We
>>>>> already check for LRP subnets that match the next hop in ovn-northd. We
>>>>> don't want to duplicate that logic to ovn-controller IMO.
>>>>>
>>>>>
>>>> Hi Dumitru,
>>>> By "garbage" I mean useless entries that are just increasing the size of
>>>> southbound.
>>>>
>>>
>>> Hi Lucas,
>>>
>>> But do we really expect a lot of routes to be learned via next hops that
>>> are not reachable locally? That sounds like an unusual routing
>>> configuration.
>>>
>>> Regards,
>>> Dumitru
>>>
>>>>
>>>> Regards,
>>>> Lucas
>>>>
>>>>
>>>>> Regards,
>>>>> Dumitru
>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Lucas
>>>>>>
>>>>>>
>>>>>>> Regards,
>>>>>>> Dumitru
>>>>>>>
>>>>>>>
>>>>>>>> check_uuid ovn-sbctl create Learned_Route \
>>>>>>>> datapath=$datapath \
>>>>>>>> logical_port=$sw1 \
>>>>>>>> @@ -15586,7 +15586,9 @@ check_uuid ovn-sbctl create Learned_Route \
>>>>>>>> nexthop=\"2001:db8:ffff::20\"
>>>>>>>> check ovn-nbctl --wait=sb sync
>>>>>>>> check_row_count Advertised_Route 4
>>>>>>>> -check_row_count Learned_Route 2
>>>>>>>> +check_row_count Learned_Route 1
>>>>>>>> +check_row_count Learned_Route 0 logical_port=$sw1
>>>>>>> ip_prefix=\"2001:db8:2::/64\"
>>>>>>>> +
>>>>>>>> ovn-sbctl dump-flows lr0 > lr0flows
>>>>>>>> AT_CHECK([grep -w "lr_in_ip_routing" lr0flows | ovn_strip_lflows],
>>>>> [0],
>>>>>>> [dnl
>>>>>>>> table=??(lr_in_ip_routing ), priority=0 , match=(1),
>>>>>>> action=(drop;)
>>>>>>>> @@ -15605,6 +15607,14 @@ AT_CHECK([grep -w "lr_in_ip_routing"
>>> lr0flows
>>>>> |
>>>>>>> ovn_strip_lflows], [0], [dnl
>>>>>>>> # active.
>>>>>>>> check ovn-nbctl --wait=sb set Logical_Router_Port lr0-sw1 \
>>>>>>>> networks="\"2001:db8::1/64\" \"2001:db8:ffff::1/64\""
>>>>>>>> +
>>>>>>>> +# Learn a route to 2001:db8:2::/64 via 2001:db8:ffff::20 learned on
>>>>>>> lr0-sw1.
>>>>>>>> +# Northd doesn not remove now because lrp have address in same
>>> subnet
>>>>>>> from nexthop
>>>>>>>> +check_uuid ovn-sbctl create Learned_Route \
>>>>>>>> + datapath=$datapath \
>>>>>>>> + logical_port=$sw1 \
>>>>>>>> + ip_prefix=\"2001:db8:2::/64\" \
>>>>>>>> + nexthop=\"2001:db8:ffff::20\"
>>>>>>>> check_row_count Advertised_Route 5
>>>>>>>> check_row_count Learned_Route 2
>>>>>>>> ovn-sbctl dump-flows lr0 > lr0flows
>>>>>>>> diff --git a/tests/system-ovn.at b/tests/system-ovn.at
>>>>>>>> index 1cbbdfa58..6e87fb266 100644
>>>>>>>> --- a/tests/system-ovn.at
>>>>>>>> +++ b/tests/system-ovn.at
>>>>>>>> @@ -15404,10 +15404,10 @@ wait_for_ports_up mylearninglsp
>>>>>>>> check ovn-nbctl --wait=hv set Logical_Router_Port internet-phys \
>>>>>>>> options:dynamic-routing-port-name=mylearninglsp
>>>>>>>>
>>>>>>>> -check ip route add 233.253.0.0/24 via 192.168.20.20 dev hv1-mll
>>>>> onlink
>>>>>>> vrf ovnvrf1337 metric 30 proto zebra
>>>>>>>> -check ip route add 233.253.0.0/24 via 192.168.20.20 dev hv1-mll
>>>>> onlink
>>>>>>> vrf ovnvrf1337 metric 40 proto zebra
>>>>>>>> +check ip route add 233.253.0.0/24 via 192.168.10.20 dev hv1-mll
>>>>> onlink
>>>>>>> vrf ovnvrf1337 metric 30 proto zebra
>>>>>>>> +check ip route add 233.253.0.0/24 via 192.168.10.20 dev hv1-mll
>>>>> onlink
>>>>>>> vrf ovnvrf1337 metric 40 proto zebra
>>>>>>>> check ovn-nbctl --wait=hv sync
>>>>>>>> -check_row_count Learned_Route 1 ip_prefix=233.253.0.0/24
>>>>>>> nexthop=192.168.20.20
>>>>>>>> +check_row_count Learned_Route 1 ip_prefix=233.253.0.0/24
>>>>>>> nexthop=192.168.10.20
>>>>>>>>
>>>>>>>> # Stopping the ovn-controller will clean up the route entries
>>> created
>>>>>>> by it.
>>>>>>>> # We first need to unset dynamic-routing-maintain-vrf as otherwise
>>> it
>>>>>>> will
>>>>>>>> @@ -15417,8 +15417,8 @@ check ovn-nbctl --wait=hv set
>>>>>>> Logical_Router_Port internet-phys \
>>>>>>>> OVN_CLEANUP_CONTROLLER([hv1])
>>>>>>>> OVN_ROUTE_EQUAL([ovnvrf1337], [dnl
>>>>>>>> 233.252.0.0/24 via 192.168.10.10 dev lo proto zebra onlink
>>>>>>>> -233.253.0.0/24 via 192.168.20.20 dev hv1-mll proto zebra metric 30
>>>>>>> onlink
>>>>>>>> -233.253.0.0/24 via 192.168.20.20 dev hv1-mll proto zebra metric 40
>>>>>>> onlink])
>>>>>>>> +233.253.0.0/24 via 192.168.10.20 dev hv1-mll proto zebra metric 30
>>>>>>> onlink
>>>>>>>> +233.253.0.0/24 via 192.168.10.20 dev hv1-mll proto zebra metric 40
>>>>>>> onlink])
>>>>>>>>
>>>>>>>> # Starting it again will add the routes again.
>>>>>>>> start_daemon ovn-controller
>>>>>>>> @@ -15431,8 +15431,8 @@ blackhole 192.0.2.10 proto ovn metric 100
>>>>>>>> blackhole 192.0.2.20 proto ovn metric 100
>>>>>>>> blackhole 198.51.100.0/24 proto ovn metric 1000
>>>>>>>> 233.252.0.0/24 via 192.168.10.10 dev lo proto zebra onlink
>>>>>>>> -233.253.0.0/24 via 192.168.20.20 dev hv1-mll proto zebra metric 30
>>>>>>> onlink
>>>>>>>> -233.253.0.0/24 via 192.168.20.20 dev hv1-mll proto zebra metric 40
>>>>>>> onlink])
>>>>>>>> +233.253.0.0/24 via 192.168.10.20 dev hv1-mll proto zebra metric 30
>>>>>>> onlink
>>>>>>>> +233.253.0.0/24 via 192.168.10.20 dev hv1-mll proto zebra metric 40
>>>>>>> onlink])
>>>>>>>>
>>>>>>>> # Changing the vrf name will switch to the new one.
>>>>>>>> # The old vrf will be removed.
>>>>>>>> @@ -15449,8 +15449,8 @@ blackhole 192.0.2.10 proto ovn metric 100
>>>>>>>> blackhole 192.0.2.20 proto ovn metric 100
>>>>>>>> blackhole 198.51.100.0/24 proto ovn metric 1000
>>>>>>>> 233.252.0.0/24 via 192.168.10.10 dev lo proto zebra onlink
>>>>>>>> -233.253.0.0/24 via 192.168.20.20 dev hv1-mll proto zebra metric 30
>>>>>>> onlink
>>>>>>>> -233.253.0.0/24 via 192.168.20.20 dev hv1-mll proto zebra metric 40
>>>>>>> onlink])
>>>>>>>> +233.253.0.0/24 via 192.168.10.20 dev hv1-mll proto zebra metric 30
>>>>>>> onlink
>>>>>>>> +233.253.0.0/24 via 192.168.10.20 dev hv1-mll proto zebra metric 40
>>>>>>> onlink])
>>>>>>>>
>>>>>>>> # Stopping with --restart will not touch the routes.
>>>>>>>> OVN_CONTROLLER_EXIT([],[--restart])
>>>>>>>> @@ -15462,8 +15462,8 @@ blackhole 192.0.2.10 proto ovn metric 100
>>>>>>>> blackhole 192.0.2.20 proto ovn metric 100
>>>>>>>> blackhole 198.51.100.0/24 proto ovn metric 1000
>>>>>>>> 233.252.0.0/24 via 192.168.10.10 dev lo proto zebra onlink
>>>>>>>> -233.253.0.0/24 via 192.168.20.20 dev hv1-mll proto zebra metric 30
>>>>>>> onlink
>>>>>>>> -233.253.0.0/24 via 192.168.20.20 dev hv1-mll proto zebra metric 40
>>>>>>> onlink])
>>>>>>>> +233.253.0.0/24 via 192.168.10.20 dev hv1-mll proto zebra metric 30
>>>>>>> onlink
>>>>>>>> +233.253.0.0/24 via 192.168.10.20 dev hv1-mll proto zebra metric 40
>>>>>>> onlink])
>>>>>>>>
>>>>>>>> # When we now stop the ovn-controller it will remove the VRF.
>>>>>>>> start_daemon ovn-controller
>>>>>>>> @@ -15494,8 +15494,8 @@ blackhole 192.0.2.20 proto ovn metric 100
>>>>>>>> blackhole 192.0.2.21 proto ovn metric 100
>>>>>>>> blackhole 198.51.100.0/24 proto ovn metric 1000
>>>>>>>> 233.252.0.0/24 via 192.168.10.10 dev lo proto zebra onlink
>>>>>>>> -233.253.0.0/24 via 192.168.20.20 dev hv1-mll proto zebra metric 30
>>>>>>> onlink
>>>>>>>> -233.253.0.0/24 via 192.168.20.20 dev hv1-mll proto zebra metric 40
>>>>>>> onlink])
>>>>>>>> +233.253.0.0/24 via 192.168.10.20 dev hv1-mll proto zebra metric 30
>>>>>>> onlink
>>>>>>>> +233.253.0.0/24 via 192.168.10.20 dev hv1-mll proto zebra metric 40
>>>>>>> onlink])
>>>>>>>>
>>>>>>>> # Bind "vip" port locally and check the virtual IP is added in the
>>>>> VRF.
>>>>>>>> NS_EXEC([vif4], [arping -U -c 1 -w 2 -I vif4 192.0.2.30])
>>>>>>>> @@ -15511,8 +15511,8 @@ blackhole 192.0.2.21 proto ovn metric 100
>>>>>>>> blackhole 192.0.2.30 proto ovn metric 100
>>>>>>>> blackhole 198.51.100.0/24 proto ovn metric 1000
>>>>>>>> 233.252.0.0/24 via 192.168.10.10 dev lo proto zebra onlink
>>>>>>>> -233.253.0.0/24 via 192.168.20.20 dev hv1-mll proto zebra metric 30
>>>>>>> onlink
>>>>>>>> -233.253.0.0/24 via 192.168.20.20 dev hv1-mll proto zebra metric 40
>>>>>>> onlink])
>>>>>>>> +233.253.0.0/24 via 192.168.10.20 dev hv1-mll proto zebra metric 30
>>>>>>> onlink
>>>>>>>> +233.253.0.0/24 via 192.168.10.20 dev hv1-mll proto zebra metric 40
>>>>>>> onlink])
>>>>>>>>
>>>>>>>> check ovn-sbctl clear Port_Binding vip virtual-parent
>>>>>>>> OVN_ROUTE_EQUAL([ovnvrf1338], [dnl
>>>>>>>> @@ -15524,8 +15524,8 @@ blackhole 192.0.2.20 proto ovn metric 100
>>>>>>>> blackhole 192.0.2.21 proto ovn metric 100
>>>>>>>> blackhole 198.51.100.0/24 proto ovn metric 1000
>>>>>>>> 233.252.0.0/24 via 192.168.10.10 dev lo proto zebra onlink
>>>>>>>> -233.253.0.0/24 via 192.168.20.20 dev hv1-mll proto zebra metric 30
>>>>>>> onlink
>>>>>>>> -233.253.0.0/24 via 192.168.20.20 dev hv1-mll proto zebra metric 40
>>>>>>> onlink])
>>>>>>>> +233.253.0.0/24 via 192.168.10.20 dev hv1-mll proto zebra metric 30
>>>>>>> onlink
>>>>>>>> +233.253.0.0/24 via 192.168.10.20 dev hv1-mll proto zebra metric 40
>>>>>>> onlink])
>>>>>>>>
>>>>>>>> # Remove the backoff period, so we can bind it right away.
>>>>>>>> check ovn-sbctl remove Port_Binding vip options vport-backoff
>>>>>>>> @@ -15543,8 +15543,8 @@ blackhole 192.0.2.21 proto ovn metric 100
>>>>>>>> blackhole 192.0.2.30 proto ovn metric 100
>>>>>>>> blackhole 198.51.100.0/24 proto ovn metric 1000
>>>>>>>> 233.252.0.0/24 via 192.168.10.10 dev lo proto zebra onlink
>>>>>>>> -233.253.0.0/24 via 192.168.20.20 dev hv1-mll proto zebra metric 30
>>>>>>> onlink
>>>>>>>> -233.253.0.0/24 via 192.168.20.20 dev hv1-mll proto zebra metric 40
>>>>>>> onlink])
>>>>>>>> +233.253.0.0/24 via 192.168.10.20 dev hv1-mll proto zebra metric 30
>>>>>>> onlink
>>>>>>>> +233.253.0.0/24 via 192.168.10.20 dev hv1-mll proto zebra metric 40
>>>>>>> onlink])
>>>>>>>>
>>>>>>>> # Simulate "vip" bound to a different chassis.
>>>>>>>> check ovn-sbctl clear Port_Binding vip virtual-parent
>>>>>>>> @@ -15559,8 +15559,8 @@ blackhole 192.0.2.20 proto ovn metric 100
>>>>>>>> blackhole 192.0.2.21 proto ovn metric 100
>>>>>>>> blackhole 198.51.100.0/24 proto ovn metric 1000
>>>>>>>> 233.252.0.0/24 via 192.168.10.10 dev lo proto zebra onlink
>>>>>>>> -233.253.0.0/24 via 192.168.20.20 dev hv1-mll proto zebra metric 30
>>>>>>> onlink
>>>>>>>> -233.253.0.0/24 via 192.168.20.20 dev hv1-mll proto zebra metric 40
>>>>>>> onlink])
>>>>>>>> +233.253.0.0/24 via 192.168.10.20 dev hv1-mll proto zebra metric 30
>>>>>>> onlink
>>>>>>>> +233.253.0.0/24 via 192.168.10.20 dev hv1-mll proto zebra metric 40
>>>>>>> onlink])
>>>>>>>>
>>>>>>>> # Check with dynamic-routing-redistribute-local-only=false.
>>>>>>>> check ovn-nbctl --wait=hv set logical_router_port internet-public \
>>>>>>>> @@ -15576,8 +15576,8 @@ blackhole 192.0.2.22 proto ovn metric 1000
>>>>>>>> blackhole 192.0.2.30 proto ovn metric 1000
>>>>>>>> blackhole 198.51.100.0/24 proto ovn metric 1000
>>>>>>>> 233.252.0.0/24 via 192.168.10.10 dev lo proto zebra onlink
>>>>>>>> -233.253.0.0/24 via 192.168.20.20 dev hv1-mll proto zebra metric 30
>>>>>>> onlink
>>>>>>>> -233.253.0.0/24 via 192.168.20.20 dev hv1-mll proto zebra metric 40
>>>>>>> onlink])
>>>>>>>> +233.253.0.0/24 via 192.168.10.20 dev hv1-mll proto zebra metric 30
>>>>>>> onlink
>>>>>>>> +233.253.0.0/24 via 192.168.10.20 dev hv1-mll proto zebra metric 40
>>>>>>> onlink])
>>>>>>>>
>>>>>>>> # Remove the backoff period, so we can bind it right away.
>>>>>>>> check ovn-sbctl remove Port_Binding vip options vport-backoff
>>>>>>>> @@ -15596,8 +15596,8 @@ blackhole 192.0.2.22 proto ovn metric 1000
>>>>>>>> blackhole 192.0.2.30 proto ovn metric 100
>>>>>>>> blackhole 198.51.100.0/24 proto ovn metric 1000
>>>>>>>> 233.252.0.0/24 via 192.168.10.10 dev lo proto zebra onlink
>>>>>>>> -233.253.0.0/24 via 192.168.20.20 dev hv1-mll proto zebra metric 30
>>>>>>> onlink
>>>>>>>> -233.253.0.0/24 via 192.168.20.20 dev hv1-mll proto zebra metric 40
>>>>>>> onlink])
>>>>>>>> +233.253.0.0/24 via 192.168.10.20 dev hv1-mll proto zebra metric 30
>>>>>>> onlink
>>>>>>>> +233.253.0.0/24 via 192.168.10.20 dev hv1-mll proto zebra metric 40
>>>>>>> onlink])
>>>>>>>>
>>>>>>>> OVN_CLEANUP_CONTROLLER([hv1])
>>>>>>>> AT_CHECK([ip vrf | grep -q ovnvrf1338], [1], [])
>>>>>>>> @@ -15857,7 +15857,7 @@ check ip route add 233.253.0.0/24 via
>>>>>>> 192.168.10.10 dev lo onlink vrf ovnvrf1337
>>>>>>>> check ovn-nbctl --wait=hv sync
>>>>>>>> # With a Gateway Router all LRPs are locally bound, and without
>>>>> explicit
>>>>>>>> # mapping/filtering they will all learn the route.
>>>>>>>> -check_row_count Learned_Route 2
>>>>>>>> +check_row_count Learned_Route 1
>>>>>>>> lp=$(fetch_column port_binding _uuid logical_port=internet-phys)
>>>>>>>> check_row_count Learned_Route 1 logical_port=$lp ip_prefix=
>>>>>>> 233.252.0.0/24 nexthop=192.168.10.10
>>>>>>>>
>>>>>>>> @@ -15892,10 +15892,10 @@ wait_for_ports_up mylearninglsp
>>>>>>>> check ovn-nbctl --wait=hv set Logical_Router_Port internet-phys \
>>>>>>>> options:dynamic-routing-port-name=mylearninglsp
>>>>>>>>
>>>>>>>> -check ip route add 233.253.0.0/24 via 192.168.20.20 dev hv1-mll
>>>>> onlink
>>>>>>> vrf ovnvrf1337 metric 30 proto zebra
>>>>>>>> -check ip route add 233.253.0.0/24 via 192.168.20.20 dev hv1-mll
>>>>> onlink
>>>>>>> vrf ovnvrf1337 metric 40 proto zebra
>>>>>>>> +check ip route add 233.253.0.0/24 via 192.168.10.20 dev hv1-mll
>>>>> onlink
>>>>>>> vrf ovnvrf1337 metric 30 proto zebra
>>>>>>>> +check ip route add 233.253.0.0/24 via 192.168.10.20 dev hv1-mll
>>>>> onlink
>>>>>>> vrf ovnvrf1337 metric 40 proto zebra
>>>>>>>> check ovn-nbctl --wait=hv sync
>>>>>>>> -check_row_count Learned_Route 1 ip_prefix=233.253.0.0/24
>>>>>>> nexthop=192.168.20.20
>>>>>>>> +check_row_count Learned_Route 1 ip_prefix=233.253.0.0/24
>>>>>>> nexthop=192.168.10.20
>>>>>>>>
>>>>>>>> # Stopping the ovn-controller will clean up the route entries
>>> created
>>>>>>> by it.
>>>>>>>> # We first need to unset dynamic-routing-maintain-vrf as otherwise
>>> it
>>>>>>> will
>>>>>>>> @@ -15905,8 +15905,8 @@ check ovn-nbctl --wait=hv set
>>>>>>> Logical_Router_Port internet-phys \
>>>>>>>> OVN_CLEANUP_CONTROLLER([hv1])
>>>>>>>> OVN_ROUTE_EQUAL([ovnvrf1337], [dnl
>>>>>>>> 233.252.0.0/24 via 192.168.10.10 dev lo proto zebra onlink
>>>>>>>> -233.253.0.0/24 via 192.168.20.20 dev hv1-mll proto zebra metric 30
>>>>>>> onlink
>>>>>>>> -233.253.0.0/24 via 192.168.20.20 dev hv1-mll proto zebra metric 40
>>>>>>> onlink])
>>>>>>>> +233.253.0.0/24 via 192.168.10.20 dev hv1-mll proto zebra metric 30
>>>>>>> onlink
>>>>>>>> +233.253.0.0/24 via 192.168.10.20 dev hv1-mll proto zebra metric 40
>>>>>>> onlink])
>>>>>>>>
>>>>>>>> # Starting it again will add the routes again.
>>>>>>>> start_daemon ovn-controller
>>>>>>>> @@ -15919,8 +15919,8 @@ blackhole 192.0.2.10 proto ovn metric 100
>>>>>>>> blackhole 192.0.2.20 proto ovn metric 100
>>>>>>>> blackhole 198.51.100.0/24 proto ovn metric 1000
>>>>>>>> 233.252.0.0/24 via 192.168.10.10 dev lo proto zebra onlink
>>>>>>>> -233.253.0.0/24 via 192.168.20.20 dev hv1-mll proto zebra metric 30
>>>>>>> onlink
>>>>>>>> -233.253.0.0/24 via 192.168.20.20 dev hv1-mll proto zebra metric 40
>>>>>>> onlink])
>>>>>>>> +233.253.0.0/24 via 192.168.10.20 dev hv1-mll proto zebra metric 30
>>>>>>> onlink
>>>>>>>> +233.253.0.0/24 via 192.168.10.20 dev hv1-mll proto zebra metric 40
>>>>>>> onlink])
>>>>>>>>
>>>>>>>> # Stopping with --restart will not touch the routes.
>>>>>>>> OVN_CONTROLLER_EXIT([],[--restart])
>>>>>>>> @@ -15932,8 +15932,8 @@ blackhole 192.0.2.10 proto ovn metric 100
>>>>>>>> blackhole 192.0.2.20 proto ovn metric 100
>>>>>>>> blackhole 198.51.100.0/24 proto ovn metric 1000
>>>>>>>> 233.252.0.0/24 via 192.168.10.10 dev lo proto zebra onlink
>>>>>>>> -233.253.0.0/24 via 192.168.20.20 dev hv1-mll proto zebra metric 30
>>>>>>> onlink
>>>>>>>> -233.253.0.0/24 via 192.168.20.20 dev hv1-mll proto zebra metric 40
>>>>>>> onlink])
>>>>>>>> +233.253.0.0/24 via 192.168.10.20 dev hv1-mll proto zebra metric 30
>>>>>>> onlink
>>>>>>>> +233.253.0.0/24 via 192.168.10.20 dev hv1-mll proto zebra metric 40
>>>>>>> onlink])
>>>>>>>>
>>>>>>>> # Now we set maintain-vrf again and stop the ovn-controller.
>>>>>>>> # It will then remove the VRF.
>>>>>>>> @@ -16925,13 +16925,13 @@ check_row_count Learned_Route 1
>>>>>>>> AS_BOX([No dynamic-routing-port-name: routes learned on lrp1 and
>>>>> lrp2])
>>>>>>>> check ovn-nbctl --wait=hv \
>>>>>>>> remove logical_router_port lrp2 options
>>> dynamic-routing-port-name
>>>>>>>> -check_row_count Learned_Route 1 ip_prefix=3.3.3.0/24 \
>>>>>>>> +check_row_count Learned_Route 0 ip_prefix=3.3.3.0/24 \
>>>>>>>> nexthop=2.2.2.2 \
>>>>>>>> logical_port=$lrp1
>>>>>>>> check_row_count Learned_Route 1 ip_prefix=3.3.3.0/24 \
>>>>>>>> nexthop=2.2.2.2 \
>>>>>>>> logical_port=$lrp2
>>>>>>>> -check_row_count Learned_Route 2
>>>>>>>> +check_row_count Learned_Route 1
>>>>>>>>
>>>>>>>> OVN_CLEANUP_CONTROLLER([hv1])
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
