Hi,
I'm deploying FortiGate SDWAN with dual-hub (DC and DRC) with many spokes. The spokes may not required to communicate each other, so that ADVPN is optional.
I have routing challenge when I use iBGP between Hubs and Spokes. At the first, the iBGP includes Hub to Hub, Hub DC to Spokes, Hub DRC to Spokes. Then behind the hub is connected with router which is running OSPF. In that case, I need redistribute the spokes prefix from BGP into OSPF, but I found some routing loop issue in the behind caused by redistribution and advertises OSPF between DC router <> DRC router and advertises iBGP between Hub DC <> Hub DRC.
My colleague advise me to use eBGP instead of iBGP for Hubs to Spokes and Hub to Hub.
I need insight about what impact or disadvantage if I use eBGP in SDWAN deployment. Since I learn that the best practice of FortiGate SDWAN is to use iBGP.
Thank you in advance.
Solved! Go to Solution.
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.
I don't know if or how SD-WAN settings would effectively work in you dynamic routing situation. Because if you remove SD-WAN completely, your network is still completely redundant at least for DC reachability, or to network behind DC/DRC. However, if each spoke has two IPsecs over two different local internet circuits to both DC and DRC (totally 4 IPsecs per spoke), then SD-WAN probably can control which tunnel to be used for what kind of traffic per HUB (DC or DRC).
And internet bound traffic is probably completely different story, which you didn't mention about.
So I'll avoid commenting on anything about SD-WAN.
If you draw a topoloby diagram, it would be much clearer. But I'm assuming those two hub FGTs are OSPF's ABRs neighboring each other over OSPF (in addition to BGP neighboring) so that both can share the infomation about the same spoke networks coming from BGP. Otherwise, it might cause routing loops ospf->bgp->ospf.
On BGP side, the key is a router wouldn't re-advertise iBGP learned route to another iBGP neighbor. Because iBGP is IGP. It's meant to share route in internal network. So I would do iBGP between DC and DRC or between two HUBs, then set up eBGP between the HUB and spokes, so that all spoke advertised routes would be re-advertised another hub over iBGP.
Toshi
Hello arie_arie,
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.
Thanks,
I don't know if or how SD-WAN settings would effectively work in you dynamic routing situation. Because if you remove SD-WAN completely, your network is still completely redundant at least for DC reachability, or to network behind DC/DRC. However, if each spoke has two IPsecs over two different local internet circuits to both DC and DRC (totally 4 IPsecs per spoke), then SD-WAN probably can control which tunnel to be used for what kind of traffic per HUB (DC or DRC).
And internet bound traffic is probably completely different story, which you didn't mention about.
So I'll avoid commenting on anything about SD-WAN.
If you draw a topoloby diagram, it would be much clearer. But I'm assuming those two hub FGTs are OSPF's ABRs neighboring each other over OSPF (in addition to BGP neighboring) so that both can share the infomation about the same spoke networks coming from BGP. Otherwise, it might cause routing loops ospf->bgp->ospf.
On BGP side, the key is a router wouldn't re-advertise iBGP learned route to another iBGP neighbor. Because iBGP is IGP. It's meant to share route in internal network. So I would do iBGP between DC and DRC or between two HUBs, then set up eBGP between the HUB and spokes, so that all spoke advertised routes would be re-advertised another hub over iBGP.
Toshi
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 |
---|---|
1705 | |
1093 | |
752 | |
446 | |
230 |
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.