why is scale limited to one DHCP interface?

[hescominsoon]

The title says it all. Linux is perfectly capable of having multiple interfaces run dhcp...what is the logic behind this decision?
after reading this..it's an arbitrary decision by ix systems..yes based on "best practices". however i have every single interface physically attached to its own physical port and each of those ports has it's own VLAN on a separate subnet. for the main interface..yes i have it set to static. the others do not need to be static and i would like the option to put them into dhcp. what's stupid is ALL interfaces are on dhcp right after install. It's only when i go to make one static does the system go and then wreck the initial config. Give us the option to do it how we wish please..:)

 

[morganL]

Under "report a bug", there is an option to make "suggestions" which can then be upvoted.
Report the "bug-ID" here and we can see how many people want this and prioritize accordingly.

It's probably not a configuration we test automatically....

 

[crkinard]

The title says it all. Linux is perfectly capable of having multiple interfaces run dhcp...what is the logic behind this decision?
after reading this..it's an arbitrary decision by ix systems..yes based on "best practices". however i have every single interface physically attached to its own physical port and each of those ports has it's own VLAN on a separate subnet. for the main interface..yes i have it set to static. the others do not need to be static and i would like the option to put them into dhcp. what's stupid is ALL interfaces are on dhcp right after install. It's only when i go to make one static does the system go and then wreck the initial config. Give us the option to do it how we wish please..:)

If I recall CORE did the same thing and it was annoying. Exact same situation. All ports DHCP till you muck with one of them then the system goes all 'ONE DHCP HURRRR'.

 

[Patrick M. Hausen]

What is the system supposed to do if it gets a default gateway on each of these interfaces? Gateways and routing are global properties, not per-interface ... Similarly for DNS-Servers.

 

[jgreco]

CORE did the same thing and it was annoying.

Yes, it does, and it is probably the most correct behaviour to reject multiple DHCP because of @Patrick M. Hausen 's issue. This has been discussed semi-often before. Infrastructure systems such as NAS hosts generally should have a static IP assignment. It could be okay to listen for DHCP on more than one interface if route and DNS results were disregarded, and apparently TrueNAS already has some of that logic built in, as a poster in this thread discovered:

https://www.truenas.com/community/threads/static-routes-only-set-at-boot.99119/

But this post is ALSO the perfect example of what happens in that case; you then get a complex and unexpected interaction of behaviours where a user trying to provide static route configurations finds them not working in light of the DHCP subsystem's management. In that case, the user's locally specified static routes were not persisting through a link flap because the kernel deletes routes when an interface is reconfigured, and while the gateway is maintained by the dhclient.conf entry, there's nothing that reinstantiates the statics. "Ooooooops".

The obvious problem with multi DHCP is that if one network gives you one set of (routes, DNS, NTP, domain suffixes, etc), and another network gives you another, which ones do you use? Non-default routes may not happen to conflict, which would be good, but most of the rest, including default routes, generate configuration ambiguity.

Additionally, given that DHCP servers can die, your NAS can fall offline, and since a DHCP server is not obligated to give you the same IP address, client sessions can be broken at lease renewal or whatever.

All of this combines to make DHCP a really bad idea for a NAS host or, more generally, most other multi-interface UNIX hosts.

 

[crkinard]

EDIT: <deletes baby rant and just drops it>

 

[jgreco]

EDIT: <deletes baby rant and just drops it>

Responding to ... that.

The problem is that even if your use case doesn't actually cause a problem, the developers need to write code that anticipates the next guy, who may be trying to do something just a bit too "clever" and then runs afoul of issues.

I predicted your response which is why I linked to an example of the trainwreck of trying to negotiate the collision of manual and automatic configurations, and also the classic arguments against using DHCP on a multi-interface UNIX system.

If these things could be made to work reliably, such as under IPv6 where DHCP isn't really such a big thing, then they probably would be made to work reliably. We've all been living with the drain bamage that is IPv4 for way too long. Happy to gripe about it over a beer with you if you'd like. Until then, we all kind of have to suffer from the real world implementation issues.