New Member

Question

Fortigate SD-WAN Traffic not redirected if link down - Requirements not fulfilled

Forum|Forum|3 years ago
August 25, 2022
3 replies
3438 views

Hi guys,

I am currently working on a simple site-to-site SD-WAN solution using only two Fortigates. I am using the models 100E and 100D both running v6.2.10. In this case, one of the Fortigates is acting like an HQ Fortigate and the other one as a remote FG using two dialup vpn connections. The SD-WAN is only activated on the remote Fortigate with the SD-WAN members being the physical Interfaces used by the VPN Tunnels. I've got this running, am now struggeling to implement the rules to fullfill the requirements, which are the following:

Goal is to load balance traffic between one satellite and one LTE link. If the satellite link provides more than 1,5 Mbit/s, traffic with the destination IP 192.168.6.2 is supposed to use that link and the rest shall use the LTE connection. If the satellite connection is slower than 1,5 Mbit/s however, there are two options: If the LTE connection is also slower than 1,5 Mbit/s, traffic shall still be possible, however the link does not matter in this case. If the LTE connection is faster than 1,5 Mbit/s, the entire traffic is supposed to use LTE.

If have been struggling to find where I can define those bandwidth tresholds. However, even by defining latency tresholds, the system is not correctly switching paths, the given requirements are not fullfilled anymore.

If you could give help when it comes to defining the required SLAs and SD-WAN rules, I would be very grateful. Is it necessary to activate SD-WAN on the HQ FG as well?

Best regards

FortiGate

Anthony_E

Staff

Hello florenz,

Thank you for using the Community Forum.

I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible.

Regards,

Best Regards

aionescu

Staff

Hi @florenz ,

It is not possible to configure link bandwidth as a target under Performance SLA.

You said that, "latency thresholds, the system is not correctly switching paths" - can you provide more info about the behavior?

florenzAuthor

New Member

Hi!

Thanks for helping. I now got the SD-WAN rules working the way I want them to - at least sometimes. On other occasions, the system does not behave the way it used to before. I don't understand that because I am working in a controlled test environment and the quality of the links does not change if I don't want them to. Is there any possibility to see, which rule is being applied?

florenzAuthor

New Member

I've done some more troubleshooting and it turns out that the Fortigate tends to use the implicit rule and not the ones I have defined above. I have double checked everything, but all the parameters of the rules are correct, so theoretically the rule should be applied. Has anyone come up with a similar problem? Finding out the rule, that is currently being used would really help me. Is there anything in the diagnostics tools?

aionescu

Staff

Hi @florenz , can you provide more details about the issue you are facing?

You can check the matching policy following the info available at: Technical Tip: Verify the matching policy route - Fortinet Community

florenzAuthor

New Member

Okay, I'll try to provide all the necessary logs and explain it.

We have got two connections, one via DSL (Latency ~1.5ms) and one via Satellite (Latency ~100-200ms). The DSL connection passes through a wan emulator which will increase the latency by 400ms and can be turned on or off. The required SLA target is a ping of 200ms.

The target has changed a bit and is as follows:

Goal is to load balance traffic between one DSL and one SAT link. If the DSL link provides less than 200 ms of latency, traffic with the destination IP 192.168.6.2 is supposed to use that link and the rest shall use the SAT connection. If the DSL connection is slower than 200 ms however, there are two options: If the SAT connection is also slower than 200 ms, traffic shall still be possible, however the link does not matter in this case. If the LTE connection is faster than 200 ms, the entire traffic is supposed to use the satellite connection.

The SD-WAN rules I implemented are the following (OneWeb is the sat connection):

In rules 1-4, the lowest cost strategy has been selected. In SD-WAN settings, the cost of DSL is set to 3 and the cost of SAT to 2, however I guess this should not have an effect. Implicit rule is set to volume at an equivalent ratio.

When I start pinging 192.168.6.2, I get this result:

Connected

FortiGate-100E-Mobile # execute ping-options source 192.168.5.1

FortiGate-100E-Mobile # execute ping-options repeat-count 100

