The VRF-to-VRF (as stated in RFC 4364) or the back-to-back VRF (as named by Cisco) approach is the simplest method for allowing Inter-AS MPLS VPN between different providers.
In this approach, PE routers residing in different autonomous systems function as ASBRs, interconnected via either a single link consisting of logical subinterfaces or via multiple physical links.
VRFs are configured on the ASBRs to collect the VPN client routes, and each subinterface or interface connected between the ASBRs is dedicated to a single client VRF.
The single client VRF can run eBGP, RIPv2, EIGRP, OSPF, or static routing to distribute the VPN routes to its adjacent peer (each ASBR treats the facing ASBR as a CE, and they exchange IPv4 routes per VRF, in the same manner as a PE-CE routing protocol). However, the use of eBGP is the most common in the back-to-back VRF method because eBGP scales best to this type of applications, retaining the type of the route and offering better policy, scalability, and security mechanisms.
In this method, the LSP paths in adjacent MPLS VPN autonomous systems are interconnected using the traditional IP forwarding mechanism between the AS border routers, i.e. packets are forwarded as pure IP packets between the AS border routers.
The limitation in this approach is due to the need of separate interfaces/subinterfaces and eBGP sessions per VRF on the ASBRs (scalability issue), however this is the widely deployed Inter-AS option used today. Actually the fact of the need of an eBGP session per VRF is the major scalability issue with this approach, and this drawback is tackled with the latest addition to the inter-AS options; Option AB.
The configuration for the back-to-back VRF method on the ASBR routers is similar to the ordinary configuration on a PE router providing MPLS VPN services, the routing protocol is configured under the address-family ipv4 vrf as was the case with the PE-CE routing protocols – In the below example we shall use eBGP since it is the common practice.
We simply use the provider ASN for all the VRFs eBGP peering on both ASBRs, and use the directly connected interface/subinterface belonging to the VRF on both ASBRs for the eBGP peering (if loopbacks are to be used its obvious that they must belong to the VRF on both sides).
Here is a simple example for the ASBR configuration using eBGP as the routing protocol:
! ip vrf test rd 1:1 route-target import 1:1 route-target export 1:1 ! ip vrf test2 rd 2:2 route-target import 2:2 route-target export 2:2 ! interface Loopback0 ip address 126.96.36.199 255.255.255.255 ! interface ATM1/0.1 point-to-point description Connection to P1 ip address 10.10.23.3 255.255.255.0 ip router isis mpls ip ! interface FastEthernet0/0.10 encapsulation dot1q 10 ip vrf forwarding test ip address 10.10.10.1 255.255.255.0 ! interface FastEthernet0/0.20 encapsulation dot1q 20 ip vrf forwarding test2 ip address 188.8.131.52 255.255.255.0 ! router isis net 49.0001.0030.0300.3003.00 is-type level-2-only metric-style wide log-adjacency-changes passive-interface Loopback0 ! router bgp 1 no synchronization bgp log-neighbor-changes neighbor 184.108.40.206 remote-as 1 neighbor 220.127.116.11 update-source Loopback0 no auto-summary ! address-family vpnv4 neighbor 18.104.22.168 activate neighbor 22.214.171.124 send-community extended neighbor 126.96.36.199 next-hop-self exit-address-family ! address-family ipv4 vrf test neighbor 10.10.10.2 remote-as 2 neighbor 10.10.10.2 activate no auto-summary no synchronization exit-address-family ! address-family ipv4 vrf test2 neighbor 188.8.131.52 remote-as 2 neighbor 184.108.40.206 activate no auto-summary no synchronization exit-address-family !
I hope that I’ve been informative, and I’ll be covering the rest of the options in the upcoming posts.