Zebra 6.2.3 Release

Ecosystem Updates Zcash Foundation
3

v6.2.3: “attempted to add a banned peer addr” logged ~300k times in 24h

Running zebrad 6.2.3 on Ubuntu 24.04 (ThinkPad L450, 8 GB RAM), Mainnet, fully synced.

After a peer is banned for misbehavior, crawl_and_dial repeatedly attempts to re-add the same banned address to the address book, emitting a WARN each time — dozens of times within the same millisecond:

2026-08-03T19:20:06.585024Z  WARN crawl_and_dial{new_peer_interval=61s}: zebra_network::address_book: attempted to add a banned peer addr to address book change=UpdateAttempt { addr: <redacted>:60886 }
2026-08-03T19:20:06.585102Z  WARN crawl_and_dial{new_peer_interval=61s}: zebra_network::address_book: attempted to add a banned peer addr to address book change=UpdateAttempt { addr: <redacted>:60886 }
[... 17 more within the same millisecond, same address ...]

I archived my log yesterday, so this is roughly 24 hours of runtime: 297 881 occurrences of this single warning, in a 61 MB log file. It is the overwhelming majority of the file.

The ban itself looks legitimate:

WARN zebra_network::address_book: banned ip and removed banned peer addresses from address book
  updated=MetaAddr { addr: <redacted>:8233, misbehavior_score: 100,
  last_connection_state: Responded, user_agent: Some("/Zebra:6.2.3/"),
  negotiated_version: Some(Version(170160)) } total_peers=2090 recent_peers=1

Note total_peers=2090 but recent_peers=1, dropping to 0 a minute later.

What looks wrong is that the crawler keeps selecting an address it has just banned, rather than excluding it from the candidate set. Two questions:

  1. Should banned addresses be filtered out of the crawler’s candidate selection instead of being rejected at insertion time?
  2. If the repeated attempts are expected, could this be logged at DEBUG or rate-limited? At this rate a long-running node produces gigabytes of logs.

Context, likely unrelated to the above: my node holds only 1–5 peers. Of the negotiated peer versions I could extract from the log, 38 were 170140/170150 and only 7 reached 170160, so most candidates are rejected at handshake on protocol version. I take this to reflect the current state of NU6.3 migration across the network rather than a Zebra defect — mentioning it only in case a small candidate pool contributes to the crawler hammering the same few addresses.

Config is standard: peerset_initial_target_size = 75, default max_connections_per_ip, listen_addr = "0.0.0.0:8233", standard DNS seeders (I removed mainnet.is.yolo.money, which no longer resolves — the others return 25, 7, 1 and 2 addresses respectively).

Happy to provide a fuller log excerpt or run any diagnostic.

Pense à vérifier que les adresses IP sont bien anonymisées si tu colles des extraits supplémentaires — ton log les affiche déjà en v4redacted, donc c’est géré nativement par Zebra.

3 Likes