BGP does not refresh routes in response to a refresh request
blademd opened this issue · comments
Description
If a peer does not send the Graceful Restart Capability, FRR does not consider it an EoR message receiver. If also the peer sends the Enhanced Route Refresh Capability any normal route refresh request from the peer won't be answered because FRR doesn't set the PEER_STATUS_EOR_SEND flag. This flag is checked for every AFI/SAFI pair before sending BoRR. It seems the sending of BoRR is postponed in this case (in vain).
2024-05-31 05:38:08.195 [DEBG] bgpd: [ZA6YQ-H64CG] 192.X.X.X(Unknown) rcvd route-refresh (REQUEST) for IPv4/vpn
2024-05-31 05:38:08.196 [DEBG] bgpd: [GS2BM-BJ0T4] 192.X.X.X(Unknown) rcvd route-refresh (REQUEST) for IPv4/vpn before EoR
Version
FRRouting 10.0 (XXXX) on Linux(6.1.0-21-amd64).
How to reproduce
Imagine a simple topology of two PE routers. One is FRR, another is third-party. There are IGP, LDP, and iBGP adjacencies between them. Under the BGP session, there is 1/128 AFI/SAFI negotiated. The third-party router does not send the Graceful Restart Capability and sends the Route Refresh and Enhanced Route Refresh ones. The FRR router advertises some routes from its VRF table but the third-party router is not ready to receive them (there is no matching RT import). After some time an operator creates a VRF table on the third-party router which RT import policy considers the FRR VPN routes as desirable. The third-party router sends a normal route refresh request to receive VPNv4 Adj-RIB-Out of the FRR router.
Expected behavior
FRR, receiving a normal route refresh request, re-sends its Adj-RIB-Out (according to the rules of RFC 7313) to a peer even though the EoR message has not been sent to the peer before (in case, when FRR hasn't received the Graceful Restart Capability from the peer).
Actual behavior
FRR always considers itself a Graceful Restart capable speaker and validates the presence of the PEER_STATUS_EOR_SEND flag before sending the BoRR message. It prevents sending the BoRR and consequent update of Adj-RIB-Out whether a remote peer hasn't signaled the Graceful Restart Capability.
Additional context
Disabling the Graceful Restart on the FRR router does not alter the behavior. Activating the Graceful Restart on a remote peer fixes the problem.
Checklist
- I have searched the open issues for this bug.
- I have not included sensitive information in this report.
Could you try grabbing the decent package from the Artifacts and testing from here? https://ci1.netdef.org/browse/FRR-PULLREQ3-3502/artifact
Yes, FRRouting 10.1-dev (####) on Linux(6.1.0-21-amd64).
Now I see the FRR router sending an EoR message apriori. That works for me, thanks.