Description
When advertising a static route to an iBGP neighbor, the next hop information of that static route is not changed to a FortiGate IP but to the one of the next hop in the static route definition.
This article describes this feature.
Scope
FortiGate.
Solution
Example:
config router bgp
set as 65000
set router-id 10.140.1.1
config neighbor
edit "10.0.0.1"
set remote-as 65000
next
end
config network
edit 1
set prefix 10.10.10.0 255.255.255.0
config redistribute "static"
set status enable
config router static
edit 4
set dst 10.10.10.0 255.255.255.0
set gateway 192.168.10.1
set device "internal"get router info bgp network 10.10.10.0 <----- On the peer side.
BGP routing table entry for 10.10.10.0/24
Paths: (1 available, best 1, table Default-IP-Routing-Table)
Not advertised to any peer
Local
10.140.1.1 from 10.0.8.1 (192.168.10.1)
Origin incomplete metric 0, localpref 100, valid, internal, best
Last update: Tue Feb 4 02:25:22 2020
Advertising to a BGP peer by using both a network statement and redistribute static for a prefix which is also mentioned in a static route entry, the local BGP routing table will have 2 entries:
get router info bgp network
BGP table version is 2, local router ID is 10.140.1.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.10.10.0/24 0.0.0.0 100 32768 0 i <-/-> *>
*> 192.168.10.1 32768 0 ? <-/1>
The first entry does not have a BGP NextHop because it is inserted into the BGP table due to the 'network' statement for 10.10.10.0.
The second entry has a BGP next-hop because it is inserted into the BGP table due to the 'redistribute static' statement.
The redistribution process preserves the original next-hop from the source protocol (here, static route) as well as other original attributes (e.g., an OSPF cost would become a BGP MED).
The best of this two prefixes (the one with '>' which has a BGP NH) is announced to the peer via iBGP. Consequently, BGP NH 192.168.10.1 is preserved when the prefix is advertised to the peer.
The spoke therefore sees the next-hop of the original static route.
If this behavior is not wanted, two options are proposed:
- Use only network statements for the static commands.
- Use a route map when redistributing static and change the next hop to an IP on the FortiGate.
Modifying the next hop:
Static routes via IPsec tunnel do not have a Gateway IP. Redistributing such routes into BGP will add the tunnel ID as the next hop
for the BGP prefix. This can be modified by creating a route-map and specifying the next hop manually using 'set-ip-nexthop'.
In this topology, Hub-FGT (ADVPN with BGP) is redistributing static route of the Site-to-Site IPSEC into BGP.
Before configuring set-ip-nexthop in HUB-FGT, Spoke-FGT sees the route to 10.15.0.0/16 with next hop ip 10.0.0.6:
Hub-FGT # get router info routing-table details 10.15.0.0
Routing table for VRF=0
Routing entry for 10.15.0.0/16
Known via "static", distance 10, metric 0, best
* via Site-to-Site tunnel 10.0.0.6 vrf 0, tun_id
Hub-FGT # diagnose vpn ike gateway list name Site-to-Site
.
tun_id: 10.0.0.6/::10.0.0.6
.
Hub-FGT # get router info bgp neighbors 172.16.100.25 advertised-routes | grep 10.0.0.6
*>i10.15.0.0/16 10.0.0.6 100 32768 0 ? <-/->
Spoke-FGT # get router info routing-table details 10.15.0.0
Routing table for VRF=0
Routing entry for 10.15.0.0/16
Known via "bgp", distance 200, metric 0, best
Last update 00:00:20 ago
* vrf 0 10.0.0.6, tag 1 priority 1 (recursive via 24.173.215.41, wan2), best-match
After configuring set-ip-nexthop in a route-map of Hub-FGT and apply it in BGP settings, Spoke-FGT sees 10.15.0.0 with next hop IP address 172.16.100.1.
Hub-FGT configuration:
config router route-map
edit "Set-Nexthop"
config rule
edit 1
set match-ip-address "IPSEC-Into-BGP" <----- prefix-list 10.15.0.0/16
set set-ip-nexthop 172.16.100.1
next
end
next
end
config router bgp
config redistribute static
set status enable
set route-map "Set-Nexthop"
end
end
Hub-FGT # get router info bgp neighbors 172.16.100.25 advertised-routes | grep 10.0.0.6
*>i10.15.0.0/16 172.16.100.1 100 32768 0 ? <-/->
Spoke-FGT # get router info routing-table details | grep 10.15.0.0
B *> 10.15.0.0/16 [200/0] via 172.16.100.1 tag 1 (recursive via ADVPN tunnel 10.0.0
.2), 00:01:45, [1/0]
In the example above, route-map was applied on 'config redistribute static' on the Hub. Based on the topology, it could be instead be applied as route-map-out in the Hub's BGP neighbor or neighbor-group configuration.
config router bgp
config neighbor-group
edit "advpn-spokes"
set route-map-out "Set-Nexthop"
next
end
end
