Technical Tip: Routing Change and Session Fail-over with SD-WAN
Description
This article explains the Routing Change and Session Fail-over with SD-WAN.
Scope
FotiGate.
Solution
The three interfaces (Port 1, 2 and 3) are configured over an SD-WAN zone and participating in a Performance SLA.
If the Failure Threshold was reached for port3 (5 unanswered consecutive probes), the SLA state of Port3 switches to dead for health-check SLA_ISPs.
FGT-1 # diagnose system virtual-wan-link health-check SLA_ISPs
Health Check(SLA_ISPs):
Seq(1): state( alive ), packet-loss(0.000%) latency(50. 871), jitter(1.862) sla_map=0x0 <----- Port 1
Seq(2): state( alive ), packet-loss(0.000%) latency(80. 789), jitter(0.534) sla_map=0x0 <----- Port 2
Seq(3): state( dead ), packet-loss(5.000%) sla_marOx0 <----- Port 3
Health Check(SLA_ISPs):
Seq(1): state( alive ), packet-loss(0.000%) latency(50. 871), jitter(1.862) sla_map=0x0 <----- Port 1
Seq(2): state( alive ), packet-loss(0.000%) latency(80. 789), jitter(0.534) sla_map=0x0 <----- Port 2
Seq(3): state( dead ), packet-loss(5.000%) sla_marOx0 <----- Port 3
From FortiOS 6.4./ 7.x onward, the command to check status of SDWAN performance SLA is as follows:
FGT-1 # diagnose system sdwan health-check SLA_ISPs
Health Check(SLA_ISPs):
Seq(1): state( alive ), packet-loss(0.000%) latency(50. 871), jitter(1.862) sla_map=0x0 <----- Port 1
Seq(2): state( alive ), packet-loss(0.000%) latency(80. 789), jitter(0.534) sla_map=0x0 <----- Port 2
Seq(3): state( dead ), packet-loss(5.000%) sla_marOx0 <----- Port 3
Health Check(SLA_ISPs):
Seq(1): state( alive ), packet-loss(0.000%) latency(50. 871), jitter(1.862) sla_map=0x0 <----- Port 1
Seq(2): state( alive ), packet-loss(0.000%) latency(80. 789), jitter(0.534) sla_map=0x0 <----- Port 2
Seq(3): state( dead ), packet-loss(5.000%) sla_marOx0 <----- Port 3
If update-static-route is enabled, all static routes over Port3 via next-hop 203.0.113.2 are removed from the routing table. The 'inactive' flag is added:
# FGT-1 # get router info routing-table database
(...)
5 *>. 0.0.0.0/0 [1/0] via 192.2.0.2, portl
*> [1/0] via 198.51.100.2, port2
[1/0] via 203.0.113.2, port3 inactive
(...)
5 *>. 0.0.0.0/0 [1/0] via 192.2.0.2, portl
*> [1/0] via 198.51.100.2, port2
[1/0] via 203.0.113.2, port3 inactive
After a routing change, sessions are re-validated and may fail over to another SD-WAN member.
Example of routing change:
- The order of 'oif' interfaces in the policy-route changes.
- An SD-WAN member switches to a dead state.
- Dynamic route update.
After the static routes removal, existing sessions over Port3 must be re-validated against the firewall policies.
The following constraints apply for the re-validation of NAT sessions:
- NAT sessions are only re-checked against firewall policies if this setting is explicitly enabled:
config system global
set snat-route-change enable
end
- NAT sessions are only re-checked against firewall policies performing NAT with the same 'NAT-IP'.
- Example: Sessions fail over between public internet links is possible if the same 'public IP' is used to NAT traffic via all ISPs (BGP/dynamic routing peering is needed).
- For this case, configuring IP-Pool over the policy is necessary.