-
Notifications
You must be signed in to change notification settings - Fork 283
OCPBUGS-83406 OCPBUGS-83407: fix issue for managed mode of no-overlay #2960
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
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -46,7 +46,7 @@ data: | |||||
| # | ||||||
| vtysh_enable=yes | ||||||
| zebra_options=" -A 127.0.0.1 -s 90000000 --limit-fds 100000" | ||||||
| bgpd_options=" -A 127.0.0.1 -p 0 --limit-fds 100000" | ||||||
| bgpd_options=" -A 127.0.0.1 -p {{ if .NoOverlayManagedEnabled }}179{{ else }}0{{ end }} --limit-fds 100000" | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Listening on port 179 is the default, so this can just be
Suggested change
However, is this really correct? Won't dropping the
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. With managed no-overlay, there are some BGP messages that we want to accept, but that doesn't meant that we want to accept all BGP messages from all sources. The fact that we previously disabled this implies that either (a) in some clusters there are "stray" BGP messages that we want to ignore, or (b) there are security concerns with accepting all BGP messages. So, we may need some sort of firewall rule or bgpd configuration option in addition to enabling port 179.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @danwinship initially, we were listening on all ports. Then, some issue arose due to listening on all ports and we blocked traffic by mentioning
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @danwinship it's not about messages, it's about who initiates the bgp session.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @fedepaol @karampok I think there might have been an issue, maybe related to graceful restart: https://redhat.atlassian.net/browse/OCPBUGS-48521?focusedCommentId=3095119 Other than that... What @danwinship suggested here is good right? There is no need to explicitly set I think we should register port 179 here: https://github.com/openshift/enhancements/blob/master/dev-guide/host-port-registry.md In terms of hardening, I guess the API&docs should describe that this opens up port 179 to accept incoming BGP connections from other cluster nodes and leave it up to the customer to install whatever firewall rules it deems necessary? I am not aware of other instances where we apply hardening on user behalf (might completely be missing it).
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yes. We probably also need to deal with the "commatrix" stuff (the thing that makes sure that all listening ports are properly declared as Services). (eg, see OCPBUGS-077019)
It's not just nodes. It's any host that can reach nodes. In particular, it might mean we accept BGP connections from our upstream router?
We install a lot of firewall rules in IPI clusters (in the form of AWS/GCP/Azure/etc security policies). For UPI clusters, we document what ports need to be left open, and who they need to be left open to (https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/installation_configuration/configuring-firewall).
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yeah. what I meant to say is document the purpose so that a user can apply correct policies: i.e. block any incoming connection that does not come from other cluster node/subnet.
Is that done from installers? Do we own those policies? Anything for baremetal?
Good place to doc!
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The GR (Gracefull Restart) was dropped by openshift so we should be okay. Nevertheless if in the future there is a another property that is set only during the BGP session, then that might be have the same bug (= the external side setups the session before the ocp side writed the frr config use this property) My preference would be to have |
||||||
| ospfd_options=" -A 127.0.0.1" | ||||||
| ospf6d_options=" -A ::1" | ||||||
| ripd_options=" -A 127.0.0.1" | ||||||
|
|
||||||
Uh oh!
There was an error while loading. Please reload this page.