FRR IS-IS SR-MPLS IPv6 Labels: The IPv4 Loopback Mystery

Introduction: Unraveling the Core Problem with FRR, IS-IS, and SR-MPLS

Hey everyone, let's dive deep into a curious and frankly, a bit puzzling issue that network engineers are encountering with FRRouting (FRR), specifically when trying to implement Segment Routing over MPLS (SR-MPLS) in an IPv6-only IS-IS environment. Imagine this: you’ve meticulously designed your network to be forward-thinking, completely embracing IPv6 for your loopback addresses, aiming for a clean, modern infrastructure. You're using IS-IS as your Interior Gateway Protocol (IGP), which is a solid, scalable choice, and you've got SR-MPLS enabled because, let's be honest, it's the future of traffic engineering. Everything should work seamlessly, right? Well, not quite. The head-scratcher here is that SR-MPLS transport labels, which are absolutely crucial for getting your data packets where they need to go efficiently, simply aren't being exchanged for your IPv6 loopback addresses within this pure IPv6 setup. This means your network, despite being configured for cutting-edge segment routing, isn't fully leveraging its capabilities for IPv6 prefixes. It’s like having a brand-new, high-performance sports car but being stuck in first gear – you know it can do more, but something's holding it back. This unexpected behavior has been observed across several FRR versions, including 10.3, 10.4.1, and even 10.5, suggesting it might be a deeper architectural quirk rather than a fleeting bug. The biggest plot twist? Adding a seemingly unrelated /32 IPv4 address to the very same IPv6 loopback interface magically fixes the transport label exchange for your IPv6 addresses. Yes, you read that right. An IPv4 address, which you didn't even want in your IPv6-only world, becomes the unexpected hero, enabling proper SR-MPLS functionality for your IPv6 prefixes. This kind of dependency on an IPv4 address in an otherwise IPv6-centric network can be a real headache for network architects striving for complete IPv6 adoption and streamlined configurations. We're talking about an issue that can significantly impact the deployment of IPv6-only data centers and service provider networks that rely heavily on Segment Routing for its programmability and efficiency. Understanding and addressing this FRR IS-IS SR-MPLS IPv6 Loopback Label Issue is paramount for anyone building future-proof networks. It's not just about a missing label; it's about potentially hindering the full promise of IPv6 and Segment Routing working together in perfect harmony. So, let’s peel back the layers and understand why this is happening and what it means for your network designs and operational strategies. We’ll explore the exact symptoms, how to reproduce them, and the baffling workaround that brings everything back online, all while keeping a friendly, conversational tone. Get ready, because this is where network troubleshooting gets interesting!

Diving Deep: The Mysterious Case of Missing SR-MPLS Labels in IPv6-Only IS-IS

Let's get down to the nitty-gritty of this perplexing situation where SR-MPLS transport labels seem to play hide-and-seek in an IPv6-only FRR IS-IS setup. You've configured your routers, your interfaces are up, and IS-IS is chugging along, but when you peek at your IPv6 routing table for those crucial transport labels, they're just... gone. Specifically, the problem manifests when you configure IPv6 /128 loopback addresses on your PE (Provider Edge) routers, use IS-IS as your IGP, and enable MPLS and Segment Routing. In a perfect world, IS-IS should advertise these IPv6 prefixes along with their corresponding MPLS transport labels (SIDs), allowing for seamless segment routing paths. However, in this IPv6-only scenario, the labels for remote IPv6 loopbacks don't appear as expected in the show ipv6 route isis output. Instead of seeing a beautiful label 20022 (or whatever SID you've assigned), you might see label IPv6 Explicit Null for some prefixes or, more critically, no transport label at all for others, just a weight. This omission completely defeats the purpose of SR-MPLS for those particular IPv6 destinations, forcing traditional IP forwarding or breaking segment routing paths for IPv6. The Explicit Null label is fine for the destination itself, meaning it tells the penultimate hop to pop the label, but it doesn't give you a transport label to reach that destination across the network. The real head-scratcher, folks, is that the network does exchange the IPv6 prefixes themselves; IS-IS is doing its job in that regard. It's specifically the association and exchange of the SR-MPLS transport labels with these IPv6 prefixes that's falling short without that tiny IPv4 loopback address. This suggests that FRR's MPLS forwarding plane or its IS-IS integration for label distribution might have an implicit dependency on an IPv4 address being present on the loopback interface, even when handling purely IPv6 prefixes. It’s an unintuitive requirement that directly contradicts the goal of building a fully IPv6-native network. Think about it: you're trying to build a cutting-edge SRv6 network (or an SR-MPLS network primarily serving IPv6 services), and you're forced to add an IPv4 address just to make the MPLS labels work for IPv6. This isn't just an aesthetic issue; it can complicate IP address management, introduce unnecessary IPv4 overhead, and potentially create security surface area that wouldn't exist in a truly IPv6-only design. This behavior is particularly perplexing because IS-IS, unlike OSPF, doesn't inherently require an IPv4 address for its router ID (it uses the NET, Network Entity Title, which is independent of IP addresses). So, the