SVI/netbird
1
0
Fork 0
mirror of https://github.com/netbirdio/netbird.git synced 2026-05-17 13:42:11 -04:00
Code Issues 3.0k Packages Projects Releases 10 Wiki Activity

How to disconnect Netbird Peering Router without affecting clients #2025

New Issue
Open
opened 2025-11-20 06:11:28 -05:00 by saavagebueno · 3 comments
saavagebueno commented 2025-11-20 06:11:28 -05:00
Owner
Copy Link

Originally created by @karlveezoo on GitHub (Jun 30, 2025).

Hello,

I am running netbird peering routers in 2 pods in my kubernetes cluster for HA. When either upgrading the deployment or the nodes, these pods will be recreated in a rolling fashion. However it does feel like when this happen the client gets affected and you either have to wait a few minutes or disconnect/connect the client to get a connection established again.

I added a preStop hook to my kubernetes deployment for the routers that does "netbird down", before terminating the pods, but it doesn't seem to make things noticeably better.

Any tips for how I can achieve that when a pod is terminated the router will let the client "know" so they can establish connections to the other router pod instead?

Originally created by @karlveezoo on GitHub (Jun 30, 2025). Hello, I am running netbird peering routers in 2 pods in my kubernetes cluster for HA. When either upgrading the deployment or the nodes, these pods will be recreated in a rolling fashion. However it does feel like when this happen the client gets affected and you either have to wait a few minutes or disconnect/connect the client to get a connection established again. I added a preStop hook to my kubernetes deployment for the routers that does "netbird down", before terminating the pods, but it doesn't seem to make things noticeably better. Any tips for how I can achieve that when a pod is terminated the router will let the client "know" so they can establish connections to the other router pod instead?
saavagebueno added the peer-managementclientroutesnetworkingperformance labels 2025-11-20 06:11:28 -05:00
saavagebueno commented 2025-11-20 06:11:29 -05:00
Author
Owner
Copy Link

@nazarewk commented on GitHub (Jun 30, 2025):

Seems like a use case for https://github.com/netbirdio/netbird/issues/3636

Could you provide a set of debug bundles for ~2 client Peers affected by the slow reconnection times? It is expected to take seconds (not minutes), so we would like to take a look.

Could you tell if it's more than 10 minutes or less? It might be somehow related to Ephemeral Peers expiration time.

Which version are you running? Can you try with the latest one?

For gathering logs I would suggest to do following:

  1. set NB_LOG_LEVEL to trace
  2. increase NB_LOG_MAX_SIZE_MB to 200 MB to cover a few minutes of logs (there are lots of those)
  3. perform an upgrade
  4. upload a debug bundle https://docs.netbird.io/how-to/troubleshooting-client#debug-bundle-uploads
@nazarewk commented on GitHub (Jun 30, 2025): Seems like a use case for https://github.com/netbirdio/netbird/issues/3636 Could you provide a set of debug bundles for ~2 client Peers affected by the slow reconnection times? It is expected to take seconds (not minutes), so we would like to take a look. Could you tell if it's more than 10 minutes or less? It might be somehow related to Ephemeral Peers expiration time. Which version are you running? Can you try with the latest one? For gathering logs I would suggest to do following: 1. set `NB_LOG_LEVEL` to `trace` 2. increase `NB_LOG_MAX_SIZE_MB` to 200 MB to cover a few minutes of logs (there are lots of those) 3. perform an upgrade 4. upload a debug bundle https://docs.netbird.io/how-to/troubleshooting-client#debug-bundle-uploads
saavagebueno commented 2025-11-20 06:11:29 -05:00
Author
Owner
Copy Link

@nazarewk commented on GitHub (Jun 30, 2025):

What I gathered from the team, the current expectations are as follows:

  • Relay - Relay connections can take up to ~3 minutes to be reestablished, but those can take seconds in ideal network conditions.
  • P2P -> Relay connections aren't expected to take less than ~30 seconds due to wireguard timeouts and connection reestablishments
  • P2P - P2P connections should kick in faster than ~30 seconds

We're planning to improve this sooner rather than later.

@nazarewk commented on GitHub (Jun 30, 2025): What I gathered from the team, the current expectations are as follows: - Relay - Relay connections can take up to ~3 minutes to be reestablished, but those can take seconds in ideal network conditions. - P2P -> Relay connections aren't expected to take less than ~30 seconds due to wireguard timeouts and connection reestablishments - P2P - P2P connections should kick in faster than ~30 seconds We're planning to improve this sooner rather than later.
saavagebueno commented 2025-11-20 06:11:29 -05:00
Author
Owner
Copy Link

@karlveezoo commented on GitHub (Jul 7, 2025):

Hi,

thanks for the reply. I will do an upgrade this week and do some tracing on my client for you

@karlveezoo commented on GitHub (Jul 7, 2025): Hi, thanks for the reply. I will do an upgrade this week and do some tracing on my client for you
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
2021 Q4
2022 Q1
2022 Q1
accessibility
acl
agent
agent
Android
Android
api
authentik
automation
azure
battery-usage
bug
cache
client
client-ui
cloud
cloud-only
cloudflare
community
compatibility
config-idp
config-issue
connection
contribution
coturn
cross-vpn
dashboard
data-usage
distribution
dns
docker
documentation
duplicate
enhancement
enhancement
event-stream
feature-request
freebsd
getting-started
go
good first issue
gui
help wanted
home-assistant
idp
inconsistency
integration
integrations
ios
ipv6
jwt
k8s
keycloak
linux
login
macos
management-service
missing-docs
mobile
moved-internal
needs-review
netbird-ui
networking
new-platform
nginx
notification
okta
openwrt
packaging
peer-management
peer-management
peer-management
performance
postgres
posture-checks
psk
pull-request
Mirrored from GitHub Pull Request
 question
refactor
relay
release
rfc
routes
security
security-related
self-hosting
server
signal
sleep-issue
ssh
ssl
status
store
synology
system-compatibility-issue
test-suite
third-party-integration
triage
triage-needed
troubleshooting
UX
waiting-feedback
windows
wontfix
zitadel
No Label client networking peer-management performance routes
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
saavagebueno
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: SVI/netbird#2025
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?