Intro to VRF lite
VRFs, or VPN Routing and Forwarding instances, are most commonly associated with MPLS service providers. In such networks, MPLS encapsulation is used to isolate individual customers' traffic and an independent routing table (VRF) is maintained for each customer. Most often, MP-BGP is employed to facilitate complex redistribution schemes to import and export routes to and from VRFs to provide Internet connectivity.
However, VRF configuration isn't at all dependent on MPLS (the two components just work well together). In Cisco terminology, deployment of VRFs without MPLS is known as VRF lite, and this article discusses a scenario where such a solution could come in handy.
Assume the topology illustrated below is a network owned by an enterprise. As you would expect, normal company traffic must pass through the firewall so that company policy can be enforced. However, this a secondary Internet connection has been added to this network: an unrestricted ADSL circuit designated for guests visiting the company campus. The 10.0.0.0/16 network is used for trusted traffic, and 192.168.0.0/16 is used for guest traffic.
All router interfaces which provide transport for both types of traffic have been configured with two subinterfaces performing 802.1Q encapsulation; .10 for VLAN 10 (blue) and .20 for VLAN 20 (red). Note that although 802.1Q encapsulation is used to tag frames across the link, each link is a routed segment with an IP interface at either end. For example, here is R1's F2/0 configuration (the complete config of all three core routers is attached at the end of the article if you'd like to skip ahead):
interface FastEthernet2/0 description R2 no ip address ! interface FastEthernet2/0.10 encapsulation dot1Q 10 ip address 10.0.12.1 255.255.255.252 ! interface FastEthernet2/0.20 encapsulation dot1Q 20 ip address 192.168.12.1 255.255.255.252
If this were a generic routed network, the network admin would be busy touching up his or her resume right now. Obviously, the addition of a "back door" Internet access link opens a huge security hole, but we can employ VRFs here to segment the single physical infrastructure into two virtual, isolated networks. VRFs employ essentially the same concept as VLANs and trunking, but at layer three.
VRF lite is simple: each routed interface (whether physical or virtual) belongs to exactly one VRF. Unless import/export maps have been applied, routes (and therefore packets) cannot move from one VRF to another, much like the way VLANs work at layer two. Packets entering VRF A can only follow routes in routing table A, as we'll see shortly.
Prior to VRF configuration, all routers have all of their connected routes in the global routing table as you would expect:
R1# show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
192.168.12.0/30 is subnetted, 1 subnets
C 192.168.12.0 is directly connected, FastEthernet2/0.20
192.168.13.0/30 is subnetted, 1 subnets
C 192.168.13.0 is directly connected, FastEthernet2/1.20
10.0.0.0/30 is subnetted, 3 subnets
C 10.0.12.0 is directly connected, FastEthernet2/0.10
C 10.0.13.0 is directly connected, FastEthernet2/1.10
C 10.0.0.0 is directly connected, FastEthernet1/1
192.168.0.0/30 is subnetted, 1 subnets
C 192.168.0.0 is directly connected, FastEthernet1/0
To begin, let's create VRFs BLUE and RED on R1:
R1(config)# ip vrf BLUE R1(config-vrf)# description Trusted Traffic R1(config-vrf)# ip vrf RED R1(config-vrf)# description Guest Traffic
Certainly not the most challenging of tasks, eh? Next, we'll add interface F1/0 (which connects to the guest-use ADSL uplink) to VRF RED:
R1(config)# int f1/0 R1(config-if)# ip vrf forwarding RED % Interface FastEthernet1/0 IP address 192.168.0.2 removed due to enabling VRF RED
Wait a tick, what just happened? When assigning an interface to a VRF, IOS automatically deletes any preconfigured IP address to remove that route from the global table. Now when an IP address is assigned to this interface, its network gets added to the specific routing table for that VRF.
So, we reapply our IP to F1/0 and verify that its configuration is complete:
R1(config-if)# ip add 192.168.0.2 255.255.255.252 R1(config-if)# ^Z R1# show run interface f1/0 Building configuration...
Current configuration : 137 bytes ! interface FastEthernet1/0 description RX ip vrf forwarding RED ip address 192.168.0.2 255.255.255.252 duplex auto speed auto end
But look at our routing table now:
R1# show ip route
[...]
192.168.12.0/30 is subnetted, 1 subnets
C 192.168.12.0 is directly connected, FastEthernet2/0.20
192.168.13.0/30 is subnetted, 1 subnets
C 192.168.13.0 is directly connected, FastEthernet2/1.20
10.0.0.0/30 is subnetted, 3 subnets
C 10.0.12.0 is directly connected, FastEthernet2/0.10
C 10.0.13.0 is directly connected, FastEthernet2/1.10
C 10.0.0.0 is directly connected, FastEthernet1/1
The 192.168.0.0/30 route is gone from the global table; it now resides in the VRF RED table, which we have to inspect separately by appending the vrf argument to show ip route:
R1# show ip route vrf RED
[...]
192.168.0.0/30 is subnetted, 1 subnets
C 192.168.0.0 is directly connected, FastEthernet1/0
As you can imagine, this extra step of reapplying an IP address must be repeated for every interface we add to a VRF. I'll spare you the monotony of line-by-line configs and instead present the relevant finished configuration of R1:
interface FastEthernet1/0 description RX ip vrf forwarding RED ip address 192.168.0.2 255.255.255.252 ! interface FastEthernet1/1 description FW ip vrf forwarding BLUE ip address 10.0.0.2 255.255.255.252 ! interface FastEthernet2/0 description R2 no ip address ! interface FastEthernet2/0.10 encapsulation dot1Q 10 ip vrf forwarding BLUE ip address 10.0.12.1 255.255.255.252 ! interface FastEthernet2/0.20 encapsulation dot1Q 20 ip vrf forwarding RED ip address 192.168.12.1 255.255.255.252 ! interface FastEthernet2/1 description R3 no ip address ! interface FastEthernet2/1.10 encapsulation dot1Q 10 ip vrf forwarding BLUE ip address 10.0.13.1 255.255.255.252 ! interface FastEthernet2/1.20 encapsulation dot1Q 20 ip vrf forwarding RED ip address 192.168.13.1 255.255.255.252
As all interfaces now belong to isolated VRFs, our global routing table is completely empty. We can verify that all 10.0.0.0/16 routes are stored in VRF BLUE, and all 192.168.0.0/16 routes are stored in VRF RED:
R1# show ip route vrf BLUE
Routing Table: BLUE
[...]
10.0.0.0/30 is subnetted, 3 subnets
C 10.0.12.0 is directly connected, FastEthernet2/0.10
C 10.0.13.0 is directly connected, FastEthernet2/1.10
C 10.0.0.0 is directly connected, FastEthernet1/1
R1# show ip route vrf RED
Routing Table: RED
[...]
192.168.12.0/30 is subnetted, 1 subnets
C 192.168.12.0 is directly connected, FastEthernet2/0.20
192.168.13.0/30 is subnetted, 1 subnets
C 192.168.13.0 is directly connected, FastEthernet2/1.20
192.168.0.0/30 is subnetted, 1 subnets
C 192.168.0.0 is directly connected, FastEthernet1/0
At this point, although only R1 has been configured with VRFs, it can still route traffic to R2 and R3 with no problem. This is because, like VLANs, VRFs are only locally significant to the router.
After tediously configuring VRFs on the other two routers in the same manner, we can now configure our IGP. For this example, we'll be running an OSPF instance per VRF. We do this by appending the vrf argument to each router statement:
R1(config)# router ospf 1 vrf BLUE R1(config-router)# router-id 0.0.1.1 R1(config-router)# network 10.0.0.0 0.0.255.255 area 0 R1(config-router)# router ospf 2 vrf RED R1(config-router)# router-id 0.0.1.2 R1(config-router)# network 192.168.0.0 0.0.255.255 area 0
These are completely independent OSPF processes; as such, a unique router ID must be used for each. (If you're used to using IPv4 addresses as router ID, the IDs used above might seem strange. Remember that the OSPF router ID is in fact an arbitrary 32-bit value simply expressed in dotted-decimal. Here, the third "octet" represents the router number and the fourth octet represents the VRF.)
After configuring the other two routers with two OSPF processes each, we see two adjacencies formed per link, one per VRF:
R1# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 0.0.3.2 1 FULL/DR 00:00:39 192.168.13.2 FastEthernet2/1.20 0.0.2.2 1 FULL/DR 00:00:39 192.168.12.2 FastEthernet2/0.20 0.0.3.1 1 FULL/DR 00:00:31 10.0.13.2 FastEthernet2/1.10 0.0.2.1 1 FULL/DR 00:00:32 10.0.12.2 FastEthernet2/0.10
Assuming our edge routers aren't running OSPF, we'll also create two static default routes on R1, one for each VRF:
R1(config)# ip route vrf BLUE 0.0.0.0 0.0.0.0 10.0.0.1 R1(config)# ip route vrf RED 0.0.0.0 0.0.0.0 192.168.0.1
By now you've probably deduced that VRF configuration mostly consists of appending a vrf keyword to certain commands where appropriate. Unfortunately the argument isn't inserted at the same point in all commands, so it may take a few queries of the context-sensitive help before you get them all down.
We can verify that our static routes exist along with their OSPF-leanred companions in their respective VRFs:
R1# show ip route vrf BLUE
Routing Table: BLUE
[...]
10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
C 10.0.12.0/30 is directly connected, FastEthernet2/0.10
C 10.0.13.0/30 is directly connected, FastEthernet2/1.10
O 10.0.2.0/24 [110/2] via 10.0.12.2, 00:04:52, FastEthernet2/0.10
O 10.0.3.0/24 [110/2] via 10.0.13.2, 00:04:52, FastEthernet2/1.10
C 10.0.0.0/30 is directly connected, FastEthernet1/1
O 10.0.1.0/24 [110/2] via 10.0.12.2, 00:04:52, FastEthernet2/0.10
O 10.0.23.0/30 [110/2] via 10.0.13.2, 00:04:52, FastEthernet2/1.10
[110/2] via 10.0.12.2, 00:04:52, FastEthernet2/0.10
S* 0.0.0.0/0 [1/0] via 10.0.0.1
R1# show ip route vrf RED
Routing Table: RED
[...]
192.168.12.0/30 is subnetted, 1 subnets
C 192.168.12.0 is directly connected, FastEthernet2/0.20
192.168.13.0/30 is subnetted, 1 subnets
C 192.168.13.0 is directly connected, FastEthernet2/1.20
192.168.23.0/30 is subnetted, 1 subnets
O 192.168.23.0 [110/2] via 192.168.13.2, 00:04:16, FastEthernet2/1.20
[110/2] via 192.168.12.2, 00:04:16, FastEthernet2/0.20
192.168.0.0/30 is subnetted, 1 subnets
C 192.168.0.0 is directly connected, FastEthernet1/0
O 192.168.1.0/24 [110/2] via 192.168.12.2, 00:04:16, FastEthernet2/0.20
O 192.168.2.0/24 [110/2] via 192.168.12.2, 00:04:16, FastEthernet2/0.20
O 192.168.3.0/24 [110/2] via 192.168.13.2, 00:04:17, FastEthernet2/1.20
S* 0.0.0.0/0 [1/0] via 192.168.0.1
Finally we just need to advertise a default route in both OSPF processes from R1 so R2 and R3 can learn them:
R1(config)# router ospf 1 R1(config-router)# default-information originate R1(config-router)# router ospf 2 R1(config-router)# default-information originate
Note that when entering OSPF process configuration, we no longer need to append the vrf keyword as it has already been applied.
Over on R2, we see that each VRF now has its own complete routing table:
R2# show ip route vrf BLUE
Routing Table: BLUE
[...]
10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
C 10.0.12.0/30 is directly connected, FastEthernet1/0.10
O 10.0.13.0/30 [110/2] via 10.0.23.2, 00:14:23, FastEthernet1/1.10
[110/2] via 10.0.12.1, 00:13:53, FastEthernet1/0.10
C 10.0.2.0/24 is directly connected, FastEthernet2/1.10
O 10.0.3.0/24 [110/2] via 10.0.23.2, 00:14:23, FastEthernet1/1.10
O 10.0.0.0/30 [110/2] via 10.0.12.1, 00:13:53, FastEthernet1/0.10
C 10.0.1.0/24 is directly connected, FastEthernet2/0.10
C 10.0.23.0/30 is directly connected, FastEthernet1/1.10
O*E2 0.0.0.0/0 [110/1] via 10.0.12.1, 00:03:33, FastEthernet1/0.10
R2# show ip route vrf RED
Routing Table: RED
[...]
192.168.12.0/30 is subnetted, 1 subnets
C 192.168.12.0 is directly connected, FastEthernet1/0.20
192.168.13.0/30 is subnetted, 1 subnets
O 192.168.13.0 [110/2] via 192.168.23.2, 00:36:59, FastEthernet1/1.20
[110/2] via 192.168.12.1, 00:20:54, FastEthernet1/0.20
192.168.23.0/30 is subnetted, 1 subnets
C 192.168.23.0 is directly connected, FastEthernet1/1.20
192.168.0.0/30 is subnetted, 1 subnets
O 192.168.0.0 [110/2] via 192.168.12.1, 00:20:54, FastEthernet1/0.20
C 192.168.1.0/24 is directly connected, FastEthernet2/0.20
C 192.168.2.0/24 is directly connected, FastEthernet2/1.20
O 192.168.3.0/24 [110/2] via 192.168.23.2, 00:41:13, FastEthernet1/1.20
O*E2 0.0.0.0/0 [110/1] via 192.168.12.1, 00:01:41, FastEthernet1/0.20
At this point our two VRFs are fully functional! A packet from a host on the BLUE VLAN on switch 2, for example, enters the BLUE VRF subinterface on R2 and gets routed via R1's BLUE VRF out to the firewall. Note that for troubleshooting actions (like pinging) you must specify a VRF:
R2# ping 10.0.0.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) R2# ping vrf BLUE 10.0.0.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 12/15/20 ms
Below are the final configurations from all three routers.
UPDATE: Find out how to share routes between VRFs in Inter-VRF Routing with VRF Lite.
About the Author
Jeremy Stretch is a freelance networking engineer, instructor, and the maintainer of PacketLife.net. He currently lives in Fairfax, Virginia, on the edge of the Washington, DC metro area. Although primarily an R&S guy, he likes to get into everything, and runs a free network training lab out of his basement for fun. You can contact him by email or follow him on Twitter.
Comments
You should be thinking about VRF lite when you start creating accesslists that permit or deny entire subnets to other entire subnets, eg.
permit ip 10.1.0.0 0.0.255.255 192.168.0.0 0.0.255.255 anydeny ip 10.3.0.0 0.0.255.255 192.168.0.0 0.0.255.255 any
etc.
Nice post. Will work on it.
Great article. I love the way you can succinctly describe a technology with just the right amount of detail to aid in understanding. Have you ever thought about writing a book?
I have never looked at VRF's like that before.
Great post...keep up the great work.
Another great article! I second the call... have you ever thought about writing a book?
Nice review of VRF concepts. A couple of additional points:
-
Re: yapchinhoong's question, you can exchange routes between VRFs using an Import/Export function. This is common in service provider networks to offer common services to multiple customers, yet keep them separated.
-
With later versions of IOS, the "ip vrf" command becomes "vrf context" command. This aligns to the configurations of Nexus 7000 and other devices (like ACE 4710).
Love the discussion!
Nice write-up! :)
Just got to know that Route Leaking allows route injections between VRFs. :)
This is an excellent work like your previous postings.. helps a lot to understand the concepts.
Really nice article, very well written, and easy to understand... please keep them coming!!
Hi i had no idea what was VFR before reading this article, but after i must admin i just have to try this in lab, thanks really nice summary and example of vrf.
How would you integrate this design into a service provider provisioned MPLS network running BGP in the cloud? Is it possible to work with your provider to implement different VRFs?
Nice post :)
So what happens if and when we need to integrate extranet into the above scenario with vrf-lite, with extranets we will have to leak traffic into multiple vrf's right ?
Views please
Thanks for the good post. I am relatively new to this topic.It would be great if you could clarify these queries.
You have mentioned 'VRFs are only locally significant to the router' . Does this mean that if I configure VRF at one end of a link in a router and configure the other end interface in a different router without VRF it will work ?
Also, what happens if the next hop IP is not a part of the VRF routing table and is found in the global routing table?
This was very helpful for an project im working on. What i like most about this is there is just enough detail to cover the topic, and you dont over complicate anything.
thanks!!!!!!
Excellent article. I need this information to set up a temp. network for Disaster Recovery testing. Thanks
You know I read a lot of articles on tech snippets and I can safely say this one about the VRF-Lite ranks amongts the best I have come across. Simple, straight to the point and covers all the needed bases.
So here is my personal BIG thanks. Yaman
This article explains VRF in the most excellent way and has clarified majority of my confusions. (Great Work) Thanks.
Great article, Concise and very informative. I just introduced into a customers WAN design and it works great for segmenting traffic. Just a tip thought; if using an access-class on a line vty be sure to add the vrf-also keyword i.e.
line vty 0 4
access-class 123 in vrf-also
Hi.
And It's possible to conect two VFR's inside the same Router/Switch without using and external cable conecting the two VLAN/VRF.
Thanks in advance.
Enrique.
Hi Everyone;
This is the best article i seen on VRF so far. It is explained so easily. I am new to this topic, so could someone help me what the config will be on the switch end ?
Thanks in advance,
Rams
Dear ,
Its a great blog and an excellent article. Thanks for your easy explanation of this complex technology.
WArm Regards Thameem
Great article!!
Its really good one. Just wanted to know if we could do the same for ipv6 as well ?
Excellent doc , this is great doc for those who have a question " what is VRF LITE " like i had before reading this paper.
Awesome. Been to some classes that make a two hour discussion out of this that didn't come across nearly as clear. Make sure you do a follow up on how to route between VRF's. Thanks for the knowledge.
A few words but explains so much. Better than wikipedia.
Fantastic!!
Simple and clear, thanks for article !
Briliant article. Keep up the good work!!
yapchinhoong.
Per your Question: Nice article. :) I have a question in mind, once we implemented this network with VRF, what are the available solutions if suddently the CIO said would like to exchange traffic between 2 VRFs?
Yes, large enterprises do this on a daily basis, especially when you are dealing with ePHI, PCI and PHI data infrastructures. Typically Route Leaking is a NoNo and should be avoided if you can.
The best option is using Firewall's to filter and connect the networks together at a point that is feasible. In other words, you will have Red VRF subnet connected to the Firewall on Vlan 100 and Blue VRF connected to the firewall on Vlan 200 there is no true reason to have the Firwall to be VRF aware unless you have IP overlapping.
Hope this helps.
This is one of the best articles so far I saw. Easy to understand and just enough information.
Thank you very much for such a great article. This is the first article that I've read about VRF-Lite that has not included way too much useless babble. Cisco need to hire more experts like yourself!
If only all Textbooks were written in this kind of format too.... would save time studying.
Without any knowledge on VRF, I read this post. It was very excellent and explained with very simple configurations.
Keep up your good work.
Very deftly done..can we have more of them Jeremy ??
Thanks man. This is very simple and clear.
Best article I've read about vrf-lite. Thank you!
Wow, this walk-through is great! Just one question:
I see that VRF allows multiple interfaces to be connected to distinctly unique subnets that may even use the same address space, normally something you cannot do in a single router instance.
That said, how could you enable two hosts, each with the same address but on two separate VLANs and served by separate VRFs to conduct peer-to-peer communications (file transfer, for instance)? If I am 10.1.1.2 on VLAN A and would like to talk to another customer's 10.1.1.2 on VLAN B through a router implementing VRF, can & how does this work? Or is this a limitation that cannot be overcome?
Thanks for any help!
Hey Jeremy,
Just one hour ago i had a discussion on implementin VRFs for a project i have been assigned to. I decided to come by and take a look at what you have to say about VRF. I must admit man, you made my day!
Clear, simple and also concise, i knew close to nothing about VRFs until today.
Thanks a million
Hey Jeremy,
I have to say that your explanation is very clear. I have questions:
- What software do you use to draw the network topology?
- Your example of VRF is very clear, and it can be used for DMZ zone. How could you do to allow corporate side to connect to public servers (www, email, ftp, ...) which are located on the GUEST VRF network?
Thanks a bunch!
Really GOOD work - keeps me inspiring :)
Hello - I just found your blog and have a vrf-lite question.
Can a vrf-lite instance have a routing space that is part of the global routing space? In other words, we have 164.72.0.0 defined in our global EIGRP routing config, and for various reasons, we cannot use another address space for a vrf-lite configuration. The vrf-lite is behind an internal firewall, which does EIGRP, and the firewall inside interface is the default route for the vrf-lite. So the config will look like this:
router eigrp 1 network 164.72.0.0 no auto-summary ! address-family ipv4 vrf CDE network 164.72.233.128 0.0.0.127 no auto-summary autonomous-system 1 exit-address-family
Unfortunate, with this configuration the vrf-lite routes are known in the global space, which is OK, but traffic from the global network bypasses the firewall and just routes straight over to the vrf-lite vlan.
Is this because the vrf-lite network space is a subset of the global space?
In the lab, if I substitute a private address space for the vrf-lite config, then all is well and global traffic routes to the firewall to enter the vrf-lite.
Excellent article! This is a very good reference to vrf-lite.
This is the best article I have read on VRF-Lite. Kudos!
Good Job Bro! That was the LIGHTest with a full pack information that a noob like me to know...
Literally, I was clapping my hands saying "Finally I can surely say I understand the basics about VRF".
KUDOS!
Thanks; I found your articles always great.
excellent site.
Nice article. :) I have a question in mind, once we implemented this network with VRF, what are the available solutions if suddently the CIO said would like to exchange traffic between 2 VRFs?