Bug 435599 - [Deployment Guide] A few informations missing for DHCP section (chapter 21)
Summary: [Deployment Guide] A few informations missing for DHCP section (chapter 21)
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: Documentation
Version: 5.4
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Murray McAllister
QA Contact: Joshua Wulf
URL: https://www.redhat.com/docs/manuals/e...
Depends On:
Blocks: 237606
TreeView+ depends on / blocked
Reported: 2008-03-02 11:58 UTC by Răzvan Sandu
Modified: 2015-01-04 22:35 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-11-09 05:54:54 UTC
Target Upstream Version:

Attachments (Terms of Use)
build of Deployment Guide that contains multihomed DHCP configuration (7.28 MB, application/octet-stream)
2008-05-22 06:08 UTC, Murray McAllister
no flags Details
mmcallis reply to comment# 6 (4.14 KB, text/plain)
2008-05-22 10:16 UTC, Murray McAllister
no flags Details

Description Răzvan Sandu 2008-03-02 11:58:56 UTC
Description of problem:

The Deployment Guide misses informations regarding DHCP server installation in
the following situations:

- DHCP server runs on a multihomed machine (say a router, more than one Ethernet
interface). Via DHCP, we want to communicate different network parameters to
those different Ethernet segments. What is the canonical, correct way of
configuration in /etc/dhcpd.conf ?

- DHCP server runs on a multihomed machine (say a router, more than one Ethernet
interface). We only want DHCP server listening and serving eth1, eth3 and eth5.
What should we write in /etc/sysconfig/dhcpd, at the DHCPDARGS parameter (how to
exclude eth0 and eth2 from DHCP server configuration)?

