|
Topology used in this scenario is as follows:
The primary IPSec tunnel is named advpn, and the Secondary IPSec tunnel is named advpn2. An SD-WAN Performance SLA has been configured on Spoke pointing towards the loopback IP on Hub:
SDWAN config:
config system sdwan
set status enable
config zone
edit "virtual-wan-link"
next
edit "IPSec"
next
end
config members
edit 1
set interface "port1"
set gateway 20.0.0.254
next
edit 2
set interface "port2"
set gateway 30.0.0.254
next
edit 3
set interface "advpn"
set zone "IPSec"
next
edit 4
set interface "advpn2"
set zone "IPSec"
next
end
config health-check
edit "Google"
set server "8.8.8.8"
set members 1 2
config sla
edit 1
next
end
next
edit "IPSEC"
set server "192.168.99.99"
set members 3 4
config sla
edit 1
next
end
next
end
config service
edit 1
set name "Internal"
set mode priority
set dst "Private"
set health-check "IPSEC"
set priority-members 3 4
next
edit 2
set name "Internet"
set dst "all"
set priority-members 1 2
next
end
end
When checking the performance SLA and the SLA status, the latency that both advpn and advpn2 interfaces have:
diagnose sys sdwan health-check
Health Check(Google):
Seq(1 port1): state(alive), packet-loss(0.000%) latency(0.878), jitter(0.114), bandwidth-up(9999989), bandwidth-dw(9999993), bandwidth-bi(19999982) sla_map=0x1
Seq(2 port2): state(alive), packet-loss(0.000%) latency(0.808), jitter(0.103), bandwidth-up(9999997), bandwidth-dw(9999997), bandwidth-bi(19999994) sla_map=0x1
Health Check(IPSEC):
Seq(3 advpn): state(alive), packet-loss(0.000%) latency(0.660), jitter(0.195), bandwidth-up(9999999), bandwidth-dw(9999999), bandwidth-bi(19999998) sla_map=0x1
Seq(4 advpn2): state(alive), packet-loss(0.000%) latency(0.523), jitter(0.168), bandwidth-up(9999999), bandwidth-dw(9999999), bandwidth-bi(19999998) sla_map=0x1
The latency for advpn is 0.660, and advpn2 is 0.523. Based on how the latency is, FortiGate can either select advpn or advpn2. This would mean that traffic might fluctuate at any time and is not recommended during ADVPn setup.
Especially in a case where the shortcut has a higher latency than the parent tunnel, traffic will go via the parent tunnel, causing RPF failures on the remote end as the remote end is expecting traffic on the shortcut.
To always have the traffic out of the primary tunnel and traffic to use only the secondary tunnel when the primary is down, latency SD-WAN criteria should not be used. In such cases, use manual or lowest-cost SLA criteria (subject to the that SLA is always met by all members at all times)
Ensure that the SD-WAN performance SLA target is customized based on the Internet SLA (5ms latency and 5ms jitter is too low if the device does not have higher speed).
|
