Sometimes while you do routing, you want to do it in a destination-based way and also differentiate routing for different sub-autonomous systems in your AS. Well, such behavior can be enforced by PBR, but it is not that scalable and it lacks some of the nicer things dynamic routing protocols bring to the table. Enter Virtual Routing and Forwarding – VRF Lite (though, different vendors will call it differently) which can be seen as running different routing tables on one physical (or, well, virtual: CSR1000v) router.
Motivation for Virtual Routing and Forwarding (VRF) Lite
VRF Lite is a logical division of routing devices. Virtual Routing and Forwarding allows for software segmentation of the Routing table akin to VLAN of the Switching table of a switch. The use is rather obvious in Service Provider environment, where it is a good practice to separate as far as possible different clients and control traffic of SP’s network itself. The neat thing here is that VRF Lite allows for IP networks to overlap between segments (VRFs) without causing trouble.
But what about Enterprise environment? Here use cases for VRF Lite are more rare, as less than every Enterprise network grows to a size where any of Service Provider technologies has any use. In my experience, there was one case where enterprise security policy required the network to be segregated in that way (while not requiring an air gap at the same time). Something to do with Personal Data and regulations requiring it to be treated separately or something like that.
So, any time we need to work with two or more different systems on as less physical devices as possible (while preserving separation AND redundancy) we can use VRF Lite to help us. Just like Virtual Machines or VLANs or VPNs, basically.
How a router makes sense of VFR Lite configuration
To perform Virtual Routing and Forwarding (lite edition), a router may either:
- run several really separate routing table processes, attaching routing protocol processes and interfaces to them
- run a single routing table, but add another field – VRF tag – to it, and also tag routing processes and interfaces (incoming traffic)
From outside of the router’s black box there won’t be much difference, because the separation is there anyway. There are then some internal resource consumption differences, but it is hard to say if they matter on current generation routers.
Besides routing table segregation, a VRF Lite-enabled router will run different dynamic routing protocol processes for different VRFs. One segment can run OSPF, another EIGRP, or even RIP (insert sloth joke here). Or one segment can run OSPF, and others too – run OSPF (What? Memory is cheap, right?).
But there is a little problem with BGP. For some reason or another, Cisco IOS-based routers can run only one BGP process at a time system-wide. That means that segmentation must be done at the protocol-level, instead of process-level. BGP allows for special route tagging – the community metrics. For VRF Lite in particular, the extended community metrics must be supported. The tags MUST match at both sides of BGP neighbor relationship for this to work, obviously (This is kind of fuzzy between VRF Lite and network-wide VRF, apparently I have to read more on the subject).
Moreover, each and every IP interface (SVI, subinterface etc) is assigned to a VRF. That way, the router knows against which routing table to route incoming traffic and makes the VRF machinery transparent to unsuspecting endpoints.
Note: subinterface dot1q VLAN ID must be unique on a router – endpoint systems cannot share them.
Basic VRF Lite configuration
To create a VRF on a Cisco router, this minimal config is necessary:
ip vrf [vrf-name, like NetworkABCD]
rd [route-distinguisher, like 188.8.131.52:42]
interface [int id, like gi0.149]
ip vrf forwarding [vrf-name, like NetworkABCD]
Here, vrf-name is a name used to distinguish between VRFs in configuration. It is convenient to make it human-readable and relevant to the entity being routed (be it a customer name or system name). The route-distinguisher is what actually separates one routing table from another. Therefore, route distinguisher must be different (but only locally to the router) To run separate routing protocol processes these minimal configs might be used:
router ospf [process-id, like 1] vrf [vrf-name, like NetworkABCD]
For EIGRP (in the new shiny named mode):
router eigrp [process name, like ABCD]
address-family ipv4 unicast vrf [vrf-name, like NetworkABCD] autonomous-system [EIGRP AS number]
[rest of EIGRP configuration]