Understanding the switch mechanism and how links are chosen
When each metric is measured or calculated, each link is evaluated: this involves comparing the last measurement (latency) or last metric calculation (jitter or packet loss rate) with the value set in the SD-WAN SLA. If this measurement does not meet the thresholds that have been configured, the link will be considered degraded.
A link may therefore be described by 3 possible statuses:
- Optimal: the link is available and metric calculations/measurements meet the defined SLA thresholds.
- Degraded: one or several metrics do not meet the defined SLA thresholds.
- Unavailable: the link cannot be used following an incident.
The tables below show the link switching mechanisms, and the chosen links for the various possible types of connections.
In this document, the 3 possible statuses are represented by the following symbols:
-
: optimal link, -
: degraded link, -
: unavailable link.
New incoming connections
In a four-link configuration (two main links and two backup links), the table below shows how the links will be chosen based on their respective status at a given moment, and based on the chosen configuration (whether there is load balancing, threshold values, etc.).
| Main links | Backup links | Order of links used according to the configuration | ||||||
|---|---|---|---|---|---|---|---|---|
| No load balancing | With load balancing | |||||||
| When at least one gateway cannot be reached | When all gateways cannot be reached | |||||||
| Link 1 | Link 2 | Link 3 | Link 4 |
|
Enable all backup gateways |
|
Enable all backup gateways | |
|
|
|
|
|
1 | 1 and 2 | 1 and 2 | 1 and 2 | 1 and 2 |
|
|
|
|
|
2 | 2 | 2 | 2, 3 and 4 | 2 and 3 |
|
|
|
|
|
3 | 3 and 4 | 3 and 4 | 3 and 4 | 3 and 4 |
|
|
|
|
|
4 | 4 | 4 | 4 | 4 |
|
|
|
|
|
1 | 1 and 2 | 1 and 2 | 1 and 2 | 1 and 2 |
|
|
|
|
|
1 | 1 | 1 | 1, 3 and 4 | 1 and 3 |
|
|
|
|
|
3 | 3 | 3 | 3 | 3 |
|
|
|
|
|
2 | 2 | 2 | 2 | 2 |
|
|
|
|
|
3 | 3 and 4 | 3 and 4 | 3 and 4 | 3 and 4 |
|
|
|
|
|
4 | 4 | 4 | 4 | 4 |
|
|
|
|
|
The policy defined in the router object's If no gateways are available field is applied:
|
||||
|
|
|
|
|
3 | 3 | 3 | 3 | 3 |
|
|
|
|
|
2 | 2 | 2 | 2 and 3 | 2 and 3 |
|
|
|
|
|
2 | 2 | 2 | 2, 3 and 4 | 2 and 3 |
|
|
|
|
|
1 | 1 and 2 | 1 and 2 | 1 and 2 | 1 and 2 |
Existing connections
Default route with failover (no load balancing) or static routing
| What happens to passing connections when the gateway is changed | |
| Address translation (NAT) | When the gateway changes* |
| No NAT | Connections are kept during the switch |
| With NAT (NAT policy, or via a proxy) | RST packet is sent to the client of a TCP connection, and the connection table is purged (UDP and TCP) |
*depending on the rules described in the table New incoming connections.
Default route with load balancing or policy-based routing
| What happens to passing connections when the gateway is changed | ||||||
| Address translation (NAT) | When the gateway status changes | |||||
|
➟ |
➟ |
➟ |
➟ |
➟
|
➟ |
|
| No NAT | Connections are kept | Connections are kept during the switch | Connections are kept | None | ||
| With NAT (NAT policy, or via a proxy) | RST packet is sent to the client of a TCP connection, and the connection table is purged (UDP and TCP) | |||||
Connections initialed by the firewall
| What happens to connections initialed by the firewall when the gateway is changed |
| When the gateway changes* |
| The connection table is purged (UDP and TCP) and service resumes |
*depending on the rules described in the table New incoming connections.