If you have successfully boot your CSN's Swarm nodes, and would like these chassis to always have those specific IP addresses, you can statically assign those IP addresses to specific MAC addresses. There are some caveats that I will explain at the bottom.
If you can type: /opt/caringo/csn/bin/ip-assignments and get output similar to:
You can statically assign those IP addresses to those MAC addresses. That way you know that every time you boot the Swarm chassis with MAC 000c290ac7a2, it will come up with these 3 IP addresses: 192.168.202.84, 192.168.202.85, and 192.168.202.86. Most of the time, especially in a stable network environment, the same chassis will always get the same IP addresses, but there is no guarantee by default.
If you would like to lock down these IP addresses to these MAC addresses, you will need to create static configuration files in /var/opt/caringo/netboot/content/nodeconfigs/ in the form of sn[mac].cfg where each file is specific to one chassis.
Within each of these configuration files, you can put whatever parameters are specific to that chassis. Usually, each chassis should be configured exactly the same, but in the case we are discussing, you want to assign the networking parameters in the form below:
There is a script in the support bundle swarm-support-tools.tgzcalled csn-create-nodeconfigs.sh that will allow you to create the appropriate files assuming your current ip-assignments output is the desired MAC to IP binding.
These node-specific files only take effect after a reboot of the nodes.
The Swarm Reporter function in the CSN requires ip-assignments to be up-to-date and accurate. If you use Swarm Reporter (which is removed in CSN 8.3), using node-specific configuration files may break your reporting.
You can run the script against a file that had been previously created with ip-assignments command. Please use the -h flag for an example.
If the underlying chassis hardware configuration changes, that will not be reflected in this script output. Ie, if you remove a CPU and boot the chassis again, you may have too many processes defined for the underlying hardware.
If you change the internal network in the CSN UI, these files will not automatically change. You would need to delete the files, boot the cluster normally, then run this script again to generate node-specific configuration files that reflect the new networking changes.