Skip to content

Enable sloppy_tcp when DSR and Maglev is enabled #1888

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

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

AnupamGhosh
Copy link

Fixes #1860

Copy link
Collaborator

@aauren aauren left a comment

Choose a reason for hiding this comment

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

Thanks @AnupamGhosh!

Overall looks really good! I added just a few small requests.

sysctlErr := sloppyTCP.WriteVal(1)
if sysctlErr != nil {
klog.Errorf("Failed to enable IPVS sloppy TCP: %s", sysctlErr.Error())
} else {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can you simplify this just a bit by putting a return after the klog.Errorf above and removing the else statement?

Copy link
Author

Choose a reason for hiding this comment

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

sure

} else {
klog.Infof("IPVS sloppy TCP enabled")
}
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

We should handle disabling Sloppy TCP in the case that it is enabled and there are no DSR services with maglev hashing found.

Can you add an else if here to handle !enableSloppyTCP && sloppyTCP.CachedVal() == 1? (I think that one of the linters in this project may ask you to change the if ... else if to a switch statement when making this change)

Copy link
Author

Choose a reason for hiding this comment

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

I was thinking about the scenario when an user had already set sloppy_tcp to 1 and if we disable sloppy_tcp then we are going against the user even though kube-router can still function with sloppy_tcp being set.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think that its a pretty obscure option, so we're probably safe here. And since it potentially makes services less secure, if we set it, then we should unset it if its not needed.

I see what you're saying, but I think that we can probably just explain this a bit by adding something to the documentation saying that we expect to control this option when the service controller is enabled.

Copy link
Author

Choose a reason for hiding this comment

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

okay.
I have updated the code to disable sloppy_tcp if there is no service with DSR or Maglev enabled.

@@ -241,6 +251,10 @@ func NewKRNode(node *apiv1.Node, linkQ LocalLinkQuerier, enableIPv4, enableIPv6
},
linkQ: linkQ,
NodeInterfaceName: nodeInterfaceName,
sloppyTCP: SysctlConfig{
name: IPv4IPVSSloppyTCP,
value: 0,
Copy link
Collaborator

Choose a reason for hiding this comment

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

At first I was sceptical about hard-coding this this value, but I think that it makes sense, especially when handling the reverse condition that I asked for above. Essentially assuming that this is 0 from a kube-router standpoint, means that if the user has set this value for whatever reason manually, we won't revert it above unless we specifically set it to 1. Which means that we have less of a chance of reverting manual changes to the system that the admin may have made.

Do you mind writing something like that in a comment above this setting so that we remember that we purposefully didn't look up the live setting with GetSysctl()?

Copy link
Author

Choose a reason for hiding this comment

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

sure I will do.

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.

Resilience to TCP SYN Node Loss
2 participants