I have what seems to be a good SRv6 test in my lab running XRv9k 7.0.2

But I’m wondering why the sniffer doesn’t show the much-spoken-of SRH (Segment Routing Header)…. But rather, shows my L3VPN v4 traffic riding v6 and that’s it. Let me know if I’m seeing an SRH and just don’t know it, LOL.

Ethernet – Type 0x86dd

Ipv6 – Next Header IPIP (4)

Ipv4 – icmp echo (my tests ce to ce end to end)

Those layers is all it shows. I’ve read a lot about SRv6 with SID’s inside extension headers or segment routing header, but I’m not seeing it.

Any idea what this is that I’m seeing ?

I’ve configured the PE’s IAW

I can give you more info if you wish.


But rather, shows my L3VPN v4 traffic riding v6 and that�s it.

that is how SRv6 works. IPv6 + extension headers (+ a bit extra which is incompatible with ipv6).

Let me know if I�m seeing an SRH and just don�t know it, LOL.

Check out the IPv6 Extension Headers in the underlay packet.


Thanks Nick, I only see the following layers... I see no extension headers
behind the ipv6 header. I sent you the wireshark sniff directly so you can
see what I'm seeing.

Ethernet - Type 0x86dd
Ipv6 - Next Header IPIP (4)


you should see extension headers if you're doing more complex stuff? E.g. if you run a ping / traceroute with the "use-srv6-op-sid" parameter, or create a segment list under "segment-routing srv6 traffic engineering", that should throw in some EHs.


Oh snap! Hey hey, that's good, thanks Nick. I had to go into the locator service of the remote pe and find a sid that would respond to ping.

This is apparently an OAM Endpoint with Punt (End.OP)

Here I'm executing ping/trace from the SRv6 ingress the egress PE

RP/0/RP0/CPU0:r1#ping fc00:0:4:4::1 source lo0 use-srv6-op-sid fc00:0:0:4:40::
Mon Sep 14 20:27:09.727 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to fc00:0:4:4::1, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 329/371/416 ms

RP/0/RP0/CPU0:r1#traceroute fc00:0:4:4::1 source lo0 use-srv6-op-sid fc00:0:0:4:40::
Mon Sep 14 20:27:19.068 UTC

Type escape sequence to abort.
Tracing the route to fc00:0:4:4::1

1 ::ffff:
        [IP tunnel: DA=fc00:0:0:4:40:: SRH Stack 0 =(fc00:0:4:4::1 ,SL=1) ] 29 msec
        [IP tunnel: DA=fc00:0:0:4:40:: SRH Stack 0 =(fc00:0:4:4::1 ,SL=1) ] 56 msec
        [IP tunnel: DA=fc00:0:0:4:40:: SRH Stack 0 =(fc00:0:4:4::1 ,SL=1) ] 12 msec
2 ::ffff:
        [IP tunnel: DA=fc00:0:0:4:40:: SRH Stack 0 =(fc00:0:4:4::1 ,SL=1) ] 118 msec
        [IP tunnel: DA=fc00:0:0:4:40:: SRH Stack 0 =(fc00:0:4:4::1 ,SL=1) ] 101 msec
        [IP tunnel: DA=fc00:0:0:4:40:: SRH Stack 0 =(fc00:0:4:4::1 ,SL=1) ] 99 msec
3 fc00:0:4:4::1 224 msec 277 msec 254 msec
4 ::ffff: 237 msec 209 msec 204 msec
5 fc00:0:4:4::1 386 msec 431 msec 403 msec

Now I see this on the wireshark capture...

Ethernet - 86dd
Ipv6 - DA fc00:0:0:4:40:: (cool, this is the active/top SID, and not the ping'ed DA)
- routing header for v6 (segment routing)
--- segments left: 1
--- address next segment: fc00:0:4:4::1


My head hurts :-)...


yep, and you're not alone - the complexity level is pretty high, right from the control plane to the hardware.

It's not clear that the modest net gain in functionality is worth it.


Well, we know who's pushing this agenda, and why...

Here's hoping that a CTO and CEO near you do not drink the Kool-Aid, and
for once, can see right through a vendor's intentions.


