Cisco NX-OS VXLAN Innovations Part 1: Inter-VNI Communication Using Downstream VNI

In this blog, we’ll look closely at VXLAN EVPN Downstream VNI for intra-site and inter-site (Inter-VNI communication using Downstream VNI).

Segmentation is one of the basic needs for Multi-Tenancy. There are many different ways to segment,  be it with VLANs in Ethernet or VRFs in IP Routing use-cases. With Virtual Extensible LAN (VXLAN), segmentation becomes more scalable with over 16 million assignable identifiers called VNI (Virtual Network Identifier). Traditionally, VXLAN segments are assigned in a symmetrical fashion, which means it must be the same to allow communication. While this symmetric assignment is generally fine, there are use cases that could benefit from a more flexible assignment and the communication across VNIs. For example, Acquisition and Mergers or  Shared Services offerings.

During Acquisition and Mergers, it is pertinent to achieve a fast and seamless integration both for the business and the IT infrastructure. In the specific case of the IT infrastructure, we are aiming to integrate without any renumbering. This broken down to VXLAN, we want to provide inter-VNI communication.

In the case of Shared Services, many deployed segments are required to reach a common service like DNS, Active Directory or similar. These shared, or extranet, services are often front-ended with a firewall which avoids the need for inter-VNI communication. Nevertheless, there are cases where specific needs dictate transparent access to this extranet service and inter-VNI communication becomes critical.

There are different methods where inter-VNI communication is used. The most common cases with attached terminology are called VRF Route Leaking. In VRF Route Leaking, the goal is to bring an IP route from one VRF and transport or leak it, into a different VRF. Different needs are present in translation cases. For example,  when you want to represent a segment with a different identifier than what was assigned (think VLAN translation).

Downstream VNI assignment for VXLAN EVPN addresses inter-VNI communication needs, be it for communication between VRFs, or is it for use-cases of translating VNIs between Sites.

Use Case Scenarios

Downstream VNI for shared services provides the functionality to selectively leak routes between VRFs. By adjusting the configuration of the VRF Route-Targets (RT), you have the option to import IP prefixes into a different VRF. Downstream VNI assignment allows the egress VTEP (Downstream) to dictate the VNI used by the ingress VTEP (Upstream). This is to reach the network advertised by the egress VTEP, which would otherwise honor the configured VNI. Downstream VNI complements and completes the need for asymmetric VNI assignment and simplifies the communication between different VRF with different VNIs. For example, the Extranet/Shared Services scenario where a service (DNS Server) sitting in service VRF needs to share the services to all the hosts (servers in different VRFs). The Shared service VRF needs to a) import the multiple VRFs into its local VRF as well as should be b) able to support the disparate value of downstream VNI.

Similar as in the shared services use-case, Downstream VNI provides a method of Translating or Normalizing VNI assignments in a VXLAN EVPN Multi-Site deployment. Where traditionally the same VNIs have to be assigned across all the Sites, with Downstream VNI we can allow inter VNI communication on the Border Gateway (BGW). By aligning the Route-Target configuration between the BGW, Sites with different VNIs will be able to communicate. Exactly as explained for the prior use-case, the egress VTEP (Downstream) dictates the VNI to be used by the ingress VTEP (Upstream) For example, Normalization/Asymmetric VNI deployment scenario, when we are adding new Sites in VXLAN EVPN Multi-Site, on new Border Gateway (BGW), it may be desirable to use and stitch completely disparate values of VNIs.

Benefits

Seamless Integration and Flexible Deployments. With Downstream VNI we have the opportunity for more seamless integration of disjoint networks with the same intent. As a result, a much more agile and time-saving approach is available. For use-cases where Extranet/Shared Service scenario exists, a more flexible deployment option exists with Downstream VNI.

How it works

1. Upon receiving a route update on the ingress VTEP (Upstream), the route is being installed with the advertised VNI from the egress VTEP (Downstream). In short, the prefix is installed with the Downstream VNI.

2. As a result, the egress VTEP dictates the VNI used by the ingress VTEP to reach the respective network advertisement done by egress VTEP. This way, the ingress VTEP uses the right VNI to reach the prefix advertised by the egress VTEP when forwarding data to this peer.

3. The process of Downstream VNI is achieved by the egress VTEP (Downstream) publishing the VNI via BGP control-plane protocol to other receiving VTEPs, which will use this downstream assigned VNI for the encapsulation instruction to send data to the egress VTEP. Data traffic will always be sent with the Downstream VNI assigned to a prefix and will override the otherwise honored configured VNI.

4. The egress VTEP dictates the VNI to be used by ingress VTEP by performing the downstream VNI assignment via the BGP EVPN control-plane protocol.

In the above example, the VTEPs have disparate VNIs i.e. 50001 and 50002. If VLAN 20 with VRF-B needs to communicate to VLAN10 of VRF-A, the VTEP-1 (L3VNI 50001) will act as a Downstream VTEP and dictate VTEP-4 to use VNI 50001 to encapsulate the packets to reach VLAN 10 and vice-versa.

What’s Next?

Stay tuned for our next blogs which cover features and benefits for VXLAN EVPN based data center fabrics such as Loop detection and mitigation in VXLAN EVPN fabrics, deliver packets in secured fashion across VXLAN EVPN sites using CloudSec and seamless integration of multicast packet (TRM) with MVPN (Draft-Rosen).