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
[Windows] Bugfix: SNAT is not performed on the +est packets. #2702
Conversation
|
/test-all |
|
/test-windows-all |
|
/test-windows-conformance |
| l3FwdTable := c.pipeline[l3ForwardingTable] | ||
| nextTable := l3FwdTable.GetNext() | ||
| snatTable := c.pipeline[snatTable] | ||
| nextTable := snatTable.GetNext() |
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.
@jianjuns @tnqn I am thinking shall we resubmit the packet to the l3DecTTLTable after SNAT on Windows? In current implementation (<= Antrea 1.2), we output the SNATed packet to the uplink interface, and we didn't decrement TTL because we define l2ForwardingCalcTable is the one next to snatTable. I think it is possibly because we output the packet to antrea-gw0 on Linux, and TTL is decremented on the Linux host.
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.
That makes sense to me.
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.
@wenyingd @jianjuns It looked to me that you are outputting SNATted packet to antrea-gw0 interface (as destination IP is in a different subnet) and not to the uplink interface directly on Windows too. Once it goes to antrea-gw0, it comes back to OVS pipeline via br-int (as that is the one that has the nodeIP). And then you o/p it via uplink interface (e.g Ethernet).
You probably meant the same thing. But, I wanted to make sure that I understand the converstion.
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.
If you are submitting it directly to uplink interface, how would you know the mac address of this out of k8s cluster IP?
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.
@shettyg Thanks for reminding me. You are correct, we actually output the packet th antrea-gw0 even if we perform SNAT inside OVS. The current code for TTL is correct, and please ignore my previous suggestion. I would add comments here for the next table so that we could avoid similar confusion in future.
build/yamls/antrea-windows.yml
Outdated
| @@ -95,7 +95,7 @@ data: | |||
| # supporting Pod traffic across IP subnets. | |||
| # hybrid: noEncap if source and destination Nodes are on the same subnet, otherwise encap. | |||
| # | |||
| #trafficEncapMode: encap | |||
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.
You will revert the change before merge?
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, this change is to trigger CI test only.
| l3FwdTable := c.pipeline[l3ForwardingTable] | ||
| nextTable := l3FwdTable.GetNext() | ||
| snatTable := c.pipeline[snatTable] | ||
| nextTable := snatTable.GetNext() |
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.
That makes sense to me.
450938f
to
eee3588
Compare
Codecov Report
@@ Coverage Diff @@
## release-1.2 #2702 +/- ##
===============================================
+ Coverage 60.19% 65.04% +4.85%
===============================================
Files 284 284
Lines 22385 25672 +3287
===============================================
+ Hits 13474 16699 +3225
+ Misses 7474 7413 -61
- Partials 1437 1560 +123
Flags with carried forward coverage won't be shown. Click here to find out more.
|
eee3588
to
549c6c9
Compare
|
/test-all |
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.
|
/test-all-features-conformance |
|
/test-e2e |
549c6c9
to
15f4b63
Compare
|
/test-all |
|
/test-ipv6-conformance |
|
/test-e2e |
|
/skip-e2e |
|
/test-windows-networkpolicy |
|
/skip-windows-networkpolicy |
| // Do not decrement TTL on the SNATed packet on Windows. This is because the SNATed packet is output to antrea-gw0 | ||
| // first to learn the destination MAC using the host ARP cache. And antrea-gw0 will decrement the TTL when it | ||
| // forwards the packet to the bridge interface on which the host IP address is configured. | ||
| nextTable := c.pipeline[l3DecTTLTable].GetNext() |
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.
The snatTable's default next table is l2ForwardingCalcTable, why we don't use its next table directly here but uses a non-related table's?
I think the meaning of default table is packets will go to it by default unless we explicitly change it for some reason. So I don't quite understand what's the indication here.
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.
I want to explicitly skip "l3DecTTLTable" for the reason I commented here.
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.
I understand the comment but what's the point of the default next table then? I think this would confuse readers that snatTable's next table is l3DecTTLTable so we explicitly skip it. Overriding nextTable only makes sense when we use a non-default value. If the normal path should go snatTable -> l3DecTTLTable, it would make sense to skip it like this. When the pipeline is designed as snatTable-> l2ForwardingCalcTable, doesn't it imply we only delTTL for particular traffic explicitly? I'm fine with the comment but want to avoid this confusing nextTable declaration.
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.
Sure, updated.
15f4b63
to
ad76105
Compare
Load the SNAT mark in snatTable on the established connection packets which is sent out from local Pods. Signed-off-by: wenyingd <wenyingd@vmware.com>
ad76105
to
930d41a
Compare
|
/test-all I have passed Windows conformance test, networkpolicy test, and windows-e2e-test in noEncap mode on my local setup. Since the change is only on Windows Node and IPv6 cluster is not impacted, I skip IPv6 related tests. |
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
|
/test-networkpolicy |
|
/test-all |
|
@wenyingd could you take care of back-porting to release-1.1? |
Yes, I would check if it is needed in release-1.1 |
Load the SNAT mark in snatTable on the established connection packets which is sent out from local Pods.
Fixes #2701
Signed-off-by: wenyingd wenyingd@vmware.com