NetNotes

VRF Lite - VRFs without MPLS

MPLS VRFs are both a popular and widely advertised solution for provider VPNs and for segregating traffic through a backbone network, and they provide and rely on a few features to sell well

• Segmentation of the network traffic from different client devices on both sides of a cloud, usually a provider cloud;
• The option of keeping the clients routing information intact while carrying it through the cloud to another client device;
• The option for the provider to carry several client routing tables through its cloud in parallel, even if they contain overlapping address spaces, including overlapping RFC1918 addressing;

The traditional solution for such a situation, based on MPLS VPNs with separate VRF instances for each client, provides all of the features mentioned above, on the basis of a few technical items:

• A routing relationship between the client (Customer Edge, aka CE) router and the border router of the provider - Provider Edge aka PE router, using the clients routing protocol of choice ;
• The advertisement of all client networks over this routing relationship, just in the same way as if the PE router were part of the client network itself ;
• The existence of at least one VRF instance per client;
• Marking on behalf of the PE device of all client routes with a specific Route Distinguisher, aka RD tag, thus forming the so-called VPNv4 address;
• Redistribution, done by the PE device, of all client routes from the client routing protocol of choice into MP-iBGP, running only between the PE devices on both sides of the provider cloud;
• The existence of a stable IGP, sustaining the internal routing in the provider cloud, and consequently the MPLS core and MP-iBGP;
• The existence of a stable and scalable MPLS core;

All this is great if you are an ISP having a ready and stable MPLS core. However, if you are trying to develop a custom solution for your specific corporate network needs, there are a few challengfes you will face in terms of MPLS VPNs. Most of these challenges are related to device resource planning:

• You need 3 routing protocols on every PE device in your network (protocol that the client is running, MP-iBGP and a separate internal routing protocol to hold your own core network together);
• The PE devices need to be powerful and reliable enough to run and scale the 3 routing protocols needed, as well as the required number of VRFs or parallel routing tables;
• The core MPLS routers need to be powerful and scalable enough themselves;;

What the VRF Lite feature can offer is VRF functionality without the need for MPLS and its inherent complexity and resource usage, and without the need of multiple routing protocols on the PE devices. This way we can successfully carry several routing tables in parallel through a cloud without having MPLS inside it.

Using VRFs with MPLS implies that the segregation of the different client routing tables is achieved through using a separate protocol between the PE devices, carryng these client routing tables, tagged accordingly with the right RD tag.  In order to enable the same segregation of routing tables with VRF Lite, that is without MPLS, we need to have separate connectivity over which to run multiple routing neighborships between our devices, with each neighborship only carrying a single VRFs routing table.

We can use the following two lab scenarios to illustrate the differences between the two VRF configurations.

VRFs on an MPLS backbone with OSPF as an IGP

In this scenario we have a ready MPLS backbone, two client routers and two PE routers. We will only run a single VRF - maka.biz - for illustration purpose. The maka.biz VRF is configured to carry the clients routing table between the two client devices on the sides of or cloud. Lets have a look at the configuration of our two PE routers - R5 and R6 below.

R5:

