Find the answer to your Linux question:
Results 1 to 5 of 5
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 ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Dec 2008
    Location
    Bangalore
    Posts
    5

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


    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

  2. #2
    Linux Guru Lazydog's Avatar
    Join Date
    Jun 2004
    Location
    The Keystone State
    Posts
    2,677
    DHCP requests are a broadcast

    Regards
    Robert

    Linux
    The adventure of a life time.

    Linux User #296285
    Get Counted

  3. #3
    Just Joined!
    Join Date
    Dec 2008
    Location
    Bangalore
    Posts
    5
    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.

  4. $spacer_open
    $spacer_close
  5. #4
    Linux Guru Lazydog's Avatar
    Join Date
    Jun 2004
    Location
    The Keystone State
    Posts
    2,677
    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.

    Regards
    Robert

    Linux
    The adventure of a life time.

    Linux User #296285
    Get Counted

  6. #5
    Just Joined!
    Join Date
    Dec 2008
    Location
    Bangalore
    Posts
    5
    Quote Originally Posted by Lazydog View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •