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.

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

Support outputting and filtering by vxlan/geneve tunnel data #494

Merged
merged 2 commits into from
Mar 27, 2025

Conversation

tommyp1ckles
Copy link
Contributor

@tommyp1ckles tommyp1ckles commented Jan 28, 2025

If the flag is enabled, packets that appear to be vxlan encapsulated will have the filtering function applied. Note: Therefore, to avoid getting non-vxlan traffic you will want to apply a general pcap filter on the vxlan udp ports.

As well, the flag --output-tunnel will result in output of vxlan header data (i.e. flag/vin) as well as inner address tuple.

Example Output

sudo ./pwru --output-tuple  --filter-func=udp_queue_rcv_skb  'port 8472' --output-tunnel --filter-tunnel-pcap-l3 'port 8080'  --output-tcp-flags
2025/01/27 16:35:45 Attaching kprobes (via kprobe)...
1 / 1 [-----------------------------------------------------------------------------------------------------------------------------------------------------------] 100.00% ? p/s
2025/01/27 16:35:45 Attached (ignored 0)
2025/01/27 16:35:45 Listening for events..
SKB                CPU PROCESS          NETNS      MARK/x        IFACE       PROTO  MTU   LEN   TUPLE FUNC TUNNEL
0xffff0000ea5d7ce8 7   <empty>:2287425  4026532458 0            eth0:353     0x0800 65536 90    172.18.0.5:54806->172.18.0.2:8472(udp) udp_queue_rcv_skb 52:2e:36:8d:11:23 -> ba:44:d8:6c:66:5a 10.244.1.205:36739->10.244.3.122:8080(tcp:SYN)
0xffff00011e41e900 7   <empty>:2287425  4026532646 0            eth0:359     0x0800 65536 90    172.18.0.2:53786->172.18.0.5:8472(udp) udp_queue_rcv_skb 92:53:8f:3a:e7:ef -> 7e:16:77:14:df:0d 10.244.3.122:8080->10.244.1.205:36739(tcp:SYN|ACK)
0xffff00011e41ef00 7   <empty>:2287425  4026532458 0            eth0:353     0x0800 65536 82    172.18.0.5:54806->172.18.0.2:8472(udp) udp_queue_rcv_skb 52:2e:36:8d:11:23 -> ba:44:d8:6c:66:5a 10.244.1.205:36739->10.244.3.122:8080(tcp:ACK)
0xffff0000ea5d7ce8 7   <empty>:2287425  4026532458 0            eth0:353     0x0800 65536 82    172.18.0.5:54806->172.18.0.2:8472(udp) udp_queue_rcv_skb 52:2e:36:8d:11:23 -> ba:44:d8:6c:66:5a 10.244.1.205:36739->10.244.3.122:8080(tcp:FIN|ACK)
0xffff0000e9b75ce8 6   node:2108761     4026532646 0            eth0:359     0x0800 65536 82    172.18.0.2:53786->172.18.0.5:8472(udp) udp_queue_rcv_skb 92:53:8f:3a:e7:ef -> 7e:16:77:14:df:0d 10.244.3.122:8080->10.244.1.205:36739(tcp:FIN|ACK)

Follow up work

  • Add support for Geneve
  • Add support for ip encap ip

@tommyp1ckles tommyp1ckles changed the title Add tunnel l2 pcap flag for optiona vxlan pcap. Add tunnel l2 pcap flag for optiona vxlan filtering Jan 28, 2025
@tommyp1ckles tommyp1ckles changed the title Add tunnel l2 pcap flag for optiona vxlan filtering Support outputting and filtering by vxlan tunnel data Jan 28, 2025
@tommyp1ckles tommyp1ckles force-pushed the pr/tp/tunnel-l2-pcap branch 3 times, most recently from e757528 to 698e31d Compare February 14, 2025 17:54
@tommyp1ckles tommyp1ckles changed the title Support outputting and filtering by vxlan tunnel data Support outputting and filtering by vxlan/geneve tunnel data Feb 14, 2025
@tommyp1ckles tommyp1ckles marked this pull request as ready for review February 14, 2025 23:47
@tommyp1ckles tommyp1ckles requested a review from a team as a code owner February 14, 2025 23:47
@tommyp1ckles tommyp1ckles requested review from smagnani96 and removed request for a team February 14, 2025 23:47
Copy link

@smagnani96 smagnani96 left a comment

Choose a reason for hiding this comment

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

Great contrib, I really like to filter by vxlan/geneve.
I mostly left nits and questions for my understanding, but the PR LGTM.

I'm almost sure the IPv4/IPv6-related questions are because we don't support the ip6 filter in pwru. In that case, its support is out-of-scope for this PR as it is a more general concern. But I might be wrong, so please let met know 🙏

@tommyp1ckles tommyp1ckles force-pushed the pr/tp/tunnel-l2-pcap branch 2 times, most recently from 6628f53 to 6363aaf Compare March 19, 2025 19:38
@tommyp1ckles tommyp1ckles requested a review from smagnani96 March 19, 2025 19:39
Copy link

@smagnani96 smagnani96 left a comment

Choose a reason for hiding this comment

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

Thanks! Looks all good except one last bit concerning the l4_off computation in case of an IPv6 packet.

I've also added some non-blocking comments for potential improvements by using skb->inner_X and skb->encapsulation bit.

@tommyp1ckles tommyp1ckles force-pushed the pr/tp/tunnel-l2-pcap branch 6 times, most recently from 7e52831 to 6c2ff6e Compare March 22, 2025 04:25
@tommyp1ckles tommyp1ckles requested a review from smagnani96 March 22, 2025 04:25
Copy link

@smagnani96 smagnani96 left a comment

Choose a reason for hiding this comment

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

Tom, many thanks for the PR!
I very much like the way it is, BPF changes are clean and very readable.
(CI broken?)

I'm leaving this pointer (cilium/cilium#38374) just for future reference: skb->inner_X seems to work even when skb->encapsulation is erroneously not set. If this will not be true anymore in future, we'll have to manually check UDP ports.

@tommyp1ckles
Copy link
Contributor Author

tommyp1ckles commented Mar 26, 2025

@smagnani96 Created a PR to fix CI here: #511 Merged, will rerun CI following rebase.

@tommyp1ckles tommyp1ckles force-pushed the pr/tp/tunnel-l2-pcap branch 2 times, most recently from b704a7e to 8b6a01c Compare March 26, 2025 22:30
If the flag is enabled, packets that appear to be vxlan
encapsulated will have the filtering function applied.
Note: Therefore, to avoid getting non-vxlan traffic you
will want to apply a general pcap filter on the vxlan udp
ports.

Signed-off-by: Tom Hadlaw <[email protected]>
Trying to use a l2 based expression such as
'host ether xx-xx-xx-xx-xx-xx' results in a error
as it is not a valid l3 expression (thus compilation fails)
however, in order to be able to have both l2&l3 expressions
we need to seperate out the flags and pass them seperately.

Signed-off-by: Tom Hadlaw <[email protected]>
@tommyp1ckles tommyp1ckles force-pushed the pr/tp/tunnel-l2-pcap branch from 8b6a01c to 1d9a4d0 Compare March 27, 2025 04:21
@smagnani96 smagnani96 merged commit 07a071d into cilium:main Mar 27, 2025
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants