Visitor III

Question

SDWAN Asymetric

Forum|Forum|9 months ago
August 14, 2025
8 replies
1821 views

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?

FortiGate

Stephen_G

Moderator

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,

Stephen_G - Fortinet Community Team

Stephen_G

Moderator

Hello,

We are still looking for someone to help you.

We will come back to you ASAP.

Thanks,

Stephen_G - Fortinet Community Team

AEK

SuperUser

Hello HS08

The info in this tech tip should be a very good starting point:

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Policy-Routing-Enhancements-for-Traffic-in-Reply/ta-p/201620

AEK

SuperUser

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?

AEK

Toshi_Esumi

SuperUser

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

HS08Author

Visitor III

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?

Toshi_Esumi

SuperUser

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

Igneus

Explorer

I solved the issue by assigning priorities to each SD-WAN member/route (I have 4 routes per site to reach the peer). I only needed to assign the same priorities on the corresponding routes at both sites, and now the failovers happen symmetrically.

I preferred this approach because we have some voice traffic running between the sites, and it could not tolerate asymmetry, even if the routing was technically correct.

djp

Visitor III

Be careful with ADVPN 2.0. It is really more dangerous that it is helpful, and should really be using only in situation where you have different transits (MPLS & DIA...).

Question, which ADVPN flavor are deploying and is this in lab or production? This will tell us what SLA mechanism you are using and allow me to pinpoint where your configuration issue is at.

djp

Visitor III

I did a video not to long ago on this: https://youtu.be/3SmNWZGlIgw?si=9sMbir2BXQDsJV_W

jamesmarsden8

New Member

For asymmetric routing issues like this, policy-based routing or SLA-aware routing could help ensure replies follow the intended path. On a lighter note, thinking about stable and reliable solutions reminds me of installing a hochwertiger Vinylboden—solid, durable, and dependable under all conditions!

AEK

SuperUser

This is a new feature on 7.6.4.

https://docs.fortinet.com/document/fortigate/7.6.0/new-features/204310/advpn-2-0-enhancement-trigger-just-one-shortcut-for-each-distinct-underlay-path-7-6-4

But actually I'm not very sure if it helps with your issue.

AEK

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded