Configuring VRF-lite on Cisco routers

Overview

VRF which stands for virtual routing and forwarding is a feature that allows a single physical router to segregate network traffic into separate virtual routing instances. A router has only one global routing table by default which includes all connected, static and dynamic learned routes. As an analogy VRFs can be viewed as a segregation feature at layer 3 similar to VLANs at layer 2. If we take the example of an ISP with multiple customers by using VRFs we can have separate routing tables per customer on the same router. VRF-lite is a simple form of VRF implementation which is used without MPLS and is appropriate for small to medium enterprises. Being logically isolated each VRF can use overlapping IP address spaces without conflicting with each other.

VRF-lite configuration

In order to demonstrate how VRF-lite works let’s consider the following scenario using the topology shown below. We have 3 different customers each one having 2 sites connected through the ISP router. Since each customer has sensitive information they will be placed in a separate VRF and the connectivity will be provided through the ISP router. For customers 2 and 3 we will use the same address space to demonstrate that overlapping IPs does not cause any conflicts. One thing to keep in mind is that interfaces assigned to VRFs can be physical or logical and that a interface cannot belong to more than one VRF at any time.

The IP addressing scheme for each customer router and each PC will be configured according to the topology presented above. For the connection between the ISP router and each customer we will use a /30 subnet with the first IP from the subnet being allocated to the ISP router interface and the second IP to the customer router interface. We will use OSPF as the routing protocol between the ISP and each customer router. First we’ll go on the ISP router and globally define the VRF for each customer. In order to create the VRFs we need to use the ip vrf <vrf_name> command in global configuration mode.

Since CUSTOMER-1 and CUSTOMER-3 use the same address space (172.20.1.0/24 and 172.20.4.0/24) for their sites we need a way to identify which route belongs to which customer. A solution to this problem is to use route distinguishers (RD). A route distinguisher is a unique number of 64 bits in length which is prepended to each route within a VRF and helps us to identify to which VRF this route belongs. The RD value is usually composed from an AS number followed by a semicolon and an arbitrary number. In this scenario for the RD value I’ll use 100 as the AS number and the site ID of each customer. Below is the VRF and RD configuration for each customer.

ISP(config)# ip vrf CUSTOMER-1
ISP(config-vrf)# rd 100:1
ISP(config)# ip vrf CUSTOMER-2
ISP(config-vrf)# rd 100:2
ISP(config)# ip vrf CUSTOMER-3
ISP(config-vrf)# id 100:3

The next step is to associate each VRF instance with at least one interface. For this we need to go into interface configuration mode and use the ip vrf forwarding <vrf_name> command.

Note! It is recommended to apply this command on the interface before configuring an IP address otherwise the IP address will be removed and you will need to configure it again. A message similar to the one below will be displayed on the router console.

% Interface GigabitEthernet0/0 IPv4 disabled and address(es) removed due to enabling VRF CUSTOMER-1

According to the diagram we’ll associate interfaces Gi0/0 and Gi0/3 to CUSTOMER-1 vrf, interfaces Gi0/1 and Gi0/4 to CUSTOMER-2 vrf and interfaces Gi0/2 and Gi0/5 to CUSTOMER-3 vrf. Below is the configuration for each interface.

ISP(config)# interface GigabitEthernet0/0
ISP(config-if)# ip vrf forwarding CUSTOMER-1
ISP(config)# interface GigabitEthernet0/1
ISP(config-if)# ip vrf forwarding CUSTOMER-2
ISP(config)# interface GigabitEthernet0/2
ISP(config-if)# ip vrf forwarding CUSTOMER-3
ISP(config)# interface GigabitEthernet0/3
ISP(config-if)# ip vrf forwarding CUSTOMER-1
ISP(config)# interface GigabitEthernet0/4
ISP(config-if)# ip vrf forwarding CUSTOMER-2
ISP(config)# interface GigabitEthernet0/5
ISP(config-if)# ip vrf forwarding CUSTOMER-3

In order to to display the created VRFs and the associated interfaces we can use the show ip vrf command in EXEC mode.

ISP#show ip vrf       
  Name                             Default RD            Interfaces
  CUSTOMER-1                       100:1                 Gi0/0
                                                         Gi0/3
  CUSTOMER-2                       100:2                 Gi0/1
                                                         Gi0/4
  CUSTOMER-3                       100:3                 Gi0/5
                                                         Gi0/2

With the VRF being created and interfaces assigned let’s proceed now and configure the OSPF routing.

Configuring OSPF routing

In order to keep things simple we’ll enable OSPF on all interfaces for each customer router by running the following command.

CUST1-R1(config)# router ospf 1
CUST1-R1(config-router)# network 0.0.0.0 255.255.255.255 area 0

The command dictates that you do not care (255.255.255.255) what the IP address is, but if an IP address is enabled on any interface, place it in area 0. Next on the ISP router we can use the same command but we need to define 3 separate OSPF instances for each customer (one instance per VRF).

ISP(config)# router ospf 1 vrf CUSTOMER-1
ISP(config-router)# network 0.0.0.0 255.255.255.255 area 0
ISP(config)# router ospf 1 vrf CUSTOMER-2
ISP(config-router)# network 0.0.0.0 255.255.255.255 area 0
ISP(config)# router ospf 1 vrf CUSTOMER-3
ISP(config-router)# network 0.0.0.0 255.255.255.255 area 0

