check-udp-conntrack

<!-- cspell:ignore Rcvbuf conntrack NoPorts --> # Check UDP Conntrack ## Overview Use this skill to investigate whether UDP instability is caused by kernel-side conntrack saturation or related packet-path pressure. The canonical human-facing reference is: - `docs/udp-conntrack-runbook.md` Keep durable explanations and operational guidance in that document. This skill should stay focused on workflow and safe execution. ## When To Use Use this skill when the user asks to: - check whether conntrack is too small - diagnose UDP timeouts or packet loss - validate that current conntrack tuning is still active - verify whether the server is dropping UDP packets - assess whether current symptoms point to conntrack saturation or something else ## Workflow 1. Run the host checks from `docs/udp-conntrack-runbook.md`. 2. Summarize the results in terms of: - conntrack occupancy - presence or absence of `table full` events - IPv4 and IPv6 UDP receive-buffer errors - whether `NoPorts` counters are relevant or benign 3. Distinguish conntrack saturation from softirq/RX steering imbalance. 4. If the user asks to document the result, update the relevant issue evidence or incident file and reference the runbook when appropriate. ## Interpretation Rules - `nf_conntrack_count` near or equal to `nf_conntrack_max` means real pressure. - Any fresh `nf_conntrack: table full, dropping packet` message is a confirmed problem. - `UdpRcvbufErrors` or `Udp6RcvbufErrors` increasing during the incident means packet loss below the application layer. - `NoPorts` counters alone do not prove tracker loss. - High load average with one CPU dominated by `%soft` points to softirq concentration, not necessarily conntrack exhaustion. ## Safety Constraints - Do not change sysctl values unless the user explicitly asks for a fix. - If applying a fix, update both runtime state and persistent files when appropriate. - Preserve issue-specific evidence in `docs/issues/evidence/ISSUE-<N>/`. - Do not present the skill as the primary source of truth; the runbook in `docs/` is the canonical explanation.