No DHCP response (Multiple VLAN setup)



  • Server
    • FOG Version: 1.3.5
    • OS: CentoOS 7
    Description

    Here is the situation I am having… I’ve been scouring the internet for a few days now with no luck solving so I’m hoping someone can point me in the right directions. I have a network with 3 vlans each with a different network. I have routers in place that route between the vlans/networks just fine. I previously had Fog 1.20 running on Ubuntu just fine with this setup but I stood up a new Fog server on CentOS and am having an odd issues I cant figure out. The Fog server is on a vlan/network 192.168.91.X. There is a Windows DHCP server on this VLAN that dishes out IP’s just fine. Clients on this VLAN are given DNS servers in the 172.30.10.X VLAN and all clients can access DNS just fine. I’ve setup DHCP option 66 and 67 as specified and clients pxe boot into the Fog menu just fine. Just to clarify the clients are on the 192.168.91.x vlan (same vlan as Fog server). The issues start when I try to do anything from this point on. For example when doing a full host registration there are multiple lines of udhcpc stating that a lease of 192.168.91.x was obtained. Followed deleting routers, adding dns 172.30.1.x. After this it goes to sending discover and sending select for the IP which was obtained by DHCP. At this point the whole process starts again and it just keeps looping until it finally bugs out and says no DHCP response on interface eth0. I’m not really sure where the issue is or what to look at so any friendly pointers in the right direction would be appreciated.



  • @Tom-Elliott

    The IP the machine is getting both in PXE and when selecting any menu option is 192.168.91.242… within the specified range for that vlan. FOG server is on 192.168.91.243. No, the nic is an onboard broadcom nic on a dell optiplex 580


  • Senior Developer

    So doing a quick calculation.

    Gateway IP address shoudl be 192.168.91.193, the broadcast address for the network should be 192.168.91.255. The network address would be 192.168.91.192.

    This leaves a network range applicable to:
    192.168.91.194 through 192.168.91.254.

    The IP Address the machine is getting is within this scope?

    This almost seems like the nic goes down and fails to come back up. Is the NIC on the machine a USB NIC?



  • @Tom-Elliott said in No DHCP response (Multiple VLAN setup):

    55.255.255.192

    It is supposed to be .192. This is also reflected on the fog server as well as all DHCP clients on that vlan.


  • Senior Developer

    @mhanna Is the subnet mask supposed to be 255.255.255.192 or 255.255.255.128? (Is the subnet mask setup properly in more direct fashion).



  • @Tom-Elliott said in No DHCP response (Multiple VLAN setup):

    the host machine when it’s in PXE mode, but in the FOS System, it’s unable to communicate to the Client Machine anymore. This leads me to think it’s getting an IP Address that can’t route anywhere.

    Its getting the same IP in PXE mode as it is when I select the option to register host. They exact same IP. Which is in the same vlan as the fog server… they are actually only 1 IP apart. I can have a continuous ping going and from the FOG server I can get replies up to the point there I select the register host option. At that point the replies stop. I can then reboot the client and once it start the PXE boot process the pings start replying again… from the same IP. Its really odd… while in PXE it gets DHCP with all the correct information… but once we go anywhere in the Fog menu we lose all connectivity. When running the route command on the client once in debug I see the following:

    Destination Gateway Genmask
    default 192.168.91.193 0.0.0.0
    192.168.91.192 * 255.255.255.192

    192.168.91.193 is the correct gateway for this vlan but is unpingable from the client at this point.


  • Senior Developer

    The question here, is more about if the client can ping the FOG Server.

    When you are at the FOG PXE Menu, IP Helpers within the route help direct the traffic on where to get an IP Address. This will typically work, but requires the route be accessible by the FOG Server. The Same, however, path must be setup in reverse.

    So it’s fully possible to enable a DHCP server to receive dhcp, but the client side receiving that IP still needs a way to communicate to the fog server.

    You’re certain the iPXE IP Address issued is the same scope the FOS Engine is receiving?

    I ask the questions because, you state the FOG Server can ping the host machine when it’s in PXE mode, but in the FOS System, it’s unable to communicate to the Client Machine anymore. This leads me to think it’s getting an IP Address that can’t route anywhere.



  • @george1421

    Understood. I was trying to illustrate that there did not appear to be a communication issue between devices on the vlan in question by stateing that they communicate just fine up to a certain point.


  • Moderator

    @mhanna said in No DHCP response (Multiple VLAN setup):

    When the system is pxe booting I am able to ping from the fog server to the client. While at the main fog menu I am able to ping from fog server to client.

    This is because the iPXE (fog menu kernel is running at this point in the booting process)

    The moment I select full host registration I am no longer able to ping from fog server to client.

    At this point, the FOS engine is running and not able to pick up (or think’s it can’t pick up) a dhcp address.



  • @Tom-Elliott

    Based on what I see that would appear to be the case… except I know its not the case. When the system is pxe booting I am able to ping from the fog server to the client. While at the main fog menu I am able to ping from fog server to client. The moment I select full host registration I am no longer able to ping from fog server to client.


  • Senior Developer

    Useful for all I suppose:

    (https://curl.haxx.se/libcurl/c/libcurl-errors.html) is found here.


  • Senior Developer

    @mhanna Well your ping command seems to indicate an issue here as well.

    And for reference:

    CURLE_COULDNT_CONNECT (7)
    
    Failed to connect() to host or proxy.
    

    So both sides seem to point in the same direction. For whatever reason, this vlan is not able to locally communicate.



  • @Tom-Elliott

    Sorry, I did the second… after doing it the correct way the number 7 was returned.


  • Senior Developer

    @mhanna so you did:

    curl request
    echo $?
    

    Or you did:

    curl request echo $?
    

    The first form is what I mean sorry for the confusion.



  • @Tom-Elliott

    I added to the end of the curl command you sent me and it still just drops me back at the command line with no output.


  • Senior Developer

    @mhanna now if you run the curl command followed immediately by:

    echo $? it should print a number



  • @Tom-Elliott

    Yes, valid IP and netmask.


  • Moderator

    @Tom-Elliott While I understand this will not help right now. I was able to duplicate this condition in my home dev environment last week. I was able to also correct it, it was simple and stupid. I’m sure I communicated with you via chat what I found. But at this point I can’t remember for the life of me what it was.

    I was using a virtual box vm and pxe booting it going to test either uefi of dnsmasq and I got that boot loop in FOS. It was a fos thing where it would get the address and then deallocate it and then try again, eventually giving up with the message the OP posted.


  • Senior Developer

    @mhanna But ifconfig returns with a valid IP Address?

    You could try:

    udhcpd -i eth0 (I don’t remember the syntax off the top of my head sorry).



  • @Tom-Elliott

    The command executed. Didn’t generate anything… just ran and nothing. I’m not able to ping from the client to fog server or the other way around. Which is odd because I can ping from the fog serve to every other IP on the VLAN that I’ve attempted.


Log in to reply
 

329
Online

38727
Users

10554
Topics

99920
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.