Proving the Path Part 2: Ingress and Session

Part 1 set up the fault: a Teams call from SPOKE-14 went choppy during a brief SD-WAN SLA breach on the HUB-1 path, and stayed choppy after the dashboard showed recovery. Stage 1 of the chain is ingress, stage 2 is the session table, and both come before I let myself look at SD-WAN, routing or policy, because if the answer’s sitting in either of the first two stages, everything downstream is a distraction.

Ingress first, briefly

Ingress just answers whether the frame arrived where I expect. On SPOKE-14 that’s interface and VLAN counters on the WAN port, and they were clean throughout the incident window: no errors, no drops, no VLAN state flap. That rules ingress out quickly, which is normal; ingress is rarely the interesting stage unless there’s a physical or driver-level problem, and this isn’t one.

The session table doesn’t lie about the past

Teams media rides UDP, so I filter narrowly on the destination port range and the branch subnet rather than pulling the whole table:

diagnose sys session filter dport 3478
diagnose sys session filter src 10.30.10.55
diagnose sys session list

One entry matches, and the fields that matter are these:

session info: proto=17 proto_state=01 duration=187 expire=14 timeout=3600
  ... hook=post dir=org act=snat 10.30.10.55:50142->52.x.x.x:3478(203.0.113.5:50142)
  ... npu_state=0x4000
  ... policy_id=44

hook=post dir=org act=snat says this session’s NAT decision is already made: it’s mid-flow, source-NAT applied, nothing pending. policy_id=44 is the firewall policy it matched at creation, which I’ll come back to in Part 5. npu_state=0x4000 says it’s already NPU-offloaded, which matters a lot in Part 6 for a different reason.

The field that actually answers the question for this part is duration=187. That’s just over three minutes, which puts session creation before the health-check breach, the failover event, and the recovery all happened. This session is not new. Whatever decision it made about SD-WAN member, policy, NAT and egress interface, it made before any of tonight’s SLA drama. That’s the point of the whole series: it hasn’t been asked to reconsider that decision since.

What the session table doesn’t show you directly

The session entry doesn’t print the SD-WAN member name against the flow the way a service-rule log does. What it gives you instead is the egress interface implicit in the NAT translation and hook direction, which is enough to correlate against diagnose sys sdwan service in Part 4 once I know what the rule is choosing today. For now the useful fact is narrower and more solid: this specific session predates the incident. Whatever it’s doing, it’s been doing since before HUB-1 degraded.

False conclusion checkpoint: the sniffer shows nothing, so nothing’s wrong

This is a good point to flag one of the traps that shows up again in Part 6. npu_state=0x4000 here means this flow has already been handed to the NPU for fast-path forwarding. A CPU-level packet capture on the egress interface (diagnose sniffer packet) can show little or nothing for an offloaded flow past its first handful of packets, because the ASIC is doing the work without punting each packet back to the CPU for inspection. If someone ran a quick sniffer check during the incident and saw nothing alarming, that’s consistent with the flow being both fine and badly degraded: the sniffer’s silence proves offload, not health. I’ll come back to the right way to get visibility into an offloaded flow’s actual behaviour in Part 6.

Where this leaves us

The pinned session’s duration proves it predates the SLA event, which means whatever SD-WAN, policy, NAT and egress decision it holds was made before the failure and hasn’t changed since, regardless of anything that’s happened to the SD-WAN service rule in the meantime. That’s a claim worth testing against reality rather than accepting outright, so Part 3 checks what a brand-new flow to the same destination would do right now, which gives me something concrete to compare the pinned session against.