TL;DR: I want to verify the following is the right procedure for using DHCP on a network bridge, where DHCP is actually used to assign TrueNAS a static IP address (via MAC address to IP mapping in the DHCP config).
Having recently discovered Jailmaker, I wanted to experiment with nspawn jails that can get their own IP via DHCP and be fully routeable on my network. The first step in doing this is to have a bridge interface on the TrueNAS host.
I’m not currently using VLANs. The TrueNAS system has a single physical network interface. I have my router set as a DHCP server, though most devices on the network (including the TrueNAS server) have a static MAC address to IP mapping. (IOW, the router’s DHCP config allows for a single point to manage static IP addresses and DNS names on my local network.)
Prior setting up the bridge, this was a trivial network config (enable DHCP on the one connected interface, and everything just works). After some trial and error, the process to switch to a bridge with static-DHCP appears to look like this:
Router: disable the DHCP static mapping for the TrueNAS NIC’s MAC address
TrueNAS: disable DHCP for the existing interface
TrueNAS: create the bridge device, select DHCP, add the device from previous step as a member
TrueNAS: save and test config
Router: watch the DHCP log for a new request and make note of the MAC address
At this point, on first glance, it will appear that the TrueNAS device has lost connectivity, but it should be alive and well but under a new DHCP address (this will be a temporary IP address)
TrueNAS: login to the GUI using this new (temporary) IP and save the network config so that it is persistent
Router: recreate the DHCP static mapping for TrueNAS but use the MAC address from step 5
TrueNAS: restart networking (or reboot), and it should now be using the desired IP address
I also have a Proxmox server, which also has a single physical interface, no VLANs, and a bridge device. However, with that server, I am able to use the MAC address of the physical NIC for its DHCP static mapping. I initially assumed TrueNAS would work similarly, and struggled a bit until I realized that under TrueNAS, the bridge will make its DHCP query with a new MAC address.
Everything appears to be working. But my main question is: the MAC address that TrueNAS generated (step 5 above): can I count on that being permanent? Or is there a chance it will arbitrarily change?
Assuming its permanent, and the process I outlined above is indeed valid for this use case, I hope it’s useful for others who might be struggling.
To me, there’s some amount of inescapable complexity, therefore it’s a matter of where you want to have the complexity. If indeed the bridge MAC address that TrueNAS generated is permanent, then I’m “paying” that complexity only once. And now, per my initial post, the instructions are plainly laid out in text, no need to sit through a video.
Compare that to the “recurring payment” complexity of having my static IP and DNS database no longer in a single central place. IOW, that would result in a “split brain” situation, where most of my devices IPs are managed in my router, but now I have to remember that TrueNAS is a special case.
Surely using DHCP to assign static IPs is a common practice, specifically for the benefit of having a single “source of truth”? Particularly at a smaller scale, e.g. SOHO/SMB, where the scale isn’t big enough to warrant using infrastructure-as-code/automation/orchestration tools.
Price wise your argument makes sense only if you pay for if you are outside the homelab case: You have to do bridging for many machines and you are paying DHCP server maintanence already.
Also IIRC Creating a bridge is happens at the link layer(mac addresses) not at the IP layer; IP is where I understand DHCP does its work. Its “clever” to do that wityh bridges than with DHCP. But you could theoretically create a routing system in the DHCP server to send traffic from all VMs/Containers to the host.
can I count on that being permanent? Or is there a chance it will arbitrarily change?
No, but if you are going to change the mac address of the bridge all your VM’s traffic is going to be disrupted. For homelabs this is an amortized price, paid over over crashes/reinstalls etc. For enterprise, I can see that central management via a router would take precedence. But only you can answer which of those two cases your NAS falls under as I mentioned in the first line.
recreate the DHCP static mapping for TrueNAS but use the MAC address from step 5.
If you are saying you have to recreate it in the router, This is not needed. Per sec 3.2 https://www.ietf.org/rfc/rfc2131.txt the client can ignore it. Yes, you have to pick an IP address when attaching your machine to a network that is outside the DHCP address range to be safe, but that is pretty much it.
In summary:
You decide the operating regime.
If Homelab, The MAC changing should not matter because it works at MAC addresses(data link layer) and you should not be needing to use it – Neither do @Stux’s videos – and I suspect you should be able to use midctl to do the same programmatically
If managed DHCP, $$insert custom/dhcp solution here$$
