Comparing Inter-AS MPLS L3VPN Options (A, B, C)

When an L3VPN service needs to span across two different service providers, an Inter-AS L3VPN solution is required. This scenario is common for national or international circuits where a single service provider is not present in both locations. The routers connecting the two autonomous systems (AS) are known as Autonomous System Border Routers (ASBRs) or boundary routers. In this article I will go into the three primary options for connecting L3VPNs across autonomous system boundaries: Option A, Option B, and Option C, highlighting their distinct characteristics, operational mechanisms, and suitability for various deployment scenarios.

Inter-AS L3VPN Options: Overview

The following table summarizes the key differences between Inter-AS L3VPN Option A, Option B, and Option C, drawing from design considerations, scalability, security, and operational complexity 
 
Aspect

Option A

(Back-to-Back VRF)


Option B

(VPNv4 between ASBRs)

Option C

(RR-to-RR VPNv4)
Scalability Least scalable Moderate Highest
Security Most secure Lower Lowest
Resource Utilization High (per VRF state on ASBRs) Moderate Low (ASBRs only exchange loopbacks)
Label Handling No MPLS between ASBRs Yes, via BGP (RFC 3107) Yes, via BGP LU + RT exchange
Complexity Simple More complex Very complex
BGP AF IPv4 per VRF VPNv4 VPNv4 (multihop)
Typical Use Case Small deployments, high security Medium scale, simpler than C Large-scale carriers, scalability focus

Inter-AS Option A – Back-to-Back VRF

Topology

Theory

Option A is the simplest to understand and deploy. Each provider treats the other as a customer, and the ASBRs host VRFs for every inter-AS VPN. Routing information is exchanged within those VRFs across dedicated interfaces or subinterfaces. Because the ASBRs carry customer traffic and maintain full VRF state, the model is very resource-intensive and scales poorly.

The clear benefit of Option A is its simplicity and strong per-VRF isolation. It gives providers granular control and is also considered the most secure option since the separation between customers is maintained on a per-VRF basis. However, the main drawback is low scalability. As the number of VPNs increases, ASBRs quickly become bottlenecks due to the overhead of maintaining VRFs, policies, and forwarding state for every customer.

Packet Walk

 

Hop Device Action on Labels Resulting Packet Notes
1 PE1 (AS 65000) Imposes VPN label (e.g., 24000) [VPN L=24000] IP(192.168.3.1) CE1 in VRF RED sends traffic. PE1 pushes VPN label for CE3’s prefix (learned via MP-BGP).
2 P1 (AS 65000 core) Swaps VPN label via LDP [VPN L=24000] IP(...) Core does normal MPLS forwarding within AS 65000.
3 ASBR1 (10.0.0.1) Pops VPN label, forwards as plain IPv4 in VRF RED IP(192.168.3.1) Since the inter-AS link is VRF-aware (subinterface in VRF RED), ASBR1 removes the VPN label and sends raw IPv4.
4 ASBR2 (10.0.0.2) Receives IPv4 in VRF RED, re-imposes new VPN label (e.g., 31000) [VPN L=31000] IP(192.168.3.1) Acts like a PE — assigns new VPN label for CE3’s VRF RED in AS 651111.
5 P2 (AS 651111 core) Swaps VPN label via LDP [VPN L=31000] IP(...) Normal MPLS forwarding in AS 651111.
6 PE2 (AS 651111) Pops VPN label 31000 IP(192.168.3.1) Packet is placed into VRF RED and forwarded to CE3.

Configure

====== AS65000
====== ASBR:


! VRF RED
vrf RED
 rd 65000:1
 address-family ipv4 unicast
  import route-target 65000:1
  export route-target 65000:1

! VRF BLUE
vrf BLUE
 rd 65000:2
 address-family ipv4 unicast
  import route-target 65000:2
  export route-target 65000:2

! Subinterfaces for VRFs
interface GigabitEthernet0/0/0/0.10
 vrf RED
 ipv4 address 10.0.0.1 255.255.255.252

interface GigabitEthernet0/0/0/0.20
 vrf BLUE
 ipv4 address 10.0.0.5 255.255.255.252

! Route-policies
route-policy PASS
  pass
end-policy

