Hello David
This is an interesting one since it involves the interconnection of multiple ASes within an MPLS domain. Just for completeness, let me briefly explain Options A and B in inter-AS MPLS design.
The basic idea is that two different MPLS autonomous systems connect through their ASBRs, and those ASBRs exchange VPNv4 routes together with MPLS labels using MP-eBGP. Unlike Option A, you do not create a separate VRF-facing link between the ASBRs for every customer VPN.
Let’s first take a look at the core issue. In Option B, the ASBR-to-ASBR link is intentionally kept outside IGP and LDP for AS isolation. This means the interconnect subnet (whether /30, /24, or any other mask) is never advertised into the IGP, so LDP never creates a label binding for it. Your eBGP session comes up fine. TCP reaches the peer, BGP’s “is next-hop reachable?” check passes — but there is no MPLS label entry (LFIB) for that next-hop address. When a VPNv4 packet with labels arrives at the ASBR, the forwarding engine has no label-switched path to traverse, so traffic drops. That is exactly the “control plane up, data plane down” symptom you described.
Why /32, not /24? RFC 4364 Section 5 states that BGP next-hops for VPN-IPv4 routes must be injected as /32 host prefixes into the IGP precisely so that each next-hop gets its own, unambiguous MPLS label binding. This pattern (used for PE loopbacks too) allows every LDP-speaking node along the path to bind a label to that exact FEC. A less-specific /24 covering the subnet would not inherently solve the problem, because:
- In Option B, the interconnect subnet itself is never redistributed into IGP at all — so a /24 simply doesn’t exist as an LDP route unless you manually created it.
- MPLS forwarding is built on an exact-match, it doesn’t fall back to “longest match” like IP routing does.
The solution: Inject a static /32 host route to the peer ASBR’s interface address and redistribute it into your IGP. This creates the missing FEC, LDP binds a label to it, and the label-switched path through the P routers to that next-hop becomes complete.
In an IOS/IOS-XE environment, when you enable eBGP VPNv4 peering on an interface, the mpls bgp forwarding feature is auto-applied, and IOS automatically installs the /32 host route for the peer and enables MPLS forwarding on it. IOS-XR’s architecture doesn’t do this auto-insertion, so you must configure it explicitly. That’s the documented difference between the two.
It’s simply the way it works. Why was IOS-XR designed like this? My personal opinion is that, because IOS-XR is built for carrier-grade environments, it tends to require certain behaviors and parameters to be configured explicitly rather than inferred or enabled automatically. This makes the configuration more deliberate, predictable, and easier to control at scale, especially in large and complex service-provider networks.
I hope this has been helpful!
Laz
PS: This was a learning experience for me too, so thanks for the question!