Cisco SD-WAN Dynamic on-demand Tunnel Feature
Fig 1.1- Cisco SDWAN Dynamic on-demand Tunnel Feature
Problem Statement
 |
| Fig 1.1- Cisco SDWAN Dynamic on-demand Tunnel Feature |
Hub-and-spoke topology is good in a network to access
centralized applications. However, when there is a requirement to have spoke-to-spoke
communication, the tunnel scale, and the hardware sizing for remote locations do
not meet any-to-any communication requirement when it is needed.
Solution
With the SD-WAN version 20.3 release, Cisco has introduced dynamic on-demand tunnels feature where tunnels between the spoke locations are formed when it
is required. In a typical scenario when there is no traffic between remote
sites, these tunnels are inactive. This feature reduces the computation
overhead demand on a router, maintaining the always-on tunnels even if there is
no traffic between spoke locations. In addition to this other advantages
include –
- 1. Reduced management traffic over tunnels – as there is no need to run BFD tunnels between spoke devices as tunnels are inactive
- 2. Direct tunnels between sites reduce the memory usage and CPU cycles
- 3. Maintaining the full-mesh network with small-scale devices installed in remote branch locations
Let’s See under the hood
On-demand tunnel functionality is enabled as soon as dynamic
tunnels are configured for a site. In the case of dynamic tunnels, spoke to
spoke tunnels don’t come up. Hub SD-WAN routers at the central site work as
backup forwarding nodes that provide a secondary path for traffic between two
spoke locations. All spoke locations build the permanent tunnels with Hub location.
The route to the hub location is called the backup route, and it is used for initial
traffic forwarding between the two spoke sites.
TLOCs and the prefix information are shared among the spoke
locations. The on-demand tunnel is established once the traffic gets initiated
from either end of the tunnel. There are two states of the on-demand spoke site
–
Inactive – the on-demand tunnel is not set up with
the remote spoke location; as the tunnel is inactive, there is no BFD sessions;
in this scenario, all the traffic from the remote location is forwarded to the
hub site using the backup path.
Active – the on-demand direct tunnel is set to Up
with the remote spoke location; it is similar to the normal state where an IPsec
tunnel is built between spoke locations with BFD session to check the health
and liveliness of the path. There is an idle timer (ten minutes) to ensure
tunnel termination if there is no traffic between locations. Once the tunnel is
down, the state would change to Inactive.
Series of steps executed between two spoke locations configured with on-demand tunnels –
- Let’s start with two spoke locations as there is no traffic flowing between them, they are in the inactive state
- Traffic initiated by host-1 behind the spoke-1 towards the host-2 at spoke-2
- Spoke-1 Edge forwards the traffic towards the backup path (hub location)
- Spoke-1 provision the on-demand tunnel and form the BFD. Now the tunnel is up between two spoke locations, Spoke-2 transition to Active state for spoke-1
- When spoke-2 receives the return traffic from local-host (host-2), it reverts to host-1 using the hub locations as a backup path
- Spoke-2 provisions the on-demand tunnels, and BFD session is established. Now spoke-1 is active on spoke-2.
- Now there is an on-demand tunnel up between both the spoke locations
- Traffic between spoke locations is tunneled directly using this on-demand tunnel
If there is no traffic between for idle timeout (10 minutes),
this on-demand tunnel is deleted and both spoke sites transition to inactive
state.
 |
| Fig 1.2- Cisco SDWAN Dynamic on-demand Tunnel Feature |
Let’s understand the configuration part with the help of a
demo on how to configure a dynamic on-demand tunnel between two remote locations.
