I have my containers getting a dynamic IP address from my home network’s router, however, I have run into an issue. My router is so poor and dated that I can’t even reserve IP addresses. So, this means I have to request that IP address from my container. I have tried a couple things that don’t seem to work.
1- edit the /etc/network/interfaces.d/50-cloud-init.cfg so that it requests a static IP
Producing error:
RTNETLINK answers: Cannot assign requested address
when I do ifdown eth0 && ifup eth0
2- lxc config device set containerName eth0 ipv4.address ip-addr
The configs for the container show this after I make that change:
eth0:
ipv4.address: 192.168.1.110
nictype: bridged
parent: br0
type: nic
However, I still get an unwanted address from my router’s DHCP server. I don’t want to do the NAT method with a couple of my containers because they’re remaining on the inside network only and I have a lot of ports to forward that I don’t want to do. Any ideas?
Not sure I follow. Are you saying your containers get DHCP addresses from the local host (i.e. container host) as well as your local router?
As for the 50-could-init.cfg file; I remove this file on all my containers as it causes network confusion during booting. I simply use the /etc/network/interfaces file for all dynamic/static IP address assignments.
I get a DHCP address from my network router right now, not my host. My problem is I want to assign a static IP address to my containers, however, my router (for whatever reason) doesn’t have the functionality to reserve IP addresses so I need to configure my containers to request a static address from my router. This isn’t a problem on the host server, as the IP address I requested is indeed addressed to my host. I hope that clears up what I said
ipv4.address can only be used when the bridge is LXD managed, which it’s not in your case.
So the solution here is to manually configured your container for a static address, through /etc/network/interfaces. You mentioned an error above which is most likely due to an invalid configuration being put in that file.
Modifying the configuration and then doing ifdown + ifup isn’t supported, especially when you’re changing config type (from dhcp to static for example). ifupdown is stateless and so doesn’t know how the interface was configured in the past.
Thank you for the help Stéphane! I edited the container’s config file like you said, and had to ifdown eth0, edit the config and ifup eth0 like you said. I also took @rkelleyrtp advice and deleted the 50-could-init.cfg file. Talking about the states when changing the config files…is that a container problem? I remember changing configs on a host then doing ifdown/up after the matter
Nope, it’s a general problem which applies to any system using ifupdown.
The most common example of this is if you change from “inet dhcp” to “inet manual”.
Doing “ifdown eth0 && ifup eth0” after the fact will appear to succeed, in that the interface will go down and your static address will be set.
However, the DHCP client that was running before (because of “inet dhcp”) will NOT be stopped by ifupdown (as it no longer knows about DHCP) and so whenever the lease is due to be renewed, the DHCP client will do its job and change your interface’s configuration again, typically wiping your static IP in the process.
This case is the worst as it will typically result in loss of connectivity and also won’t appear to be related to the change of configuration since it can happen hours after the ifdown/ifup.
That explains some of the problems I have seen with using ifdown/ifup in general when running a command to simply change my IP to a static one in a single command. Good to know, thank you again for your input