CentOS - Jan 2017 - Centos 7 dhcpd failure to allow a 2nd network over same interal nic

> I have not been able to make any headway resolving this problem; 
Personally, I don't understand how you expect the DHCP server to decide
which scope to use when a new connection appears on the network.

DHCP discovery queries are presented from 0.0.0.0 to 255.255.255.255, not to
a particular network's broadcast address.

I'd be interested to see what happens when one of your 10.x.x.x nodes
reaches half time or lease expiration and tries to renew its IP.  I tend to
think it would then be offered an address from the 192.168.0.x scope
instead, if it's currently offering those to the wireless connections.

Date: Sun, 15 Jan 2017 11:57:35 -0500
> I have not been able to make any headway resolving this problem; 
Personally, I don't understand how you expect the DHCP server to decide
which scope to use when a new connection appears on the network.

DHCP discovery queries are presented from 0.0.0.0 to 255.255.255.255, not to
a particular network's broadcast address.

I'd be interested to see what happens when one of your 10.x.x.x nodes
reaches half time or lease expiration and tries to renew its IP.  I tend to
think it would then be offered an address from the 192.168.0.x scope
instead, if it's currently offering those to the wireless connections.

--------------------------------------------------------------
Thanks for your response !!!!

All I can say is that when I looked at the dhcpd.conf examples and read
the man pages as well as the explanations of how dhcpd works, we should
be able to use dhcpd for more than one subnet :

Take a look at Rehat's explanation of a Multihomed dhcp server :

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sect-Configuring_a_Multihomed_DHCP_Server.html

If I am reading this and other documents incorrectly, then I would
welcome having you step on my toes.  I have spent more time on time on
this problem than it would have taken just to purchase another nic card
and put in another piece of hardware.  However, it is always worth the
effort in learning how everything works.

Thanks again for your input!!!

Greg Ennis

On 01/15/2017 09:11 AM, Gregory P. Ennis wrote:
> All I can say is that when I looked at the dhcpd.conf examples and read
> the man pages as well as the explanations of how dhcpd works, we should
> be able to use dhcpd for more than one subnet :


You can, provided they're on different physical interfaces.

I'm mostly certain you can have two DHCP scopes on one physical 
interface, provided that the DHCP server itself only has addresses on 
one of them.  That is, if eth0 has 192.168.1.9 and only that address, 
you should be able to offer addresses for 192.168.1.0/24 and also 
192.168.2.0/24 on that interface.  Any host you want to assign an 
address in 192.168.2.0/24 will have to be manually added to that subnet 
with a "host" entry in dhcpd.conf.  Otherwise, imagine that you have
an
Ethernet LAN that includes a WAP.  When the DHCP server gets a request 
from a new host, how does it know whether that client is on Ethernet or 
WiFi?  There's no indication in the request the server receives that 
indicates which media the client is using.

However, attaching two IP subnets to the same broadcast domain is 
usually a bad idea.  Networks are typically segregated for one of two 
reasons: either to establish access controls or to reduce traffic to 
improve service.  You'll accomplish neither.  Hosts on each subnet won't
be able to communicate with each other directly, but they will all see 
all of the address discovery traffic broadcast on the network.  A host 
that wanted to communicate with a host in another subnet could simply 
add a new address manually and bypass any access controls that the 
router had in place. Worse, because any communication you *do* want to 
allow has to pass to the router and then be sent back out the same 
network interface, you've actually doubled the amount of traffic on your 
LAN.

Having multiple subnets on a single broadcast domain can be an 
interesting, inexpensive way to experiment with access control or 
simulate multihosting, but you don't want to do it for any longer than 
is necessary for experimental purposes.