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?
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
