Technical Tip: Routing Change and Session Fail-over with SD-WAN

[pkungatti_FTNT]

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 # 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. 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

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.