There is a moment in almost every escalated incident when someone says "let's get a capture" - and then starts one wherever access happens to be easiest. Twenty minutes later there is a two-gigabyte file, a filter that turned out to be wrong, and no agreement on what the capture was supposed to prove. The problem was never the tooling. The problem is that the capture was collected before anyone decided what question it was answering. Capture planning is evidence design: where to observe, in what order, and - decided in advance - what seeing or not seeing something would establish.
Boundaries, not convenience
Packets change meaning at boundaries: a NAT rewrites addresses, a load balancer splits one conversation into two, a proxy originates a fresh session upstream, a VPN gateway wraps everything in ESP, a TLS terminator ends one cryptographic world and starts another. A capture point earns its place by sitting on one of these boundaries, because that is where a comparison localizes a fault. Two captures that straddle a firewall answer "did the firewall eat it?" in one look; a single capture taken somewhere convenient answers almost nothing, however large the file. When the path has a transformation in it, the plan should pair points across that transformation - and match flows by ports, sequence numbers, and timing, never by addresses that a NAT has already rewritten.
Absence is evidence too
The most underused observation in packet work is the packet that is not there. A SYN visible at the client and absent at the server-side capture bounds the loss to the path between them; retransmissions present upstream of a device and missing downstream indict the device; a request that never reaches the origin while the client holds an error names the intermediary that wrote it. None of these conclusions comes from reading payload - they come from comparing presence across two synchronized points. That word, synchronized, carries the discipline: for anything intermittent, clocks must agree and windows must overlap, or the comparison will manufacture a story instead of testing one.
Decide what it would mean - first
The step that separates a plan from a fishing trip is the interpretation matrix: for each candidate conclusion, write down in advance what observation would support it and what would weaken it. "If the handshake completes at the VIP but no member-side connection appears, the balancer or its pool is implicated; if the front side already shows no SYN-ACK, the problem is in front of it." Doing this before collection keeps the evidence honest - it prevents the capture from being read as confirmation of whatever theory was loudest when the file finally opened. It also keeps captures small: a point that cannot change any conclusion does not belong in phase one.
Minimal exposure is part of the plan
Captures on TLS and HTTP classes can hold credentials, tokens, and user content. A plan worth exporting says so: truncate to headers where the question allows it, cap the duration, control who can read the files, and redact before sharing. And every plan begins with the unglamorous line that makes the rest legitimate - confirm you are authorized to capture at each point, and agree what happens to the files afterward. Evidence collected without that line has a way of becoming the incident.