Technical Tip: Next hop information in BGP for redistributed static routes

[ciordan]

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.