This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 482983 - Multihomed DHCP server cross-assigns dynamic addreses between subnets
Multihomed DHCP server cross-assigns dynamic addreses between subnets
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: dhcp (Show other bugs)
5.4
All Linux
low Severity medium
: rc
: ---
Assigned To: Jiri Popelka
Release Test Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-29 02:13 EST by Răzvan Sandu
Modified: 2010-03-23 04:29 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-03-23 04:29:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dhcpd.conf configuration file, for testcase (2.48 KB, text/plain)
2009-01-29 02:15 EST, Răzvan Sandu
no flags Details

  None (edit)
Description Răzvan Sandu 2009-01-29 02:13:49 EST
Hello,

Description of problem:

Please consider the following scenario: a multihomed DHCP server (router), with two Ethernet cards, eth0 and eth1.

Each card is supposed to have a single Ethernet segment attached to it, with exactly one IP class, say 192.168.1.0/24 for eth0 and 192.168.2.0/24 for eth1.
 take
The dhcp configuration file is the attached one.

As long as stations are configured in "fixed DHCP" (assigned by MAC), everything works well.

If the administrator enters dynamic "range" clauses in the two subnets, the corresponding IP addreses are cross-assigned (i.e. stations from one Ethernet segment inadvertently take IP addreses from the other, resulting in no TCP/IP connectivity).

There is no clue in the official Red Hat documentation how to treat this case, in the dhcp configuration file.

Version-Release number of selected component (if applicable):
dhcp-3.0.5-13.el5 (on stock CentOS 5.2 + all updates as of January 29th, 2009)

How reproducible:
Always.

Steps to Reproduce:

1. Configure a multihomed DHCP server (and router, i.e. IP forwarding enabled) with two ethernet cards

2. Start DHCP server using a dhcpd.conf configuration file like the attached one

3. Observe server cross-assigning IP addreses between the two segments.

  
Actual results:

The server cross-assigns IP dynamic IP addreses between the Ethernet segments; there is no specific Red Hat documentation how to treat this case (DHCP chapter in the Deployment Guide).


Expected results:

The server should assign IP addresses segment by segment, keeping the two pools of addreses separated (by the physical Ethernet cards and by subnet declarations). A piece of documentation should exist about how to treat this particular case.   

Additional info:

Please see related bug #435599.
Comment 1 Răzvan Sandu 2009-01-29 02:15:25 EST
Created attachment 330325 [details]
dhcpd.conf configuration file, for testcase
Comment 2 Răzvan Sandu 2009-11-04 17:31:20 EST
Even this was reported on Red Hat/CentOS 5.2, I've hit this bug again in 5.4...

Is there any way to link each subnet/IP class to the corresponding network interface (say 192.168.1.0/24 to eth0, 192.168.2.0/24 to eth1) ?

Regards,
Răzvan
Comment 3 Jiri Popelka 2010-02-15 10:27:24 EST
Hi,

sorry for such a big delay.

Looking at your dhcpd.conf I think the problem is in the 'shared-network' statement.
The 'shared-network' statement in your configuration tells the server that the two subnets are on the same network segment.

The following change in your dhcpd.conf fixes
the problem on my testing machine:

--- dhcpd.conf.orig     2010-02-15 15:38:44.000000000 +0100
+++ dhcpd.conf          2010-02-15 15:57:05.000000000 +0100
@@ -5,7 +5,7 @@
 ddns-update-style interim;
 ignore client-updates;
 
-shared-network example {
+#shared-network example {
 
         subnet 192.168.1.0 netmask 255.255.255.0 {
                 authoritative;
@@ -77,5 +77,5 @@
          	
         }
 
-}
+#}

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