Troubleshooting Tip: Shortcuts of Spokes are Not Forming in ADVPN Tunnel

[FortiArt]

Description	This article presents a possible reason why spokes cannot form the dynamic shortcuts given that the ADVPN tunnel is up and running.
Scope	FortiGate with ADVPN.
Solution	Scenario: Consider the following ADVPN topology: Running real-time IKE debug on Hub, Spoke_1, and Spoke_2 does not show any specific error messages. Only Hub attempts to communicate with Spoke_2 are noticeable: Solution: A full check for the ADVPN tunnel and BGP routing configuration, the root cause is represented by missing the following setting: route-reflector-client enable. This setting is under the BGP neighbor configuration on the Hub FortiGate. This setting renders the Hub as a designated router that will reflect routes learned from other iBGP peers. In this case, all spoke FortiGates form a peering relationship only with the Hub FortiGate. Running the IKE debugs on Hub shows the correct negotiation on running 'ping' command from Spoke_1 to Spoke_2 (or 'ping' from source and destination devices behind the spokes): As a result, the spokes formed the dynamic shortcuts as in the following: Note: There could be other possible reasons that prevent the dynamic shortcuts of the spokes from forming. This article only shows one of those possible reasons. Additionally, static routing is not suitable for use as a routing protocol in HUB-spoke topologies and must not be considered as a fallback or workaround in cases where BGP or ADVPN is not functioning. While it may appear to work temporarily in certain spoke-side configurations, it must never be used on the HUB. Only dynamic routing protocols are appropriate for properly configuring and maintaining HUB-spoke topologies.