Description
This article describes the FortiOS v7.4.7 and earlier behavior that the BGP route with better AD 20 is not installed into the routing table while the OSPF route with AD 110 is preferred (if any BGP link fails the BGP routes will not come back as long as OSPF is online).
The route received from OSPF is redistributed into BGP.
Scope
FortiOS before v7.4.8, including FortiGate v7.4.7 and earlier, v7.6.2 and earlier.
Solution
The following article is relevant for FortiOS v7.2 as well as v7.4 versions up to and including v7.4.7. In FortiOS v7.4.8 and later, the routing logic is changed to use administrative distance of the original parent route instead of BGP weight in order to prevent a possible loop between the BGP and NSM processes. In the first GA releases which include this change (Issue ID 1085314, v7.4.8 and v7.6.3), there is another known issue which causes the administrative distance of a redistributed route to not be calculated correctly if a route map is applied. This issue is resolved in v7.4.9 and v7.6.4. See Issue ID 1171689 in FortiOS v7.4.8 Release Notes | Known Issues.
Topology:
FGT1 receives 10.0.0.0/24 network via FGT2 over BGP. <----- Primary Route.
FGT1 receives 10.0.0.0/24 network via FGT3 over OSPF. <----- Backup path.
FGT 1 configuration:
config router ospf
set router-id 172.16.16.1
config area
edit 0.0.0.0
next
end
config ospf-interface
edit "1"
set interface "port2"
next
end
config network
edit 1
set prefix 172.16.16.0 255.255.255.0
next
end
end
config router bgp
set as 64512
set router-id 172.17.17.1
config neighbor
edit "172.17.17.2"
set remote-as 64513
next
end
config redistribute "ospf" <----- Redistributed OSPF into BGP.
set status enable
end
end
Before the BGP link failure, manually clear the BGP neighborship.
FGT1 # get router info bgp neighbors 172.17.17.2 received-routes | grep 10.0.0.0/24
*> 10.0.0.0/24 172.17.17.2 0 0 64513 i <-/->
FGT1 # get router info routing-table details | grep 10.0.0.0/24
B 10.0.0.0/24 [20/0] via 172.17.17.2, port3, 00:00:22
The route received from BGP is installed in the routing table and the OSPF route kept in the database table.
FGT1 # get router info ospf route | grep 10.0.0.0/24
O 10.0.0.0/24 [101] via 172.16.16.2, port2, Area 0.0.0.0
FGT1# get router info routing-table database | grep 10.0.0.0/24
O 10.0.0.0/24 [110/101] via 172.16.16.2, port2, 00:01:05 <----- OSPF in the database.
B *> 10.0.0.0/24 [20/0] via 172.17.17.2, port3, 00:02:55
After BGP link failure/manually clearing the BGP neighbourship:
FGT1 # get router info routing-table details | grep 10.0.0.0/24
O 10.0.0.0/24 [110/101] via 172.16.16.2, port2, 00:09:44
The OSPF route in the database table installed into the routing table once the BGP link down.
After the BGP link is restored, the original primary route is not installed into the routing table. The OSPF route with higher AD 110 is preferred over BGP AD 20.
FGT1 # get router info bgp neighbors 172.17.17.2 received-routes | grep 10.0.0.0/24
*> 10.0.0.0/24 172.17.17.2 0 0 64513 i <-/->
FGT1 # get router info routing-table details | grep 10.0.0.0/24
O 10.0.0.0/24 [110/101] via 172.16.16.2, port2, 00:17:38
The issue occurs because the OSPF route is redistributed into BGP.
FGT1 # get router info bgp network
VRF 0 BGP table version is 2, local router ID is 172.17.17.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight RouteTag Path
* 10.0.0.0/24 172.17.17.2 0 0 0 64513 i <-/->
*> 172.16.16.2 101 32768 0 ? <-/1>
Total number of prefixes 1
The network 10.0.0.0/24 learned via its peer 172.17.17.2 is having default weight 0 but the redistributed network from OSPF (next hop 172.16.16.2) to BGP has 32768.
When the eBGP link went down, the OSPF route was installed into the routing table and redistributed into BGP routing table.
The redistributed route in BGP is considered locally originated so it has a default weight of 32768.
When the eBGP link comes back up, the BGP routing table will have 2 entries for the same network so, considering the best path selection, BGP chooses the one with the higher weight so it will remain with the route learned from OSPF.
It is possible to avoid this by configuring the BGP weight for the route to be higher than the locally injected routes (OSPF).
Example:
config router prefix-list
edit "Test-Network"
# config rule
edit 1
set prefix 10.0.0.0/24
end
end
config router route-map
edit "test-map"
# config rule
edit 1
set match-ip-address "Test-Network"
set set-weight 32769
end
config router bgp
config neighbor
edit 172.17.17.2
set route-map-in "test-map"
next
end
end
Hub # get router info bgp network
VRF 0 BGP table version is 2, local router ID is 172.17.17.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight RouteTag Path
*> 10.0.0.0/24 172.17.17.2 0 32769 0 64513 i <-/1>
* 172.16.16.2 101 32768 0 ? <-/->
Total number of prefixes 1
Now the weight has changed to 32769 which is higher than the redistributed network and the route will be installed in routing table.
This workaround is not necessary in v7.4.8 and later. In these firmware versions, the administrative distance of the original parent protocol (OSPF in this case) is used before BGP weight when comparing redistributed routes.
