Technical Tip: Understanding unexpected Next-Hop behavior in FortiGate ADVPN with BGP

In a hub-and-spoke ADVPN topology with BGP (often iBGP in the same AS), hubs commonly act as route reflectors (RRs) to propagate routes between spokes without requiring a full-mesh peering.

By default, when a hub reflects a route from one spoke to another, it preserves the original next-hop IP (the originating spoke's tunnel IP) rather than rewriting it to its own IP.

This is intentional in ADVPN to enable spoke-to-spoke shortcuts: Traffic initially flows through the hub, but upon detection, a direct IPsec tunnel forms between spokes, bypassing the hub.

This preservation can appear 'unexpected' if it anticipates hub-centric routing, where the hub's IP should always be the next-hop.

In iBGP, next-hops are not automatically changed (unlike eBGP), and standard next-hop-self does not apply to reflected routes, only to local or eBGP-learned ones.

As a result, commands like get router info bgp neighbors received-routes may show next-hops as spoke IPs, even though the routes are advertised by the hub.

In this diagram:

• The hub reflects routes between Spoke1 and Spoke2, preserving the next-hop (e.g., Spoke1's route to Spoke2 uses 10.1.1.3 as next-hop).
• Once traffic flows, ADVPN triggers a direct shortcut tunnel between spokes.

Configuration Steps Leading to the Issue.

On the hub:

Step 1: Set Up IPsec Tunnels for ADVPN.

config vpn ipsec phase1-interface

    edit "ADVPN-Hub"
        set interface "port1" <----- WAN interface.
        set peertype any
        set proposal aes256-sha256
        set psksecret <secret>
        set auto-discovery-sender enable # <----- Enables shortcut triggering.
    next
end

config vpn ipsec phase2-interface
    edit "ADVPN-Hub"
        set phase1name "ADVPN-Hub"
        set proposal aes256-sha256
    next
end

On spokes (e.g., Spoke1 and Spoke2), use similar configs with auto-discovery-receiver enabled.

Step 2: Configure BGP on the Hub as a Route Reflector.

config router bgp
    set as 65001
        config neighbor
            edit "10.1.1.2" # Spoke1 tunnel IP
                set remote-as 65001
                set next-hop-self enable <----- Affects local/eBGP routes only.
                set route-reflector-client enable <----- Enables reflection.
            next
                edit "10.1.1.3" # Spoke2
                set remote-as 65001
                set next-hop-self enable
                set route-reflector-client enable
            next
        end
        config network
            edit 1
                set prefix 192.168.1.0 255.255.255.0 <----- Hub's local network.
            next
        end
end

Step 3: Configure BGP on Spokes

config router bgp
    set as 65001
        config neighbor
            edit "10.1.1.1" <----- Hub tunnel IP.
                set remote-as 65001
            next
        end

        config network

            edit 1
                set prefix 172.16.1.0 255.255.255.0 <----- Spoke local network.
            next
        end
end

Verification:

This default config leads to the behavior, as 'next-hop-self' does not modify reflected iBGP routes.

Use 'get router info bgp network' on spokes to observe preserved next-hops (e.g., Spoke1 sees Spoke2's route with Spoke2's IP as next-hop, advertised via hub).

To modify this default behavior, refer to the following article:

Technical Tip: Explanation of 'set next-hop-self-rr enable'