Fixing Ghost Drops: How eBPF Rescued IPv6 Telemetry
A customer complains that they aren't getting IPFIX flow data from a router.
Use socat to check that IPFIX is being received (IANA assigned port for IPFIX is 4739):
socat -b 0 -dd -u UDP6-RECV:4739 - 2>&1Output demonstrates that at least some IPFIX messages can be received when listening on port 4739.
2026/05/15 22:46:32 socat[108419] N using stdout for writing 2026/05/15 22:46:32 socat[108419] N starting data transfer loop with FDs [5,5] and [1,1] 2026/05/15 22:46:33 socat[108419] N received packet with 0 bytes from AF=10 [fec0:0000:0000:0000:0001:000c:2744:69f1]:50978 2026/05/15 22:46:33 socat[108419] N received packet with 0 bytes from AF=10 [fec0:0000:0000:0000:0001:000c:2744:69f1]:50978Use tcpdump to check for IPFIX packets. This gives visibility into packets before the host network stack, so you can see packets before they are dropped by host network stack or host firewall
tcpdump -i enp0s3 -n udp port 4739The output shows that IPFIX datagrams are being received from a second source, fec0::1:c:2744:69f0, but they aren't showing up in the socat output, so the Linux kernel must be dropping them for some reason.
dropped privs to tcpdump tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on enp0s3, link-type EN10MB (Ethernet), snapshot length 262144 bytes 21:09:57.217821 Continue reading


