Why DHCP client's DHCPREQUEST goes on all virtual interfaces?

[abhijeetaks]

Hello All,

We observed a behavior of the DHCP client which has been bogging us down for many days now.

We are using DHCP Server V3.0.5 and the DHCP client of the same version on CentOS 5.2
We need to implement VLAN and hence 8021q module is loaded on physical machines. Also we have gvrpcd running on the physical machines

We added virtual interfaces using the vconfig command and created 2 vif's (eth0.2 and eth0.3) and also created the ifcfg-<interface-name> file, where we say the option BOOTPROTO=dhcp.

Now if we do a "service network restart". I can see in my router and DHCP server that DHCPDISCOVER/DHCPREQUEST for each interface comes via eth0 eth0.2 and eth0.3! i.e for each interface 3 DHCPDISCOVER/DHCPREQUEST packet are being sent. So the DHCP server does a DHCPOFFER on subnets to be allocated to eth0, eth0.2 and eth0.3 . The DHCP client on the physical machine accepts the first DHCPOFFER and discards the rest. In many cases eth0.3 acquires the IP meant for eth0.2 and then the dhcp-client for eth0.3 goes on to flood the DHCP server with innumerable DHCPDISCOVER or DHCPREQUEST.

e.g ip's to be allocated to eth0 192.168.1.0/24
ip's to be allocated to eth0.2 192.168.2.0/24
ip's to be allocated to eth0.3 192.168.3.0/24

But after a service network restart, we have the ip allocation as

eth0 192.168.1.150
eth0.2 192.168.2.199
eth0.3 192.168.2.199

and then /sbin/dhclient for eth0.3 goes on to flood the network with DHCPDISCOVER or DHCPREQUEST. These packets are actually observed in the router logs and also the logs on DHCP server, where it does the DHCPOFFER for all DHCPREQUEST made for eth0.3. A point to be noted is unlike other DHCPREQUEST which are limited to a few trials, these DHCPREQUESTs are huge in number, enough to slow down the complete network.


Regards,
Abhijeet

[Lazydog]

DHCP requests are a broadcast

[abhijeetaks]

ofcourse we are aware that DHCPDISCOVER is broadcast... DHCPREQUEST in most cases ( actually in all cases in *nix ) is unicast directed to the "dhcp-server-identifier". But dats not my problem.

When DHCPDISCOVER is being sent from vif 2 and vif 3 simultaneously , then when vif2 was supposed to get an ip in 192.168.2.0/24 subnet and vif 3 was supposed to get ip in 192.168.3.0/24 subnet , vif 3 actually gets an ip in 192.168.2.0/24 subnet and dhclient running for vif3 goes on to sent more and more DHCPDISCOVER packets which jam the network.

[Lazydog]

Are you running one subnet per LAN or are you running both subnets over the same LAN?

If you are doing the last then you can expect 192.168.2.0/24 to be given out until there are no more addresses then 192.168.3.0/24 will start to be given out.
If you have one subnet per LAN then you have a setup issue.

[abhijeetaks]

Are you running one subnet per LAN or are you running both subnets over the same LAN?

I am running two subnets for the two VLANs

I believe the problem was not with the DHCP Client but with VMware Server. The vif's are bridged with vmnet devices. We found out the bug, did a workaround. Hope it works well.