SDWAN and Tunnel Monitor config

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

SDWAN and Tunnel Monitor config

L1 Bithead

Hi All,

 

I'm trying to get my head around SD-WAN and tunnel monitoring, specifically SD-WAN AutoVPN creates Tunnels with tunnel monitor turned on with a destination IP of the other side of the tunnel and the Tunnel Monitor profile set to sdwan-default. If I then look in Network Profiles -> Monitor  see sdwan-default configured with an action of wait-recover, inverval of 3 seconds and Threshold of 5. If I lookup the help for this page I notice the following:

 

Action
Specify an action to take if the tunnel is not available. If the threshold number of heartbeats is lost, the firewall takes the specified action.
wait-recover—Wait for the tunnel to recover; do not take additional action. Packets will continue to be sent according to the PBF rule.
fail-over—Traffic will fail over to a backup path, if one is available. The firewall uses routing table lookup to determine routing for the duration of this session.
In both cases, the firewall tries to negotiate new IPSec keys to accelerate the recovery.

 

Does this seem counter intuitive to anyone? Or is my understanding just off? The help talks about PBF rules not sdwan but if I try and read between the lines I come up with that wait-recover for an SD-WAN top down traffic distribution profile won't force traffic onto other working tunnels that are higher cost, it will sit there and wait for the top tunnel to recover? So if we want to use other working tunnels we should create a sdwan-default monitor profile and set it's action to fail-over, or alternatively set a SD-WAN policy that has a traffic distribution profile that is not top down but either best path or weighted distribution (not that this is always desirable). Does anyone know why the sdwan-default monitor profile would be set to wait-recover by default, is this just an oversight/bug or do you think most people would want a top down sdwan traffic distribution profile to not fail over onto other link types if the main tunnels were down?

 

BTW my experience with this is currently with TAC, but I have seen during a failure event traffic for sdwan.902 (tunneled traffic) does not fail over to a lower tunnel in the sdwan.902 list (which contains tunnel.901 through tunnel.906, during failover of which only tunnel.903-906 would be up) and eventually ends up trying to pass across to the INTERNET zone and out to the internet. Clearing the session for this traffic fixes it but I am curious as to if it is the tunnel monitor that is causing it to not failover in the first place or if the traffic trying to follow the default route out to the internet is some other bug and the tunnel monitor is just a red herring.

 

Thanks,

Kevin-John

1 REPLY 1

L6 Presenter

Did you check the SD-WAN Guide?  https://docs.paloaltonetworks.com/sd-wan/2-0/sd-wan-admin/configure-sd-wan/sd-wan-traffic-distribut...

 

 

For an existing session to failover the Top-Down Priority is used as written and it should force traffic on other not best paths if there is an issue.

 

 

For monitoing select Aggressive if it is not LTE of Satelite link and there is also info VPN traffic

 

https://docs.paloaltonetworks.com/sd-wan/2-0/sd-wan-admin/configure-sd-wan/configure-sd-wan-interfac...

 

 

 

For more about SD-WAN VPN:

 

https://docs.paloaltonetworks.com/plugins/sd-wan/2-0/panorama-sd-wan-plugin-help/panorama-sd-wan-plu...

  • 3060 Views
  • 1 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!