I have a PA-220 with dual ISPs (WiFi and LTE). I tried to configure SD-WAN for direct internet access (DIA). Both gateways (routers from both ISP) are localy connected via ethernet. As far as I know, SD-WAN pings the gateway IPs to calculated the link quality and because they are both locally connected, there is usually no issue. The troubles on WAN links usually happen somewhere beyond the first hop. Is there a way how to modify the IP address that is used for path monitoring?
I understand that, but the second PAN device is applicable only to the VPN use case. There is no "other end of the link" when SD-WAN is used in DIA setup. So for this case let's asume we use only one device without any VPN tunnel.
I've looked at the documentation, and to me it suggests that SD-WAN does need something at the other end, otherwise you might as well just ping 188.8.131.52 and fail between outgoing interfaces, no?
Looking at this document: https://docs.paloaltonetworks.com/sd-wan/1-0/sd-wan-admin/configure-sd-wan/sd-wan-traffic-distributi...
I don't see that there's any logic for the internet side of things at all, the traffic steering only takes place over the VPN links between offices based on the path quality profiles that you'd be configuring. If I'm wrong, somebody please correct me.
That's exactly what I am trying to figure out. Without SD-WAN I can setup two default routes in virtual router and use any IP (e.g. 184.108.40.206) for path monitoring, this works fine but only for black-outs, so when one link totally fails. But I am looking for solution that will redirect the traffic via different ISP when the latency of the first link is above some threshold.
But when the SD-WAN device is used as the default route in virtual router, the path monitoring cannot be used.
Does anybody have experience with SD-WAN used only in DIA setup?
I think you're trying to use a hammer to drill a hole. Even the illustrations that Palo Alto are using that include the internet show SAAS applications at the other side which implies that Prisma Access is acting as the remote SD-WAN device.
Are you using ECMP at all? I think that is where I will be looking once our second link is in place.
Well ECMP is not the right solution, the links are not the same cost, WiFi and LTE. Also the bottleneck is not on my side, but it is the providers network, 3rd or 4th hop from my router. The idea is to switch traffic to send link (LTE) when the performance of the 1st (WiFi) is not acceptable. I do not think that access to SaaS applications implies the use of Prisma Access. Look at this overview, there is no information about the other (cloud) device.
It looks like the documentation is not complete and I am trying to setup something that is not possible.
I am having the same question. We use SD-WAN to connect remote locations back to a hub however we use the DIA for internet traffic. We have a wired primary connection and a wireless backup connection. Yesterday the primary went down because of a fiber cut past the first hop. I have a distribution profile set to Top Down with my Primary as the main connection for outbound internet and our VOIP. So when the fiber cut occurred the link could still contact the first hop so it never failed over the secondary link that was in my Top Down profile. The remote location stayed connected back to the hub because the SD-WAN. So same question how can you do an external link monitor for the DIA connections?
You must include a PQP for the SD-WAN policies that control your DIA traffic,
even though the DIA VIF does not perform end-to-end path monitoring. The DIA VIF inherits the path
monitoring state of the IPSec tunnels sourced from member interfaces.
Starting with versiion 10.0.2 you could use saas application monitoring as well.
Hope this helps.
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!