FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
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.
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.