Many people are buying hook, line and sinker on the narrative 'it is
just IP, nothing scary and complex like MPLS'. I think SRv6 is an
abomination, it is complex SW, and very complex HW, because it exists.
We pay the premium to add HW support for it.
For use cases it has, MPLSoUDP would do the same, fast, and it would
actually pass unmanaged IP domains, unlike SRv6, since many people
filter EH at edges.

And that is what the vendor(s) pushing this hope operators "realize"...
that SRv6 is a complex mess that needs some kind of centralized system
to manage. But wait, the centralized system is, itself, quite complex
that no operator would dare spend time installing, commissioning or
maintaining it themselves.

So what ever shall we do, as operators?

Simple, pay the vendor(s) to take care of all of it for you... planning,
design, spec'ing, bill of materials, deployment, operation and refresh
programs... lock that vendor top and bottom line in for them for the
next 10 years, while they find some other RFC to create in order to keep
the cycle going 11 years later.


Sorry guys, I'm not aware of much of what you mention as far as agenda, vendor motive, and hardware support, etc....

I'm still learning, but, It does seem interesting that the IP layer (v6) can now support vpn's without mpls. So one less layer of encapsulation seems cool. Don't get me wrong, I love all that mpls has done for us and offers, but, seems that SRx6 (x=v or m) is able to do it. Seems that the end to end label challenges with unified mpls, and all the csc and vpn type a,b,c might be better done with an IPv6 stack of headers and SIDs.

(wow, I'm not a prophet, but am I sensing another death of a labeling protocol ?! this would be interesting if like MPLS killed ATM.... SR kills MPLS !) (namely SRv6/SRm6)

And with this v6 SID being smartly divided into Locator:Function(Argument), I'm reading that this will carry with it much more functionality as well, like network programmability, application-to-network interaction or something like that.

Oh and I do agree that this SRv6 terminology and architecture does make your head hurt, lol, there is some very different/new stuff going on there.


You just move the encapsulation from in-order to inside-ip making
everything harder for SW and much harder for HW, the simplicity is a

Ultimately it is very simple, we need tunneling, then the question is
how much does it cost to look up those tunnel headers and how much
space they take on the wire (relevant for overspeed), everything else
is noise.

I'm still learning, but, It does seem interesting that the IP layer
(v6) can now support vpn's without mpls.

as the packet payload is nekkid cleartext, where is the P in vpn?

Hello All ,

to quantify this, the tunneling header increased in size from a minimum of 4 octets to a minimum of 40 octets. If you want explicit path routing, you'll need to tack on a SRH which is another 8 octets + 16 octets per SID, so e.g. an mpls frame with 2-node ERO goes from 12 octets to 80 octets.

This comes at a cost. What was previously a simple lookup operation on a tightly optimised format is now up to 10x bloated with little extra functionality to show for it. It's true that these devices already do ipv6, but can they do ipv6 + complex decapsulation in a single pass? If you're using an NPU, probably yes. If an ASIC, maybe not. What if the decapsulated packet has a stash of ipv6 extension headers? This gets complicated quickly, and that complication can only be solved by adding complication to silicon, which is what you want not to do when the speed of your underlying forwarding plane is increasing by leaps and bounds. Good, cheap, fast. Choose two - or maybe one.

The control plane is byzantine. This also has a cost in terms of design, build and support / maintenance. As Mark points out, many companies have made their fortunes with a full stack product offering, from hardware and software to design, engineering and operations. It's not a bad business model as long as you realise that it's time-limited to the technology of the day. When it draws to a close, it's hard to turn companies around that have been used to a single-product or single-vertical cash trough which no longer exists. Some have done this successfully; others have floundered.


GRE, VXLAN or any other tunneling encap of the day.
As long as next-hop could be resolved behind remote end


GRE, VXLAN or any other tunneling encap of the day.
As long as next-hop could be resolved behind remote end

i was not aware that GRE, VXLAN (without CN103618596A), and other tunnel
encaps encrypted the payload. learn something new every day. thanks!


Was meant as the reply to Aaron’s comment about VPN’s over non MPLS underlay, not the encryption of it (which is orthogonal).


"smartly divided"... Did someone else prepare these words for you? :wink:

You might be on to something, but I'm unsure... are you suggesting that it's
any less private over SRv6 than it was over MPLS ?