Theoretical foundations and architecture
Inter-AS Option B and Option C connect the VPNs of two operators at scale. In Option B the ASBRs run an eBGP session between themselves with the vpnv4 address family. There are no VRFs on the ASBRs: they receive VPNv4 prefixes, set next-hop-self, allocate new local VPN labels and forward labeled packets over a single link. Option B removes the growth of subinterfaces, but the ASBRs hold all the cross-operator VPN state. In Option C the ASBRs know no VPN routes at all: they exchange only PE/RR loopbacks with labels through BGP Labeled Unicast (BGP-LU, RFC 8277, formerly RFC 3107), while VPNv4 runs directly between the RRs (or PEs) of the two ASes over multihop eBGP with the next hop preserved. A packet carries up to three labels: the in-AS transport label, the BGP-LU label and the inner VPN label. Option C scales best, but it exposes core loopbacks and requires a high level of trust between operators.
Option B: the ASBR as a VPNv4 transit node
Inter-AS Option B (RFC 4364, section 10, variant "b") replaces the many boundaries of Option A with a single eBGP VPNv4 session between ASBR1 (10.1.0.1, AS 65000) and ASBR2 (10.1.0.2, AS 65001). No VRFs are created on the ASBR: it keeps the VPNv4 routes in the BGP table and simply passes them on. Inside its own AS, ASBR1 runs a regular iBGP VPNv4 session with the RR 10.255.0.100. By default an ASBR without VRFs discards routes whose RT is not imported by any VRF; to make it retain them an explicit command is needed: IOS-XE - no bgp default route-target filter, IOS-XR - retain route-target all, VRP - undo policy vpn-target in ipv4-family vpnv4, Junos - keep all on the group (check on your release).
Labels: a swap on every ASBR
When ASBR1 advertises the route of PE1 to its neighbor, it makes itself the next hop (for eBGP this is the default behavior) and allocates a new VPN label. The chain for 192.168.10.0/24 (RD 65000:100):
- PE1 advertises the route with next hop 10.255.0.1 and VPN label 22.
- ASBR1 receives it from the RR, allocates label 25 and writes into the LFIB:
25 -> swap 22, push the LDP transport label to PE1. - ASBR1 advertises the route to ASBR2 with next hop 10.1.0.1 and label 25.
- ASBR2 allocates its own label (for example, 31):
31 -> swap 25, send to 10.1.0.1, and passes the route into AS 65001 with next-hop-self and label 31.
The reverse path is a mirror image. A packet between the ASBRs carries exactly one label (the VPN label issued by the receiving ASBR); there is no transport label because the next hop is a directly connected neighbor on the link. For an eBGP session on a connected link the interface is enabled for MPLS with mpls bgp forwarding (IOS-XE; enabled automatically for an eBGP VPNv4 session), mpls on the VRP interface, family mpls on the Junos interface.
The price of Option B
| Parameter | Option B | Consequence |
|---|---|---|
| State on the ASBR | all VPNv4 routes of both ASes (whatever the ASBR decided to retain) | the table and the LFIB grow with the number of customers |
| Labels on the boundary | one VPN label | any L3/MPLS transport, QoS by EXP/TC |
| Agreement | the customer RT must match or be rewritten on the ASBR | the operators must agree on RTs |
| Trust | the neighbor can send any RT | an RT filter on the boundary is mandatory |
Without a filter the neighboring operator can send a route with your RT 65000:100 and get into a foreign VPN. Therefore a route-map/policy is applied on the boundary: accept only the agreed RTs and reject routes with RTs used only inside the AS. If the operators use different RTs, they are rewritten on the ASBR (Cisco set extcommunity rt ... additive and delete, Junos community delete/add).
Option C: an ASBR without VPN routes
In Option C (RFC 4364, 10c) the ASBRs do not know about customers at all. They exchange over eBGP only routes with labels (BGP-LU, AFI 1 / SAFI 4, RFC 8277, formerly 3107) to the loopbacks of PEs and RRs: 10.255.0.1/32, 10.255.0.100/32 from AS 65000 and 10.254.0.2/32, 10.254.0.100/32 from AS 65001. VPNv4 routes are exchanged directly between the RRs (or PEs) of the two ASes over a multihop eBGP loopback-to-loopback session, and the RRs must preserve the next hop (next-hop-unchanged on Cisco, multihop no-nexthop-change on Junos, next-hop-invariable on VRP). Then the next hop of a VPN route is the loopback of the remote PE, and this address must resolve into an LSP built through BGP-LU.
A stack of three labels
A packet PE1 -> PE3 in Option C: [transport label to ASBR1 | BGP-LU label to 10.254.0.2/32 | VPN label of PE3]. The top label is issued by LDP/SR inside AS 65000 and removed on the penultimate node; the middle label comes from ASBR1 (iBGP-LU with next-hop-self, on ASBR1 a swap to the label of ASBR2); the bottom one is the VPN label of PE3. If the ASBR redistributes the /32s into the IGP and LDP issues the transport labels, the PE sees only two labels. ASBR1 switches by the middle label and looks neither into a VRF nor into the VPN. This gives maximum scale: tens of /32s on the ASBR instead of millions of VPN routes.
Comparison of Options A, B and C
| A | B | C | |
|---|---|---|---|
| Sessions on the boundary | N (per VPN) | 1 eBGP VPNv4 | 1 eBGP LU (+ multihop VPNv4 between RRs) |
| Labels on the boundary | none | 1 (VPN) | 1 (LU) + nested |
| ASBR state | a VRF per customer | all VPNv4 routes | only the /32s of PEs and RRs |
| Trust between operators | minimal | medium (RT filters) | high (loopbacks are exposed, a common RT) |
| Troubleshooting | simple | medium | hard (3 labels, 2 planes) |
Failures and traps
- The ASBR accepts the session but the VPNv4 table is empty:
no bgp default route-target filter/keep allis missing; the routes are dropped by RT. - PE1 sees the route but the next hop is unreachable: the ASBR did not set next-hop-self towards the RR, and PE1 received the address 10.1.0.2 outside its IGP.
- Option C: the RR received the routes but traffic does not flow:
next-hop-unchangedwas lost, the next hop became the RR loopback, the labels did not match. - Option C: the multihop session does not come up: there is no route to 10.254.0.100 (BGP-LU did not reach the RR), TTL 1 instead of
ebgp-multihop. - MTU: Option C adds 12 bytes (three labels), Option B 4-8; check with large pings with DF.
- Convergence: eBGP sends updates with an MRAI of 30 s by default (Cisco
advertisement-interval); add BFD on the boundary.
