Hi All,
I am planning to setup the below. Using FGT 7.2.4, If you see any bug also please highlight.
Spoke 1 & 2 -------> Hub 1 & Spoke 1 & 2 -------> Hub 2 (Using ADVPN -iBGP)
-------------------
Spoke1 & 2 need to be connected with Hub 1 and Hub2 (Both hubs are running with separate services)
Spoke 1 & Spoke 2 need to be communicated with each other.
Hub 1 and Hub 2 need to be communicated.
All the tunnel interfaces (From Branch to hub 1 and hub 2) in the same Overlay Zone.
--------------------------------
To achieve the above setup using the below protocols.
Between Spoke 1 & 2 ----> Hub 1 & 2 using iBGP (all Spoke and hub locations in the same iBGP AS number)
Between Hub 1 & 2 also using eBGP (or may be iBGP).
------------------------------------
Do you see any challenges on the above setup?
If you have any suggestion then please let me know.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Spoke1 & 2 need to be connected with Hub 1 and Hub2 (Both hubs are running with separate services)
- Each spoke will have routes learned from HUB1 and HUB2 respectively. I am assuming the same routes are not learned by Spoke from each HUB as you have separate services in each location with different IP allocation. If not, please be careful with the route advertisement and route configuration in the spoke to route the traffic correctly to each HUB.
Spoke 1 & Spoke 2 need to be communicated with each other.
- iBGP route reflector client need to be enabled under neighbor-group in HUB to allow route learned from one iBGP neighbor to another iBGP neighbor.
Hub 1 and Hub 2 can be interconencted using eBGP
Please check this article and will be really helpful with your deployments.
Thanks for your response!!!
Query 1:-
Spoke1 & 2 need to be connected with Hub 1 and Hub2 (Both hubs are running with separate services)
- Each spoke will have routes learned from HUB1 and HUB2 respectively. I am assuming the same routes are not learned by Spoke from each HUB as you have separate services in each location with different IP allocation. If not, please be careful with the route advertisement and route configuration in the spoke to route the traffic correctly to each HUB.
REP: So in this case Can I go with the below setup, because ADVPN (shortcut tunnel) should be enabled across all sites to be communicated with each other and should not be dependent on Hub locations.
Spoke1<------Tunnel over iBGP----->Hub1 (RR1 - for Spoke1)
Spoke2 <------Tunnel over iBGP----->Hub2 (RR1 - for Spoke2)
Hub1<------Tunnel over iBGP----------->Hub2
Query2:
Hub 1 and Hub 2 can be interconencted using eBGP
REP: Assuming if I go with the eBGP setup then shortcut tunnel not formed across the spoke locations. it always depends on the hub location. Correct me If I am wrong.
Hello,
I recommend to check this KB:
It has most of the information.
So in your case, if you will have eBGP (over Ipsec) between HUBs and you enable auto-discovery-forwarder, shortcuts will be formed - very similar to dual-region deployment. I think more simple configuration would be to run OSPF between HUBs, to have connectivity. You don't need to have eBGP/iBGP explicitly to make sure that the spokes will have always routes to all spokes via both HUBs. You just need to adjust routing so HUB1 will be primary, HUB2 will be secondary and whenever HUB1 or HUB1's overlays will be unavailable, HUB2 will be used.
Thanks again.
But in my case, Spoke needs to be communicated with both Hub's, because there are different services running on the Hub's. (Hub1 & 2, both are active/active).
so I have to form a full mesh topology, for example
Spoke1 need to be form a tunnel to Hub 1 & 2, Hub1 & 2 acting as RR for Spoke1
So in this case I have a tunnel to both hub's with redundancy for shortcut tunnels too, also there is no single hub dependency.
If hub1 isolated then still can be communicated to other spokes via Hub2.
Here I am assuming the challenges are, Spoke1, hub1 & 2 having 2 WAN links
1. Hub 1 and 2 acting as RR for Spoke1
2. Spoke1 will receive the prefixes from both Hub 1 & 2
3. Spoke - 2 active tunnels each from Hub 1 & 2, so totally 4 tunnels
4. Spoke - 4 active neighbors via iBGP
5. Spoke to Spoke communication happened via Hub1 first
6. If hub1 is isolated then it will go via Hub2
7. Hub to Hub communication can be enabled via iBGP
Please let me know the above statements are fine or any differences that can't be achieved.
Hello,
Yes, this is what it would look like. Then if some services are behind HUB1/HUB2, then you can use SD-WAN on spokes to forward traffic over correct overlay. Still, iBGP between HUBs, I am not sure about that, how effecting it will be, especially depends which prefixes you want to announce over it.
Below is the diagram for example, please suggest.
This is bit complex setup and I would advise you take proper help from our PS team to design this setup with multiple HUB and multiple WAN links.
But here are some suggestions if you wish to try yourself.
- You will have 4 overlay tunnel from each spoke (2 to each HUB across wan1 and wan2).
- Spoke to Spoke shortcuts can be formed using one overlay network per HUB by restricting HUB not to advertise additional path for the same prefixes using command (set additional-path disable).
- IPsec tunnel between HUB1 and HUB2 to allow ADVPN shortcut messages, and eBGP between HUB1 and HUB2 (if not same AS) and iBGP if same AS. This will help you form shortcuts across all spokes and Hubs
Thanks!!
To allow shortcut messages between hub 1 and 2 via iBGP, we need to add the command auto discovery forwarder , right?
Also may I know what will happen if we didn't restrict the advertisement from all overlay tunnels.
If any suggestion then please advise.
Hello TT_DU
Yes, you have to enable auto-discovery forwarder for shortcuts to form.
For your second question,could you please elaborate more on which advertisement are you talking about ?
Regards
Nagaraju.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1547 | |
1031 | |
749 | |
443 | |
210 |
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 2024 Fortinet, Inc. All Rights Reserved.