At this time the OSPF neighborship should be established. We can verify this by running the following command.

ISP# show ip ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Address         Interface
172.20.4.1        1   FULL/DR         00:00:32    10.10.60.2      GigabitEthernet0/5
172.20.1.1        1   FULL/DR         00:00:34    10.10.30.2      GigabitEthernet0/2
172.20.5.1        1   FULL/DR         00:00:34    10.10.50.2      GigabitEthernet0/4
172.20.2.1        1   FULL/DR         00:00:38    10.10.20.2      GigabitEthernet0/1
172.20.4.1        1   FULL/DR         00:00:38    10.10.40.2      GigabitEthernet0/3
172.20.1.1        1   FULL/BDR        00:00:32    10.10.10.2      GigabitEthernet0/0

Since we didn’t specify a router-ID, routers CUST1-R1 and CUST3-R1, respectively CUST1-R2 and CUST3-R2 have the same Neighbor ID.

VRF-lite verification

Now let’s check the routing tables and run some connectivity tests. First let’s check the global routing table.

ISP#show ip route
Gateway of last resort is not set

As we can see the output is empty. This is because currently the interfaces Gi0/0 through Gi0/5 are associated to VRFs and on the ISP router there aren’t any other non-VRF interfaces which have any IP address assigned. In order to check the routing table for a specific VRF we can use the show ip route vrf <vrf_name> command. Let’s verify now the routing table for CUSTOMER-1.

ISP#show ip route vrf CUSTOMER-1

Routing Table: CUSTOMER-1

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C        10.10.10.0/30 is directly connected, GigabitEthernet0/0
L        10.10.10.1/32 is directly connected, GigabitEthernet0/0
C        10.10.40.0/30 is directly connected, GigabitEthernet0/3
L        10.10.40.1/32 is directly connected, GigabitEthernet0/3
      172.20.0.0/24 is subnetted, 2 subnets
O        172.20.1.0 [110/2] via 10.10.10.2, 00:42:08, GigabitEthernet0/0
O        172.20.4.0 [110/2] via 10.10.40.2, 02:40:51, GigabitEthernet0/3

From the output we can see that only two OSPF routes were received from CUSTOMER-1 routers on interfaces Gi0/0 and Gi0/3. The same will apply to the VRF routing tables of CUSTOMER-2 and CUSTOMER-3. Now let’s run a ping and a traceroute from PC-1 to PC-4 to test reachability through the VRF between the sites of CUSTOMER-1.

PC-1# ping -c 2 172.20.4.100
PING 172.20.4.100 (172.20.4.100) 56(84) bytes of data.
64 bytes from 172.20.4.100: icmp_seq=1 ttl=61 time=2.36 ms
64 bytes from 172.20.4.100: icmp_seq=2 ttl=61 time=1.63 ms

--- 172.20.4.100 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 1.632/1.998/2.364/0.366 ms

PC-1# traceroute -n 172.20.4.100
traceroute to 172.20.4.100 (172.20.4.100), 30 hops max, 46 byte packets
 1  172.20.1.1  0.439 ms  0.354 ms  0.253 ms
 2  10.10.10.1  0.670 ms  0.737 ms  0.527 ms
 3  10.10.40.2  1.063 ms  0.865 ms  0.923 ms
 4  172.20.4.100  0.952 ms  0.988 ms  1.015 ms

From the traceroute output we can see the destination IP address is located on PC-4 since the third hop in the path (10.10.40.2) is the Gi0/0 interface on CUST1-R2 router. Now let’s try to ping PC-5 from PC-1

PC-1# ping -c 2 172.20.5.100
PING 172.20.5.100 (172.20.5.100) 56(84) bytes of data.
From 172.20.1.1 icmp_seq=1 Destination Host Unreachable
From 172.20.1.1 icmp_seq=2 Destination Host Unreachable

--- 172.20.5.100 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1010ms

Since host PC-5 is located in CUSTOMER-2 VRF is not reachable from PC-1. Router CUST1-R1 since it doesn’t have a route to network 172.20.5.0/24 and a default gateway it drops the packets. As a last test let’s run a traceroute from PC-3 to PC-6 (172.20.4.200).

PC-3# traceroute -n 172.20.4.200
traceroute to 172.20.4.200 (172.20.4.200), 30 hops max, 46 byte packets
 1  172.20.1.1  0.751 ms  2.064 ms  0.445 ms
 2  10.10.30.1  1.030 ms  0.704 ms  1.386 ms
 3  10.10.60.2  1.853 ms  3.565 ms  1.334 ms
 4  172.20.4.200  1.021 ms  0.979 ms  0.840 ms

As you can see from the output the ISP router forwards the traffic to 10.10.60.2 which is the Gi0/0 interface of CUST3-R2 router. This proves that VRFs are setup properly and overlapping IP address spaces are routed properly to their specific customer VRF.

Summary

Using the VRF-lite feature we demonstrated in this article how VRFs can be used on a single router to isolate customer traffic through the use of separate routing tables. Keep in mind that VRF-lite does not scale to the size required by global enterprises or large carriers, as there is the need to implement each VRF instance on every router, including intermediate routers. The real power of VRF comes in hand when used in conjunction with MPLS technologies.