Problem solve Get help with specific problems with your technologies, process and projects.

Configuring a VRF

Doug Downer demonstrates how to configure a VPN Routing and Forwarding (VRF) in an instance where a service provider needs to keep Internet services separate for two different clients on shared devices.

In a recent tip called Keeping it all separate with VRFs, I started talking about an increasingly common scenario...

which involves the requirement to separate customers on shared devices using VPN Routing and Forwarding (VRF) instances. VRFs allow us to logically separate L2 and L3 functions for customers which share common network devices. This separation also allows service providers the ability to separate customers on their backbone with other technologies such as MPLS. MPLS is not within the scope of this series so we'll stick to just the VRF for now. In this tip, I'll show you how to configure a VRF using the scenario we looked at before.

Scenario recap

We have been looking at a scenario involving the requirement for two customers (A and B) to be given Internet access from a service provider (you). Because of the relatively small size of the service provider and customer -- one shared network device was installed to support this requirement. At first glance this scenario allows for the networks of Customer A and Customer B to mix together. To prevent that, the service provider puts each customer within a VRF.

 

Creating the VRF

The actual configuration of a VRF is not a difficult task. There are two main components to a VRF: The route distinguisher and the route target. A route distinguisher (RD) is a number -- which doesn't actually have any real significance other than to help identify a VPN in a provider's network and allow for overlapping IP space. The RD is an 8-byte number with two parts: A 2-byte type field followed by a 6-byte value field. Without going into too much detail, the value field of the RD is most often represented as an autonomous system number (ASN 2 bytes) followed by an arbitrary number (4 bytes) or an IP address (4 bytes) followed by an arbitrary number (2 bytes). You can enter an RD in either of these formats:

More on this topic
Keeping it all separate with VRFs

Crash Course: Routers

Crash Course: VPNs

Routing & Switching tips

More VPN tips

16-bit AS number: your 32-bit number
For example, 101:3.

32-bit IP address: your 16-bit number
For example, 192.168.122.15:1.

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. Like the RD, the RT is 8 bytes in length and can be entered as:

16-bit AS number: your 32-bit number
For example, 101:3.

32-bit IP address: your 16-bit number
For example, 192.168.122.15:1.

Using the example scenario, let's configure two VRFs on the service provider router. Customer A will have an RD of 192.168.1.1:100 and Customer B will have an RD of 192.168.2.1:200

  • Customer A
    SP_Router(config)#interface loopback 1
    SP_Router(config-if)#description Loopback interface for Customer_A VRF
    SP_Router(config)#interface g0/0
    SP_Router(config-if)#description Connection to the Customer_A router
    SP_Router(config)#ip vrf Customer_A
    SP_Router(config-vrf)#rd 192.168.1.1:100
    SP_Router(config-vrf)#route-target import 192.168.1.255:100
    SP_Router(config-vrf)#route-target export 192.168.1.255:100
  •  

  • Customer B
    SP_Router(config)#interface loopback 2
    SP_Router(config-if)#description Loopback interface for Customer_B VRF
    SP_Router(config)#interface g0/1
    SP_Router(config-if)#description Connection to the Customer_B router
    SP_Router(config)#ip vrf Customer_B
    SP_Router(config-vrf)#rd 192.168.2.1:200
    SP_Router(config-vrf)#route-target import 192.168.2.255:200
    SP_Router(config-vrf)#route-target export 192.168.2.255:200

Assigning the interfaces

Once you have created the VRF you can begin to assign the particular interfaces and start to separate the customers. Notice I did not assign an IP address to the interfaces which are intended to be in the VRF. If you put the IP addresses on prior to putting the interface in the VRF, the IP address will be removed and cause you to have to re-IP the interfaces.

  • Customer A
    SP_Router(config)#interface lo1
    SP_Router(config-if)#ip vrf forwarding Customer_A
    SP_Router(config-if)#ip address 192.168.1.1 255.255.255.255
    SP_Router(config)#interface g0/0
    SP_Router(config-if)#ip vrf forwarding Customer_A
    SP_Router(config-if)#ip address 10.1.1.1 255.255.255.252
  •  

  • Customer B
    SP_Router(config)#interface lo2
    SP_Router(config-if)#ip vrf forwarding Customer_B
    SP_Router(config-if)#ip address 192.168.2.1 255.255.255.255
    SP_Router(config)#interface g0/1
    SP_Router(config-if)#ip vrf forwarding Customer_B
    SP_Router(config-if)#ip address 10.1.2.1 255.255.255.252

These configurations have modified our picture somewhat. The figure below shows what the things look like now:

You can verify your configurations by using the show ip vrf command:

 

SP_Router #show ip vrf
Name Default RD Interfaces
Customer_A 192.168.1.1:100 Loopback1
    GigabitEthernet0/0
Customer_B 192.168.2.1:200 Loopback2
    GigabitEthernet0/1

Once you have the proper interfaces within the correct VRF, you can begin to establish IP connectivity and routing between the customer routers and the service provider routers. In the next tip in this series, I'll show you how to configure OSPF on each router and verify connectivity.

 


Doug Downer (CCIE #9848 and JNCIS #881) is a Sr. Consultant with Callisma, Inc., a wholly owned subsidiary of SBC Communications. Doug has over seven years' experience in the industry and currently provides high-level business and technology consulting for various federal clients in the Washington D.C. area.

This was last published in February 2009

Dig Deeper on VPN design

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchNetworking

SearchUnifiedCommunications

SearchTelecom

SearchSDN

Close