bgpd: BGP routes owned by VRF instances not replayed to zebra after a zebra restart

[0n41rd4]

Description

If Zebra reconnects while bgpd keeps running, already selected BGP routes
in a VRF BGP instance can stay in the BGP RIB but disappear from Zebra and
the kernel. The reconnect fix added in #22411 covers ospf, isis, and rip VRF
instances, but not bgp.

Version

Latest FRR development master, local build:


FRR 10.8.0-dev-1132-gb8316e31cb
source branch: master

How to reproduce

1. Run two routers whose peer interfaces are both in the same tenant VRF:
   r1 -- r2 in VRF blue.
2. Advertise a prefix from r1 in the VRF, for example 192.0.2.1/32.
3. Wait until r2 shows the BGP route as best and it is installed in the VRF.
4. Stop only zebra on r2; keep bgpd and the BGP session running.
5. Restart only zebra on r2.
6. Check show bgp vrf blue ipv4 unicast 192.0.2.1/32,
   show ip route vrf blue 192.0.2.1/32, and ip route show in the VRF.

Expected behavior

After Zebra reconnects, bgpd should replay existing selected routes for
every BGP instance, including tenant VRF instances (the same way ospfd,
ripd and isisd replay routes for all of their instances on reconnect).

Actual behavior

The BGP route remains best in bgpd's VRF instance, but Zebra's VRF table
and the kernel are missing it.

Additional context

bgp_zebra_connected() replays the selected routes via
bgp_zebra_announce_table() but only for bgp_get_default(). Unlike
ospfd/ripd/isisd, which iterate all their instances on reconnect, the bgpd
reconnect callback never visits the tenant VRF instances, so their routes
stay in the BGP RIB but are missing from a restarted Zebra and the kernel
FIB.

Checklist

• I have searched the open issues for this bug.
• I have not included sensitive information in this report.