- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
SDWAN advpn with three hub
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- In a multi-HUB ADVPN setup, the set auto-discovery-forwarder enable command must be configured in the Phase 1 settings of the existing IPsec tunnels to allow ADVPN packet forwarding between HUBs. By default, ADVPN dynamically establishes Spoke-to-Spoke tunnels when a Spoke detects traffic destined for another Spoke. However, when there are multiple HUBs, the HUBs must forward ADVPN signaling packets between each other to ensure Spokes can discover the optimal path.
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
- In an ADVPN deployment with multiple HUBs, eBGP is commonly used for route advertisement between HUBs and Spokes. Below is the recommended eBGP configuration:
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
- In an ADVPN setup, to enable spoke-to-spoke communication across different regions, you should adjust the IPsec Phase 1 settings by using set net-device enable. This allows dynamic routing protocols like OSPF or BGP to function properly, enabling the establishment of multiple tunnels with distinct IP addresses for more flexible routing.
- You will indeed need to configure 3 separate IPsec tunnels to connect each HUB to the others. I mean each pair of HUBs requires a dedicated site-to-site IPsec tunnel. This ensures that each HUB can communicate with the other HUBs in the network. This is necessary because the ADVPN model assumes that traffic between HUBs will be routed through these tunnels using dynamic routing protocols (BGP/OSPF) to ensure proper route advertisement.
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- In a multi-HUB ADVPN setup, the set auto-discovery-forwarder enable command must be configured in the Phase 1 settings of the existing IPsec tunnels to allow ADVPN packet forwarding between HUBs. By default, ADVPN dynamically establishes Spoke-to-Spoke tunnels when a Spoke detects traffic destined for another Spoke. However, when there are multiple HUBs, the HUBs must forward ADVPN signaling packets between each other to ensure Spokes can discover the optimal path.
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
- In an ADVPN deployment with multiple HUBs, eBGP is commonly used for route advertisement between HUBs and Spokes. Below is the recommended eBGP configuration:
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
- In an ADVPN setup, to enable spoke-to-spoke communication across different regions, you should adjust the IPsec Phase 1 settings by using set net-device enable. This allows dynamic routing protocols like OSPF or BGP to function properly, enabling the establishment of multiple tunnels with distinct IP addresses for more flexible routing.
- You will indeed need to configure 3 separate IPsec tunnels to connect each HUB to the others. I mean each pair of HUBs requires a dedicated site-to-site IPsec tunnel. This ensures that each HUB can communicate with the other HUBs in the network. This is necessary because the ADVPN model assumes that traffic between HUBs will be routed through these tunnels using dynamic routing protocols (BGP/OSPF) to ensure proper route advertisement.
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
