Why DHCP client's DHCPREQUEST goes on all virtual interfaces?
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
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.