The 2 AM Network Overhaul: Why SRv6?
It’s 2 AM, and I’m staring at a legacy MPLS core that is finally hitting its limit. LDP flaps are triggering micro-loops, and the RSVP-TE tunnels we built for traffic engineering have become a management nightmare. This is the moment I realized that clinging to 20-year-old protocols while scaling a modern 100G backbone is a losing battle.
The industry is rapidly shifting toward Segment Routing over IPv6 (SRv6). Unlike traditional MPLS, SRv6 doesn’t need a separate label signaling protocol. It uses the IPv6 header itself to carry instructions, known as Segments. If your hardware can route IPv6, you are already halfway to a fully programmable network. Mastering this on Linux is the best way to escape proprietary hardware lock-in and build flexible, open infrastructure.
SRv6 vs. Traditional MPLS: The Paradigm Shift
The way we move packets is changing fundamentally. Traditional MPLS relies on a fragile stack of 32-bit labels. Every router in the path must agree on what those labels mean using LDP or BGP-LU. SRv6 replaces this complexity by using the 128-bit IPv6 address as the instruction set itself.
Key Differences
- Traditional MPLS: Requires LDP/RSVP. It maintains state at every hop. Troubleshooting becomes a headache when labels mismatch between vendors.
- SR-MPLS: This removes LDP but keeps the MPLS data plane. It’s a decent middle ground, but you’re still stuck with label depth limitations on older chipsets.
- SRv6: No labels required. The “Segment Identifier” (SID) is just a standard IPv6 address. You get native reachability and end-to-end programmability without an MPLS-aware underlay.
Real-World Pros and Cons
Before migrating your production core, you need to weigh the trade-offs I’ve seen in actual deployments.
The Pros
- Operational Simplicity: You can finally kill off LDP and RSVP. Your IGP (IS-IS or OSPFv3) handles the heavy lifting alone.
- Granular Traffic Engineering: You can steer low-latency voice traffic over a specific path just by changing the destination IPv6 prefix.
- Unified Monitoring: Everything is IPv6. Your existing Netflow collectors and Wireshark filters work out of the box because they don’t need to peek under an MPLS stack.
The Cons
- MTU Overhead: This is the big one. Every SID added to the Segment Routing Header (SRH) adds 16 bytes. If you have a path with 5 SIDs, you lose 80 bytes of MTU.
- Hardware Offloading: While the Linux kernel handles SRv6 perfectly in software, older NICs like the Intel i350 won’t offload the encapsulation. This can spike CPU usage on 10Gbps+ links.
Recommended Setup
SRv6 support has matured since Linux kernel 5.4. However, for a stable production environment, I recommend 5.15 or newer to avoid known bugs in the SRH processing logic.
- OS: Ubuntu 22.04 LTS or Debian 12.
- Routing Suite: FRRouting (FRR) version 8.5 or higher.
- Kernel: 5.15+ with
CONFIG_IPV6_SEG6_LWTUNNELenabled.
Implementation: Configuring an SRv6 Node
This setup configures a Linux node as an SRv6 LER (Label Edge Router). We will use IS-IS for the control plane and define a “Locator”—the IPv6 block used for this node’s specific instructions.
Step 1: Prep the Kernel
You must enable IPv6 forwarding and explicitly tell the kernel to process SRv6 packets on your interfaces. Run these commands:
# Enable IPv6 Forwarding
sudo sysctl -w net.ipv6.conf.all.forwarding=1
# Enable SRv6 processing on the backbone interface (e.g., eth0)
sudo sysctl -w net.ipv6.conf.eth0.seg6_enabled=1
sudo sysctl -w net.ipv6.conf.lo.seg6_enabled=1Step 2: Install FRRouting
Don’t use the default distro packages; they are often too old for advanced SRv6 features. Use the official FRR repository instead.
curl -s https://deb.frrouting.org/frr/keys.asc | sudo apt-key add -
FRR_REPO="deb https://deb.frrouting.org/frr $(lsb_release -s -c) frr-stable"
echo "$FRR_REPO" | sudo tee /etc/apt/sources.list.d/frr.list
sudo apt update && sudo apt install frr frr-pythontoolsStep 3: Define the SRv6 Locator
The locator is the pool of addresses that represent your node’s functions. Edit /etc/frr/daemons to set isisd=yes, then enter the FRR shell (vtysh).
conf t
!
segment-routing
srv6
locators
locator MAIN
prefix 2001:db8:1::/64
exit
!
exit
!Step 4: Link IS-IS to SRv6
IS-IS needs to advertise your locator to the rest of the network so other routers know how to reach your segments. Use this configuration:
router isis 1
net 49.0001.0000.0000.0001.00
is-type level-2-only
topology ipv6-unicast
!
segment-routing srv6
locator MAIN
!
interface eth0
ipv6 router isis 1
isis network point-to-point
exit
!Step 5: Verify the Data Plane
The magic happens in the kernel’s localsid table. This is where the OS maps incoming IPv6 SIDs to specific actions, like decapsulating traffic or cross-connecting to a VRF.
# View active SRv6 localsids
ip -6 sr localsid showExpected output: 2001:db8:1::1 dev lo action End. This confirms the router will process any packet destined for that address as an SRv6 endpoint rather than a standard host packet.
Final Thoughts from the Field
Deploying SRv6 on Linux requires a change in how you think about prefixes. You are no longer managing static circuits; you are managing a programmable address space. When I migrated our first test segment, the immediate benefit was the visibility. The routing table was cleaner, and we stopped chasing LDP neighbor timeouts. If you are building a private cloud or a regional ISP, Linux and FRRouting provide the most cost-effective path to mastering the tech powering modern 5G cores.