FortiGate-100E-Mobile # execute ping 192.168.6.2
PING 192.168.6.2 (192.168.6.2): 56 data bytes
64 bytes from 192.168.6.2: icmp_seq=0 ttl=63 time=1.5 ms
...
64 bytes from 192.168.6.2: icmp_seq=9 ttl=63 time=1.3 ms
64 bytes from 192.168.6.2: icmp_seq=10 ttl=63 time=401.4 ms
64 bytes from 192.168.6.2: icmp_seq=11 ttl=63 time=401.4 ms
...
64 bytes from 192.168.6.2: icmp_seq=16 ttl=63 time=401.4 ms
64 bytes from 192.168.6.2: icmp_seq=17 ttl=63 time=401.5 ms
64 bytes from 192.168.6.2: icmp_seq=18 ttl=63 time=159.1 ms
64 bytes from 192.168.6.2: icmp_seq=19 ttl=63 time=163.1 ms
64 bytes from 192.168.6.2: icmp_seq=20 ttl=63 time=153.1 ms
...
64 bytes from 192.168.6.2: icmp_seq=35 ttl=63 time=137.8 ms
64 bytes from 192.168.6.2: icmp_seq=36 ttl=63 time=1.3 ms
64 bytes from 192.168.6.2: icmp_seq=37 ttl=63 time=1.2 ms
64 bytes from 192.168.6.2: icmp_seq=38 ttl=63 time=1.3 ms
64 bytes from 192.168.6.2: icmp_seq=39 ttl=63 time=1.2 ms
64 bytes from 192.168.6.2: icmp_seq=40 ttl=63 time=1.3 ms
--- 192.168.6.2 ping statistics ---
41 packets transmitted, 41 packets received, 0% packet loss
round-trip min/avg/max = 1.2/148.6/401.5 ms

So far so good, as I increased the latency of the DSL connection by 400ms, which led to the system changing paths, as the sla were not fulfilled anymore. Even switching back to DSL once the artificial latency was removed, worked.

However, if I ping 192.168.6.1, I get this result:

FortiGate-100E-Mobile # execute ping 192.168.6.1
PING 192.168.6.1 (192.168.6.1): 56 data bytes
64 bytes from 192.168.6.1: icmp_seq=0 ttl=255 time=145.7 ms
...
64 bytes from 192.168.6.1: icmp_seq=13 ttl=255 time=152.9 ms
64 bytes from 192.168.6.1: icmp_seq=14 ttl=255 time=161.9 ms
64 bytes from 192.168.6.1: icmp_seq=15 ttl=255 time=1.4 ms
64 bytes from 192.168.6.1: icmp_seq=16 ttl=255 time=1.1 ms
...
64 bytes from 192.168.6.1: icmp_seq=26 ttl=255 time=1.1 ms
64 bytes from 192.168.6.1: icmp_seq=27 ttl=255 time=1.1 ms
64 bytes from 192.168.6.1: icmp_seq=28 ttl=255 time=162.8 ms
64 bytes from 192.168.6.1: icmp_seq=29 ttl=255 time=152.7 ms
64 bytes from 192.168.6.1: icmp_seq=30 ttl=255 time=1.2 ms
64 bytes from 192.168.6.1: icmp_seq=31 ttl=255 time=1.1 ms
64 bytes from 192.168.6.1: icmp_seq=32 ttl=255 time=1.0 ms
64 bytes from 192.168.6.1: icmp_seq=33 ttl=255 time=1.1 ms
64 bytes from 192.168.6.1: icmp_seq=34 ttl=255 time=1.1 ms
64 bytes from 192.168.6.1: icmp_seq=35 ttl=255 time=1.1 ms
--- 192.168.6.1 ping statistics ---
36 packets transmitted, 36 packets received, 0% packet loss
round-trip min/avg/max = 1.0/73.8/164.0 ms

Starting off, everything looks fine, as the system uses the sat connection as we wish. On packet 15, this connection is cut, so the system successfully switches back to DSL. When reactivating the Sat Link however, the system only switches back to this path for two more pings, after which it uses DSL again.

The moment this happens, the system does not behave like it did before, the ping on 192.168.6.2 now uses Sat as primary if both links fullfill the SLA, and the ping on 192.168.6.1 uses DSL as primary. I could not get my head around this or spot which rules could lead to the system behaving like this. Any help is welcome :)

Best regards

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded