Theoretical foundations and architecture
Inter-AS Option A (Back-to-Back VRF, RFC 4364) interconnects Autonomous System Boundary Routers (ASBRs) across provider domains using subinterfaces dedicated per tenant VRF. No MPLS encapsulation crosses the inter-AS boundary; the link behaves as standard back-to-back IP peerings running per-VRF eBGP or static routing. Benefits include simplicity, total control-plane isolation, and zero requirement to negotiate inter-provider LDP or MP-BGP peering. However, scalability is fundamentally constrained: provisioning each tenant requires a discrete 802.1Q subinterface and distinct BGP session on both ASBRs, incurring severe state expansion when supporting hundreds of customer VPNs.
The idea of Option A: two PEs glued with a cable
Inter-AS Option A (RFC 4364, section 10, variant "a") introduces no new protocols. ASBR1 in AS 65000 and ASBR2 in AS 65001 are ordinary PEs, each with its own customer VRFs; they are connected by interfaces, and ASBR1 sees ASBR2 as a CE and vice versa. That is why the design is called back-to-back VRF: every VPN gets its own (sub)interface and its own routing session (eBGP, OSPF or static) inside the VRF. The operators have to agree on neither RDs, nor RTs, nor MPLS at the boundary: in AS 65000 customer A lives with RD/RT 65000:100, in AS 65001 with 65001:100, and these values are not related to each other.
Control plane
The customer A route 192.168.20.0/24 follows this path:
- CE2 -> PE3 (AS 65001): the ordinary PE-CE protocol.
- PE3 -> ASBR2: MP-iBGP VPNv4 (RD 65001:100, RT 65001:100, VPN label).
- ASBR2 imports the route into VRF CUST-A by RT, then advertises it to the neighbor 10.1.100.1 as a plain IPv4 prefix (eBGP inside the VRF, AS_PATH 65001 ...).
- ASBR1 accepts the prefix in VRF CUST-A, adds RD 65000:100 and exports it as VPNv4 with RT 65000:100 to the RR 10.255.0.100.
- PE1 imports it into its VRF and hands it to CE1.
In steps 3-4 the RD/RT/VPN-label information of the foreign AS is lost: the ASBR is the boundary of responsibility, and the VPN information is "cut off" here.
Data plane
A packet 192.168.10.5 -> 192.168.20.7 crosses AS 65000 with the stack [LDP transport | VPN label of ASBR1]. At ASBR1 the transport label has already been removed (PHP on the penultimate node), the VPN label selects VRF CUST-A, and the packet leaves into VLAN 100 without a single label: Outgoing label = No Label. ASBR2 receives plain IPv4, performs an IP lookup in its VRF CUST-A and pushes the AS 65001 stack. Consequences: any L3 switch or firewall works at the boundary, the QoS policy is built on DSCP (EXP/TC do not cross the border), and the MTU of the link is the ordinary IP MTU plus 4 bytes of VLAN tag, but not plus labels.
What really scales badly
| Resource | Cost per VPN | What happens with 500 VPNs |
|---|---|---|
| Subinterface / VLAN | 1 | 802.1Q gives 4094 VLANs per port, beyond that QinQ or a new port is needed |
| BGP session | 1 | 500 sessions with keepalive 60 s / hold 180 s on each ASBR |
| VRF and tables | 1 | memory for a full copy of every customer's prefixes |
| Provisioning | 2 ASBRs x (VRF + sub-if + BGP) | more configuration errors, automation is required |
A separate drawback is that a failure of the physical link drops all VPNs at once; this is compensated with a LAG or two independent links and BFD on the sessions.
eBGP in a VRF and AS_PATH loops
If the customer uses the same AS number on both sites (for example, AS 65100), the route from CE2 reaches CE1 with AS_PATH 65000 65001 65100, and CE1 discards it by loop prevention. Solutions: neighbor ... as-override on PE1/PE3 (Cisco; Huawei - peer ... substitute-as, Junos - as-override in the group) or allowas-in on the CE. This is not specific to Option A, but at the AS boundary the problem is more visible: the AS_PATH chain is longer. With static routes and an IGP the problem does not exist, but then the ASBR must redistribute routes into the BGP VRF.
Labels on the ASBR: per-prefix and per-VRF
By default Cisco allocates a VPN label per prefix (per-prefix). For a prefix received over eBGP from ASBR2 the label points straight at the next hop 10.1.100.2 - without a second lookup. The per-VRF mode (mpls label mode vrf CUST-A protocol bgp-vpnv4 per-vrf) saves labels but requires an IP lookup in the VRF on receipt. Junos is similar: by default the label points at the next hop, and vrf-table-label enables a lookup in the VRF (needed, for example, when filtering by VRF is required at egress).
Security of the boundary
In Option A the ASBR sees only IPv4 customer prefixes and does not trust the neighboring operator: on every session set maximum-prefix (Huawei - route-limit, Junos - prefix-limit), filters for the expected customer prefixes and session protection (MD5/TCP-AO, GTSM ttl-security). There are no RTs and no labels at the boundary - so the operator cannot "flood" foreign VPN routes into your VRF by forging RTs. This is the main advantage of Option A and the reason it is chosen between operators that do not trust each other.
Option AB (hybrid)
For cases where the scale of Option A is too small and the isolation of Option B is insufficient, there is a hybrid (Cisco calls it Inter-AS Option AB, some documents "Option D"): the control plane works like Option B (a single VPNv4 session between the ASBRs) and the data plane like Option A (a separate interface per VRF, an IP lookup in the VRF). The implementation and name depend on the platform; in this course it is only mentioned, so check support on your own equipment.
