Cisco SD-WAN Dynamic on-demand Tunnel Feature

Fig 1.1- Cisco SDWAN Dynamic on-demand Tunnel Feature

Problem Statement

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.

 Hope you find this informative.