Virtual Routing is a technique which allows managing multiple instances of a typical router on a single system. This post describes the level of performance required to support Virtual Routing. A second post will describe how it can be implemented within a Linux-based control plane and Fast Path-based data plane, such as provided by 6WIND’s packet processing software.
Virtual Routing (VR), Virtual Routing and Forwarding (VRF) and Virtual Routers are techniques that were initially developed by MPLS designers who needed to isolate multiple sub-routing areas on the same LER.
The main concept was to tag or “ color” the packets with a VR ID based on the incoming MPLS LSP (or MPLS tag), and then execute the route lookups in the forwarding table based on the index of this VR ID. In order to populate all the VR ID tables, multiple instances of OSPF, BGP, RIP, ISIS or even static routes are executed independently. Each routing daemon receives the signaling packets of its VR through its per VR socket. This technique allows interconnecting multiple PEs for different customers on a single ingress LER without duplicating the HW resources.
Since the concepts of Virtual Routing are not specifically related to MPLS implementations but rather to the capability of tagging or coloring packets, VR has been increasingly deployed in environments comprising VLANs or tunnels (IPsec, GRE, GTP-u, L2TP, IPinIP). The main problem with tunnels compared to MPLS is that packets are associated with a VR ID and then once decapsulated they need to be processed into another VR. Consider as an example IPsec VR and the problem of defining the SADs and SPDs with the proper VR IDs according to ingress and egress flows. This requires fine-grained support of cross-VR processing.
For all those uses cases, both the packet processing Control Plane and Data Plane (Fast Path) are involved in this virtual processing.
In core networks for wired and wireless infrastructure, systems can comprise thousands of VRs. There are several options for implementing VR on a multicore CPU:
- use one dedicated hardware thread or core for each VR, though this approach does not scale well to thousands of Virtual instances
- use virtual instances of the OS and Control Plane based on VMWare, XEN, KVM, etc, though this also doesn’t scale well to thousands of Virtual instances, neither does it support cross-VR for complex use cases such as IPsec
The next post in this series will review how to use a multicore CPU to implement a scalable VR implementation.