Configuring bootnodes in a production network
A network must have at least one operating bootnode. To allow for continuity in the event of failure, configure two or more bootnodes.
We do not recommend putting bootnodes behind a load balancer because the enode relates to the node public key, IP address, and discovery ports. Any changes to a bootnode enode prevents other nodes from being able to establish a connection with the bootnode. This is why we recommend putting more bootnodes on the network itself.
To ensure that a bootnode enode does not change when recovering from a complete bootnode failure:
- Create the node key pair (that is, the private and public key) before starting the bootnode.
When creating bootnodes in the cloud (for example, AWS and Azure), attempt to assign a static IP address to them. If your network is:
- Publicly accessible, assign an elastic IP.
- Internal only, specify a private IP address when you create the instance and record this IP address.
We recommend that you store the bootnode configuration under source control.
To allow for failure, specify all bootnodes on the command line (even to the bootnodes themselves).
If your network has two bootnodes, pass the following parameter to all nodes, including the bootnodes.
Having each bootnode list the other bootnodes increases the speed of discovery. Nodes ignore their own enode in the bootnodes list so it is not required to specify different bootnode lists to the bootnodes themselves.
Adding and removing bootnodes
Adding new bootnodes is a similar process to creating bootnodes. After creating the bootnodes and
adding them to the network,update the
command line option for each node to include the new bootnodes.
When adding bootnodes, you do not need to restart running nodes. By updating the
--bootnodes option, the next time you restart the
nodes (for example, when upgrading), the nodes connect to the new