🌁The road to success is paved with…IPv4 over SRv6 over ISIS and BGP on SR OS 21.10🌄

8 SR OS nodes performing SPRING

“One packet does not make SPRING” — yours truly

The IETF Source Packet Routing in Networking (SPRING) working group was created in 2013, shortly after my family and I emigrated from Europe to Canada. I can’t say I’ve ever been involved personally, I have heard about Segment Routing as a concept but hadn’t really done anything with it until now. Especially in the context of “SRv6” it regularly seems to get derided as a networking vendor ploy to sell more equipment — but while I can confirm nor deny the level of truth in that, I am technically intrigued.

For every problem there are countless solutions, and this is especially true in networking. Does the world really need Yet Another Method to send packets from A to B? The strive for simplicity would seem to imply a minimal amount of variations and protocols, but how can we know what “simple” looks like? This line of thinking inspired a challenge 🥶: Build the most complicated combination of protocols you can imagine, then take it from there.

SRv6 — “or some people would feel left out”

Never too shy to share his thoughts, Ivan confirmed that SRv6 should definitely be included in such an exercise. A quick Google search resulted in this starting point by Juniper, and the resulting Netsim-Tools topology brings it to life.

New: Netsim-Tools srv6 core module

Netsim-Tools (v1.0) has support for ‘regular’ segment routing, but not (yet) for srv6. A simple module was easily built; basically every node needs a unique IPv6 ‘locator’ prefix to be assigned.

I also added some BGP peering flags to select the right combination of protocol families and peering sessions.

SRv6 configuration on SR OS (IPv4 over SRv6)

SRv6 is a relatively recent feature in the SR OS platform, and comprehensive sample configuration snippets were a little hard to come by. The final template is only a little over 100 lines, but there are some key knobs that must be aligned for things to work smoothly. Here is an overview of the main config items:

Base router SRv6 with explicit Forwarding Path Element configuration and ‘end-dt4’ to get BGP service SIDs

ISIS SRv6 configuration — requires ‘wide metrics’ and ‘ipv6-routing: native’ for TLVs to be advertised

Don’t ignore what your neighbors tell you…

Differences

Unlike the original Juniper example, this configuration advertises the SRv6 service SIDs using BGP (iBGP via R2 as Route Reflector). There is no need for a policy to modify the next hop manually; instead, ‘next-hop-self’ causes the SRv6 TLV attributes to be added. The Route Reflector itself does not need to enable SRv6, but it must support IPv6 next hops for IPv4 routes ( ‘extended-nh-encoding’ and ‘advertise-ipv6-next-hops’ for ipv4)

Basic verification

ipv4 route details (received via RR)

Resulting SRv6 tunnels between R0 and R7

Working pings from h1 to h2

Next hops 👣

Obviously a lot more could be said about this setup: There is Loop Free Alternate (LFA) to be explored and tested, and what about Flex-Algo to engineer different paths besides the shortest one(s)?

I’ll leave things here for now (and thanks go to my Nokia colleague Neil Pescod for his SR OS SRv6 slide deck). Until our paths cross again!