Skip to content

PATTERN Cited by 1 source

iptables packet counter for rate metric

Use systems/iptables's built-in per-rule packet and byte counters as a lightweight, kernel-side rate-metric primitive. Add a rule matching traffic of interest, jump it to an empty user-defined chain to isolate the counter, and poll the counter from a shell loop reporting to your metrics pipeline.

Mechanism

  1. Create a new chain for isolation: 
    iptables -N VPC_RESOLVER
  2. Add a jump rule on the OUTPUT chain matching the target (e.g. packets destined for the AWS VPC resolver): 
    iptables -A OUTPUT -d 10.0.0.2 -j VPC_RESOLVER
  3. Add an empty catch-all rule inside the user-defined chain so the counter tallies every matched packet without side effects: 
    iptables -A VPC_RESOLVER
  4. Poll the counter once per second: 
    while :; do
  PACKET_COUNT=$(iptables -L VPC_RESOLVER 1 -x -n -v | awk '{ print $1 }')
  report-metric $PACKET_COUNT "vpc_resolver.packet_count"
  sleep 1
done

The metric pipeline calculates rates by differencing successive samples.

When this beats alternatives

  • vs tcpdump: tcpdump captures every packet, which is expensive at high rate and requires parsing pcap files. iptables counters are free (already incremented by the kernel) and integer-valued.
  • vs eBPF: eBPF is more flexible but requires more recent kernels and a deploy-an-agent discipline. iptables is in every modern Linux distribution out of the box.
  • vs application metrics: application-level DNS metrics count logical queries, not outbound packets. When retries at multiple layers amplify logical queries into many outbound packets (the canonical DNS retry amplification shape), only the packet-level metric reveals the true outbound rate.

Limitations

  • No per-flow or per-source breakdown without adding more rules. Each rule's counter is scalar.
  • Counter overflow. On 32-bit counters at very high rates, overflow matters; modern kernels use 64-bit counters but some userspace scripts truncate.
  • Lost on iptables reload / restart unless using iptables-save / iptables-restore with counter preservation, or netfilter persistent rules.
  • Ordering matters. A rule placed after a terminating rule (ACCEPT, DROP) won't see the traffic.

Seen in

  • Stripe — The secret life of DNS packets (2024-12-12). Canonical wiki instance. Stripe added the jump-to-empty-chain rule on every DNS server host, ran a 1-second shell loop to report packets-per-second to Datadog, and used the new metric to confirm the correlation between SERVFAIL spikes and outbound packet rate to the VPC resolver exceeding the 1,024-pps cap.
Last updated · 470 distilled / 1,213 read