SDWAN SLA performace in spoke1 choose shortcut tunnel to spoke2 because the latency is more small than main tunnel to the hub.
SDWAN SLA performace in spoke2 choose main tunnel to spoke2 because the latency is more small than main tunnel to the hub.
With this case spoke1 and spoke2 can't communiate. DOing the packet sniffer i can see traffic from LAN spoke1 is reach to spoke2 but spoke2 will reply using main tunnel to the hub.
How we can deal with asymetric routing like this due to different SLA performance result?
Hello HS08,
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,
Hello,
We are still looking for someone to help you.
We will come back to you ASAP.
Thanks,
Hello HS08
The info in this tech tip should be a very good starting point:
If I understand well, I think a possible solution is to force it with a policy route, to force the traffic return from where it comes (if asymmetric or auxiliary enabled). Otherwise the traffic returns from the coming interface, right?
I think it's a network design problem or conflict. I konw you're using AD-VPN in addition to SD-WAN. AD-VPN detects a new spoke via HUB when it's added to the network and establish a spoke-to-spoke VPN automatically, while SD-WAN doesn't add a new member of zone or even can't detect it automatically. Once it's in a zone asym-routing shouldn't happen. But you have to manually add it and add proper rules as well. Nothing is automatic with the current FGT SD-WAN. Means they don't work together well if co-exist.
Toshi
When connection from spoke to the hub using MPLS or private link with different vendor, let say spoke1 - hub using MPLS from vendor1 and spoke2 - hub using MPLS from vendor2. With this scenario i believe there is no direct traffic from spoke1 to spoke2 even vpn shortcut created.
I can see traffic from LAN spoke1 to spoke2 passing thru the hub but return path from spoke2 to spoke1 using shortcut tunnel.
So are you have comment should we still use advpn or just make point to point from every spoke to the hub and only enable the BGP and SDWAN without ADVPN?
Created on ‎08-20-2025 11:10 PM Edited on ‎08-20-2025 11:11 PM
MPLS is a private connection just like VPN over internet would provide. Some MPLS provider's implementation might include MPLS VPNs. If there is a MPLS connection that section doesn't need a VPN. But if you want to have spoke-to-spoke direct connection, you might need a VPN between them over the internet.
ADVPN is a technology when all private connections require VPN over the internet. It wouldn't work well in your situation. If you set up BGP effectively that's probably all you need for routing.
But if just one point-to-point, MPLS from a vendor would be quite expensive. Unless those locations are spread multiple countries and one vendor can't physically provide all connections, consolidating all connections into one MPLS network (some MPLS vendors can connect their MPLS networks together on vendor sides to provide one MPLS network to customers) would make your network much simpler and they can take care of routing including spoke-to-spoke direct connection over the MPLS.
Toshi
hi @Toshi_Esumi
Your statement "ADVPN is a technology when all private connections require VPN over the internet" this mean if the link between spoke and hub using private MPLS connection then ADVPN is not suitable?
Currently yes i already have MPLS connection from spoke1 to hub and spoke2 to hub. The spoke located in different country and for sure both MPLS using different provider so there are no routing or VPN on provider side.
That's my shallow understand of FGT ADVPN since I never used ADVPN. If that's wrong, somebody else would correct me.
Toshi
User | Count |
---|---|
2593 | |
1382 | |
800 | |
659 | |
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.