On Dec 29, 2018, at 4:50 AM, Dave Barach (dbarach) <dbar...@cisco.com> wrote:
> The same packet - with [traced] metadata changes - will appear multiple times > as the packet traverses the vpp forwarding graph. The description of the format should probably warn about that, because protocol analyzers that maintain state between packets might get confused if multiple instances of the same packet appear in a capture. > Simple example: from the driver layer, an ip4 transit packet will visit > ethernet-input, ip4-input[-no-checksum], ip4-lookup, ip4-rewrite, > interface-output, and the device driver TX node. Each of those visits results > in a trace record. The dispatch framework traces vectors of packets, so one > sees N x trace records from ethernet-input, the N x trace records from > ip4-input, and so on. Folks typically filter by buffer-index in wireshark, to > see what happens to one packet in a convenient sequential view. So an analyzer *could*, in theory, work around this by, for example, treating each node name(?) as a separate flow, with a copy of a packet that visited one node as not being related to packets that visited different nodes, so a dissector would treat all of the copies of the IPv4 transit packet listed above as separate packets rather than as, for example, retransmissions of the same packet, and so that a request at one layer isn't matched with all of the copies of a reply that show up. I suppose that you could also suppress all dissection past the IP or maybe transport layer, although if you see multiple instances of a TCP segment, the TCP dissector will interpret that as a retransmission unless it knows that they're just multiple appearances of the same packet. The problem here is that a VPP trace is significantly different from a regular network capture, in that it seems mainly tracing the flow of a packet through the packet processing code on a single machine rather than tracing its flow on a network; packet analyzers are more oriented towards the latter. You don't need to give details of *how* an analyzer should deal with this - different analyzers might choose to do so in different ways; just note that this is significantly different from the sort of network traces one might be used to. _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
