Grammar and readability improvements, h/t Claude
All checks were successful
continuous-integration/drone/push Build is passing

This commit is contained in:
2026-02-21 16:02:56 +00:00
parent 532ec4fcd7
commit 8ace5cf9ff

View File

@@ -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: