Manage peers
Hyperledger Besu peer-to-peer (P2P) discovery happens periodically based on the number of peers in a network and the node's peer limit.
The frequency of discovery isn't configurable, but you can limit remote connections in public networks and randomly prioritize connections in small, stable networks.
You can use admin_addPeer
to attempt a specific connection, but this isn't P2P discovery.
In private networks, we recommend using bootnodes to initially discover peers.
Limit peers
You can limit peers to reduce the bandwidth, CPU time, and disk access Besu uses to manage and respond to peers.
To reduce the maximum number of peers, use the --max-peers
option. The default is 25.
The minimum number of peers is set by the --Xp2p-peer-lower-bound
option, which also has a default of 25. If you reduce the --max-peers
from the default, you must also set the --Xp2p-peer-lower-bound
option to the same value or lower. For example, if you decrease --max-peers
to 20, set --Xp2p-peer-lower-bound
to 20 or lower.
Note, Xp2p-peer-lower-bound
is an early access option.
Limit remote connections
Prevent eclipse attacks when using --sync-mode
and --fast-sync-min-peers
on public networks by enabling the remote connection limits.
In private and permissioned networks with only trusted peers, enabling the remote connection limits is unnecessary and might adversely affect the speed at which nodes can join the network. Limiting remote connections can cause a closed group of peers to form when the number of nodes in the network is slightly higher than --max-peers
. The nodes in this closed group are all connected to each other and can't accept more connections.
You can use --random-peer-priority-enabled
to help prevent closed groups of peers in small, stable networks.
Monitor peer connections
JSON-RPC API methods to monitor peer connections include:
Each peer entry returned by admin_peers
includes a protocols
section. Use the information in the protocols
section to:
Determine the health of peers. For example, an external process can use
admin_peers
andadmin_removePeer
to disconnect from peers that are stalled at a single difficulty for an extended period of time.Monitor node health. For example, if peers report increasing difficulties but the node is stuck at the same block number, the node may be on a different fork to most peers.
Determine which protocol level peers are communicating with. For example, you can see if
"version": 65
is being used to reduce transaction sharing traffic.
List node connections
The default logging configuration doesn't list node connection and disconnection messages. To enable listing them, set the --logging
option to DEBUG
. For more verbosity, set the option to TRACE
.
The console logs connection and disconnection events when the log level is DEBUG
or higher. If the message Successfully accepted connection from ...
displays, connections are getting through the firewalls.
2018-10-16 12:37:35.479-04:00 | nioEventLoopGroup-3-1 | INFO | NettyP2PNetwork | Successfully accepted connection from 0xa979fb575495b8d6db44f750317d0f4622bf4c2aa3365d6af7c284339968eef29b69ad0dce72a4d8db5ebb4968de0e3bec910127f134779fbcb0cb6d3331163c
Disable discovery
To disable P2P discovery, set the --discovery-enabled
option to false
.
With discovery disabled, peers can't open connections with the node unless they were previously discovered or manually peered (for example, using admin_addPeer
). Static nodes can also open connections.
Troubleshoot
If your nodes fail to connect, ensure the required ports are open.
If your nodes are running in AWS, check you have appropriate SecurityGroups
to allow access to the required ports.
Check that the enode URLs specified for bootnodes or static nodes match the enode URLs displayed when starting the remote nodes.