Hello All,
I was trying this in my lab
There is one HUB and two spokes in my SDWAN topology
Spoke1 has 4 overlay interfaces ADVPN_M1, ADVPN_M2, ADVPN_M3, ADVPN_M4.. M1 to M4 are private links (Like MPLS) which has reachability between them as well..
From Spoke 1, I am having SDWAN rule to reach spoke 2 with Best quality strategy out of these 4 interfaces.. Same rule in spoke 2 as well to reach spoke 1
Now I have Self healing SDWAN configured in Hub to identify the best path, as per the configuration I am receiving a good health community and route-tagging it with 1 for M1, 2 for M2, 3 for M3, 4 for M4.. and 5 for bad SLA. I have created SDWAN rule for all source to destination tag 1 as SDWAN rule 1, similarly have created individual SDWAN rules for tag 2 to tag 5..
Now the interesting part is, from spoke 1 as per best quality strategy M2 is being selected since M1 at spoke 1 is not having best quality... Traffic reaches to Hub location, checking the SDWAN rule 1 and sending that traffic in M1 interface to spoke 2. After this, Hub also sending short cut offer to spoke 1 in M2 interface and spoke 2 in M1 interface. Since both M1 and M2 underlays are reachable between them.. From Spoke 2 perspective child tunnel is getting formed as ADVPN_M1_0 and spoke 1 perspective child tunnel is getting formed as ADVPN_M2_0. Issue starts here, from spoke 1 when a PC tries to send traffic to spoke 2, forward path is through ADVPN_M2 which is reaching to spoke 2 and then getting dropped due to RPF failure since Spoke 2 doesnt have any return route neither tunnel formed on ADVPN_M2 child interfaces
Child interfaces are getting formed correctly at spoke 1 in respective interfaces but in spoke 2 it is getting formed only in M1 interfaces (where other end is respective interface).
This is the issue of cross tunneling from Hub. We have configured different Network overlay ID while creating VPN communities but still we could see this cross tunneling..
Not sure whether this is due to any config mismatch or bug behavior..
Any thoughts??.. we are using 6.4.9 code..
if M1 on spoke 2 has access to M2 on spoke 1 the tunnel should form. If it is not forming properly, I would try to setup policy routes on the hub. Create a policy route for each interface that forces M1 to stay on M1 and M2 to stay on M2.
When the shortcut tunnels are setup do you have the routes added into the table properly?
Hi,
Thanks for your reply
Yes could see routes in shortcut tunnels..
If I configure policy routes in Hub for overlay stickiness, whether this will impact other traffic using SDWAN rules in Hub location... Example : If I have All to All SDWAN rule for central internet breakout at Hub location.. Similarly there are other SDWAN rules for Self healing config with source all and destination with respective route tag..
Regards
Raja
If you don't want to do the overlay stickiness, another thing I thought to check is, do you have ping allowed on the spoke tunnel interfaces? When a shortcut tunnel is built, it checks the sla by pinging the other end's tunnel ip. You could check if it is a health-check issue by running:
diag sys sdwan health-check status
Also check the service status
diag sys sdwan service
Yes, we are allowing ping and could see alive state of SLA ....
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 |
---|---|
1737 | |
1108 | |
752 | |
447 | |
240 |
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.