Skip to content
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

Enable IP forwarding on the Windows bridge local interface #3137

Merged
merged 1 commit into from Feb 25, 2022

Conversation

hongliangl
Copy link
Contributor

@hongliangl hongliangl commented Dec 14, 2021

Traffic from the uplink interface will be output to the bridge local
interface directly. When an external client connects to a LoadBalancer
type Service, and the packets of the connection are routed to the
selected backend Pod via the bridge interface, if we do not enable IP
forwarding on the bridge interface, the connection will be discarded
on the bridge interface as the destination of the connection is not the
Node.

Signed-off-by: Hongliang Liu lhongliang@vmware.com

@codecov-commenter
Copy link

codecov-commenter commented Dec 14, 2021

Codecov Report

Merging #3137 (3f43b54) into main (a5114e7) will increase coverage by 19.63%.
The diff coverage is n/a.

Impacted file tree graph

@@             Coverage Diff             @@
##             main    #3137       +/-   ##
===========================================
+ Coverage   40.35%   59.98%   +19.63%     
===========================================
  Files         167      302      +135     
  Lines       20879    37135    +16256     
===========================================
+ Hits         8426    22276    +13850     
- Misses      11632    12994     +1362     
- Partials      821     1865     +1044     
Flag Coverage Δ
e2e-tests 50.69% <ø> (?)
kind-e2e-tests 47.72% <ø> (?)
unit-tests 40.38% <ø> (+0.02%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
pkg/agent/cniserver/ipam/antrea_ipam_controller.go 12.97% <0.00%> (-52.41%) ⬇️
pkg/ipam/poolallocator/allocator.go 21.28% <0.00%> (-41.14%) ⬇️
pkg/agent/cniserver/ipam/antrea_ipam.go 42.16% <0.00%> (-34.31%) ⬇️
pkg/ipam/ipallocator/allocator.go 54.22% <0.00%> (-29.99%) ⬇️
pkg/controller/networkpolicy/endpoint_querier.go 61.46% <0.00%> (-29.97%) ⬇️
pkg/controller/egress/controller.go 61.11% <0.00%> (-27.34%) ⬇️
pkg/controller/ipam/validate.go 57.14% <0.00%> (-22.86%) ⬇️
pkg/agent/util/iptables/lock.go 60.00% <0.00%> (-21.82%) ⬇️
pkg/controller/externalippool/validate.go 55.17% <0.00%> (-21.02%) ⬇️
pkg/controller/egress/validate.go 47.54% <0.00%> (-16.91%) ⬇️
... and 286 more

@@ -188,6 +188,13 @@ func (i *Initializer) prepareOVSBridge() error {
err = nil
klog.V(4).Infof("Address: %s already exists when configuring IP on interface %s", uplinkNetConfig.IP.String(), brName)
}
// Enable bridge local interface forwarding. Since now all traffic from uplink interface is output to bridge local interface
// directly instead of being resubmitted to UplinkTable, for connection of Service LoadBalancer, when the client is from
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sentence is too long to read.

How about:
Traffic from the uplink interface will be output to the bridge local interface directly. If we do not enable IP forwarding on the bridge interface, when an external client connects to a LoadBalancer type Service and the selected backend Pod is on a remote Node, the connection will be discarded on the bridge local interface.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, much better. I changed a little according your version

// Enable IP forwarding on the bridge local interface. Traffic from the uplink interface will be output to the bridge
// local interface directly. When an external client connects to a LoadBalancer type Service, and the packets of the
// connection is routed to the selected backend Pod via the bridge interface, if we do not enable IP forwarding on
// the bridge interface, the connection will be discarded on the bridge interface as the source of the connection
// is not the Node.

pkg/agent/agent_windows.go Outdated Show resolved Hide resolved
@hongliangl hongliangl force-pushed the windows-br-int-enable-forwarding branch from abe4c5b to 69c4e47 Compare December 15, 2021 01:49
@hongliangl hongliangl changed the title Enable Windows bridge local interface forwarding Enable Windows bridge local interface IP forwarding Dec 15, 2021
@hongliangl hongliangl changed the title Enable Windows bridge local interface IP forwarding Enable IP forwarding on the Windows bridge local interface. Dec 15, 2021
@hongliangl hongliangl force-pushed the windows-br-int-enable-forwarding branch from 69c4e47 to 1f4b9d0 Compare December 15, 2021 01:50
Copy link
Contributor

@jianjuns jianjuns left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@@ -188,6 +188,14 @@ func (i *Initializer) prepareOVSBridge() error {
err = nil
klog.V(4).Infof("Address: %s already exists when configuring IP on interface %s", uplinkNetConfig.IP.String(), brName)
}
// Enable IP forwarding on the bridge local interface. Traffic from the uplink interface will be output to the bridge
// local interface directly. When an external client connects to a LoadBalancer type Service, and the packets of the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest to break it to two sentences:

When an external client connects to a LoadBalancer type Service, the packets of the connection are routed to the selected backend Pond via the bridge interface; if we do not enable...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, done.

@hongliangl hongliangl force-pushed the windows-br-int-enable-forwarding branch from 1f4b9d0 to ee59bc9 Compare December 15, 2021 01:57
@hongliangl hongliangl changed the title Enable IP forwarding on the Windows bridge local interface. Enable IP forwarding on the Windows bridge local interface Dec 15, 2021
// Enable IP forwarding on the bridge local interface. Traffic from the uplink interface will be output to the bridge
// local interface directly. When an external client connects to a LoadBalancer type Service, and the packets of the
// connection are routed to the selected backend Pod via the bridge interface; if we do not enable IP forwarding on
// the bridge interface, the connection will be discarded on the bridge interface as the source of the connection is
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the connection will be discarded on the bridge interface as the destination of the connection is not the Node/

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right. The reason is that the destination of the connection is not the Node, if IP forwarding is not enabled, the connection will be discarded.

@hongliangl hongliangl force-pushed the windows-br-int-enable-forwarding branch from ee59bc9 to 53fbae7 Compare December 15, 2021 03:44
Copy link
Member

@tnqn tnqn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have few questions:

  1. Is this related to AntreaProxy's enablement?
  2. Does NodePort traffic work without the change?
  3. If we don't have tests to detect the issue, could we add one?

pkg/agent/agent_windows.go Outdated Show resolved Hide resolved
@hongliangl
Copy link
Contributor Author

hongliangl commented Dec 17, 2021

@tnqn

1 .Is this related to AntreaProxy's enablement?

Yes, if IP forwarding is not enabled, the br-int interface will drop the packets whose destination is not the Node, as a result, LB connections (destination is external IP) from external network will be discarded on Nodes.

  1. Does NodePort traffic work without the change?

No, NodePort traffic doesn't need this as the destination IP of NodePort connections is the Node.

  1. If we don't have tests to detect the issue, could we add one?

I think we can add one like egress e2e test. We can add such a case in PR #2950.

wenyingd
wenyingd previously approved these changes Jan 11, 2022
Copy link
Contributor

@wenyingd wenyingd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@hongliangl
Copy link
Contributor Author

/test-all-features-conformance
/test-conformance
/test-e2e
/test-flexible-ipam-e2e
/test-ipv6-conformance
/test-ipv6-e2e
/test-ipv6-networkpolicy
/test-ipv6-only-conformance
/test-ipv6-only-e2e
/test-ipv6-only-networkpolicy
/test-multicluster-e2e
/test-networkpolicy
/test-windows-conformance
/test-windows-e2e
/test-windows-networkpolicy
/test-windows-proxyall-e2e

Traffic from the uplink interface will be output to the bridge local
interface directly. When an external client connects to a LoadBalancer
type Service, and the packets of the connection are routed to the
selected backend Pod via the bridge interface; if we do not enable IP
forwarding on the bridge interface, the connection will be discarded
on the bridge interface as the destination of the connection is not the
Node.

Signed-off-by: Hongliang Liu <lhongliang@vmware.com>
@tnqn
Copy link
Member

tnqn commented Feb 23, 2022

/skip-all
/test-windows-all

1 similar comment
@tnqn
Copy link
Member

tnqn commented Feb 24, 2022

/skip-all
/test-windows-all

@hongliangl
Copy link
Contributor Author

/test-windows-all

1 similar comment
@hongliangl
Copy link
Contributor Author

/test-windows-all

@hongliangl
Copy link
Contributor Author

/test-windows-networkpolicy

1 similar comment
@tnqn
Copy link
Member

tnqn commented Feb 25, 2022

/test-windows-networkpolicy

@tnqn tnqn merged commit 74a05c5 into antrea-io:main Feb 25, 2022
bangqipropel pushed a commit to bangqipropel/antrea that referenced this pull request Mar 2, 2022
…#3137)

Traffic from the uplink interface will be output to the bridge local
interface directly. When an external client connects to a LoadBalancer
type Service, and the packets of the connection are routed to the
selected backend Pod via the bridge interface; if we do not enable IP
forwarding on the bridge interface, the connection will be discarded
on the bridge interface as the destination of the connection is not the
Node.

Signed-off-by: Hongliang Liu <lhongliang@vmware.com>
hongliangl added a commit to hongliangl/antrea that referenced this pull request Mar 21, 2022
hongliangl added a commit to hongliangl/antrea that referenced this pull request Mar 21, 2022
Signed-off-by: Hongliang Liu <lhongliang@vmware.com>
@hongliangl hongliangl deleted the windows-br-int-enable-forwarding branch April 21, 2022 01:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants