-
Notifications
You must be signed in to change notification settings - Fork 23
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
NETOBSERV-1275: Introduce new "INNER" direction for inner-node traffic #483
Conversation
|
Related PR: netobserv/flowlogs-pipeline#483 The flows (and duplicates) generated for inner-node traffic differs compared to node-to-node traffic, and reinterpret direction isn't able to decide between ingress or egress. This is causing discrepancies with the dedup mechanism that filters out flows where Duplicate=true and also favors ingress over egress, since the Duplicate flag can be set randomly on ingress or on egress. To fix that, the proposed solution is to create this new INNER direction specifically for this kind of traffic. Deduping this INNER traffic can then rely solely on the Duplicate flag, since that flag was set from a single Agent (single node) there will always be only one Duplicate=false.
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #483 +/- ##
=======================================
Coverage 66.03% 66.03%
=======================================
Files 94 94
Lines 6921 6921
=======================================
Hits 4570 4570
Misses 2092 2092
Partials 259 259
Flags with carried forward coverage won't be shown. Click here to find out more.
☔ View full report in Codecov by Sentry. 📢 Have feedback on the report? Share it here. |
New image: It will expire after two weeks. To deploy this build, run from the operator repo, assuming the operator is running: USER=netobserv VERSION=deb2e32 make set-flp-image |
@jotak: This pull request references NETOBSERV-1275 which is a valid jira issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, let's just wait for plugin PR before merge.
Edit: what about managing NETOBSERV-1109 in this PR at the same time ?
We would just need to revert a05a86d
Another case where reinterpret doesn't work as expected is when
|
In this example, AgentIP == DstK8S_HostIP so reinterpret says it's an Ingress (seems like this is a DNS response observed from the sender). Why is it incorrect? It seems an ingress indeed, despite not knowing the other end's host IP ? |
@jpinsonneau for conversation I can remove that |
New changes are detected. LGTM label has been removed. |
New image: It will expire after two weeks. To deploy this build, run from the operator repo, assuming the operator is running: USER=netobserv VERSION=6048977 make set-flp-image |
DNS Would you expect
Yes please 👍 No changes on query side as far as I seen. |
Related PR: netobserv/flowlogs-pipeline#483 The flows (and duplicates) generated for inner-node traffic differs compared to node-to-node traffic, and reinterpret direction isn't able to decide between ingress or egress. This is causing discrepancies with the dedup mechanism that filters out flows where Duplicate=true and also favors ingress over egress, since the Duplicate flag can be set randomly on ingress or on egress. To fix that, the proposed solution is to create this new INNER direction specifically for this kind of traffic. Deduping this INNER traffic can then rely solely on the Duplicate flag, since that flag was set from a single Agent (single node) there will always be only one Duplicate=false.
Well this is how it has always worked with netflows, so yes, for the response, Src must be the DNS server, and Dst must be the querier Edit: but it seems to be already the case, no? |
Yes my bad, I retested and see 1 egress (Pod -> Service) and 2 ingress (Service -> Pod) with one duplicate. |
Services aren't really running on nodes, I'm not sure we could consider them as "Inner traffic" ... |
The flows (and duplicates) generated for inner-node traffic differs compared to node-to-node traffic, and reinterpret direction isn't able to decide between ingress or egress. This is causing discrepancies with the dedup mechanism that filters out flows where Duplicate=true and also favors ingress over egress. To fix that, the proposed solution is to create this new INNER direction specifically for this kind of traffic. Deduping this INNER traffic can then rely solely on the Duplicate flag, since that flag was set from a single Agent (single node) there will always be only one Duplicate=false.
Regarding my last comment: DNS duplicates are currently being considered via this ticket and dealt with from the Agent |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jotak The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
#378) * Introduce new "INNER" direction for inner-node traffic Related PR: netobserv/flowlogs-pipeline#483 The flows (and duplicates) generated for inner-node traffic differs compared to node-to-node traffic, and reinterpret direction isn't able to decide between ingress or egress. This is causing discrepancies with the dedup mechanism that filters out flows where Duplicate=true and also favors ingress over egress, since the Duplicate flag can be set randomly on ingress or on egress. To fix that, the proposed solution is to create this new INNER direction specifically for this kind of traffic. Deduping this INNER traffic can then rely solely on the Duplicate flag, since that flag was set from a single Agent (single node) there will always be only one Duplicate=false. * fix fmt * Fix test * Update texts & API for doc * fix linter
Related PR: netobserv/network-observability-console-plugin#378
The flows (and duplicates) generated for inner-node traffic differs compared to node-to-node traffic, and reinterpret direction isn't able to decide between ingress or egress. This is causing discrepancies with the dedup mechanism that filters out flows where Duplicate=true and also favors ingress over egress, since the Duplicate flag can be set randomly on ingress or on egress.
To fix that, the proposed solution is to create this new INNER direction specifically for this kind of traffic. Deduping this INNER traffic can then rely solely on the Duplicate flag, since that flag was set from a single Agent (single node) there will always be only one Duplicate=false.