Re: Metamako DLT Request

[David Mirabito <davidm () metamako com>]

Hi Guy,

Thanks for the comments, addressed inline:

> I have attached a more detailed description as a text file (lest email
> mangle the ASCII-art), but in short, a packet would look on the wire like:
> > * SOF
> > * Destination address
> > * Source Address
> > * EtherType/Length
> > * Payload
> > * FCS . <--- everything up to, and including, here is unmodified by
> MetaWatch. Typically our appending a trailer may allow this FCS to be
> captured by NICs which would otherwise have stripped it
>
> So an Ethernet frame passes through one of your K-series devices, and it
> takes the entire frame, appends a trailer, and sends it out for something
> else to capture, so that the original FCS is part of the new packet's
> payload, and is thus always present?


Correct. The typical use case is for Ethernet stream(s) to pass through the
box unmodified, and internally we can Tap & Aggregate with metadata
appended some/all of these. The "something else" might be our on-board
management platform, or (more commonly) the aggregate stream is fed out a
port to a dedicated capture/persist/analytics appliance, some of which
currently do interpret the trailer.


> > * Optional Extension TLVs
> > * Timestamp: Seconds
> > * Timestamp: Nanoseconds
> > * Flags (currently whether FCS was correct at ingress, and presence of
> any extension TLVs)
> > * Device ID (by default unique portion of the device's serial number)
> > * Port ID
> > * NewFCS (calculated so that metawatch emits a valid frame, not always
> captured by capturing NICs)
> > * EOF
> >
> > The intent when parsing is that the base trailer is always the last 12
> bytes so given a complete capture one may simply skip directly to "wlen -
> 12", so there is no need to interpret EtherLen, or do a full dissection to
> locate the trailer. I agree that the case where caplen < wirelen may be
> problematic, but then you're guaranteed a corrupted or missing trailer
> anyway so it might not be worth even trying.
>
> Well, if len - caplen < 12, you know that 12 - (len - caplen) bytes of the
> base trailer are present, so you can extract the parts that *are* present.
> If it's >= 12, none of the base trailer is there, so you don't know whether
> there are extensions, and you can't parse the extensions.


This is true, and a good idea. To be fair, my current prototype doesn't do
that, but will add such robustness to any submitted code implementing the
proposed DLT.

Thanks again,
David
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers