Tagged: proving-the-path
6 posts · browse all tags
-
Proving the Path Part 1: The Chain, and the Fault We're Chasing
A companion series to Day in the Life of a Packet, framed around diagnosis rather than architecture: one Teams call that stayed choppy long after the dashboards said everything had recovered, and the nine-stage chain I used to prove where the packet actually was.
-
Proving the Path Part 2: Ingress and Session
Before touching SD-WAN or routing, the session table tells you whether the flow you're chasing predates the event you're investigating. For the choppy Teams call, that one field settles more than the dashboard did.
-
Proving the Path Part 3: Policy Route and Routing
The pinned session predates the fault. Before blaming SD-WAN or routing for what's happening now, I need to know what a brand-new flow to the same destination would actually do today, and that's a different question from what the config says on paper.
-
Proving the Path Part 4: SD-WAN Member, SLA, and Rule Selection
The health-check history shows a breach, a failover, and a recovery, all working exactly as designed. Which raises the real question: if SD-WAN did its job correctly, why did the call stay broken?
-
Proving the Path Part 5: Policy/NAT and IPsec
The tunnel the pinned session is using never went down. The policy it matched hasn't changed. Both of those facts are true, and neither of them means the session's path was healthy the whole time it mattered.
-
Proving the Path Part 6: Egress, NPU Offload, and the Verdict
Every stage checked out clean on its own terms. The fix isn't clearing everything and hoping, it's one targeted action once the evidence points at a single cause. Closing the series with the full false-conclusions list and the discipline behind it.