Fortigate advpn sdwan bgp route summary

[antonio993]

Hello guys,

I am labing fortigate advpn sdwan with bgp routing. I am trying to summarize the spoke's lan networks in the hub but when doing this I loose spoke-to-spoke shortcut vpn and all traffic is forced through the hub. Cisco has NHRP to solve this issue to override the bgp spoke routing so exact route can be received from the other spoke. How I can summarize of fortigate in the hub firewall so I can have on-demand shortcuts in the spokes? Thank you so much.

[atakannatak]

Hi @antonio993 ,

I think this is the one of the core challenge of using route summarization with ADVPN on FortiOS. For example; what's actually happening: You have Spoke A with 10.10.1.0/24, and Spoke B with 10.10.2.0/24. Both advertise their LANs to the HUB using BGP. If the HUB then summarizes these subnets into 10.10.0.0/16 and re-advertises the summary to the other spokes, it can lead to potential issues with routing and direct spoke-to-spoke communication.

• Spoke A will see: "To reach 10.10.0.0/16, go to HUB."
• Spoke B will also see: "To reach 10.10.0.0/16, go to HUB."
• Result: All traffic goes through HUB — NO shortcuts. For spoke-to-spoke shortcuts to work, the exact destination prefix must be advertised to the other spoke so that the FortiGate can trigger shortcut creation. If a spoke only sees a summarized route (like /16), it cannot form a shortcut.

To preserve spoke-to-spoke communication, the hub must advertise the specific /24 routes to the other spokes — summarization must be avoided or done selectively outside of ADVPN peers.

In the opposite scenario, where summarization is done on the spoke, let's say Spoke A has the subnets 10.10.1.0/24 and 10.10.2.0/24, and it summarizes them as 10.10.0.0/16 and advertises that to the hub, then the hub—and all other spokes—only learn the summary route via Spoke A. This may become a problem when, for example, Spoke B attempts to establish a shortcut tunnel directly to 10.10.1.0/24. If it only receives the summarized route (10.10.0.0/16), it might not have the specific prefix required to trigger the shortcut tunnel. As a result, the shortcut may not be established, and traffic could end up routing through the hub instead. Since shortcut tunnels typically depend on the presence of exact prefixes, summarizing on the spoke side can potentially hide those routes from other spokes, which might interfere with direct spoke-to-spoke communication.

You mentioned that you tested this in a lab environment—would it be possible for you to revise your lab setup to explore the scenario where route summarization is done on the spoke side? I believe this could provide valuable insights, especially in understanding the practical impact on ADVPN shortcut behavior. It would be greatly appreciated if you could share your observations and results with the community afterward.

BR.

If my answer provided a solution for you, please mark the reply as solved it so that others can get it easily while searching for similar scenarios.

CCIE #68781