VRF, meaning Virtual Routing and Forwarding, is a technology implemented in the IP network routers that allows multiple instances of a routing table to exist on the same router in the same time. Since each VRF is independent, the same IP subnet can exist in 2 different VRFs. Basically you can overlap one IP address in 2 VRFs but without conflicting with each other. Even this is possible, I would not suggest doing so, unless you have a very good reason to do it.
Another meaning of VRF is VPN Routing and Forwarding which is a key element in Cisco’s MPLS (Multiprotocol Label Switching) VPN technology. Internet service providers often take advantage of VRF to create separate virtual private networks (VPNs) for customers. Some advantages of using this technology is than an ISP can provision scalable IP MPLS VPN services, generate reports (e.g. audit for services), Service Level Agreements (SLA) contracts and more…
To summarize, virtual networks enable administrators to split a physical link into multiple virtual links completely isolated one from the others. Typically, a virtual network will be dedicated to traffic from a specific application or from a specific users / customers.
Now that we clarify the basic of what is and how it works, let’s see where is VRF used the most. As you maybe guess already, this is in the MPLS VPN environment, due to the fact that in today’s business granularity is very important and VRF help network engineers to isolate and provide security for its customers in an ISP environment or to separate services in an Intranet environment. As you probably already know, MPLS functionality is based on P (Provider) routers, PE (Provider edge) routers and CE (Customer edge) routers. Each of these routers must be configured in order for MPLS to work within an enterprise’s architecture. I describe a little bit the MPLS technology, so you can understand better the topology presented below and then following configuration example:
As you can see from the topology, one PE router can hold and manage multiple virtual routing table, one for each customer that an ISP have. If you are running in a private environment (e.g. Intranet), you can use MPLS VPN to separate services (e.g. office, development…) The basic functionality is the same and I’ll show you below how to implement VRFs.
The actual configuration of VRFs is not a complicate task to achieve. There are two main components to a VRF: The route distinguisher(RD) and the route target(RT).
The route distinguisher (RD) is a number which help identify a VPN in a provider’s network and allow for overlapping IP space.
The route target (RT) indicates the VPN membership of a route and allows VPN routes to be imported or exported into or out of your VRFs. The RT functions a little like a routing policy — determining how routes are distributed throughout the particular VPN.
The RD / RT is a 8-byte (64-bits) number which can be written down as follow:
– 16-bit AS number: your 32-bit number
(e.g.) 65000:100
or
–32-bit IP address: your 16-bit number
(e.g) 192.168.0.1:10
Usually the first method is used more often.
For some very basic VRF configuration follow the steps:
1. Enters VRF configuration mode and assigns a VRF name.
Router(config)#ip vrf vrf-name
2. Creates a VPN route distinguisher (RD) following one of the 16bit-ASN:32bit-number or 32bit-IP:16bit-number explained above
Router(config-vrf)#rd route-distinguisher
3. Creates a list of import and/or export route target communities for the specified VRF.
Router(config-vrf)# route-target {import | export | both} route-distinguisher
4. (Optional step) Associates the specified route map with the VRF.
Router(config-vrf)# import map route-map
5. Specifies an interface and enters interface configuration mode.
Router(config)# interface type number
6. Associates a VRF with an interface or subinterface.
Router(config-vrf)# ip vrf forwarding vrf-name
To check your configuration, you can use ping or traceroute tools under Cisco CLI, but remember that you have to use “vrf vrf-name” parameter:
Router# ping vrf vrf-name IP-address
Also you can check the virtual routing table:
Router# show ip route vrf vrf-name
In some of the following posts, I will present a VRF implementation following a real environment topology, but until then I hope you understood the basics of VRF functionality. It’s not hard to implement (from case to case it might be due to local topologies and technology) but it can help you to have a more granular connections and makes troubleshooting more easy, especially in the environments which have a lot of IP addresses under management.