Avoid IP collisions with servers' static IP in the mesh

[nicopace]

While having a conversation with @tbdinesh this issue came about:

We are thinking of using 1 pi for dns resolution and run bind on it. How to give a static ip on mesh for this name server?

this made me think how we manage the computers that are fixed in our networks.

One way of approaching this is to add the fixed ip and host to /etc/hosts, but you would have to maintain it yourself.

The other way is by not configuring it at all... i think that when the dhcp does a lease, it asks if that ip has been used (so it doesn't step onto anyone else)... but not sure if it happens on all interfaces (so bat0 is also included, ie the whole mesh), or not...

Anyway, I believe this should be a typical usecase that we should consider.

[ilario]

One possibility is to specify an IP range for nodes autoconfiguration (with the /16/17 notation) and another for DHCP leaving out a range available for the static IPs.

lime-packages/packages/lime-docs/files/www/docs/lime-example.txt

Lines 33 to 35 in 2b7226a

	option main_ipv4_address '10.%N1.0.0/16' # Here you have 4 possibilities: set a static IP and the subnet, like '10.0.2.1/16'; parametrize with %Mn and %Nn, and set the subnet, like '10.%N1.%M5.%M6/16'; set a whole network address (not a specific IP) for getting the IP autocompleted in that network with bits from MAC address, this works also with netmasks other than /24 or /16, like '10.0.128.0/17' (but not valid network addresses, for example '192.0.128.0/16' or '192.0.129.0/17' won't get parametrized); set two different parameters, the first for subnet and the second for IP parameterization, like '10.0.128.0/16/17', this results in /16 subnet but IP parametrized in a /17 range (from 10.0.128.1 to 10.0.255.254).
	option anygw_dhcp_start '2' # First IP in the subnet to be used for DHCP for clients. For example, if the subnet is 10.x.0.0/16 and you want the clients to get an IPv4 from a DHCP pool starting from 10.x.100.2, the start parameter will have to be 100 * 256 + 2 = 25602.
	option anygw_dhcp_limit '0' # Number of IPs available for DHCP. Use zero for having the DHCP pool ranging from anygw_dhcp_start up to the end of the subnet. For example, if the subnet is 10.x.0.0/16, the start of the DHCP pool is at 10.x.100.2 and you want the DHCP pool to finish at 10.x.127.254, the limit parameter will have to be (127 - 100) * 256 + (254 - 2) + 1 = 7165. Instead, if you want the DHCP pool to go from 10.x.100.2 up to 10.x.255.254 (last valid IPv4 in the /16 subnet) you can just set the limit to zero.

[nicopace]

Thanks @ilario for your response. Yes indeed, you can.

I would like to (and feel would be positive for the process):

1. understand how it behaves when a device connects to the network and has a fixed IP address
2. consider this usecase for the non-technical or semi-technical crew: ie. someone that knows how to fix an IP address in its computer, but not in the whole mesh.

Also, I am interested in ways to approach this that don't require to reflash the whole mesh with a new set of configurations, or if needed to create the necessary changes in order for this not to be required, as it is something that belongs to the runtime of the network, and it happens in relation with a different layer, so it should expect not to be hardwired on the firmware.... right?

eager to hear the rest here...

[germanferrero]

If I got this right, I think this may somehow tackle number 2 as it does not need to be configured in the whole mesh manually:

At the node in which you have your pi / computer that needs a fixed ip connected add the following:

# /etc/lime-assets/node/my-server-static-lease.conf

dhcp-host=<MAC>,<IP>,<HOSTNAME>,infinite

# /etc/config/lime-node

(...)
config copy_asset my-server-static-lease
   option asset 'node/my-server-static-lease.conf'
   option dst '/etc/dnsmasq.d'

From d632acc
this will make shared-state spread both the lease and the host to the network.

By using copy_asset at lime-node, the configuration will be persisted through upgrades making maintenance easier.

[nicopace]

Thanks for this @germanferrero !
I think it is the easiest.
Though the best would be for the mesh to remember leases and hostnames (so users don't have to fiddle with IP Addresses management), this is a fair tradeoff.

[brunovianna]

Im trying the suggestion by German, and I'm getting the following error when running lime-config after the changes:

/usr/bin/lua: /usr/lib/lua/lime/config.lua:122: attempt to index local 'high_pt' (a nil value)
stack traceback:
	/usr/lib/lua/lime/config.lua:122: in function 'uci_merge_files'
	/usr/lib/lua/lime/config.lua:169: in function 'uci_autogen'
	/usr/lib/lua/lime/config.lua:195: in function 'main'
	/usr/bin/lime-config:55: in main chunk
	[C]: ?

the files were edited like this:
/etc/lime-assets/node/static-lease.conf:

dhcp-host=01:33:3:33:33:33:33,10.7.7.7,name,infinite

/etc/config/lime-node:

        option hostname 'name'

config lime 'network'

config lime 'wifi'

config copy_asset static-lease
   option asset 'node/static-lease.conf'
   option dst '/etc/dnsmasq.d'

[spiccinini]

Hi Bruno! I think that the problem is that UCI does not support the middle - in the name (static-lease) .... I believe it has to be 'static-lease' or static_lease, can you try that?

[ilario]

Even after years this is still useful, se need to confirm this work and document it.
@brunovianna did this work?