Typo fixes, h/t Claude

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 magnents, 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's 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
@@ -115,7 +115,7 @@ The _Segment Endpoint Node_ is a router that is SRv6 capable. A packet may arriv
 configured address in the IPv6 destination. The magic happens here - one of two things:
 
 1.   The _Segment Routing Header_ is inspected. If _Segments Left_ is 0, then the next header
-(typically UDP, TCP, ICMP) is processed. Otherwisem the next segment is read from the _Segment
+(typically UDP, TCP, ICMP) is processed. Otherwise, the next segment is read from the _Segment
 List_, and the IPv6 destination address is overwritten with it. The _Segments Left_ field is
 decremented. In this case the packet is routed normally through a bunch of potential transit
 routers, who are blissfully ignorant of what is happening, and onto a next _Segment Endpoint_
@@ -296,9 +296,9 @@ vpp0-0# sr policy add bsid 8298::2:2 next 2001:678:d78:20F::2:ffff next 2001:678
         next 2001:678:d78:20f::3:1 encap
 ```
 
-Now each router knows that if an IPv6 packet is destined to it's `:ffff` address, that it needs to
+Now each router knows that if an IPv6 packet is destined to its `:ffff` address, that it needs to
 "End" the segment by inspecting the SRH. And the _SR Policy_ for `vpp0-0` is to send it first to
-`::2:ffff`, which is `vpp0-2`, which has now inspects the SRH and advances the _Segment List_.
+`::2:ffff`, which is `vpp0-2`, which now inspects the SRH and advances the _Segment List_.
 
 
 The proof is in the tcpdump pudding, and it makes me smile to see the icmp-echo packet bounce back
@@ -476,7 +476,7 @@ this bug and SRv6 encap starts to work flawlessly.
 I decide to add four tests: for {PHY, SUB} x {Encap, Decap}. On the encap side, I create a _SR
 Policy_ with BSID `a3::9999:1` which encapsulates from source `a3::` and sends to _Segment List_
 [`a4::`, `a5::`, `a6::c7`]. I then _steer_ L2 traffic from interface `pg0` using this _BSID_. I'll
-generate a packet and want to receive it ffom `pg1` encapsulated with the correct SRH and
+generate a packet and want to receive it from `pg1` encapsulated with the correct SRH and
 destination address. On the decap side, I create an SRv6 packet and send it into `pg1`, and want to
 see it decapsulated and exit on interface `pg0`.