SVI/netbird
1
0
Fork 0
mirror of https://github.com/netbirdio/netbird.git synced 2026-08-04 19:55:09 -04:00
Code Issues 3.0k Packages Projects Releases 10 Wiki Activity

Remove unused|stale peers from netbird peer entries configuration #2437

New Issue
Closed
opened 2025-11-20 07:09:49 -05:00 by saavagebueno · 3 comments
saavagebueno commented 2025-11-20 07:09:49 -05:00
Owner
Copy Link

Originally created by @marcportabellaclotet-mt on GitHub (Nov 4, 2025).

Description:

Currently, when peers disconnect or stay offline , they continue to appear in the local netbird peers configuration (netbird status -d). These peers are shown with a Status: Connecting, even though they are no longer active.

When peers are completely removed from the Netbird configuration, they do disappear as expected — however, there’s no automatic cleanup for peers that are simply disconnected or inactive for a long time.

This leads to “peer entry spam” in the netbird configuration, which can grow significantly over time in larger networks.

Expected behavior:
Peers that remain disconnected for a long time (or are inactive beyond a configurable threshold) should be automatically removed or cleaned up from the local netbird peers configuration to keep it accurate and manageable.

Actual behavior:
Disconnected or long-inactive peers remain indefinitely in the local configuration with a Connecting status.

Steps to reproduce:

Connect multiple peers to the same Netbird network.

Disconnect some peers or keep them offline for an extended period.

Run netbird status -d on an active peer.

Observe that inactive peers still appear with a Connecting status.

Impact:

The list of peers grows indefinitely in long-lived networks.

Harder to read and manage peer states.

Potentially unnecessary overhead on peer configuration synchronization.

 xtx31q4kxw.netbird.selfhosted:
  NetBird IP: 100.127.138.6
  Public key: zzzzz
  Status: Connecting

Peers count: 20/102 Connected
Originally created by @marcportabellaclotet-mt on GitHub (Nov 4, 2025). Description: Currently, when peers disconnect or stay offline , they continue to appear in the local netbird peers configuration (netbird status -d). These peers are shown with a Status: Connecting, even though they are no longer active. When peers are completely removed from the Netbird configuration, they do disappear as expected — however, there’s no automatic cleanup for peers that are simply disconnected or inactive for a long time. This leads to “peer entry spam” in the netbird configuration, which can grow significantly over time in larger networks. Expected behavior: Peers that remain disconnected for a long time (or are inactive beyond a configurable threshold) should be automatically removed or cleaned up from the local netbird peers configuration to keep it accurate and manageable. Actual behavior: Disconnected or long-inactive peers remain indefinitely in the local configuration with a Connecting status. Steps to reproduce: Connect multiple peers to the same Netbird network. Disconnect some peers or keep them offline for an extended period. Run netbird status -d on an active peer. Observe that inactive peers still appear with a Connecting status. Impact: The list of peers grows indefinitely in long-lived networks. Harder to read and manage peer states. Potentially unnecessary overhead on peer configuration synchronization. ``` xtx31q4kxw.netbird.selfhosted: NetBird IP: 100.127.138.6 Public key: zzzzz Status: Connecting Peers count: 20/102 Connected ```
saavagebueno added the feature-requestclient labels 2025-11-20 07:09:49 -05:00
saavagebueno commented 2025-11-20 07:09:50 -05:00
Author
Owner
Copy Link

@nazarewk commented on GitHub (Nov 4, 2025):

You can somewhat remedy the increased connectivity attempts with Lazy connections. Currently there is no way to hide those except for --filter-by-status=connected argument to netbird status.

I think we were considering not sending offline peers from the management, but it will need careful design not to break anything or degrade performance and therefore will not land in the foreseeable future.

@nazarewk commented on GitHub (Nov 4, 2025): You can somewhat remedy the increased connectivity attempts with Lazy connections. Currently there is no way to hide those except for `--filter-by-status=connected` argument to `netbird status`. I think we were considering not sending offline peers from the management, but it will need careful design not to break anything or degrade performance and therefore will not land in the foreseeable future.
saavagebueno commented 2025-11-20 07:09:50 -05:00
Author
Owner
Copy Link

@marcportabellaclotet-mt commented on GitHub (Nov 4, 2025):

Thanks for the quick reply.
What would be the impact of removing peer configurations that are no longer active or have been disconnected for a long time? If those peers try to reconnect later, could that cause any issues?

Also, is it possible to manually remove peer configurations from other peers, similar to what WireGuard allows with wg set peer remove? I was able to remove a peer using the wg command, but it still appears in netbird status -d, and it reappears in wg show after restarting Netbird.

And just as I am curious, where is this peer config stored on netbird?

@marcportabellaclotet-mt commented on GitHub (Nov 4, 2025): Thanks for the quick reply. What would be the impact of removing peer configurations that are no longer active or have been disconnected for a long time? If those peers try to reconnect later, could that cause any issues? Also, is it possible to manually remove peer configurations from other peers, similar to what WireGuard allows with wg set <interface> peer <public-key> remove? I was able to remove a peer using the wg command, but it still appears in netbird status -d, and it reappears in wg show after restarting Netbird. And just as I am curious, where is this peer config stored on netbird?
saavagebueno commented 2025-11-20 07:09:50 -05:00
Author
Owner
Copy Link

@nazarewk commented on GitHub (Nov 12, 2025):

And just as I am curious, where is this peer config stored on netbird?

It's not stored anywhere; it comes from the management server as a part of "Network Map" to apply to the local client.

@nazarewk commented on GitHub (Nov 12, 2025): > And just as I am curious, where is this peer config stored on netbird? It's not stored anywhere; it comes from the management server as a part of "Network Map" to apply to the local client.
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 feature-request
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#2437
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?