Hello,
I have to design a network based on sdwan, ibgp and advpn technology by the book, but using three hubs instead of the classical two.
It is possible to implement advpn based on three hubs?
Thank you all
Vincenzo Stolfi
Solved! Go to Solution.
Hi @vincenzo ,
In a typical ADVPN setup with two Hubs, eBGP is used for exchanging ADVPN packets between the Hubs. This approach ensures clear separation of routing information, as iBGP is already managing routing between the Hub and Spokes within the same region. However, if OSPF is used between the Hub and Spokes, then iBGP can be used between the HUBs instead of eBGP.
Although this setup hasn't been tested in a lab on myside with three hubs, a similar two-hub deployment has been successfully implemented. If properly configured, extending the design to three hubs should be scalable and achievable.
Given that a standard ADVPN structure is already in place and Hub-Spoke communication within the same region is functioning correctly, the key challenge is integrating a third HUB into the design while maintaining optimal routing and failover mechanisms.
config vpn ipsec phase1-interface
edit <HUB-to-HUB-Tunnel>
set auto-discovery-forwarder enable # Allows HUBs to forward ADVPN packets between each other
set auto-discovery-sender enable # Enables ADVPN packet transmission from this device
set auto-discovery-receiver enable # Allows this device to receive ADVPN packets
set net-device disable # Disables treating the tunnel as a physical interface (ensures routing works correctly)
set tunnel-search nexthop # Ensures the correct next-hop is used for dynamic tunnel selection
set add-route disable # Prevents automatic route injection (manual BGP/OSPF route control required)
next
end
config router bgp
set as 65001 # Local AS number
set router-id X.Y.Z.T # Unique router ID (usually a loopback or primary interface IP)
config neighbor
edit "A.B.C.D" # Remote BGP peer IP (e.g., HUB2 or Spoke)
set remote-as 65102 # Remote AS number (ensure it matches peer configuration)
set attribute-unchanged next-hop # Preserves the next-hop attribute to avoid incorrect routing
set ebgp-enforce-multihop enable # Allows eBGP sessions over multiple hops (required for ADVPN)
next
end
end
I hope this provides you with a useful perspective. Since testing this scenario in the lab will take some time, I will test it when I get the opportunity and will report the results to you separately.
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
Hello,
Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible.
If anyone knows anything about this topic, please feel free to contribute!
Thanks,
Hi @vincenzo ,
In a typical ADVPN setup with two Hubs, eBGP is used for exchanging ADVPN packets between the Hubs. This approach ensures clear separation of routing information, as iBGP is already managing routing between the Hub and Spokes within the same region. However, if OSPF is used between the Hub and Spokes, then iBGP can be used between the HUBs instead of eBGP.
Although this setup hasn't been tested in a lab on myside with three hubs, a similar two-hub deployment has been successfully implemented. If properly configured, extending the design to three hubs should be scalable and achievable.
Given that a standard ADVPN structure is already in place and Hub-Spoke communication within the same region is functioning correctly, the key challenge is integrating a third HUB into the design while maintaining optimal routing and failover mechanisms.
config vpn ipsec phase1-interface
edit <HUB-to-HUB-Tunnel>
set auto-discovery-forwarder enable # Allows HUBs to forward ADVPN packets between each other
set auto-discovery-sender enable # Enables ADVPN packet transmission from this device
set auto-discovery-receiver enable # Allows this device to receive ADVPN packets
set net-device disable # Disables treating the tunnel as a physical interface (ensures routing works correctly)
set tunnel-search nexthop # Ensures the correct next-hop is used for dynamic tunnel selection
set add-route disable # Prevents automatic route injection (manual BGP/OSPF route control required)
next
end
config router bgp
set as 65001 # Local AS number
set router-id X.Y.Z.T # Unique router ID (usually a loopback or primary interface IP)
config neighbor
edit "A.B.C.D" # Remote BGP peer IP (e.g., HUB2 or Spoke)
set remote-as 65102 # Remote AS number (ensure it matches peer configuration)
set attribute-unchanged next-hop # Preserves the next-hop attribute to avoid incorrect routing
set ebgp-enforce-multihop enable # Allows eBGP sessions over multiple hops (required for ADVPN)
next
end
end
I hope this provides you with a useful perspective. Since testing this scenario in the lab will take some time, I will test it when I get the opportunity and will report the results to you separately.
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
Hi @atakannatak
thank you so much for your reply.
I will start with customer a lab to test the solution with three hubs and three spoke and surely I will use your post as starting point. Also I will implement shortcuts to enhance performace.
I will keep in touch in next weeks with results to share my eexperience.
User | Count |
---|---|
2602 | |
1384 | |
804 | |
664 | |
455 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2025 Fortinet, Inc. All Rights Reserved.