Description
This article explains the Routing Change and Session Fail-over with SD-WAN
Solution
Let us consider the three Interfaces port 1, 2 and 3 are configured over an SD-WAN interface and participating in a Performance SLA.
If the Failure Threshold was crossed for port3 (5 consecutive probes remained unanswered), the SLA state of port3 switched to dead for health-check SLA_ISPs.
# FGT-1 # diag sys 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
If update-static-route is enabled, all static routes over port3 via next-hop 203.0.113.2 are removed from the routing table.
# 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
- After a routing change, sessions are re-validated and may fail over to another SD-WAN member
Example of routing change:
1) The order of oif interfaces in the policy-route changes
2) An SD-WAN member switches to dead state
3) Dynamic route update
- After removal of the static routes, existing sessions over port3 must be re-validated against the firewall policies.
The following constraints apply for re-validation of NAT sessions:
- NAT sessions are only re-checked against firewall policies if this setting is explicitly enabled:
1) The order of oif interfaces in the policy-route changes
2) An SD-WAN member switches to dead state
3) Dynamic route update
- After removal of the static routes, existing sessions over port3 must be re-validated against the firewall policies.
The following constraints apply for 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”
- For e.g., session fail over between Internet accesses is possible only if the same “public IP-range” is used to NAT traffic via all ISPs (BGP/dynamic routing peering needed)
Note: Here, Configuring the IP-Pool over the policy and having route via Dynamic peer is very important.
