Aggressive peer connection burst at startup (can look like port scanning)

[akrem-chabchoub]

Context

• Bee version: 2.7.1-rc2
• Mode: ultra-light (no RPC), mainnet, existing data dir with populated address book
• Config: full-node: false, blockchain-rpc-endpoint: "", mainnet: true, verbosity: debug

Summary

On startup, the node connects to bootnodes then immediately tries to connect to every peer in the address book in one go. That produces a large burst of outbound TCP connection attempts to many IPs/ports in a short time. Many attempts fail (stale addresses, private IPs, unreachable IPv6), but the pattern can look like port scanning to network monitoring or firewalls. In a restart loop (e.g. when RPC is down), this burst repeats every restart and amplifies the effect.

Expected behavior

Startup peer discovery should be gradual: connect to bootnodes first, then add and connect to address-book peers in a limited or staggered way so we don’t blast hundreds of connection attempts in the first seconds.

Actual behavior

1. Node starts and connects to bootnodes (e.g. 3).
2. Kademlia loads the full address book from disk and adds all peers as known (batches of 500).
3. The manage loop runs immediately and tries to connect to many of those peers in parallel.
4. Result: hundreds of "attempting connect to peer" and "libp2p connect" attempts in a short window; many fail (connection refused, i/o timeout, no route to host). Log grows very large (e.g. hundreds of thousands of characters).

Relevant log excerpts (verbosity debug):

Startup and bootnode connections:

"time"="2026-02-23 14:49:54.370753" "level"="info" "logger"="node" "msg"="chain backend disabled - starting in ultra-light mode" "full_node_mode"=false "blockchain-rpc-endpoint"=""
"time"="2026-02-23 14:49:54.371014" "level"="info" "logger"="node" "msg"="using chain with network" "chain_id"=100 "network_id"=1
"time"="2026-02-23 14:50:04.845372" "level"="debug" "logger"="node/libp2p" "msg"="successfully connected to peer (outbound)" "address"="6b2bbaefb45f2e3a5bcfde27efa4acf0b646422a3a93152dccd07652e61cd419"
"time"="2026-02-23 14:50:16.387694" "level"="debug" "logger"="node/libp2p" "msg"="successfully connected to peer (outbound)" "address"="b0901e49ce52ed334be87917260020d62247c94936a792b27b708c415559b8fd"
"time"="2026-02-23 14:50:26.776554" "level"="debug" "logger"="node/libp2p" "msg"="successfully connected to peer (outbound)" "address"="a8ef8f87372897bfb37e2614a38d801ba3561ea14e8e4a9d3e67ccb5499be82c"

Immediately after, Kademlia starts a burst of connection attempts (same second):

"time"="2026-02-23 14:50:26.779170" "level"="debug" "logger"="node/kademlia" "msg"="attempting connect to peer" "peer_address"="a445397b498ce9cc05c12c24a281cd20fba88102ac24ac44d805d10987ae2eef"
"time"="2026-02-23 14:50:26.779279" "level"="debug" "logger"="node/kademlia" "msg"="attempting connect to peer" "peer_address"="b414b4c2a5e041509a16756a76e290b9e6db5dbfa2903c0614717d36b278414d"
"time"="2026-02-23 14:50:26.779363" "level"="debug" "logger"="node/kademlia" "msg"="attempting connect to peer" "peer_address"="dcc5bb419e24164892fc67b3934bb3168c9d7668ae224ec23c26779882967244"
"time"="2026-02-23 14:50:26.779584" "level"="debug" "logger"="node/kademlia" "msg"="attempting connect to peer" "peer_address"="94085d1cd13219c6b7d0dedbd81ed4fb63772d6434329b24625a9f02cead4beb"
"time"="2026-02-23 14:50:26.779663" "level"="debug" "logger"="node/kademlia" "msg"="attempting connect to peer" "peer_address"="fc5c6e007f5a2089ad551d55d529de2ddfe3083361f1b9b0f2f4443583f7a12f"
"time"="2026-02-23 14:50:26.779650" "level"="debug" "logger"="node/kademlia" "msg"="attempting connect to peer" "peer_address"="99fba5149f92fce4394ff48785c2b4f74f9e97974f8be0fb4ff886176ec6e993"
... (many more in same second)

Failures (connection refused, private IP timeouts, IPv6 no route):

"time"="2026-02-23 14:50:26.904886" "level"="warning" "logger"="node/libp2p" "msg"="libp2p connect" "peer_id"="QmWNHYruQVrBYyEeZqXn5RbE38mAEamhGfNhnAbJaVTPd3" "underlay"=["/ip4/46.212.38.179/tcp/49856"] "error"="... dial tcp4 46.212.38.179:49856: connect: connection refused"
"time"="2026-02-23 14:50:26.905353" "level"="info" "logger"="node/kademlia" "msg"="could not connect to peer" "peer_address"="99fba5149f92fce4394ff48785c2b4f74f9e97974f8be0fb4ff886176ec6e993" "error"="... connection refused"
"time"="2026-02-23 14:50:42.134581" "level"="warning" "logger"="node/libp2p" "msg"="libp2p connect" "underlay"=["/ip4/10.233.86.42/tcp/1634"] "error"="... dial tcp4 10.233.86.42:1634: i/o timeout"
"time"="2026-02-23 14:50:42.134752" "level"="warning" "logger"="node/libp2p" "msg"="libp2p connect" "underlay"=["/ip4/10.233.88.6/tcp/1634"] "error"="... i/o timeout"
"time"="2026-02-23 14:50:04.846461" "level"="debug" "logger"="node/libp2p/reacher" "msg"="ping failed" "addr"="/ip6/2a03:b0c0:2:d0::10bf:e001/tcp/1634/..." "error"="... connect: no route to host"

Steps to reproduce

1. Run a Bee node on mainnet with RPC for a while so the address book gets populated (or use an existing data dir that already has many peers).
2. Stop the node then emove RPC config.
3. Start Bee again with the same data dir.
4. Observe logs: right after bootnode connections, many "attempting connect to peer" (kademlia) and "libp2p connect" (success or warning) lines in a short time; many failures to private IPs (10.x), stale ports (connection refused), or IPv6 (no route to host). Log file grows quickly.

Possible solution

Spread it out: Don’t add the whole address book at once. Add peers in small chunks over time (e.g. 50 every 10–15 seconds) instead of 500 in one go. That way connection attempts are spread over time and we avoid a big burst at startup. Same peers get tried, just not all in the first few seconds.