Home » Bury the hatchet » Option 1(10A): Back-to-Back VRF – Inter-AS MPLS VPN – The whole story (2) – Updated Dec 2008

Option 1(10A): Back-to-Back VRF – Inter-AS MPLS VPN – The whole story (2) – Updated Dec 2008

Well, lets start examining the different options that we have highlighted in the previous post one by one, in this post we shall be covering Option 10A (Type A as described in RFC 4364).

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.

Configuration example:

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 3.3.3.3 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 20.20.20.1 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 1.1.1.1 remote-as 1
 neighbor 1.1.1.1 update-source Loopback0
 no auto-summary
!
 address-family vpnv4
  neighbor 1.1.1.1 activate
  neighbor 1.1.1.1 send-community extended
  neighbor 1.1.1.1 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 20.20.20.2 remote-as 2
  neighbor 20.20.20.2 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.

BR,
Mohammed Mahmoud.

5 comments

  1. Thanks for your information,it’s very useful!

  2. Hello, Thanks for the nice post.

    I have designed InterAS option A with 2 ASBR per Autonomous system for site redundancy. And the peering between AS is eBGP. It is working fine, now the problem is “failover time”. When site-1 goes down it is taking a longtime to shift to second site. How I can tune the BGP convergence? Or what would be the best solution in such case?

  3. Nice example for explanation :)

  4. Hi Amit,

    In your setup, failover time is depending mainly on BGP timers to converge.
    You can use BFD over eBGP sessions to speed up failover time

Leave a Reply

Your email address will not be published. Required fields are marked *