# MPLS Inter-AS Option B
**URL:** https://forum.networklessons.com/t/mpls-inter-as-option-b/58842
**Category:** BGP
**Created:** [September 14, 2026, 5:40pm UTC](https://forum.networklessons.com/t/mpls-inter-as-option-b/58842 "2026-09-14T17:40:26Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@davidilles](https://forum.networklessons.com/u/davidilles)
#### Post date: [September 14, 2026, 5:40pm UTC](https://forum.networklessons.com/t/mpls-inter-as-option-b/58842/1 "2026-09-14T17:40:26Z")
Hello, Laz
I have a slightly complicated question regarding inter-AS MPLS Option 2.
When we configure the BGP VPNv4 session between the two ASBRs, why does the BGP next-hop need a /32 route for the next-hop **in order for MPLS to work?**
**Cisco:**
_For IOS-XR over Inter-As Option B link there is a different logic as compared to that of IOS. It is required to configure a static /32 route to ASBR1’s interface, so that mpls label is bound for a /32 prefix. If this is not done then control plane will come up but the traffic will not be forwarded._
May I know why does it work this way? I don’t quite understand what the problem is if the prefix isn’t /32? Does this have to do anything that I might have possibly missed with MPLS’s operation?
I understand that MPLS needs the next-hop to be resolved via a label binding but that can be simply accomplished by even using /24 routes, or not?
The funny thing is, IOS-XE also wants a /32 route but it adds it automatically once you define the VPNv4 peering on the ASBRs
`C 192.168.45.0/24 is directly connected, GigabitEthernet1 `
`L 192.168.45.4/32 is directly connected, GigabitEthernet1 `
**`C 192.168.45.5/32 is directly connected, GigabitEthernet1 - next hop`**
So do we know how is it? Documentation states “do it this way” but I don’t quite understand why /32 is so important here and why it breaks the data plane otherwise…
Thank you!
David
---
### Author:  [@lagapidis](https://forum.networklessons.com/u/lagapidis)
#### Post date: [September 20, 2026, 6:43am UTC](https://forum.networklessons.com/t/mpls-inter-as-option-b/58842/2 "2026-09-20T06:43:04Z")
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](https://datatracker.ietf.org/doc/html/rfc4364#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:
1. 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.
2. 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!