Skip to main content
sagha
Staff
sagha
Staff
March 14, 2025

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

  • March 14, 2025
  • 0 replies
  • 1266 views
Description This article describes a scenario where FortiGate fails to redistribute BGP routes into OSPF
Scope FortiGate.
Solution
  1. 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
 

                                 Presentation2.png

  1. 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
 
  1. 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.
  2. As an example, consider network 10.15.17.0/24 here on Hub1 where BGP went down with Spoke.
  3. 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

 

  1. Once BGP is restored, this route does not show in the active routing table via BGP from Spoke.
  2. 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.

 

  1. 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 ? <-/->

 

  1. Since the routes learned via Spoke are not in the routing-table of Hub1, they would also not be redistributed into OSPF on Hub1.
  2. 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
      Terms & ConditionsAccessibility statement