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

[10.4 stable] Detect Network Instance IP subnet conflict #3832

Merged
merged 1 commit into from
Mar 25, 2024

Conversation

milan-zededa
Copy link
Contributor

@milan-zededa milan-zededa commented Mar 22, 2024

Zedrouter is able to detect if NI IP subnet overlaps with the subnet of another NI or with a device port network. When a conflict is detected for a new NI, it is blocked from being created. If IP conflict arises for an already created NI (e.g. a device port later received IP from an overlapping subnet), the NI is unconfigured and VIFs are set DOWN (not deleted). In both cases an error is reported for the NI.

This is crucial because, previously, an NI with a subnet overlapping with a device port network would result in the device permanently losing controller connectivity (due to routing conflicts), with very limited options to restore connectivity and make the device manageable again. Instead, the device should remain online, inform the user about the issue, and allow to correct the IP configuration.

When IP conflict is detected for an already created NI with an app connected to it, we intentionally do not halt and undeploy the app. Instead, the app is left running, just VIFs connected to the problematic NI lose their connectivity. This allows the user to fix the network config or at least backup the application data when IP conflict arises.

To enable the deletion of NI when an IP conflict is detected, followed by its later recreation when the conflict is resolved, and to reconnect already running apps, few enhancements had to be made to the NI Reconciler, particularly in the area of VIF bridging.

(cherry picked from commit f868941)

Zedrouter is able to detect if NI IP subnet overlaps with the subnet
of another NI or with a device port network. When a conflict is detected
for a new NI, it is blocked from being created. If IP conflict arises
for an already created NI (e.g. a device port later received IP from
an overlapping subnet), the NI is unconfigured and VIFs are set DOWN
(not deleted). In both cases an error is reported for the NI.

This is crucial because, previously, an NI with a subnet overlapping with
a device port network would result in the device permanently losing
controller connectivity (due to routing conflicts), with very limited
options to restore connectivity and make the device manageable again.
Instead, the device should remain online, inform the user about the issue,
and allow to correct the IP configuration.

When IP conflict is detected for an already created NI with an app
connected to it, we intentionally do not halt and undeploy the app.
Instead, the app is left running, just VIFs connected to the problematic
NI lose their connectivity. This allows the user to fix the network
config or at least backup the application data when IP conflict arises.

To enable the deletion of NI when an IP conflict is detected, followed
by its later recreation when the conflict is resolved, and to reconnect
already running apps, few enhancements had to be made to the NI Reconciler,
particularly in the area of VIF bridging.

Signed-off-by: Milan Lenco <milan@zededa.com>
(cherry picked from commit f868941)
Copy link
Contributor

@eriknordmark eriknordmark left a comment

Choose a reason for hiding this comment

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

LGTM

@eriknordmark eriknordmark merged commit 89fb811 into lf-edge:10.4-stable Mar 25, 2024
15 checks passed
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.

2 participants