From 8ace5cf9fffb6267f5fcab7e57fd0cd4617bfc09 Mon Sep 17 00:00:00 2001 From: Pim van Pelt Date: Sat, 21 Feb 2026 16:02:56 +0000 Subject: [PATCH] Grammar and readability improvements, h/t Claude --- content/articles/2026-02-21-vpp-srv6.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/content/articles/2026-02-21-vpp-srv6.md b/content/articles/2026-02-21-vpp-srv6.md index 238d698..d1bba5c 100644 --- a/content/articles/2026-02-21-vpp-srv6.md +++ b/content/articles/2026-02-21-vpp-srv6.md @@ -71,7 +71,7 @@ signatures, operational and performance monitoring data, and so on. {{< image width="14em" float="right" src="/assets/vpp-srv6/magnets.jpg" alt="Insane Clown" >}} -Much like magnets, you might be wondering _SRv6 Routers: How do they work?_. There's really only +Much like magnets, you might be wondering _SRv6 Routers: How do they work?_. There are really only three relevant things: SR Policy (they determine how packets are steered into the SRv6 routing domain), SRv6 Source nodes (they handle the ingress part), and SRv6 Segment Endpoint Nodes (they handle both the intermediate routers that participate in SRv6, and also the egress part where the @@ -97,7 +97,7 @@ stop talking about MPLS now :) #### SRv6: Source Node An _SR Source Node_ originates an IPv6 packet with a Segment in the destination address, and it -optionally adds an SRH with a list of instructions on the network. The _SR Source Node_ is the +optionally adds an SRH with a list of instructions for the network. The _SR Source Node_ is the ingress point and enables SRv6 processing in the network, which is called _steering_. Instead of setting the destination address to the final destination, the source node will set it to the first Segment, which is the first router that needs to be visited. @@ -112,7 +112,7 @@ those routers are not actively participating in SRv6 and they don't need to know #### SRv6: Segment Endpoint Node The _Segment Endpoint Node_ is a router that is SRv6 capable. A packet may arrive with a locally -configured address in the IPv6 destination. The magic happens here - one of two things: +configured address in the IPv6 destination. The magic happens here - one of two things can occur: 1. The _Segment Routing Header_ is inspected. If _Segments Left_ is 0, then the next header (typically UDP, TCP, ICMP) is processed. Otherwise, the next segment is read from the _Segment @@ -262,9 +262,9 @@ And then I take a look at this IPv4 ICMP packet on the wire: The first packet is coming in on vlan 30 (`host0-0:enp16s0f0` to `vpp0-0:Gi10/0/2`). I then see it go out on vlan 20 (from `vpp0-0` to `vpp0-1`). I see it is an IPv6 packet from `2001:678:d78:200::` -(the encapsulation address I configured), and to `2001:678:d78:20f::3:1` (the _BSID_ steers towards -this Segment Router ID), and then I see the Ethernet inner payload with the ICMP echo packet. But -where's the _Segment Routing Header_?? +(the encapsulation address I configured), and to `2001:678:d78:20f::3:1` (the _BSID_ resolves to an +_SR Policy_ with a single segment: this address), and then I see the Ethernet inner payload with the +ICMP echo packet. But where's the _Segment Routing Header_?? It is here that I learn why the RFC says that SRH are optional. This packet has everything it needs to have using the destination address, `2001:678:d78:20f::3:1`, which is routed towards the loopback @@ -358,8 +358,9 @@ acting as a transit router (just normally using IPv6 FIB lookup to pass it along to 1, and sent it to the second segment, which is onwards to `vpp0-1`. 1. on vlan 21 yet again, because when `vpp0-1` got it, it decremented the SRH _Segments Left_ from 1 to 0, and sent it to the third and final segment, which is onwards to `vpp0-3`. -1. on vlan 22, because `vpp0-2` is a transit router, using its FIB to pass it along to `vpp0-3`, -which decapsulates it with End.DX2 and sends it as an L2 packet on Gi10/0/3. +1. on vlan 22, because `vpp0-2` is acting as a transit router here (the destination is now `vpp0-3`, +not its own localsid), using its FIB to pass it along to `vpp0-3`, which decapsulates it with End.DX2 +and sends it as an L2 packet on Gi10/0/3. 1. coming out of vlan 43 (between `vpp0-3:Gi10/0/3` and `host0-1`), where it is simply an IPv4 packet again. @@ -370,7 +371,7 @@ packets from the wire, and here's what it looks like: The screenshot shows the packet observed on step 4 above - it is coming from `vpp0-0`'s loopback address and destined to the End localsid on `vpp0-1`, and I can see that the SRH has the list of 3 Segments in -reversed order with the `Address[0]` is the last one, a _LocalSID_ on `vpp0-3` that is an End.DX2. I +reversed order, where `Address[0]` is the final destination: a _LocalSID_ on `vpp0-3` configured as End.DX2. I can also see that _Segments Left_ is set to 1. VPP has a few relevant dataplane nodes: