| Description | This article describes one identified reason for the creation of a transient shortcut during SLA recovery. |
| Scope | SD-WAN/ADVPN 2.0. |
|
Solution |
Consider the following network topology where spokes have 2 uplinks belonging to the same transport-group:
The SD-WAN service is configured as SLA mode, using the health-check HUB with latency as a link-cost-factor.
config system sdwan config zone edit "sdwan-dc100" set advpn-select enable
config members edit 101 set interface "advpn101" edit 102 set interface "advpn102"
config health-check edit "HUB" ... config sla edit 1 set link-cost-factor latency
config service edit 1 ... set mode sla set priority-members 101 102 Traffic is initiated from spoke-1 to spoke-2, and path management has created a shortcut over the advpn101 overlay (advpn101_0).
get vpn ipsec tunnel summary 'advpn101_0' 198.18.22.2:0 selectors(total,up): 2/2 rx(pkt,err): 9/0 tx(pkt,err): 10/3
Latency increases over advpn101, making the underlay advpn101 and shortcut advpn101_0 out-of-sla (sla_map=0x0). As a result, path management creates a new shortcut initiated from advpn102 (advpn102_0).
get vpn ipsec tunnel summary 'advpn101_0' 198.18.22.2:0 selectors(total,up): 2/2 rx(pkt,err): 817/0 tx(pkt,err): 818/3 'advpn102_0' 198.18.22.2:0 selectors(total,up): 2/2 rx(pkt,err): 22/0 tx(pkt,err): 22/4
Later on, latency decreases back to normal level. At recovery time, a 3rd shortcut has been established initiating again from advpn101 (advpn101-1), but to the other remote end point on spoke-2.
get vpn ipsec tunnel summary 'advpn101_0' 198.18.22.2:0 selectors(total,up): 2/2 rx(pkt,err): 823/0 tx(pkt,err): 824/3 'advpn101_1' 198.18.21.2:0 selectors(total,up): 2/2 rx(pkt,err): 4/0 tx(pkt,err): 4/2 'advpn102_0' 198.18.22.2:0 selectors(total,up): 2/2 rx(pkt,err): 30/0 tx(pkt,err): 30/4
This shortcut has a limited packet count and is no longer in use after several seconds as the initial advpn101_0 is now forwarding again.
One possible explanation for this behavior is provided below and requires a capture of the SD-WAN health-check command during the SLA recovery phase to be confirmed.
Explanation:
The sla of the underaly (advpn101) has recovered faster back in SLA than the the initial shortcut (advpn101-0), as can be seen by the respective sla_map.
diag sys sdwan health-check Health Check(HUB): Seq(101 advpn101): state(alive), packet-loss(30.000%), latency(51.153), jitter(0.479), ….., sla_map=0x1 Seq(101 advpn101_0): state(alive), packet-loss(16.000%), latency(234.383), jitter(33.651), …, sla_map=0x0
During this time, path management has created a new shortcut originating from advpn101 (advpn101_1) to an endpoint different than the initial one, as the advpn101-0 shortcut is still out of SLA and therefore not usable.
Once advpn101_0 shortcut gets back into SLA (sla_map 0x1), the transient shortcut is no longer used and will be flushed if configured to do so after the idle timeout period. |
