Technical Tip: FortiGate not redistributing BGP routes received via Spoke into OSPF on Hub location

[sagha]

Description	This article describes a scenario where FortiGate fails to redistribute BGP routes into OSPF
Scope	FortiGate.
Solution	There are two Hub locations, i.e., Hub1 and Hub2. On Hub locations, the BGP route is learned from Spoke, which then gets redistributed into OSPF and sent across the neighbors in the internal network.  config router ospf     set router-id 10.201.250.254     config area         edit 0.0.0.252             set authentication message-digest         next .. ..     config redistribute "bgp"         set status enable     end end                                   If BGP between Spoke and Hub1 or Hub2 goes down, the OSPF routes would also be learned on Hub1 or Hub2 accordingly via internal OSPF neighbors. These OSPF routes would then be redistributed into BGP.  config router bgp     set as 65000     set router-id 10.150.250.253 .. ..     config redistribute "ospf"         set status enable     end end This is where the routing might be affected, as the expectation is to have the BGP route installed in the routing table once the BGP connectivity is restored between Spoke and Hub1. The BGP router, however, is not added to the routing table. As an example, consider network 10.15.17.0/24 here on Hub1 where BGP went down with Spoke. On Hub1, the route is learned via OSPF after BGP went down.  Hub1 # get router info routing-table details 10.15.17.0/24 Routing table for VRF=0 Routing entry for 10.15.17.0/24 Known via "ospf", distance 110, metric 1, best Last update 3d04h49m ago * vrf 0 10.20.25.2, via internal1, tag 2684420093 Once BGP is restored, this route does not show in the active routing table via BGP from Spoke. This does not show in the routing table because the route redistributed from OSPF via BGP is showing as best: Hub1 # get router info bgp network 10.15.17.0/24 VRF 0 BGP routing table entry for 10.15.17.0/24 Paths: (2 available, best #2, table Default-IP-Routing-Table)   Advertised to peer-groups:   VPN1 VPN2 WAN   Original VRF 0   Local     10.100.100.7 from 10.100.100.7 (10.150.250.2)   <----- Via Spoke.       Origin incomplete metric 0, localpref 100, valid, internal       Last update: Tue Mar  4 04:51:56 2025   Original VRF 0   Local     10.20.25.2 from 0.0.0.0 (10.20.25.2)   <----- Redistributed via OSPF.       Origin incomplete metric 1, tag 2684420093, localpref 100, weight 32768, valid, sourced, best       Last update: Tue Mar  4 04:51:55 2025 Once redistributed from OSPF to BGP, a route would have a weight added. Hence, it would be preferred over BGP routes with no weight. The route would also be advertised to the Spoke from Hub. Hub1 # get router info bgp neighbors 10.100.100.7 advertised-routes | grep 10.15.17 *>i10.150.170.0/24 10.100.100.253 1 100 32768 0 ? <-/-> Since the routes learned via Spoke are not in the routing-table of Hub1, they would also not be redistributed into OSPF on Hub1. To fix this:  OSPF routes need to be filtered when advertised back to FortiGate Hub locations via Internal Neighbors. On Hub1 or Hub2, an inbound route map could be applied to ensure that the weight of the BPG routes learned via Spoke is higher so that the routes are installed in the routing table.  config router route-map     edit "RMAP-Weightin"             # config rule                 edit 1                     set set-weight 40000                 next             end     next end