Reading a BIG-IP Capture: The F5 Trailer in Wireshark

A capture taken with the TMM detail suffix carries extra bytes after each packet. On its own that looks like noise. With the f5ethtrailer dissector, Wireshark turns it into readable fields that tell you exactly how BIG-IP handled each flow.

Capturing the packets is half the job; reading them is the other half. A BIG-IP capture taken with a detail suffix (:n, :nn, or :nnn) contains the standard frames plus an F5 trailer on each one. This article is about turning that trailer into answers. You build the capture itself with the BIG-IP tcpdump builder.

Open it in Wireshark

Write the capture to a file with -w and transfer it off the box, then open it in Wireshark. Modern Wireshark ships with the f5ethtrailer dissector, which recognises the trailer's magic marker and decodes it automatically. If you do not see the F5 fields, confirm the dissector is enabled in the protocol preferences.

What the trailer tells you

Depending on the detail level you captured with, the decoded trailer can show:

Direction: whether BIG-IP saw the packet ingress or egress.
Slot and TMM: which blade and which TMM instance processed it, which matters on multi-TMM and chassis platforms.
Virtual server: the name of the virtual that owns the flow (at medium and high detail).
Flow and peer-flow IDs: the internal identifiers that let you tie the client-side and server-side halves of a connection together.
Reset cause: at high detail, the reason BIG-IP reset a connection, which is often the single most useful field when a connection dies unexpectedly.

Tying the two flows together

This is where peer flows pay off. If you captured with the p modifier, both halves of the connection are in the file. Using the flow and peer-flow identifiers from the trailer, you can follow a request from the client, through the BIG-IP, to the chosen pool member, and back, even though the addresses change at the proxy boundary. The detail levels and peer flows article explains how those halves relate.

Filtering inside Wireshark

Once open, ordinary Wireshark display filters apply: filter by ip.addr, tcp.port, tcp.flags.reset, and so on. The F5 trailer adds its own filterable fields under the f5ethtrailer namespace, so you can, for example, isolate every packet a specific TMM handled, or every flow that ended in a reset. Combining a tight capture filter on the box with a focused display filter in Wireshark is how you go from a large file to the three packets that explain the problem.

A note on the keylog

The F5 trailer mechanism is diagnostic metadata only. Reading it does not expose TLS session secrets; decrypting application payload is a separate, deliberate step that requires its own key material. The trailer alone tells you how BIG-IP routed and handled a flow, not what was inside an encrypted payload.

The same conversation appears twice, and that is correct

A BIG-IP is a full proxy. A capture on the box therefore shows two separate TCP connections for one client transaction: client to virtual server, and BIG-IP to pool member. Different ports, different sequence numbers, often different IP addresses.

Read without that in mind it looks like duplication, a routing loop, or a retransmission storm. It is none of those. It is the proxy doing its job, and the two halves are only related through the device in the middle.

The F5 trailer is what puts them back together: the peer flow identifier lets you pivot from one side to the other. Without it you are reading two conversations and guessing they are the same one.