Home > CCNP R&S Study Group > Discussions

Introduction to VRFs - Part 2 (Multiprotocol VRFs)

Created by Kevin Santillan on Jul 12, 2015 7:22 PM. Last modified by Kevin Santillan on Jul 20, 2015 6:24 PM.

Table of Contents:

Overview
Configuration
Verification
IPv4-Only VRF to Multiprotocol VRF Configuration Migration

Overview

The first document in this series provided insight about the operation and configuration of VRFs. However, it only focused on Single-
Protocol, IPv4-Only VRFs which are already considered legacy. Now a days, service providers already implement the use of
Multiprotocol VRFs to support both IPv4 and IPv6 address families. This document sheds some light on Multiprotocol VRFs along with
the relevant configuration.

Here, we will be presenting the same topology that was used in the first doc where in a service provider is catering two different
customers, each having two different sites that require reach ability, and each customer router has a default route to the service
provider. The only difference is, the customers now require both IPv4 and IPv6 support.

The objective is to be able to accommodate the overlapping IPv4 and IPv6 addressing schemes and completely separate traffic for
each customer to ensure security. This can be accomplished through the use of Multiprotocol VRFs.

Compared to an IPv4-Only VRF which requires two configuration steps at a minimum, the basic configuration of a Multiprotocol VRF
requires at least three steps:

1.) Create the VRF

(config)# vrf definition <vrf name>

2.) Enable the desired address family / families within the VRF

(config-vrf)# address-family ipv4

and / or
(config-vrf)# address-family ipv6

3.) Associate the VRF to the appropriate interface(s)

(config-if)# vrf forwarding <vrf name>

The second step, which is being able to support both address families, is what mainly differs Multiprotocol VRFs from Single-Protocol
VRFs. Upon checking the Feature Navigator, the oldest IOS version for ISRs that can support Multiprotocol VRFs is 12.4(20)T that is
being ran on a 3825, 3845 or a 7200. If you don't have these platforms to test on, then you need one that is running 15.0(1)M at least.

Now, one might ask, what happens if you don't turn on an address-family? If you don't turn on at least one, then you can't do anything
with the VRF. The behavior might be slightly different depending on the code version, but the end result is the same. That is, you won't
be able to use the VRF.

For example, with a 7200 running 15.0(1)M, associating a VRF with an interface without specifying an address-family prohibits you to
assign that VRF to an interface such as show below.

ISP(config)#vrf definition CUST-X

ISP(config-vrf)#interface FastEthernet 0/0
ISP(config-if)#vrf forwarding CUST-X
 % Cannot configure VRF forwarding since no address family configuration exists in this VRF
CUST-X; Please configure address family first

Next, we have a CSR1Kv running 15.4(3). It will allow you to associate the VRF to an interface even without specifying an address-
family, but you won't be able to configure any IP address.

CSR1Kv(config)#vrf definition CUST-X

CSR1Kv(config-vrf)#exit
CSR1Kv(config)#interface gigabitEthernet 2
CSR1Kv(config-if)#vrf forwarding CUST-X
% Interface GigabitEthernet2 IPv4 disabled and address(es) removed due to enabling VRF
CUST-X
% Interface GigabitEthernet2 IPv6 disabled and address(es) removed due to enabling VRF
CUST-X
CSR1Kv(config-if)#ip address 10.130.1.1 255.255.255.252
%GigabitEthernet2 is linked to a VRF. Enable IPv4 on that VRF first.
CSR1Kv(config-if)#ipv6 address 2001:130::1/64
%GigabitEthernet2 is linked to a VRF. Enable IPv6 on that VRF first.

Also note that regardless of what address-family you turn on in a Multiprotocol VRF, when you associate it to an interface, all
addresses previously configured for that interface whether it be IPv4 and IPv6 will be removed.

Configuration

Lets go ahead and create the VRFs for each customer along with the appropriate static routes to each customer's LAN.