router bgp 65000
 address-family vpnv4 unicast
  neighbor 10.0.0.99
   remote-as 65000
   update-source Loopback0
   route-reflector-client
   address-family vpnv4 unicast
    send-community both

 ! VRF RED
 vrf RED
  rd 65000:1
  address-family ipv4 unicast
   neighbor 10.0.0.2
    remote-as 651111
    address-family ipv4 unicast
     route-policy PASS in
     route-policy PASS out

 ! VRF BLUE
 vrf BLUE
  rd 65000:2
  address-family ipv4 unicast
   neighbor 10.0.0.6
    remote-as 651111
    address-family ipv4 unicast
     route-policy PASS in
     route-policy PASS out

====== AS65111
====== ASBR:


! VRF RED
vrf RED
 rd 65111:1
 address-family ipv4 unicast
  import route-target 65111:1
  export route-target 65111:1

! VRF BLUE
vrf BLUE
 rd 65111:2
 address-family ipv4 unicast
  import route-target 65111:2
  export route-target 65111:2

! Subinterfaces for VRFs
interface GigabitEthernet0/0/0/0.10
 vrf RED
 ipv4 address 10.0.0.2 255.255.255.252

interface GigabitEthernet0/0/0/0.20
 vrf BLUE
 ipv4 address 10.0.0.6 255.255.255.252

! Route-policies
route-policy PASS 
  pass
end-policy

router bgp 65111
 address-family vpnv4 unicast
  neighbor 10.111.111.99
   remote-as 651111
   update-source Loopback0
   route-reflector-client
   address-family vpnv4 unicast
    send-community both

 ! VRF RED
 vrf RED
  rd 65111:1
  address-family ipv4 unicast
   neighbor 10.0.0.1
    remote-as 65000
    address-family ipv4 unicast
     route-policy PASS in
     route-policy PASS out

 ! VRF BLUE
 vrf BLUE
  rd 65111:2
  address-family ipv4 unicast
   neighbor 10.0.0.5
    remote-as 65000
    address-family ipv4 unicast
     route-policy PASS in
     route-policy PASS out

Inter-AS Option B – VPNv4 Peering Between ASBRs

Topology

Theory

Option B removes the need for ASBRs to carry individual VRFs by establishing an eBGP VPNv4 session between the boundary routers. Labels are exchanged via BGP (RFC 3107), which allows traffic to remain MPLS-encapsulated across the inter-AS link. Compared to Option A, this reduces configuration overhead on the ASBRs and avoids per-VRF scaling issues.

The main advantage of Option B is improved scalability while still being relatively straightforward to deploy. Because a single VPNv4 eBGP session can carry multiple customers’ routes, the operational burden is lighter. However, Option B introduces complexity around label distribution and next-hop handling, which requires careful configuration. Security is weaker compared to Option A, since VRF separation is no longer enforced at the ASBRs, and providers must rely more on BGP policy control.

Packet Walk

 

Hop Device Action on Labels Resulting Label Stack Notes
1 PE1 (AS 65000) Imposes two labels [Transport L=16045] [VPN L=24000] Outer = LDP label toward ASBR1. Inner = VPN label allocated by PE2, learned via VPNv4 eBGP exchange between ASBRs.
2 P1 (AS 65000 core) Swaps outer 16045 → 16051 [16051] [24000] Normal LDP transport in AS 65000. Inner VPN label untouched.
3 ASBR1 (10.0.0.1) Swaps outer 16051 → 20010 [20010] [24000] ASBR1 knows VPNv4 routes and their labels (from ASBR2). It preserves the inner VPN label 24000.
4 ASBR2 (10.0.0.2) Swaps outer 20010 → 30077 [30077] [24000] ASBR2 also carries VPNv4 routes. It forwards toward PE2 while preserving the inner VPN label.
5 P2 (AS 651111 core) Swaps outer 30077 → 16012 (PHP) [24000] Penultimate hop popping removes the transport label, leaving only the VPN label.
6 PE2 (AS 651111) Pops inner 24000 IP(192.168.3.1) Looks up 24000 in VRF RED, forwards packet to CE3.

Configure

====== AS65000
====== ASBR:


route-policy PASS
  pass
end-policy

router bgp 65000
 address-family vpnv4 unicast
  retain route-target all
  neighbor 10.0.0.2
   remote-as 651111
   address-family vpnv4 unicast
    route-policy PASS in
    route-policy PASS out
    send-community both
    next-hop-self

====== AS65111
====== ASBR:


route-policy PASS
  pass
end-policy

