Description of problem:
FRR is running on two peer nodes (frr-8.3.1-5.el9.x86_64).

One of them exposes via BGP a route to an IP from its loopback interface:
[root@cmp-1-1 ~]# ip a s lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet 172.30.1.3/32 brd 172.30.1.3 scope host lo
valid_lft forever preferred_lft forever

The frr config running on this node can be found attached.

The peer node, leaf-0, receives a route to 172.30.1.3 via BGP (100.65.1.10 is another IP on a physical interface at cmp-1-1):
[root@leaf-0 ~]# vtysh -c 'show ip route 172.30.1.3'
Routing entry for 172.30.1.3/32
Known via "bgp", distance 200, metric 0, best
Last update 00:01:14 ago

• 100.65.1.10, via eth5, weight 1

When frr is restarted on cmp-1-1, the route to 172.30.1.3 is removed from leaf-0 and it takes several minutes to recover it, more than 5 minutes, which is not acceptable.
When frr is stopped on cmp-1-1, wait 1 second, and started again, the route to 172.30.1.3 is removed from leaf-0, but it is recovered almost immediately, which is fine.

The frr version frr-8.3.1-5.el9.x86_64 has been updated on leaf-0 to frr-8.5.1-02.el9.x86_64 (it has been obtained from [1]).
The test is repeated and now the routes are recovered immediately after restarting frr on cmp-1-1.

We believe this is the PR that fixes this issue: https://github.com/FRRouting/frr/pull/12034
Can this patch be backported to RHEL9.2 frr version? (or can it be rebased? whatever is usually done in these cases).

[1] https://rpm.frrouting.org/

Version-Release number of selected component (if applicable):
frr-8.3.1-5.el9.x86_64

How reproducible:
100%

Steps to Reproduce:
1. restart frr on one node
2. check the BGP routes on its peer node
3.

Actual results:
BGP routes are not recovered after the frr restart

Expected results:
BGP routes should be recovered after the frr restart

Additional info: