One of the main advantages of Cisco SD-WAN is that it works over any mix of WAN transports in an automated, secure, and flexible manner. The solution builds a fabric of overlay tunnels, either IPsec or GRE, between all WAN edge routers over any available transport. The process of establishing the fabric is fully automated, and the traffic that goes through these tunnels is encapsulated, encrypted, and authenticated.

The solution is essentially just that - a mesh of IPsec/GRE tunnels automatically built over any transport underlay, as shown in the figure above. In a simplified language, we can summarize each SD-WAN capability as a function of the overlay fabric of tunnels:

• SD-WAN routing is simply choosing an outgoing overlay tunnel for a destination.
• Controlling the topology is simply specifying between which sites vEdge routers can establish overlay tunnels.
• Application-aware routing (AAR) is just choosing the best overlay tunnel for an application based on pre-defined SLA.
• Public cloud integration is simply building IPsec tunnels to vEdges hosted in the cloud provider.
• Middle-mile optimization is simply building overlay tunnels to a Colocation or Software-defined Cloud Interconnect (SDCI) provider.
• Cloud-delivered security is simply establishing overlay tunnels to a SASE provider such as Cisco Umbrella.
• Securing the forwarding plane is simply encrypting and authenticating the data traffic with the overlay tunnels using IPsec.

You can see that everything in the Cisco SD-WAN solution revolves around the overlay fabric that is established between the WAN edge devices. Therefore, it is essential to really understand how vEdges form and maintain the fabric and how we can manipulate and customize the process. So let’s deep-dive into the data plane.

The Default Fabric Behaviour

Suppose we have a WAN edge router with two connections to two different WAN providers - Internet and MPLS. The router will have two TLOCs - one that represents the Internet link and one that represents the MPLS circuit. By default, the SD-WAN solution behaves like the following (visualized in the figure below):

• A vEdge router advertises its TLOCs to the vSmart controller. 
• The vSmart controller stores all received TLOCs in a TLOC table. If no policy is applied, the controller advertises all TLOCs to all vEdge routers.
• Every vEdge router attempts to form an overlay tunnel with every TLOC in its TLOC table over each connected WAN transport. The only exception is that a vEdge does not try to create a tunnel with TLOCs that have the same site-id or the same system-IP.

Let’s look at the example shown in figure 2 above. If vEdge-1 receives two TLOC routes (let’s name them T3 and T4) from vSmart, it immediately attempts to form a tunnel to each of the received TLOCs (T3 and T4) over each of its own TLOCs (T1 and T2). Therefore, this will result in the following tunnels:

1. T1< -- >T3
2. T2< -- >T3
3. T1< -- >T4
4. T2< -- >T4

You can see that one TLOC, for example, T1, does not represent one tunnel - a TLOC is a tunnel endpoint for all remote TLOCs.