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

Implementation required to enable Forwarding if it is already disabled #4172

Merged
merged 1 commit into from
Jun 5, 2024

Conversation

arghosh93
Copy link
Contributor

This PR is to remove any iptables rules which were created based on config.Gateway.DisableForwarding set to true and later it was changed to false.

This PR also ensures forwarding sysctl parameters are set for all IPv4 and IPv6 interfaces by either enabling or disabling it based on config.Gateway.DisableForwarding

- What this PR does and why is it needed

- Special notes for reviewers

- How to verify it

- Description for the changelog

@arghosh93
Copy link
Contributor Author

I have added a function setGlobalForwardingRule() to enable or disable forwarding for all IPv4 and IPv6 interfaces based on config.Gateway.DisableForwarding.
Currently we enable forwarding sysctl parameters for Global ipForwarding mode and we do set it while starting[1] ovnkube-node POD. But we dont rollback forwarding sysctl parameters to default value if we change ipForwarding mode from Global to Restricted but I think we should do that. Instead of taking care of this in here we can take care of this in ovnkube-node startup script[1]. I am open to suggestions on this point.

[1] - https://github.com/openshift/cluster-network-operator/blob/master/bindata/network/ovn-kubernetes/common/008-script-lib.yaml#L568

@tssurya tssurya self-assigned this Feb 21, 2024
@tssurya
Copy link
Member

tssurya commented Feb 21, 2024

ack let's talk about this a bit in our next meeting

@tssurya tssurya added kind/bug All issues that are bugs and PRs opened to fix bugs core-networking Issues related to traffic flows, OVN/OVS bugs, network disruption area/gateway Issues related to node gateway code labels Mar 12, 2024
@coveralls
Copy link

Coverage Status

coverage: 52.606% (-0.02%) from 52.623%
when pulling 4bfce93 on arghosh93:ipForwarding
into 49e1aea on ovn-org:master.

Copy link
Member

@tssurya tssurya left a comment

Choose a reason for hiding this comment

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

main logic looks good, please add tests for this and then I can approve

I won't force you but ... if you have time are you interested in writing up a short documentation on "disable-forwarding" config option under https://ovn-kubernetes.io/developer-guide/configuration/ please? We never had the culture of documenting anything before so I know it might seem unfair to ask you to do this now so feel free to ignore my suggestion but if you do have time.. then all I need is a
subtitle saying "Disable Forwarding Config" => then write details on what this does and add all the sample iptables rules it adds and how one can set it to false to avoid these rules etc.. (PS: Don't add any OCP product info BUT deff mention the use case for this config option and then instead of using OCP/CNO etc use operator or admin or whatever generic terms suits here) (also move configuration.md from developer-guide to getting-started folder)

// delExternalBridgeServiceForwardingRules removes iptables rules which might
// have been added to disable forwarding
func delExternalBridgeServiceForwardingRules(cidrs []*net.IPNet) error {
return deleteIptRules(getGatewayForwardRules(cidrs))
Copy link
Member

Choose a reason for hiding this comment

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

do we need the extra abstraction here? can't we just call nodeipt.DelRules(getGatewayForwardRules(cidrs)) straight from here? its straightforward enough for readability that I don't see the need for abstracting

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have done this to keep consistency with the initExternalBridgeServiceForwardingRules() and initExternalBridgeDropForwardingRules() function. init functions uses this abstraction mostly due to use of insertIptRules() in one and appendIptRules() in the other init function.

Copy link
Member

@tssurya tssurya Jun 4, 2024

Choose a reason for hiding this comment

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

but those functions have abstraction since we pass true/false for insert/append. We don't need that here which makes the layer useless right?

Copy link
Member

Choose a reason for hiding this comment

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

go-controller/pkg/node/gateway_localnet.go Show resolved Hide resolved
go-controller/pkg/node/gateway_shared_intf.go Outdated Show resolved Hide resolved
tssurya
tssurya previously approved these changes Jun 4, 2024
@tssurya
Copy link
Member

tssurya commented Jun 4, 2024

docs will be done in new PR

@tssurya
Copy link
Member

tssurya commented Jun 4, 2024

DCO seems confused, not sure why.

@arghosh93
Copy link
Contributor Author

Unit test passed in local environment. Unrelated flake from ovn-kubernetes/go-controller/pkg/ovn/egressip_test.go:1981

/retest-required

This PR is to remove iptables rules from FORWARD chain if
config.Gateway.DisableForwarding is set to false. Following
iptables rules gets removed from FORWARD chain given 10.1.0.0/16
is clusterNetwork CIDR and 10.96.0.0/16 is serviceNetwork CIDR.

-A FORWARD -s 10.96.0.0/16 -j ACCEPT
-A FORWARD -d 10.96.0.0/16 -j ACCEPT
-A FORWARD -s 169.254.169.1 -j ACCEPT
-A FORWARD -d 169.254.169.1 -j ACCEPT
-A FORWARD -d 10.1.0.0/16 -j ACCEPT
-A FORWARD -s 10.1.0.0/16 -j ACCEPT
-A FORWARD -i breth1 -j DROP
-A FORWARD -o breth1 -j DROP

Jira: https://issues.redhat.com/browse/OCPBUGS-23758

Signed-off-by: Arnab Ghosh <[email protected]>
Copy link
Member

@tssurya tssurya left a comment

Choose a reason for hiding this comment

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

Will merge after dcoapp/app#211 get's sorted out

@tssurya
Copy link
Member

tssurya commented Jun 5, 2024

CI is green, only the DCO lane is blocked but I have manually verified the signoff is correct. tysm @arghosh93 !!

@tssurya tssurya merged commit d021690 into ovn-org:master Jun 5, 2024
34 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/gateway Issues related to node gateway code core-networking Issues related to traffic flows, OVN/OVS bugs, network disruption kind/bug All issues that are bugs and PRs opened to fix bugs
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

None yet

4 participants