!
version 12.4
service timestamps debug datetime
service timestamps log datetime
service password-encryption
!
hostname AggrR5
!
boot-start-marker
boot-end-marker
!
enable secret 5 $1$PQ3m$GEf/oh.1lkMcCFmSVv05t0
!
no aaa new-model
!
resource policy
!
ip cef
!
!
!We define the VRF here:
!————————
ip vrf maka.biz
rd 100:1
route-target export 1:100
route-target import 1:100
!
no ip domain lookup
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
username admin secret 5 $1$WQsy$l8IBaM0ei1LmFoBG8k/fb1
!
!
!
!
!
!
!
interface Loopback0
ip address 172.31.0.5 255.255.255.255
!
interface FastEthernet0/0
description IC to MPLSCore3 f0/0
ip address 172.30.254.2 255.255.255.252
duplex full
speed 100
mpls ip
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
interface POS1/0
ip vrf forwarding maka.biz
ip address 172.29.2.1 255.255.255.252
!
interface POS2/0
no ip address
shutdown
!
router eigrp 100
no default-information in
no auto-summary
!
address-family ipv4 vrf maka.biz
redistribute bgp 100 metric 64 1000 255 1 1500
network 172.29.2.0 0.0.0.3
no default-information in
no auto-summary
autonomous-system 100
exit-address-family
!
router ospf 100
router-id 172.31.0.5
log-adjacency-changes
redistribute connected subnets route-map INJECT-LOOPBACK-INTO-OSPF
network 172.30.254.0 0.0.0.3 area 1
!
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 172.31.0.6 remote-as 100
neighbor 172.31.0.6 update-source Loopback0
no auto-summary
!
address-family vpnv4
neighbor 172.31.0.6 activate
neighbor 172.31.0.6 send-community both
exit-address-family
!
address-family ipv4 vrf maka.biz
redistribute eigrp 100
no synchronization
exit-address-family
!
no ip http server
no ip http secure-server
!
!
!
!
ip prefix-list Permit-Local-Loopback description Permits only local Loopback address
ip prefix-list Permit-Local-Loopback seq 10 permit 172.31.0.5/32
ip prefix-list Permit-Local-Loopback seq 20 deny 0.0.0.0/0 le 32
logging alarm informational
!
!
!
route-map INJECT-LOOPBACK-INTO-OSPF permit 10
match ip address prefix-list Permit-Local-Loopback
set tag 101
!
!
!
!
control-plane
!
!
!
!
!
!
gatekeeper
shutdown
!
!
line con 0
login local
stopbits 1
line aux 0
stopbits 1
line vty 0 4
login local
!
!
end

We are running three separate routing protocols on our AggrR5 PE-router:

• EIGRP 100 with a vrf address space defined, that we are using to maintain a routing neighborship to the client router R7 over which we receive the client routes;
• BGP 100, which we are using for an iBGP neighborship to our other PE router R6; All the routes we receive in EIGRP 100 are being redistributed into the BGP process to be carried to R6 directly, without affecting our internal core routing table;
• OSPF 100, holding our internal routing and thus enabling the iBGP peering above and the MPLS core reachability, without carrying any client routes;

The configuration on the other PE router R6 is equivalent:

!
version 12.4
service timestamps debug datetime
service timestamps log datetime
service password-encryption
!
hostname AggrR6
!
boot-start-marker
boot-end-marker
!
enable secret 5 $1$9YEQ$uZlyuTzGqxufECuDjnf4s.
!
no aaa new-model
!
resource policy
!
ip cef
!
!
!
!
ip vrf maka.biz
rd 100:1
route-target export 1:100
route-target import 1:100
!
no ip domain lookup
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
username admin secret 5 $1$gJsl$bxfN4trCZLuWc1HnPaFpV1
!
!
!
!
!
!
!
interface Loopback0
ip address 172.31.0.6 255.255.255.255
!
interface FastEthernet0/0
description IC to MPLSCore4 f2/0
ip address 172.30.254.6 255.255.255.252
duplex full
speed 100
mpls ip
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
interface POS1/0
ip vrf forwarding maka.biz
ip address 172.28.2.1 255.255.255.252
!
interface POS2/0
no ip address
shutdown
!
router eigrp 100
no auto-summary
!
address-family ipv4 vrf maka.biz
redistribute bgp 100 metric 64 1000 255 1 1500
network 172.28.2.0 0.0.0.3
no default-information in
no auto-summary
autonomous-system 100
exit-address-family
!
router ospf 100
router-id 172.31.0.6
log-adjacency-changes
redistribute connected subnets route-map INJECT-LOOPBACK-INTO-OSPF
network 172.30.254.4 0.0.0.3 area 2
!
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 172.31.0.5 remote-as 100
neighbor 172.31.0.5 update-source Loopback0
no auto-summary
!
address-family vpnv4
neighbor 172.31.0.5 activate
neighbor 172.31.0.5 send-community both
exit-address-family
!
address-family ipv4 vrf maka.biz
redistribute eigrp 100
no synchronization
exit-address-family
!
no ip http server
no ip http secure-server
!
!
!
!
ip prefix-list Permit-Local-Loopback description Permit only local looopback0
ip prefix-list Permit-Local-Loopback seq 10 permit 172.31.0.6/32
ip prefix-list Permit-Local-Loopback seq 20 deny 0.0.0.0/0 le 32
logging alarm informational
!
!
!
route-map INJECT-LOOPBACK-INTO-OSPF permit 10
description Ijects only Lo0 into OSPF
match ip address prefix-list Permit-Local-Loopback
set tag 101
!
!
!
!
control-plane
!
!
!
!
!
!
gatekeeper
shutdown
!
!
line con 0
login local
stopbits 1
line aux 0
stopbits 1
line vty 0 4
login local
!
!
end

Haviong said this, we can see the difference in the configuration of VRF Lite with another, significantly simpler lab below.

VRF Lite without an MPLS core, using only EIGRP as a single routing protocol

This scenario is using a significantly simpler lab - we have only two routers, and instead of using seaparate “client” routers, we have two Loopbacks defined, to introduce two simulated “client” networks on both sides of our network. Each one of the client networks is assigned to a separate VRF, as is the connectivity between the two routers - we are using two IEEE 802.1q suibinterfaces in separate networks, thaty we use to run separate EIGRP neighborships for each VRF. The only routing protocol used here is EIGRP 100, carrying two VRFs - 1.maka.biz and 2.maka.biz which we can also use to store some core routes of our own in the main routing table (not in a VRF).

The configurations of the two routers are quite sim ple and are listed below.

R1:

!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R1
!
boot-start-marker
boot-end-marker
!
enable secret 5 $1$BZ3Q$Kb58LcCY0oG4J/vrStso2/
!
no aaa new-model
ip cef
!
!
!
!
ip vrf 1.maka.biz
rd 100:1
route-target export 1:100
route-target import 1:100
!
ip vrf 2.maka.biz
rd 200:2
route-target export 2:200
route-target import 2:200
!
multilink bundle-name authenticated
!
!
!
archive
log config
hidekeys
!
!
!
!
!
interface Loopback0
description NET1 - VRF 1.maka.biz
ip vrf forwarding 1.maka.biz
ip address 192.168.0.1 255.255.255.0
!
interface Loopback1
description NET2 - VRF 2.maka.biz
ip vrf forwarding 2.maka.biz
ip address 10.100.0.1 255.255.255.0
!
interface FastEthernet0/0
no ip address
duplex auto
speed auto
!
interface FastEthernet0/0.1
description IC to R2 in 1.maka.biz
encapsulation dot1Q 1 native
ip vrf forwarding 1.maka.biz
ip address 172.20.20.1 255.255.255.252
!
interface FastEthernet0/0.2
description IC to R2 ion 2.maka.biz
encapsulation dot1Q 2
ip vrf forwarding 2.maka.biz
ip address 172.16.16.1 255.255.255.252
!
interface FastEthernet0/1
no ip address
duplex auto
speed auto
!
router eigrp 1
passive-interface Loopback0
passive-interface Loopback1
no auto-summary
!
address-family ipv4 vrf 2.maka.biz
network 10.100.0.0 0.0.0.255
network 172.16.16.0 0.0.0.3
no auto-summary
autonomous-system 200
exit-address-family
!
address-family ipv4 vrf 1.maka.biz
network 172.20.20.0 0.0.0.3
network 192.168.0.0
no auto-summary
autonomous-system 100
exit-address-family
!
!
!
ip http server
!
!
!
control-plane
!
!
line con 0
line aux 0
line vty 0 4
password cisco
login
line vty 5 15
password cisco
login
!
scheduler allocate 20000 1000
end