- DHCP server runs on a multihomed machine (say a router, more than one Ethernet
interface). How to configure two workstations with the same name NAME, in two
*different* Ethernet segments, physically connected to eth1 and eth3 ?

   host NAME {
      option hardware ethernet xx:xx:xx:xx:xx:xx;
      option fixed-address xx.xx.xx.xx;

- We have a DHCP client with two (or more) Ethernet interfaces, who connect
*alternatively* to the same Ethernet segment (one at a time). We want this
client to take the same name and IP address, independently of the interface we
What to write in /etc/dhcpd.conf of the server ? Since it seems it's not correct
to write:

     host NAME {
      option hardware ethernet xx:xx:xx:xx:xx:xx;
      option hardware ethernet yy:yy:yy:yy:yy:yy;
      option fixed-address xx.xx.xx.xx;

Version-Release number of selected component (if applicable):
RHEL Deployment Guide, version Revision 5.1.0-1, Tue Jun 26 2007

How reproducible:

Thanks a lot,

Comment 1 Răzvan Sandu 2008-05-13 10:58:22 UTC
Hello, any news about this, please ?


Comment 2 Murray McAllister 2008-05-14 06:52:55 UTC
Hi Razvan,

I am currently looking into this. I will reply again when I have more
information, and when the content is ready.



Comment 3 Murray McAllister 2008-05-22 06:06:40 UTC

I am attaching a build of the Deployment Guide which includes the requested
content. This content will not appear in the Deployment Guide package, or on
redhat.com/docs until a later release cycle.

To quickly answer your questions:

1. different parameters to different networks are done with multiple subnet
declarations. Refer to 21.4 "Configuring a Multihomed DHCP Server", on
approximately page 363 of the PDF.

2. to listen only on specific interfaces, add those interfaces to
/etc/sysconfig/dhcpd The following will only listen on eth0 and eth1"

DHCPDARGS="eth0 eth1";

3. workstations with the same name? It does not matter what their name is, so
use multiple host declarations, making sure the "hardware ethernet" address is 
              the host you want to configure. Refer to 24.4.1 "Host
Configuration", approximately page 365 of the PDF. Also refer to this for your
last question, simply add more host declarations, but change the fixed-address
for the desired subnet/network.



Comment 4 Murray McAllister 2008-05-22 06:08:09 UTC
Created attachment 306338 [details]
build of Deployment Guide that contains multihomed DHCP configuration

Comment 5 Murray McAllister 2008-05-22 06:11:04 UTC
Note: the above attachment is 7meg...

Comment 6 Răzvan Sandu 2008-05-22 07:50:28 UTC
Thank you al lot for the documentation and quick answers !

We (me and my mates) will repeat experiments using your indications - however,
in previous attempts:

- we were unable to configure DHCP server with the same workstation NAME in
*different* subnets (DHCP service won't start afterwards);

- we just wanted to know how to *exclude* an interface from the list, if
possible ("listen on all interfaces except this");

- we needed to know how to configure alternate hardware addreses (say a laptop
that connects to the same network, in one situation by wire, in other by radio,
and requests IP adress from the same DHCP server)

Best regards,

Comment 7 Murray McAllister 2008-05-22 10:14:46 UTC

I have a lot of text, so I'm adding it as an attachement.

Hope it helps.



Comment 8 Murray McAllister 2008-05-22 10:16:47 UTC
Created attachment 306357 [details]
mmcallis reply to comment# 6

Comment 9 Răzvan Sandu 2008-05-25 13:21:06 UTC

Thanks for your clarifications in comment #8 .

However, there are two serious limitations for those that don't use dynamic DNS:

1. We have a multihomed DHCP server connected to two networks (say and We have a mobile workstation (say a laptop)
that moves between the two networks and needs the DHCP server to assign an IP to
it in both of them.

However, we want the laptop to have an *unique* name (DNS name = /etc/hosts name
= Samba name = DHCP name in host section etc.) independently of the network is
connected to.

2. We have a DHCP server providing IP addreses to a network (say The network can accomodate fixed workstations and wireless ones
(via a wireless access point).

We want the workstation to have an *unique* name, independently of the way of
connecting it - so we don't want two host sections in DHCP with *different*

Is there any way to accopmplish this ?

Thank you a lot,

Comment 10 Murray McAllister 2008-05-25 22:21:28 UTC

1) Do you want the laptop to have a different hostname, based on which network
it connects to? Try adding an "option host-name" option to "/etc/dhcpd.conf":

host test0 {
	  hardware ethernet xxxxxx;
	  fixed-address address-in-subnet-1;
	  option host-name "subnet1";

host test1 {
	hardware ethernet xxxxxx;
	fixed-address address-in-subnet-2;
	option host-name "subnet2";

Where "subnet2" can be something like "laptop.subnet1"...

Most DHCP clients ignore the "host-name" option, so you may need to do the

1. If not installed already, install the "dhclient" package.
2. Create an empty "/etc/dhclient.conf" file.
3. Add (at least) the following:

interface eth0 {

Refer to the example "dhcpd.conf" file in the
"/usr/share/doc/dhclient-[version]/" directory.

According to http://linux.about.com/od/commands/l/blcmdl5_dhclien.htm , this
should allow the hostname to be set by the DHCP server.

2) Use the example above, but have a "host" declaration for each interface, for
example, the "fixed-address" will be different in each one.

The "option host-name" option *overrides* the "host [name] {" name, so having
names such as "test0" and "test1" will not affect your client machines:

host test0 {
	  hardware ethernet ethernet-mac-address;
	  fixed-address address-in-subnet-1;
	  option host-name "subnet1";

host test1 {
	hardware ethernet wireless-mac-address;
	fixed-address address-in-subnet-2;
	option host-name "subnet2";

Apologies for taking so long on this. Please let us know how you go!

Kind Regards,


Comment 11 Murray McAllister 2008-05-25 22:23:53 UTC

For the last example, I put the ethernet and wireless in different subnets, but
it will work fine if they are in the same subnet.



Comment 12 Răzvan Sandu 2008-05-26 21:19:38 UTC
> Do you want the laptop to have a different hostname, based on which network
> it connects to?


On the contrary, in examples given in comment #9, I want the laptop to have a
*single*, unique name in all networks where it is connected, independently of
the interface I use for connecting (fixed or wireless).

I will insert this name in (static) DNS, with multiple corresponding IP addreses.

Is that tecnhnically possible ?


Comment 13 Murray McAllister 2008-05-26 21:55:07 UTC
Sorry, I misunderstood.

Re comment #12, it is most certainly possible. If you set the hostname in
"/etc/hosts" | "/etc/sysconfig/network", DHCP will not change this, and it does
not matter where you take your machine, or where you connect it to - it will
keep this hostname. Also, changing from ethernet to wireless will not change it...

So, for an example, if you are running BIND, your zone database file might look
like this:

laptop IN A
laptop IN A

Depending on which network you connect to, one of these will not work. If you
are connected to, the address will fail to resolve to
"laptop". The Red Hat Enterprise Linux Deployment Guide has information on
configuring BIND:

What you need to do:

1. Configure DHCP to _always_ give a certain address to the machine.
2. Configure your nameserver with these IP addresses, both resolving to the same

Hope that helps.



Comment 14 Murray McAllister 2008-05-26 21:57:01 UTC
re comment #13, point 1, you will need to configure DHCP to give an address to
both ethernet and wireless interfaces. Refer to comment #10


Comment 15 Răzvan Sandu 2008-05-28 17:51:09 UTC

Is it correct to write:

host test0 {
	  hardware ethernet ethernet-mac-address;
	  fixed-address address-in-subnet;
	  option host-name "laptop";

host test1 {
	hardware ethernet wireless-mac-address;
	fixed-address address-in-subnet;
	option host-name "laptop";

so I will keep the name "laptop" wherever I connect to ?

"address-in-subnet" may be the same ?


Comment 16 Murray McAllister 2008-05-29 00:40:20 UTC
re comment #15:

Yes, that configuration looks sane; however, as mentioned in the Deployment
Guide, most DHCP clients ignore the "option host-name" option, and if your
configuration is like you have posted, configure the hostname "laptop" in
"/etc/hosts", and also in "/etc/sysconfig/network" (if it is going to be the
same, like your configuration says).

/etc/hosts:       localhost.localdomain   localhost       myhostname

Change "myhostname" to whatever name you want (your FQDN and aliases may differ
to mine, as shown above). The format is IP address -> FQDN -> aliases. In the
above example, both "localhost" and "myhostname" will resolve to



Change the "HOSTNAME" variable to match the appropriate alias in "/etc/hosts".

"address-in-subnet" can be the same -- but I am not sure if this will cause
lease conflicts. If you could test it by using the same address, un-plugging
ethernet, and then turning on wireless, making sure both times they receive the
same "address-in-subnet" address, then I'll add it to the guide. In
"/etc/dhcpd.conf" file, what values are you using for the following options:

default-lease-time x; 
max-lease-time x;

It should be possible to use the same address for each, while quickly swapping,
but if not, is there any reason why you need the same address for both interfaces?

Thanks for your help,

- Murray.

Comment 17 Răzvan Sandu 2008-05-29 05:04:54 UTC
Thank you,

About manually putting the names in /etc/hosts (which I always do):

Please note that there is NetworkManager, that introduces new ways of doing
things in networking. This is still in Fedora 9, but it will probably land in
Red Hat, too.

There is a whole discussion about NetworkManager (inadvertently) modifying
/etc/resolv.conf - please see NetworkManager bugs #134886 , #441453, and many
others. Network files tends to be dynamic, rather than static - should this
affect the DHCP-assigned names, too ?

To control things, we *surely* need some good quality documentation about the
new behaviour introduced by NetworkManager, including relationship with DHCP...


Comment 18 Murray McAllister 2008-05-29 05:25:37 UTC

On Red Hat Enterprise Linux 5 NetworkManager should not change your hostname.

All instructions so far have been written for Red Hat Enterprise Linux 5; I was
not aware you were using Fedora.

What configurations are you trying, and which ones are working?

"we *surely* need some good quality documentation about the
new behaviour introduced by NetworkManager" - agreed, that is lacking. I sent a
post to fedora-docs list asking about it:



Comment 19 Răzvan Sandu 2008-05-29 05:40:01 UTC
I'm using Fedora on *some* (non-critical) machines (for tests) and Red Hat
Enterprise on others (servers).

I just feared NetworkManager's newly introduced behaviour will land in RHEL, too.
And I'm trying to make sure this won't happen until some carrefully designed
documentation, that covers all possible situations, is available.

Thanks a lot for your help,

Comment 20 Murray McAllister 2008-05-29 09:02:06 UTC
No worries, that should not be in Red Hat Enterprise Linux for quite a while ;)

The following overview might explain things better:

Regarding your first questions in comment #1, have these been answered, or are
you still having problems?


Comment 21 Murray McAllister 2008-06-06 02:03:48 UTC

Any updates on this? 

Are you finding any configurations for multihomed DHCP in the  Red Hat
Enterprise Linux Deployment Guide to be incorrect? 

Anything more you would like added?

Kind Regards,


Comment 22 Răzvan Sandu 2008-06-06 03:16:09 UTC
Hello an d thanks A LOT,

Just taking time to evaluate and test in practice  ;-)  !

For the moment, just one suggestion. Please add in some part of the guide the
trick in comment #15 : how to add a laptop to a network and maintain the *name*
and *IP* when connecting with two possible cards, Ethernet or wireless.

Best regards,

Comment 23 Răzvan Sandu 2008-06-06 03:22:27 UTC
Murray, are you evaluating only the DHCP part of the guide or the document as a
whole ? Maybe I have other suggestions for other chapters.

If so, please see bug #240891, #286387, #435602, #447140, #435410, #243982, #216687.

All of these bugs have *at least one part (paragraph) related to documentation
issues* and some of them are really old and still unsolved.

Thanks again.


Comment 24 Murray McAllister 2008-06-06 05:54:19 UTC

Thanks for the feedback. I am planning to add more details after this
conversation, since I was not clear the first time.

This bug is only for DHCP, and only for this request. I can quickly look at
those other bugs, but not sure if I have time at the moment to resolve.

Thanks again for your help and testing.

- Murray.

Comment 25 Murray McAllister 2008-06-06 06:01:11 UTC

Those look quite detailed. I'll try to see if someone can help. regarding bug
#286387, I could not find this one.



Comment 26 Răzvan Sandu 2008-06-07 07:30:20 UTC
Sorry, my fault - it was a typo !

The complete list is:

bug #240891, bug #216387, bug #435602, bug #447140, bug #435410, bug #243982,
bug #216687

Please let me know if I can help by testing or by writing pieces of
documentation (can't do it right now because I don't know the technical answers
in the first place  ;-)  ).


Comment 27 Murray McAllister 2008-06-19 03:05:02 UTC

* bug 240891 - I don't know anything about this

* bug 216387 - At the moment this guide is for Red Hat Enterprise Linux, not
Fedora. Not sure if this one will make it in...

* bug 435602 - Not sure on this one.

* bug 447140 - I did the static route thing you added. The section is limited
because routing should be done on a router. At this point we are unable to
include details about the version of NetworkManager as shipped in Fedora.

* bug 435410 - Looks like a Fedora thing -- but this should not be too much of a
hassle to do to the Red Hat Enterprise Linux Deployment Guide (if it is not
there already).

* bug 243982 - I thought this was something you set in your email client?

* bug 216687 - I have no news one this. I am not experienced with mail. I can
try to follow it up later if you would like.

Sorry for the late response. Hope this helps, and thanks for the offer to test!



Comment 28 Murray McAllister 2008-06-19 04:14:47 UTC
Also, what version of dhcp are you using? You can find this by running "rpm -q
dhcp". I am using and tested the above on dhcp-3.0.5-7.el5


Comment 29 Răzvan Sandu 2008-06-22 11:32:49 UTC

Regarding comment #28:

I am using a mixture of machines, mainly CentOS and Fedora.

I've tested all the solutions you gave me about DHCP and they seem perfectly OK.
I've tested on mainly on dhcp-4.0.0-14.fc9.x86_64.

So I think we may close this specific bug about DHCP documentation.

How do you suggest acting on the (documentation part of the) other bugs, as
listed in comment #27 ?

Many of these  bugs are old and unsolved and I have to put specific comments on
each of them. Murray, would you please consider adding yourself in Cc: at each
of them, so we may close this DHCP-documentation bug and continue discussion on
the other bugs, individually ?

Thanks A LOT,

Comment 30 Murray McAllister 2008-06-22 22:37:20 UTC

Thanks for testing and confirming those configurations work. I need to update
the guide to add a few bits based on your previous comments.

I will try to find out what is happening with regards to the other bugs.

Thanks again for your help and patience.

- Murray.

Comment 31 Murray McAllister 2008-08-10 05:44:24 UTC
Apologies for the slow response. I will try to update next weekend with details from the previous comments.

Comment 32 Murray McAllister 2008-11-02 23:37:26 UTC
Apologies for the delay. I have added a bit of text to make this clearer.

If you want specific information about configuring "/etc/dhclient.conf" for clients, please open another bug.


Comment 33 Răzvan Sandu 2008-12-16 06:25:55 UTC

Regarding point no. 2 in my original bug, please note that there are situations when one cannot enumerate all valid DHCP interfaces, like in DHCPARGS="eth0 eth1". Simply because you cannot know the name of the interface in advance (is it wlan0 or eth0, when using various wireless USB adapters)...

In /etc/sysconfig/dhcpd, it will be very useful to have a way to *exclude* an interface from DHCP, so to say "run DHCP on all system interfaces except this".

A syntax like DHCPARGS=!eth0 , if possible.

As of December 16, 2008, changes are still not present in the official Red Hat guide.

Many thanks,

Comment 34 Răzvan Sandu 2008-12-16 06:42:07 UTC
Please also add a few more comments about other useful options (common scenarios...) in DHCP, such as:

- how to provide workstations with information about the POP3 or SMTP server to use (is it possible to let a remote e-mail client, say Thunderbird or mutt, learn these parameters from the DHCP server instead of statically configuring ? This would be especially useful for roaming laptops - provide the local SMTP server to temporary clients, with no SMTP setting alteration)

- how to provide worksttions with informations about static routes, if possible/recommended

- how to correct the "Vista bug": a stock computer with Microsoft Windows Vista will *not work* with the default/example configuration of GNU/Linux DHCP unless a flag is set.


Since it's very common to have GNU/Linux DHCP servers for Windows workstations, this worths to be mentioned in the guide.

Best regards,

Comment 35 Murray McAllister 2009-01-04 04:30:16 UTC
re comment #33

I believe the only way to exclude interfaces is to list the ones you want to listen on (if you do not list any, all of them are used as far as I know).

Regarding not knowing the interfaces ahead of time, is this for a server or a desktop? You should know the server interfaces ahead of time.

re comment #34

1. I spoke to support, and they believe it is not possible to cleanly do this (pop3, smtp, email clients learning...) with DHCP alone. Look into avahi (man avahi-daemon and <http://avahi.org/wiki/Avah4users#Documentation>).

2. Refer to "man 5 dhcp-options". This documents an "option static-routes" option.

3. By default, the DHCP server in Red Hat Enterprise Linux 5 is configured to accept broadcast - so this should not be an issue.

Comment 36 Murray McAllister 2009-01-04 04:37:37 UTC
These changes should be on redhat.com/docs soon. Apologies for the delay! :)

Note You need to log in before you can comment on or make changes to this bug.