Serving Multiple Subnets on one NIC, and two vNICs

[Glenn Satchell]

On Thu, August 2, 2012 9:50 am, Adam Wolfe wrote:
> Message: 5 Date: Wed, 1 Aug 2012 10:52:55 +0100 From: Simon Hobson
> <dhcp1 at thehobsons.co.uk> To: Users of ISC DHCP
> <dhcp-users at lists.isc.org> Subject: Re: Serving Multiple Subnets on one
> NIC, and two vNICs Message-ID:
> <p06240816cc3eaa4b2bee at simon.thehobsons.co.uk> Content-Type: text/plain;
> charset="us-ascii" ; format="flowed" Adam Wolfe wrote:
>>> I am in the middle of setting up a new dhcp server between 3
>>> subnets, using ubuntu 10.04.
>>>
>>> The subnet that eth0 is connected to is 10.8.35.0 and will not use
>>> dhcp at all.
>>>
>>> The subnet that eth0:26 is connected to is 10.8.26.0, eth0:37 is on
>>> 10.8.37.0
>> OK, a couple of things you need to know here.
>> 1) You **CANNOT** run a DHCP server on a virtual NIC like eth0:1.
>> DHCP is a broadcast technology, and when a broadcast packet arrives
>> on the physical interface, there is no way whatsoever to determine
>> which of the interfaces it should be handled by.
>> Leading on from that, you cannot service only some subnets on an
>> interface ...
> Thanks.  Didn't know that about vNICs, but it does make sense the way
> you explain it.  I've also tried adding additional "real" NICs (this is
> a VM), but again the routes seem to be confusing the server like you
> pointed out.  So I'd assume serving dhcp (shared-network or otherwise)
> would best be done using one NIC only.  Is that correct?
>> 2) What you have here is known as a shared network - multiple IP
>> subnets on the same broadcast domain. Lookup shared-network in man
>> dhcpd.conf
>>
> Right.
>>> I'm practically positive on my dhcp.conf, it was copied from
>>> another, already working, server.  It just seems like it doesn't
>>> know where it should be sending the info to, but it is trying.  It
>>> also cannot ping other devices on the 26 and 37 subnets.
>> Well since you didn't post your dhcpd.conf we can't see what's in it.
>> My guess is you don't have the right information.
> I'm confident in the conf, but I can post it if needed when I get back
> to work tomorrow.  I took the dhcp.confs from two working servers I've
> set up previously that have been running for about a year or so and
> merely wrapped them in a shared-network clause to make this one,
> current, conf.  The server is sending replies when it receives a
> request, they simply do not make it to the requestor which leads me to
> believe it's the routes, or, noting your first comment, the fact that
> it's bcast.  My thinking is now that it has no idea where to send a
> bcast reply since it has 3 NICs.  Silly of me, now that I think of it.
>>> I was also wondering how to overcome the 'not configured to listen
>>> on any interfaces' caused by adding "INTERFACES="eth0 eth0:26
>>> eth0:37" " to /etc/default/dhcp-server.
>> Virtual NICs aren't valid.
>>
>> What you will need in dhcpd.conf is :
>>
>> shared-network "somename" {
>>     subnet 10.8.35.0 ...
>>     }
>>     subnet 10.8.26.0 ...
>>       option ...
>>       range ...
>>     }
>>     subnet 10.8.37.0 ...
>>       option ...
>>       range ...
>>     }
>> }
>>
>> Not that there is a subnet declaration for 10.8.35.0, just nothing in
>> it so no clients will be given an address in this subnet.
> Yeah.  The 10.8.35.0 is a static only network for servers, switches,
> W/APs etc etc.  Thanks for the tip, though.  Like you said, I needed to
> add in the 10.8.35.0 (with no range or any options) just to get dhcp
> running when I moved from three NICs to one.  It confused me for a bit
> until I realized what you meant.  Thanks again.
>
>> Anticipating the next question ... which I expect will be some
>> variant of "why do clients get an address in the 'wrong' subnet ?"
>> As far as DHCP is concerned, all the available IPs in the
>> shared-subnet are equal, and any address can be given to any client.
>> If you need to have certain clients in certain subnets then you'll
>> have to find some means of identifying them and explicitly telling
>> DHCPD how to treat them. This may be by listing all of one class with
>> host declarations and then using [allow|deny]-known clients; or you
>> may need to use classes.
> Nah.  Not my problem.  That's the CCNAs job.  ;)  They say they can take
> care of this at the router/switch level.  Something about flagging the
> bcast request on the way to the dhcp server so when the reply is made
> the switches then know where to send the reply back or simply ignore it
> if it's not on their network.
>
> So basically from where I started, I guess I'm down to:
>
> Should I be using one NIC only, regardless of the number of subnets
> being served?  Or would I be better off just going back to separate
> servers for each subnet?  I kinda stumbled upon the shared-network
> option when I was converting the two previous dhcp servers into one VM,
> it turned into a challenge so I thought I'd pursue it and learn.  But if
> I'm a loooong ways from success on it, please, let me know.  I can put
> it on the back burner and play with it during free-time rather than
> trying to hammer it out now and sucking up others' time.
>
A shared-network is for when you have multiple IP ranges in the same
broadcast domain, ie on the same layer 2 switches.

If you use a router to have different physical subnets, then that is not a
shared-network, and in that case you don't configure virtual IPs for those
other subnets on the dhcp server. Doing so makes those subnets local, and
the dhcp server will never be able to route back to where it should go.

Using routers, sounds like the network guys set up a dhcp-relay (or in
Cisco speak an "ip-helper"). For that situation you still need the subnet
defintions, but no shared-network, and no local virtual interfaces for
those subnets. Check you can ping the various routers to confirm the
networking is configured properly.

regards,
-glenn

> Again, thanks for the tips, all.
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>