Virtual Routing and Forwarding (VRF) is a ubiquitous concept in networking, first introduced in the late 1990s as the control and data plane mechanism to provide traffic isolation at layer 3 over a shared network infrastructure. VRF for Linux is an excellent blog that describes the technology behind VRFs, especially as it pertains to the Linux kernel. With the introduction of support for leaking of routes, VRFs get to enjoy their isolation while also having the nous to mix and mingle.
Wait, aren’t VRFs meant to be completely isolated?
You have a valid question there. That was certainly the initial use case for VRFs. Each VRF was intended to represent a customer of a service provider and isolation was a fundamental tenet. Each VRF had its own routing protocol sessions and IPv4 and IPv6 routing tables and route computation as well as packet forwarding was independent from other VRFs. All communication stayed within the VRF other than specific scenarios such as reaching the Internet. Hershey’s wouldn’t want to get too chatty with Lindt, right? No, VRFs weren’t meant to be gregarious.
As VRFs moved outside the realm of the service provider and started finding application elsewhere, such as in the data center or within an enterprise, additional needs arose for VRFs to be a bit more social.
Key use cases for VRF route leaking
As VRFs started representing departments or business functions within an enterprise rather than just an ISP’s customer, the need for some inter-VRF communication arose. Hey, I do need the Friday happy hour notices from Human Resources to reach me, though I may not be able to log on to their servers and give myself a bonus!
In a multi-tenant data center, or even in an enterprise cloud, offering of shared services started becoming common. The Engineering and Marketing teams don’t need their individual email servers, though I daresay the Engineering team deserves its own espresso machine. Services such as storage, backup, security/AAA etc. are often offered or implemented as shared, and made available to multiple tenants as depicted in the diagram below.
Additionally, VRFs regularly need external connectivity. This connectivity may not be limited to just the Internet — it might also be connected to services hosted externally or to other data centers.
All of the use cases above, and others like them, can be addressed by leaking routes between VRFs to get them talking to one another. The leaking of routes results in each VRF getting to know the IP routing information to reach destinations that are part of another VRF.
In Cumulus Linux, you have choice in how you want to implement route leaking between VRFs. You can control this as closely as you would your child’s first foray into social networking by setting everything up through explicit configuration. Or, you can take it easy and just define the broad parameters and let the implementation handle it from there. Let’s dig in a bit more.
Static route leaking — keep things on a tight leash
For strict control of inter-VRF chatter, you configure routes manually in a VRF whose next hops are reachable over an interface that is part of another VRF. This is useful when a small number of specific destinations in a different VRF need to be reachable from another VRF. You can use static route leaking to reach remote destinations in another VRF (ones that are reachable through a next hop router) or directly connected destinations in another VRF. Note that in terms of configuration, you have to configure routes in each of the two VRFs in order to get them to talk. A statically configured leaked route will be active only if the specified next hop or connected destination is active in its original VRF.
Dynamic route leaking — just set the boundaries
What if the strict regime of static route leaking doesn’t work for you? Fear not, Cumulus Linux also supports a more dynamic approach where the system deals with routes as they come and go. All that you have to do is set the boundaries and the system will honor that as routes are moved from one VRF to another.
So, what are these boundaries that I’m speaking of? The only thing you really need to specify is that VRF A is interested in the routes of VRF B. As routes are learned, updated and deleted in VRF B, the system takes care of leaking them over to VRF A. You can of course apply additional control — filtering the routes that get leaked. Again, for a proper dialogue, you have to also specify that VRF B is interested in the routes of VRF A; otherwise, all you have is a monologue which can quickly become dull.
Under the hood, the horsepower for both static and dynamic route leaking is provided by the Free Range Routing protocol suite (FRR). Here is a nice blog if you wanted to know more about this protocol suite. Dynamic route leaking happens via the BGP routing protocol. Here is a way to visualize it:
The advantage of route leaking via BGP is that BGP has well-defined mechanisms for dealing with VRFs and VPNs — constructs such as Route Distinguishers (RDs) and Route Targets (RTs). Fear not though, because once again, we make this simple. FRR has been coded to figure this all out; all you have to do is specify the broad parameters as mentioned earlier. Also, IPv6 aficionados needn’t worry: though the illustration above only refers to IPv4, route leaking for IPv6 routes is fully supported.
Since a party of two can sometimes get a little monotonous, dynamic route leaking can support multiple VRFs. This is particularly useful when shared services are deployed in a specific VRF and many other VRFs need access to this service.
If you’d like to cut to the chase and look at the technical documentation, head here.
VRF route leaking in cahoots with EVPN
We all know hip and trendy gravitate towards one another. Yes, VRF route leaking has applications in an EVPN context too. What is special about this? For one, EVPN has a lot to do with host routes, and that is a level of detail you don’t want to bother with when leaking routes across VRFs. Also, there are a myriad of routing paradigms for EVPN. Cumulus Linux is currently working on a simplified solution for this use case, so check back here for an update in a little while. By the way, for a good recap of EVPN and its support for routing, read this excellent blog.
With the support for VRF route leaking, Cumulus Linux has expanded the reach and power of open networking to more use cases. And in its inimitable fashion, provided a choice of options with simplified configuration. VRFs keep their isolation but are no longer held incommunicado. Who doesn’t like to have their cake and eat it too? I definitely know I do.