Re: Request for a new LINKTYPE_/DLT_ type.

[Guy Harris <gharris () sonic net>]

On Dec 29, 2018, at 4:50 AM, Dave Barach (dbarach) <dbarach () 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