router bgp 65111
 address-family vpnv4 unicast
  retain route-target all
  neighbor 10.0.0.1
   remote-as 65000
   address-family vpnv4 unicast
    route-policy PASS in
    route-policy PASS out
    send-community both
    next-hop-self

Inter-AS Option C – VPNv4 Peering Between Route Reflectors

Topology

Theory

Option C represents the most scalable approach to inter-AS L3VPNs. In this model, ASBRs no longer carry customer VRF state or VPNv4 routes. Instead, only loopback reachability is exchanged between ASBRs using IPv4 labeled unicast. VPNv4 sessions are established directly between route reflectors (or in some cases PEs) in each AS. This pushes state away from the ASBRs and distributes it across the RR infrastructure, which is generally designed to scale.

The advantage of Option C is scalability. It allows providers to interconnect large numbers of VPNs without overwhelming the ASBRs, making it the preferred design for large carrier environments. On the other hand, it is also the most complex option to implement. Route reflectors must be carefully designed to handle the additional state, and policies must be applied to control route exchange. Security is weaker compared to the other options since providers exchange a much broader set of routes, and leaks are more difficult to contain

Packet Walk

 

These are the hops from CE device in the VRF RED on the left, towards CE device in the VRF RED on the right.

Hop Device Action on Labels Resulting Label Stack Notes
1 PE1 (AS 65000) Imposes labels [Transport L=16045] [VPN L=24000]

Outer = LDP/LU to PE2 loopback (10.111.111.2).
Inner = VPN label from PE2 for VRF RED.
2 P1 (AS 65000 core) Swaps outer 16045 → 16051 [16051] [24000] Standard LDP label swap toward ASBR1.
3 ASBR1 (10.0.0.1) Swaps outer 16051 → 20010 [20010] [24000] Label learned via BGP LU from ASBR2.
4 ASBR2 (10.0.0.2) Swaps outer 20010 → 30077 [30077] [24000] New LU label toward PE2 loopback.
5 P2 (AS 651111 core) Swaps outer 30077 → 16012 (PHP) [24000] Penultimate hop popping removes transport, leaves only inner VPN label.
6 PE2 (AS 651111) Pops inner 24000 IP(192.168.3.1) Looks up VPN label in VRF RED, forwards to CE3.

Configure

====== AS65000
====== ASBR:

route-policy PASS
  pass
end-policy

router bgp 65000
 address-family ipv4 unicast
  allocate-label all
  neighbor 10.0.0.2
   remote-as 651111
   address-family ipv4 labeled-unicast
    route-policy PASS in
    route-policy PASS out
    
====== RR:
  
route-policy PASS
  pass
end-policy

router bgp 65000
 address-family vpnv4 unicast
  neighbor 10.111.111.99
   remote-as 651111
   update-source Loopback0
   ebgp-multihop 255
   address-family vpnv4 unicast
    route-policy PASS in
    route-policy PASS out
    send-community both
    next-hop-unchanged


====== PE:

vrf RED
 rd 65000:1
 address-family ipv4 unicast
  import route-target 65111:1      
  export route-target 65000:1  
  
  
====== AS65111
====== ASBR:

route-policy PASS
  pass
end-policy

router bgp 65111
 address-family ipv4 unicast
  allocate-label all
  neighbor 10.0.0.1
   remote-as 65000
   address-family ipv4 labeled-unicast
    route-policy PASS in
    route-policy PASS out
    
====== RR:

route-policy PASS
  pass
end-policy

router bgp 65111
 address-family vpnv4 unicast
  neighbor 10.0.0.99
   remote-as 65000
   update-source Loopback0
   ebgp-multihop 255
   address-family vpnv4 unicast
    route-policy PASS in
    route-policy PASS out
    send-community both
    next-hop-unchanged    
    
====== PE:

vrf RED
 rd 65111:1
 address-family ipv4 unicast
  import route-target 65000:1  
  export route-target 65111:1

Conclusion

Inter-AS MPLS VPN interconnects can be deployed in several ways, each with clear trade-offs.

Option A provides maximum isolation and security but quickly becomes unmanageable at scale.

Option B improves scalability by moving VRFs off the ASBRs but sacrifices per-customer policy control.

Option C achieves the highest level of scalability by limiting ASBR involvement, but it is operationally complex and comes with reduced security.

Ultimately, the choice depends on business drivers, scale, and security requirements. Smaller interconnects may favor Option A, while large carriers often rely on Option C.