<HTML dir=ltr><HEAD><TITLE>Why DHCP client's DHCPREQUEST goes on all virtual interfaces?</TITLE>
<META http-equiv=Content-Type content="text/html; charset=unicode">
<META content="MSHTML 6.00.2900.3429" name=GENERATOR></HEAD>
<BODY>
<DIV id=idOWAReplyText70769 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>Hi</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>In usual cases the DHCP client sends out a few DHCPDISCOVER packets and if it receives no response it simply goes silent. No more packets are sent right ?? </FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>If that is the case, then why in our set-up the dhclient is flooding the network with DHCPDISCOVER messages ?</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Regards,</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>Abhijeet</FONT></DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Abhijeet Kumar Sinha (WT01 - Computing and Storage IPG)<BR><B>Sent:</B> Tue 12/2/2008 6:22 PM<BR><B>To:</B> dhcp-users@lists.isc.org<BR><B>Subject:</B> Why DHCP client's DHCPREQUEST goes on all virtual interfaces?<BR></FONT><BR></DIV>
<DIV><BR>
<P><FONT size=2>Hello All,<BR><BR>We observed a behavior of the DHCP client which has been bogging us down for many days now.<BR><BR>We are using DHCP Server V3.0.5 and the DHCP client of the same version on CentOS 5.2<BR>We need to implement VLAN and hence 8021q module is loaded on physical machines. Also we have gvrpcd running on the physical machines<BR><BR>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.<BR><BR>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.<BR><BR>e.g ip's to be allocated to eth0    192.168.1.0/24<BR>ip's to be allocated to eth0.2    192.168.2.0/24<BR>ip's to be allocated to eth0.3    192.168.3.0/24<BR><BR>But after a service network restart, we have the ip allocation as<BR><BR>eth0     192.168.1.150<BR>eth0.2   192.168.2.199<BR>eth0.3   192.168.2.199<BR><BR>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.<BR><BR><BR>Regards,<BR>Abhijeet<BR></FONT></P></DIV><P><strong><span style='font-size:10.0pt;font-family:
"Palatino Linotype","serif";color:green'> Please do not print this email unless it is absolutely necessary. </span></strong><span style='font-family:"Arial","sans-serif"'><o:p></o:p></span></p>


<p> The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. </p>

<p>WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. </p>
<p>
www.wipro.com
</p>
</BODY></HTML>