Noobie Link Monitor and SD-WAN questions
On a client's T35 running 12.5.7 U3, I am setting up SD-WAN for the first time and doing the link monitor setup first. The help article here https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/link monitor/link_monitor_about.html states, "Specify a different Link Monitor host for each external interface."
I want to know if their VoIP phone provider's circuit (Fonality/Netfortris) should work best over Spectrum or over their new AT&T connection, so I want to use their VoIP phone provider's FQDN as the target on both of the interfaces. Will that cause problems? Is that what I should be doing to monitor each provider's quality?
On External-1-Spectrum, I have targets of ####.pbxtra.fonality.com and 8.8.8.8 with pinging to both. On External-2-ATT, I have targets of ####.pbxtra.fonality.com and one of AT&T's DNS servers with pinging to both.
What do you think?
Gregg Hill
Comments
Answering my own question, having the same target on both link monitoring interfaces does exactly what I wanted...it allows comparing the performance on the two different circuits going to the same target. I changed from FQDN for the Fonality targets to the IP of that FQDN, just to keep DNS lookups out of the picture
I just looked in the web UI at the SD-WAN loss, latency, and jitter graphs. It is MUCH better on AT&T than Spectrum, especially for jitter.
Gregg Hill
Now my questions (or need to verify that I understand it all) are about how Multi-WAN, Link Monitoring, and SD-WAN all work together. I have 55 policies on the client's T35. One of them is for two VLANs for guest and employee wireless devices to use.
This is my setup:
I have Multi-WAN set with External-1-Spectrum as primary and External-2-ATT as secondary, set to Failover and immediate failback.
I have Link Monitoring for both ISPs with the client's Fonality server as the one to ping monitor for loss, latency, and jitter so that I can compare the circuits, plus Spectrum and AT&T DNS servers as the secondary ping monitors respectively.
In SD-WAN, I have an External-1-Primary action with Spectrum as primary, and I have an External-2-Primary with AT&T as primary.
I am using their guest/employee device VLANs as a test, and I have that policy using the External-2-Primary SD-WAN action. Traffic from those two VLANs goes out the AT&T connection as I expected.
Now my first question about this setup is, for all of the other policies that do NOT have a specific SD-WAN action applied, do Link Monitor and Multi-WAN take over here in case the External-1-Spectrum connection goes down? I suspect that because no SD-WAN action is applied that would override the Multi-WAN settings, that Link Monitoring would cause the connection to fail over to the External-2-ATT connection. That is my desired result, i.e., that if Spectrum goes down, EVERYTHING goes to AT&T, then when Spectrum comes back, it all fails back to Spectrum or AT&T according to the SD-WAN actions applied.
Can anyone verify that is what will/should happen?
Gregg Hill
Another question: I have the recommended minimum of two ping targets for each interface in Link Monitoring. My assumption is that BOTH of External-1-TWC's targets must fail the ping response three time at 5-seconds intervals in order for failover to trip, and that if either interface's targets still get a response from at least one of their targets, then that interface is considered to be up still. That is what would make sense to me.
Gregg Hill
Q: do Link Monitor and Multi-WAN take over here in case the External-1-Spectrum connection goes down?
A: that is how I understand it to work
If one has 2 link monitor targets for an external interface, it makes no sense to me that if 1 gets no reply and the other does, to consider the link down.
This should be clarified in the docs, but isn't.
Answering my own "...for all of the other policies that do NOT have a specific SD-WAN action applied, do Link Monitor and Multi-WAN take over here in case the External-1-Spectrum connection goes down?" question, a few minutes after I posted that question, the client's Spectrum connection was detected as down and everything failed over to the ATT secondary line. How's THAT for timing a question? IT all failed back to Spectrum within a minute of the failover.
I thought I was losing my mind (and I was right, but that's beside the point). So, yes, if one does not have an SD-WAN action defined on a policy, it will get the global Multi-WAN action applied, which in my case, was to failover to the secondary circuit. The timing of it threw me off completely.
Gregg Hill
Thank you , Bruce. At least I did grasp it correctly. It has been a rough few days.
Gregg Hill
That's correct but that brings up a related question for me. Multi-WAN seems inferior to SD-WAN so in order to use SD-WAN, we'd have to select it on every single policy?
It would be better if Multi-WAN also had the metric options for loss, latency, and jitter. Either that or let us select one of our SD-WAN options as the route method on the Multi-WAN page.
I look at Multi-WAN as providing a general goal for outgoing packet routing, and SD-WAN as providing specific routing for non-general routing needs.
Some applications are more sensitive to performance issues.
SMTP and most file transfers are not, but some like VoIP are.
It is not obvious to me that I want or need to apply latency and jitter values to SMTP etc. TCP does a fine job of handling packet loss and retransmissions for non time critical data transfers.
I'm use SD-WAN to send guest traffic over a second isp and fails over to the primary if the second goes down. The opposite is set up for everything else using Multi-WAN so at the moment the guest network has better link monitoring.
I had an issue a couple times now where many web sites were barely loading on the primary isp. A single ping target wasn't causing a fail over so I was looking for more options. For now, I've added a second tcp target and checked the box to require all the probe to all targets to be successful to see if that helps.
If you would like some future version of Fireware to have Multi-WAN with options for loss, latency, and jitter, then post for this on the Product Enhancements section.
Firebox - Product Enhancements
https://community.watchguard.com/watchguard-community/categories/firebox-product-enhancements