-
Notifications
You must be signed in to change notification settings - Fork 386
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
Set NO_FLOOD to IPsec tunnel ports #4419
Conversation
Codecov Report
@@ Coverage Diff @@
## main #4419 +/- ##
==========================================
+ Coverage 69.58% 69.67% +0.08%
==========================================
Files 400 400
Lines 59122 58369 -753
==========================================
- Hits 41141 40666 -475
+ Misses 15175 14914 -261
+ Partials 2806 2789 -17
*This pull request uses carry forward flags. Click here to find out more.
|
// Set the port with no-flood to reject ARP flood packets. | ||
if err := c.ovsCtlClient.SetPortNoFlood(int(ofPort)); err != nil { | ||
return 0, fmt.Errorf("failed to set port %s with no-flood config: %w", portName, err) | ||
} |
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.
Want to understand the issue: the normal tunnel port doesn't need setting it because "normal" action doesn't flood broadcast packets to flow based tunnel ports but will flood to ipsec tunnels because they are port based?
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.
Yes, the general tunnel port is flow based, and it needs flow to tell it how to encap the tunnel header on a packet. For ARP, we do not have a flow to explicitly set tht tunnel peer, that is why we do not see ARP packets are broadcast to all other Nodes. But for IPSec tunnel, one port is created per peer Node, so when ARP packet outputs ( via normal action) to the port, OVS datapath is able to send it to peer Node. Then the packet hits the "normal" flow on peer Node, and continue flooding.
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.
LGTM
@xliuxu I suppose this should be backported? |
/test-all |
I think so. I will backport this PR once merged. |
/test-e2e |
It failed on testIPSecTunnelConnectivity twice. Is it related to the change? |
/test-e2e |
I cannot reproduce the same error locally. I will trigger a new e2e test and check the results on the testbed if it still fails. |
Could you check the previous failures too? Even if the 3rd succeeds, we need to understand the failures as they are frequent. |
I cannot reproduce the error in the testbeds. I will trigger more e2e tests to check. |
/test-latest-e2e |
11025af
to
f51d79d
Compare
/test-e2e |
f51d79d
to
b6fdfce
Compare
/test-e2e |
2 similar comments
/test-e2e |
/test-e2e |
b6fdfce
to
5953341
Compare
/test-e2e |
4 similar comments
/test-e2e |
/test-e2e |
/test-e2e |
/test-e2e |
/test-e2e |
5953341
to
8c23549
Compare
/test-e2e |
/test-e2e |
1 similar comment
/test-e2e |
76bc543
to
82be664
Compare
/test-e2e |
82be664
to
f80665a
Compare
/test-e2e |
/test-e2e |
1 similar comment
/test-e2e |
Set NO_FLOOD to IPsec tunnel ports to avoid ARP flooding. Signed-off-by: Xu Liu <xliu2@vmware.com>
f80665a
to
ecf67b4
Compare
/test-e2e |
/test-all |
@tnqn The flaky e2e of this PR should be the same as #4477 but I did not find the root cause. I can tell that the configs of strongswan and the xfrm policies are configured correctly when the error occurred. I suspect this could be related to the underlying testbed and it is now not reoccurring. Do you think we can merge this PR? |
Got it. We could revisit it when it happens again. |
Set NO_FLOOD to IPsec tunnel ports to avoid ARP flooding.
Signed-off-by: Xu Liu xliu2@vmware.com