LB removes invalid Target neighbor entries #549
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
zolug
changed the title
This comment was marked as resolved.
This comment was marked as resolved.
zolug
force-pushed
the
lb-del-target-neigh
branch
from
2fb97cf to
4b89e0c
Compare
|
/reverify |
zolug
force-pushed
the
lb-del-target-neigh
branch
2 times, most recently
from
ad345c0 to
1f9e762
Compare
Monitor TAPA->Proxy NSM connections and update neighbor cache upon connection close events by removing neighbor entries associated with TAPA side IP addresses. Currently, the connection monitor uses a wildcard filter, matching all connections. New stateless-lb container env variables: - NAMESPACE - TARGET_DISCONNECT_MONITORING (enabling the feature by default)
zolug
force-pushed
the
lb-del-target-neigh
branch
from
1f9e762 to
7ada824
Compare
|
rebased on master |
Use network service based scope selector limiting the scope of the cluster connection monitor functionality in stateless-lb. Thus, only NSM connection events that are associated with TAPA->Proxy conns are forwarded to stateless-lb in order to update its linux neighbor cache. Requires at least NSM v1.14.2, which introduces server-side support for the new scope selector. Otherwise, functionality will fall back to the wildcard filter behavior, potentially involing a perfomrmance penalty depending on the number of NSM connections and events in the cluster. (Can be disabled via the stateless-lb env var TARGET_DISCONNECT_MONITORING.) Go version had to be updated to 1.23 because of NSM.
Some linters got inactivated leading to an error when running the linter. Thus, they are now removed from the config file's enable list. Also, deadline is not a valid linter run option based on config verify.
zolug
force-pushed
the
lb-del-target-neigh
branch
from
7ada824 to
0abcfea
Compare
zolug
added
size/M
concept/attractor
component/stateless-lb
kind/enhancement
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
LB applies cluster-wide monitoring of NSM connection Delete events between TAPA and Proxy, to remove invalid Target entries from its Linux neighbor cache preventing connection disturbances.
When TAPA experiences a NSM Heal event for example due to an unexpected connection refresh failure, the NSM connection is first closed and the associated interface is removed. Thus, the MAC address associated with the Target IP(s)
is no longer valid. Even if the same Target IP(s) will get re-assigned when the Heal process concludes, it's unlikely that the same MAC address will be assigned to the new NSM interface.
Feature can be disabled via stateless-lb env variable:
TARGET_DISCONNECT_MONITORINGAlso, stateless-lb requires the k8s namespace it's running in to figure out the NSM Network Service name the Conduit (proxy) provides for TAPAs to connect.
Note: Because NSM heal by default (i.e. without datapath monitoring) cleans up the old interface, even with the improvements proposed in this PR some disturbance might be expected (depends both on traffic and on how fast NSM heal could recover the connection).
Issue link
#548
Checklist