R2:

!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R2
!
boot-start-marker
boot-end-marker
!
enable secret 5 $1$stQL$j.wQW62DA7okHjtwUtZEA.
!
no aaa new-model
no network-clock-participate wic 2
ip cef
!
!
!
!
ip vrf 1.maka.biz
rd 100:1
route-target export 1:100
route-target import 1:100
!
ip vrf 2.maka.biz
rd 200:2
route-target export 2:200
route-target import 2:200
!
multilink bundle-name authenticated
!
!
!
archive
log config
hidekeys
!
!
controller E1 0/2/0
!
!
!
!
interface Loopback0
description NET1 - VRF 1.maka.biz
ip vrf forwarding 1.maka.biz
ip address 10.100.1.1 255.255.255.0
!
interface Loopback1
description NET2 - VRF 2.maka.biz
ip vrf forwarding 2.maka.biz
ip address 192.168.1.1 255.255.255.0
!
interface FastEthernet0/0
no ip address
duplex auto
speed auto
!
interface FastEthernet0/0.1
description IC to R1 in 1.maka.biz
encapsulation dot1Q 1 native
ip vrf forwarding 1.maka.biz
ip address 172.20.20.2 255.255.255.252
!
interface FastEthernet0/0.2
description IC to R1 in 2.maka.biz
encapsulation dot1Q 2
ip vrf forwarding 2.maka.biz
ip address 172.16.16.2 255.255.255.252
!
interface FastEthernet0/1
no ip address
duplex auto
speed auto
!
router eigrp 1
passive-interface Loopback0
passive-interface Loopback1
no auto-summary
!
address-family ipv4 vrf 2.maka.biz
network 172.16.16.0 0.0.0.3
network 192.168.1.0
no auto-summary
autonomous-system 200
exit-address-family
!
address-family ipv4 vrf 1.maka.biz
network 10.100.1.0 0.0.0.255
network 172.20.20.0 0.0.0.3
no auto-summary
autonomous-system 100
exit-address-family
!
!
!
ip http server
!
disable-eadi
!
!
control-plane
!
!
line con 0
line aux 0
line vty 0 4
password cisco
login
line vty 5 15
password cisco
login
!
scheduler allocate 20000 1000
end

Conclusion

The functionality VRF Lite gives us in this case is similar to what could be called a “Layer3/routing VLAN” - we get separate routing information in multiple parallel routing tables. However, we need to have separate per-VRF connectivity to enable this routing segregation without MPLS and iBGP redistribution.  Such a solution does not rely on a cloud connectivity and possibly lacks some redundancy benefits a cloud could offer. The separate IP connectivity holding the separate per-VRF routing neighborships needs to be configured manually and throughout the whole backbone area that the VRFs need to span.  Although this could be a challenge, such a solution could prove itself viable in certain situations where we do not have an MPLS core, neither Metro Ethernet, and such a separation could not be done with VLANs. An example could be a radio network of relay stations, providing layer 1 and layer 2 connectivity with limited features, with IP and routing running over it. VRF Lite could be a viable solution for this type of problem ion such an environment where we do not have the option metro ethernet-like functionality such as vlans or spanning-tree.

Having said this and realizing the different issues VRF Lite and MPLS VPNs address, VRF Lite could possibly appear as a nail in the MPLS coffin, as it can offer one of the widely proclaimed MPLS benefits that are VRFs in a completely non-MPLS environment say Metro Ethernet or another.

Tags: BGP, EIGRP, metro ethernet, MP-iBGP, MPLS, OSPF, Routing, VRF, VRF Lite

1 Comment to VRF Lite - VRFs without MPLS

1. 

   respected sir

   please send me detail about product of your compapny

   ravi mhaske
   chairman
ravi on November 20th, 2009

Leave a comment