SD-WAN - Route Leaking between VPNs

SD-WAN - Route Leaking between VPNs

SD-WAN - Route Leaking between VPNs

In our rapidly evolving IT industry, we consistently introduce novel devices and technologies to our established network, ensuring its ongoing dynamism and adaptability. One notable paradigm shift is the emergence of Software Defined Networking (SDN) Technologies in the past 10 years. These SDN technologies promote controller-based configuration to bestow configurational scalability across the enterprise infrastructure. A prime example of this transformative technology is Software Defined Wide Area Network (SD-WAN).

SD-WAN Architecture

SD-WAN empowers you to configure, operate, and maintain a private WAN through a centralized suite of controllers. Within Cisco's SD-WAN framework, the underlay traffic and overlay traffic (comprising end-user data traffic) are segregated into distinct Virtual Routing and Forwarding (VRF) instances.

Understanding VPNs and VRFs in Cisco SD-WAN

Cisco SD-WAN utilizes the term "VPNs" to denote these VRFs. Should you desire the partitioning of end-user data traffic, the allocation of routes to separate VPNs (VRFs) accomplishes this. The VPNs dedicated to end-user data are referred to as Service VPNs. As a default behavior, traffic remains demarcated among various VPNs.

Purpose of This Guide

The purpose of this blog is to delve into the configuration necessary to facilitate controlled inter-VPN (inter-VRF) communication via route leaking. We will achieve this by working through an example.

Example Topology

Cisco SD-WAN Topology Diagram

In the topology shared below, the present status indicates that both Service VPNs are fully functional and are in communication with each other, yet they remain segregated. The objective at hand is to establish communication between the 172.16.X.0/24 and 10.10.X.0/24 networks.

Configuration Steps

We will start the task at hand by thoroughly examining the steps necessary for configuring inter-VPN communications between these two Service VPNs. The realization of inter-VPN communication hinges on the practice of route leaking, whereby routes are shared from one VPN to another. This process is executed by configuring a Topology Policy on the vManage platform and subsequently deploying it to the WAN Edges through vSmart.

We will start the task at hand by thoroughly examining the steps necessary for configuring inter-VPN communications between these two Service VPNs. The realization of inter-VPN communication hinges on the practice of route leaking, whereby routes are shared from one VPN to another. This process is executed by configuring a Topology Policy on the vManage platform and subsequently deploying it to the WAN Edges through vSmart. 

Now, let's delve into an in-depth exploration of the sequential steps essential to achieve this objective:

    1. To enable vSmart management and configuration from vManage, a vSmart Device Template within vManage needs to be set up. The necessary steps to accomplish this are outlined below:

    1. Execute the “ Show Run” command on the vSmart device.
    2. Highlight and copy the config.
    3. Create a Device Template for vSmart using a CLI Template
    4. Paste the copied config.
    5. Attach the vSmart to this template

    2. Moving forward, the subsequent task involves the creation of classification lists, which will play a pivotal role in our Topology Policy. The necessary lists for our configuration encompass Site IDs for individual sites, Service VPN IDs for each VPN, and a compilation of prefixes earmarked for leakage. The classification lists for our configuration are itemized as follows:

    • VPN List:
          1. Name: VPN-10 - ID: 10
          2. Name: VPN-20 - ID: 20
    • SITE List:
          1. Name: DUBAI - ID: 1
          2. Name: London - ID: 2
          3. Name: LA - ID: 3
    • Prefix List:
        1. Name: PL-VPN-10 Prefix: 172.16.0.0/16 le 32
        2. Name: PL-VPN-20 Prefix: 10.10.0.0/16 le 32

    3. Our next undertaking involves the creation of a Topology Policy aimed at executing route leaking, utilizing the lists crafted in the preceding phase. This endeavor will be guided by the following attributes:

    1. Name: ROUTE-LEAKING-10-20 Desctiption: ROUTE-LEAKING
    2. Policy # 1:
      1. Condition: VPN-ID = VPN-10 & Prefix=PL-VPN-10
      2. Action: Export To: VPN-20
    3. Policy # 2:
      1. Condition: VPN-ID = VPN-20 & Prefix=PL-VPN-20
      2. Action: Export To: VPN-10
    4. Default Policy:
      1. Action: Accept

    4. Upon the successful creation of the Topology Policy, the subsequent step entails establishing a Centralized Policy and integrating the previously crafted Topology Policy. Once the Topology Policy is imported, the subsequent action involves its application on the vSmart device for incoming routes from the three designated sites. The directives listed below outline the procedure for generating the Centralized Policy:

    1. Name: CENTRAL-POLICY
    2. Topology Policy: ROUTE-LEAKING-10-20 (Import the Policy)
    3. Apply the policy to incoming routes from DUBAI, London & LA
    4. Activate the policy. By activating the policy, it will apply it on vSmart.

Validation and Conclusion

At this juncture, upon inspecting the routing table on the internal routers stationed at the Dubai, London, and LA sites, you will observe the comprehensive inclusion of routes for both the 172.16.X.0/24 and 10.10.X.0/24 networks. To further validate the connectivity, you can employ Ping or Traceroute commands to ascertain reachability. This configuration denotes the establishment of Inter-VPN communication.

I hope this gives you a good understanding of the steps involved and the general procedure that one needs to follow in order to establish a controlled inter-VPN (inter-VRF) communication via route leaking.