Description of problem:
A metallb configuration always have a deny all route rule to avoid external routers to be able to inject routes to the ocp nodes.

In some particular scenarios, we allow injecting a rule that overrides that in the final part of the configuration.

So, in the configuration we have something like

route-map 172.18.0.5-in deny 20

Then we update the configuration file appending
route-map 172.18.0.5-in permit 20

and we reload it with the frr-reload.py script.

The current-config shows the rule being updated correctly, but a refresh route message is not sent to the neighbor, so any published route is not received.

This is different from what is observed with frr 8.4.2, where as soon as we update the configuration file a route refresh message is sent out

023/04/11 09:14:40.021 BGP: [WNMVF-B11FV] Processing route_map 172.30.0.2-in(IPv4:unicast) update on peer 172.30.0.2 (inbound, route-refresh)
2023/04/11 09:14:40.021 BGP: [QCZ1W-VKS36] 172.30.0.2(14513de9912d) sending REFRESH_REQ for afi/safi: IPv4/unicast
2023/04/11 09:14:40.021 BGP: [WNMVF-B11FV] Processing route_map 172.30.0.2-in(IPv6:unicast) update on peer 172.30.0.2 (inbound, route-refresh)
2023/04/11 09:14:40.021 BGP: [QCZ1W-VKS36] 172.30.0.2(14513de9912d) sending REFRESH_REQ for afi/safi: IPv6/unicast

Version-Release number of selected component (if applicable):
7.5.1

How reproducible:
Always

Steps to Reproduce:
Described above.

• A neighbor configured to push routes
• an initial config with a deny all route rule
• a new config with a permit any to amend the previous deny

Actual results:

We must either kill the session or restart the frr instance to see the routes

Expected results:

The local frr instance asks for routes to the neighbor

Additional info: