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

  • edited January 2023

    @greggmh123 said:

    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.

    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.

  • edited January 2023

    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.

  • @Bruce_Briggs said:
    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

Sign In to comment.