Bootnodes
Bootnode in Staex network is a node that is used to copy initial configuration to the new node that joins the network.
A bootnode is not a special type of node: any existing node can be used as a bootnode.
The IP address and the port of the bootnode is specified using -boot argument for mcc executable.
You can not use IP address that you specified in -net-ip argument as the address of the bootnode.
In this tutorial we will learn how to configure bootnodes in typical scenarios.
Scenario 1: VPN
Suppose you are a robotics company. You deployed your robots to a warehouse and now want to monitor and manage them remotely. You also have a fleet manager node runnning on client's premises. Your client kindly provided you with VPN access to the fleet manager node. On you premises you have multiple computers that are connected to the client's VPN via a bastion host. The following table contains example nodes and their addresses.
| Node | IP address | Network | Network owner |
|---|---|---|---|
| bastion | 172.27.0.100 | LAN | robotics company |
| bastion | 10.123.0.101 | VPN | warehouse company |
| workstation 1 | 172.27.0.201 | LAN | robotics company |
| workstation 1 | 10.123.0.102 | LAN | robotics company |
| workstation 2 | 172.27.0.202 | LAN | robotics company |
| workstation 2 | 10.123.0.103 | LAN | robotics company |
| fleet manager node | 192.168.0.100 | LAN | warehouse company |
| fleet manager node | 10.123.0.100 | VPN | warehouse company |
| robot 1 | 192.168.0.101 | LAN | warehouse company |
| robot 2 | 192.168.0.102 | LAN | warehouse company |
Both fleet manager node and bastion node have two addresses: one in LAN and one in VPN. VPN is configured as a tunnel between these two nodes, and other nodes do not have an address in VPN. The following table shows all the networks.
| Network | Address | Owner |
|---|---|---|
| office LAN | 172.27.0.0/16 | robotics company |
| VPN | 10.123.0.0/16 | warehouse company |
| warehouse LAN | 192.168.0.0/16 | warehouse company |
In the network infrastructure specified in the above tables there is no global connectivity. As a result we can not use one node as a bootnode and have to choose different bootnodes depenging on the physical network we are in. The following table shows one possible configuration.
| Node | IP address | Bootnode |
|---|---|---|
| bastion | 172.27.0.100 | 10.123.0.100 |
| workstation 1 | 172.27.0.201 | 10.123.0.100 |
| workstation 2 | 172.27.0.202 | 10.123.0.100 |
| fleet manager node | 192.168.0.100 | none |
| robot 1 | 192.168.0.101 | 192.168.0.100 |
| robot 2 | 192.168.0.102 | 192.168.0.100 |
As you can see fleet manager node is the only node that does not have the bootnode. We could also choose bastion to not have the bootnode and point fleet manager node to bastion node for the initial configuration. This would result in the same connectivity within Staex network. The following diagram is a graphical representation of the configuration from the table.
General advice
In general you may use any node that is directly accessible to the current node as a bootnode. Technically it is more efficient to use a node from the local network as a bootnode for all other nodes from this network, and then use a node with the public IP address as the bootnode for this local node. This will minimize the network traffic because only one local node needs to exchange internal messages with the node with a public IP address. Right now bootnodes is the only way to bridge several physical networks using Staex.
There are certain limitations on how networks can be bridged with Staex. Using a node (or a group of nodes) with a public IP address you can bridge any number of local networks. Using a VPN you can also bridge any number of networks, but the VPN have to include all nodes from all networks except one arbitrary local network from which the VPN may include only one node.