Skip to main content
rajamanickam
rajamanickam
Explorer II
November 11, 2022
Question

ADVPN with self healing SDWAN

  • November 11, 2022
  • 2 replies
  • 2994 views

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..

 

 

2 replies

distillednetwork
distillednetwork
Explorer II
November 13, 2022

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?

 

rajamanickam
rajamanickamAuthor
Explorer II
November 13, 2022

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

distillednetwork
distillednetwork
Explorer II
November 13, 2022

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

rajamanickam
rajamanickamAuthor
Explorer II
November 15, 2022

Yes, we are allowing ping and could see alive state of SLA ....

Terms & ConditionsAccessibility statement