VRF – Virtual Routing and Forwarding

(Part II) Virtual Routing and Forwarding

This is the second part in the series of posts dedicated to network virtualization and path isolation.

Ever needed one extra router? It’s possible to split the router into more logical routers by using VRF. How? Here’s how!

Virtual Routing and Forwarding or VRF allows a router to run more that one routing table simultaneously. When running more routing tables in the same time, they are completely independent. For example, you could use overlapping IP addresses inside more VRFs on the same router and they will function independently without conflict (You can see this kind of overlap in the example below). It is possible to use same VRF instance on more routers and connect every instance separately using VRF dedicated router port or only a sub-interface.

You can find VRFs to be used on ISP side. Provider Edge (PE) routers are usually running one VRF per customer VPN so that one router can act as a PE router for multiple Customer Edge (CE) routers even with more customers exchanging the same subnets across the VPN. By running VRF per customer, those subnets will never mix in-between them.

VRFs are used to create multiple virtual routers from one physical router.

Every VRF is creating his own Routing table and CEF table, basically a separate RIB and FIB.

VRF is simply created by entering this command into Cisco router supporting VRFs:

ip vrf MYTESTVRF

When created, VRF needs route distinguisher in order to become functional. Route distinguishers are described a bit later. Route distinguisher (RD) for this VRF  MYTESTVRF are configured with:

rd 111:1

When created and configured with RD, VRF needs some interfaces which will then be dedicated to this VRF and could bring some traffic into this VRF. Router interface (or most probably subinterface), will  be assigned to a VRF like this: 

int gi1/0/1
  ip vrf forwarding MYTESTVRF

On L3 switch which is also a clever router, when we want a VLAN to become part of the VRF, we need to add VLAN interface to VRF and all members of the VLAN will then be part of that special VRF:

int VLAN 20
  ip vrf forwarding MYTESTVRF

You need to take into account that addition of interface to VRF will remove all existing IP addresses configured on the interface. It is done in this way because it can help to avoid address duplication in the new routing table if some incautious engineer is entering interface with IP address into VRF that already has an interface with this same IP.

When configured, traffic received on the interface which is member of VRF is routed and forwarded with that VRF table.

When thinking of VRFs, best example of something similar is VLAN trunking between two switches. Packet with VLAN tag entering the trunk interconnection in-between two switches can only enter the same VLAN when arriving on the other switch side. With VRFs is the same but done on L3 rather L2 for VLANs, and there are no trunk ports but L3 sub-interfaces (or physical interfaces). Packets that enter a specific VRF will be forwarded with routes from that VRF’s routing table.

Example goes even further. Like VLANs that span across multiple switches through trunk port, VRFs can be extended across multiple devices as well through sub-interfaces of two router interconnection or with separate interconnections.

The connections are L3 sub-interfaces, usually Ethernet VLAN interfaces with dot1q encapsulation. Most common Layer 2 virtualisation technique used these days.

VRF

Configuration for both examples

First Example (two interconnections)

R1:

ip vrf MYTESTVRF
  rd 111:1

interface Gi 1/0/1
description Global Routing Table Interconnect
ip address 10.10.10.1 255.255.255.252

interface Gi 1/0/2
description VRF MYTESTVRF Interconnect
ip vrf forwarding MYTESTVRF
ip address 10.10.10.1 255.255.255.252

R2:

ip vrf MYTESTVRF
  rd 111:1

interface Gi 1/0/1
description Global Routing Table Interconnect
ip address 10.10.10.2 255.255.255.252

interface Gi 1/0/2
description VRF MYTESTVRF Interconnect
ip vrf forwarding MYTESTVRF
ip address 10.10.10.2 255.255.255.252

Second Example (dot1q tagged subinterfaces)

R1:

ip vrf MYTESTVRF
  rd 111:1
interface Gi 1/0/1.10
description Global Routing Table Interconnect
encapsulation dot1q 10
ip address 10.10.10.1 255.255.255.252

interface Gi 1/0/1.20
description VRF MYTESTVRF Interconnect
encapsulation dot1q 20
ip vrf forwarding MYTESTVRF
ip address 10.10.10.1 255.255.255.252

R2:

ip vrf MYTESTVRF
  rd 111:1
interface Gi 1/0/1.10
description Global Routing Table Interconnect
encapsulation dot1q 10
ip address 10.10.10.2 255.255.255.252

interface Gi 1/0/1.20
description VRF MYTESTVRF Interconnect
encapsulation dot1q 20
ip vrf forwarding MYTESTVRF
ip address 10.10.10.2 255.255.255.252

ICMP Test Example

Pinging from Gi 1/0/1 to Gi 1/0/1 on other side within Global Routing Table is straight forward ping:

R1:

ping 10.10.10.2

If you want to ping the same (but other) ip address. The one that is inside VRF MYTESTVRF you neet to initiate the ping within that VRF on R1:

ping vrf MYTESTVRF 10.10.10.2

Example above shows both solutions, although the subinterface example is the one that is used in the real world most of the time. We are extending VRF MYTESTVRF to other router (R2) by configuring interfaces of interconnection with VRF mapping configuration (ip vrf forwarding inside interface configuration). In this way every one of the interconnection will forward the traffic for mapped VRF.

Global Routing table is basically a VRF 0. The first RIB and FIB with no need of mapping as they exist by default and all L3 interfaces on the router are by default part of Global Routing table. When expanding VRF MYTESTVRF we use one interconnection but we need to use another interconnection for Global routing table.

 We can look at Global Routing table as first (native) VRF on the router with more VRF configured. This is also known as Global VRF, existing on all routers, with all interfaces assigned to it by default.

VRF Lite

Method of expanding several VRFs across multiple devices by using separate sub-interfaces or separate interconnection links is known as VRF Lite. This is basically the most lightweight way of running VPNs.

Being the simplest way of creating non-overlapping VPNs in a network is having some downsides to. This way of doing VRF expansion has poor scalability. You need dedicated link between two routers for every VPN (or dedicated sub-interface of one link). If you have the need for many VRFs, you will need many provisioned connections between routers.

Route Distinguishers

Remember from above, this is basic VRF config:

ip vrf MYTESTVRF
    rd 111:1

111 and 1 are 32-bit integers. Route Distinguisher is used to label every route from an VRF routing table with 64-bit prefix. It is done so that router can distinguish which prefixes are member of which VRF (different routing tables) avoiding that prefixes from different VRFs are mixed up.

Format for RD should be ASN:NN, with ASN meaning autonomous system and NN VRF number inside the router. Other way to configure it is IP-Address:NN,  IP being the router IP address and NN VRF number.

DOWNLOAD

Examples above configured in GNS3 lab are awailable here for download so that you can run them and try it out by yourself. Everything should work fine with latest GNS3 installed

 

UPDATE on 25 April 2016:
GNS3 Lab for above examples is added. Enjoy labbing.

UPDATE on 26 April 2016:
There was an unintentional error on the last configuration example which missed sub-interface numbers in configuration.

It is corrected now, sorry.

 

Read the whole series about Path Isolation techniques:

Overview:

  • Network Virtualization
  • VRF – Virtual Routing and Forwarding
  • inter-VRF Routing
  • Path Isolation Overview (Policy Based & Control Plane Based)
    • Path Isolation inside LAN
      • Using ACLs (legacy)
      • VRF-Lite & GRE tunnels
      • MPLS VPN
      • VRF-Lite hop-by-hop
    • Path Isolation across the WAN
      • Using ACLs (legacy)
      • VRF-Lite & GRE tunnels
      • MPLS VPN
      • VRF-Lite hop-by-hop

Leave a Reply