hostname ISP
!
vrf definition CUST-X
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
!
interface FastEthernet0/0
vrf forwarding CUST-X
ip address 10.110.1.1 255.255.255.252
ipv6 address 2001:110::1/64
!
interface FastEthernet0/1
vrf forwarding CUST-X
ip address 10.120.1.1 255.255.255.252
ipv6 address 2001:120::1/64
!
ip route vrf CUST-X 10.10.10.0 255.255.255.0 10.110.1.2
ip route vrf CUST-X 10.20.20.0 255.255.255.0 10.120.1.2
!
ipv6 route vrf CUST-X 2001:10::/64 2001:110::2
ipv6 route vrf CUST-X 2001:20::/64 2001:120::2
!
vrf definition CUST-Y
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
!
interface FastEthernet1/0
vrf forwarding CUST-Y
ip address 10.130.1.1 255.255.255.252
ipv6 address 2001:130::1/64
!
interface FastEthernet1/1
vrf forwarding CUST-Y
ip address 10.140.1.1 255.255.255.252
ipv6 address 2001:140::1/64
!
ip route vrf CUST-Y 10.10.10.0 255.255.255.0 10.130.1.2
ip route vrf CUST-Y 10.30.30.0 255.255.255.0 10.140.1.2
!
ipv6 route vrf CUST-Y 2001:10::/64 2001:130::2
ipv6 route vrf CUST-Y 2001:30::/64 2001:140::2
You can do a show run vrf as discussed in the first document to view the full configuration that was done for each VRF. You can also
use show vrf to quickly view each VRF, the address-families enabled within it, and the interfaces where it was associated.

ISP#show vrf
Name Default RD Protocols Interfaces
CUST-X <not set> ipv4,ipv6 Fa0/0
Fa0/1
CUST-Y <not set> ipv4,ipv6 Fa1/0
Fa1/1

Verification

Shown below are the IPv4 and IPv6 networks that overlap for each customer. Since we associated the VRFs to the appropriate
interfaces, the global routing table is now empty and the routes can only be found in the respective IPv4 and IPv6 routing tables within
each VRF.

ISP#show ip route 10.10.10.0

% Network not in table

ISP#show ip route vrf CUST-X 10.10.10.0

Routing Table: CUST-X
Routing entry for 10.10.10.0/24
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
* 10.110.1.2
Route metric is 0, traffic share count is 1

ISP#show ip route vrf CUST-Y 10.10.10.0

Routing Table: CUST-Y
Routing entry for 10.10.10.0/24
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
* 10.130.1.2
Route metric is 0, traffic share count is 1

ISP#show ipv6 route 2001:10::

% Route not found

ISP#show ipv6 route vrf CUST-X 2001:10::

Routing entry for 2001:10::/64
Known via "static", distance 1, metric 0
Route count is 1/1, share count 0
Routing paths:
2001:110::2
Last updated 01:27:28 ago

ISP#show ipv6 route vrf CUST-Y 2001:10::

Routing entry for 2001:10::/64
Known via "static", distance 1, metric 0
Route count is 1/1, share count 0
Routing paths:
2001:130::2
Last updated 01:27:19 ago

One difference in showing the routing table of each address-family within a VRF is that only the show ip route vrf supports the use of
an asterisk (*) at the end of the command to show all IPv4 routing tables for all VRFs. The show ipv6 route vrf does not.

Here are tests from the service provider and one of the customers showing that all IPv4 and IPv6 traffic is isolated within each VRF.

ISP(tcl)#foreach IP {
+>10.10.10.1
+>10.20.20.1
+>2001:10::1
+>2001:20::1
+>} {puts "[exec ping vrf CUST-X $IP]"}

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/129/184 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.20.20.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 92/163/304 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:10::1, timeout is 2 seconds:
!!!!!
Success rate is 80 percent (5/5), round-trip min/avg/max = 72/142/236 ms
 Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:20::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/84/184 ms

ISP(tcl)#foreach IP {
+>10.10.10.1
+>10.30.30.1
+>2001:10::1
+>2001:30::1
+>} {puts "[exec ping vrf CUST-Y $IP]"}

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/130/236 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.30.30.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/115/208 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:10::1, timeout is 2 seconds:
!!!!!
Success rate is 80 percent (5/5), round-trip min/avg/max = 20/77/112 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:30::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/79/136 ms

