| Solution |
Design brief:
FortiGate 1: Network 20.0.0.1/32 advertised to BGP peer, and eBGP is implemented between FortiGate 1 and FortiGate 2.
FortiGate 2: Runs both OSPF and BGP, and it learns the route 20.0.0.1/32 from eBGP as well as OSPF.
FortiGate 3: Network 20.0.0.1/32 is advertised in the OSPF domain.
Ideal scenario:
In the unicast routing table on FortiGate 2, the network 20.0.0.1/32 is preferred via eBGP, because the administrative distance of eBGP is 20 when compared to that of OSPF which is 110.
FGT2 # get router info routing-table all
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
V - BGP VPNv4
* - candidate default
Routing table for VRF=0
S* 0.0.0.0/0 [10/0] via 10.5.191.254, port1, [1/0]
C 10.5.128.0/18 is directly connected, port1
B 20.0.0.1/32 [20/0] via 10.5.135.65 (recursive is directly connected, port1), 00:01:26, [1/0]
FGT2 # get router info routing-table details 20.0.0.1
Routing table for VRF=0
Routing entry for 20.0.0.1/32
Known via "ospf", distance 110, metric 101
Last update 00:03:44 ago
vrf 0 10.5.143.180, via port1
Routing entry for 20.0.0.1/32
Known via "bgp", distance 20, metric 0, best
Last update 00:04:09 ago
* vrf 0 10.5.135.65 priority 1 (recursive is directly connected, port1)
If losing the eBGP route, the OSPF route will get installed in the unicast routing table, but when the BGP route comes up, it will replace the OSPF route due to the lower administrative distance.
FGT2 # execute router clear bgp all
FGT2 # get router info routing-table all
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
V - BGP VPNv4
* - candidate default
Routing table for VRF=0
S* 0.0.0.0/0 [10/0] via 10.5.191.254, port1, [1/0]
C 10.5.128.0/18 is directly connected, port1
O 20.0.0.1/32 [110/101] via 10.5.143.180, port1, 00:05:00, [1/0]
FGT2 # get router info routing-table all
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
V - BGP VPNv4
* - candidate default
Routing table for VRF=0
S* 0.0.0.0/0 [10/0] via 10.5.191.254, port1, [1/0]
C 10.5.128.0/18 is directly connected, port1
B 20.0.0.1/32 [20/0] via 10.5.135.65 (recursive is directly connected, port1), 00:00:10, [1/0]
Problem Scenario:
When configuring OSPF to the BGP redistribution, the behavior changes. When the BGP route is lost, the OSPF route takes over, however, when the BGP route comes back, the OSPF route remains as the winner.
FGT2 # execute router clear bgp all
FGT2 # get router info routing-table all
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
V - BGP VPNv4
* - candidate default
Routing table for VRF=0
S* 0.0.0.0/0 [10/0] via 10.5.191.254, port1, [1/0]
C 10.5.128.0/18 is directly connected, port1
O 20.0.0.1/32 [110/101] via 10.5.143.180, port1, 00:05:21, [1/0]
If checking the BGP table, notice the reason for this behavior. The weight of a locally injected route is by default 32,768, which has a bigger weight than the one received by eBGP. In this case, the selection of routes is taking place in the BGP table instead of the routing table.
FGT2 # get router info bgp network 20.0.0.1
VRF 0 BGP routing table entry for 20.0.0.1/32
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
10.5.135.65
Original VRF 0
6501
10.5.135.65 from 10.5.135.65 (1.1.1.1)
Origin incomplete metric 0, localpref 100, valid, external
Last update: Fri Sep 27 13:34:55 2024
Original VRF 0
Local
10.5.143.180 from 0.0.0.0 (2.2.2.2)
Origin incomplete metric 101, localpref 100, weight 32768, valid, sourced, best
Last update: Fri Sep 27 13:34:23 2024
To fix the situation, clear the route from the routing table, in which case the route via eBGP is preferred again, however, this is a manual intervention.
How to Fix:
The scenario described above works only for routes injected via redistribution and not via network command in BGP.
To prefer the eBGP route always, change the weight of the routes being learned via the eBGP neighbor higher than the ones locally injected.
FGT2 # config router bgp
FGT2 (bgp) # config neighbor
FGT2 (neighbor) # edit 10.5.135.65
FGT2 (10.5.135.65) # set weight
weight Enter an integer value from <0> to <65535> (default: <0>).
FGT2 (10.5.135.65) # set weight 40000
<Enter>
Once the BGP neighbor is cleared, the OSPF routes win however as soon as the BGP neighbor comes up, the BGP route takes over, thanks to the higher weight that has been configured in the previous step.
FGT2 # execute router clear bgp all
FGT2 # get router info routing-table all
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
V - BGP VPNv4
* - candidate default
Routing table for VRF=0
S* 0.0.0.0/0 [10/0] via 10.5.191.254, port1, [1/0]
C 10.5.128.0/18 is directly connected, port1
O 20.0.0.1/32 [110/101] via 10.5.143.180, port1, 00:05:00, [1/0]
FGT2 # get router info routing-table all
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
V - BGP VPNv4
* - candidate default
Routing table for VRF=0
S* 0.0.0.0/0 [10/0] via 10.5.191.254, port1, [1/0]
C 10.5.128.0/18 is directly connected, port1
B 20.0.0.1/32 [20/0] via 10.5.135.65 (recursive is directly connected, port1), 00:00:10, [1/0]
Conclusion:
If the OSPF route arrives first:
- OSPF gets installed in RIB.
- BGP network command or redistribution injects this into the BGP table with weight 32768.
- eBGP learned the route arrived from the neighbor.
- BGP route selection happens, and the locally injected route gets preferred due to weight. Based on the BGP best path selection algorithm. This article provides details of the BGP selection process.
The decision happens at the BGP table.
If the BGP route arrives first:
- BGP route gets installed in RIB.
- OSPF route then gets learned.
- OSPF into BGP redistribution does not take place, because redistribution will only happen for routes installed in the RIB.
- The route selection is done based on Administrative Distance comparing eBGP with a value of 20 and OSPF with a value of 110.
The decision happens at the routing table instead of the BGP table.
|
