This lab lesson will explore another common use case of Cisco SD-WAN centralized control policies - exporting OMP routes between VPN routing tables.

What is Route Leaking?

In the context of Cisco SD-WAN, route leaking is the propagation of routing information beyond its intended scope - a VPN. For example, the site-local routes learned via a routing peer connected in VPN2 are intended for the VPN2 routing table of vSmart. If we export these routes from the VPN2 route table into another VPN route table, this process is called route leaking.

When do we use Route Leaking?

Organizations often need to leak routes between VPN routing tables. A common use case is when an organization wants to provide some shared service to clients connected to different VPNs while at the same time making sure that the clients cannot access each other. For example, access to shared storage, database, software repository, ERP, or any other shared resource.  

The lab topology

In this lab lesson, we are going to manipulate the routing information exchange in such a way that VPNs 3 and 4 can access a shared service located in the data center and connected to VPN 2, as shown in figure 1. At the same time, VPN3 will not be able to access VPN4.

The overlay topology is hub-and-spoke with vEdges 3-6 being the spokes.

To accomplish this design objective, we will use a control-policy action called “export-to.” It allows vroutes to be copied from one VPN route table into another VPN table on vSmart. It is important to note that the action can only be used in an inbound direction from the controller’s perspective and can only be used for service-side VPNs (cannot be used for VPN0 and VPN512). 

Configuring Route Leaking

Configuring route-leaking between VPNs is always a two steps process. First, we need to leak the routes from VPN X into VPN Y. This will allow clients in VPN Y to send packets to clients in VPN X. However, the connectivity will be unidirectional because VPN X would not have a route back to VPN Y. Therefore, the second step will always be allowing bidirectional data plane connectivity by leaking the routes in the reverse direction, from VPN Y into VPN X. 

Applying this logic to our lab example, first, we will inject the vroutes from VPNs 3 and 4 into VPN 2. This is illustrated on the left side of figure 2. Then we will inject the routes from VPN2 into the routing tables of VPN3 and 4. This is illustrated on the right side of figure 2. In the end, we should have bidirectional data-plane connectivity between subnets 10.1.2.0/24 (VPN2) - 10.1.3.0/24 (VPN3) and between 10.1.2.0/24 (VPN2) - 10.1.4.0/24 (VPN4). However, 10.1.3.0/24 (VPN3) must not be able to reach 10.1.4.0/24 (VPN4).

Exporting the VPN 3-4 routes to VPN2

Let’s start with the first step. We need to configure a new control policy that matches the vroutes with VPN-ids 3 and 4 coming from the spokes vEdges. Then we will specify action export-to vpn 2, which will copy the routes in the vSmart’s routing table for VPN2. Let’s translate this objective into configuration logic:

• We need to match vroute with VPN-ids 3 and 4 - therefore we will need a new VPN list that matches vpn-ids 3 and 4. We will name the list SPOKES-SHARED-VPNS;
• We need to match vroutes coming from spokes to vSmart - hence we will apply the control policy to site-list SPOKES in an inbound direction. 
• And the most important thing - when we apply a new control policy, the behavior of vSmart changes, and only the explicitly accepted routes are processed by vSmart. All other routes are silently discarded. This applies to all OMP route types (vroutes, tloc routes, and service routes). Therefore, we either have to explicitly match and accept all other vroutes coming from spokes (in VPNs 1, 5, 6, for example) and all tloc routes or change the default action at the end to be accepted. We are going to go with the latter.

Let’s create a new control policy called SHARED-SERVICES-TO-SPOKES and apply it inbound to site-list SPOKES.