Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

epb: add three new epb options, packetid, queue and verdict #91

Merged
merged 4 commits into from Jun 3, 2020
Merged

epb: add three new epb options, packetid, queue and verdict #91

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
1d89b75
epb: add three new epb options, packetid, queue and verdict
chaudron Apr 9, 2020
294fa5f
epb: fixed some spelling errors and add verdict clarification
chaudron Apr 15, 2020
43fa650
epb: changes based on comments from guyharris
chaudron Apr 30, 2020
b5b2c08
epb: fix assigned ID to epb_queue
chaudron May 1, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
70 changes: 70 additions & 0 deletions draft-tuexen-opsawg-pcapng.xml
View file
Open in desktop
Expand Up @@ -77,6 +77,19 @@
</address>
</author>

<author initials='E.' surname='Chaudron' fullname='Eelco Chaudron'>
<organization abbrev='Red Hat'>Red Hat</organization>
<address>
<postal>
<street>De Entree 238</street>
<code>1101 EE</code>
<city>Amsterdam</city>
<country>NL</country>
</postal>
<email>eelco@redhat.com</email>
</address>
</author>

<author fullname="Michael C. Richardson" initials="M."
surname="Richardson">
<organization abbrev="Sandelman">Sandelman Software Works</organization>
Expand Down Expand Up @@ -1332,6 +1345,22 @@ Section Header
<c>4</c>
<c>8</c>
<c>no</c>

<c>epb_packetid</c>
<c>5</c>
<c>8</c>
<c>no</c>

<c>epb_queue</c>
<c>6</c>
<c>4</c>
<c>no</c>

<c>epb_verdict</c>
<c>7</c>
<c>variable, minimum verdict type-dependent</c>
<c>yes</c>

</texttable>

<t>
Expand Down Expand Up @@ -1371,6 +1400,47 @@ Section Header

<t>Example: '0'.</t>

<t hangText="epb_packetid:"><vspace blankLines="0"/>The
epb_packetid option is a 64-bit unsigned integer that uniquely
identifies the packet. If the same packet is seen by multiple
interfaces and there is a way for the capture application to
correlate them, the same epb_packetid value must be used. An
example could be a router that captures packets on all its
interfaces in both directions. When a packet hits interface A
on ingress, an EPB entry gets created, TTL gets decremented,
and right before it egresses on interface B another EPB entry
gets created in the trace file. In this case, two packets are
in the capture file, which are not identical but the
epb_packetid can be used to correlate them.</t>

<t>Example: '0'.</t>

<t hangText="epb_queue:"><vspace blankLines="0"/>The epb_queue
option is a 32-bit unsigned integer that identifies on which queue
of the interface the specific packet was received.</t>

<t>Example: '0'.</t>

<t hangText="epb_verdict:"><vspace blankLines="0"/>The epb_verdict
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does "verdict" mean? I assume it means firewall/ACL activity like "drop", "reject", "accept"? Not all readers might be familiar with the term, so it would be good to explain it just a bit :-)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added some additional explanation

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By the way, the Linux_eBPF_TC and Linux_eBPF_XDP verdict types appear to be integral values; if so, are they in the byte order of the host writing the file (so that a little-endian machine will write them as little-endian numbers and a big-endian machine will write them as big-endian numbers)?

And is the hardware verdict type an opaque blob of bytes?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(The byte order question also applies to the packet ID and queue options, with presumably the same answer.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Linux_eBPF_TC and Linux_eBPF_XDP are stored a uint64 and hence the same as all other metadata in the block, so in host order as explained in the "Endianness" section.

You are right about the hardware verdict type, this is an opaque blob of bytes.

Packet and queue ID are the same as any other option, for example, epb_dropcount, which are stored as explained in the "Endianness" section.

option stores a verdict of the packet. The verdict indicates what
would be done with the packet after processing it. For example, a
firewall could drop the packet. This verdict can be set by various
components, i.e. Hardware, Linux's eBPF TC or XDP framework, etc.
etc. The first octet specifies the verdict type, while the
following octets contain the actual verdict data, whose size
depends on the verdict type, and hence from the value in the first
octet. The verdict type can be: Hardware (type octet = 0, size =
variable), Linux_eBPF_TC (type octet = 1, size = 8 (64-bit unsigned
integer), value = TC_ACT_* as defined in the Linux
<eref target="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/pkt_cls.h">pck_cls.h</eref>
include), Linux_eBPF_XDP (type octet = 2, size = 8 (64-bit unsigned
integer), value = xdp_action as defined in the Linux
<eref target="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/bpf.h">pbf.h</eref>
include).</t>

<t>Example: '02 00 00 00 00 00 00 00 02' for Linux_eBPF_XDP with
verdict XDP_PASS.</t>

</list>
</t>

Expand Down