fix: add secondary IPs for enrichment #272
Conversation
|
@rbtr Hi Evan, Could you give me another approval for running the CI tests? Thanks! |
|
hey @FZhg it looks like your branch has conflicts, can you resolve them? Please update it against latest |
Thanks for your help! Problem solved. |
FZhg
force-pushed
the
fix/sencondary-ips-enrichment
branch
from
b5d2212
to
c882308
Compare
|
lgmt, thank you for your contribution |
# Description Please provide a brief description of the changes made in this pull request. ## Related Issue Fixes #224 ## Checklist - [x] I have read the [contributing documentation](https://retina.sh/docs/contributing). - [x] I signed and signed-off the commits (`git commit -S -s ...`). See [this documentation](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification) on signing commits. - [x] I have correctly attributed the author(s) of the code. - [x] I have tested the changes locally. - [x] I have followed the project's style guidelines. - [x] I have updated the documentation, if necessary. - [x] I have added tests, if applicable. ## Screenshots (if applicable) or Testing Completed  ## Additional Notes Both the previous implementation and this PR don't clear stale IP-endpoint bindings immediately from the ipToEpKey Map. E.g. When endpoint A changes from IP address "1.1.1.1" to "2.2.2.2", the stale binding between the IP address "1.1.1.1" and endpoint A is still in the ipToEpKey map until the IP address "1.1.1.1" gets reassigned to another pod. However, this shouldn't be a problem. The DNS is supposed to provide up-to-date IP addresses for the sender and receiver so that any flow event will always contain the latest IP addresses.
Description
Please provide a brief description of the changes made in this pull request.
Related Issue
Fixes #224
Checklist
git commit -S -s ...). See this documentation on signing commits.Screenshots (if applicable) or Testing Completed
Additional Notes
Both the previous implementation and this PR don't clear stale IP-endpoint bindings immediately from the ipToEpKey Map.
E.g. When endpoint A changes from IP address "1.1.1.1" to "2.2.2.2", the stale binding between the IP address "1.1.1.1" and endpoint A is still in the ipToEpKey map until the IP address "1.1.1.1" gets reassigned to another pod.
However, this shouldn't be a problem. The DNS is supposed to provide up-to-date IP addresses for the sender and receiver so that any flow event will always contain the latest IP addresses.