When an organization migrates its existing WAN network to SD-WAN, installing SD-WAN equipment at some sites is not always possible. In such cases, migrated SD-WAN sites should be able to communicate with legacy branches over the underlay MPLS network. Figure 1 illustrates this graphically.

SDWAN sites communicating with non-migrated sites
Figure 1. SDWAN sites communicating with non-migrated sites

An important design consideration here is whether the SDWAN branches need to communicate with the legacy sites directly over the MPLS site or they should pass a centralized location such as a data center. 
Both use cases are feasible options. However, in this lesson, we will show how to enable communication to legacy branches via a regional data center.

The problem with user traffic in the underlay

In Cisco SD-WAN, the WAN interfaces and the LAN interfaces of a vEdge router belong to different VPNs. WAN interfaces are always in the transport VPN0 which represents the underlay. On the other hand, LAN interfaces are always placed in a service VPN. Therefore, data traffic cannot be easily routed between the site-local network and the underlay, because LAN and WAN interfaces are isolated in different VPN segments.

Local breakouts can be used to force data traffic received on a service-side VPN to be forwarded to the underlay (VPN0). However, it is challenging to forcibly transfer data traffic received in the underlay to a service-side VPN, as shown in figure 2 below. (Strictly speaking, it could be possible using NAT and Port Forwarding in VPN0)

Leaking traffic into the underlay
Figure 2. Leaking traffic into the underlay

When facing this design task, many engineers start thinking that if we connect an interface belonging to Transport VPN 0 on the LAN side, we can easily enable the communication between the service-side VPN and the underlay. However, it is not that simple. According to the Cisco SD-WAN specification, in the transport VPN 0, packets received on a transport interface (TLOC-enabled interface) cannot be forwarded to other interfaces. Transport interfaces only serve as tunnel endpoints for the overlay fabric. Additionally, packets coming on other interfaces cannot be forwarded to a TLOC-enabled interface. Figure 3 illustrates this graphically.

Traffic to/from the underlay
Figure 3. Traffic to/from the underlay

The solution to this problem is to enable the local TLOC on a loopback interface instead of on a physical one, as shown in figure 4 below. This allows the router to forward data traffic between the site-local network connected in VPN 0 and the WAN underlay.

Using Loopback as a local TLOC
Figure 4. Using Loopback as a local TLOC

You can learn about the different ways of configuring a loopback interfaces as a local TLOC in the following lesson.

Configuration Example

Now that we have covered the key point in this design challenge, let's go ahead and show an example in practice.

Initial Topology

Figure 5 shows the initial topology that we are going to use in this lab lesson. vEdge1 and 2 represent the data center, while vEdges 3-6 are remote branches. The overlay topology is hub-and-spoke and the mpls color is restricted. Therefore, each branch has one Internet and one MPLS tunnel to the hubs. 

Figure 5. Initial Topology
Figure 5. Initial Topology

The goal of the configuration example would be to enable communication between VPN5 and the legacy branch.

Configuration Steps

Enabling the communication between sdwan branches and the legacy branch requires the following steps at a minimum:

  1. Migrating the local MPLS TLOC to a loopback interface on both hub vEdges. It is currently configured on a physical interface ge0/1.
  2. On the core switches to advertise the legacy branches' subnets to VPN5. Any routing protocol can be used, including static routing in VPN5 on the vEdges themselves. In this example, we will use static routing.
  3. On the core switches to advertise the VPN5's IP range to the transport VPN0. In principle, any routing protocol can be used. However, BGP is most commonly used so we will use BGP in the example as well.

Configuring Loopback TLOC

The first thing that we are going to do in order to enable communication to the legacy branches is to change the local TLOC configuration on the mpls interfaces from the physical interface to a loopback interface. Currently, the local MPLS tloc of vEdge-2 is configured as follows:

#vEdge-2
!
 interface ge0/1
  description WAN-MPLS
  ip address 10.10.0.2/24
  tunnel-interface
   encapsulation ipsec
   color mpls restrict
   allow-service dhcp
   allow-service dns
   allow-service icmp
  !
  no shutdown
 !

The local mpls tloc of the other vEdge router is configured the same way with just a different IP address.

Let's go ahead and migrate the local tloc configuration to a loopback interface. First, we will need to delete the tunnel-interface configuration of the physical interface ge0/1 and configure it on a new loopback interface, as shown in the following output.

Full Content Access is for Registered Users Only (it's FREE)...

  • Learn any CCNA, DevNet or Network Automation topic with animated explanation.
  • We focus on simplicity. Networking tutorials and examples written in simple, understandable language for beginners.
Sign up for free ►