I have found for myself long ago that reading several articles and documents explaining the same thing, often using different approaches, helps me quite a lot to understand it. Trying to brush up my knowledge in Layer 3 MPLS VPN and doing some experiments in the lab environment I have decided to write a series of short posts on how it works with my way of explaining it. Hope it will help someone who also likes to read various materials on the same topic.

The solution, as many already know, consists of the following basic components:

• VRF
• Multiprotocol BGP
• MPLS (label propagation and switching)
• Some Interior Gateway Routing Protocol

And it all looks something like this (an example shows LDP as label propagation mechanism though it is not the only one possible):

The idea is to be able to pass Layer 3 private networks across some transport (MPLS-enabled) network leaving routing processes within these private networks independent of each other and of the ones that take place in the backbone network (unless you actually want to interchange some routing information).

The most difficult part is usually not to understand how each of the components works by itself, but go get the whole picture. I started by asking: “Why do we need all of these components to make the solution work?” Starting with the first one the question will be:

Why do we need VRF?

Remember the goal of L3 MPLS VPN – several independent Layer-3 networks should be able to send data over one transport network. This means we are going to have traffic of two or more private networks on the same router and we need to have separate routing instances for each of these networks. This is what VRF does.

How does it work?

VRF is often called Router Virtualization and is compared to Server/Desktop Virtualization. This analogy doesn’t seem very accurate to me. When you virtualize a server with let’s say VMWare ESXi you normally get all of it’s main components – CPU, RAM, disks, network cards, virtualized and managed separately from the same components of other virtual servers. In case of VRF what gets virtualized is just routing instance. You don’t manage how many hardware resources each virtual routing instance will get, router RAM and CPU resources remain shared.

What makes each VRF is its Layer-3 interface members and its proper routing table. To me an analogy with VLANs each having its Layer-2 port members and proper MAC-address table seems more correct.

A good example of network virtualization technology that gets really close to the server/desktop virtualization would be VDC in Cisco NX-OS, not VRF.

VRF instances are local to the router

This is an important thing to keep in mind. Two switches receiving Ethernet frames from each other across dot1q trunk understand which traffic belongs to which VLAN by looking at dot1q tag. There is nothing similar happening with VRF instances. Each VRF instance is local to the router where it is configured. There is no data in the packet that could indicate which VRF it comes from.

Configuration

VRF configuration is basically resumed to

Creating VRF instances

The meaning of the Route Distinguisher parameter configured with rd command will be explained in later post.

Assigning Layer-3 interfaces

Configuring routing

I have added just static routes, though it is also possible to use dynamic routing protocols capable to work with VRF.

As a result we have separate routing tables for each VRF instance:

The routes that don’t belong to any of the VRF instances created, stay in Global routing instance. Here I have FastEthernet0/0 interface that is not assigned to any VRF:

VRF as part of MPLS L3VPN

In MPLS L3VPN solution VRF is used on the transport network border routers (often called PE routers). Let’s say we have Network A and Network B across backbone network. Each of them will have its own VRF on every PE router that has Network A, B devices (CE-routers) connected.