Seeing the Invisible: Capturing RDMA Traffic with ibdump

RDMA bypasses the kernel, so tcpdump captures nothing while the port counters swallow gigabytes. The NIC itself can mirror the port though, and from the host that owns the PF you can watch every byte your SR-IOV guests exchange.
ibdump banner

On this page

The traffic tcpdump cannot see

RDMA's whole value is that the kernel never touches the data path. That has an awkward consequence the first time something misbehaves: your favorite tools are blind. Here's the blindness measured, on my SR-IOV lab fabric, while an RDMA write test hammers the port:

Port counters climbing by 327 MB while tcpdump captures zero packets
The port counter swallows 327 MB. tcpdump, told to grab any 100 packets, never sees one. Both are telling the truth.

The hardware counters prove the traffic is real; tcpdump proves the kernel wasn't invited. Great for performance, terrible for troubleshooting. So how do you actually look at RDMA on the wire?

Sniff where the silicon is

Mellanox HCAs have a hardware port sniffer: the NIC itself mirrors everything crossing a physical port into a capture queue. The tool that drives it is ibdump, and the catch is a permission: arming the sniffer is a privileged operation on the physical function. Try it from inside one of my guests, whose function arrived via VFIO passthrough, and the firmware politely refuses. But my topology has a loophole that most SR-IOV setups share:

Diagram: four VFs passed to guests all ride the host-owned PF, where ibdump arms the port sniffer
Four guests, four virtual functions, one physical port that the host still owns. Whoever owns the PF owns the view.

The capture

Running ibdump on the host against that PF while two guests ping across the fabric:

ibdump capturing 44 packets on the host and tshark dissecting guest-to-guest ICMP
Guest-to-guest traffic, captured from a machine neither guest knows about, dissected down to the ICMP sequence numbers.

That's IPoIB-encapsulated ICMP between two VMs, complete with InfiniBand headers, LRH and BTH and all, readable in Wireshark's InfiniBand dissector. Two practical notes: open the pcap in Wireshark, not tcpdump, which misreads the link type; and the sniffer is a read-only mirror, so capturing doesn't perturb the traffic it watches.

What the capture proves

Beyond debugging, the capture is an audit tool. My compute nodes live in a partition that forbids them from talking to each other (the opensm post covers why). Their mutual silence in a port-level capture, while both chat happily with the storage node, is the strongest possible evidence that the isolation is real: not a firewall rule that might be bypassed, but an absence of packets at the only place they could exist.

There's a security lesson in the same observation. If you rent VFs to tenants, remember what PF ownership means: the infrastructure operator can watch every byte your virtual function sends. On my fabric that's a feature. In someone else's cloud, it's the trust model.

The nugget: you can't tcpdump traffic on a native InfiniBand fabric, and that's by design. But the physical port sees everything, and if you own the PF, so do you: ibdump -d <pf-device> -w capture.pcap, then Wireshark.

Subscribe to LevelUp I.T. newsletter and stay updated.

Don't miss anything. Get all the latest posts delivered straight to your inbox. It's free!
Great! Check your inbox and click the link to confirm your subscription.
Error! Please enter a valid email address!