openshift-ci-robot
commented
3 months ago @msherif1234: This pull request references NETOBSERV-1478 which is a valid jira issue.
Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.16.0" version, but no target version was set.
In response to [this](https://github.com/netobserv/netobserv-ebpf-agent/pull/307):
>## Description
>
>This PR allow provisioning global filter to limit what goes to eBPF table
>based on filter rule direction user has to provision ipCIDR based on this rule
>- Direction: Ingress , use srcIP CIDR
>- Direction: Egress, use dstIP CIDR
>
>The following shows example of provision this feature
>```shell
>
>sudo TARGET_HOST=127.0.0.1 TARGET_PORT=9999 ENABLE_FLOW_FILTER=true FLOW_FILTER_IP_CIDR="172.253.122.1/24" FLOW_FILTER_DIRECTION="ingress" FLOW_FILTER_PROTOCOL="tcp" FLOW_FILTER_SOURCE_PORT=80 LOG_LEVEL="trace" METRICS_ENABLE=true ./bin/netobserv-ebpf-agent
>```
>The above rule provision ingress filter rule so the source CIDR is `172.253.122.1/24` for protocol `TCP` with srcPort `80` which is the configuration to match my test with
>`curl google.com`
>
>I also enabled metrics because we counter to show flows been filtered
>
>### UT
>- run the above standalone agent command
>- from another xterm run `curl -4 google.com -v`
>- from another xterm check metrics and ebpf map content and logs
>```shell
>curl 127.0.0.1:9090/metrics | grep Filter
> % Total % Received % Xferd Average Speed Time Time Time Current
> Dload Upload Total Spent Left Speed
>100 8318 0 8318 0 0 3062k 0 --:--:-- --:--ebpf_agent_dropped_flows_total{reason="FlowFilterDropCounter",source="flow-fetcher"} 1076
>:-- --:--:-- 4061k
>
>udo bpftool map dump id 211
>[{
> "key": {
> "prefix_len": 24,
> "ip_data": [172,253,122,1,0,0,0,0,0,0,0,0,0,0,0,0
> ]
> },
> "value": {
> "protocol": 6,
> "dstPortStart": 0,
> "dstPortEnd": 0,
> "srcPortStart": 80,
> "srcPortEnd": 0,
> "icmpType": 0,
> "icmpCode": 0,
> "direction": "INGRESS",
> "ip": [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
> ]
> }
> }
>]
>
> irq/177-iwlwifi-1194 [010] ..s2. 6252.626434: bpf_trace_printk: ip_filter:
> irq/177-iwlwifi-1194 [010] ..s2. 6252.626438: bpf_trace_printk: 172
> irq/177-iwlwifi-1194 [010] ..s2. 6252.626438: bpf_trace_printk: 253
> irq/177-iwlwifi-1194 [010] ..s2. 6252.626438: bpf_trace_printk: 122
> irq/177-iwlwifi-1194 [010] ..s2. 6252.626438: bpf_trace_printk: 101
> irq/177-iwlwifi-1194 [010] ..s2. 6252.626438: bpf_trace_printk: 0
> irq/177-iwlwifi-1194 [010] ..s2. 6252.626439: bpf_trace_printk: 0
> irq/177-iwlwifi-1194 [010] ..s2. 6252.626439: bpf_trace_printk: 0
> irq/177-iwlwifi-1194 [010] ..s2. 6252.626439: bpf_trace_printk: 0
> irq/177-iwlwifi-1194 [010] ..s2. 6252.626439: bpf_trace_printk: 0
> irq/177-iwlwifi-1194 [010] ..s2. 6252.626439: bpf_trace_printk: 0
> irq/177-iwlwifi-1194 [010] ..s2. 6252.626440: bpf_trace_printk: 0
> irq/177-iwlwifi-1194 [010] ..s2. 6252.626440: bpf_trace_printk: 0
> irq/177-iwlwifi-1194 [010] ..s2. 6252.626440: bpf_trace_printk: 0
> irq/177-iwlwifi-1194 [010] ..s2. 6252.626440: bpf_trace_printk: 0
> irq/177-iwlwifi-1194 [010] ..s2. 6252.626440: bpf_trace_printk: 0
> irq/177-iwlwifi-1194 [010] ..s2. 6252.626440: bpf_trace_printk: 0
> irq/177-iwlwifi-1194 [010] ..s2. 6252.626441: bpf_trace_printk:
>
> irq/177-iwlwifi-1194 [010] ..s2. 6252.626441: bpf_trace_printk: rule found
>
> irq/177-iwlwifi-1194 [010] ..s2. 6252.626442: bpf_trace_printk: srcPortStart matched
>
> irq/177-iwlwifi-1194 [010] ..s2. 6252.626442: bpf_trace_printk: direction matched
>
> irq/177-iwlwifi-1194 [010] ..s2. 6252.626443: bpf_trace_printk: result: 2
>
>```
>## Dependencies
>
>
>n/a
>
>## Checklist
>
>If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that.
>
>* [ ] Will this change affect NetObserv / Network Observability operator? If not, you can ignore the rest of this checklist.
>* [ ] Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix _(in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes)._
>* [ ] Does this PR require product documentation?
> * [ ] If so, make sure the JIRA epic is labelled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs.
>* [ ] Does this PR require a product release notes entry?
> * [ ] If so, fill in "Release Note Text" in the JIRA.
>* [ ] Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc.
> * [ ] If so, make sure it is described in the JIRA ticket.
>* QE requirements (check 1 from the list):
> * [ ] Standard QE validation, with pre-merge tests unless stated otherwise.
> * [ ] Regression tests only (e.g. refactoring with no user-facing change).
> * [ ] No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team).
>
Instructions for interacting with me using PR comments are available [here](https://prow.ci.openshift.org/command-help?repo=netobserv%2Fnetobserv-ebpf-agent). If you have questions or suggestions related to my behavior, please file an issue against the [openshift-eng/jira-lifecycle-plugin](https://github.com/openshift-eng/jira-lifecycle-plugin/issues/new) repository.
codecov-commenter
msherif1234
github-actions[bot]
jotak
Amoghrd
openshift-ci[bot]
Description
This PR allow provisioning global filter to limit what goes to eBPF flows table this also fix #266
Dependencies
n/a
Checklist
If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that.