add `--reply` flag
michi-covalent opened this issue · comments
because why not
What would --reply mean for different protocols?
What would --reply mean for different protocols?
yeah that's a really good question. from hubble client's perspective it's just filtering on is_reply field here https://github.com/cilium/cilium/blob/a48bce8448d0f4c01b35a98ac8fbd011f0df42e4/api/v1/flow/flow.proto#L84-L87 but i don't know how exactly the field is set for some protocols. let me write down what i know, and i'll let other folks chime in (maybe @gandro ?)
- TCP: is_reply = false for packets sent from client to server. is_reply = true for packets sent from server to client. i think there are some exceptions where hubble doesn't know the direction 💭
- UDP: is_reply = false for packets sent from client to server. is_reply = true for packets sent from server to client. i think there are some exceptions where hubble doesn't know the direction 💭
- ICMPv4: i don't know how is_reply field is set.
- ICMPv6: i don't know how is_reply field is set.
- SCTP: i don't know how is_reply field is set.
- DNS: dns request => is_reply = false. dns response => is_reply = true.
- HTTP: http request => is_reply = false. http response => is_reply = true.
- Kafka: i don't know for sure but given kafka protocol is client/server request/response kind of thing, i'm guessing request => is_reply = false. response => is_reply = true.
is_reply these days is a tri-state flag: It can be true/false/unknown.
For trace events, we determine the true or false value based on the connection tracking table. Not all trace points access the connection tracking table, so it's "unknown" for trace points such as "from-container" for example.
The condition in the datapath that declares something as a reply packet is here:
https://github.com/cilium/cilium/blob/f26c056dc279279ee80b417c16d315e593601e03/bpf/lib/conntrack.h#L570
The way it seems to work is that it flips the source and destination address/port pair and if it finds a connection in the the reverse direction, then it considers the current packet a reply packet. That means that a UDP "connection" is defined via the usual five-tuple logic.
As for supported protocols, the cases are listed here. It seems that ICMP and SCTP are supported, though ICMP only for echo/reply, and not for things like "destination unreachable"
https://github.com/cilium/cilium/blob/f26c056dc279279ee80b417c16d315e593601e03/bpf/lib/conntrack.h#L709
One question for the flag is: How do we treat unknown values as a filter flag? In particular, if the viper flag is only a boolean that can be set or not set, then one can probably only query for is_reply=true flows, but not is_reply=false flows (as an unset reply flag should return everything).
One question for the flag is: How do we treat unknown values as a filter flag?
hmm yeah so maybe the flag cannot be a boolean 💭
assign me
dropping this as there were some priority issues assigned to me at tetragon repo