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
| Aspect |
Option A (Back-to-Back VRF) |
(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). |
| 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.