CX-A(tcl)#foreach IP {
+>10.20.20.1
+>2001:20::1
+>10.30.30.1
+>2001:30::1
+>} {ping $IP}

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.20.20.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 116/189/252 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:20::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/129/232 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.30.30.1, timeout is 2 seconds:
UUUUU
Success rate is 0 percent (0/5)
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:30::1, timeout is 2 seconds:
UUUUU
Success rate is 0 percent (0/5)

IPv4-Only VRF to Multiprotocol VRF Configuration Migration

In case you have an IPv4-Only VRF and are just starting to implement IPv6, you can convert the existing configuration of the IPv4-
Only VRF into a Multiprotocol VRF configuration via the vrf upgrade-cli command. Here is an example.

ISP#show run vrf TEST

Building configuration...

Current configuration : 182 bytes

ip vrf TEST
!
interface Loopback100
ip vrf forwarding TEST
ip address 10.50.50.1 255.255.255.0
ipv6 address 2001:50::1/64
!
ip route vrf TEST 0.0.0.0 0.0.0.0 10.50.50.2
end

ISP(config)#vrf upgrade-cli multi-af-mode common-policies vrf TEST

You are about to upgrade to the multi-AF VRF syntax commands.
You will lose any IPv6 address configured on interfaces
belonging to upgraded VRFs.

Are you sure ? [yes]:

Number of VRFs upgraded: 1

ISP(config)#do show run vrf TEST

 Building configuration...

Current configuration : 204 bytes

vrf definition TEST
!
address-family ipv4
exit-address-family
!
interface Loopback100
vrf forwarding TEST
ip address 10.50.50.1 255.255.255.0
!
ip route vrf TEST 0.0.0.0 0.0.0.0 10.50.50.2
end

One thing to take note here is the IPv6 address that was previously configured in the interface was removed upon upgrade. Hence,
you need to enable the IPv6 address-family within the VRF and configure the address again.

6918 Views Categories: Tags:

Average User Rating

(12 ratings)

MOST LIKED

12 Comments

Darby Weaver CCNP/CCDP Jul 15, 2015 9:56 AM

Thanks Kevin!

Clean crisp and clear...

Nice work.

Darby Weaver

http://www.darbyslogs.blogspot.com

Actions

Mark Holm - 3xCCIE #34763/CCDE #20160020 Jul 15, 2015 12:23 PM

Kevin,

Well written doc.

/Mark

Actions

Kevin Santillan Jul 15, 2015 4:39 PM (in response to Mark Holm - 3xCCIE #34763/CCDE #20160020)

Thanks Mark!

Actions

Fabrizio Chessa Jul 15, 2015 3:23 PM

Hi,

very good explanation!!!

One good thing is the explanation of upgrade. I should try it on a lab.

Many thanks!!

Regards,
Fabrizio

Actions

Kevin Santillan Jul 15, 2015 4:41 PM

Darby and Fabrizio,

Thanks for the compliments!

Actions

Uma Shankar V. Jul 15, 2015 10:02 PM

 Thanks, Kevin for the Part 2 !! Bookmarked both Docs !! Excellent Reference for VRF !! Please continue this great work !!

Regards
Uma Shankar V.

Actions

jean-christophe manciot - CCDP Jul 16, 2015 2:32 AM

Very nice! As crystal clear as part 1

Actions

Matt Jul 16, 2015 3:39 AM

Thanks again, very good

Actions

Kevin Santillan Jul 18, 2015 8:34 PM

Uma, Jean and Matti,

Thanks for the kind words.

Actions

Inacio Feb 9, 2016 6:18 PM

Thanks for the post, very clear.

Actions

David P. Feb 10, 2016 12:28 AM

Love it! Thanks/gracias!

Actions

MLP Mar 29, 2019 8:48 AM

Thank you for the VRF explanations.

Actions

Terms & Conditions Privacy Statement Cookie Policy Trademarks Languages Follow us: