Hyperledger Besu peer-to-peer (P2P) discovery happens periodically based on the number of peers in a network and the node’s peer limit.
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.
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.
Xp2p-peer-lower-bound is an early access option.
Limit remote connections
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_removePeerto 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": 65is 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
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.
Sample log output
2018-10-16 12:37:35.479-04:00 | nioEventLoopGroup-3-1 | INFO | NettyP2PNetwork | Successfully accepted connection from 0xa979fb575495b8d6db44f750317d0f4622bf4c2aa3365d6af7c284339968eef29b69ad0dce72a4d8db5ebb4968de0e3bec910127f134779fbcb0cb6d3331163c
To disable P2P discovery, set the
--discovery-enabled option to
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.
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.